jcsbanks

I understand the assembly language of our SH2 ECUs. I have written code snippets which work

I know what I want to write and can string together the assembler instructions to do it.

However, for the life of me I can't work out how on earth to use a modern development environment to simply assemble a few dozen lines of assembly language into a little hex file!

I've downloaded a Windows port of some SH specific gcc binutils - I really need to use "as" to assemble and "ld" to link I believe.

I then type:

as myassemblyfile.txt (which contains my code)

And it produces "a.out"

Then I try to use "ld" which is a "linker" and I have no idea what to do.

a.out seems to be much larger than my code should be and contains symbols which I think the linker is supposed to sort out.

Can someone explain to me how a linker works and how to simplify this whole process?

At present I'm reduced to using a debugger that I can load the entire ROM image into and line by line alter the assembly instructions and read the hex code out and then insert it using a hex editor. The real pain is that for offsets from say the program counter I have to work them out by hand and can't get it to use opcodes with labels!

jcsbanks

As usual when I post something putting down the problem helps me to start working it out.

I've made some progress.

Now I can make a text file with some assembly instructions in.

Then I type as test.txt and this produces a.out
then I type ld -o output.hex a.out and this produces output.hex which has my instructions in it!

However, it defaults to code origin of 0x1000, I need to find the directive to change it. Then work out labels etc.

Then I should be able to move blocks of hex into the ROM.

JoeBee

I don't know witch compiler you use.
On some compilers it is something like this:

.org 0x4000

donour

iTrader: (6)

PM'd

EDIT: are you sure you're using the proper cross build tools? Either way, I have fairly detailed knowledge on how the gnu toolchain works. shoot me and email and I'll help you with any snags.

EDIT2: do you need your assembly to be PIC code?

donour

jcsbanks

Thanks. Can't seem to get anything to work including the command line to change the start, although it doesn't really matter since virtually all the new code I need to do is relative/relocatable.

I have the goal I wanted now which is to be able to assemble simple stuff with labels, and the ability to save the source file.

I can then insert code using a hex editor to move blocks from the assembled file to the ROM, and then load it into a simulator to test.

A bit of a run around compared with an integrated development environment that could probably do the lot, but I need control of every single byte of what I'm producing and these C-based environments produce masses of code just to do nothing it seems.

I need my assembly to be SH2 code to run in our Evo ECUs.

I'm expecting that a first attempt at a patch to read any ROM or RAM address will be about 100 lines of code or so. I'm happy with the sort of protocol I've described on aktivematrix. Need to plan my variables and see what sort of RAM locations I can confiscate

jfitzpat

If you need help with SuperH or the gnu tools, you are always welcome to PM me as well. I've actually done several SHx based projects. I'm happy to help you with targeting and linking, but if you are playing cut and paste into an existing rom, you might want to just write positionless code anyway. If memory serves, this isn't very hard on the SH-2. BRA and BSR are already 'displacement' (position relative to current PC). I believe you have to go register indirect (JMP, JSR, etc.) to use absolute addresses at all.

-jjf

jcsbanks

Thanks jjf, it does seem quite positionless. I'm doing a register indirect JMP out and JMP back to run my own routine on the comms. It is too far to BRA into lots of space in the flash memory.

jfitzpat

Understood. Though, since it is register indrect, you only need to alter the immediates to put the code anywhere in flash. Again, feel free to PM me if you need help with the GNU, Hitachi, or D.D. tools.

-jjf

jcsbanks

Thanks for the help, it is coming together in my mind now

The high up flash areas are the big ones and take a little while to write, I might nestle it somewhere lower down the addresses as it can flash quicker in smaller blocks.

Hopefully with simulator testing and small steps I won't need too many flashes to get each little section working.

I will as usual be sure to share any code and ideas

donour

iTrader: (6)

We do appreciate it.

donour