We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all, I wanted to consult with you regarding a decision I need to make related to my hobby project (sourceforge.net/.../). I am planning to write a port for the ARM architecture (I will probably be using a MCBSTR9) while maintaining the support for the C167. I tried several approaches but I find them all tasteless! I tried to create a hardware specific layer, which allows most of the sources to remain platform independent. That works for the C167, but the RealView compiler for ARM does not like some expressions like "bit" and "far", that do appear in the application code. In addition, the platform dependant code is not correlated; ISR macros intermix with interrupt related code, and other things. Should I make a functional specific platform dependant files? I don't like the sound of that... I tried to use the pre-processor to distinguish between platforms, but that was a huge mess. There is no way I am going to do that. Or maybe I should offer a sleek implementation per platform? That would be the fastest and smallest code. Any ideas or recommendations?
As you said, there are a number of approaches. The preprocessor tricks are only usable to a certain extent, they can quickly lead to a mess. The only (?) other thing to do is to create an API layer to insulate the hardware-specific stuff. It's up to you to decide where this layer is positioned. And I must say that 'bit' and 'far' are most certainly NOT platform-independent. What I would call platform-independent is ANSI C and maybe C99.
Thank you.
Hey,
I tried to create a hardware specific layer, which allows most of the sources to remain platform independent.
What about looking over the fence at Linux, which is also multi platform, and see how they did things there?
-- Joost Leeuwesteijn
Hey Joost, Thanks for your reply. Actually, I did so in the past: I stole their schueduler :) :) (only the concept, of course...)