[Mspgcc-users] Beginners guide to contributing to MSPGCC please?

[Wayne Uroda]

Hi everyone, I work at a company where one of our products uses an MSP430F147. We have been using MSPGCC since the start of that particular project and are very happy with how it works. Recently we have started a new project around the MSP430F2418. We have since learned that MSPGCC doesn't support the extended memory above 64kB. I have a little bit of time to try and fix MSPGCC, because we want to provide it to customers so that they can develop custom firmware for the device. I need a bit of a push in the right direction so I can help to get this support into msp430-gcc. Firstly, I have built binutils-2.18.50 with the following patches applied, in this order: (from /packaging/patches) binutils-2.18-14x1-20x1-20x2-20x3-22x4-42x-42x0-461x.patch binutils-2.18-msp430x24x-msp430x26x.patch binutils-ld_scripts.patch binutils-2.18-430X.patch binutils builds and as far as I can tell the assembler contains some kind of support for calla and other extended opcodes. If I create a file test.asm and write in it: calla #0x12345 and assemble it with no arguments, I get the following: $ ./msp430-as test.asm test.asm: Assembler messages: test.asm:1: Error: Extended instruction (calla) not allowed with msp430x11 mcu This leads me to think that there is some support for calla (msp430-as knows about it at least). When I try with the mcu set to msp430x2418 I get the following: $ ./msp430-as -mmcu=msp430x2418 test.asm test.asm: Assembler messages: test.asm:1: Error: Illegal instruction or not implemented opcode. it works fine though if my assembly file reads "call #0x1234" so I think it doesn't know about calla somehow. I have also built msp430-gcc according to the build instructions in the mspgcc manual, against the patched version of binutils. I get the same assembler error when I try to use inline assembly with the "calla" instruction. Is it just the calla instruction that doesn't work? can somebody provide me with some instructions on how to get started with getting the inline assembler working, so I can look at patching gcc to allow it to call functions above 64kB? Many thanks, - Wayne Uroda