Fun idea! The real time interaction with GPIO from the CLI is the most interesting thing here, I could see a general framework for that being useful for early-stage prototyping with new hardware/sensors if you included things like I2C, SPI, and UART.
The next level of this is serving the Arduino as files: https://github.com/echoline/NinePea then mounting that on your host OS. A friend wrote his own 9P server while doing embedded work on an ST Arm board by mounting the board under Linux. Files are just nodes to RPC calls that you the user decide so the file server can do anything.
Your IO points can be individual files so you can 'echo 127 >/n/arduino/pwm0' to set and reading is just as easy 'cat /n/arduino/pwm0' If you want to save all the pin states you 'tar -c /n/arduino | gzip >arduinostate.tgz' then reverse that process to write the values back.
To change pin config you can create a ctl file which you can use to control and configure things using key=value pairs, e.g. echo 'pinmode pin=3 mode=output' >/n/arduino/ctl. Errors are communicated through the file system so a failed write() will return -1 along with an errstr(2) message to your calling process.
Want a cli in addition? No problem, just make a file called e.g. con (console) and hang a REPL off it. Now open that file using a console emulator like con(1) on Plan 9: 'con -C /n/arduino/con' and type your heart away.
I have toyed with the linked library on 9front and tinkered with robotfs and the RNG demos. This is one of the cleanest ways to interact with software IMO.
No, which is a good thing. As demonstrated, things like -z are completely unnecessary. If you want to save time typing, you write a script. IMO things like -z are hacks people thought were clever because it saves THEM time typing without thinking of WHY it was not there in the first place. Pipes and shell scripts exist for a reason.
I made something similar a long time ago partly as a challenge to see what could be done with just 2 KB RAM [0]. It was possible to implement some very basic context switching between two "processes", pipes (okay, I only had a single pipe, and it only worked between certain commands), and some other things like a few built-in games (pong, snake, and a breakout-style game, naturally). I didn't go as far as adding any filesystem functionality though, and ultimately yours does feel more Unix-like overall, but it was a fun little project where you learned to always consider every single byte as precious.
>// The descriptive files (i.e., README and QUICKSTART) were written by Claude AI (with minor tweaks). Why? Because if I had done it myself, it would have ended up as a few lines of incoherent gibberish that wouldn't tell you anything.//
I would have enjoyed your lines of gibberish far more than the slop that Claude spit out.
The UNO is definitely past it's prime, but I think the exercise was more a "can I do this" challenge. The code is pretty generic C++ so the techniques should also be good for other more up to date micro's and for others to learn from.
Fun idea! The real time interaction with GPIO from the CLI is the most interesting thing here, I could see a general framework for that being useful for early-stage prototyping with new hardware/sensors if you included things like I2C, SPI, and UART.
The next level of this is serving the Arduino as files: https://github.com/echoline/NinePea then mounting that on your host OS. A friend wrote his own 9P server while doing embedded work on an ST Arm board by mounting the board under Linux. Files are just nodes to RPC calls that you the user decide so the file server can do anything.
Your IO points can be individual files so you can 'echo 127 >/n/arduino/pwm0' to set and reading is just as easy 'cat /n/arduino/pwm0' If you want to save all the pin states you 'tar -c /n/arduino | gzip >arduinostate.tgz' then reverse that process to write the values back.
To change pin config you can create a ctl file which you can use to control and configure things using key=value pairs, e.g. echo 'pinmode pin=3 mode=output' >/n/arduino/ctl. Errors are communicated through the file system so a failed write() will return -1 along with an errstr(2) message to your calling process.
Want a cli in addition? No problem, just make a file called e.g. con (console) and hang a REPL off it. Now open that file using a console emulator like con(1) on Plan 9: 'con -C /n/arduino/con' and type your heart away.
I have toyed with the linked library on 9front and tinkered with robotfs and the RNG demos. This is one of the cleanest ways to interact with software IMO.
Does `tar` under Plan 9 lack ordinary command-line arguments?
Such as:
https://xkcd.com/1168/No, which is a good thing. As demonstrated, things like -z are completely unnecessary. If you want to save time typing, you write a script. IMO things like -z are hacks people thought were clever because it saves THEM time typing without thinking of WHY it was not there in the first place. Pipes and shell scripts exist for a reason.
For that, a Forth is superior because it allows you to augment the set of commands.
Missed opportunity to call it "Unox"
Yes, but only if its rookworst flavoured.
Hehe
Creating task schedulers for microcontrollers is fun, like phenomenal fun. Everyone should have an UNO available in some form for playtime.
I made something similar a long time ago partly as a challenge to see what could be done with just 2 KB RAM [0]. It was possible to implement some very basic context switching between two "processes", pipes (okay, I only had a single pipe, and it only worked between certain commands), and some other things like a few built-in games (pong, snake, and a breakout-style game, naturally). I didn't go as far as adding any filesystem functionality though, and ultimately yours does feel more Unix-like overall, but it was a fun little project where you learned to always consider every single byte as precious.
[0] https://github.com/ls4096/avrsysh
>// The descriptive files (i.e., README and QUICKSTART) were written by Claude AI (with minor tweaks). Why? Because if I had done it myself, it would have ended up as a few lines of incoherent gibberish that wouldn't tell you anything.//
I would have enjoyed your lines of gibberish far more than the slop that Claude spit out.
But it's a cool project, thank you for sharing.
Reminds me of a good old arduino shell, Bitlash - https://github.com/billroy/bitlash/wiki/commands
Very neat, but why Arduino Uno? It's well past its prime.
The UNO is definitely past it's prime, but I think the exercise was more a "can I do this" challenge. The code is pretty generic C++ so the techniques should also be good for other more up to date micro's and for others to learn from.
Probably because that’s what they had or needed. :^)
Awesome! Next up SD card block driver and dual 328P based networking stack :)
[dead]
Mike stonebraker said the filesystem should be a database in a recent podcast with ryan peterman. Any thoughts on trying that out?
iirc BeOS (and by extension Haiku) do something similar