On 20 Aug 2011, at 15:46, David Welch wrote: >> >> >> The great strength of ARM is that the peripherals, even if in different >> locations in different manufacturers parts, are identical in hardware terms >> if they are all cortex m3; that is the IP which they license from ARM.com. >> So maybe that is another reason for keeping the peripheral offset >> definitions and peripheral drivers separate and out of the compiler. >> >> Geoffrey >> >> > > Not sure what you are saying here, almost none of the peripherals are the > same from vendor to vendor. With the cortex-m3 the systick timer and the > VNIC for example are from ARM, sure, but the majority of the items you are > going to use timers, dma, pwm, gpio, clocks and enables, etc are vendor > specific and vastly different from vendor to vendor. Within a vendor they are > very similar if not the same but from ti to st most of the items are not > compatible, likewise from ti to lpc/nxp or ti to atmel, etc.
You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM. > > Normally these are libraries and not buried in the compiler proper, I agree > with that. Perhaps that is what you were saying and I misunderstood. not quite, but it is my aspiration :-) > > And as with libraries you can take them or leave them, that would want to be > the case here (without having to dig into the compiler proper). Would need to > roll your own target to avoid/modify a library. Ideally with the compiler > you want to specify the arm core to take advantages of instructions each > newer core supports. Not use them to tie to boards or systems. > > I was hoping for thumb support but I now see that the choices are limited to > arm and thumb+thumb2 (without any separation between thumb and thumb2). > Actually thumb2 wasnt working for me, I got an arm+thumb2 mix, so I will ride > this along for a while and see what comes up, otherwise limit my use to ARM > targets, or start working on a thumb backend. Adding backends as well as arm > embedded are of interest to me so I may work on a little of both. > > So far it seems to be very straight forward to add a platform/device to fpc > arm embedded, so if the stock support is too bulky or confusing individuals > can cherry pick items they want and make their own simpler target. The approach used in coide is quite interesting. Have a look on coocox.org. They have it down to box ticking. > > Actually what we definitely need here in the near term is an arm generic > target and a thumb2 generic target that does not have any of the vendor > specific items in it, perhaps not even core specific peripherals. I agree. > > I understand this is a work in progress and sorting everything out will take > some time. Unfortunately the discussion is rather torn between the basic simplicity camp and the portmanteau camp. I rather think the latter is more suitable for a commercial company which can afford the maintenance, otherwise it is always out-of-date. Keeping up with new ARM cores is perhaps enough to do already. Geoffrey. > > David > > _______________________________________________ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
