On 21 Aug 2011, at 15:33, John Clymer wrote: > As part of my table-ization of cpuinfo.pas, I am including a generic part for > each (no code published for this yet.) The caveat to this is that FLASH size > and SRAM sizes are just set to extremely large (1 MB each for now). Which > means if the code size exceeds the space of the device - the compiler/linker > will not catch the overflow of the available resource. (Running objsize on > the ELF file will display the sizes - so I just run that after every > successful compile.)
As I pointed out, this will always fail because the stacktop is set beyond the available ram. It will cause an exception I think. How do you propose to be able to set the actual ram top for the generic part, or am I missing something? > > Also, still testing, but I have the "interrupt" reserved word working (more > or less, more testing needed.) This takes the interrupt codeword with an > integer. The integer is the offset into the vectors table. If no interrupt > is provided for the given address, it defaults to DefaultHandler in the > startup file - which is just a continual loop - so one can breakpoint on it. > (This can be enabled / disabled via a define in the source.) This is should > only be enabled for the embedded target - but I need to double check to > ensure that is the case. This is a useful development; ideally the integer would be backed by an enumeration as it is a big table. One thing which I did find missing was the interrupt enable and disable assembler codes, so I patched them with data bytes hidden in functions. The keil C compiler does not like these if you link to units doing this (throws a data/code wobbly). See the file attached to bug tracker ID0017365 for how I hacked interrupts. > Fortunately, I have a few days off before the school semester starts - so I > will be working on this quite heavily over the next few days. all power to your elbow... Geoffrey > > John > > > > > From: Geoffrey Barton <m...@periphon.net> > To: FPC developers' list <fpc-devel@lists.freepascal.org> > Sent: Sun, August 21, 2011 6:01:22 PM > Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status > > > 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 > _______________________________________________ > 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
