Home
Forgot your password?
New user?
R8C Development on Linux
Up to GCC
Calvin asked me to describe my Linux setup for R8C development here,
so...
Some background... My "natural" environment is Fedora Linux (I work
for Red Hat, so... duh 
. I'm also the guy that did the GCC, SIM,
and newlib ports for the R8C/M16C/M32C chips, and currently maintain
those and the binutils port. I also have a degree in electrical and
computer engineering, and help maintain gEDA's PCB layout editor.
I have a page at http://www.delorie.com/pcb/ that links to most of the
R8C/M32C boards I've done, and the tools I use. Since I can make my
own boards at home, I usually make a custom board for each project
rather than trying to hack an existing starterkit or use a DIP in a
protoboard.
I have a page at http://people.redhat.com/~dj/m32c/ that points to the
current state of the FSF tools (hmm, I should update it). The m32c
port is "normal" in that you should be able to just download the
latest FSF sources and build them like you would for any embedded
target (binutils, gcc, newlib, gcc again, etc). The tools should
build on *any* platform that supports gcc (Linux, Unix, Cygwin, MinGW,
MacOS/X, and maybe even DJGPP). If you build gdb also, it will build
an r8c/m16c/m32c simulator that gdb knows how to talk to, so you can
debug code that doesn't take *too* much advantage of the hardware. It
does simulate the UART that the starterkits use, so you can at least
send text to it and have it work the same under both the simulator and
the hardware). Since the sources are all available, you can of course
add other hardware support as needed. I've added timers and a few
other things at various times, to help me debug code.
I also have a unix-based flashing utility that I wrote that uses the
async serial mode to program everything from a standalone r8c to my
m32c/83 expansion board. I've modified one of the ten-nine cables to
connect the serial port's DTR to the -RESET line through a transistor,
so dropping DTR resets the board. You still need to do -MODE yourself
though, but it's useful with a terminal emulator like minicom - you
drop DTR (stty 0 < /dev/ttyS0) and run minicom - it releases DTR,
releases reset, and the chip starts up just as minicom starts talking
to its serial port. Printf-able boot messages! No gdb-to-hardware
support, though - between printf, blinky lights, gdb+simulator, and a
logic analyzer, I can usually figure out most bugs.
I have a couple of other programmers too - my furnace uses GPIOs off
the gumstix to control mode and reset, and multiplexes one serial port
across the five R8C chips. The flash utility for that setup knows how
to select which chip it's programming. I have a USB-based R8C/20 pod
at http://www.delorie.com/electronics/usb-gpio/ where the GPIO pins on
the FTDI chip control reset and mode, so I can flash the chip over
USB, then reset it and talk to my app over the same USB line.
In general, my programming utilities all have an option to continue
monitoring the UART after it's done flashing. Most know how to reset
the chip and get the user app running too, but on the rest I can
manually reset them and see the boot messages through the flasher's
"console". I also use terminal emulators like minicom and kermit to
connect through the programmer to the chip's uart.
One of these days, I'll put together an "everything you need to know
to program r8c/m16c/m32c chips" package.
As for software, I often copy the crt0 and link map files from
libgloss and tweak them for the specific chip I'm using. I have a
couple of generic "mini-printf" source files I use as needed. I also
have a perl script that parses an easily-edited "I/O map" file to
produce chip-specific .h and .inc files. For example, timer RA looks
like this:
# Timer RA (r8c-26)
tracr 100 : : tundf tedgf : tstop tcstr tstart
traioc 101 : : tipf:2 tiosel toena topcr tedgsel
tramr 102 tckcut tck:3 : tmod:3
trapre 103
tra 104
Most of the modules I write are in C, but some are in assembler.
