[Oberon] oberonnet of things

Jörg Straube joerg.straube at iaeth.ch
Mon Aug 24 20:27:15 CEST 2015


Wojtek

The Oberon language with its compiler does not provide the memory requirements you have. Although the compiler could be extended to do so, but then it's not Oberon anymore it's rather "Wojteron" :-)

The Oberon system however allows for a certain amount of memory allocation scheme you ask for. For example - as you mentioned - the HW registers to program HW are defined as the 16 high memory addresses (4 bytes each) beginning at memory adress -4 to memory address -64.
The Verilog code has to be seen as kind of HAL. So, whenever you add new HW to your (Oberon) systen, you should adopt the Verilog code, so the mentioned address space is mapped to your new HW registers.

br. Jörg

> Am 24.08.2015 um 16:36 schrieb <skulski at pas.rochester.edu> <skulski at pas.rochester.edu>:
> 
> Chris:
> 
>  thank you for the clarification. I still think that there is need to
> direct the loader to use a particular address range. Automatic address
> assignment is good for desktop PCs that pretend to have a large and
> uniform memory implemented in SDRAM, with the virtual memory management
> and caching performed under the hood without us even knowing the details.
> All this is very far away from the reality of embedded systems. Here we
> may have very little fast memory (BRAM) and somewhat more slow memory
> (SRAM, SDRAM, or even flash mapped as RAM). It is essential for the system
> performance to locate the frequently used code in fast BRAM. The system
> should allow for telling it which code and which variables are located at
> which addresses.
> 
> Assigning variables to physical addresses is also needed for yet another
> reason: it is a common practice to assign a register to control some
> hardware. Reading/writing to such a variable is used to turn on/off some
> bits that control some hardware behaviors. This is done in Oberon System
> too, but I do not see a consistent mechanism in the language for doing so.
> (Maybe I missed it.) Something like
> 
> VAR my_register : INTEGER AT ADDRESS "address value";
> 
> These facilities are not needed for a workstation where the OS is
> maintaining hardware via system calls. This is not our case. Oberon System
> is an embedded system and it needs embedded approach to its design. I am
> speaking from experience. We need all this.
> 
> Thank you for your effort with Astrobe. I will subscribe to the forums.
> 
> Regards,
> Wojtek
> 
> 
> 
> 
> 
>>> -----Original Message-----
>>> From: skulski at pas.rochester.edu [mailto:skulski at pas.rochester.edu]
> Sent: Monday, 24 August 2015 11:56 AM
>>> To: chris at cfbsoftware.com; ETH Oberon and related systems
>>> Subject: Re: [Oberon] oberonnet of things
>>> Chris:
>>>> Instead of then loading Oberon I'll be loading a simple command-
>>> line
>>>> processor that will allow you to:
>>>> 1. Upload compiled Oberon object (*.rsc) files
>>>>  via a fast (115200 Baud) RS232 link
>>>> 2. Store them to the SD card
>>>> 3. Execute them from the SD card
>>> This is great. Here I would like to see one more bullet:
>>>  1a. After uploading, execute *.rsc directly from RAM without
>>>      storing to the SD card.
>>> This will allow to test the *.rsc without steps 2 and 3. Only tested
> programs would then go to the SD card. Development version need not to
> be stored.
>> The process of uploading actually writes it to a file on the SD card -
> it
>> doesn't yet exist in RAM. If you have an older version on the SD card
> that
>> you do not want to overwrite then you will be able to rename it first or
> give the newer version a different name while it is being tested. Note
> that when you upload the code the older version might already be loaded
>> in memory. It might have been loaded as part of the startup process or
> you
>> might have already executed it in the current session. In that case you
> would need to call System.Free to unload it from RAM before you could
> execute the new version.
>> Note also that you would have all the source code of the modules running on
>> the target - you could modify these to suit your requirements.
>>>> Eventually I hope to be able to eliminate the external SRAM and
>>> target
>>>> FPGA devices with sufficient BRAM (e.g. 128 KBytes?).
>>> Eliminating external SRAM is not a good idea. BRAM is a very
>>> expensive form of RAM. If you need lots of RAM, and BRAM is the only
> option, then you need to use a high end FPGA only because it has
> sufficient BRAM. These high end FPGA are not only expensive, but they
> also come in larger footprints than the lower end FPGAs. This
>>> translates to larger boards, more layers, higher power, and more
> difficult PCB routing.
>> You have different requirements to me so my solution is unlikely to
> correspond with yours. In my case I am using and supporting existing
> tried
>> and tested off-the-shelf boards e.g. the Pipistrello. It uses an FPGA
> device
>> which I believe has enough BRAM for what I want to do - I figured I
> might
>> as
>> well use it than just have it sitting there doing nothing. I can then
> save
>> $US 40 by not having to buy the add-on board with the SRAM.
>> In your case, if you are designing and manufacturing your own boards and
> can
>> implement the Verilog code to make it all work, you might well be able
> to
>> come up with something simpler and less expensive. If you succeed in
> producing a board which runs the RISC5 processor, and has external SRAM,
> an
>> RS232 serial link, SD card and the core-OS that you can sell for less
> than
>> $US 150 and still make a profit then I'd be very interested to hear
> about
>> it.
>>> I am very interested in your tools.
>> Great! Make sure that you have registered your details in advance if
> want
>> the initial release:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cfbsoftware.com_astrobe_RISC5Register.aspx&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=VrxvyfjV7UqfHUIWalQo6qXSxcQjehtm0MhB0jjOimw&e=
> Also, subscribe to the 'Astrobe for FPGA RISC5' forum if you want to be
> notified of progress reports:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrobe.com_forum_viewforum.php-3Ff-3D13&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=26n3xDD70CuVv-XnDlNotNjnBTZ7p_TjvkbTw-2ekO8&e=
> Regards,
>> Chris
>> Chris Burrows
>> CFB Software
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrobe.com&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=nZgCMnn9wsX6vXEMzbd8bZnbb2rZskTIe3U0w2JfeFM&e=
> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=BQICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=fm9Otz364tb5wVybokffPI-h6PUXGFBnBuYBf_vNQIk&s=YeOkAohGxOztVhjigYSmDhAS-20IEEcvC5ilElXIeRM&e=
> 
> 
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2376 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150824/de21c4bc/attachment.bin 


More information about the Oberon mailing list