[Oberon] oberonnet of things

[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=