6 ms·

I have used go in an embedded application (raspberrypi) in a soft realtime manner controlling and LCD over I2C and staying under a 1.5ms looptime. The hardest p

by sly010 9y ago

I have used go in an embedded application (raspberrypi) in a soft realtime manner controlling and LCD over I2C and staying under a 1.5ms looptime. The hardest part is to undo all the things the kernel does and get access to memory so you can do memory based io, but luckily the go stdlib has everything you need to make it happen.

makapuf 9y ago
Well for this kind of things, bare metal and C are hard to beat. Is bare metal go possible?
- weberc2 9y ago
  There are projects which modify Go to allow it to run on bare metal. I don't recall any of the names though and I can't speak to their quality.
- kqr 9y ago
  Even for soft realtime I'd much sooner reach for Ada than C...
  - makapuf 9y ago
    Interesting, can you develop why ?
    - kqr 9y ago
      Sure! There are a few major reasons: - The built-in concurrency primitives are designed with real time systems in mind, freeing you from the need of constructing a cyclic executive and scheduling manually. - The tools to deal with time constraints and diagnose why deadlines were not met are very high quality. The Ravenscar profile essentially guarantees that all scheduling decisions are known statically. - Not strictly real time related, but since real time systems are often safety priority systems I'll mention it anyway: Ada makes memory management hard to get wrong. If you're interested, I think Programming Real-time with Ada 2005 over at Embedded.com[1] provides a really good overview. Many of those features are meant for safety critical hard deadline systems and are consequently overkill for bedroom experiments, but for those projects you can just take the default basics and get 98% of the way there. (If the article seems outdated in some aspects, recall that there were some further imptovements to the standard in 2012.) [1]: https://www.embedded.com/design/prototyping-and-development/4025713/Programming-real-time-with-Ada-2005 https://www.embedded.com/design/prototyping-and-development/...
jsd1982 9y ago
Nice! I have a project of my own [1] in a similar vein although not as low level as yours. Using an RPi3 with the official TFT LCD and touchscreen and rendering graphics via OpenVG. Getting about 45fps (~22ms per frame) on the Pi itself to render an 800x480 UI filled with some round-rect buttons, rotary dials, and text. Rolled my own very basic UI controls library and cross-platform host isolation library [2] to achieve this. Tested and working on darwin, win64, and raspberry pi 3. [1] https://github.com/JamesDunne/axewitcher-ovg https://github.com/JamesDunne/axewitcher-ovg [2] https://github.com/JamesDunne/golang-openvg https://github.com/JamesDunne/golang-openvg

by sly010 9y ago

makapuf 9y ago

Well for this kind of things, bare metal and C are hard to beat. Is bare metal go possible?

weberc2 9y ago
There are projects which modify Go to allow it to run on bare metal. I don't recall any of the names though and I can't speak to their quality.
kqr 9y ago
Even for soft realtime I'd much sooner reach for Ada than C...
- makapuf 9y ago
  Interesting, can you develop why ?
  - kqr 9y ago
    Sure! There are a few major reasons: - The built-in concurrency primitives are designed with real time systems in mind, freeing you from the need of constructing a cyclic executive and scheduling manually. - The tools to deal with time constraints and diagnose why deadlines were not met are very high quality. The Ravenscar profile essentially guarantees that all scheduling decisions are known statically. - Not strictly real time related, but since real time systems are often safety priority systems I'll mention it anyway: Ada makes memory management hard to get wrong. If you're interested, I think Programming Real-time with Ada 2005 over at Embedded.com[1] provides a really good overview. Many of those features are meant for safety critical hard deadline systems and are consequently overkill for bedroom experiments, but for those projects you can just take the default basics and get 98% of the way there. (If the article seems outdated in some aspects, recall that there were some further imptovements to the standard in 2012.) [1]: https://www.embedded.com/design/prototyping-and-development/4025713/Programming-real-time-with-Ada-2005 https://www.embedded.com/design/prototyping-and-development/...

jsd1982 9y ago

Nice! I have a project of my own [1] in a similar vein although not as low level as yours. Using an RPi3 with the official TFT LCD and touchscreen and rendering graphics via OpenVG. Getting about 45fps (~22ms per frame) on the Pi itself to render an 800x480 UI filled with some round-rect buttons, rotary dials, and text. Rolled my own very basic UI controls library and cross-platform host isolation library [2] to achieve this. Tested and working on darwin, win64, and raspberry pi 3. [1] https://github.com/JamesDunne/axewitcher-ovg https://github.com/JamesDunne/axewitcher-ovg [2] https://github.com/JamesDunne/golang-openvg https://github.com/JamesDunne/golang-openvg