<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">Did an analysis of the Stellaris current product lineup, there are over 180 current Stellaris products on TI's selection guide. Boiling through the FLASH and RAM availability, there are 31 unique configuratios of FLASH / SRAM between those 180 devices. So, the case() statements in t_embed.pas will have 31 more entries to completely support the entire line of Stellaris processors (and a few more with products slated for future release).<br><br>Currently, everything is in a handful of giant arrays. Just wondering if it would be better to switch to a record structure for the controller entries - rather than individual arrays. (Add in a variety of STM parts and the other manufacturers, and there could easily be over 100 memory configurations in the table.)<br><div><br>Looking at
RTL support. Currently for each ARM variant, they have a contoller unit (the controllerunitstr entry). Inside the current controller units, registers are defined. These registers definitions "automatically" become part of the variable space of an application. Is the intent for ALL controller registers be provided inside the RTL ? I would think this would be better provided by outside files. (i.e. "uses LM3S8962" - brings in a file containing all the 8962 register definitions.) <br><br>Having an outside file (it would be akin to a C header file - interface only specifications for the registers, and that would be it) would be much clearer than hiding the details inside a "hidden" file. If the user wants to chase down exactly where the definition is coming from, using a non-RTL file saves the user from having to dig through the compiler source to determine where it was coming from. (Although for a
newb, it may be preferable to have them automatigically available.)<br><br>My suggestion would be that the register definitions come in an UNIT file that only defines registers. The controller unit in the compiler source would only provide the bare minimum necessary to bring the system up and call PASCALMAIN. However, if it is deemed better to have the entire register set defined inside the RTL - that would be fine too.<br><br>John<br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br><div style="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> Florian Klämpfl <florian@freepascal.org><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> Tue, August 9, 2011 7:59:06 PM<br><b><span
style="font-weight: bold;">Subject:</span></b> Re: [fpc-devel] Arm Thumb2 - Stellaris status<br></font><br>
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:<br>> On 09-08-2011 15:53, Geoffrey Barton wrote:<br>>><br>>> On 9 Aug 2011, at 14:14, John Clymer wrote:<br>>><br>>>> I was thinking more of a generic controller class, including a<br>>>> memory.def (or whatever one wants to name it) file. That would be<br>>>> easiest as it would only effect the t_embed.pas file (and cpuinfo.pas<br>>>> file to add the generic type.)<br>>>><br>>>> Haven't looked into possibly a compiler option (and may easily be<br>>>> more trouble than a command line option):<br>>>> {$ARM_FLASH_START xxxxxxxx}<br>>>> {$ARM_FLASH_LENGTH xxxxxxxx}<br>>>> {$ARM_SRAM_START xxxxxxxx}<br>>>> {$ARM_SRAM_LENGTH xxxxxxxx}<br>>>><br>>>> But, I still think a static memory definition file would require the<br>>>> least amount of code
changes. And would only effect only the ARM<br>>>> related files.<br>>><br>>> The compiler option works well when you have conditional options for<br>>> different target builds using ifdefs, which I do I lot. It makes it<br>>> very easy to see if it is in the source file as it can be locked to<br>>> other options and you only need to select it in one place.<br>>><br>>> A separate linker file starts to make FPC handle like any other<br>>> compiler :( instead of the joy to use it is :)<br>> I agree. Keeping the configurations in code is easier to manage,<br><br>Yes. I think as well that everything should stick in the compiler. FPC<br>is open source, so no need for a convolution of compiler support and<br>external files. Full support of all devices will lead to a huge number<br>of interwinded include files in the rtl anyways.<br><br>> compared to the spiderweb of magically named files of
other embedded<br>> compilers<br>> <br>> I think that maybe creating an abstract class hierachy of chip families,<br>> instead of the current solution of a single large case statement, would<br>> be a better solution in the long run<br><br>Well, it can be done also by some sets like<br>controllers_stellaris128flash64ram. I don't think that a big full<br>fledged class hierary is needed. Even the case statement might be<br>sufficient.<br>_______________________________________________<br>fpc-devel maillist - <a ymailto="mailto:fpc-devel@lists.freepascal.org" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><span><a target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a></span><br></div></div>
</div></body></html>