But, in the meantime, a bit of catch-up:
I've had a wonderful opportunity during 2017-2018 to work with GreenArrays and their wonderful GA144 chip, on an actual real work project. There were lots of starts and stops, and not quite "full time", but we did deliver around 25 boards (and software) to the customer for "evaluation and proof-of-principle" goals. They liked what they got (delivered last December), but... they don't know if they want to continue.
I also got to do some more work with MyForth (Charley Shattuck's Arduino version) and have (for my own personal projects) pivoted back to the 8051 version (Charley & Bob Nash's work).
I ported MyForth to SiLab's (new) SleepyBee (EFM8SB2). I'll write more about that later. Perhaps a lot more, since it is one of my Copious Free Time projects.
Taking a break from intense GA144 work (in PolyFORTH and arrayFORTH) I am getting nostalgic for Forth block editors. I'm an emacs die-hard, but there is something still very focused and useful in using a block editor (well, especially when it is integrated into your development environment as deeply as PolyFORTH is on the GA144).
I may dust off my GA144 EVB and do some toolsmithing or I may dive deeper into the MyForth tooling (hmmm... can I fit a block oriented dev environment on an EFM82B2?) Recompilation is the challenge (as all of that is done in the PC under gforth). I could use the gforth block editor but MyForth is not an incremental compiler....
Still... I expect to do more Forth in the next few months (if not at work, then on my Copious Free Time projects). Stay tuned.
Just wanted to let you know someone is still out here reading your blog (when there's new content!).
ReplyDeleteI look forward to reading anything you may write about Forth but especially about MyForth. The SleepyBee looks like an interesting platform to run Forth on.
I also pop in from time to time as I'm a Forth addict :)
ReplyDeleteTalking about tethered Forths (2017),
Have you seen mecrisp-across ?
http://hightechdoc.net/mecrisp-across/_build/html/intro.html
Cheers,
Terry
The Mecrisp-across approach certainly looks interesting! I'll have to take a closer look. I've been familiar with Mecrisp proper for a few years, but have never used it for anything significant.
Delete@techman-001 The site seems to be down. :(
ReplyDelete@frogman Hopefully I will be posting some MyForth on SleepyBee code soon...
This comment has been removed by the author.
ReplyDelete@techman-001: Thanks for the pointer to Mecrisp Across. I played with Mecrisp on an MSP430 Launchpad and corresponded with Matthias Koch, Mecrisp's creator, a few years ago. He's a good guy and very helpful. But thanks to your mention, I now see he's added a lot of new stuff on his website.
ReplyDelete@toddbot: The above mentioned site has moved to:
https://mecrisp-across-folkdoc.sourceforge.io/
I look forward to seeing your MyForth on SleepyBee code!
I'm working on a DS18B20 1-wire driver and a soft-UART in MyForth, so hopefully I can post some code soon. :)
DeleteWoW, a bloody DS18B20! man I hate that thing. I spent about a week trying to make one run, then gave up in disgust. It just wants to monopolize the CPU. I think it's from a age when every factory had only ONE electric motor and shared the power via belts and pulleys ;)
DeleteI changed to a sweet little Ti LMT01 sensor and now have a system that can handle as many sensors as I want and still has plenty of time for other things.
Try not to throw up when viewing my poor Forth code design (I'm a electronics tech ok ?)
https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html#lmt01
LoL. I'm using the DS18B20 because I have a box of them lying around. The LMT01 looks like a sweet device. I'll have to order a few and see how quickly I can get it running. It would be interesting to compare Mecrisp vs MyForth. Not for competitive reasons, but out of interest in how they may differ in approach (mileage may vary -- I don't claim to be an expert MyForth programmer ;)
DeleteYour Sensor code looks well documented and clear! Thanks for pointing me to it.
I've finally updated my LMT01 temperature sensor flowchart (same url as above) and it should be a LOT clearer now. "As clear as mud", as we say in Australia ;-)
DeleteMy embedded Forth code can be pretty hard to read, especially when it's full of cmsis-svd named register configs so flowcharting is my current attempt at Forth project documentation. Flowcharting takes ages, especially after the fact when trying to work out what the hell I wrote several months ago.
I like just jumping into Forth coding, I mean that's the beauty of the Forth paradigm, "try it before you buy it" but I also love Flowcharting, so combining these two technologies in a easy and fun way is my current challenge.
Here is a weird fact:
When I used to program in assembler I flowcharted my programs first and the two technologies seemed to smoothly meld together but when I moved up to C programming I never flowcharted again, I just couldn't do it, some mental block stopped me. Perhaps C and flowcharts just don't work together,
at least in my head.
I flowchart with Graphviz Dot and it's built into my Forth development system. When I hit Make after editing the flowchart source, it's compiled into a jpeg and displayed.
That's an interesting approach to documentation. I used to use Graphviz, but hadn't thought about it in years!
DeleteI think it is hard to do "readable" (low level) Forth code on any of the modern ARMs (Cortexes). cmsis-svd is a mess. Well, I suppose it isn't cmsis-svd's problem as much as the massive number of peripherals and registers in a Cortex. My STM32L432 code is just a nightmare of names.
I wouldn't be able to use Forth on Cortex-M if not for CMSIS-SVD, the tyranny of peripherals, registers and bitfields.
DeleteI'm thinking about breaking my Forth programs into two types of files, low level config and high level application.
Putting them all in the one file seems to just make the whole thing unpleasant to read.
Then it would be a bit like C programs where all the mind numbing stuff is in header files.
But it's a work in progress, and that's half the fun.
Apologies Toddbot, I moved my unofficial doc sites to Sourceforge some time after the above post. They are now here instead:
ReplyDeleteCortex-M
https://mecrisp-stellaris-folkdoc.sourceforge.io/index.html
MSP430
https://mecrisp-across-folkdoc.sourceforge.io
Frogman, you're most welcome. Mecrisp-Across is very interesting being a Tethered Forth with MSP430 as the target and a Tiva Connected Launchpad as the Host.
I also follow the blog, when I remember to look. Fun to see my name here every once in awhile! I also get nostalgic for editing blocks. Looking forward to more stories here. I'd love to see what you did to port MyForth to that ESP chip too.
ReplyDeleteMyforth on the ESP32 would certainly be quite a feat. I have been looking at doing a Forth for the ULP co-processor, but have not made much headway (it's quite a limited processor instruction-wise).
DeleteBlocks... yes... it was so refreshing to get to use blocks again when I worked with the GA144 (last year).
Oops, guess I misread that. MyForth is on the Sleepy Bee. I'll look into that. I do miss the 8051.
ReplyDeleteThe Sleepy Bee is pretty much a re-marketed name for the C8051. The Bee series seems to whittle down the number of (8051) chip variants that need to be supported by SiLab going forward.
DeleteJames Bowman seems to be doing Bee work using MyForth for his two products: https://www.crowdsupply.com/excamera
I missed the entire Intel 8041 era mainly as I was into HC11 at the time, plus the 8041 software and support gear was darn expensive iirc.
ReplyDeleteNow it's 2019 and the 8041 is cheap, fast and multi vendor, I'm into Cortex-M0, which is cheaper, faster, 32 bit, licensed by every man and his dog with full OSS support, so I just can't see the point of a fast 8 bitter.
Apart from running Charleys cool MyForth on it that is :)
Am I missing something ? (which is entirely possible as I'm the guy who said "Nanotech ? nothing will come of that crap, and Bitcoins ? don't waste your money!")
I've done some bare metal Cortex M4 programming (mostly on a commercial medical device -- during 2016/2017). The 32 bitters certainly make the 8-bitters obsolete (performance/price) but sometimes at the cost of complexity. The STM32L476 is quite a beast. I spent a whole lot of time trying to figure out the ins and outs and couldn't just wave the problems away w/ vendor or 3rd party libraries (it was a medical device... it had to work *perfectly* and if it didn't I had to know exactly why).
DeleteNow, with an ESP32 you pretty much *need* an OS to manage its complexity. But, I still every once in a while get a nasty crash that requires me to whip out a debugger and figure out where my code crapped (as well as make sure it wasn't one of the many OSS libs I brought in).
A lot of my projects these days are fairly straightforward... so a Sleepy Bee (with its 300 page reference manual -- vs ~2000 pages for the STM32L476 (and even more for the ESP32+FreeRTOS) often fits the bill.
That said... I wouldn't want to program the Sleepy Bee without a Forth.. ;)
Yes, a big part of the appeal of an 8 bitter is the smaller manual. 2000 pages just paralyzes me and I give up. 200 is a lot, but not impossible.
ReplyDelete