<div dir="ltr">Ja.<div>That about equates to what I normally do. When one uses a makefile (in Ada) the renaming comes in handy, since then you just refer to the directory for that specific MCU in the makefile. And when this MCU proves to small (happens with these little critters) you just Make with a different MCU directory as argument to a switch.</div><div>Many years ago I modified the Oberon-0 compiler for to work for AVR. It worked well enough, but then I knew too little to make it into a proper tool set.</div><div><br></div><div>Now I would say that we need to have Oberon-07 into GCC. A cross compiler toolset is not so difficult to build once the basics are there. It would give a new lease of life to Oberon as a language. I for one would gladly switch.</div><div><br></div><div>Jan.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 8, 2018 at 5:24 PM, Jörg <span dir="ltr"><<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DE-CH" link="blue" vlink="purple"><div class="m_5077777621053284913WordSection1"><p class="MsoNormal"><span lang="EN-US">J.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">There is no “AT” keyword in Oberon so far.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">So, it’s up to us to define the semantics, under the condition we would implement this.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">But as Chris pointed out, he works without it.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">What I normally do is: I have a several low level constant definitions (the same as Chris) and name them differently.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Then in the driver layer, I import them with alias<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">IMPORT </span>MCU := LPC1769<span lang="EN-US"><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"> and in other driver<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">IMPORT MCU := LCP1347<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">br<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Jörg<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">Von: </span></b><span style="font-size:12.0pt;color:black">Oberon <<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank">oberon-bounces@lists.inf.<wbr>ethz.ch</a>> im Auftrag von Jan de Kruyf <<a href="mailto:jan.de.kruyf@gmail.com" target="_blank">jan.de.kruyf@gmail.com</a>><br><b>Antworten an: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Datum: </b>Mittwoch, 8. August 2018 um 16:50<br><b>An: </b>ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>><br><b>Betreff: </b>Re: [Oberon] Oberon FPGA hardware point of view<u></u><u></u></span></p></div><div><div class="h5"><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Joerg,<u></u><u></u></p><div><p class="MsoNormal">Yes<u></u><u></u></p></div><div><p class="MsoNormal">But now it is not immediately obvious that you do an address overlay. Because I think that the AT keyword is wrong for what it does.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Cheers<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">j.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Aug 8, 2018 at 3:58 PM, Jörg <<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">Chris<br><br>With your file organization and Walter's syntax idea you could write something like this:<br><br>IMPORT MCU, SYSTEM;<br><br>PROCEDURE PutCh*(ch: CHAR);<br> CONST txEmpty = 5;<br> VAR<br> lineStatus: SET AT MCU.ULSR;<br> tx: CHAR AT MCU.UTHR;<br> BEGIN<br> REPEAT UNTIL txEmpty IN lineStatus;<br> tx := ch<br> END PutCh;<br><br>br<br>Jörg<br><br>Am 08.08.18, 15:33 schrieb "Oberon im Auftrag von Chris Burrows" <<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank">oberon-bounces@lists.inf.<wbr>ethz.ch</a> im Auftrag von <a href="mailto:chris@cfbsoftware.com" target="_blank">chris@cfbsoftware.com</a>>:<u></u><u></u></p><div><div><p class="MsoNormal"><br> > -----Original Message-----<br> > From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank">oberon-bounces@lists.<wbr>inf.ethz.ch</a>] On Behalf Of<br> > Walter Gallegos<br> > Sent: Wednesday, 8 August 2018 4:04 AM<br> > To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank">oberon@lists.inf.ethz.ch</a>; Walter Gallegos<br> > Subject: [Oberon] Oberon FPGA hardware point of view<br> > <br> > A FPGA hardware designer point of view;<br> > <br> > In some projects (all my projects) the CPU executes software as<br> > coprocessing; in parallel but outside the main data flow of hardware<br> > DSP; hardware is faster and more efficient than software DSP.<br> > <br> > On this scenery, the memory map could change from one project to<br> > another project. So, hardware/software designers need certain degree<br> > of freedom to access memory mapped areas.<br> > <br> > I propose two modifications :<br> > <br> > 1/ Add memory mapped variables<br> > <br> > VAR [label] : [type] AT [address]<br> > VAR [label] : ARRAY [size] OF [type] AT [address]<br> > <br><br> On the surface this sounds OK but in reality the sheer number of addresses<br> involved led us to use a different approach.<br><br> Our technique follows Paul Reed's recent advice here i.e. separate all of<br> the hardware specific details from everything else into the lowest level<br> modules. This has worked out really well for us. It avoids the software<br> maintenance nightmare of having to track down / modify hard-coded addresses<br> and other hardware-specific details scattered throughout a system.<br><br> With the Astrobe for ARM Cortex-M3, M4 and M7 Oberon systems we were faced<br> with the prospect of having to maintain hundreds of memory-mapped addresses<br> for similar, but different, memory-mapped peripherals for more than 60<br> different types of microcontroller from two different manufacturers (NXP and<br> STMicroelectronics). You might expect to have a couple of different sets of<br> common definitions for each manufacturer but we ended up needing 11<br> altogether. Not as bad as 60 perhaps but I'm convinced the designers could<br> have done a lot better at eliminating inconsistencies. <br><br> The scheme we have used is this: There is a single module, called MCU.mod,<br> for each family of microcontrollers e.g. LPC176x (NXP Cortex-M3), STM32F7<br> (STM Cortex-M7) etc. There are eleven of these, all with the same name but<br> stored in a folder named after the microcontroller family. <br><br> The *key* feature is: the *only* items contained in the MCU module are CONST<br> declarations. <br><br> Each named constant represents a peripheral register address. Much of the<br> time just the base address of each peripheral is different from one MCU to<br> another so we take advantage of the fact that CONSTs can contain arithmetic<br> expressions. We can then specify a single base address for each device and<br> the other related registers are common offsets from that base. <br><br> e.g. <br><br> for UART0:<br><br> U0Base* = 04000C000H;<br> U0RBR* = U0Base+000H;<br> U0THR* = U0Base+000H;<br> U0DLL* = U0Base+000H;<br> U0DLM* = U0Base+004H;<br> ...<br><br> For UART2:<br><br> U2Base* = 040098000H;<br> U2RBR* = U2Base+000H;<br> U2THR* = U2Base+000H;<br> U2DLL* = U2Base+000H;<br> U2DLM* = U2Base+004H;<br> ...<br> ...<br><br> RBR, THR, DLL, DLM etc. are the names used for each UART function exactly as<br> used by NXP in their programming reference manual. In case you are<br> wondering, yes - RBR, THR and DLL all map to the same absolute address.<br><br> Now, just to be different, the corresponding base address for the LPC1347<br> family is U0Base* = 040008000H. If that wasn't bad enough, sometimes the<br> relative offset addresses are different as well! <br><br> There are more than 500 of these definitions in the LPC176x version of<br> MCU.mod and there are still a number of peripherals that we have not yet<br> included.<br><br> Now that we have isolated what is *different* in MCU.mod, we can then<br> implement a common hardware-interface module (e.g. Serial.mod) which uses<br> these constant definitions, with their generic names, when implementing the<br> (still hardware-specific) functions:<br><br> IMPORT MCU, SYSTEM;<br><br> PROCEDURE PutCh*(ch: CHAR);<br> BEGIN<br> REPEAT UNTIL SYSTEM.BIT(ULSR, 5);<br> SYSTEM.PUT(UTHR, ch)<br> END PutCh;<br><br><br> The next level up in the module hierarchy is the familiar common<br> *hardware-independent* 'Out' module. This works with all the different<br> microcontrollers providing functions Out.Char, Out.String. It includes the<br> statement:<br><br> IMPORT Serial;<br><br> And the functions just call PutCh in different ways.<br><br> The mechanism that we use to specify which particular MCU.mod and Serial.mod<br> files are actually used when we compile an application which targets a<br> particular family of microcontrollers is to associate the application with a<br> configuration file containing mcu-specific 'search paths'. An extract from<br> the map file for an application called 'Info' shows the consequences:<br><br> LPC1769:<br> MCU D:\AstrobeM3-v6.4\Lib\<wbr>LPC1769\MCU.arm<br> Out D:\AstrobeM3-v6.4\Lib\<wbr>General\Out.arm<br> Serial D:\AstrobeM3-v6.4\Lib\LPC1769\<wbr>Serial.arm<br> Info D:\AstrobeM3-v6.4\Examples\<wbr>General\Info.arm<br><br> LPC1347:<br> MCU D:\AstrobeM3-v6.4\Lib\<wbr>LPC1347\MCU.arm<br> Out D:\AstrobeM3-v6.4\Lib\<wbr>General\Out.arm<br> Serial D:\AstrobeM3-v6.4\Lib\LPC1347\<wbr>Serial.arm<br> Info D:\AstrobeM3\Release\Examples\<wbr>General\Info.arm<br><br> Most of the time the only functions we need to use with these CONST<br> addresses are SYSTEM.PUT to write a value, SYSTEM.GET to read a value and<br> SYSTEM.BIT to test the value of a single bit. <br><br> If multi-byte data needs to be efficiently read or written to an Oberon<br> ARRAY or RECORD, SYSTEM.ADR, SYSTEM.COPY and SYSTEM.VAL (or ARRAY OF BYTE<br> parameters) are the Oberon features that can be used. Once the conversion<br> has been done from a byte-stream to an application-specific Oberon data<br> structure at the hardware interface the Oberon data structure can be used<br> naturally in the application from then on. It only needs to be converted<br> back to a byte-stream when the hardware needs to be updated. <br><br> Regards,<br> Chris Burrows<br> CFB Software<br> <a href="http://www.astrobe.com" target="_blank">http://www.astrobe.com</a><br><br><br> --<br> <a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br><br><br><br>--<br><a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><u></u><u></u></p></div></div></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a> <u></u><u></u></p></div></div></div></div>
<br>--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
<br></blockquote></div><br></div>