[Oberon] Project Oberon

[Frans-Pieter Vonck]

Hello Wojciech,

With your physics background, did you consider to take a look at the ADC 
converter of the STM32 chips?
Ivan Denisov has made a start with it a few months ago.

STM32F1ADC1.odc
https://github.com/iadenisov/O7/tree/master/Micro/Files

Currently I'm working together with some fast and deep minds of Revspace 
to reverse-engineer the Nova SDS011 particle sensor.
It has a stm32 in it and we want to develop a opensource firmware for 
it.

The following aspects we need to consider
- The physics in the sensor, Mie scattering,
- the detector circuit,
- the sampling of the measurements by the ADC,
- interpretation of the data
 From you resume I understand you are an expert in all these subjects.

Hacker- and makerpaces all over the worlds are experimenting with the 
SDS011 , but the firmware of it is not disclosed.

Obviously we first go for C to get tinker with the hardware , but it 
would be nice to give Oberon07 a try too. Also the Blackbox utility that 
you have made could be used to interpret the data.

 From what I understand now, most of the work is done by setting the 
right bits in function registers. Buffers and DMA can complicate things.


Greets,
Frans-Pieter Vonck
Skulski, Wojciech schreef op 2020-02-21 04:01:
> Chris:
> 
>   thank you for the summary. I suspect we can wrap up this discussion
> as follows. (1) We roughly agree that a good style exists and it has
> even been written up. (2) Not much will change in any variant of the
> Oberon System (except Astrobe, where there is constant progress).
> 
> I base prediction #2 on the dictionary definition of the word
> "project", which says "an individual or collaborative enterprise that
> is carefully planned and designed to achieve a particular aim".
> 
> In that sense "Project Oberon" is not a project despite its name.
> There is no "collaborative enterprise that is carefully planned".
> There is no "particular aim". In particular, improving Oberon System
> code quality is not an aim which we would all agree upon. For this
> reason it is not likely to be achieved. I hope this prediction will be
> proven wrong.
> 
> Lacking a collaborative project, there are several  individual "Oberon
> Projects". They remain disjoint and pursued in isolation. Not much is
> moving forward on a common FPGA Oberon System frontier despite seven
> years since the original release. Things have actually deteriorated
> because the FPGA boards have disappeared, what was only partly
> compensated by the Oberon System emulators. An emulator without an
> actual board has a somewhat limited function.
> 
> If there was a common FPGA Oberon System project, then how it would
> look like? (I know I am dreaming.) Here is my own individual dream
> list concerning the FPGA Oberon System, which is my main interest.
> 
> 1) A project means collaboration among people. So the first step would
> consist of forming a team willing to communicate and to collaborate on
> a common FPGA Oberon System.
> 
> 2) The team would agree on a set of achievable goals.
> 
> 3) The team would prioritize the goals and assign them to its members.
> 
> 4) Any FPGA project consists of HW, FW, and SW which need be
> co-developed in parallel. The list of tasks and responsibilities would
> follow this division.
> 
> 5) Based on the experience with the present System, augmented with
> emulators, the team would agree on the FPGA board architecture and
> features. I submit to consideration that the FPGA board would provide
> two or four MB, preferably of the synchronous type which delivers
> better performance than ASRAM. Having more than a single MB would
> allow to add color to the display, as well as develop more ambitious
> applications.
> 
> 6) Designing a new board may not be even necessary. Five RiskFive sets
> exist and these can be distributed among the team. So this step can be
> short circuited. More such sets can be manufactured by any team
> member. I can provide the design files and the BOM.
> 
> 7) Simplified and cheaper board versions can be eventually designed.
> Other boards can get adopted to the project. (Preferably no SDRAM
> which is hard to interface.)
> 
> 8) The next ingredient is the FW. The current version of RISC5.v is
> not ideal. Considerable discussion can be devoted to fixing the timing
> flaws. Team members versed in FPGA firmware could work on fixing
> RISC5.v.
> 
> 9) The RISC5top.v seems to be surprisingly resilient. The FPGA board
> designs should take this into account by providing peripherals served
> by the RISC5top. RiskFive is very close to doing this. We actually
> achieved this stage.
> 
> 10) I am strongly advocating that factoring out the memory locations
> in the code will help while working on HW and FW interfacing. I have
> already done and published this step.
> 
> 11) Ethernet can be brought back to Oberon System with the addition of
> Ethernet controller(s) to the HW. This has been done with RiskFive,
> which is Ethernet-ready. Other FPGA boards (to be developed) can add
> their own variants of Ethernet controllers.
> 
> 12) After achieving the above, the Oberon System code would be ready
> for a serious facelift. Ethernet services, printing, file sharing, or
> remote program execution are all among possible facelifts, according
> to individual interests.
> 
> 13) After achieving the above, the team could continue pushing the
> Oberon System to become a contender against MicroPython or FreeRTOS,
> for example. There would be enough momentum in the collaboration that
> such ambitious goal can become a reality.
> 
> Please note that the above list, though maybe long, is kind of
> logical. Most of these steps follow one after another in a natural
> order.
> 
> How likely is it to happen?
> 
> Wojtek
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon