Well I will use Tachyon and a current setup to send a simple message via SMTP to our local MTA, see what I can get it to do.
MJB sent me a BASCOM version which although simple was just excessively verbose, what clutter!
So I just tried something last night via a Telnet terminal into a mail server and it is very very simple indeed. When I get some time later I will code it in so that I can just pass a string (or virtual string/file) to the SMTP routine a bit like this:
or a section of code over multiple lines may look like this:
" System alarm" SUBJECT: // Change the default subject line for an email
alarmlist RCPT: // Change the default receipient(s) by using a list
SMTP // Select SMTP DATA as an output device so everything prints to this
PRINT" Alarms detected! " CR
PRINT_ALARMS // Verbose alarm report
PRINT" System time is "
.DATE SPACE .TIME CR // System time just for the record
syssig$ PRINT$ // Print system sig at end
POST // Post this email now
This is just basic and I will refine it as I go but it will be very easy to format and send emails from runtime code.
MJB sent me a BASCOM version which although simple was just excessively verbose, what clutter!
So I just tried something last night via a Telnet terminal into a mail server and it is very very simple indeed. When I get some time later I will code it in so that I can just pass a string (or virtual string/file) to the SMTP routine a bit like this:
or a section of code over multiple lines may look like this:
" System alarm" SUBJECT: // Change the default subject line for an email
alarmlist RCPT: // Change the default receipient(s) by using a list
SMTP // Select SMTP DATA as an output device so everything prints to this
PRINT" Alarms detected! " CR
PRINT_ALARMS // Verbose alarm report
PRINT" System time is "
.DATE SPACE .TIME CR // System time just for the record
syssig$ PRINT$ // Print system sig at end
POST // Post this email now
This is just basic and I will refine it as I go but it will be very easy to format and send emails from runtime code.
I thought you were after just this type of "log" notification et al.
I thought you were after just this type of "log" notification et al.
Neat
dp
Now that I started coding it I think I have made it simpler again perhaps? Here is a snippet of embedded code that sends an email, judge for yourself:
[FONT=courier new][COLOR=#000000]
TO: PRINT" tomyfriend@somewhere.com" // diverts output to the RCPT string array (one way of doing it)
SUBJECT: PRINT" Testing email from Tachyon" // diverts output to the Subject: string (part of body)
SMTP IF // setup SMTP connection ready for body - returns with flag
PRINT" Dear Friend, this is the message" CR // now all we do is print out stuff as if it were the console
#10 0 DO CR I . SPACE PRINT" Hello World" CR LOOP // and some automated stuff as well
PRINT" The time is now " .DATE SPACE .TIME CR
PRINT" Thank you," CR // sign off
PRINT" Your friend" CR
" mysig.txt" FPRINT // print out the sig file if it exists
POST // all done, post this - returns with flag
THEN
[/COLOR][/FONT]
Now that I started coding it I think I have made it simpler again perhaps? Here is a snippet of embedded code that sends an email, judge for yourself:
[FONT=courier new][COLOR=#000000]
TO: PRINT" tomyfriend@somewhere.com" // diverts output to the RCPT string array (one way of doing it)
SUBJECT: PRINT" Testing email from Tachyon" // diverts output to the Subject: string (part of body)
SMTP IF // setup SMTP connection ready for body - returns with flag
PRINT" Dear Friend, this is the message" CR // now all we do is print out stuff as if it were the console
#10 0 DO CR I . SPACE PRINT" Hello World" CR LOOP // and some automated stuff as well
PRINT" The time is now " .DATE SPACE .TIME CR
PRINT" Thank you," CR // sign off
PRINT" Your friend" CR
" mysig.txt" FPRINT // print out the sig file if it exists
POST // all done, post this - returns with flag
THEN
[/COLOR][/FONT]
Well it doesn't get much more simple, almost as if you are typing in a session live on an SMTP server.
Do you have an example of this: // diverts output to the RCPT string array (one way of doing it)
Well it doesn't get much more simple, almost as if you are typing in a session live on an SMTP server.
Do you have an example of this: // diverts output to the RCPT string array (one way of doing it)
Of course it's just as easy to say "tomyfriend@somewhere.com" to$ $! which just stores the literal string into the string to$ but the TO: method is nice and readable and works just as well except it prints the string into the required "box"
But the way I code that is simple:
But you can have a look at the EASYMAIL public code document which gets cloned off my working document. It's a WIP while I learn how to configure XMail or some other server. I'm also testing with Googles restricted port 25 server as well at aspmx.l.google.com
Here is a test I use to show how it's coded:
[FONT=courier new]--- TESTING
pub EMAIL
TO: PRINT" pbjtech@gmail.com" // diverts output to the RCPT string array (one way of doing it)
SUBJECT: PRINT" Testing email from Tachyon" // diverts output to the Subject: string (part of body)
SMTP IF // setup SMTP connection ready for body - returns with flag
PRINT" Dear Friend, this is the message" CR // now all we do is print out stuff as if it were the console
#10 0 DO I . SPACE PRINT" Hello World" CR LOOP // and some automated stuff as well
PRINT" The time is now " .DATE SPACE .TIME CR
PRINT" Thank you," CR // sign off
PRINT" Your friend" CR
" mysig.txt" FPRINT // print out the sig file if it exists
POST // all done, post this - returns with flag
THEN
;[/FONT]
EDIT: Here is the console output when trying to connect to my local errant XMail server:
[FONT=courier new]EMAIL
#0 08:39:13 TCP PORT#12345; 25 TX . . RX . .IR=00 ST=13 INIT
#0 08:39:13 TCP PORT#12345; 25 TXCA98.CA98. RX . .IR=01 ST=17 ESTABLISHED 192.168.016.009.
HELO pbjtech.net
220
0220 xmailserver.test <1412116415.140600804349696@xmailserver.test> [XMail 1.27 ESMTP Server] service ready; Wed, 1 Oct 2014 08:33:35
+1000
#0 08:39:13 TCP PORT#12345; 25 TXCAAA.CAAA. RX 8C. 8C.IR=05 ST=17 ESTABLISHED 192.168.016.009.
MAIL FROM:<<peter@pbjtech.net>>
250
0250 xmailserver.test
#0 08:39:13 TCP PORT#12345; 25 TXCACF.CACF. RX A2. A2.IR=05 ST=17 ESTABLISHED 192.168.016.009.
RCPT TO:<pbjtech@gmail.com>
500
0500 Syntax error, command unrecognized
#0 08:39:13 TCP PORT#12345; 25 TXCAF0.CAF0. RX CA. CA.IR=05 ST=17 ESTABLISHED 192.168.016.009.
Dear Friend, this is the message
0 Hello World
1 Hello World
2 Hello World
3 Hello World
4 Hello World
5 Hello World
6 Hello World
7 Hello World
8 Hello World
9 Hello World
The time is now 14/10/01 08:39:13
Thank you,
Your friend
.
#0 08:39:18 TCP PORT#12345; 25 TXCAF0.CAF0. RX CA. F2.IR=07 ST=00 CLOSED
ok[/FONT]
Of course it's just as easy to say "tomyfriend@somewhere.com" to$ $! which just stores the literal string into the string to$ but the TO: method is nice and readable and works just as well except it prints the string into the required "box"
But the way I code that is simple:
But you can have a look at the EASYMAIL public code document which gets cloned off my working document. It's a WIP while I learn how to configure XMail or some other server. I'm also testing with Googles restricted port 25 server as well at aspmx.l.google.com
Here is a test I use to show how it's coded:
[FONT=courier new]--- TESTING
pub EMAIL
TO: PRINT" pbjtech@gmail.com" // diverts output to the RCPT string array (one way of doing it)
SUBJECT: PRINT" Testing email from Tachyon" // diverts output to the Subject: string (part of body)
SMTP IF // setup SMTP connection ready for body - returns with flag
PRINT" Dear Friend, this is the message" CR // now all we do is print out stuff as if it were the console
#10 0 DO I . SPACE PRINT" Hello World" CR LOOP // and some automated stuff as well
PRINT" The time is now " .DATE SPACE .TIME CR
PRINT" Thank you," CR // sign off
PRINT" Your friend" CR
" mysig.txt" FPRINT // print out the sig file if it exists
POST // all done, post this - returns with flag
THEN
;[/FONT]
EDIT: Here is the console output when trying to connect to my local errant XMail server:
[FONT=courier new]EMAIL
#0 08:39:13 TCP PORT#12345; 25 TX . . RX . .IR=00 ST=13 INIT
#0 08:39:13 TCP PORT#12345; 25 TXCA98.CA98. RX . .IR=01 ST=17 ESTABLISHED 192.168.016.009.
HELO pbjtech.net
220
0220 xmailserver.test <1412116415.140600804349696@xmailserver.test> [XMail 1.27 ESMTP Server] service ready; Wed, 1 Oct 2014 08:33:35
+1000
#0 08:39:13 TCP PORT#12345; 25 TXCAAA.CAAA. RX 8C. 8C.IR=05 ST=17 ESTABLISHED 192.168.016.009.
MAIL FROM:<<peter@pbjtech.net>>
250
0250 xmailserver.test
#0 08:39:13 TCP PORT#12345; 25 TXCACF.CACF. RX A2. A2.IR=05 ST=17 ESTABLISHED 192.168.016.009.
RCPT TO:<pbjtech@gmail.com>
500
0500 Syntax error, command unrecognized
#0 08:39:13 TCP PORT#12345; 25 TXCAF0.CAF0. RX CA. CA.IR=05 ST=17 ESTABLISHED 192.168.016.009.
Dear Friend, this is the message
0 Hello World
1 Hello World
2 Hello World
3 Hello World
4 Hello World
5 Hello World
6 Hello World
7 Hello World
8 Hello World
9 Hello World
The time is now 14/10/01 08:39:13
Thank you,
Your friend
.
#0 08:39:18 TCP PORT#12345; 25 TXCAF0.CAF0. RX CA. F2.IR=07 ST=00 CLOSED
ok[/FONT]
wonderful - this is pretty much how I envisioned it.
I was hoping to get by without the extra string variables for FROM: TO: SUBJ: - but I didn't realize we need them twice in the envelope AND the header inside the message body.
Would have saved some bytes ...
maybe using string pointers instead of the original - usually constant - address strings might work.
instead of copying it to from$, to$, subj$
wonderful - this is pretty much how I envisioned it.
I was hoping to get by without the extra string variables for FROM: TO: SUBJ: - but I didn't realize we need them twice in the envelope AND the header inside the message body.
Would have saved some bytes ...
maybe using string pointers instead of the original - usually constant - address strings might work.
instead of copying it to from$, to$, subj$
The mail server itself only needs it once but having them as string variables means we don't have to keep specifying them either, keep the same SUBJECT and FROM and TO even. I could use the SDFS to store this information I guess and also the email itself and the receipt which is the final reply from the mail server. Perhaps I may do just that and create an emails.txt file for this and the current strings could just be stored in the header of the file for easy reference. After all a string is just a pointer but if that pointer is > physical memory then it simply accesses virtual memory. So a string that returns $4.0000 or greater for instance is assumed to be virtual so I just change PRINT$ to fetch from virtual memory rather than RAM or even EEPROM ($8000-$3.FFFF)
I have also just mucked around with UDP to do a DNS lookup, I've kept the method simple and it works just fine, so I will incorporate that into the email client so I can then specify a mail server rather than an IP address. The Google server's IP keeps changing.
Anyway, so now it is really simple to integrate email reports etc from the Prop and certainly all this functionality will be embedded in the new extremely tiny IoT5500 module so all a host has to do is issue an EMAIL command over the serial connection followed by the text with a simple null terminator whereupon it will format and POST the email. I will have to think about how to make the serial protocol simple and flexible at the same time to which end I will integrate these modules serially into a project or two to find out what works best.
The mail server itself only needs it once but having them as string variables means we don't have to keep specifying them either, keep the same SUBJECT and FROM and TO even. I could use the SDFS to store this information I guess and also the email itself and the receipt which is the final reply from the mail server. Perhaps I may do just that and create an emails.txt file for this and the current strings could just be stored in the header of the file for easy reference. After all a string is just a pointer but if that pointer is > physical memory then it simply accesses virtual memory. So a string that returns $4.0000 or greater for instance is assumed to be virtual so I just change PRINT$ to fetch from virtual memory rather than RAM or even EEPROM ($8000-$3.FFFF)
I have also just mucked around with UDP to do a DNS lookup, I've kept the method simple and it works just fine, so I will incorporate that into the email client so I can then specify a mail server rather than an IP address. The Google server's IP keeps changing.
Anyway, so now it is really simple to integrate email reports etc from the Prop and certainly all this functionality will be embedded in the new extremely tiny IoT5500 module so all a host has to do is issue an EMAIL command over the serial connection followed by the text with a simple null terminator whereupon it will format and POST the email. I will have to think about how to make the serial protocol simple and flexible at the same time to which end I will integrate these modules serially into a project or two to find out what works best.
like:
pub from$ FILE@ ;
pub to$ FILE@ BL + ;
pub subj$ FILE@ #64 + ;
then:
" emails.txt" FOPEN$ DROP
SMTP IF
(cat)
FCLOSE
PRINT" dynamic content"
POST
THEN
I've been having some trouble making sense of the SPI words but searched the forum and learned how they worked (at least in theory) and did have to adjust a few things: SPIPINS in your example doesn't set CE (SCE in my code) and instead I did:
SCE 16 SHL 3 + 8 SHL SCLK + SPIPINS --- setup masks for SPIWR (no MISO hence the "16 SHL" to skip that byte)
*** It seems my logic analyzer compared with the speed of this routing was resulting in "sub-par" logic levels for the device. Removing the analyzer pins yields flawless writes and blazing pixel updates! Nice work! ***
The LCD device I have might not be able to keep up with the rate your code pumps out the bits. I've looked at the output of "init" with a logic analyzer and it looks like proper SPI (albeit @ 4MHz instead of ~35KHz in my code). My LCD "mostly" displays the bytes I write to it but one sure sign writes are getting dropped is that a "lcdfill" doesn't fill the entire screen with the bit pattern I specify, leaving approximately 10 or so bytes of the last row untouched. Short of re-writing SPIWR, is there a way to throttle this to a lower speed?
One thing that did bother me after looking at the analyzer output was that the SCE and SCLK lines seem to come up in a random state after SPIPINS... is this normal? I resorted to setting the pins to the desired start state after SPIPINS to compensate.
As far as vectoring "lcdch" to "uemit" in your printing examples, this doesn't work on the Nokia 5110 style displays, as they have no built-in fonts... and are instead arranged as 84 bytes 6 rows high (yielding a display 84 pixels by 48 pixels), so each "lcdch" puts a 1 pixel wide by 8 pixels high on the display.
Thanks again for your guidance... I'm slowly working up to getting SIDcog into TF and this LCD interfacing is giving me nice visual feedback for learning.
hi
did you make any progress on this Nokia 5110 driver for Tachyon?
Any code to share?
Character driver?
I just got a 5110 LCD and would like to sue it with Tachyon as well.
Thanks
Markus
There are several commercial projects which I don't need to keep confidential for whatever reason so even though I may have made parts of this available before I am including them in the Tachyon Resource Links page (see sig).
Why do I do it?
Why not!
Ever wondered how you might tackle a project, well see the way I do it, that I include diagrams and links etc in with the code in a formatted document. This is fine for development with Tachyon as all I do is copy the whole document and paste it into the terminal which then just filters the text portion through which is then compiled on the target board. So this will also work from a smartphone/tablet and I have even powered the target board via my phone's USB through a FT232 PropPlug'ish cable that also feeds power to the board! Bluetooth works too of course and I have my own Bluetooth modules that plug in in place of the PropPlug.
The project documents are normally all one page which includes schematics, timing, photos, screenshots, labels, diagrams etc.
So with this information it is possible to clone or modify to suit or just use it as a basis for starting your own Tachyon project.
There has also been an update to the Electronic Gate reader and timer project as I have added a scheduling feature to it which allows for human readable input so it's nice and easy to setup all those complicated times, days, dates, actions.
A schedule looks like this:
SCHEDULE
08.00 AM DAILY WILL OPEN
11.00 PM DAILY WILL CLOSE
12:00 PM WEEKDAYS WILL TOOT
06.00 PM MON WILL CLOSE
06.00 PM FRI WILL CLOSE
07.30 PM SAT WILL CLOSE
06.00 PM SUN WILL CLOSE
01.00 PM 13 OCT WILL CLOSE
01.00 PM 14 OCT WILL CLOSE
DONE
Anyway, I'm trying to promote the Prop and the way I use it with Tachyon.
There are several commercial projects which I don't need to keep confidential for whatever reason so even though I may have made parts of this available before I am including them in the Tachyon Resource Links page (see sig).
Why do I do it?
Why not!
Ever wondered how you might tackle a project, well see the way I do it, that I include diagrams and links etc in with the code in a formatted document. This is fine for development with Tachyon as all I do is copy the whole document and paste it into the terminal which then just filters the text portion through which is then compiled on the target board. So this will also work from a smartphone/tablet and I have even powered the target board via my phone's USB through a FT232 PropPlug'ish cable that also feeds power to the board! Bluetooth works too of course and I have my own Bluetooth modules that plug in in place of the PropPlug.
The project documents are normally all one page which includes schematics, timing, photos, screenshots, labels, diagrams etc.
So with this information it is possible to clone or modify to suit or just use it as a basis for starting your own Tachyon project.
There has also been an update to the Electronic Gate reader and timer project as I have added a scheduling feature to it which allows for human readable input so it's nice and easy to setup all those complicated times, days, dates, actions.
A schedule looks like this:
SCHEDULE
08.00 AM DAILY WILL OPEN
11.00 PM DAILY WILL CLOSE
12:00 PM WEEKDAYS WILL TOOT
06.00 PM MON WILL CLOSE
06.00 PM FRI WILL CLOSE
07.30 PM SAT WILL CLOSE
06.00 PM SUN WILL CLOSE
01.00 PM 13 OCT WILL CLOSE
01.00 PM 14 OCT WILL CLOSE
DONE
Anyway, I'm trying to promote the Prop and the way I use it with Tachyon.
Go Forth and have Fun!
That's very impressive. You've certainly done amazing things with Tachyon. Congratulations!
Just looking at it now and it looks straightforward enough but if you are interested to follow along I have just created a project document and this is the public version of the document anyone can view. So as I find some time I will add to it, all you need to do is refresh the page of course, but I will try to put half an hour into it now just to get things going, which means mostly done
If I had them hooked up I wouldn't be posting yet as I'd already be talking to them and having too much fun.
Yeah, the timing is a bit tight for bytecode especially between each new group of 24-bits although I suspect that in reality that low time can be several microseconds at least, but less than 50us RET. So without being able to verify this and without looking at other code which might be misleading or throw me off writing clean code, I have implemented a small PASM RUNMOD which gets loaded up as a macro-instruction if you like and will take the address and count of an array of left justified 24-bit RGB words in each long.
I may get some of these devices in just so I can play with them, although not to the extent that Jon does I'd like to see if I can run them purely from bytecode but having a helper "instruction" doesn't hurt either.
EDIT: Just tested this and it takes 1ms to send 96 bytes (tested and fixed earlier version) so the timing looks good including back to back bytes and on the scope.
org _RUNMOD
' TXRGB ( array cnt -- ) pin mask is in COGREG4, line RET is done at HL, not here
' Will transmit a whole array of bytes each back to back in WS2812 timing format
' A zero is transmitted as 350ns high by 800ns low (+/-150ns)
' A one is transmitted as 700ns high by 600ns low
' have all data left justified in the array anyway
' LOADMOD has room for 19 longs which just fits!
TXRGB
rdbyte X,tos+1 ' read next byte
mov R1,#8 ' data bits
jmp #TXB ' skip delay of last bit as we had to read another byte from hub
TXRGBlp call #DLYBIT ' gets skipped if this is a new byte
TXB shr X,#1 wc ' get next bit
or OUTA,REG4 ' always clock tx pin high for at least 400ns
call #DLYBIT ' delay
if_nc andn OUTA,REG4 ' pull line down now if it's a 0 we are transmitting
call #DLYBIT ' delay again, either high or low
andn OUTA,REG4 ' always needs to go low in the last third of the cycle
djnz R1,#TXRGBlp ' so go back and get the next bit ready
RGBNEXT add tos+1,#1 ' next byte in array (and delay)
djnz tos,#TXRGB ' read the next long as long as we can (tos = count)
jmp #DROP2 ' tx line left low - discard stack parameters, all done.
DLYBIT
mov R2,CNT
add R2,#13
waitcnt R2,#0 ' just a delay, no need to synch
DLYBIT_ret ret
_TXRGB byte _WORD,(@TXRGB+s)>>8,@TXRGB+s
byte XCALL,xLOADMOD,EXIT
EDIT: It seems to me as if the actual low time is not that important since each bit is transmitted as a clock bit and if it is still high then it's a one, it just needs a minimum low time but not too long as to RET the line. So this might very well work with bytecode then.
This should work and I have timed 3.5ms to send 96 bytes of data to 32 devices:
--- method 2 - packing bytes into an array instead of 24-bit longs
--- transmit the bytes in the array as to the WS2812 daisy chain
pub TXRGB ( bytearray cnt -- )
WS.TXD LOW // always start off by making sure the txd is idling
WS.TXD 4 COGREG! // setup the txd pin as a clock pin (same line as data)
#50 us // ensure synch with RET
ADO // cycle through array from beginning for cnt
I C@ // read next byte
WS.TXD SWAP // setup iomask ready for SHROUT operation ( iomask dat )
8 FOR
CLOCK // will clock txd high - min cycle time here is 400ns
SHROUT // now send next data bit - high or low - 400ns
OVER OUTSET // basically needs an operation that quickly takes this line low
NEXT
2DROP // discard data
LOOP // Advance to next long
;
So annoying, can I do a WS2812 driver he says. Yeah says I.
Anyway, a minor distraction and the timing looks good. An extra RUNMOD instruction and 19 longs has been added to the kernel so that to talk to these chips it's as easy as this:
[FONT=courier new]--- define I/O and array
#P14 == WSTXD --- define our transmit pin
#96 == rgbsz --- specify the size of the array as a constant
rgbsz BYTES rgbleds --- define our byte array
pub LEDS
WSTXD OUTCLR --- Start a RET to synch the chips
WSTXD 4 COGREG! --- setup the I/O pin for the RUNMOD to use
[TXRGB] --- select the WS2812 module for RUNMOD (needs to be renamed yet)
#10 us --- still need a bit of extra delay for a minimum RET op
rgbleds rgbsz RUNMOD --- pass the address of the array and the byte count to the RUNMOD
;
( executing LEDS will update a 96 byte display in 1 ms )
[/FONT]
I decided to do a byte array instead as that means we just pack our pixels together and if I had enough of these LEDs I could construct and draw a bit-map display very easily.
Use the latest kernel in the Dropbox or here: TACHYON.binary
So annoying, can I do a WS2812 driver he says. Yeah says I.
Anyway, a minor distraction and the timing looks good. An extra RUNMOD instruction and 19 longs has been added to the kernel so that to talk to these chips it's as easy as this:
[FONT=courier new]--- define I/O and array
#P14 == WSTXD --- define our transmit pin
#96 == rgbsz --- specify the size of the array as a constant
rgbsz BYTES rgbleds --- define our byte array
pub LEDS
WSTXD OUTCLR --- Start a RET to synch the chips
WSTXD 4 COGREG! --- setup the I/O pin for the RUNMOD to use
[TXRGB] --- select the WS2812 module for RUNMOD (needs to be renamed yet)
#10 us --- still need a bit of extra delay for a minimum RET op
rgbleds rgbsz RUNMOD --- pass the address of the array and the byte count to the RUNMOD
;
( executing LEDS will update a 96 byte display in 1 ms )
[/FONT]
I decided to do a byte array instead as that means we just pack our pixels together and if I had enough of these LEDs I could construct and draw a bit-map display very easily.
Use the latest kernel in the Dropbox or here: TACHYON.binary
I just woke up and I find you've already solved the problem. I'll try it later. Thanks!
By the way, one reason I asked is that I had thought to use this as a good first attempt at writing something in Tachyon. Maybe that wouldn't have been such a good idea anyway since it seems you had to do some clever techniques to get it to work. Maybe I should instead try to make use of what you've just done. Anyway, thanks for the quick response!
I just woke up and I find you've already solved the problem. I'll try it later. Thanks!
By the way, one reason I asked is that I had thought to use this as a good first attempt at writing something in Tachyon. Maybe that wouldn't have been such a good idea anyway since it seems you had to do some clever techniques to get it to work. Maybe I should instead try to make use of what you've just done. Anyway, thanks for the quick response!
Well it was a short and fast learning curve, looked at the timing, decided that it may be a bit tight for bytecode alone so I do what I do and create a module as there is room for 19 longs in the Tachyon cog to load in special purpose modules which are called with the RUNMOD instruction.
To run this continually (optional of course) in the background of the console cog (why not) just type:
KEYPOLL LEDS
Or else you can run it from the timer cog with:
TIMER ledtimer ( create a timer variable )
' LEDS ledtimer ALARM ( tell this timer what to do when it counts down to zero)
#20 ledtimer TIMEOUT ( timeout in 20ms but need to insert this code in LEDS really to reload timer)
To fill the array with RED you could try this:
pub RED ( value -- ) rgbsz 1 DO DUP I C! 3 +LOOP DROP ;
If you only wanted it updated when you changed something then add LEDS to the end of that code to do that.
So you could type:
20 % RED
and the red bytes in the array should fill up with a value of 51. Well, it should work and the green and blue are similar but different offset (0 DO or 2 DO)
Actually that would factor to:
pub COLOR ( value offset -- ) rgbsz SWAP DO DUP I C! 3 +LOOP DROP ;
pub RED ( value -- ) 1 COLOR ;
pub GREEN ( value -- ) 0 COLOR ;
pub BLUE ( value -- ) 2 COLOR ;
I just woke up and I find you've already solved the problem. I'll try it later. Thanks!
By the way, one reason I asked is that I had thought to use this as a good first attempt at writing something in Tachyon. Maybe that wouldn't have been such a good idea anyway since it seems you had to do some clever techniques to get it to work. Maybe I should instead try to make use of what you've just done. Anyway, thanks for the quick response!
Well when working with a new language/platform/style and complete dev environment I just skip "hello world" and go straight to a FAST FFT implementation. That is a sure way to flush out any "limitations" </sarc>
Thanks Peter for the hot runmod tips and byte code.
Well when working with a new language/platform/style and complete dev environment I just skip "hello world" and go straight to a FAST FFT implementation. That is a sure way to flush out any "limitations" </sarc>
Thanks Peter for the hot runmod tips and byte code.
Yeah, I wasn't sure how to take that, jump in by starting with something that is really sub-microsecond and timing critical
The clever technique though is how little it took to get it to work, there is no big OBEX there, just a few lines of code, not enough to impress anybody, sorry
Yeah, I wasn't sure how to take that, jump in by starting with something that is really sub-microsecond and timing critical
The clever technique though is how little it took to get it to work, there is no big OBEX there, just a few lines of code, not enough to impress anybody, sorry
You had the solution before my Arduino IDE loaded, not fair. Mommy/Daddy Peter's not playing fair.
Well when working with a new language/platform/style and complete dev environment I just skip "hello world" and go straight to a FAST FFT implementation. That is a sure way to flush out any "limitations" </sarc>
Thanks Peter for the hot runmod tips and byte code.
I had assumed I would probably find a way to use JonnyMac's PASM code to do the timing critical stuff and just write the effects in Forth. I guess that's essentially what Peter did although he wrote the PASM code himself without looking at Jon's code.
I had assumed I would probably find a way to use JonnyMac's PASM code to do the timing critical stuff and just write the effects in Forth. I guess that's essentially what Peter did although he wrote the PASM code himself without looking at Jon's code.
Ahh, that's alright David, we know how to give "curry in a hurry"
Every time I look at example code I just get headaches, normally it seems overly complicated and so verbose and set in cement. So I just look at the requirements and deduce suitable KISS methods. In this case regardless of how the data was to be manipulated at the high level, all it needed was the correct timing. Constraining that "driver" to 19 longs meant it could load in as a RUNMOD so all the rest of the stuff could be done at bytecode level after that.
I suspect however (from how I would design the chip) that bit to bit timing is actually more open than the tight one or zero bit timing, so when i get some to play with I will interact with them in this regard to find out what can be done.
Ahh, that's alright David, we know how to give "curry in a hurry"
Every time I look at example code I just get headaches, normally it seems overly complicated and so verbose and set in cement. So I just look at the requirements and deduce suitable KISS methods. In this case regardless of how the data was to be manipulated at the high level, all it needed was the correct timing. Constraining that "driver" to 19 longs meant it could load in as a RUNMOD so all the rest of the stuff could be done at bytecode level after that.
I suspect however (from how I would design the chip) that bit to bit timing is actually more open than the tight one or zero bit timing, so when i get some to play with I will interact with them in this regard to find out what can be done.
Far from doing anything in a hurry, I would have been lucky to get it done at all while learning a new language. However, I've already written some simple "Hello, world" type programs in Tachyon so I needed something a bit more challenging. Maybe WS2812 was a bit too challenging. :-)
Far from doing anything in a hurry, I would have been lucky to get it done at all while learning a new language. However, I've already written some simple "Hello, world" type programs in Tachyon so I needed something a bit more challenging. Maybe WS2812 was a bit too challenging. :-)
I suppose if you were tackling the bit timing it might have been challenging but the high level stuff is something you can easily play with and you will probably have seen my other thread regarding this, and since it's your fault I expect you to apply yourself!
Also, I mentioned that the bit to bit timing for the chip is probably more relaxed than it seems to indicate in the datasheet as this is essentially a self-clocking shift register, something fairly easy to put together in hardware. So I look at a bit time as simply 3 phases: the clock phase, the data phase (with data sampling mid phase), and the gap phase. If it's self-clocking then the gap doesn't really matter except of course if you leave it too long it will sense it as a synch which is fair enough as it's only a single wire. So if that were confirmed with some actual hardware I probably would have only just written the driver at the high level although the transfer rate would only be half of what is possible with the RUNMOD helper module. Capisce?
I suppose if you were tackling the bit timing it might have been challenging but the high level stuff is something you can easily play with and you will probably have seen my other thread regarding this, and since it's your fault I expect you to apply yourself!
Also, I mentioned that the bit to bit timing for the chip is probably more relaxed than it seems to indicate in the datasheet as this is essentially a self-clocking shift register, something fairly easy to put together in hardware. So I look at a bit time as simply 3 phases: the clock phase, the data phase (with data sampling mid phase), and the gap phase. If it's self-clocking then the gap doesn't really matter except of course if you leave it too long it will sense it as a synch which is fair enough as it's only a single wire. So if that were confirmed with some actual hardware I probably would have only just written the driver at the high level although the transfer rate would only be half of what is possible with the RUNMOD helper module. Capisce?
Yes, I understand. I will probably try out your code over the next few days. I'm traveling but will be taking an ActivityBoard and some of the AdaFruit WS2812 LED gadgets with me. Thanks!
I loaded Tachyon binary and then added SDCARD.fth. All went well until I loaded EASYFILE and I get the error listed. What am I doing wrong. Thanks, Ken Propeller .:.:--TACHYON--:.:. Forth V24140928.1630Clock frequency = 80,000,000
NAMES: $59D0...7470 for 6816 (738 bytes added)
CODE: $0000...3C59 for 8633 (1893 bytes added)
CALLS: 0371 vectors free
RAM: 7543 bytes free
I loaded Tachyon binary and then added SDCARD.fth. All went well until I loaded EASYFILE and I get the error listed. What am I doing wrong. Thanks, Ken Propeller .:.:--TACHYON--:.:. Forth V24140928.1630Clock frequency = 80,000,000
NAMES: $59D0...7470 for 6816 (738 bytes added)
CODE: $0000...3C59 for 8633 (1893 bytes added)
CALLS: 0371 vectors free
RAM: 7543 bytes free
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
TACHYON
Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
ok
--> FOPEN# <-- not found nd
I would stick with the 2.3 kernel build. Download the spin file from the dropbox and rebuild the world by adding in EXTEND.fth. However you are pasting in the file to the console make sure you have some line delay, I use 13ms.
I loaded Tachyon binary and then added SDCARD.fth. All went well until I loaded EASYFILE and I get the error listed. What am I doing wrong. Thanks, Ken Propeller .:.:--TACHYON--:.:. Forth V24140928.1630Clock frequency = 80,000,000
NAMES: $59D0...7470 for 6816 (738 bytes added)
CODE: $0000...3C59 for 8633 (1893 bytes added)
CALLS: 0371 vectors free
RAM: 7543 bytes free
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
TACHYON
Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
ok
--> FOPEN# <-- not found nd
I don't see the end of module summary message for the EASYFILE.fth
so there is s.th. wrong -
could be line delay or paste error.
Where did you get your files from?
Check EASYFILE.fth for FOPEN# it should be defined there. - it is in the lastest version anyhow.
I don't see the end of module summary message for the EASYFILE.fth
so there is s.th. wrong -
could be line delay or paste error.
Where did you get your files from?
Check EASYFILE.fth for FOPEN# it should be defined there. - it is in the lastest version anyhow.
So kernel 2.4 is ready for the rest of the show then? I would think the best way would be to have binaries for V2.3 and Extend built for people just finding this thread, cut and paste the other modules as needed.
I'm not sure where you got the files from for this and whether you have specified a header file for your hardware, however I have made sure the Dropbox files are up-to-date with the Google docs version which I work off. I then loaded Spinneret.fth + SDCARD.fth + EASYFILE.fth onto a Spinneret of course and this is what I got:
Comments
MJB sent me a BASCOM version which although simple was just excessively verbose, what clutter!
So I just tried something last night via a Telnet terminal into a mail server and it is very very simple indeed. When I get some time later I will code it in so that I can just pass a string (or virtual string/file) to the SMTP routine a bit like this:
" LOG.TXT" FOPEN$ " tomyfriend@somewhere.com" EMAIL
" testing email client" " tomyfriend@somewhere.com" EMAIL
or a section of code over multiple lines may look like this:
" System alarm" SUBJECT: // Change the default subject line for an email alarmlist RCPT: // Change the default receipient(s) by using a list SMTP // Select SMTP DATA as an output device so everything prints to this PRINT" Alarms detected! " CR PRINT_ALARMS // Verbose alarm report PRINT" System time is " .DATE SPACE .TIME CR // System time just for the record syssig$ PRINT$ // Print system sig at end POST // Post this email nowThis is just basic and I will refine it as I go but it will be very easy to format and send emails from runtime code.
I thought you were after just this type of "log" notification et al.
Neat
dp
Now that I started coding it I think I have made it simpler again perhaps? Here is a snippet of embedded code that sends an email, judge for yourself:
[FONT=courier new][COLOR=#000000] TO: PRINT" tomyfriend@somewhere.com" // diverts output to the RCPT string array (one way of doing it) SUBJECT: PRINT" Testing email from Tachyon" // diverts output to the Subject: string (part of body) SMTP IF // setup SMTP connection ready for body - returns with flag PRINT" Dear Friend, this is the message" CR // now all we do is print out stuff as if it were the console #10 0 DO CR I . SPACE PRINT" Hello World" CR LOOP // and some automated stuff as well PRINT" The time is now " .DATE SPACE .TIME CR PRINT" Thank you," CR // sign off PRINT" Your friend" CR " mysig.txt" FPRINT // print out the sig file if it exists POST // all done, post this - returns with flag THEN [/COLOR][/FONT]Well it doesn't get much more simple, almost as if you are typing in a session live on an SMTP server.
Do you have an example of this: // diverts output to the RCPT string array (one way of doing it)
Of course it's just as easy to say "tomyfriend@somewhere.com" to$ $! which just stores the literal string into the string to$ but the TO: method is nice and readable and works just as well except it prints the string into the required "box"
But the way I code that is simple:
But you can have a look at the EASYMAIL public code document which gets cloned off my working document. It's a WIP while I learn how to configure XMail or some other server. I'm also testing with Googles restricted port 25 server as well at aspmx.l.google.com
Here is a test I use to show how it's coded:
[FONT=courier new]--- TESTING pub EMAIL TO: PRINT" pbjtech@gmail.com" // diverts output to the RCPT string array (one way of doing it) SUBJECT: PRINT" Testing email from Tachyon" // diverts output to the Subject: string (part of body) SMTP IF // setup SMTP connection ready for body - returns with flag PRINT" Dear Friend, this is the message" CR // now all we do is print out stuff as if it were the console #10 0 DO I . SPACE PRINT" Hello World" CR LOOP // and some automated stuff as well PRINT" The time is now " .DATE SPACE .TIME CR PRINT" Thank you," CR // sign off PRINT" Your friend" CR " mysig.txt" FPRINT // print out the sig file if it exists POST // all done, post this - returns with flag THEN ;[/FONT]EDIT: Here is the console output when trying to connect to my local errant XMail server:
[FONT=courier new]EMAIL #0 08:39:13 TCP PORT#12345; 25 TX . . RX . .IR=00 ST=13 INIT #0 08:39:13 TCP PORT#12345; 25 TXCA98.CA98. RX . .IR=01 ST=17 ESTABLISHED 192.168.016.009. HELO pbjtech.net 220 0220 xmailserver.test <1412116415.140600804349696@xmailserver.test> [XMail 1.27 ESMTP Server] service ready; Wed, 1 Oct 2014 08:33:35 +1000 #0 08:39:13 TCP PORT#12345; 25 TXCAAA.CAAA. RX 8C. 8C.IR=05 ST=17 ESTABLISHED 192.168.016.009. MAIL FROM:<<peter@pbjtech.net>> 250 0250 xmailserver.test #0 08:39:13 TCP PORT#12345; 25 TXCACF.CACF. RX A2. A2.IR=05 ST=17 ESTABLISHED 192.168.016.009. RCPT TO:<pbjtech@gmail.com> 500 0500 Syntax error, command unrecognized #0 08:39:13 TCP PORT#12345; 25 TXCAF0.CAF0. RX CA. CA.IR=05 ST=17 ESTABLISHED 192.168.016.009. Dear Friend, this is the message 0 Hello World 1 Hello World 2 Hello World 3 Hello World 4 Hello World 5 Hello World 6 Hello World 7 Hello World 8 Hello World 9 Hello World The time is now 14/10/01 08:39:13 Thank you, Your friend . #0 08:39:18 TCP PORT#12345; 25 TXCAF0.CAF0. RX CA. F2.IR=07 ST=00 CLOSED ok[/FONT]I was hoping to get by without the extra string variables for FROM: TO: SUBJ: - but I didn't realize we need them twice in the envelope AND the header inside the message body.
Would have saved some bytes ...
maybe using string pointers instead of the original - usually constant - address strings might work.
instead of copying it to from$, to$, subj$
The mail server itself only needs it once but having them as string variables means we don't have to keep specifying them either, keep the same SUBJECT and FROM and TO even. I could use the SDFS to store this information I guess and also the email itself and the receipt which is the final reply from the mail server. Perhaps I may do just that and create an emails.txt file for this and the current strings could just be stored in the header of the file for easy reference. After all a string is just a pointer but if that pointer is > physical memory then it simply accesses virtual memory. So a string that returns $4.0000 or greater for instance is assumed to be virtual so I just change PRINT$ to fetch from virtual memory rather than RAM or even EEPROM ($8000-$3.FFFF)
I have also just mucked around with UDP to do a DNS lookup, I've kept the method simple and it works just fine, so I will incorporate that into the email client so I can then specify a mail server rather than an IP address. The Google server's IP keeps changing.
Anyway, so now it is really simple to integrate email reports etc from the Prop and certainly all this functionality will be embedded in the new extremely tiny IoT5500 module so all a host has to do is issue an EMAIL command over the serial connection followed by the text with a simple null terminator whereupon it will format and POST the email. I will have to think about how to make the serial protocol simple and flexible at the same time to which end I will integrate these modules serially into a project or two to find out what works best.
hi
did you make any progress on this Nokia 5110 driver for Tachyon?
Any code to share?
Character driver?
I just got a 5110 LCD and would like to sue it with Tachyon as well.
Thanks
Markus
Why do I do it?
Why not!
Ever wondered how you might tackle a project, well see the way I do it, that I include diagrams and links etc in with the code in a formatted document. This is fine for development with Tachyon as all I do is copy the whole document and paste it into the terminal which then just filters the text portion through which is then compiled on the target board. So this will also work from a smartphone/tablet and I have even powered the target board via my phone's USB through a FT232 PropPlug'ish cable that also feeds power to the board! Bluetooth works too of course and I have my own Bluetooth modules that plug in in place of the PropPlug.
The project documents are normally all one page which includes schematics, timing, photos, screenshots, labels, diagrams etc.
So with this information it is possible to clone or modify to suit or just use it as a basis for starting your own Tachyon project.
There has also been an update to the Electronic Gate reader and timer project as I have added a scheduling feature to it which allows for human readable input so it's nice and easy to setup all those complicated times, days, dates, actions.
A schedule looks like this:
SCHEDULE
08.00 AM DAILY WILL OPEN
11.00 PM DAILY WILL CLOSE
12:00 PM WEEKDAYS WILL TOOT
06.00 PM MON WILL CLOSE
06.00 PM FRI WILL CLOSE
07.30 PM SAT WILL CLOSE
06.00 PM SUN WILL CLOSE
01.00 PM 13 OCT WILL CLOSE
01.00 PM 14 OCT WILL CLOSE
DONE
Anyway, I'm trying to promote the Prop and the way I use it with Tachyon.
Go Forth and have Fun!
Just looking at it now and it looks straightforward enough but if you are interested to follow along I have just created a project document and this is the public version of the document anyone can view. So as I find some time I will add to it, all you need to do is refresh the page of course, but I will try to put half an hour into it now just to get things going, which means mostly done
If I had them hooked up I wouldn't be posting yet as I'd already be talking to them and having too much fun.
Yeah, the timing is a bit tight for bytecode especially between each new group of 24-bits although I suspect that in reality that low time can be several microseconds at least, but less than 50us RET. So without being able to verify this and without looking at other code which might be misleading or throw me off writing clean code, I have implemented a small PASM RUNMOD which gets loaded up as a macro-instruction if you like and will take the address and count of an array of left justified 24-bit RGB words in each long.
I may get some of these devices in just so I can play with them, although not to the extent that Jon does
EDIT: Just tested this and it takes 1ms to send 96 bytes (tested and fixed earlier version) so the timing looks good including back to back bytes and on the scope.
org _RUNMOD ' TXRGB ( array cnt -- ) pin mask is in COGREG4, line RET is done at HL, not here ' Will transmit a whole array of bytes each back to back in WS2812 timing format ' A zero is transmitted as 350ns high by 800ns low (+/-150ns) ' A one is transmitted as 700ns high by 600ns low ' have all data left justified in the array anyway ' LOADMOD has room for 19 longs which just fits! TXRGB rdbyte X,tos+1 ' read next byte mov R1,#8 ' data bits jmp #TXB ' skip delay of last bit as we had to read another byte from hub TXRGBlp call #DLYBIT ' gets skipped if this is a new byte TXB shr X,#1 wc ' get next bit or OUTA,REG4 ' always clock tx pin high for at least 400ns call #DLYBIT ' delay if_nc andn OUTA,REG4 ' pull line down now if it's a 0 we are transmitting call #DLYBIT ' delay again, either high or low andn OUTA,REG4 ' always needs to go low in the last third of the cycle djnz R1,#TXRGBlp ' so go back and get the next bit ready RGBNEXT add tos+1,#1 ' next byte in array (and delay) djnz tos,#TXRGB ' read the next long as long as we can (tos = count) jmp #DROP2 ' tx line left low - discard stack parameters, all done. DLYBIT mov R2,CNT add R2,#13 waitcnt R2,#0 ' just a delay, no need to synch DLYBIT_ret ret _TXRGB byte _WORD,(@TXRGB+s)>>8,@TXRGB+s byte XCALL,xLOADMOD,EXITEDIT: It seems to me as if the actual low time is not that important since each bit is transmitted as a clock bit and if it is still high then it's a one, it just needs a minimum low time but not too long as to RET the line. So this might very well work with bytecode then.
This should work and I have timed 3.5ms to send 96 bytes of data to 32 devices:
--- method 2 - packing bytes into an array instead of 24-bit longs --- transmit the bytes in the array as to the WS2812 daisy chain pub TXRGB ( bytearray cnt -- ) WS.TXD LOW // always start off by making sure the txd is idling WS.TXD 4 COGREG! // setup the txd pin as a clock pin (same line as data) #50 us // ensure synch with RET ADO // cycle through array from beginning for cnt I C@ // read next byte WS.TXD SWAP // setup iomask ready for SHROUT operation ( iomask dat ) 8 FOR CLOCK // will clock txd high - min cycle time here is 400ns SHROUT // now send next data bit - high or low - 400ns OVER OUTSET // basically needs an operation that quickly takes this line low NEXT 2DROP // discard data LOOP // Advance to next long ;Anyway, a minor distraction and the timing looks good. An extra RUNMOD instruction and 19 longs has been added to the kernel so that to talk to these chips it's as easy as this:
[FONT=courier new]--- define I/O and array #P14 == WSTXD --- define our transmit pin #96 == rgbsz --- specify the size of the array as a constant rgbsz BYTES rgbleds --- define our byte array pub LEDS WSTXD OUTCLR --- Start a RET to synch the chips WSTXD 4 COGREG! --- setup the I/O pin for the RUNMOD to use [TXRGB] --- select the WS2812 module for RUNMOD (needs to be renamed yet) #10 us --- still need a bit of extra delay for a minimum RET op rgbleds rgbsz RUNMOD --- pass the address of the array and the byte count to the RUNMOD ; ( executing LEDS will update a 96 byte display in 1 ms ) [/FONT]I decided to do a byte array instead as that means we just pack our pixels together and if I had enough of these LEDs I could construct and draw a bit-map display very easily.
Use the latest kernel in the Dropbox or here: TACHYON.binary
By the way, one reason I asked is that I had thought to use this as a good first attempt at writing something in Tachyon. Maybe that wouldn't have been such a good idea anyway since it seems you had to do some clever techniques to get it to work. Maybe I should instead try to make use of what you've just done. Anyway, thanks for the quick response!
Well it was a short and fast learning curve, looked at the timing, decided that it may be a bit tight for bytecode alone so I do what I do and create a module as there is room for 19 longs in the Tachyon cog to load in special purpose modules which are called with the RUNMOD instruction.
To run this continually (optional of course) in the background of the console cog (why not) just type:
KEYPOLL LEDS
Or else you can run it from the timer cog with:
TIMER ledtimer ( create a timer variable )
' LEDS ledtimer ALARM ( tell this timer what to do when it counts down to zero)
#20 ledtimer TIMEOUT ( timeout in 20ms but need to insert this code in LEDS really to reload timer)
To fill the array with RED you could try this:
pub RED ( value -- ) rgbsz 1 DO DUP I C! 3 +LOOP DROP ;
If you only wanted it updated when you changed something then add LEDS to the end of that code to do that.
So you could type:
20 % RED
and the red bytes in the array should fill up with a value of 51. Well, it should work and the green and blue are similar but different offset (0 DO or 2 DO)
Actually that would factor to:
pub COLOR ( value offset -- ) rgbsz SWAP DO DUP I C! 3 +LOOP DROP ;
pub RED ( value -- ) 1 COLOR ;
pub GREEN ( value -- ) 0 COLOR ;
pub BLUE ( value -- ) 2 COLOR ;
Well when working with a new language/platform/style and complete dev environment I just skip "hello world" and go straight to a FAST FFT implementation. That is a sure way to flush out any "limitations" </sarc>
Thanks Peter for the hot runmod tips and byte code.
Yeah, I wasn't sure how to take that, jump in by starting with something that is really sub-microsecond and timing critical
The clever technique though is how little it took to get it to work, there is no big OBEX there, just a few lines of code, not enough to impress anybody, sorry
You had the solution before my Arduino IDE loaded, not fair. Mommy/Daddy Peter's not playing fair.
Ahh, that's alright David, we know how to give "curry in a hurry"
Every time I look at example code I just get headaches, normally it seems overly complicated and so verbose and set in cement. So I just look at the requirements and deduce suitable KISS methods. In this case regardless of how the data was to be manipulated at the high level, all it needed was the correct timing. Constraining that "driver" to 19 longs meant it could load in as a RUNMOD so all the rest of the stuff could be done at bytecode level after that.
I suspect however (from how I would design the chip) that bit to bit timing is actually more open than the tight one or zero bit timing, so when i get some to play with I will interact with them in this regard to find out what can be done.
I suppose if you were tackling the bit timing it might have been challenging but the high level stuff is something you can easily play with and you will probably have seen my other thread regarding this, and since it's your fault I expect you to apply yourself!
Also, I mentioned that the bit to bit timing for the chip is probably more relaxed than it seems to indicate in the datasheet as this is essentially a self-clocking shift register, something fairly easy to put together in hardware. So I look at a bit time as simply 3 phases: the clock phase, the data phase (with data sampling mid phase), and the gap phase. If it's self-clocking then the gap doesn't really matter except of course if you leave it too long it will sense it as a synch which is fair enough as it's only a single wire. So if that were confirmed with some actual hardware I probably would have only just written the driver at the high level although the transfer rate would only be half of what is possible with the RUNMOD helper module. Capisce?
NAMES: $59D0...7470 for 6816 (738 bytes added)
CODE: $0000...3C59 for 8633 (1893 bytes added)
CALLS: 0371 vectors free
RAM: 7543 bytes free
MODULES LOADED:
34F4: SDCARD.fth SD CARD Toolkit - 140626.1400
1900: EXTEND.fth Primary extensions to TACHYON kernel - 140905-173O
BOOT: EXTEND.boot
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
ok
TACHYON
Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
ok
--> FOPEN# <-- not found nd
https://docs.google.com/document/d/1a2j0thJWkBpulZiL4v7GukSL_utJouoau3ZDgPKEiIc/pub
so there is s.th. wrong -
could be line delay or paste error.
Where did you get your files from?
Check EASYFILE.fth for FOPEN# it should be defined there. - it is in the lastest version anyhow.
So kernel 2.4 is ready for the rest of the show then? I would think the best way would be to have binaries for V2.3 and Extend built for people just finding this thread, cut and paste the other modules as needed.