<lispmacs>
I've found microcontroller programming and debugging to be more fun than with any other language I've worked with. Though, of course I'd have some nice things to say about Scheme
<lispmacs>
practically speaking, it seems easier to debug Forth code than Scheme, due to all the complicated transformations that go on in Scheme. In Guile Scheme there are back-traces but often they are difficult to read
<lispmacs>
* microntroller programming -> microcontroller programming with Forth
<proteusguy>
lispmacs, it is great fun, eh? :-)
Vedran has quit [Ping timeout: 268 seconds]
<siraben>
lispmacs: hm, I find the Guile backtraces pretty helpful
<siraben>
or maybe I spent most of my Forth programming debugging in my own implementation, so naturally it had poor debugging heh
<siraben>
lispmacs: oh is that your blog?
Zarutian_HTC1 has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
<lispmacs>
siraben: yes
Vedran has joined #forth
<KipIngram>
lispmacs: Embedded is a lot of fun. I've always enjoyed it. I particularly revel in having control over all of the hardware AND all of the software - the whole process of making them "cooperate" to get something done is just pleasant.
<KipIngram>
And Forth really is a GREAT embedded tinkering language.
<KipIngram>
Close to perfect.
<KipIngram>
So, I've been thinking about this numeric output stuff some more. At any given moment, if I had a number sitting on the stack, I could execute Forth to output it in some particular format. So I think the way to structure this is to let the format fields just be an alternative way of encoding a stream of normal Forth words. When I come to a format field, I just trigger a little byte code interpreter and it
<KipIngram>
will produce the same steps I might write in Forth.
<KipIngram>
Byte code was the way I did it before, but it was a little different - I had no idea of the byte code actually representing Forth in a very specific way.
<KipIngram>
In particular, there was no concept of "looping over the byte code." The byte code really just managed the acquisition of numeric parameters for the conversion, and then the last character triggered a word that did the whole job.
<KipIngram>
This time I'm going to explore having the byte code actually encode all the work, in a very explicit way, with loops and the whole shebang.
<KipIngram>
See which way turns out better.
<KipIngram>
It may turn out that doing that way makes the format field too complex.
<KipIngram>
I actully think that's fairly likely.
<KipIngram>
But I think there may be a nice "collaboration" of the previous byte code interpreter idea with my new way of using stack frames, that could make the whole process a little more elegant.
LispSporks has joined #forth
gravicappa has quit [Ping timeout: 260 seconds]
LispSporks has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
proteus-guy has quit [Ping timeout: 265 seconds]
wineroots has quit [Remote host closed the connection]
proteus-guy has joined #forth
* tabemann
has life running on his F7 board, displayed over swdcom as sixels
<KipIngram>
Cool. :-)
<tabemann>
next thing to do: display it on the screen that comes with the F7 DISCO
tech_exorcist has quit [Ping timeout: 268 seconds]
spoofer has quit [Quit: Lost terminal]
<tabemann>
I should make a modification so it can display four pixels per cell rather than one pixel
<tabemann>
because one pixel is pretty tiny
LispSporks has joined #forth
spoofer has joined #forth
proteus-guy has quit [Ping timeout: 252 seconds]
proteus-guy has joined #forth
<tabemann>
now my sixel support uses RLE
<Zarutian_HTC>
nice!
<KipIngram>
Oh... That DISCO board looks pretty sweet.
<KipIngram>
That's a nice roomy display.
<KipIngram>
Is it a touch screen?
<KipIngram>
Oh, it IS.
<KipIngram>
Very sweet.
<KipIngram>
Plenty of flash and RAM for a Forth to go to town in, too.
LispSporks has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]