search

numworks / epsilon

Modern graphing calculator operating system.
https://www.numworks.com/resources/engineering/software/
1.75k stars 463 forks source link

Why is ION layer written from scratch? #839

Closed bremenpl closed 5 years ago

bremenpl commented 5 years ago

Hello there, I received the Numworks calculator for Christmas, happy me :). Noticed right after unpacking it that it doesnt support any useful features for programmers (hex/ bin formats, logical operators etc.). Since the project is open source, it is not a problem, will try to implement it myself. I started to explore the device architecture and while I could (in the end) understand why was the firmware written in C++ not C, and why was the OS written from scratch instead of basing on any available OS'es (like FreeRTOS), I cannot quite understand why is the hardware layer written from scratch. There is STDlib (obsolete) and HAL libraries available for the STM32 MCU's (other manufacturers as well).

Is there any deeper idea behind this? I would appreciate all help, just trying to understand as much as I can about this project.

boricj commented 5 years ago

The earliest commits have traces of FreeRTOS, but they were removed a very long time ago. As for why NumWorks chose to write everything from the ground up, this blog post offers some answers: https://blog.st.com/numworks-stm32f4-open-source-graphing-calculator/

bremenpl commented 5 years ago

Hello Jean, It does answer the question at some abstract level, I can get the idea/ intension. Thank you.

bremenpl commented 5 years ago

Hello again @boricj , I went a bit further into the ion code. This is only a guess, but I think that it was more likely written by software engineers than electrical engineers. Thus, the large lack of comments in the code is surprising for me. Also there is no standard (like Doxygen) there. It looks more like some kind of notes in various places. Since the lowest firmware layer is written from scratch, is there any API documentation for eventual contributors? For instance, if I wanted to add an additional peripheral on the PCB, and its interface would be I2C, this forces me to write the I2C driver from scratch as well, since HAL was not used. I am asking because I have noticed that the only indication for the device on the battery SoC (State of charge) is the battery voltage, which is a mere indicator (one has to account the battery temperature and the current integral (Coulomb counting). Also the code still resides in the MCU flash, which will be full at some point (always is). Kudos for NOR flash slot, but again, writing the driver from scratch is not a piece of cake. While I understand the makers intended to make a budget device (and I have no problem with that), I think there should be some better support for 3rd party contributors (documentation, API's). Please let me know your thought about this.

adriweb commented 5 years ago

Kudos for NOR flash slot, but again, writing the driver from scratch is not a piece of cake.

Speaking of which, interfacing with an additional memory chip has been done: see https://github.com/zardam/epsilon and https://tiplanet.org/forum/viewtopic.php?t=20557

bremenpl commented 5 years ago

Adrien, Thank you, will check this out.

boricj commented 5 years ago

Lack of documentation at the firmware level is indeed an ongoing concern (#825) as it makes for a quite steep learning curve for newcomers. I'm probably one of the most knowledgeable people about epsilon outside of the NumWorks team (at least that I know of) and yet I still can get stumped from time to time, especially with escher or whenever poincare gets a major refactoring (last time it happened, https://github.com/boricj/numworks-rpn was broken for an entire month).

That being said, once you know your way around the source tree it's not too bad as long as you have a decent understanding of C++ and a decent editor. To get back at your question, writing a new hardware driver does require writing it directly against the MCU's registers, but it's not really an issue in practice since the STM32 series of chips have really exhaustive datasheets, there are plenty of samples online and ion tends to be fairly well commented overall.

bremenpl commented 5 years ago

Hello Jean, I of course aggree with you. The point is, instead of adding one functionality, one has to write another one (the driver) prior to that. Its just unusual, thats all, since the hal libraries (with all their pitfalls) are working quite correctly.

In free time I will download the sdk, configure eclipse for it, solder the swd port (which doesnt have a part number in the schematics sheets) and chexk either the whole thing is debugable via jlink/ stlink. After that works, ill try to implement the lacking (imo) parts.

Thank you for info.

Ecco commented 5 years ago

I'm closing this issue as it's neither a bug report nor a feature request 😄