The docs look really good, so I think the maker is taking the approach of creating an ecosystem of learning around the product and considering that in the cost.
Certainly you could make your own for cheaper, but then... you wouldn't need their system and could just put FlashForth on your chip yourself.
This is awesome! I haven't heard about this before, but it looks like it's pretty full featured with a great price. I'm probably going to have to pick one of these up.
I'm tempted to get that. Heavens know I've got enough microcontroller dev boards, FPGAs, and Arduino-like gizmos lying around, but the entirely "self contained" aspect of it kind of speaks to me.
Very recently I just wanted to speak some SPI to some RF IC on a breakout board. I narrowed down the quickest options to this:
* Use my UM232H (FTDI FT232H dev board) to do SPI from my Mac. Dismissed pretty quickly, since I did not feel like dealing with the drivers and FTDI library.
* Boot Linux on one of my FPGA/ARM combos and hope that the generic SPI driver also exposes itself to user space, so that I can just pipe my data on the shell using xxd -r to /dev/spi-foo or whatever. But even if the case, I had to probably at least mess with the device tree to get the I/O pins assigned (and boot Linux, and have the proper tools).
* Use the Arduino Uno that I got as a gift, but never used so far, and either use its SPI library or hope someone made a "Sketch" already that I could just paste.
In the end, the last option won out, because someone actually had made a Sketch already that I could literally just paste and run.
But that was kind of lucky. I feel like such a self-contained Forth computer that is always ready to accept some Forth (instead of having to mess with a C toolchain) could make tasks like this super quick and simple, with flexibility.
I'm a fan of #3, but with the ESP32 family rather than Arduino series. Same reason: someone has probably written an Arduino library for whatever I'm looking to drive (most are trivially ported to the ESP core)
I wish I could knuckle down and figure out #1, or, how to get Python talking through one of those FTDI USB->GPIO/I2C/SPI/UART/kitchenSink chips in a way that works in between OS reformats.
Ah well. I went to the store page on my iPhone and it just would not add it to the cart, nothing happened. Tried again on my MacBook, and it now says it's out of stock upfront. Guess when I tried to add it previously, it was already freshly out, and the Tindie shop ist just bad at telling me that. Oh well, next time.
Until this (Scamp), uLisp was the only powerful, interactive REPL for microcontrollers I’d seen. And it still runs on more platforms (including Pi Pico).
I really like micropython for the quick and dirty prototyping, you can use the REPL and send some bytes over SPI interactively. I tried it on the Raspberry Pi Pico and NodeMcu.
Currently, I'm using a Raspberry Pi Pico W with micropython to count pulses from my power meter, to log my consumption.
That is when you're supposed to reach for your Bus Pirate [1], aarr matey.
It's a USB-connected Swiss army knife of embedded electronics access-enabling fun. Really really recommended for anyone who has ever had a similar need.
It's by Dangerous Prototypes [2] but I linked to AdaFruit since it's one of the recommended retailers, their site is good, and so on. There is a legendary 4.x version "in the works", but ignore that and get the 3.x if you need to get work done.
This is so elegant. The 'Intro to Scamp Forth' video[1] on the 'what is' page is a great overview of the device and of Forth in a shade over 10 minutes.
Only 3 in stock, so I imagine this showing up on HN will rapidly reduce that to zero. Sorely tempted to buy one, but someone will get much more use out of it than I would.
Maybe i'm being too short-sighted, but at $30 per unit, this seems hopelessly overpriced for widespread use. I'd rather have a bucket full of those new 10 cent RiscV microcontrollers*, rather than one lone unit, even granting that it has more power and features.
This is a minor nit, perhaps, but for me, the sticking point with pretty much all bare-metal Forths out there is that they don't have a TCP/IP stack.
I'm theorizing that it's just too difficult to built such a stack in Forth for a hobbyist to have reasonably done. And that's a bit of a letdown of course. I really would like Forth to be able to have system libraries for networking etc., but the language philosophy is not helping here.
The good news is that by some definition, bare-bones could mean 'developed on RTOS', where the TCP stack is implemented (in C, I think) in the low level OS. 1-9-9-1.com shows that it's possible/not too hard to implement a software stack on top of sockets.
21 comments
[ 3.4 ms ] story [ 57.1 ms ] threadCertainly you could make your own for cheaper, but then... you wouldn't need their system and could just put FlashForth on your chip yourself.
Very recently I just wanted to speak some SPI to some RF IC on a breakout board. I narrowed down the quickest options to this:
* Use my UM232H (FTDI FT232H dev board) to do SPI from my Mac. Dismissed pretty quickly, since I did not feel like dealing with the drivers and FTDI library.
* Boot Linux on one of my FPGA/ARM combos and hope that the generic SPI driver also exposes itself to user space, so that I can just pipe my data on the shell using xxd -r to /dev/spi-foo or whatever. But even if the case, I had to probably at least mess with the device tree to get the I/O pins assigned (and boot Linux, and have the proper tools).
* Use the Arduino Uno that I got as a gift, but never used so far, and either use its SPI library or hope someone made a "Sketch" already that I could just paste.
In the end, the last option won out, because someone actually had made a Sketch already that I could literally just paste and run.
But that was kind of lucky. I feel like such a self-contained Forth computer that is always ready to accept some Forth (instead of having to mess with a C toolchain) could make tasks like this super quick and simple, with flexibility.
Experiences?
I wish I could knuckle down and figure out #1, or, how to get Python talking through one of those FTDI USB->GPIO/I2C/SPI/UART/kitchenSink chips in a way that works in between OS reformats.
https://www.raspberrypi.com/documentation/microcontrollers/m...
It's a USB-connected Swiss army knife of embedded electronics access-enabling fun. Really really recommended for anyone who has ever had a similar need.
It's by Dangerous Prototypes [2] but I linked to AdaFruit since it's one of the recommended retailers, their site is good, and so on. There is a legendary 4.x version "in the works", but ignore that and get the 3.x if you need to get work done.
[1]: https://www.adafruit.com/product/237
[2]: http://dangerousprototypes.com/docs/Bus_Pirate
[1] https://www.youtube.com/watch?v=1q7XsMH8dvk
* https://news.ycombinator.com/item?id=33302035
https://en.wikipedia.org/wiki/SCAMP_(boat)
Sixteen registers? I wonder what do use those for in their Forth? https://udamonic.com/uploads/1/2/1/3/121343112/scamp2-ff-uda... mentions a “p register” and an “a register”, but they must have lots of unused ones.
I'm theorizing that it's just too difficult to built such a stack in Forth for a hobbyist to have reasonably done. And that's a bit of a letdown of course. I really would like Forth to be able to have system libraries for networking etc., but the language philosophy is not helping here.
The good news is that by some definition, bare-bones could mean 'developed on RTOS', where the TCP stack is implemented (in C, I think) in the low level OS. 1-9-9-1.com shows that it's possible/not too hard to implement a software stack on top of sockets.