<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Ramtop for a generic part defined as having 1 MB of SRAM<br><br>In the generic startup file, place an 8 KB array, inside a chunk of assembly, set stack_top = top of the array. So long as the program doesn't exceed the SRAM space AND the program doesn't exceed the array size - no problem. (The actual size will have to be debated a bit, I think 8KB should suffice - but this would preclude small devices from being used this way.)<br><br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Geoffrey Barton <mrb@periphon.net><br><b><span style="font-weight:
bold;">To:</span></b> FPC developers' list <fpc-devel@lists.freepascal.org><br><b><span style="font-weight: bold;">Sent:</span></b> Sun, August 21, 2011 7:06:05 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [fpc-devel] Arm Thumb2 - Stellaris status<br></font><br>
<meta http-equiv="x-dns-prefetch-control" content="off"><base><br><div><div>On 21 Aug 2011, at 15:33, John Clymer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse:separate;font-family:Verdana;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;font-size:medium;"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-family:times, serif;font-size:12pt;"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;">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.)<br></div></div></div></span></blockquote><div><br></div>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?</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse:separate;font-family:Verdana;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;font-size:medium;"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-family:times, serif;font-size:12pt;"><div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;"><br>Also, still testing, but I have the "<span style="font-weight:bold;">interrupt"<span class="Apple-converted-space"> </span></span>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.<br></div></div></div></span></blockquote><div><br></div>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 ID<span class="Apple-style-span" style="color:rgb(17, 17, 17);font-family:Arial, Verdana, sans-serif;">0017365 for how I hacked interrupts.</span></div><div><font class="Apple-style-span" color="#111111" face="'Trebuchet MS', Arial, Verdana, sans-serif"><span class="Apple-style-span" style=""><br></span></font></div><div><font class="Apple-style-span" color="#111111" face="'Trebuchet MS', Arial, Verdana, sans-serif"><span class="Apple-style-span" style=""><br></span></font></div><div><blockquote type="cite"><span class="Apple-style-span"
style="border-collapse:separate;font-family:Verdana;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;font-size:medium;"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-family:times, serif;font-size:12pt;"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;">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.<br></div></div></div></span></blockquote><div><br></div>all power to your elbow...</div><div><br></div><div>Geoffrey</div><div><br><blockquote type="cite"><span class="Apple-style-span"
style="border-collapse:separate;font-family:Verdana;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;font-size:medium;"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-family:times, serif;font-size:12pt;"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;"><br>John<br><br><br><br></div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-family:times, serif;font-size:12pt;"><br><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-family:arial, helvetica, sans-serif;font-size:10pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight:bold;">From:</span></b><span class="Apple-converted-space"> </span>Geoffrey Barton <<a rel="nofollow"
ymailto="mailto:mrb@periphon.net" target="_blank" href="mailto:mrb@periphon.net">mrb@periphon.net</a>><br><b><span style="font-weight:bold;">To:</span></b><span class="Apple-converted-space"> </span>FPC developers' list <<a rel="nofollow" ymailto="mailto:fpc-devel@lists.freepascal.org" target="_blank" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>><br><b><span style="font-weight:bold;">Sent:</span></b><span class="Apple-converted-space"> </span>Sun, August 21, 2011 6:01:22 PM<br><b><span style="font-weight:bold;">Subject:</span></b><span class="Apple-converted-space"> </span>Re: [fpc-devel] Arm Thumb2 - Stellaris status<br></font><br><br>On 20 Aug 2011, at 15:46, David Welch wrote:<br><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> 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<span class="Apple-converted-space"> </span><a rel="nofollow" target="_blank" href="http://ARM.com">ARM.com</a>. So maybe that is another reason for keeping the peripheral offset definitions and peripheral drivers separate and out of the compiler.<br>>><span class="Apple-converted-space"> </span><br>>> Geoffrey<br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> 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.<br><br>You are right, of course. I have not looked at the data for other than Stellaris devices, I just generalised from the ARM TRM.<br><br>><span class="Apple-converted-space"> </span><br>> 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.<br><br>not quite, but it is my aspiration :-)<br><br>><span class="Apple-converted-space"> </span><br>> 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.<br>><span class="Apple-converted-space"> </span><br>> 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.<br>><span class="Apple-converted-space"> </span><br>> 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.<br><br>The approach used in coide is quite interesting. Have a look
on<span class="Apple-converted-space"> </span><a rel="nofollow" target="_blank" href="http://coocox.org">coocox.org</a>. They have it down to box ticking.<br><br>><span class="Apple-converted-space"> </span><br>> 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.<br><br>I agree.<br><br>><span class="Apple-converted-space"> </span><br>> I understand this is a work in progress and sorting everything out will take some time.<br><br>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.<br><br>Geoffrey.<br><br>><span
class="Apple-converted-space"> </span><br>> David<br>><span class="Apple-converted-space"> </span><br>> _______________________________________________<br>> fpc-devel maillist - <span class="Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:fpc-devel@lists.freepascal.org" target="_blank" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><span>><span class="Apple-converted-space"> </span><span><a target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a></span></span><br><br>_______________________________________________<br>fpc-devel maillist - <span class="Apple-converted-space"> </span><a rel="nofollow" ymailto="mailto:fpc-devel@lists.freepascal.org" target="_blank" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><a rel="nofollow"
target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a><br></div></div></div>_______________________________________________<br>fpc-devel maillist - <a rel="nofollow" ymailto="mailto:fpc-devel@lists.freepascal.org" target="_blank" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><a rel="nofollow" target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a><br></div></span></blockquote></div><br><meta http-equiv="x-dns-prefetch-control" content="on"></div></div>
</div></body></html>