[Oberon] oberonnet of things

[Chris Burrows]

> -----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:

http://www.cfbsoftware.com/astrobe/RISC5Register.aspx

Also, subscribe to the 'Astrobe for FPGA RISC5' forum if you want to be
notified of progress reports:

http://www.astrobe.com/forum/viewforum.php?f=13

Regards,
Chris

Chris Burrows
CFB Software
http://www.astrobe.com