How to compile C code for a Motorola 68K ECB using TUTOR?

January 28, 2005 5:00 PM

How do I compile C code into code to be run on a Motorola 68K ECB unit using its native TUTOR program? [MI]

This is definitely a bit esoteric, but I'm almost certain it can be done, I just lack the know-how. For one of my ECE classes we've got these ECB-compatible boxes kicking around, and I think it would be wicked sweet if I could actually write C code that would compile into some form of executable for one of these guys. I know what a cross-compiler is and how they work, but I don't know how to cross-compile to the MC68KECB/TUTOR environment. Assume once the code is assembled I can figure out how to get it on the machine. Suggestions and advice greatly appreciated!

posted by onalark to computers & internet (10 comments total)

I assume you're coming from a Windows perspective or you would've at least mentioned gcc. gcc (or g++ for C++) is THE primary open source compiler that's used in Linux and the BSDs and has been for a long time, and it's common knowledge that it can cross-compile for just about anything under the sun, and in a small handful of languages other than C/C++ as well.

I can't find references to the exact specific unit you mention, but not having a lot of knowledge about microcontrollers I don't know if 'ECB' refers to a specific subtype of m68k processor it runs, or is just a descriptor of some kind.

You'll want to check the following links:

http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/M680x0-Options.html#M680x0-Options - specific for m68k options

http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Submodel-Options.html#Submodel-Options - in case there's another name in here you recognize as referring to the environment you need

Props for posting a comparatively esoteric question ;)
posted by cyrusdogstar at 6:07 PM on January 28, 2005

Apologies for re-using the same clichéd word as you did. Need to read slower next time :D
posted by cyrusdogstar at 6:08 PM on January 28, 2005

Nice start, but I'm coming from a UNIX background. I've been messing around with the Gnu Compiler Collection for a couple years, but never had to deal with cross-compiling. I know I want the M68K architecture, but I wasn't able to successfully cross-compile without choosing an operating system, and TUTOR isn't exactly an operating system.

I know the binutils have something to do with this, but past that I'm a bit stuck.
posted by onalark at 6:54 PM on January 28, 2005

Motorola 86Ks are not uncommon at all. Just about anything built in the '80s and early '90s in silicon valley had some sort of 68k part in it. As cyrusdogstar notes, gcc is the choice for esoteric cross-compillation.

DJGPP was at one point the standard gcc port to DOS/Windows. It looks like it is still active, but you may want to google around for other gcc cross-compiler info.

On preview, since you are on unix, you don't need DJGPP. You might find more cross compilation examples that are appropriate to your project by digging around the 68hc11 sites. 68hc11 systems are frequently too small to need an OS.
posted by b1tr0t at 7:03 PM on January 28, 2005

68k's are not uncommon. 86k would be esoteric....
posted by b1tr0t at 7:04 PM on January 28, 2005

Believe it or not, the operating system shouldn't be all that important. To give you a sense, I know someone who was using Think C on a Macintosh to compile code to run on a set-top box he got which just happened to be based on a 68K. He had no support except for what he could divine from the existing ROM. What matters is:
1) how the code gets invoked
2) how to define/call system routines
3) how to manage those things built into C, but not supported natively by the CPU.

Here's a decent document that shows how to get going in creating a cross-compiler with gcc.

1. is usually solved with a little piece of glue assembly to make the stack and to call main. For a 68K, it might be as simple as:
move #stacktop, A7
moveq.l #0, -(A7) ; push a NULL for argv
moveq.l #0, -(A7) ; push a 0 for argc
jmp _main

2. is usually solved with either compiler glue (for the Mac there were extensions to define inline raw data to be inserted in the code. This would be used for creating an A-Line Trap that would be taken over by the ROM routines to actually call the code, glue in an external library usually written in assembly, or surpisingly straightforward definitions like:
static extern int (*pcharOut)(char c) = 0x80002000; /* make a function pointer to a routine fixed at address 80002000 which can be called through a macro */
#define charOut(c) (*pcharOut)(c);

3. is usually some assembly glue provided by the compiler itself for things like floating point (on a 68K with no native FP) or longword math (not fully defined in a plain 68000 for things like long * long or long % long).

I've written 68K cross code that was compiled on an R3000 using gcc and downloaded to a basic monitor which set up interrupt vectors, could load code from a serial port into RAM and could set simple breakpoints. Everything else was done in straight C except for #3, which was a surprisingly small chunk of code.
posted by plinth at 7:33 PM on January 28, 2005

A 68HC11 and a 68K are totally different processors, even though they are both from Motorola. The HC11 is an 8 bit, while most 68K variants have 32 bit registers and a 16 bit data bus.

Tutor is a machine language monitor. It basically just loads the absolute binary of the program you have assembled or compiled and linked to an S19 file (Motorola S record format).

You need to know the memory map of your board, along with what functions are built into its ROM. I don't know anything about this board, as all of the systems I have worked on have been custom.

If it were me, I would use the Motorola freeware assembler and skip C entirely. The 68K has probably the best instruction set of any processor ever made.

I programmed 68K's for about 8 years, and the 8 bit Motorola processors for 12 years before that.
posted by rfs at 7:49 PM on January 28, 2005

What plinth said. I think you should be able to configure GCC to compile for a generic m68k target (well, I think you'll need to specify an object file format, like ELF). Then write a linker script to relocate the program properly for your board's memory layout, and use binutils to convert it to S-records for download.
posted by hattifattener at 9:36 PM on January 28, 2005

Thanks a lot for your help guys. Looks like I may be getting into more than I bargained for :-). Any place to get started for writing this linker script that will relocate the program? I have access to information about the board's layout, but I haven't messed around much with object files or linkers before :-/
posted by onalark at 2:27 PM on January 29, 2005

The 'Info' file for the GNU ld has a section on writing linker scripts. They're not necessarily complicated; basically they just tell the linker, "Okay, put all the code in a section starting at address FOO, and all the initialized, read/write data at BAR, ..." and so on. A minimal one tells the linker "just stash everything in order starting at address 0", which might or might not be what you want; I forget if the 68k has interrupt vectors there or something.

Converting to s-records is as easy as invoking objcopy with "-O srec". (Objcopy is part of the GNU binutils that'll have been built along with the cross-compiler.)

If you already have the ability to write stuff for the board in assembly language, you could use "gcc -S" to produce assembly files from your C sources, but gcc might use a different set of mnemonics from what your assembler is using.

Also, I'd suggest asking in comp.arch.embedded for pointers (or read the recent posts there looking for a FAQ).
posted by hattifattener at 12:30 AM on January 30, 2005