I'm going to start coding up the flux gate I2C, and use the MAX SPI 8-digit display driver (from MJB ?)
depends where you got it from.
I think I postet one a while ago.
to show angles etc. Trouble for me is that my current SPIN codes used floating point and matrix-like math to do the tilt compensation.
Cheers!
it is not difficult to implement matrix style operations in Tachyon.
And floating point is really seldom needed (except for lazy programmers ;-) ... )
and can usually be replaced by a simple scaling e.g. 1.005 m == 1005 mm
and you would probably need to scale the trig functions.
There is the rom table with sin/?? I think, which also used scaled
angles. Don't remember where I saw the code.
actually there are sin/cos available already (unless you go SMALL)
here it is using the ROM tables
IFNDEF SMALL
pub COS ( angle -- cosine \ the angle is in radians scaled to ?? bits ?? )
$800 +
pub SIN ( angle -- sine \ the angle is in radians scaled to ?? bits ?? )
DUP $1000 AND SWAP \ test quadrant 3|4
DUP $800 AND IF NEGATE THEN \ test quadrant 2|4 and negate if true
$7000 OR 2* W@ \ lookup word from sin table
SWAP IF NEGATE THEN \ if quadrant 3|4, negate sample
;
: LM2 ( matrix row col -- addr ) 2* + 4* + ;
\ with row 0..1 and col 0..1
\ will give access to an long 2*2 matrix
\ defined with
4 LONGS mymatrixA
17 mymatrixA 0 0 LM2 !
mymatrixA 0 0 LM2 @ \ 17
sure does not read so nice as the code above,
but can be used in Tachyon.
and then there is .DP which prints numbers in decimal point format.
addit:
there is a way to get the nice syntax above also in Tachyon by defining the compiletime constructor as
: cell-matrix ... like above
and have a helper
: (cell-matrix) ... doing the runtime part
I know in general how to do it, but don't have a Prop here
and I expect it to need some experiments ;-)
Peter had mentioned he would at some point enable Tachyon to "call" pasm code. When that is ready you will be able to use Lonesock's et al single cog F.P. pasm routines. This will open up all the neat assembly code on the site to Tachyon users!
Peter had mentioned he would at some point enable Tachyon to "call" pasm code. When that is ready you will be able to use Lonesock's et al single cog F.P. pasm routines. This will open up all the neat assembly code on the site to Tachyon users!
Hi D.P.
yes -
I remember, you like FP as well ;-)
If there is a need the FP-COG code can be put into the Tachyon.spin file and loaded into a COG.
But in addition it will require some Tachyon support code like FP variables, printing etc.
@Peter J (or anyone knowledgeable): I'm an old Forth hand and had thought that the Prop architecture was just a poor fit for the language, full stop. Happy to be wrong!
I'm running on very little sleep atm, this thread is 78 pp long, and Peter's Dropbox has a ton of stuff in it -- so please forgive me if there's a place I might have found my answer upthread or elsewhere.
Somewhere in my sleep-depped wanderings, probably from Peter's Dropbox, I've picked up a document called TACHYONFortholdversion120903.html (actually, it's a .zip file with that at top level). It appears to include lots of nifty details. But it says "old version"...
What/where is a current or recent version, if any exists? Thanks!
Hi mm, yes used to think that the Prop (and the tools) were a poor fit for Forth too!.
I'm wondering how you got to that link as I just clicked on the dropbox link that is in my sig and without going into any of the folders I find a list of 20 files including a README. However here is a quick binary (binaries folder) for Tachyon plus Tachyon V2.7 is the kernel source although it is better to go with the binary straight up and try building from source and EXTEND etc later.
Hello!
I had the idea to connect up to 4 of my Propeller One boards with a bus board: https://hackaday.io/project/915-propeller-one
There are P16 to P25, also 10 data lines on the bus.
So I could send data to from one Propeller board to another using 8 data lines for a byte.
The picture of the bus board is on the linked page. It is simply a piece of stripe hole board with connectors on it.
And the master board can power the slaves if the jumper is set. I used 1 A DC/DC regulators on the boards so this should be possible :-).
How can I split up say a byte to it's single bits and put them on the bus? The least significant bit on P16 and then the next on P17 and so on.
Parallel buses are an awful waste of I/O on a I/O limited processor like the Propeller plus there is no support for it either in terms of strobes or interrupts etc. I have about 40 Props all bused together over RS485 which requires only 2 I/O and even though I am only transmitting at 1Mbit I can easily go much higher right up to 10Mbit. Now why would I want an awkward parallel bus?
In trying to implement a parallel bus using dumb I/O you run into inefficient (the awkward part) software handshaking as I noticed on the project page that this important issue hasn't even been addressed yet. Getting it to work well will not be easy and when you think that at 10Mbit I can transfer a byte to anyway without handshaking every microsecond then you might ask what is the advantage then of a parallel bus? However that is probably what you need to do first, is ask the question and why do you need a bus and what is it going to be used for. For sure it won't be used to transfer Gigabytes of information so what then? Is it just the occasional command and sensor data and motor positioning etc?
I have a hard time exhausting a single Propeller chip and rarely would I have any bussed together but the times I have they have been serial and this is how they were used:
- Main Prop + I/O solenoid timing Prop + 2x 6-channel discriminators
- Main Prop + VGA/keyboard Prop
- Main Prop + dedicated Networking
- my current Project with a P2 + 44 slaved modules over RS-485.
P.S. Those existing parallel lines can be used as multiple serial lines over a short distance.
I am slowly building up a Glossary of Tachyon words, their stack usage and a one line comment for each word. It's a work in progress of course and I have covered much of the kernel, but I still need to go on to EXTEND and the filesystem words.
LOOPING
DO and LOOP use a separate loop stack to hold the parameters and a branch stack to hold the looping address for very fast looping.
CODE 0C h....... DO ( to from -- ) Push from as index and to as limit onto loop stack and save next IP onto branch stack for LOOP
CODE D0 h....2x. ADO ( from cnt -- ) Like DO would except it uses friendlier parameters. ( BOUNDS DO )
CODE 0C h....... LOOP ( -- ) Increment the loop index I and exit loop if index => limit or else loop back using saved DO branch
CODE 0C h....... +LOOP ( cnt -- ) Add cnt to loop index and exit loop if index => limit
CODE 0C h....... FOR ( cnt -- ) Push cnt onto loop stack and save next IP onto branch stack for NEXT
CODE 0C h....... NEXT ( -- ) Decrement loop IX and exit loop if IX = 0 or else branch using saved FOR branch address
CODE 0C h....... I ( -- DOindex ) Push DO index onto data stack
YCALL 55 h.....x. IX ( -- FORindex ) Push FOR index onto data stack
YCALL 54 h.....x. K ( -- DOindex2 ) Push second level DO index
YCALL 53 h.....x. J ( -- DOindex3 ) Push third level DO index
YCALL 57 h.....x. UNLOOP ( -- ) Discard current DO index and limit and branch address etc….. (more detail req)
YCALL 56 h.....x. LEAVE ( -- ) Set the index to limit-1 so that it will LEAVE the loop when it encounters LOOP
CODE 0C h....... BRANCH> Pop the branchstack and discard - used if a forced exit from a DO LOOP or FOR NEXT
@Peter - wow you have been diligent - 183 changes ... thanks, that is a great document, not only for beginners, but also just to be reminded of the wealth of available power words.
Yes the Glossary is fantastic, It would be nice to link each word to a code snippet for context. I will add what I can to the "Glossary". Beginners will find code snippets and use cases very helpful, uh so will I.
Yes the Glossary is fantastic, It would be nice to link each word to a code snippet for context. I will add what I can to the "Glossary". Beginners will find code snippets and use cases very helpful, uh so will I.
That's the plan to keep it simple and uncluttered and insert links where appropriate for further information and code examples etc. Even I have to scratch my head though while I fill in all this detail, and I still have a lot left to do too
Simplified the glossary format with just the basics. Now getting into some of the high level words like this:
SPIWRB ( byte -- byte ) C Send byte over SPI lines as defined in COGREGs and return with same byte
SPIWR16 ( long -- long1 ) C Send msb 16-bits (b31..b16) over SPI and return with long rotated left by 16 bits
SPIWR ( long -- long1 ) C Send 8 MSBs of long over SPI and return with left rotated long1 ( $12345678 -> $34567812 )
SPIRD ( long -- long1 ) C Read SPI data and left rotate into long with long1 as result ( $12345678 -> $345678NN ) - 2.8us
RGBLEDS ( buffer cnt pin – ) H Output buffer for cnt to pin to drive WS2812 RBG LED string
DHT ( pin -- rh temp ) H Read DHT22 type humidity/temperature sensor on this pin and use last reading if too soon
PING ( trig echo -- us ) H Trigger PING sensor and listen on echo pin and return with microseconds value
DISTANCE ( trig echo -- distance.mm ) H PING sensor and return with reading in millimetres
SEROUT ( dataByte pin -- ) H Transmit serial data byte to pin at rate set with SERBAUD
There are lots of goodies built into Tachyon that I tend to forget what they are but I will try and group them to make them easier to find. There will be links to examples as well.
Fantastic, I really would like to see more "language extension examples", this part of FORTH is the most subtle and elusive part of the language for me. Serious thought compression, dragon be here.
Is there a serial version of your Propeller Hardware Explorer? I see a link to a VGA version in your signature.
Obviously you haven't tried that then The serial console is always active and the VGA version simply incorporates the driver and high level words for VGA but doesn't use this as a default although you can easily set it to do so.
Thanks. I finally fixed a bug in my loader and this is now working on the Parallax Wi-Fi module. I'm looking forward to playing with it with the help of your new Tachyon glossary.
Some time ago MJB wrote a driver for the MAX7219 chip to drive an 8-digit LED display but I found the driver too large and cumbersome (sorry MJB) and although I don't have a display I decided to redo the driver. Now it is less than 70 lines of source and uses only 353 bytes of code memory along with 113 bytes of dictionary. Mostly though the driver is a standard streaming character output so it's simply a matter of redirecting the Tachyon output to it instead of the terminal or perhaps VGA etc. The driver is also auto-initializing as well, just talk to it as you would any terminal. The source is available in the Tachyon Dropbox in the extras folder.
Usage example (plus buffer peek):
MAX7219 PRINT" HELP" 1234 . CON ok
ledbuf 10 DUMP
0000_4560: 28 0C 0B 0D 0E 01 02 03 04 00 29 73 0B A0 11 A0 (.........)s.... ok
MAX7219 ^L EMIT CON ok
ledbuf 10 DUMP
0000_4560: 20 20 20 20 20 20 20 20 20 00 29 73 0B A0 11 A0 .)s.... ok
max7219 PRINT" 12.34" CON ok
ledbuf 10 DUMP
0000_4560: 24 01 82 03 04 20 20 20 20 00 29 73 0B A0 11 A0 $.... .)s.... ok
TACHYON [~
FORGET MAX7219.fth
pub MAX7219.fth PRINT" MAX7219/7221 8-digit LED Driver by PBJ 160407-0000 " ;
DECIMAL
{
PBJ - Simplified version of MJB's original Tachyon code also makes it a totally streaming character output device
Just select MAX7219 as the output device and driver handles special controls etc
}
&14.12.15.13 == ledpins --- setup hardware pinout as &ce.xx.mosi.sck (default=breadboard)
0 == ledce --- dummy chip enable pin gets set automatically
10 BYTES ledbuf --- character write position plus 8 characters
pub DIGITS ( nDIGITS - ) 1- 11
pub LED! ( val reg -- ) SPIWRB DROP SPIWRB DROP ledce HIGH ;
pub REFRESH 9 1 DO ledbuf I + C@ I LED! LOOP ;
pub ASC>SEG
"0" "9" SWITCH>< IF SWITCH@ $30 - BREAK
"-" CASE $0A BREAK
"E" CASE $0B BREAK
"H" CASE $0C BREAK
"L" CASE $0D BREAK
"P" CASE $0E BREAK
$0F --- default is SPACE/BLANC/EMPTY/OFF
;
pub (LED) ( char -- )
SWITCH --- use the ASCII value as a switch in the case statement
^M CASE ledbuf C~ BREAK --- on CR reset display pos
^J CASE BREAK --- ignore LF
^L CASE ledbuf 9 BL FILL REFRESH BREAK --- reset and blank
^N CASE 0 12 LED! BREAK --- enable display (unblank)
^O CASE 1 12 LED! BREAK
"." CASE $80 ledbuf C@ 1- 7 AND ledbuf 1+ + C+! BREAK --- add in DP to previous character (or first)
SWITCH@ BL < IF SWITCH@ >N 10 LED! EXIT THEN --- set 4-bit brightness $10..$1F
ASC>SEG ledbuf C@ 7 AND ledbuf 1+ + C! --- otherwise treat it as a character
ledbuf C++ --- increment position
REFRESH
;
pub >LED ( char -- )
ledbuf @ 0= --- initialise the display if necessary (all zeros on startup)
IF
ledpins SPIPINS --- setup masks used by SPI instructions
@SPISCK 3 + COGREG@ >| ' ledce 1+ ! --- automatically setup chip enable pin constant
ledce HIGH --- ensure chip enable is and output and set to off
@SPISCK COGREG@ OUTCLR --- MAX7219 likes to work with clock low to high
8 DIGITS --- scan limit
$FF 9 LED! --- full decode
0 15 LED! --- dont forget to reset TEST mode
$18 (LED) --- SET BRIGHTNESS
^L (LED) --- clear the display
^N (LED) --- enable display
THEN
(LED)
;
--- Switch Tachyon character output to the MAX7219 LED display
--- i.e. MAX7219 CR PRINT" HELP" 123 PRINT
pub MAX7219 ' >LED uemit W! ;
]~ END
BACKUP
Some time ago MJB wrote a driver for the MAX7219 chip to drive an 8-digit LED display but I found the driver too large and cumbersome (sorry MJB) and although I don't have a display I decided to redo the driver. Now it is less than 70 lines of source and uses only 353 bytes of code memory along with 113 bytes of dictionary.
Sure - the master of Tachyon can improve my driver :-) - thanks
I can still learn something from you ;-)
It was just a bottom up, step by step approach and I was aware, that I could inline a lot in the end to save many definitions.
And I also used parts of my driver for 8*8 matrix displays, which use the same MAX7219 chip.
Recently I had a visitor who just wanted to start with Arduino and I showed him a little Propeller + Tachyon. He was so excited, that I made a Prop breadboard setup for him to play immediately and he ordered some Propellers.
Now he got one of those cheap 240*320 QVGA displays with ILI9341 and touch controller XPT2046 and asks how to do this with Tachyon.
So I had a look and found Peter's SSD2119QVGA.fth which looks close and I think I could adapt.
That's a good side about Arduino - you can find drivers just about for anything ...
I tell him next time better check if there is a Tachyon driver, before ordering new HW ;-)
Sure - the master of Tachyon can improve my driver :-) - thanks
I can still learn something from you ;-)
It was just a bottom up, step by step approach and I was aware, that I could inline a lot in the end to save many definitions.
And I also used parts of my driver for 8*8 matrix displays, which use the same MAX7219 chip.
Recently I had a visitor who just wanted to start with Arduino and I showed him a little Propeller + Tachyon. He was so excited, that I made a Prop breadboard setup for him to play immediately and he ordered some Propellers.
Now he got one of those cheap 240*320 QVGA displays with ILI9341 and touch controller XPT2046 and asks how to do this with Tachyon.
So I had a look and found Peter's SSD2119QVGA.fth which looks close and I think I could adapt.
That's a good side about Arduino - you can find drivers just about for anything ...
I tell him next time better check if there is a Tachyon driver, before ordering new HW ;-)
@MJB: In your original driver it was the sheer number of methods and all the special routines even for printing numbers that ""offended my sensibilities, I just thought at the time "this is not the way to code". Many Spin objects I see were created with lots of methods and hooks which was kind of like having dedicated wires for each function. In hardware this leads to unnecessary complexity and limits the flexibility of the circuit, cumbersome in other words. So I always try to make my device drivers a "device", as if it were remote, one that doesn't have dozens of wires running back but simply relies on a data/command channel, much like a serial terminal.
I'm mainly a hardware guy so the software has to make the hardware work or more correctly they should work in unison. While I can probe and stimulate digital logic the same is not true with binary blob firmware where the emphasis is on the PC and the tools. My first exposure to Forth totally inspired me, for the first time I could see that I could interact with the "system", the whole synergistic union of hardware and software in a friendly way. I had also used Basic but peeking and poking and goto'ing in decimal was not friendly at all. Outside of that the various compilers were so PC centric, I had to know about the current version of the compiler, its quirks, and about its libraries, although most of the time this stuff was dark and mysterious. When I did manage to get it to compile and load it didn't help unless it worked perfectly, there was no way to test, debug, trim, improve anything on the board, only scratch your head and wonder what the compiler was actually generating.
So with the Propeller my Tachyon approach is not PC centric, but my focus is on the hardware itself, the Propeller chip in its raw glory and being able to interact with that chip in a similar way I would with digital logic. This leads to bottom up coding which despite all the bad things said about it is actually a good thing if done interactively with a top down vision. When I design a new xyz board that has new special sensors and new displays etc I know I can tickle these interactively initially to make sure I'm on the right path. With a compiler the usual approach people take is "where's the driver?". In contrast I am totally empowered and have great freedom of expression with Tachyon and receive instant feedback (and fun) from booting up a brand new board.
So @MJB just as when you had the Arduino visitor and you showed him the Prop+Tachyon and he was so excited that he could "play" immediately, that is exactly the kind of thing that I try to make happen when I make Tachyon totally open and even make Explorer images. You even wrote a lot of the 1-wire stuff that searches every pin and lists any devices it finds. I kind of expect that people would be eager to try Tachyon, to load'n'go as it were, but I am constantly amazed at the number that hold off from trying it. I know that they are missing out big time. Perhaps I have made it too easy, or perhaps it is because they have preconceptions about "Forth", even on the Prop itself and are wary, but why? Nothing ventured, nothing gained, and it is so easy to get started, I even have a long Introduction to Tachyon Forth and step by step examples. But that is not much different as is the case with "oldies" who try to use a new piece of technology and give up in disgust within seconds because it doesn't work the way they are used to. Even kids had to play and play before they learnt anything but then again kids don't have preconceptions (and pride).
Sure - the master of Tachyon can improve my driver :-) - thanks
I can still learn something from you ;-)
It was just a bottom up, step by step approach and I was aware, that I could inline a lot in the end to save many definitions.
And I also used parts of my driver for 8*8 matrix displays, which use the same MAX7219 chip.
Recently I had a visitor who just wanted to start with Arduino and I showed him a little Propeller + Tachyon. He was so excited, that I made a Prop breadboard setup for him to play immediately and he ordered some Propellers.
Now he got one of those cheap 240*320 QVGA displays with ILI9341 and touch controller XPT2046 and asks how to do this with Tachyon.
So I had a look and found Peter's SSD2119QVGA.fth which looks close and I think I could adapt.
That's a good side about Arduino - you can find drivers just about for anything ...
I tell him next time better check if there is a Tachyon driver, before ordering new HW ;-)
@MJB: In your original driver it was the sheer number of methods and all the special routines even for printing numbers that ""offended my sensibilities, I just thought at the time "this is not the way to code". Many Spin objects I see were created with lots of methods and hooks which was kind of like having dedicated wires for each function. In hardware this leads to unnecessary complexity and limits the flexibility of the circuit, cumbersome in other words. So I always try to make my device drivers a "device", as if it were remote, one that doesn't have dozens of wires running back but simply relies on a data/command channel, much like a serial terminal.
I'm mainly a hardware guy so the software has to make the hardware work or more correctly they should work in unison. While I can probe and stimulate digital logic the same is not true with binary blob firmware where the emphasis is on the PC and the tools. My first exposure to Forth totally inspired me, for the first time I could see that I could interact with the "system", the whole synergistic union of hardware and software in a friendly way. I had also used Basic but peeking and poking and goto'ing in decimal was not friendly at all. Outside of that the various compilers were so PC centric, I had to know about the current version of the compiler, its quirks, and about its libraries, although most of the time this stuff was dark and mysterious. When I did manage to get it to compile and load it didn't help unless it worked perfectly, there was no way to test, debug, trim, improve anything on the board, only scratch your head and wonder what the compiler was actually generating.
So with the Propeller my Tachyon approach is not PC centric, but my focus is on the hardware itself, the Propeller chip in its raw glory and being able to interact with that chip in a similar way I would with digital logic. This leads to bottom up coding which despite all the bad things said about it is actually a good thing if done interactively with a top down vision. When I design a new xyz board that has new special sensors and new displays etc I know I can tickle these interactively initially to make sure I'm on the right path. With a compiler the usual approach people take is "where's the driver?". In contrast I am totally empowered and have great freedom of expression with Tachyon and receive instant feedback (and fun) from booting up a brand new board.
So @MJB just as when you had the Arduino visitor and you showed him the Prop+Tachyon and he was so excited that he could "play" immediately, that is exactly the kind of thing that I try to make happen when I make Tachyon totally open and even make Explorer images. You even wrote a lot of the 1-wire stuff that searches every pin and lists any devices it finds. I kind of expect that people would be eager to try Tachyon, to load'n'go as it were, but I am constantly amazed at the number that hold off from trying it. I know that they are missing out big time. Perhaps I have made it too easy, or perhaps it is because they have preconceptions about "Forth", even on the Prop itself and are wary, but why? Nothing ventured, nothing gained, and it is so easy to get started, I even have a long Introduction to Tachyon Forth and step by step examples. But that is not much different as with the case with "oldies" who try to use a new piece of technology and give up in disgust within seconds because it doesn't work the way they are used to. Even kids had to play and play before they learnt anything but then again kids don't have preconceptions (and pride).
Hi @Peter Jakacki
I just had discovered the Propeller when you started with Tachyon.
So I was with you from the beginning and liked it because it has many of the benefits I was used from huge LISP systems.
Full source code, interactive, introspection, little syntax and huge expressive power ...
And this taylored for the Propeller.
Reading the Tachyon kernel was my introduction into PASM ... great.
I just have way too little time to do a lot of coding.
thanks for sharing your development process and it's results.
Markus
I just had discovered the Propeller when you started with Tachyon.
So I was with you from the beginning and liked it because it has many of the benefits I was used from huge LISP systems.
Full source code, interactive, introspection, little syntax and huge expressive power ...
And this taylored for the Propeller.
Reading the Tachyon kernel was my introduction into PASM ... great.
I just have way too little time to do a lot of coding.
thanks for sharing your development process and it's results.
Markus
That's what's been so much fun too, being able to share and get feedback and experiences. You've been a great contributor to Tachyon even if you unfortunately have "way too little time to do a lot of coding" I know it would have been a lot more fun teaching this as a regular hands-on workshop, everyone coming up with great and wonderful things by the end of each session. But the thing is that Forth allows all kinds of approaches to coding as nobody is locked into syntax or libraries etc. This might mean the code ends up more cumbersome and less efficient than it could be (or that I think it could be ), but the important thing is that you can get it to work and code with the way you think. Code can always be improved later on. Functionality and fun first.
I just had discovered the Propeller when you started with Tachyon.
So I was with you from the beginning and liked it because it has many of the benefits I was used from huge LISP systems.
Full source code, interactive, introspection, little syntax and huge expressive power ...
And this taylored for the Propeller.
Reading the Tachyon kernel was my introduction into PASM ... great.
I just have way too little time to do a lot of coding.
thanks for sharing your development process and it's results.
Markus
That's what's been so much fun too, being able to share and get feedback and experiences. You've been a great contributor to Tachyon even if you unfortunately have "way too little time to do a lot of coding" I know it would have been a lot more fun teaching this as a regular hands-on workshop, everyone coming up with great and wonderful things by the end of each session. But the thing is that Forth allows all kinds of approaches to coding as nobody is locked into syntax or libraries etc. This might mean the code ends up more cumbersome and less efficient than it could be (or that I think it could be ), but the important thing is that you can get it to work and code with the way you think. Code can always be improved later on. Functionality and fun first.
actually in this case I had some problems with the HW (I thought ;-) )
and made every tiny SetThisParameter a separate function,
to verify everything step by step - which finally worked.
And then I did not do the (fully agree with you) final step in consolidating it before publishing it.
Actually I like your coding style ;-)
but it is sometimes a bit concise to start with.
so again
Did anybody work with a touch controller like
touch controller XPT2046.
I was thinking of polling it inside the timer cog every ms and put events in a queue to be processed inside keypoll
This is a very simple chip to interface, something that we just play with in Forth and get up and running in no time. Page 23 of the manual shows the SPI sequence required, send a control bytes, read back 16-bits. So in Forth I would setup the pins, interactively write a control byte and read two bytes or 16-bits back before releasing the CE. When it comes back the way I expect, I then build on that. Thirty minutes later we have a fully functional "driver". That's much less time and a lot more rewarding than searching for a "driver"!
The high level approach I would just query it as required since we wouldn't expect to do anything fancy with this underwhelming and seemingly obsolete chip (why?).
so again
Did anybody work with a touch controller like
touch controller XPT2046.
I was thinking of polling it inside the timer cog every ms and put events in a queue to be processed inside keypoll
This is a very simple chip to interface, something that we just play with in Forth and get up and running in no time. Page 23 of the manual shows the SPI sequence required, send a control bytes, read back 16-bits. So in Forth I would setup the pins, interactively write a control byte and read two bytes or 16-bits back before releasing the CE. When it comes back the way I expect, I then build on that. Thirty minutes later we have a fully functional "driver". That's much less time and a lot more rewarding than searching for a "driver"!
The high level approach I would just query it as required since we wouldn't expect to do anything fancy with this underwhelming and seemingly obsolete chip (why?).
pub ASC>SEG
SWITCH \ this line is missing I think - no HW to try atm
"0" "9" SWITCH>< IF SWITCH@ $30 - BREAK
"-" CASE $0A BREAK
"E" CASE $0B BREAK
"H" CASE $0C BREAK
"L" CASE $0D BREAK
"P" CASE $0E BREAK
$0F --- default is SPACE/BLANC/EMPTY/OFF
;
pub ASC>SEG
SWITCH \ this line is missing I think - no HW to try atm
"0" "9" SWITCH>< IF SWITCH@ $30 - BREAK
"-" CASE $0A BREAK
"E" CASE $0B BREAK
"H" CASE $0C BREAK
"L" CASE $0D BREAK
"P" CASE $0E BREAK
$0F --- default is SPACE/BLANC/EMPTY/OFF
;
No bug, just a redundancy since we would have to do a SWITCH@ ASC>SEG and then another SWITCH again, all redundant, just use the same SWITCH. Even without the hardware I was able to confirm the driver works by examining the display buffer as the SPI signals are straightforward and don't need to be taken into account. The only thing that might need a little tweak is the order of the digits depending upon the actual hardware, left to right or right to left, but that would only be something like a "7 XOR" in the right place in REFRESH. In fact the whole driver could have used a buffer for all the 7219 registers that gets updated when we run REFRESH since it takes less than 200us to update the whole chip.
pub ASC>SEG
SWITCH \ this line is missing I think - no HW to try atm
"0" "9" SWITCH>< IF SWITCH@ $30 - BREAK
"-" CASE $0A BREAK
"E" CASE $0B BREAK
"H" CASE $0C BREAK
"L" CASE $0D BREAK
"P" CASE $0E BREAK
$0F --- default is SPACE/BLANC/EMPTY/OFF
;
No bug, just a redundancy since we would have to do a SWITCH@ ASC>SEG and then another SWITCH again, all redundant, just use the same SWITCH. Even without the hardware I was able to confirm the driver works by examining the display buffer as the SPI signals are straightforward and don't need to be taken into account. The only thing that might need a little tweak is the order of the digits depending upon the actual hardware, left to right or right to left, but that would only be something like a "7 XOR" in the right place in REFRESH. In fact the whole driver could have used a buffer for all the 7219 registers that gets updated when we run REFRESH since it takes less than 200us to update the whole chip.
what a trick !!! using the switch from a previous / outer word ...
I was just thinking about that MAX7219 chip and the silly limit on the encoded characters H E L P that it displayed and I smacked my head when I realized that it does allow unencoded 7-segment data. So all I need is a table and just modify the method and presto! Scouring around I couldn't find any complete or handy ASCII to 7-segment conversion table so I just encoded the segments in my head in hex, all of them, I didn't leave any out, even if they might look a little strange. Lower case is just the same as upper case and all the symbols are there too.
A quick test reveals it works, maybe somebody would like to try it on a real display and simply switch Tachyon output to it with a simple "MAX7219".
This is my quick test:
MAX7219 PRINT" HELLO123" CON ok
ledbuf 10 DUMP
0000_4560: 28 76 79 38 38 5C 06 59 4F 00 29 73 0B A0 11 A0 (vy88\.YO.)s.... ok
Thinking about it I might even get it to scroll horizontally when a line gets more than 8 characters. Anyway this is it for now.
TACHYON [~
FORGET MAX7219.fth
pub MAX7219.fth PRINT" MAX7219/7221 8-digit LED Driver by PBJ 160407-0000 " ;
DECIMAL
{
PBJ - Simplified version of MJB's original Tachyon code also makes it a totally streaming character output device
Just select MAX7219 as the output device and driver handles special controls etc
}
&14.12.15.13 == ledpins --- setup hardware pinout as &ce.xx.mosi.sck (default=breadboard)
0 == ledce --- dummy chip enable pin gets set automatically
10 BYTES ledbuf --- character write position plus 8 characters
pub DIGITS ( nDIGITS - ) 1- 11
pub LED! ( val reg -- ) SPIWRB DROP SPIWRB DROP ledce HIGH ;
pub REFRESH 9 1 DO ledbuf I + C@ I LED! LOOP ;
--- !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
TABLE 7segs
$00 | $86 | $42 | $49 | $2D | $52 | $5B | $02 | --- $20..$27 !"#$%&'
$39 | $0F | $C9 | $46 | $04 | $40 | $80 | $52 | --- $28..$2F ()*+,-./
$3F | $06 | $59 | $4F | $66 | $6D | $7D | $07 | --- $30..$37 01234567
$7F | $6F | $41 | $45 | $70 | $48 | $46 | $DB | --- $38..$3F 89:;<=>?
$7B | $77 | $7C | $39 | $5E | $79 | $71 | $3D | --- $40..$47 @ABCDEFG
$76 | $30 | $0E | $72 | $38 | $23 | $54 | $5C | --- $48..$4F HIJKLMNO
$73 | $79 | $50 | $6D | $46 | $3E | $62 | $1C | --- $50..$57 PQRSTUVW
$52 | $6E | $59 | $39 | $64 | $0F | $01 | $08 | --- $58..$5F XYZ[\]^_
$00 | $77 | $7C | $39 | $5E | $79 | $71 | $3D | --- $60..$67 `abcdefg
$76 | $30 | $0E | $72 | $38 | $23 | $54 | $5C | --- $68..$6F hijklmno
$73 | $79 | $50 | $6D | $46 | $3E | $62 | $1C | --- $70..$77 pqrstuvw
$52 | $6E | $59 | $39 | $36 | $0F | $52 | $00 | --- $78..$7F xyz{|}~
pub (LED) ( char -- )
SWITCH --- use the ASCII value as a switch in the case statement
^M CASE ledbuf C~ BREAK --- on CR reset display pos
^J CASE BREAK --- ignore LF
^L CASE ledbuf 9 BL FILL REFRESH BREAK --- reset and blank
^N CASE 0 12 LED! BREAK --- enable display (unblank)
^O CASE 1 12 LED! BREAK
"." CASE $80 ledbuf C@ 1- 7 AND ledbuf 1+ + C+! BREAK --- add in DP to previous character (or first)
SWITCH@ BL < IF SWITCH@ >N 10 LED! EXIT THEN --- set 4-bit brightness $10..$1F
SWITCH@ BL - 7segs + C@ ledbuf C@ 7 AND ledbuf 1+ + C! --- otherwise treat it as a character
ledbuf C++ --- increment position
REFRESH
;
pub >LED ( char -- )
ledbuf @ 0= --- initialise the display if necessary (all zeros on startup)
IF
ledpins SPIPINS --- setup masks used by SPI instructions
@SPISCK 3 + COGREG@ >| ' ledce 1+ ! --- automatically setup chip enable pin constant
ledce HIGH --- ensure chip enable is and output and set to off
@SPISCK COGREG@ OUTCLR --- MAX7219 likes to work with clock low to high
8 DIGITS --- scan limit
0 9 LED! --- no decode, use table
0 15 LED! --- dont forget to reset TEST mode
$18 (LED) --- SET BRIGHTNESS
^L (LED) --- clear the display
^N (LED) --- enable display
THEN
(LED)
;
--- Switch Tachyon character output to the MAX7219 LED display
--- i.e. MAX7219 CR PRINT" HELP" 123 PRINT
pub MAX7219 ' >LED uemit W! ;
]~ END
BACKUP
Comments
I think I postet one a while ago. it is not difficult to implement matrix style operations in Tachyon.
And floating point is really seldom needed (except for lazy programmers ;-) ... )
and can usually be replaced by a simple scaling e.g. 1.005 m == 1005 mm
and you would probably need to scale the trig functions.
There is the rom table with sin/?? I think, which also used scaled
angles. Don't remember where I saw the code.
actually there are sin/cos available already (unless you go SMALL)
here it is using the ROM tables
IFNDEF SMALL pub COS ( angle -- cosine \ the angle is in radians scaled to ?? bits ?? ) $800 + pub SIN ( angle -- sine \ the angle is in radians scaled to ?? bits ?? ) DUP $1000 AND SWAP \ test quadrant 3|4 DUP $800 AND IF NEGATE THEN \ test quadrant 2|4 and negate if true $7000 OR 2* W@ \ lookup word from sin table SWAP IF NEGATE THEN \ if quadrant 3|4, negate sample ;if you post your spin code ... ;-) ...
unfortunately there is no CREATE DOES> in Tachyon so from here
does not work
but a simple
sure does not read so nice as the code above,
but can be used in Tachyon.
and then there is .DP which prints numbers in decimal point format.
addit:
there is a way to get the nice syntax above also in Tachyon by defining the compiletime constructor as
: cell-matrix ... like above
and have a helper
: (cell-matrix) ... doing the runtime part
I know in general how to do it, but don't have a Prop here
and I expect it to need some experiments ;-)
Hi D.P.
yes -
I remember, you like FP as well ;-)
If there is a need the FP-COG code can be put into the Tachyon.spin file and loaded into a COG.
But in addition it will require some Tachyon support code like FP variables, printing etc.
I'm running on very little sleep atm, this thread is 78 pp long, and Peter's Dropbox has a ton of stuff in it -- so please forgive me if there's a place I might have found my answer upthread or elsewhere.
Somewhere in my sleep-depped wanderings, probably from Peter's Dropbox, I've picked up a document called TACHYONFortholdversion120903.html (actually, it's a .zip file with that at top level). It appears to include lots of nifty details. But it says "old version"...
What/where is a current or recent version, if any exists? Thanks!
I'm wondering how you got to that link as I just clicked on the dropbox link that is in my sig and without going into any of the folders I find a list of 20 files including a README. However here is a quick binary (binaries folder) for Tachyon plus Tachyon V2.7 is the kernel source although it is better to go with the binary straight up and try building from source and EXTEND etc later.
I had the idea to connect up to 4 of my Propeller One boards with a bus board: https://hackaday.io/project/915-propeller-one
There are P16 to P25, also 10 data lines on the bus.
So I could send data to from one Propeller board to another using 8 data lines for a byte.
The picture of the bus board is on the linked page. It is simply a piece of stripe hole board with connectors on it.
And the master board can power the slaves if the jumper is set. I used 1 A DC/DC regulators on the boards so this should be possible :-).
How can I split up say a byte to it's single bits and put them on the bus? The least significant bit on P16 and then the next on P17 and so on.
In trying to implement a parallel bus using dumb I/O you run into inefficient (the awkward part) software handshaking as I noticed on the project page that this important issue hasn't even been addressed yet. Getting it to work well will not be easy and when you think that at 10Mbit I can transfer a byte to anyway without handshaking every microsecond then you might ask what is the advantage then of a parallel bus? However that is probably what you need to do first, is ask the question and why do you need a bus and what is it going to be used for. For sure it won't be used to transfer Gigabytes of information so what then? Is it just the occasional command and sensor data and motor positioning etc?
I have a hard time exhausting a single Propeller chip and rarely would I have any bussed together but the times I have they have been serial and this is how they were used:
- Main Prop + I/O solenoid timing Prop + 2x 6-channel discriminators
- Main Prop + VGA/keyboard Prop
- Main Prop + dedicated Networking
- my current Project with a P2 + 44 slaved modules over RS-485.
P.S. Those existing parallel lines can be used as multiple serial lines over a short distance.
The Google document link has been changed to comment only but if someone wants to chip in then please request via the document page.
Here is a sample from that page:
That's the plan to keep it simple and uncluttered and insert links where appropriate for further information and code examples etc. Even I have to scratch my head though while I fill in all this detail, and I still have a lot left to do too
There are lots of goodies built into Tachyon that I tend to forget what they are but I will try and group them to make them easier to find. There will be links to examples as well.
84*48 nokia lcd 5110
160*128 based on ST7735
320*240 based on ILI9341
Peter has a driver for a 128*64 based on ST7920
that might be possible to adapt to the two non Nokia displays.
The 320*240 is even available with touch controller.
Thanks. I finally fixed a bug in my loader and this is now working on the Parallax Wi-Fi module. I'm looking forward to playing with it with the help of your new Tachyon glossary.
Usage example (plus buffer peek):
TACHYON [~ FORGET MAX7219.fth pub MAX7219.fth PRINT" MAX7219/7221 8-digit LED Driver by PBJ 160407-0000 " ; DECIMAL { PBJ - Simplified version of MJB's original Tachyon code also makes it a totally streaming character output device Just select MAX7219 as the output device and driver handles special controls etc } &14.12.15.13 == ledpins --- setup hardware pinout as &ce.xx.mosi.sck (default=breadboard) 0 == ledce --- dummy chip enable pin gets set automatically 10 BYTES ledbuf --- character write position plus 8 characters pub DIGITS ( nDIGITS - ) 1- 11 pub LED! ( val reg -- ) SPIWRB DROP SPIWRB DROP ledce HIGH ; pub REFRESH 9 1 DO ledbuf I + C@ I LED! LOOP ; pub ASC>SEG "0" "9" SWITCH>< IF SWITCH@ $30 - BREAK "-" CASE $0A BREAK "E" CASE $0B BREAK "H" CASE $0C BREAK "L" CASE $0D BREAK "P" CASE $0E BREAK $0F --- default is SPACE/BLANC/EMPTY/OFF ; pub (LED) ( char -- ) SWITCH --- use the ASCII value as a switch in the case statement ^M CASE ledbuf C~ BREAK --- on CR reset display pos ^J CASE BREAK --- ignore LF ^L CASE ledbuf 9 BL FILL REFRESH BREAK --- reset and blank ^N CASE 0 12 LED! BREAK --- enable display (unblank) ^O CASE 1 12 LED! BREAK "." CASE $80 ledbuf C@ 1- 7 AND ledbuf 1+ + C+! BREAK --- add in DP to previous character (or first) SWITCH@ BL < IF SWITCH@ >N 10 LED! EXIT THEN --- set 4-bit brightness $10..$1F ASC>SEG ledbuf C@ 7 AND ledbuf 1+ + C! --- otherwise treat it as a character ledbuf C++ --- increment position REFRESH ; pub >LED ( char -- ) ledbuf @ 0= --- initialise the display if necessary (all zeros on startup) IF ledpins SPIPINS --- setup masks used by SPI instructions @SPISCK 3 + COGREG@ >| ' ledce 1+ ! --- automatically setup chip enable pin constant ledce HIGH --- ensure chip enable is and output and set to off @SPISCK COGREG@ OUTCLR --- MAX7219 likes to work with clock low to high 8 DIGITS --- scan limit $FF 9 LED! --- full decode 0 15 LED! --- dont forget to reset TEST mode $18 (LED) --- SET BRIGHTNESS ^L (LED) --- clear the display ^N (LED) --- enable display THEN (LED) ; --- Switch Tachyon character output to the MAX7219 LED display --- i.e. MAX7219 CR PRINT" HELP" 123 PRINT pub MAX7219 ' >LED uemit W! ; ]~ END BACKUPI can still learn something from you ;-)
It was just a bottom up, step by step approach and I was aware, that I could inline a lot in the end to save many definitions.
And I also used parts of my driver for 8*8 matrix displays, which use the same MAX7219 chip.
Recently I had a visitor who just wanted to start with Arduino and I showed him a little Propeller + Tachyon. He was so excited, that I made a Prop breadboard setup for him to play immediately and he ordered some Propellers.
Now he got one of those cheap 240*320 QVGA displays with ILI9341 and touch controller XPT2046 and asks how to do this with Tachyon.
So I had a look and found Peter's SSD2119QVGA.fth which looks close and I think I could adapt.
That's a good side about Arduino - you can find drivers just about for anything ...
I tell him next time better check if there is a Tachyon driver, before ordering new HW ;-)
@MJB:
I'm mainly a hardware guy so the software has to make the hardware work or more correctly they should work in unison. While I can probe and stimulate digital logic the same is not true with binary blob firmware where the emphasis is on the PC and the tools. My first exposure to Forth totally inspired me, for the first time I could see that I could interact with the "system", the whole synergistic union of hardware and software in a friendly way. I had also used Basic but peeking and poking and goto'ing in decimal was not friendly at all. Outside of that the various compilers were so PC centric, I had to know about the current version of the compiler, its quirks, and about its libraries, although most of the time this stuff was dark and mysterious. When I did manage to get it to compile and load it didn't help unless it worked perfectly, there was no way to test, debug, trim, improve anything on the board, only scratch your head and wonder what the compiler was actually generating.
So with the Propeller my Tachyon approach is not PC centric, but my focus is on the hardware itself, the Propeller chip in its raw glory and being able to interact with that chip in a similar way I would with digital logic. This leads to bottom up coding which despite all the bad things said about it is actually a good thing if done interactively with a top down vision. When I design a new xyz board that has new special sensors and new displays etc I know I can tickle these interactively initially to make sure I'm on the right path. With a compiler the usual approach people take is "where's the driver?". In contrast I am totally empowered and have great freedom of expression with Tachyon and receive instant feedback (and fun) from booting up a brand new board.
So @MJB just as when you had the Arduino visitor and you showed him the Prop+Tachyon and he was so excited that he could "play" immediately, that is exactly the kind of thing that I try to make happen when I make Tachyon totally open and even make Explorer images. You even wrote a lot of the 1-wire stuff that searches every pin and lists any devices it finds. I kind of expect that people would be eager to try Tachyon, to load'n'go as it were, but I am constantly amazed at the number that hold off from trying it. I know that they are missing out big time. Perhaps I have made it too easy, or perhaps it is because they have preconceptions about "Forth", even on the Prop itself and are wary, but why? Nothing ventured, nothing gained, and it is so easy to get started, I even have a long Introduction to Tachyon Forth and step by step examples. But that is not much different as is the case with "oldies" who try to use a new piece of technology and give up in disgust within seconds because it doesn't work the way they are used to. Even kids had to play and play before they learnt anything but then again kids don't have preconceptions (and pride).
I just had discovered the Propeller when you started with Tachyon.
So I was with you from the beginning and liked it because it has many of the benefits I was used from huge LISP systems.
Full source code, interactive, introspection, little syntax and huge expressive power ...
And this taylored for the Propeller.
Reading the Tachyon kernel was my introduction into PASM ... great.
I just have way too little time to do a lot of coding.
thanks for sharing your development process and it's results.
Markus
That's what's been so much fun too, being able to share and get feedback and experiences. You've been a great contributor to Tachyon even if you unfortunately have "way too little time to do a lot of coding"
and made every tiny SetThisParameter a separate function,
to verify everything step by step - which finally worked.
And then I did not do the (fully agree with you) final step in consolidating it before publishing it.
Actually I like your coding style ;-)
but it is sometimes a bit concise to start with.
Did anybody work with a touch controller like
touch controller XPT2046.
I was thinking of polling it inside the timer cog every ms and put events in a queue to be processed inside keypoll
This is a very simple chip to interface, something that we just play with in Forth and get up and running in no time. Page 23 of the manual shows the SPI sequence required, send a control bytes, read back 16-bits. So in Forth I would setup the pins, interactively write a control byte and read two bytes or 16-bits back before releasing the CE. When it comes back the way I expect, I then build on that. Thirty minutes later we have a fully functional "driver". That's much less time and a lot more rewarding than searching for a "driver"!
The high level approach I would just query it as required since we wouldn't expect to do anything fancy with this underwhelming and seemingly obsolete chip (why?).
pub ASC>SEG SWITCH \ this line is missing I think - no HW to try atm "0" "9" SWITCH>< IF SWITCH@ $30 - BREAK "-" CASE $0A BREAK "E" CASE $0B BREAK "H" CASE $0C BREAK "L" CASE $0D BREAK "P" CASE $0E BREAK $0F --- default is SPACE/BLANC/EMPTY/OFF ;No bug, just a redundancy since we would have to do a SWITCH@ ASC>SEG and then another SWITCH again, all redundant, just use the same SWITCH. Even without the hardware I was able to confirm the driver works by examining the display buffer as the SPI signals are straightforward and don't need to be taken into account. The only thing that might need a little tweak is the order of the digits depending upon the actual hardware, left to right or right to left, but that would only be something like a "7 XOR" in the right place in REFRESH. In fact the whole driver could have used a buffer for all the 7219 registers that gets updated when we run REFRESH since it takes less than 200us to update the whole chip.
what a trick !!! using the switch from a previous / outer word ...
A quick test reveals it works, maybe somebody would like to try it on a real display and simply switch Tachyon output to it with a simple "MAX7219".
This is my quick test:
Thinking about it I might even get it to scroll horizontally when a line gets more than 8 characters. Anyway this is it for now.
TACHYON [~ FORGET MAX7219.fth pub MAX7219.fth PRINT" MAX7219/7221 8-digit LED Driver by PBJ 160407-0000 " ; DECIMAL { PBJ - Simplified version of MJB's original Tachyon code also makes it a totally streaming character output device Just select MAX7219 as the output device and driver handles special controls etc } &14.12.15.13 == ledpins --- setup hardware pinout as &ce.xx.mosi.sck (default=breadboard) 0 == ledce --- dummy chip enable pin gets set automatically 10 BYTES ledbuf --- character write position plus 8 characters pub DIGITS ( nDIGITS - ) 1- 11 pub LED! ( val reg -- ) SPIWRB DROP SPIWRB DROP ledce HIGH ; pub REFRESH 9 1 DO ledbuf I + C@ I LED! LOOP ; --- !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ TABLE 7segs $00 | $86 | $42 | $49 | $2D | $52 | $5B | $02 | --- $20..$27 !"#$%&' $39 | $0F | $C9 | $46 | $04 | $40 | $80 | $52 | --- $28..$2F ()*+,-./ $3F | $06 | $59 | $4F | $66 | $6D | $7D | $07 | --- $30..$37 01234567 $7F | $6F | $41 | $45 | $70 | $48 | $46 | $DB | --- $38..$3F 89:;<=>? $7B | $77 | $7C | $39 | $5E | $79 | $71 | $3D | --- $40..$47 @ABCDEFG $76 | $30 | $0E | $72 | $38 | $23 | $54 | $5C | --- $48..$4F HIJKLMNO $73 | $79 | $50 | $6D | $46 | $3E | $62 | $1C | --- $50..$57 PQRSTUVW $52 | $6E | $59 | $39 | $64 | $0F | $01 | $08 | --- $58..$5F XYZ[\]^_ $00 | $77 | $7C | $39 | $5E | $79 | $71 | $3D | --- $60..$67 `abcdefg $76 | $30 | $0E | $72 | $38 | $23 | $54 | $5C | --- $68..$6F hijklmno $73 | $79 | $50 | $6D | $46 | $3E | $62 | $1C | --- $70..$77 pqrstuvw $52 | $6E | $59 | $39 | $36 | $0F | $52 | $00 | --- $78..$7F xyz{|}~ pub (LED) ( char -- ) SWITCH --- use the ASCII value as a switch in the case statement ^M CASE ledbuf C~ BREAK --- on CR reset display pos ^J CASE BREAK --- ignore LF ^L CASE ledbuf 9 BL FILL REFRESH BREAK --- reset and blank ^N CASE 0 12 LED! BREAK --- enable display (unblank) ^O CASE 1 12 LED! BREAK "." CASE $80 ledbuf C@ 1- 7 AND ledbuf 1+ + C+! BREAK --- add in DP to previous character (or first) SWITCH@ BL < IF SWITCH@ >N 10 LED! EXIT THEN --- set 4-bit brightness $10..$1F SWITCH@ BL - 7segs + C@ ledbuf C@ 7 AND ledbuf 1+ + C! --- otherwise treat it as a character ledbuf C++ --- increment position REFRESH ; pub >LED ( char -- ) ledbuf @ 0= --- initialise the display if necessary (all zeros on startup) IF ledpins SPIPINS --- setup masks used by SPI instructions @SPISCK 3 + COGREG@ >| ' ledce 1+ ! --- automatically setup chip enable pin constant ledce HIGH --- ensure chip enable is and output and set to off @SPISCK COGREG@ OUTCLR --- MAX7219 likes to work with clock low to high 8 DIGITS --- scan limit 0 9 LED! --- no decode, use table 0 15 LED! --- dont forget to reset TEST mode $18 (LED) --- SET BRIGHTNESS ^L (LED) --- clear the display ^N (LED) --- enable display THEN (LED) ; --- Switch Tachyon character output to the MAX7219 LED display --- i.e. MAX7219 CR PRINT" HELP" 123 PRINT pub MAX7219 ' >LED uemit W! ; ]~ END BACKUP