Hello,
I'm trying embedded arm port (LPC2xxx) and I want to contribute to the full port.
I'm adding new controllers right now. I just wanted to know, from compiler side, what is the state of development? what need to be enhanced or developed to have a full working port?

Regards
octal

It is fully working as long as the controller is supported/added.

Thank you Florian.

I'll publish all LPCxxx serie once I finish work on them.

Just wanted to ask another question:
is there any support for interrupt procedures? how to declare a proc as an interrupt and associate it to its vector?
is that implemented or have I to rework the parser and add needed stuff? Regard

Thank you Florian. I'll publish all LPCxxx serie once I finish work on them.

Please publish work early if possible. It makes it easier to correct wrong coding.

Just wanted to ask another question: is there any support for interrupt procedures?

It is implemented for DOS/go32v2.

how to declare a proc as an interrupt and associate it to its vector?

Not yet, but my processor specific units declare callbacks/hooks.

is that implemented or have I to rework the parser and add needed stuff?

I think the easiest is to do register saving etc. in a wrapper in the processor specific unit and then call a simple hook/call back being a procedure variable.

Ok. thanks Floran.
I was studying your files.
I'm working actually on the LPC2148. I'm porting the header file for LPC214x (LPC2141/42/44/46/48), and I'm adding the mcus to the linker and arm cpuinfo concerned units.

Once I got it to work to the 2148 I'll post this first post.

Regards
Ahmed

I'll also try to do tests on interrupt handling using callbacks, and let you know the result (tests on real hardware next weekend :) )

Regards
Ahmed
octal A/T pocketmt.com
http://pocketmt.com

Ok, great. To avoid that the patch is forgotten, just open an issue in the bug tracker and attach the patch.

Just a question Florian,

C offers the "volatile" attribute to mention that a variable can change value without source code intervention (for example a variable that maps to a port register).
how can that be handled by the compiler in order to avoid that the compiler do optimize pascal instructions that uses these vars?

Regards
Ahmed
http://www.pocketmt.com

C offers the "volatile" attribute ...

I never found an issue when using static public variables for synchronizing threads (while avoiding "atomic" problems). So seemingly FPC (and Delphi) handles all non-local variables as volatile. (While C usually optimizes them using temporary local variables if appropriate.)

C can do local (Stack?) volatile variables. This does not seem to make much sense.

-Michael

Michael Schnell wrote

C can do local (Stack?) volatile variables. This does not seem to make much sense.

Why not? You could pass a pointer to this stack variable to another thread which could write to it asynchronously to your thread.

Micha

Micha Nelissen wrote

You could pass a pointer to this stack variable to another thread which could write to it asynchronously to your thread.

Ah, I see. Thanks for the enlightenment !

This might cause problem with FPC/Delphi. All local variables that are referenced with a pointer of course will be placed on the stack instead of in a register. But with this paradigm they would need to be handled as volatiles. Seems like slowing down things too much....

-Michael

I had all sort of troubles with gcc aggressive optimizations. Two years ago, I had to initialize SDRAMS for an ARM9 board for example. This requiered to write sequences of data to the same memory address (among other things). I finally wrote this part in assembler, because I could not get this work with gcc.

Something like the fpc {$OPTIMIZATION xxx} compiler switch, which allows to enable/disable optimizations on procedure level, would have helped me a lot. As far as I know, gcc has not such a thing.

Regards, Bernd.

can you provide a working example for the lpc controller?

Regards, Bernd.

Did you already try it and it didn't work or do you need a starting point :)?

no, I did not try it for the lpc series. I have something working for the AT91SAM7S controller but I needed ages to get it work ;-( I could provide this stuff if it would help.

I am considering to replace the AT91 with a lpc controller, but I don't have much time for experiments. I am not totally sure, if the vectored interrupt controllers are working the same way for example and I have no hardware to test at the moment.

Regards, Bernd.