TACHYON Forth O/S -Fast, Compact, and Interactive with FAT32+FTP+WEB+TELNET+EMAIL

[Peter Jakacki]

Doesn't nesting like this save memory? Obviously not a lot in this case, but I'm trying to be as efficient as possible from the start so as I learn and as my projects become more complex, I've developed good habits..Nesting is, of course only after I've tweaked and verified, when I'm cleaning up and commenting my code for later interactions.

After I implemented your ORG recommendation ...

BUFFERS ORG
1         DS    wsgrn     --- 
1         DS    wsred     ---
1         DS    wsblu     ---
wsbytes   DS    wsdata    ---

If I tried

BUFFERS $800 ERASE BUFFERS pxlbytes + pxlbytes $FF FILL

it blanked out the data I was trying to preserve...I have packaged the whole thing into a module and have BACKUP'd the Prop. BUFFERS . returns the address of my ORG'd data ( wsgrn . = 7500, BUFFERS . = 7500)

...Is BUFFERS ORG the wrong way to setup the variables?

I'm also not seeing the advantage of ERASE then FILL. Is there one I don't see other than cleaning up pseudo-random data for possible later use?

The semicolon just after the fill compiles as an EXIT so the code that you have after that will not execute plus this is something you never do in any Forth although Tachyon does allow multiple entry points.

pub BLANK ( -- )     
  pub BLANKBUFF ( -- ) 
      BUF wsbytes $00 FILL ; <---------code will exit here because of the semicolon (it's an EXIT)     
     #10 us BUF SHOW ; <------- the code here never gets executed

Also remember that $00 compiles as a 2 byte opcode [BYTE] [00] whereas 0 is an opcode and compiles as a fast single byte opcode [0]. In this case it is neither here nor there but be aware of it if.

Once again I can't help you too much when I can only look through a keyhole, just post all the code. For instance you have wsbytes specifying the number of bytes for wsdata but I don't know what value that is. Then you have pxlbytes which is another value I don't know. However BUFFERS $800 ERASE is going to wipe everything for sure, is that what you want?

Try putting things like BUFFERS $800 ERASE on one line by itself and give it a comment so that you at least will know what you are trying to do, then put that BUFFERS pxlbytes + pxlbytes $FF FILL on it's own line with a comment. Be methodical and try talking to yourself as if you are explaining what you are doing to someone who is trying to follow along. As you verbalize your thoughts you will do as many of us have done and go "you idiot" or "of course, why didn't I see that before" etc.

BTW, ERASE is the same thing as 0 FILL.

[Chameleon]

It looks like you are over-thinking things a little as ORG and DS etc look after that stuff for you. The thing is that you can use this in one part of the code and then use it later and it still points to the next available area. But if you really want to know where it is just look in the org variable (lower-case). But you don't need to keep setting ORG, normally just once is fine.

The 10 us is redundant here, it was used at the end of a transmission to ensure a minimum gap period, that's all.

Now, it normally helps if I can see all your code rather than snippets but I'm wondering what you are trying to do by nesting a definition within a definition? Perhaps you copy and pasted without removing the ; after the FILL ?

pub BLANK ( -- )
    pub BLANKBUFF ( -- ) BUF wsbytes $00 FILL ;
    #10 us BUF SHOW ;

Doesn't nesting like this save memory? Obviously not a lot in this case, but I'm trying to be as efficient as possible from the start so as I learn and as my projects become more complex, I've developed good habits..Nesting is, of course only after I've tweaked and verified, when I'm cleaning up and commenting my code for later interactions.

After I implemented your ORG recommendation ...

BUFFERS ORG
1         DS    wsgrn     --- 
1         DS    wsred     ---
1         DS    wsblu     ---
wsbytes   DS    wsdata    ---

If I tried

BUFFERS $800 ERASE BUFFERS pxlbytes + pxlbytes $FF FILL

it blanked out the data I was trying to preserve...I have packaged the whole thing into a module and have BACKUP'd the Prop. BUFFERS . returns the address of my ORG'd data ( wsgrn . = 7500, BUFFERS . = 7500)

...Is BUFFERS ORG the wrong way to setup the variables?

I'm also not seeing the advantage of ERASE then FILL. Is there one I don't see other than cleaning up pseudo-random data for possible later use?

[Peter Jakacki]

Works fabulously! In efforts to be constantly wary to save vectors and bytes, I found an issue I don't understand...Can you see my error?

pub BUF ( -- ) wsdata wsbytes + ; 

pub BLANKBUFF ( -- ) BUF wsbytes $00 FILL ;

pub BLANK ( -- ) BLANKBUFF #10 us BUF SHOW ;

works perfectly, while

pub BLANK ( -- ) 
    pub BLANKBUFF ( -- ) BUF wsbytes $00 FILL ;
    #10 us BUF SHOW ;

does not.


Your mini tutorial was helpful, but one added question: Is there a way to keep track of what part of the buffers has been claimed? Since my data is started at BUFFERS, I need to increment the "buffer" area to keep from wiping out the data I want preserved...OR is there a better way to ORG so that I don't run into the same issue where data is being stored in code space?

It looks like you are over-thinking things a little as ORG and DS etc look after that stuff for you. The thing is that you can use this in one part of the code and then use it later and it still points to the next available area. But if you really want to know where it is just look in the org variable (lower-case). But you don't need to keep setting ORG, normally just once is fine.

The 10 us is redundant here, it was used at the end of a transmission to ensure a minimum gap period, that's all.

Now, it normally helps if I can see all your code rather than snippets but I'm wondering what you are trying to do by nesting a definition within a definition? Perhaps you copy and pasted without removing the ; after the FILL ?

pub BLANK ( -- )
    pub BLANKBUFF ( -- ) BUF wsbytes $00 FILL ;
    #10 us BUF SHOW ;

[Chameleon]

Since the RUNMOD function only requires the start address and count it is easy enough to have a blank area or any other area for that matter such as the tables in ROM but otherwise just feel free to use the BUFFERS area or part thereof.
Initially you could: BUFFERS $800 ERASE BUFFERS pxlbytes + pxlbytes $FF FILL

To blank all the LEDs: BUFFERS pxlbytes RUNMOD
To light em up: BUFFERS pxlbytes + pxlbytes RUNMOD

In fact rather than calling RUNMOD directly you should really have this:
pub SHOW ( address -- ) pxlbytes RUNMOD #50 us ;

So BLANK becomes pub BLANK BUFFERS SHOW ;

Works fabulously! In efforts to be constantly wary to save vectors and bytes, I found an issue I don't understand...Can you see my error?

pub BUF ( -- ) wsdata wsbytes + ; 

pub BLANKBUFF ( -- ) BUF wsbytes $00 FILL ;

pub BLANK ( -- ) BLANKBUFF #10 us BUF SHOW ;

works perfectly, while

pub BLANK ( -- ) 
    pub BLANKBUFF ( -- ) BUF wsbytes $00 FILL ;
    #10 us BUF SHOW ;

does not.

You can also define storage areas as constants with ORG such as:
BUFFERS ORG
pxlbytes DS pxldata
1 DS tempgrn
and so on to keep it all together without worrying about slamming into code.

Your mini tutorial was helpful, but one added question: Is there a way to keep track of what part of the buffers has been claimed? Since my data is started at BUFFERS, I need to increment the "buffer" area to keep from wiping out the data I want preserved...OR is there a better way to ORG so that I don't run into the same issue where data is being stored in code space?

[Peter Jakacki]

if I remember correctly there are 1k call vectors in the XCALL, YCALL, ZCALL, WCALL tables each 256 entries.
Aren't we at the limit now ?

Yes, you noticed, but it's all being taken care of. One of the main reasons I used vectors in the first place was so that Spin tool compiled bytecode kernel would play nice with bytes but not words, otherwise every single word would have to be broken up into high and low bytes with offsets etc. Doable, but such a pain. Secondly, using vectors meant that we could reduce a high-level call from 3 bytes (opcode+address) to 2 bytes where one of four opcodes each picks one of 256 16-bit vectors from the table.

So there is nothing to stop us from using 3 byte calls at a higher level on top of the kernel. I have implemented the CALL16 and getting back to modifying the BCOMPILE word so that it if it runs out of vectors for new words it will just compile a CALL16 opcode followed by the absolute address of the function it is calling. No big deal and at this level there is no real difference in code size as it is only the references to new unvectored words that take an extra byte.

Sometimes I feel like Harper from Andromeda, yeah baby, well at least when it all comes together and it works. When it doesn't then sometimes I feel like Harper from Andromeda.......IYKWIM

[MJB]

.STATS
Propeller .:.:--TACHYON--:.:. Forth V24141103.0500
Clock frequency = 80,000,000
NAMES: $70E0...74CD for 1005 (-1364 bytes added)
CODE: $0000...617C for 23951 (3091 bytes added)
CALLS: 0000 vectors free
RAM: 3940 bytes free

if I remember correctly there are 1k call vectors in the XCALL, YCALL, ZCALL, WCALL tables each 256 entries.
Aren't we at the limit now ?

[D.P]

Just created COMPACT and tested it all out which is all you ever need to worry about for now and you can even compact the dictionary as you go as it will detect whether it is a new or additional operation.

To test this out I loaded a full EXTEND.fth so it included the whole kit and kaboodle, loaded EPRINT, my hardware headers, SDCARD, EASYFILE and without trying to reclaim any headers as there is no need to I then loaded SDWORDS and had 1.4K free.
Ran COMPACT and ended up with 9.3K free.
Added W5200 and EASYNET and ended up with 1.7K
Ran COMPACT and finally still have 3.9K free even with all the EXTEND fluff and ALL the headers intact!


LISTWORDS Mounted SD Card

.STATS
Propeller .:.:--TACHYON--:.:. Forth V24141103.0500
Clock frequency = 80,000,000
NAMES: $70E0...74CD for 1005 (-1364 bytes added)
CODE: $0000...617C for 23951 (3091 bytes added)
CALLS: 0000 vectors free
RAM: 3940 bytes free

Whoa, 4K free, that is a giant tachyon / forth app since the kitchen sink has been loaded already.

[Peter Jakacki]

I will probably try to automate this as easily as possible but for the moment I am invoking operations manually to check it all. Right now I'm seeing if I can load up the full EXTEND.fth etc, compact the dictionary after EASYFILE, load EASYNET, and compact again. In fact I may just create the word COMPACT to do this automatically so it works out whether it's a new dictionary or an addition etc.
<snip>
Newer method may just use the one word COMPACT and then manually BACKUP in case there is an ooops!.

Just created COMPACT and tested it all out which is all you ever need to worry about for now and you can even compact the dictionary as you go as it will detect whether it is a new or additional operation.

To test this out I loaded a full EXTEND.fth so it included the whole kit and kaboodle, loaded EPRINT, my hardware headers, SDCARD, EASYFILE and without trying to reclaim any headers as there is no need to I then loaded SDWORDS and had 1.4K free.
Ran COMPACT and ended up with 9.3K free.
Added W5200 and EASYNET and ended up with 1.7K
Ran COMPACT and finally still have 3.9K free even with all the EXTEND fluff and ALL the headers intact!


LISTWORDS Mounted SD Card
Media mounted as 71CC.0203 mkfs.fat WIDGET FAT32 Cluster size = 4,096 Sectors = 4,512

0000: @gateway @sip @mac @PAD @CNT @SCK @SCL @rtc @FAT @ATR @CMS @RCD
0001: !PCB !WIZ autosend ANDN AVAR ansi ATN? ATN@ ATN! !ADC ADC@ APIN
0001: !PCB ACMD !SDWORDS
0002: BYTE base BELL BYTE BITS BOLD BPIN boot
0003: CON] CASE contimer #CONNECT CDUP cwd$ CASE COG! COG@ CALL C@++ CONSTANT
0003: CNT@ CON] CTRA CTRB COMPARE$ #adc CTR@ CTR! COLD CLUSTER@
0004: dataport DROP DIRA DIRB DUMP DUTY DAC! date days DAY@ DAY! dir$
0004: DIR? DIR! dictsect dict
0005: ELSE eNET EMIT ELSE EXIT ECHO ESC? ESC[ ENQ! ENQ@ EERD ERRORLED
0005: EASYFILE.fth
0006: FILE &TIMEOUT &CON FlushSkt FEAT FREE FILL FRQA FRQB FIND &TR1 &TE1
0006: &TR2 &TE2 FILE fats file FREM fkey FGET FPUT FCREATE$ FRUN
0007: GETFNAME GET$ GRAB
0008: HTTP HEAD (CREATE) HERE here HOLD (.") (OPCODE) HIGH HOME (VA) (CLKSET)
0008: HELP (FORGET) HEX: (ls)
0009: ifconfig IDLE I2CSTART I2C! I2C@
000A: JUMP
000B: KOLD KEY@ KEY! KEEP +HEX +NFA +SDWORDS
000C: LEDS LOOP LREADSKT LIST LEN$ LOOP LONG LONGFILL LIKE leds LEDS
000D: myGW myIP mySN MDTM MYOP MASK mod2load MID$ matchstr MUTE
000E: .IPX .IP1 .@SKTBUF .PTR .NET .SOCKETS nettimer .BYTEDEC .IPD NFA' NOTFOUND .DEC
000E: .VER .HEX NEXT NOOP .NUM .MODULES .PIN .MAP .LAP .AUTORUN .DAY .ASMONTH
000E: .FAT .ATR .DIR NFA>SECT
000F: oui2 OVER OUTA OUTB
0010: PASS PORT PASV PRIVATE] PIN! PIN@ PHSA PHSB PINLOAD? PWM% PWM! PCB$
0011: QUIT
0012: READYLED RNFR RNTO RETR REST 2DUP REVECTOR RS232LED RS485LED READYLED RES@ rsvd
0012: root
0013: SET? SKT@ sDIP sPRO sCONNECT sSENDMAC sCLOSED? sDISCON? skt$ SYST SENDFILE SIZE
0013: STOR SET? STOP SWITCH>< SWAP SPR! SQRT SARX SDERRLED SDBSYLED sdwr sdrd
0013: sdhc SD2@ SD4@ SDRD SDWR sect/fat SPLITDEC SDSEARCH
0014: TRUE THEN txwr type TYPE TERMINAL TASK THEN TRUE TYPE TASKREGS time
0014: TIMEOUT? timerstk timerjob TIMERJOB tval term
0015: USER ukey unum UNSMUDGE udir
0016: VCFG VSCL VCLS
0017: WAITSEND word WKEY WORD WATCHDOG WRITEHEX
0018: XSHR XADR
001B: [CON [WS2812] [PWM32!] [PRIVATE [CON [C,] [W,] [EPRINT]
001C: <CR>
001D: =dtk
001E: >PFA >VEC >F83
001F: ?FTP ?CONTENT ?LED ?EASYNET ?DUP
0020: @BASE @txwr @ @HATR @MOSI @MISO @FILE @ROOT @BOOT @FEXT
0021: !TXWR AUTO! ALLOCATED ALLOT AGAIN ! ALIAS ALIGN ANSI? A ALARM !LEDS
0021: !SDIO
0022: BREAK BREAK BCOMP " BEGIN BYTES BDUMP blksz B BCD++ byte/sect
0023: CONIO contd COMMA codes # COGID CMOVE CLOCK CONIO CTYPE COPY$ CALL$
0023: CountDown card? CARD? cache
0024: DEBUG DEPTH DISCONNECTED? delim DEBUG DEPTH DELTA DUMPL DUMPW DUMPA DATE@ DATE!
0024: DATE@ DATE! dboot
0025: ERROR ERASE ENDIF EMITS % ERSCN eeadr ENDRD ESAVE ELOAD eebuf ECOPY
0025: EFILL eFILE
0026: &RECV fsave flags FALSE &WNDO &WNCS &WNCK &WNDI &IOCS &SFCS &SDCS &SDDO
0026: &SDCK &SDDI FILE# &sdto FLUSH fat32 fboot file$ FILE$ FILE@ fread fstat
0026: FPUTB FILE> FOPEN FLOAD
0027: ' getsz '
0028: ( HDUMP (KEY) ( (WAITPNE) (WAITPEQ) (NULLOUT) (rnd) HYPOT (SEP) (BDW) (ESC)
0028: (COGINIT) (RECLAIM) (MAP) hexch (cat) (DIR)
0029: I IPRAW INTS@ IFDEF I IMMEDIATE I2C!? IDUMP INFO@
002A: *end* * J
002B: KEEPALIVE +CALL +LOOP + K +CHAR +DIR!
002C: LREAD LSEND LCKEY ledon lines , LEMIT LONGS LEAVE LBIT! LOCAL
002C: LEFT$ lpace lscnt LISTWORDS
002D: MOUNT - modloaded MASKS MASK? MATCH mount MOUNT
002E: names . .LONG .WORD .BYTE navar .HEAD .DECX .ADDR NULL$ NORMALIZE .ATRS
002E: .NAME .SPRS .PINS .HHMM .TIME .DATE .TIME .DATE .CARD .LIST .FILE
002F: /
0030: 0 PLAIN PPPoE PORT! pass$ 0EXIT 0 Published PRINT PINS@ PLAIN PWM.START
0030: PROCESS_TOKEN parts
0031: 1 QUIET 1
0032: RETRYTIME RXSIZ RNFR$ RESET 2 2DROP radix RADIX RI232 RDRTC READFAT32 RCDSZ
0032: ROMSZ
0033: 3 SHL16 sMODE sCMD! sINTS sSTAT sPORT sDHAR sOPEN sSEND sSENDKEEP sRECV
0033: sCLOSING? sendtimer SCRUB SPACE SPIRD SPIWR 3DROP 3 SWAPB STRIP SERIN SI2C!
0033: SI2C@ SDBUF SDCLK STAT@
0034: 4 TXSIZ tasks 4 TIMES TABLE TASK? TIMER ttint TIME@ TIME! TIMERTASK
0034: TIME@ TIME!
0035: UPORT user$ ufind uemit UNTIL U/MOD UNPRIVATE UPPER uboot ucard
0036: vread
0037: W5200.fth wMODE WCOLD WHILE WORDS WRRTC
0038: 8 8 XSAVE XLOAD XADR!
003A: :
003B: [COMPILE] ; { [COMPILE] [SSD] { ;
003C: < \ < | \
003D: = } =
003E: > ~ >CHAR > ~ ^ >CSTR >FILE
003F: ?EXIT ?SENDPOLL ?SEND ?HTTP ?EXIT ?DICT
0040: @wcold @ports @NAMES @X @. @WRFLG @FNAME @CTIME @CDATE @ADATE @FTIME @FDATE
0040: @FCLST @FSIZE @FREAD
0041: !WIZIO !WIZIP ADCBUF APPEND.BLK APPEND
0042: BUFSIZ BINARY BL BOUNDS BACKUP BLKSIZ blklen
0043: C@ C! CR CLOSED CONNECTED? CREATE CREATEWORD create #S #> CR C,
0043: COGREG CMPSTR C! C@ C~ consav CURSOR CLKSET CE1372.fth CTS232 CLUST>SECT
0044: DO disreq DISCONNECT digits DO DOUBLE DS dwidth $! $= DTR232 DSR232
0044: DCD232 diradr dirbuf
0045: eW5200 errors EXTEND.fth %% ERLINE ERASE$ EEPROM E@ E! ESAVEB EE EPRINT.fth
0045: eprint EPRINT extbuf
0046: FTPDAT FTPMSG FORGET FIXBIN fatptr fname$ FSIZE@ fwrite FINPUT FCLOSE FOPEN# FOPEN$
0046: FDATE! FTIME! FSTAMP
0047: GO '' GETRND
0048: (RETR) (STOR) (EMIT) (.NUM) HZ hexbuf hexptr hexadr hexflg (SDWR) (SDRD) (.DIR)
0049: IF IFNDEF IF INPUTS INVERT IN IX indent
004B: +! ++ +TIMER +CACHE
004C: LANLED L! L@ LWRITE LANKEY LCEMIT LANCON ledcnt LANSKT LOOKUP LSTACK L>
004C: locals LANLED LOGSZ? ls
004D: ms MACRAW ms -1 -- m@ M@ MATCH? MY ma
004E: NETMAN NUMBER .S ." NEGATE .INDEX .TASKS .BLOCK .STATS .BOOTS .DTFMT .FYEAR
004E: .FDATE .FTIME .FNAME .UTIME .FILES
004F: ON OUTCLR OUTSET OR ON OK ok // /ROUND OPCODE
0050: PRINT" prompt PRINT$ 0< 0= PUBLIC PRINT" P@ P! PINSET PINCLR PININP
0050: PLLDIV pwmtbl PULSEWIDTH PRINT"
0051: 1+ QW 1- 1+ 16 QHYPOT QW QWORDS QV
0052: REBOOT RXREAD RETRYS REBOOT REPEAT 2- 2+ RUNMOD R> 2* 2/ RETURN
0052: RADIX> RCFAST RCSLOW RIGHT$ RTS232 RXD232 rtcbuf RW RENAME
0053: SPIWRW socket SOCKET sDPORT sSSIZE sRXMEM sTXMEM SUBNET sCLOSE sINACTIVE? sktbuf switch
0053: SEARCH STACKS SWITCH SPIRDX SPIWRX SPIWRB SHRINP SHROUT STREND SETMOD SPACES STRING
0053: second SEROUT SI2C!? SETPWM SDCARD.fth sdinfo sdpins sdsize sdbusy sector scanch SDBUSY
0053: SDPINS SDERR? SDDAT! SECTOR SD sect/clust serial
0054: TXREAD txtime txsize TELNET TO timers TXD232
0055: un UpdateTXWR U. us U< U/ UNLOOP U> U! U@
0056: vwrite VC VP VOLTS@ VirtualRTC
0057: W! WBUFSZ WITHIN W! W@ WORDS: W~ WWORDS WRESET WPWRDN wrflgs WRSECT
0058: XCALLS X1 X2 X3 X4 XY X@ X!
005B: [NFA'] [WS2812CL] [PLOT] [SDWR] [SDRD] [SPIO] [~
005C: <CMOVE <# || <> << |< <=
005D: ]~ ]~ == =>
005E: >UPPER >DIGIT >L >R >B >N >RADIX >W ~~ >> >|
005F: ?CTRLS ?SDTIMEOUT ?MOUNT ?WRDCT
0060: @subnet @SOCKET @TXBASE @SKTBUF @CE @SPISCK @EE @EEWAIT @FCLSTH @DIRBUF @FWRITE
0061: AND !SP !TXBUFS aUTORUN autorun !SP !RP ABS AND ADO APPEND$ any
0061: ANY atr ackI2C@ AUTORUN !SD ACTIVE?
0062: BYE blkpoll BLKSEND BUFFERS baudcnt BCA BRANCH> B>W B>L bdw BCD>DEC
0063: C+! CON C~~ COMPACT #SOCKET CONNECT constat #ftpmin #ftpmax CWD CONTENT CONSOLE
0063: COGINIT CLS COGDUMP CLR C+! CLKFREQ CREATE$ CON COGREG! COGREG@ C++ C--
0063: C~~ CNT COS COGINIT CLK ctr CTR CTRMODE COUNTUP CONBAUD #EP cid
0063: csd crc CMD clshift cat COMPACT
0064: DISCARD DISCREQ DISCARD DECIMAL DUP DS+ DPL dst DUMPROM DEC>BCD DIR dictflg
0065: END EASYNET.fth ECHOREQ EASYNET EXECUTE EC! EC@ EW! EW@ EVERIFY END EXTEND.boot
0065: eSD eof
0066: filesel &SENDOK &DISCON FTP FINDSTR FOR FRQ filesel fatname FC! FOUTPUT FRESHEN
0067: GATEWAY GETPAGE GET GETWORD GETLINE
0068: (LSEND) HEX ( (WORDS) (STRIP) HEXLOAD (SLIST) (.LIST)
0069: INTMASK INA INB I2CPINS I2CSTOP
006B: keypoll keypoll KEY KHZ
006C: LC! LW! LC@ LW@ LANSEND LANEMIT LAN LITERAL lastkey LOADMOD LAP LOW
006C: L>W LSP LOCATE$ LISTKEY LED LEDREG! LOADROM LOADIMG
006D: --- MAC -NEGATE --- MODULE: MIN MAX MOD mc@ mw@ MC@ MW@
006D: MODPINS MHZ MARKER? -FERASE
006E: .IP .SOCKET netflgs NFA>CFA .STACKS NOP NOT NIP ... NULLOUT .RETSTK .I2CBUS
006E: NCO .TIMERS .DT .SW .DT .SD nfasect
006F: OFF OUTPUTS OFF OUT org ORG ocr oemname
0070: pri PRIVATE pub PWD pri pub 0<> PRIVATE PFA>NFA PAR PLL pwmfreq
0070: pwmmask PWMCOG.TASK PULSEWIDTHS PCB
0072: RXSIZE@ RXWRITE RXBASE0 RXMASK0 RESTART READBUF REG REV ROR ROL ROT RELEASE
0072: RND RAM REVERSE RUN runtime RECLAIM rootdir RENAME$
0073: seconds SKT SIP sLISTEN sDISCON sESTAB? sCONNECTED? SetPORT SPINNER SWITCH= SWITCH@ SP!
0073: SPIWR16 3RD SET SHL SHR SPR SIN SQR SPIPINS SETPINS SAR seconds
0073: SERBAUD SCL SDA SETPWMS SETPWMW sectcrc SD@ SD! scancnt scanpos sdtimer SDRDBLK
0073: sectors SAVEROM SAVEIMG SDWORDS.fth SDWORDS
0074: TXFREE@ TXWRITE TCP TXBASE0 TXMASK0 TACHYON 4TH TAB tid TIMEOUT
0075: UDP UIP UNKNOWN UM* U.N
0076: VER volname
0077: wizpins WIZ WAITCNT W+! WAITPNE WAITPEQ W>B W>L W++ W-- W~~ WAITKEY
0077: wdt
0078: XOR XC@ XC! XW@
007B: ['] [PWM32] [SPIOD] [ESPIO]
007C: \\\
007E: >|RCDSZ
007F: ?SDCARD ?BACKUP ?TELNET ?DISCONNECT ?NEGATE ?BACKUP ?SDCARD ok
.STATS
Propeller .:.:--TACHYON--:.:. Forth V24141103.0500
Clock frequency = 80,000,000
NAMES: $70E0...74CD for 1005 (-1364 bytes added)
CODE: $0000...617C for 23951 (3091 bytes added)
CALLS: 0000 vectors free
RAM: 3940 bytes free

[Peter Jakacki]

So do we need a "--- convert the dictionary in RAM to a sorted and indexed dictionary in SDFS in the WORDS.DCT file (128K)" or a 64KB file as stated in this post.
Also at the bottom of SDWORDS.fth you talk about loading all the goodies except the app and running SDWORDS then initializing with !SDWORDS.
So step one: create a 64 or 128K blank file named WORDS.DCT on the SDCard
Two: load up tachyon the way you want your kernel upto the application you are building/working on.
Three: Run SDWORDS from the SDWORDS.fth module
Four: BACKUP
Five: initialize your rebooted Tachyon sessions with !SDWORDS to use the dictionary interactively and/or compile your app
Six: you are able to simply forget your app or reboot for development ease
Seven: backup again after your app is ready
Eight: now you have so much code space you are bound to have even more fun

Is this about right?

I will probably try to automate this as easily as possible but for the moment I am invoking operations manually to check it all. Right now I'm seeing if I can load up the full EXTEND.fth etc, compact the dictionary after EASYFILE, load EASYNET, and compact again. In fact I may just create the word COMPACT to do this automatically so it works out whether it's a new dictionary or an addition etc.

So steps at present are:
1. Load in SDWORDS.fth on a system that has EASYFILE already loaded.
2. Ensure you have a file called WORDS.DCT with at least 64KB available (only uses 64KB)
3. Run SDWORDS which will populate WORDS.DCT sectors with those words as they are indexed
4. When you want to release the old dictionary in RAM then run !SDWORDS which will init the cache, reset the dictionary to the start of cache, and revector the SEARCH method.
5. BACKUP after !SDWORDS if you want to lock all this in now. Run .STATS to see how much RAM is now available.
6. Load app normally and this can also be forgotten normally as well. Only way to forget compacted stuff at present is to do a COLD and start again.
7. Forth Freaking Frolicking Fun

Newer method may just use the one word COMPACT and then manually BACKUP in case there is an ooops!.

BTW, I still have to add an FCREATE to EASYFILE to allow new files to be created in the system although I had been trying to avoid any FAT32 housekeeping on the embedded side previously.

[D.P]

So do we need a "--- convert the dictionary in RAM to a sorted and indexed dictionary in SDFS in the WORDS.DCT file (128K)" or a 64KB file as stated in this post.
Also at the bottom of SDWORDS.fth you talk about loading all the goodies except the app and running SDWORDS then initializing with !SDWORDS.
So step one: create a 64 or 128K blank file named WORDS.DCT on the SDCard
Two: load up tachyon the way you want your kernel upto the application you are building/working on.
Three: Run SDWORDS from the SDWORDS.fth module
Four: BACKUP
Five: initialize your rebooted Tachyon sessions with !SDWORDS to use the dictionary interactively and/or compile your app
Six: you are able to simply forget your app or reboot for development ease
Seven: backup again after your app is ready
Eight: now you have so much code space you are bound to have even more fun

Is this about right?

[Peter Jakacki]

The problem: A fully loaded networked system only has a couple of KBs of RAM left for an application even after reclaiming memory. Although most of the dictionary is not needed at runtime, it is needed to compile the application, so the 10K it takes up cannot be freed before an application is compiled which results in a catch-22 situation.

The proposed solution:
Move the dictionary out of RAM into a file in such a way that words can be found quickly and easily, preferably at normal source code compile speeds.


The result:
The dictionary optimization code is up and running and fully integrated into Tachyon now. It sorts and stores the dictionary into indexed sectors so that for any word there is an indexed sector where the valid word will be found along with it's attribute and code header. The 7-bit index is generated from 5 lsbs of the first character plus 2 lsbs of it's count and this 7-bit index is used to open a 512-byte sector within the 64KB WORDS.DCT file.

This method is fast and even if it needed to read in a sector for every word it only takes around 3ms per word. However a cache is implemented which pushes the latest header into the start of the cache including any matches in the cache itself to keep it fresh. So before a sector is indexed and read in, the cache is searched for a match first, which after it starts to fill up will end up scoring more and more hits, especially since it keeps it's hits fresh. The oldest words that get pushed or partially pushed off (variable lengths) the end of the cache become invalid anyway due to a null termination area.


This works but that still leaves the problem of adding new words to the dictionary easily. Since the normal Tachyon dictionary grows downwards in memory it becomes a simple matter to say that the start of the cache is the default start of the dictionary. So instead of searching the "cache" Tachyon will use it's normal method of searching from "names" (pointer to the dictionary) and initally it's the same thing. Now as new defintions are created they are prepended to the "dictionary" which is now a combination of the new words growing downwards in memory but still cascading into the cache. It just works, and really well at that.

To test it out properly I loaded my datalogging application onto a full system with EASYFILE and EASYNET running. Normally even after reclaiming all the private headers (about >2KBs worth) there is no room left after this and no easy way to add more to it. Now I leave all the private headers intact, have the application fully loaded in and there is around 6K free.


You would also think that looking up each word from SD might be slow but the combination of indexed sectors, cache, and dictionary let me load my application in without any extra delays.

This paves the way for adding even more features to what is essentially a little 32KB microcontroller. It's now possible to include VGA buffers and many other things including the assembler etc.

<link to SDWORDS.fth>

Out of interest here's a MAP listing with comments which prints out a packed byte for every xN bytes, some "bytes" are comprised of 16 or 256 bytes etc. However the main area of interest is in red where even with the whole dictionary intact and networking and application we still have almost 6K free. In terms of Forth code that's a whole continent.


.MAP
REGISTERS x16 (Forth registers)
0024: .. .. .. .. 02 .. .. .. .. .. 01 .. 04 05 01 ..

VECTORS x64 (all high level defs have a 16-bit vector)
0124: 11 11 14 11 12 0D 18 0E 14 13 14 13 15 17 14 13
0524: 14 15 14 15 13 12 15 18 19 18 18 18 18 16 1A 0D
KERNEL CODE x256 (high level bytecode defintiions)
0928: 63 63 88 88 6A 64 5B 68 71 64 79 64 58 73 77 42
CODE x256 (EXTEND.fth + UTILITES + EASYFILE + EASYNET + APPLICATION)
18C6: 64 5C 54 5B 72 6B 6D 64 66 67 6C 84 51 6A 60 6D
28C6: 5D 6B 80 49 23 6A 70 6E 35 4B 3E 65 43 64 5B 5E
38C6: 75 72 72 55 68 96 73 60 78 73 6D 61 88 7C 84 7B
48C6: 67 85 6D 74 65 80 74 7C 6E 77 58 69 81 66 41 ..
SPARE @576B: for 5,779
DICTIONARY x256 (new words added after converting dictionary to file)
6DFE: 6A
(cache and private dictionary sector sit in here = 1K total)
BUFFERS x64 (There are four 512-byte sector buffers for four open files in EASYFILE)
7500: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
7900: .. .. .. .. .. .. .. .. 11 15 19 1D 21 25 29 2D

RX BUFFER x64 (Serial receive buffer - laid down over the PASM image)
7D00: 0E 0C 0C 0C 0E 0D 0F 0E
HUB STACK x16
7F60: .. 01 01 .. .. .. .. .. .. ..

[Peter Jakacki]

Hej Peter!

Thanks for the 12 34, now I can test my pub's.
When I use . on the terminal with nothing on the stack I get -1 back, I understand this. But when I use . in my pub same condition, I get 1 back, this confused me a bit.
With 12 34 I am back on track.
But the next little pub confuses me a bit.

pub ad CR 0 DO I . ."  " LOOP CR ;

  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630

  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
Clock frequency = 80,000,000
NAMES:  $5C89...745E for 6101 (3715 bytes added)
CODE:   $0000...34EC for 7447 (7212 bytes added)
CALLS:  0450 vectors free
RAM:    10141 bytes free

MODULES LOADED: 
18C0: EXTEND.fth          Primary extensions to TACHYON kernel - 141027-1000
BOOT: EXTEND.boot

----------------------------------------------------------------
pub ad CR 0 DO I . ."  " LOOP CR ;  ok
  ok
15 ad 
0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 
 ok
16 ad 
0 1 2 3 4 5 6 7 8 9 A B C D E F 
 ok
17 ad 
0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 15 16 
 ok

All in hex, 15 and 17 I understand, but 16 I do not.
Am I too sluggish on the uptake.

15 . 15 ok
16 . 10 ok
17 . 17 ok

Maybe you better check all sequences up to 4294967296? Do you want to be a beta tester?

16 is one of the predefined fast constants just like 0 1 2 etc but unlike 0 to 9 which are the same in hex or decimal there is this little problem that you have come across. But I had decided by then when I had added it to the kernel that my hex numbers were all going to be prefixed to avoid any confusion at all. So if I meant 16 in hex then I would say $16 and indeed it's a force of habit now that all hex numbers I type in are prefixed.

Now I have an additional leaning towards leaving the system in decimal mode as I can easily control radix of input and output without affecting everything globally. The variable base is a very nice feature of Forth but it also creates problems too which is why I have ways to force recognition of numbers. So my source code will always have hex numbers prefixed with $ but I have used # to make sure my decimal numbers are decimal but maybe if I leave the default base set to decimal then these won't need to be prefixed and if you see 16 just as it is, then it really is 16 decimal.

As for printing numbers there are plenty of support words for that including the very flexible .NUM word which accepts a control word to specify digits, base, separators, leading blanks or zeros etc.
Actually that brings up another point, the traditional dot that's used in Forth to print a number is a bit too terse in source code form as a tiny dot gets lost whereas during debug it's quick and easy. That's why I have aliases for many of these words such as PRINT and PRINT" so that these words stand out clearly in source code rather than . and ." so perhaps .NUM needs an alias too, PRINTNUM.

[MJB]

I can reproduce it.
interrestingly
26 . 26 ok is correct
just trying to figure out the kernel code to see how this can happen

got it
16 is one of the fast constants like -1, 0,1 ... 8,16, BL for 32, FALSE = 0, OFF = 0, ON = -1, TRUE = -1
it is intercepted and handled independently of BASE setting.
so definitely 16 independently of the base set is #16 $10

so better set default base to 10 and mark all hex numbers clearly with $.

maybe it should be renamed to #16 - can still be a fast constant.

DECIMAL  \ sets input and output base
15 . 15 ok
16 . 16 ok
#16 . 16 ok
$10 . 16 ok
.S  \ prints the stack in both DECIMAL and HEX  always good to cross check

[frida]

Hej Peter!

Thanks for the 12 34, now I can test my pub's.
When I use . on the terminal with nothing on the stack I get -1 back, I understand this. But when I use . in my pub same condition, I get 1 back, this confused me a bit.
With 12 34 I am back on track.
But the next little pub confuses me a bit.

pub ad CR 0 DO I . ."  " LOOP CR ;

  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630

  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
Clock frequency = 80,000,000
NAMES:  $5C89...745E for 6101 (3715 bytes added)
CODE:   $0000...34EC for 7447 (7212 bytes added)
CALLS:  0450 vectors free
RAM:    10141 bytes free

MODULES LOADED: 
18C0: EXTEND.fth          Primary extensions to TACHYON kernel - 141027-1000
BOOT: EXTEND.boot

----------------------------------------------------------------
pub ad CR 0 DO I . ."  " LOOP CR ;  ok
  ok
15 ad 
0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 
 ok
16 ad 
0 1 2 3 4 5 6 7 8 9 A B C D E F 
 ok
17 ad 
0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 15 16 
 ok

All in hex, 15 and 17 I understand, but 16 I do not.
Am I too sluggish on the uptake.

15 . 15 ok
16 . 10 ok
17 . 17 ok

[Peter Jakacki]

pub aa ( -- ) \ test
$CC DUP . CR
    #8 FOR
        DUP 1 AND .
        #1 SHR
        NEXT
    \    DROP
CR
. CR
;
pub ab ( -- ) \ test
$CC DUP . CR
    #8 FOR
        DUP 1 AND .
        #1 SHR
        NEXT
        DROP
CR
. CR
;



.VER 
  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
 ok
aa CC
00110011
0
 ok
ab CC
00110011
1
 ok

Why is the last print giving a "0" in aa, and giving a "1" in ab?
I would expect the stack to be empty.

These two definitions can be reduced to simple one liners like this:

$CC DUP . CR 8 FOR DUP 1 AND . 2/ NEXT CR . CR

$CC DUP . CR 8 FOR DUP 1 AND . 2/ NEXT DROP CR . CR

The trouble is that at the end of the second test you are dropping the remainder of $CC which is now 0 off the stack and telling Forth to print a number from an "empty" stack except there is always a "top of stack". If I paste in these one liners this is what I get.
$CC DUP . CR 8 FOR DUP 1 AND . 2/ NEXT CR . CR CC
00110011
0
ok
ok
$CC DUP . CR 8 FOR DUP 1 AND . 2/ NEXT DROP CR . CR CC
00110011
1
ok

Now before I run it I pad the stack with two numbers 12 34 then do it again I get:
$CC DUP . CR 8 FOR DUP 1 AND . 2/ NEXT CR . CR CC
00110011
0
ok
ok
$CC DUP . CR 8 FOR DUP 1 AND . 2/ NEXT DROP CR . CR CC
00110011
34
ok

So you can see there is nothing mysterious it's just you are operating outside of defined parameters and I forego a lot of this "stop everything and report error code mumbo-jumo" stuff which while fine on the testing bench only disrupts a system which could otherwise continue operating normally without downtime.

TIP: There is never a need to prefix a # to single digits 0 to 9 as these will always be decimal but as a tip you could leave your system in DECIMAL mode and only prefix the hex and binary numbers. Also 2/ is more efficient than 1 SHR.

Also there is no difference in TF interactive mode and compile mode, it always compiles, so you can use your loops and conditionals without having to create a definition or use "special" forms of those words as is common in traditional Forths.

[frida]

pub aa ( -- ) \ test
$CC DUP . CR
	#8 FOR
		DUP 1 AND .
		#1 SHR
		NEXT
	\	DROP
CR
. CR
;
pub ab ( -- ) \ test
$CC DUP . CR
	#8 FOR
		DUP 1 AND .
		#1 SHR
		NEXT
		DROP
CR
. CR
;



.VER 
  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
 ok
aa CC
00110011
0
 ok
ab CC
00110011
1
 ok

Why is the last print giving a "0" in aa, and giving a "1" in ab?
I would expect the stack to be empty.

[Peter Jakacki]

With this strategy (first suggestion from the previous thread), &GPGGA wierds out when one of the data fields is blank/NULL, such as "$GPGGA,123519,,,,1,08,0.9,545.4,M,46.9,M,,*47"

...Of course, this isn't a perfect NMEA sentence but is similar to what the GPS will send when it hasn't yet calculated a location fix. "Full postfix" treatment isn't possible while $GPGGA is still interpreted as $A, like #PIN4 is interpreted as #4.

In $GPGGA, there are two fields (altitude / height above geoid) which are measured in Meters, but the postfix above treats any data followed by "M" as altitude

--I've been mulling around with the idea of buffering an NMEA sentence at 4800 baud, stripping the "$" from the sentence identifier, replacing ",," with ",0," and then resending the corrected stream at 19200 baud, and handling the sentence postfix. Resending at 19200 baud should be able to fit between the sentences if your GPS is sending $GPGGA, $GPRMC, $GPGSA and $GPGSV at 1Hz. Certainly not the most elegant strategy, but seems to be a small-space solution to the above mentioned issues, within the small part of my world I control.

Peter's postfix is certainly the fastest and most code-efficient approach, but has a couple of issues off the shelf. I'm certainly looking for the fastest route from what the GPS actually sends to what he initially proposed. I'm not trying to criticize, but want to keep jay-t (a newbie like me) from pulling his hair out over a couple of critical and already identified issues. I thought I was doing good with a three-page method to accomplish what Peter came so close to accomplishing in ten lines.

Since the KISS just uses the comma as it would a space then it's just empty space to Forth but there's an easy fix for the empty CSV value problem and as always it's only a couple of lines of code if that. This little routine should work as it remembers the last character and checks for a double comma in which case it returns with a "0" instead and forces the second comma back into the stream with a KEY!.

BYTE lastgps
pub GPSKEY
    rxdgps SERIN DUP "," = lastgps C@ "," = AND        --- is this the second comma?
      IF KEY! "0" THEN            --- force it for next time but return a 0 now
    DUP lastgps C!
    ;

[Chameleon]

That's not really a problem as nulls are filtered out in normal KEY input so it doesn't matter how many you get, they just don't appear in a normal ASCII stream in Tachyon. Yes it is possible to read a null if you wanted to but the only reason why is because it would be part of a file transfer protocol or something. So don't worry about those nulls, I assure you, this NMEA stuff is child's play, there are so many ways to do it, and you can have fun with all of them. The thing is not to hold back from doing anything because of overthinking, there's enough of that on this forum!

LONG lat,lon,alt
LONG sum,horz,sats,fix,utc

: S    NEGATE
: N    lat ! ;
: W    NEGATE 
: E    lon ! ; 
: M    alt ! ; 

: ?GPS        word C@ "*" = IF word 1+ NUMBER DROP sum ! THEN    ;

: &GPGGA    horz ! sats ! fix ! utc ! prompt W~ ;
: GPGGA        DECIMAL ' ?GPS unum W! ' &GPGGA prompt W! ; IMMEDIATE
"," delim C!

\ our sample data
GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

\ report what we found
lat @.
lon @.
alt @.
sum @.
horz @.
sats @.
fix @.
utc @.


{ which looks like this:
lat @. 4807038 ok
lon @. 1131000 ok
alt @. 469 ok
sum @. 47 ok
horz @. 9 ok
sats @. 8 ok
fix @. 1 ok
utc @. 123519 ok
}

With this strategy (first suggestion from the previous thread), &GPGGA wierds out when one of the data fields is blank/NULL, such as "$GPGGA,123519,,,,1,08,0.9,545.4,M,46.9,M,,*47"

...Of course, this isn't a perfect NMEA sentence but is similar to what the GPS will send when it hasn't yet calculated a location fix. "Full postfix" treatment isn't possible while $GPGGA is still interpreted as $A, like #PIN4 is interpreted as #4.

In $GPGGA, there are two fields (altitude / height above geoid) which are measured in Meters, but the postfix above treats any data followed by "M" as altitude

--I've been mulling around with the idea of buffering an NMEA sentence at 4800 baud, stripping the "$" from the sentence identifier, replacing ",," with ",0," and then resending the corrected stream at 19200 baud, and handling the sentence postfix. Resending at 19200 baud should be able to fit between the sentences if your GPS is sending $GPGGA, $GPRMC, $GPGSA and $GPGSV at 1Hz. Certainly not the most elegant strategy, but seems to be a small-space solution to the above mentioned issues, within the small part of my world I control.

Peter's postfix is certainly the fastest and most code-efficient approach, but has a couple of issues off the shelf. I'm certainly looking for the fastest route from what the GPS actually sends to what he initially proposed. I'm not trying to criticize, but want to keep jay-t (a newbie like me) from pulling his hair out over a couple of critical and already identified issues. I thought I was doing good with a three-page method to accomplish what Peter came so close to accomplishing in ten lines.

[Peter Jakacki]

Just a couple of gotcha's here...I've been looking into NMEA interface for a bit now, but on a back burner. Note that NMEA sentences permit nulls in the sentences. Peter's first suggestion (the thread MJB referenced) doesn't handle these nulls well, placing data in the wrong memory locations.

That's not really a problem as nulls are filtered out in normal KEY input so it doesn't matter how many you get, they just don't appear in a normal ASCII stream in Tachyon. Yes it is possible to read a null if you wanted to but the only reason why is because it would be part of a file transfer protocol or something. So don't worry about those nulls, I assure you, this NMEA stuff is child's play, there are so many ways to do it, and you can have fun with all of them. The thing is not to hold back from doing anything because of overthinking, there's enough of that on this forum!

[Chameleon]

here was some discussion about a NMEA parser in TACHYON

http://forums.parallax.com/showthrea...=1#post1253073

Just a couple of gotcha's here...I've been looking into NMEA interface for a bit now, but on a back burner. Note that NMEA sentences permit nulls in the sentences. Peter's first suggestion (the thread MJB referenced) doesn't handle these nulls well, placing data in the wrong memory locations.

[MJB]

Is there already a NMEA receive module for Tachyon somewhere?
.

here was some discussion about a NMEA parser in TACHYON

http://forums.parallax.com/showthrea...=1#post1253073

[Peter Jakacki]

I build a little robot inspired by the Mousey from Make magazine. It uses a Propeller as the controller.
I wrote a little Tachyon Forth program to make it avoid obstacles via it's IR sensors.
http://diy-2010.net/community/2014/0...-new-mousebot/

Now I want to use a GPS receiver module and get the NMEA sentences over the serial port.
Is there already a NMEA receive module for Tachyon somewhere?

I tried to get the serial data with some:



Where "serb" is of BYTE type. How can I build a string out of this data?
The goal is to get the NMEA string line from the GPS module.

How is the interactive Forth shell handled? The GPS module is soldered to the RX/TX lines of the Propeller.
So it shares the same serial lines with the shell serial input. Can the Forth shell interactive mode be switched off?

Sorry for asking some newbie stuff...

Welcome to the forum Jay!

Obviously to build a string you need to string bytes together, one after another, you can't do it with one byte. Your input routine should have a byte array that it can write the next character into and also a write index and the termination of that inputting is when it detects a CR. It's a good idea to write a null to the end of this input as it can be treated just like a string. That bit of code is fairly trivial and normally a good exercise for a beginner so if I give you an example then it's up to you to understand it and make any changes you need to make.

There is also no problem with using the console serial for this except of course how do you interact with it and debug it then? So I recommend tying the GPS transmit to another port through a 10K resistor (in case it's a 5V signal) and just use SERIN. Remember that the ! word means it stores a long, whereas you want to store a byte at a time so of course you need C! instead (it represents "character store").

Now it'll be interesting to see how you go with Mousey so please keep us updated, not just with the problems, but with the wins.

BTW: Choose "Go Advanced" in the forum buttons and change the thread title to "Mousey II" or something, and you can also even edit your first post.

#4800 SERBAUD --- set default baud rate for GPS
#84 BYTES gpsbuf --- NMEA sentence max is 80 visible characters
#P0 == rxdgps --- define out GPS receive port

pub GETGPS ( -- array ) gpsbuf BEGIN 0 OVER C! rxdgps SERIN DUP $0D <> WHILE OVER C! 1+ REPEAT DROP gpsbuf ;

GETGPS PRINT$
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545. 4,M,46.9,M,,*47 ok

[jay-t]

I build a little robot inspired by the Mousey from Make magazine. It uses a Propeller as the controller.
I wrote a little Tachyon Forth program to make it avoid obstacles via it's IR sensors.
http://diy-2010.net/community/2014/0...-new-mousebot/

Now I want to use a GPS receiver module and get the NMEA sentences over the serial port.
Is there already a NMEA receive module for Tachyon somewhere?

I tried to get the serial data with some:

31 SERIN serb !

Where "serb" is of BYTE type. How can I build a string out of this data?
The goal is to get the NMEA string line from the GPS module.

How is the interactive Forth shell handled? The GPS module is soldered to the RX/TX lines of the Propeller.
So it shares the same serial lines with the shell serial input. Can the Forth shell interactive mode be switched off?

Sorry for asking some newbie stuff...

[D.P]

Your threats to move the dictionary out of ram seem to be materializing nicely. Many people have good ideas, but very few can pull them from the "ether" and place them into reality.

[Peter Jakacki]

Great news!!! I've been running into the dreading "dictionary is full" error after loading all the networking goodies and wondering what I need/can chop out. Look forward to testing this new functionality when ready.

As the eternal optimist was heard saying as he plummeted from the top of the tall building "so far, so good". The SDWORDS conversion (71 bytes) just works and all the information seems to be there fine.
Typing in this definition:
pub LOOK ( <name> -- ) IMMEDIATE --- just a handy debug to dump the relevant word sector
GETWORD 1- C@++ 7 SHL SWAP C@ + 9 SHL FILE@ + $100 SD DUMP
;
then using it to have a look at a word sector:

LOOK CONNECT
0480_CA00: 07 43 4F 4E 54 45 4E 54 8A C0 C1 07 43 4F 4E 4E .CONTENT....CONN
0480_CA10: 45 43 54 8A BF A9 07 43 4F 55 4E 54 55 50 82 C2 ECT....COUNTUP..
0480_CA20: CE 07 43 4F 47 49 4E 49 54 82 C1 A7 07 43 4F 47 ..COGINIT....COG
0480_CA30: 52 45 47 40 82 C1 3F 07 43 52 45 41 54 45 24 82 REG@..?.CREATE$.
0480_CA40: C1 1A 07 43 4C 4B 46 52 45 51 82 C1 09 07 43 4F ...CLKFREQ....CO
0480_CA50: 4D 50 49 4C 45 A2 C2 60 07 43 4F 47 44 55 4D 50 MPILE..`.COGDUMP
0480_CA60: 82 C2 17 07 43 4F 47 49 4E 49 54 82 C2 97 07 43 ....COGINIT....C
0480_CA70: 4F 4E 53 4F 4C 45 82 C2 4B 00 00 00 00 00 00 00 ONSOLE..K.......
0480_CA80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

So this is the sector that would be presented as the "dictionary" whenever I type in a 7 character word that starts with a capital C. The nulls at the end of the words would then be seen as an end of dictionary if there wasn't a match and it would either try to convert it to a number or fail to find the word which is normal.

[D.P]

With a full filesystem and networking loaded (+app) this 32K RAM bottleneck has been bothering me for ages and the logical thing to do is to move the dictionary to external memory but EEPROM is way too slow and SD seems to be the choice, but how to actually manage and search it efficiently then? A dictionary can grow to 10K and even with SD it takes around 3ms per sector so that 60ms is still way too long to search for each word if we are compiling. So I have looked at hashing schemes and hybrid hashing schemes but they also introduce complexities without saving that much RAM.

Now, finally now I have come up with a scheme which keeps the dictionary in SDFS but can find any word from the console within 3ms, the time it takes to read a sector. This means that I "sacrifice" 2MB of SD but of course that's nothing as I convert 5 bits of the count and 7-bits of the first character as a 1 of 4,096 sector index into a dictionary file. So the sector gets read into a fixed buffer (there are 4 of them for 4 open files) and Tachyon just searches that RAM the same as it would when all the dictionary was in RAM, but now only the possible matches are presented, the ones with the same string length and same first character. Everything from there on works the same.

When a new word is created it goes into the "current" dictionary except of course there's that little step that makes sure it has read in the matching sector. Then the sector gets written and everything continues as normal. From Tachyon's text interpreter point of view the dictionary is a tiny 512 byte sector buffer, except that buffer gets magically loaded and saved as needed.

A dictionary can be converted to SDFS once the SDFS is in place as I am adding a simple SDWORDS which writes all the dictionary to the WORDS.DCT file, reclaims RAM, and then wires itself in to handle the SDFS as necessary.

I needed this has my application that sits on top of all the network layer needed around >2K and I was constantly running out of room. Expect to see a lot more added functionality now and even VGA with a full blown system too.

The slight problem now is that a full system image is comprised of 32K Prop EEPROM, + optional print strings in upper EEPROM + the 2MB WORDS.DCT file to make it complete. So don't expect the Spin tool to load it all with just a 32K binary although it may be that simple plus copy the WORDS.DCT to your SD card.

Great news!!! I've been running into the dreading "dictionary is full" error after loading all the networking goodies and wondering what I need/can chop out. Look forward to testing this new functionality when ready.

[Peter Jakacki]

With a full filesystem and networking loaded (+app) this 32K RAM bottleneck has been bothering me for ages and the logical thing to do is to move the dictionary to external memory but EEPROM is way too slow and SD seems to be the choice, but how to actually manage and search it efficiently then? A dictionary can grow to 10K and even with SD it takes around 3ms per sector so that 60ms is still way too long to search for each word if we are compiling. So I have looked at hashing schemes and hybrid hashing schemes but they also introduce complexities without saving that much RAM.

Now, finally now I have come up with a scheme which keeps the dictionary in SDFS but can find any word from the console within 3ms, the time it takes to read a sector. This means that I "sacrifice" 2MB of SD but of course that's nothing as I convert 5 bits of the count and 7-bits of the first character as a 1 of 4,096 sector index into a dictionary file. So the sector gets read into a fixed buffer (there are 4 of them for 4 open files) and Tachyon just searches that RAM the same as it would when all the dictionary was in RAM, but now only the possible matches are presented, the ones with the same string length and same first character. Everything from there on works the same.

When a new word is created it goes into the "current" dictionary except of course there's that little step that makes sure it has read in the matching sector. Then the sector gets written and everything continues as normal. From Tachyon's text interpreter point of view the dictionary is a tiny 512 byte sector buffer, except that buffer gets magically loaded and saved as needed.

A dictionary can be converted to SDFS once the SDFS is in place as I am adding a simple SDWORDS which writes all the dictionary to the WORDS.DCT file, reclaims RAM, and then wires itself in to handle the SDFS as necessary.

I needed this has my application that sits on top of all the network layer needed around >2K and I was constantly running out of room. Expect to see a lot more added functionality now and even VGA with a full blown system too.

The slight problem now is that a full system image is comprised of 32K Prop EEPROM, + optional print strings in upper EEPROM + the 2MB WORDS.DCT file to make it complete. So don't expect the Spin tool to load it all with just a 32K binary although it may be that simple plus copy the WORDS.DCT to your SD card.

[Peter Jakacki]

Awesome! Once again, I'm thinking about added code, and it was already there...seems to be a recurring theme for me...so many paradigms to overcome, but fun to try. I always keep features in mind, since I need them in order to know when it is functional.



I ran into precisely the same issue on a different section of the project I'm working on...That's why I had DUMPTEMP and DUMPB spit out the relevant addresses. I was blind, since I looked for precisely that and looked right over it. The noob is humbled. I just haven't had the time to fully understand ORG and the pros and cons (if there are any), but definately see an advantage.

It now works even better than I hoped. I was expecting it to have more of a delay than it actually had, which is always a good thing when you're looking for as fast as friggin' possible. I'm adding some features, and will re-post the whole (functional and with the features I need) module.

When I grow up, I wanna be like Peter. Most coders tell MCUs what to do. He convinces them that they want to do what he wants them to do.

ORG just sets a pointer somewhere into memory that you would like to use for pure storage as opposed to variables which all feature at least a bytecode to say that the following memory is a variable or a constant etc. So when you use ORG you can then use DS (Data Storage) to specify how many bytes you would like at the current storage address and the symbol for it. Unlike an assembler that this concept is taken from the symbol lives on in the Forth dictionary as a constant that supplies the address of that storage area which could be used for anything at all, totally untyped and unchecked.

So for instance we set up some buffers for these LEDs we go like this:

32            == ledcnt
ledcnt 3 *    == pxlbytes

BUFFERS       ORG              --- use BUFFERS for data storage
pxlbytes      DS pxldata       --- pxldata begins at BUFFERS and ORG is advanced to BUFFERS+96
1             DS tempgrn       --- tempgrn becomes a constant set as BUFFERS+96 and ORG is incremented
1             DS tempred
1             DS tempblu
3             DS tempcolors

What's different about this compared to using variables although they both return an address to a storage area is that there are no code bytes mixed in as the code is in code space as a constant whose value is the address of this storage area over here. So you can wipe the whole memory in this data storage area for instance and it won't affect the code but write a long to a byte variable will cause it to zap the code that follows that byte. How we use this DS then is sometimes to keep all our data in one place to allow it to be accessed as a structure such as file system tables and entries etc which are comprised of variable sized records. Have a look at SDCARD.fth and EASYFILE.fth for example.

Now having grown up I wouldn't call myself a coder or perhaps even a programmer plus I've made too many mistakes around too many talented people such as we have on this forum to ever worry about getting a big head and thinking I can get stuff to do what I want it to do, mostly I just coax it along and get lucky sometimes. The thing is with this stuff, more important than important is having fun and learning and sharing. That's something any of us can do and who gets tired of having fun?

[Chameleon]

Since the RUNMOD function only requires the start address and count it is easy enough to have a blank area or any other area for that matter such as the tables in ROM but otherwise just feel free to use the BUFFERS area or part thereof.
Initially you could: BUFFERS $800 ERASE BUFFERS pxlbytes + pxlbytes $FF FILL

To blank all the LEDs: BUFFERS pxlbytes RUNMOD
To light em up: BUFFERS pxlbytes + pxlbytes RUNMOD

In fact rather than calling RUNMOD directly you should really have this:
pub SHOW ( address -- ) pxlbytes RUNMOD #50 us ;

So BLANK becomes pub BLANK BUFFERS SHOW ;

Anyway there are all kinds of optimizations possible although I normally worry about "functionality first, features second". The scrolling marquee was one I was going to demo as soon as I get some LEDs but don't let me stop you, keep up the fun work.

Awesome! Once again, I'm thinking about added code, and it was already there...seems to be a recurring theme for me...so many paradigms to overcome, but fun to try. I always keep features in mind, since I need them in order to know when it is functional.

EDIT: the crash is simply because you are using a byte array in code space, not normally a problem but it was overwriting the GRN@ to BLU+ words which weren't noticed until it overran COLOR.
pxldata $80 DUMP
0000_3557: 00 C0 1F 62 0F BF 1F 62 0F C0 20 62 0F C0 1F 6A ...b...b.. b...j
0000_3567: 0F BF 1F 6A 0F C0 20 6A 0F C0 1F 6A BF 1F 6A C0 ...j.. j...j..j.
0000_3577: 20 6A 0F 87 C0 1F 6A 87 BF 1F 6A 87 C0 20 6A 0F j....j...j.. j.
0000_3587: C0 26 17 87 BF 25 0F C0 26 17 4A 21 87 21 BF 25 .&...%..&.J!.!.%
0000_3597: 0F C0 26 C0 1F 6A 0F C0 26 BF 1F 6A 0F C0 26 C0 ..&..j..&..j..&.
0000_35A7: 20 6A 0F 21 62 21 6A 0F 0F 85 F5 14 C0 22 29 0F j.!b!j......").
0000_35B7: 0F C0 2A 17 C0 1F C0 29 2C 17 BF 1F C0 29 2C C0 ..*....),....),.
0000_35C7: 20 C0 29 0F C0 2A 17 C0 1F BF 29 2C 17 BF 1F BF .)..*....),.... ok
' COLOR . 3570 ok
' GRN+ . 3564 ok
pxldata #29 + . 3574 ok

You can also define storage areas as constants with ORG such as:
BUFFERS ORG
pxlbytes DS pxldata
1 DS tempgrn
and so on to keep it all together without worrying about slamming into code.

I ran into precisely the same issue on a different section of the project I'm working on...That's why I had DUMPTEMP and DUMPB spit out the relevant addresses. I was blind, since I looked for precisely that and looked right over it. The noob is humbled. I just haven't had the time to fully understand ORG and the pros and cons (if there are any), but definately see an advantage.

It now works even better than I hoped. I was expecting it to have more of a delay than it actually had, which is always a good thing when you're looking for as fast as friggin' possible. I'm adding some features, and will re-post the whole (functional and with the features I need) module.

When I grow up, I wanna be like Peter. Most coders tell MCUs what to do. He convinces them that they want to do what he wants them to do.

[Peter Jakacki]

...AND that it only requires one byte in the code as opposed to two bytes (my original reason for trying it, to start as byte-efficient as possible as early as possible)



Doh! is right. The simple stuff can kill...can you tell me why it worked well for the first 28 LEDs, but not 29 plus?

I started calculating the byte count, but crashed because I started manipulating the array only (no attention to calling [WS2812]), and pxlcount 3 * BYTES pxldata failed (or something else at the same time during development)...I started with the right intent, just missed a step.



pxlcount vs. ledcount is (human) semantics. I chose pixels since the WS2812s I bought from Adafruit are "Neopixels."

What are your thoughts about adding an led clear to the kernel like the runmod? I see this being essential in a lot of applications, where we'll want to turn off all LEDS without affecting the color data already in the array (such as flashing a pattern on and off). I'm worried that we'll run into timing issues, where the strip will see my approach as an intentional reset...I haven't tested it yet since I've just seen your helpful smack on the forehead for a braindead flub.

While I'm at it, does anyone else have suggestions for additional functions? I'm kinda enjoying this, and this makes a good post "Hello World" project. I've already been thinking about scrolling marquees, so will be looking into multi-strip support.

Since the RUNMOD function only requires the start address and count it is easy enough to have a blank area or any other area for that matter such as the tables in ROM but otherwise just feel free to use the BUFFERS area or part thereof.
Initially you could: BUFFERS $800 ERASE BUFFERS pxlbytes + pxlbytes $FF FILL

To blank all the LEDs: BUFFERS pxlbytes RUNMOD
To light em up: BUFFERS pxlbytes + pxlbytes RUNMOD

In fact rather than calling RUNMOD directly you should really have this:
pub SHOW ( address -- ) pxlbytes RUNMOD #50 us ;

So BLANK becomes pub BLANK BUFFERS SHOW ;

Anyway there are all kinds of optimizations possible although I normally worry about "functionality first, features second". The scrolling marquee was one I was going to demo as soon as I get some LEDs but don't let me stop you, keep up the fun work.

EDIT: the crash is simply because you are using a byte array in code space, not normally a problem but it was overwriting the GRN@ to BLU+ words which weren't noticed until it overran COLOR.
pxldata $80 DUMP
0000_3557: 00 C0 1F 62 0F BF 1F 62 0F C0 20 62 0F C0 1F 6A ...b...b.. b...j
0000_3567: 0F BF 1F 6A 0F C0 20 6A 0F C0 1F 6A BF 1F 6A C0 ...j.. j...j..j.
0000_3577: 20 6A 0F 87 C0 1F 6A 87 BF 1F 6A 87 C0 20 6A 0F j....j...j.. j.
0000_3587: C0 26 17 87 BF 25 0F C0 26 17 4A 21 87 21 BF 25 .&...%..&.J!.!.%
0000_3597: 0F C0 26 C0 1F 6A 0F C0 26 BF 1F 6A 0F C0 26 C0 ..&..j..&..j..&.
0000_35A7: 20 6A 0F 21 62 21 6A 0F 0F 85 F5 14 C0 22 29 0F j.!b!j......").
0000_35B7: 0F C0 2A 17 C0 1F C0 29 2C 17 BF 1F C0 29 2C C0 ..*....),....),.
0000_35C7: 20 C0 29 0F C0 2A 17 C0 1F BF 29 2C 17 BF 1F BF .)..*....),.... ok
' COLOR . 3570 ok
' GRN+ . 3564 ok
pxldata #29 + . 3574 ok

You can also define storage areas as constants with ORG such as:
BUFFERS ORG
pxlbytes DS pxldata
1 DS tempgrn
and so on to keep it all together without worrying about slamming into code.

[Chameleon]

Absolutely no difference using 1 + instead of 1+ except that 1+ is a Tachyon opcode and only takes 400ns to execute.

4 LAP 1 + LAP .LAP   2. 200us ok
. 5 ok
4 LAP 1+ LAP .LAP   400ns ok
. 5 ok

...AND that it only requires one byte in the code as opposed to two bytes (my original reason for trying it, to start as byte-efficient as possible as early as possible)

But here's your problem, look at this code and also your original and besides using defined constants as parameters for other constants, notice BYTE vs BYTES (doh!)

#32   == pxlcount         --- number of LEDS in the array
pxlcount 3 *   == pxlbytes
pxlbytes   BYTES pxldata        --- pxlbytes

vs the original:

--- configure the pixel array itself
#32   == pxlcount         --- number of LEDS in the array
#96   == pxlbytes         --- MUST BE 3x pxcount
#96   BYTE pxldata        --- pxlbytes

Doh! is right. The simple stuff can kill...can you tell me why it worked well for the first 28 LEDs, but not 29 plus?

I started calculating the byte count, but crashed because I started manipulating the array only (no attention to calling [WS2812]), and pxlcount 3 * BYTES pxldata failed (or something else at the same time during development)...I started with the right intent, just missed a step.

pxlcount should also really be ledcount as each led has 3 pixels.

EDIT: looking at the other BYTE defs they might need to be changed too as BYTE will only create byte sized variables without requiring any extra parameters and BYTES needs to know how many bytes in an array as such:
BYTE onebyte
BYTE x,y,z
8 BYTES mybuf

So the purality of BYTE(S) WORD(S) LONG(S) indicates that you need to tell it how many. There are no error messages if you say 20 BYTE as 20 is just another stack parameter that may have a purpose only you know of but as you know Forth does not enforce syntax "you must do it this way" which while fine for students with training wheels is IMO too restictive if you know what you are doing.

BTW, if you mostly deal with decimal numbers you can just change your base to DECIMAL and skip the # tags. Perhaps I may just make decimal the default as I find that I normally prefix all my hex numbers with $ anyway.

pxlcount vs. ledcount is (human) semantics. I chose pixels since the WS2812s I bought from Adafruit are "Neopixels."

What are your thoughts about adding an led clear to the kernel like the runmod? I see this being essential in a lot of applications, where we'll want to turn off all LEDS without affecting the color data already in the array (such as flashing a pattern on and off). I'm worried that we'll run into timing issues, where the strip will see my approach as an intentional reset...I haven't tested it yet since I've just seen your helpful smack on the forehead for a braindead flub.

While I'm at it, does anyone else have suggestions for additional functions? I'm kinda enjoying this, and this makes a good post "Hello World" project. I've already been thinking about scrolling marquees, so will be looking into multi-strip support.

[D.P]

Absolutely no difference using 1 + instead of 1+ except that 1+ is a Tachyon opcode and only takes 400ns to execute.

4 LAP 1 + LAP .LAP   2. 200us ok
. 5 ok
4 LAP 1+ LAP .LAP   400ns ok
. 5 ok

.
.
.

Yep the version I wrote worked and I missed the BYTE/S mixup, thus just throwing hay into the wind with wild hope. Thanks for the explanation/s, always.

[Peter Jakacki]

replace every 1+ with 1 + and if it works Peter can explain

Absolutely no difference using 1 + instead of 1+ except that 1+ is a Tachyon opcode and only takes 400ns to execute.

4 LAP 1 + LAP .LAP   2. 200us ok
. 5 ok
4 LAP 1+ LAP .LAP   400ns ok
. 5 ok

But here's your problem, look at this code and also your original and besides using defined constants as parameters for other constants, notice BYTE vs BYTES (doh!)

#32   == pxlcount         --- number of LEDS in the array
pxlcount 3 *   == pxlbytes
pxlbytes   BYTES pxldata        --- pxlbytes

vs the original:

--- configure the pixel array itself
#32   == pxlcount         --- number of LEDS in the array
#96   == pxlbytes         --- MUST BE 3x pxcount
#96   BYTE pxldata        --- pxlbytes

pxlcount should also really be ledcount as each led has 3 pixels.

EDIT: looking at the other BYTE defs they might need to be changed too as BYTE will only create byte sized variables without requiring any extra parameters and BYTES needs to know how many bytes in an array as such:
BYTE onebyte
BYTE x,y,z
8 BYTES mybuf

So the purality of BYTE(S) WORD(S) LONG(S) indicates that you need to tell it how many. There are no error messages if you say 20 BYTE as 20 is just another stack parameter that may have a purpose only you know of but as you know Forth does not enforce syntax "you must do it this way" which while fine for students with training wheels is IMO too restictive if you know what you are doing.

BTW, if you mostly deal with decimal numbers you can just change your base to DECIMAL and skip the # tags. Perhaps I may just make decimal the default as I find that I normally prefix all my hex numbers with $ anyway.

[Chameleon]

replace every 1+ with 1 + and if it works Peter can explain

Nope...I believe I changed from 1 + to 1+ as a possible solution (straw grab)...tried this recommendation with precisely the same outcome.

I'd like to hear any limitations of 1+ vs 1 +, because I can't see any, and using 1+ rather than 1 + saves one byte per call. While I'm learning, I'd like to ingrain as many byte-efficient strategies as possible, like word nesting and 1+ vs 1 +. Using 1+, I have 9044 bytes free, where 1 + leaves me with 9038 (Tachyon + EXTEND + another module I wrote)

I'll move Forth and (hopefully) succeed!

[D.P]

I've had some good success, but am still fighting some bugs. I'm running into some seemingly random reboots, but wanted to toss out the general idea I had. Being a noob, I'm still trying to understand why one solved bug (creating tempgrn, tempred and tempblu after creating pxldata placed the temp colors within pxldata) actually happened...

( WS2812.fth )

TACHYON

[~
FORGET WS2812.fth
pub WS2812.fth         PRINT" WS2812 Intelligent RGB LED driver V1.0 1410221430.0000 " ;
IFNDEF [WS2812]                        --- use newer name for module in case this had the old name
ALIAS [TXRGB] [WS2812]
}

{  configure for the strip in use  }
#P0   MASK     == WSTXD   --- define our transmit pin
--- three bytes for storing temporary color values, used for writing to/reading from the pixel array
#1    BYTE tempgrn
#1    BYTE tempred
#1    BYTE tempblu
#3    BYTE tempcolors
--- configure the pixel array itself
#32   == pxlcount         --- number of LEDS in the array
#96   == pxlbytes         --- MUST BE 3x pxcount
#96   BYTE pxldata        --- pxlbytes

{  read/write tempcolor array  }
    {  read colors from tempcolor to stack }
pub GRN@ ( -- value ) tempgrn C@ ;
pub RED@ ( -- value ) tempred C@ ;
pub BLU@ ( -- value ) tempblu C@ ;

    {  "additive" color setting...leaves other color bytes unaffected  }
pub GRN+ ( value -- ) tempgrn C! ;
pub RED+ ( value -- ) tempred C! ;
pub BLU+ ( value -- ) tempblu C! ;

    {  "exclusive" color setting...blanks out (zeroes) the other color bytes  }
pub COLOR ( blu red grn -- )  tempgrn C! tempred C! tempblu C! ;    
pub BLACK ( -- ) 0 tempgrn C! 0 tempred C! 0 tempblu C! ;
pub MAGENTA ( value -- ) BLACK DUP 0 COLOR ;
pub CYAN ( value -- ) BLACK DUP 2/ SWAP 0 SWAP COLOR ;

pub GRN! ( value -- ) BLACK tempgrn C! ;
pub RED! ( value -- ) BLACK tempred C! ;
pub BLU! ( value -- ) BLACK tempblu C! ;

{  pixel setting  }
--- CMOVE (src dest num -- )  --- evaluate for byte savings (PXRD, PXWR, etc)

--- use two vectors, but saves a few bytes
pub PXRD ( src dest -- )
    SWAP 
    pub PXWR ( dest src -- )
        C@ SWAP C!
        ;
    ;

--- very likely unneeded...(PXCOLORADDR, not PXADDR) 
pub PXCOLORADDR ( grb pixelid --- coloraddress ) --- used for each read/write to the pixel data array
    pub PXADDR ( pixelid -- grnaddr ) 
        3 * pxldata + 
        ;
    +
    ;

pub PX@ ( pixelid -- )    --- read the color setting for a single pixel to tempcolor
    PXADDR DUP
    tempgrn PXRD
    1+ DUP tempred PXRD
    1+ tempblu PXRD
    ;
    
pub PX! ( pixelid -- )    --- write tempcolor values to a single pixel
    PXADDR DUP            
    tempgrn PXWR          
    1+ DUP tempred PXWR
    1+ tempblu PXWR
    ;


--- work in progress...figure out why fails after #28 pixels
--- remove numleds after it works for the entire array
pub PXFILL ( numleds -- )         --- write tempcolor to entire pixel array
    --- pxlcount 0 DO    --- planned function
    0 DO                 --- remove once it works for all leds, regardless of pixel count
      I PX!
    LOOP
    ;


{  communicate with the led strip  }
pub LEDCONFIG ( -- )  --- needs to be separated for blankleds..."configure" cog, then send three bytes at a time to strip
    WSTXD OUTCLR              --- Start a RET to synch the chips
    WSTXD 4 COGREG!           --- setup the I/O pin for the RUNMOD to use
    [WS2812]                   --- select the WS2812 module for RUNMOD
    #10 us                    --- still need a bit of extra delay for a minimum RET op while txd is low
    ;

pub LEDS ( -- )  --- Replacement for Peter's LEDS...same code, just split into two words
    LEDCONFIG 
    pxldata pxlbytes RUNMOD      --- pass the address of the array and the byte count to the RUNMOD
    ;

--- Is this an easier task for the kernel addition?
pub BLANKLEDS ( -- ) --- Turns off all LEDS (0G 0R 0B) without affecting the color data in pxldata
    --- PLACE HOLDER...Figure out crashes with current code first...I have no idea if the strip timing chokes doing this
    {
    set tempcolors to $000000...easier way?
    LEDCONFIG                --- set up cog for sending the data to the strip
    pxlcount 0 DO            --- do once per pixel
        tempcolors 3 RUNMOD  --- send the temp data to the strip
    LOOP
    }
    
{  debug code  }
pub DUMPTEMP ( -- )       --- dumps the contents of tempcolor
    CR 
    CR PRINT" ============================================="
    CR PRINT" LED TEMP COLORS (" tempgrn . PRINT" , " tempred . PRINT" , " tempblu . PRINT" , " tempcolors . PRINT" )"
    CR 
    PRINT" GREEN: " tempgrn C@ . 
    PRINT"   RED: " tempred C@ . 
    PRINT"   BLUE: " BLU@ .    
    PRINT"   TEMPCOLORS: " tempcolors @ .
    ;
        
pub DUMPB  ( -- )    --- 3 byte data element array pretty dumper (thanks, D.P.)
    DUMPTEMP 
    CR 
    CR PRINT" ============================================="
    CR PRINT" LED STORED COLORS "
    CR 
    pxldata pxlbytes       --- push this onto the stack: arrayaddr arraysize
    CR                                --- Carrriage return to start
    ADO  I C@ . "-" EMIT              --- fetch each first byte show it
      I pxldata - 1+ 3 MOD 0=        --- test for third byte
        IF PRINT" --" pxldata I - 1+ 3 /  . PRINT"  (" I 2 - . PRINT" )" CR THEN    --- pretty print it
    LOOP                 --- around we go
 ;

]~

END

#28 PXFILL works without issue, but #29 PXFILL reboots the prop...

I'm continuing to work on this, but if anyone has any thoughts as to why I'm getting the reboots, I'd be happy to hear it.

replace every 1+ with 1 + and if it works Peter can explain

[Chameleon]

COLOR crashes the prop! It looks to me like it starts stomping on the registers.

Changing to

pub COLOR ( value offset -- ) rgbleds + rgbsz ADO DUP I C! 3 +LOOP DROP ;

works beautifully!
I've got several projects where these will be outrageously useful, and will be attaching a bit of an update with some more capabilities. We need the ability to change the color on specific pixels, the ability to blank the strip without affecting the data in the array among other functions.

I've had some good success, but am still fighting some bugs. I'm running into some seemingly random reboots, but wanted to toss out the general idea I had. Being a noob, I'm still trying to understand why one solved bug (creating tempgrn, tempred and tempblu after creating pxldata placed the temp colors within pxldata) actually happened...

( WS2812.fth )

TACHYON

[~
FORGET WS2812.fth
pub WS2812.fth         PRINT" WS2812 Intelligent RGB LED driver V1.0 1410221430.0000 " ;
IFNDEF [WS2812]                        --- use newer name for module in case this had the old name
ALIAS [TXRGB] [WS2812]
}

{  configure for the strip in use  }
#P0   MASK     == WSTXD   --- define our transmit pin
--- three bytes for storing temporary color values, used for writing to/reading from the pixel array
#1    BYTE tempgrn
#1    BYTE tempred
#1    BYTE tempblu
#3    BYTE tempcolors
--- configure the pixel array itself
#32   == pxlcount         --- number of LEDS in the array
#96   == pxlbytes         --- MUST BE 3x pxcount
#96   BYTE pxldata        --- pxlbytes

{  read/write tempcolor array  }
    {  read colors from tempcolor to stack }
pub GRN@ ( -- value ) tempgrn C@ ;
pub RED@ ( -- value ) tempred C@ ;
pub BLU@ ( -- value ) tempblu C@ ;

    {  "additive" color setting...leaves other color bytes unaffected  }
pub GRN+ ( value -- ) tempgrn C! ;
pub RED+ ( value -- ) tempred C! ;
pub BLU+ ( value -- ) tempblu C! ;

    {  "exclusive" color setting...blanks out (zeroes) the other color bytes  }
pub COLOR ( blu red grn -- )  tempgrn C! tempred C! tempblu C! ;    
pub BLACK ( -- ) 0 tempgrn C! 0 tempred C! 0 tempblu C! ;
pub MAGENTA ( value -- ) BLACK DUP 0 COLOR ;
pub CYAN ( value -- ) BLACK DUP 2/ SWAP 0 SWAP COLOR ;

pub GRN! ( value -- ) BLACK tempgrn C! ;
pub RED! ( value -- ) BLACK tempred C! ;
pub BLU! ( value -- ) BLACK tempblu C! ;

{  pixel setting  }
--- CMOVE (src dest num -- )  --- evaluate for byte savings (PXRD, PXWR, etc)

--- use two vectors, but saves a few bytes
pub PXRD ( src dest -- )
    SWAP 
    pub PXWR ( dest src -- )
        C@ SWAP C!
        ;
    ;

--- very likely unneeded...(PXCOLORADDR, not PXADDR) 
pub PXCOLORADDR ( grb pixelid --- coloraddress ) --- used for each read/write to the pixel data array
    pub PXADDR ( pixelid -- grnaddr ) 
        3 * pxldata + 
        ;
    +
    ;

pub PX@ ( pixelid -- )    --- read the color setting for a single pixel to tempcolor
    PXADDR DUP
    tempgrn PXRD
    1+ DUP tempred PXRD
    1+ tempblu PXRD
    ;
    
pub PX! ( pixelid -- )    --- write tempcolor values to a single pixel
    PXADDR DUP            
    tempgrn PXWR          
    1+ DUP tempred PXWR
    1+ tempblu PXWR
    ;


--- work in progress...figure out why fails after #28 pixels
--- remove numleds after it works for the entire array
pub PXFILL ( numleds -- )         --- write tempcolor to entire pixel array
    --- pxlcount 0 DO    --- planned function
    0 DO                 --- remove once it works for all leds, regardless of pixel count
      I PX!
    LOOP
    ;


{  communicate with the led strip  }
pub LEDCONFIG ( -- )  --- needs to be separated for blankleds..."configure" cog, then send three bytes at a time to strip
    WSTXD OUTCLR              --- Start a RET to synch the chips
    WSTXD 4 COGREG!           --- setup the I/O pin for the RUNMOD to use
    [WS2812]                   --- select the WS2812 module for RUNMOD
    #10 us                    --- still need a bit of extra delay for a minimum RET op while txd is low
    ;

pub LEDS ( -- )  --- Replacement for Peter's LEDS...same code, just split into two words
    LEDCONFIG 
    pxldata pxlbytes RUNMOD      --- pass the address of the array and the byte count to the RUNMOD
    ;

--- Is this an easier task for the kernel addition?
pub BLANKLEDS ( -- ) --- Turns off all LEDS (0G 0R 0B) without affecting the color data in pxldata
    --- PLACE HOLDER...Figure out crashes with current code first...I have no idea if the strip timing chokes doing this
    {
    set tempcolors to $000000...easier way?
    LEDCONFIG                --- set up cog for sending the data to the strip
    pxlcount 0 DO            --- do once per pixel
        tempcolors 3 RUNMOD  --- send the temp data to the strip
    LOOP
    }
    
{  debug code  }
pub DUMPTEMP ( -- )       --- dumps the contents of tempcolor
    CR 
    CR PRINT" ============================================="
    CR PRINT" LED TEMP COLORS (" tempgrn . PRINT" , " tempred . PRINT" , " tempblu . PRINT" , " tempcolors . PRINT" )"
    CR 
    PRINT" GREEN: " tempgrn C@ . 
    PRINT"   RED: " tempred C@ . 
    PRINT"   BLUE: " BLU@ .    
    PRINT"   TEMPCOLORS: " tempcolors @ .
    ;
        
pub DUMPB  ( -- )    --- 3 byte data element array pretty dumper (thanks, D.P.)
    DUMPTEMP 
    CR 
    CR PRINT" ============================================="
    CR PRINT" LED STORED COLORS "
    CR 
    pxldata pxlbytes       --- push this onto the stack: arrayaddr arraysize
    CR                                --- Carrriage return to start
    ADO  I C@ . "-" EMIT              --- fetch each first byte show it
      I pxldata - 1+ 3 MOD 0=        --- test for third byte
        IF PRINT" --" pxldata I - 1+ 3 /  . PRINT"  (" I 2 - . PRINT" )" CR THEN    --- pretty print it
    LOOP                 --- around we go
 ;

]~

END

#28 PXFILL works without issue, but #29 PXFILL reboots the prop...

I'm continuing to work on this, but if anyone has any thoughts as to why I'm getting the reboots, I'd be happy to hear it.

[MJB]

What about using 7 strips and pushing the 5X7 font out for a basic scrolling marque

In keypoll of course while running telnet, http, ftp and sending an email, okay maybe email is running in its own cog since it could block a bit.

If you want a controlled timing (like for running text) you might better put the redisplay routine into a timer task running in the timer COG.
Or if need be even in it's own COG. All very easy with Tachyon. and since we have some spare COGs we can use them as well.

[D.P]

Yeah, dumb things like that happen as I didn't get to test it out and "rgbleds" was in the original before I factored it out "quickly"

But good to hear it works because when I get some leds I will be posting some videos of some fancy patterns which I will be able to tune interactively of course.

What about using 7 strips and pushing the 5X7 font out for a basic scrolling marque

In keypoll of course while running telnet, http, ftp and sending an email, okay maybe email is running in its own cog since it could block a bit.

[Peter Jakacki]

I agree with Chameleon, just don't get your above COLOR word Peter. I do think you meant ADO instead of DO and need to adjust the initial address of the array with the proper byte offset before the loop?

Yeah, dumb things like that happen as I didn't get to test it out and "rgbleds" was in the original before I factored it out "quickly"

But good to hear it works because when I get some leds I will be posting some videos of some fancy patterns which I will be able to tune interactively of course.

[D.P]

COLOR crashes the prop! It looks to me like it starts stomping on the registers.

Changing to

pub COLOR ( value offset -- ) rgbleds + rgbsz ADO DUP I C! 3 +LOOP DROP ;

works beautifully!
I've got several projects where these will be outrageously useful, and will be attaching a bit of an update with some more capabilities. We need the ability to change the color on specific pixels, the ability to blank the strip without affecting the data in the array among other functions.

I agree with Chameleon, just don't get your above COLOR word Peter. I do think you meant ADO instead of DO and need to adjust the initial address of the array with the proper byte offset before the loop?

[Chameleon]

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 ;

COLOR crashes the prop! It looks to me like it starts stomping on the registers.

Changing to

pub COLOR ( value offset -- ) rgbleds + rgbsz ADO DUP I C! 3 +LOOP DROP ;

works beautifully!
I've got several projects where these will be outrageously useful, and will be attaching a bit of an update with some more capabilities. We need the ability to change the color on specific pixels, the ability to blank the strip without affecting the data in the array among other functions.

[mindrobots]

Tachyon 2.4 & latest EXTEND.FTH from Dropbox is working fine now. In this message, I reported issues loading extend - after grabbing a fresh copy of extend.fth from Dropbox, it loaded fine onto a Prop BOE and also onto a QuickStart.

Win7, Tera Term, 230400 with 15ms line delay.

The ws2812 code with the MASK change also works just fine with my ws2811 LEDs.

Fun stuff!!

[richaj45]

Thanks for the education.

rich

[Peter Jakacki]

there are no stupid questions ... maybe ...

you can also write PASM drivers to be loaded in COGS, but this currently requires to put the code in Tachyon.spin

There are easy ways to load directly into cogs form EEPROM or SD so I will update the files to do this which also includes assembling a PASM source from onboard file to a cog PASM object. Simply specify the file and cog to run when you want to run it during runtime, so you can change it on the fly. One moment it's an FFT, next moment it's handling high level communications etc.

[MJB]

Along the line of multicore, i have a question.

From the Tachyon code it looks to me the receive serial get left in COG 0 and the rest of the code goes into COG 1.

If i am write how does one put special drivers and such into other COGs using Tachon?

Forgive me if this is a stupid question, i only come around every so often.

cheers,
rich

there are no stupid questions ... maybe ...

if you look at the end of tachyon 2.4.spin you find this

{ Boot-time Spin startup - launches Tachyon into all the remaining cogs and starts serial receive in this cog = 0 }

PUB Start
  rxticks := txticks := clkfreq / baudrate    ' Force VM transmit routine to correct baud
  coginit(1,@HSSerialRx, @rxbuffers)
  repeat 6
cognew(@RESET, @IDLE_reset)
  coginit(0,@RESET, @TERMINAL_reset)

you see that the serial started is started in COG1 and COG0 is loaded with the Tachyon Terminal.
The other 6 COGs get loaded with the Tachyon kernel as well, but put in IDLE state, waiting for a WORD / function to be loaded.

see:
( COG TASK CONTROL )
and
( INTERTASK COMMUNICATIONS ) in EXTEND.fth for how to start a Tachyon-Task in an other COG

EXTEND also defines a TIMER task, that is started in COG 7
see Timer and Keypoll examples here

you can also write PASM drivers to be loaded in COGS, but this currently requires to put the code in Tachyon.spin

[richaj45]

Along the line of multicore, i have a question.

From the Tachyon code it looks to me the receive serial get left in COG 0 and the rest of the code goes into COG 1.

If i am write how does one put special drivers and such into other COGs using Tachon?

Forgive me if this is a stupid question, i only come around every so often.

cheers,
rich

[Peter Jakacki]

Peter:

Somewhat off topic. In searching for some Forth info, I ran across a question on Stack Overflow asking about a multicore forth back in 2011. The question remains open and is largely unanswered in terms of a practical implementation. There seems to be at least 3 on this forum. Care to contribute an answer?

http://stackoverflow.com/questions/5...h-is-there-one

Rick

Just keeping the reply to this forum but considering the reference it seems to be mainly academic in nature? Computer languages to many are a great source of debate, like Apple vs Android etc etc. Personally I find all the Forth forums very boring as this debate and also about features of the language are bounced back and forth (pun) ad nasuem. I can't say I would use Forth for everything, but for me there is a sweet spot between really low end and high end where Forth shines. But it's not about the language really, it's about productivity which increases in an environment that allows you to test out things interactively AND easily, not like interactive Basic peek and poke in decimal etc, but creating defintiions and structures that allow high level interaction at the bare metal layer at close to assembly speed, or at least fast enough.

There's this joke about what's the differnce between a scientist and an engineer? The engineer gets his hands dirty. Yeah, I like to get into it rather than standing around all day talking about it and many times getting into it just proves that most don't know what they are talking about.

Now back to that other forum and not really answering the question either but I don't really consider Tachyon a multicore Forh either, and I think that distinction for the Prop should go to PropForth as not only does it launch multiple Forth consoles one in each core but it also facilitates multi-chip processing too. However this approach seems to have traded off some of the very advantages of Forth that I at least need, one of which is speed, and also compactness too amongst other things. But each to his own and hopefully we have come to our own decision rather than relying upon popular opinions etc.

[RickB]

Peter:

Somewhat off topic. In searching for some Forth info, I ran across a question on Stack Overflow asking about a multicore forth back in 2011. The question remains open and is largely unanswered in terms of a practical implementation. There seems to be at least 3 on this forum. Care to contribute an answer?

http://stackoverflow.com/questions/5...h-is-there-one

Rick

[D.P]

@DP, are you using Windows/TeraTerm or Linux/Minicom?

I'll try it on a Quickstart to rule out a board issue.

OSX, minicom, here's my alias to start minicom for this quickstart board

alias mini5='minicom -D /dev/tty.usbserial-AH00OO83 -b 230400'

I use 13 ms line delay no character delay

[mindrobots]

@DP, are you using Windows/TeraTerm or Linux/Minicom?

I'll try it on a Quickstart to rule out a board issue.

[D.P]

Works just fine on my quickstart, wow V2.4x has some really neat stuff! Thanks Peter

0035  ok
0267      INCLUDING #9 PIN_I/O_OPERATIONS
0436      INCLUDING #8 CHARACTER_OUTPUT
0493      INCLUDING #7 LOCAL_VARIABLES 
0515      INCLUDING #6 FIXED_POSITION_VARIABLES 
0571      INCLUDING #5 MATHS_FUNCTIONS 
0707      INCLUDING #12 NUMBER_PRINT_FORMATING 
0822      INCLUDING #19 ANSI_TERMINAL
0998      INCLUDING #24 INTERTASK_COMMUNICATIONS
1027      INCLUDING #20 STRINGS
1102      INCLUDING #21 SAN_FILTER
1128      INCLUDING #22 MCP3208_8_channel_ADC
1407      INCLUDING #13  PBASIC_STYLE_SERIAL_I/O
1441      INCLUDING #14   EXAMINE_SPECIAL_PURPOSE_REGISTERS
1486      INCLUDING #15   Memory Map Reporting
1917      INCLUDING #17 Virtual RTC words 51 48 17 3B 
2024      INCLUDING #10 PWM
2084      INCLUDING #11 HEX FILE LOAD & DUMP
2163      INCLUDING #18 COMPILER REPORTING
2270  ok
2271  ok
2272 

00:00:00  End of source code, 2273 lines processed and 0000 errors found 
MODULES LOADED: 
1900: EXTEND.fth          Primary extensions to TACHYON kernel - 140905-173O


  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
Clock frequency = 80,000,000
NAMES:  $5CB2...7471 for 6079 (3682 bytes added)
CODE:   $0000...33CC for 7181 (6860 bytes added)
CALLS:  0452 vectors free
RAM:    10470 bytes free
 ok
?BACKUP  ok
  ok

[KMyers]

I am as usual confused today. This morning when I rebooted my Act brd the extension file showed up in the start up screen, Peter please ignore my mental issues. I assumed that when the extension completed it would automatic reboot. My bad...

[whiteoxe]

Hey Peter, I tried to send you a private messagre but i got a message saying your message box was full and could not accept any more ?

[KMyers]

Same set up here except with an activity board. Load current binary works great, cut and paste the extend get to about line 17 and get a missing word, then about 20 minutes later I get several more then nothing. Let run all afternoon into late evening and it never finished with the log on and prompt. I know its something I am not doing but what?

I used Notepad ++ to copy the file and terra term to paste into Tachyon. Also tried to reduce baud rate and left the delays set to original setting...

[mindrobots]

Hi Peter,

I broke my Tachyon!

I just grabbed the latest (15 hours old) from Dropbox: Tachyon V2.4 and Extend.fth. I'm using a Propeller BOE on Win7 with TeraTerm 4.78 (all my usual suspects).

I load Tachyon (F11 from source) to the board, start up Tera Term 230,400 (15ms line delay). When I paste EXTEND.fth into TeraTerm, I get this:

  ok
( EXTEND.fth )  ok
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140619.0000
 ok
0000  ok
0001  ok
0002  ok
0003  okND.fth        ." Primary extensions to TACHYON kernel - 121122.1200 " ;
0004  ok
" !!!!!!!!!!!!!!!!!!!!! REQUIRES LATEST KERNEL V2.0 121012.2200 upwards !!!!!!!!0005  ok
0006  ok
0007  ok
0008  ok
0009  ok  DUP $0A <> IF $100 OR 2* (EMIT) ELSE DROP THEN ;
0010  ok
\
0011  ok
\
0012  ok
0013  ok              1 flags CLR ' LEMIT uemit W! ;
0014  ok
\
0015  ok
0016  ok              1 flags SET  0 uemit W! ;
0017  ok
0018 @ÞÖ@``br@@ÞÖ@``d`@@ÞÖ@``db@@ÞÖ@``dd@@ÞÖ@``df@@ÞÖ@``dh@@ÞÖ@``dj@@ÞÖ@``dl@@``dn@@ZZ|@¦¨¤
           @xZZ@ÜÞè@ÌÞêÜÈ@@``dp@@``dr@@ZZ|@²¨
                                             @xZZ@ÜÞè@ÌÞêÜÈ@

and that's the end of things.

I tried it with V2.3 (the above is actually the test of V2.3) and results are the same.

I've tried slowing it down to 115,200, increasing the line pause, adding a character pause, nothing seems to get past this point.

If I drop back to V2.3 with an EXTEND from June 2014, it all works fine.

[Peter Jakacki]

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:

  Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
Clock frequency = 80,000,000
NAMES:  $5440...7471 for 8241 (1170 bytes added)
CODE:   $0000...48C9 for 10392 (2856 bytes added)
CALLS:  0222 vectors free
RAM:    2935 bytes free


MODULES LOADED: 
3DA1: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 190924-1100 
3654: SDCARD.fth          SD CARD Toolkit - 140626.1400 
34F4: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200 
1900: EXTEND.fth          Primary extensions to TACHYON kernel - 140905-173O
BOOT: EXTEND.boot


----------------------------------------------------------------
MOUNT  Mounted SD Card 
Media mounted as CAC0.660D          NO NAME     FAT32    Cluster size = 2,768   Sectors = 6,320
 ok
ls -l
-rwxrwxrwx 1 502     500     90980 Jun 15  15:44 CE1372.PDF
-rwxrwxrwx 1 502     500     10401 Jun 12  14:53 TELNET.TXT
-rwxrwxrwx 1 502     500     32768 Jun 15  15:44 FIRMWARE.ROM
-rwxrwxrwx 1 502     500      7935 Jun 15  15:44 FRED.PNG
-rwxrwxrwx 1 502     500     64764 Jun 15  15:44 FSRPCB.PNG
-rwxrwxrwx 1 502     500     84098 Jun 16  11:27 HOME2.HTM
-rwxrwxrwx 1 502     500     24190 Jun 15  15:44 HOME.BAK
-rwxrwxrwx 1 502     500      1137 Jun 12  15:21 W5100.   
-rwxrwxrwx 1 502     500       564 Jun 15  15:44 HTTP404.HTM
-rwxrwxrwx 1 502     500     16204 Jun 15  15:44 IMAGE.   
-rwxrwxrwx 1 502     500     12500 Jun 15  15:44 IMAGE1.   
-rwxrwxrwx 1 502     500     51347 Jun 15  15:44 IMAGE2.   
-rwxrwxrwx 1 502     500     80286 Jun 15  15:44 IMAGE3.   
-rwxrwxrwx 1 502     500       388 Jun 15  15:44 LOGON.HTM
-rwxrwxrwx 1 502     500      6109 Jun 15  15:43 PARALLAX.PNG
-rwxrwxrwx 1 502     500    159937 Jun 15  15:43 TACHYON.HTM
-rwxrwxrwx 1 502     500    305152 Jun 15  15:44 TEST0001.LOG
-rwxrwxrwx 1 502     500      8069 Dec 17  09:57 FAVICON.ICO
-rwxrwxrwx 1 502     500      2707 Jun 15  15:43 TOUCH.HTM
-rwxrwxrwx 1 502     500   1048576 Feb 24  14:31 LOG0004.TXT
-rwxrwxrwx 1 502     500   1048576 Feb 24  14:31 LOG0003.TXT
-rwxrwxrwx 1 502     500   1226386 Jul  8  18:02 W5200DS.PDF
-rwxrwxrwx 1 502     500     21603 Dec  3  10:50 TACHYON.JPG
-rwxrwxrwx 1 502     500   1048576 Feb 24  14:31 LOG0002.TXT
-rwxrwxrwx 1 502     500   1048576 Feb 24  14:31 LOG0001.TXT
-rwxrwxrwx 1 502     500    117804 Dec 11  15:45 POPCORN.WAV
-rwxrwxrwx 1 502     500   1048576 Dec  3  01:56 SYSLOG.TXT
-rwxrwxrwx 1 502     500   1442886 Feb 22  22:57 P8X32A.PDF
-rwxrwxrwx 1 502     500     99235 Jun 15  15:44 HOME3.HTM
-rwxrwxrwx 1 502     500     79876 Jun 16  01:21 HOME.HTM

[D.P]

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.

[MJB]

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


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

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.

[D.P]

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


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

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.

https://docs.google.com/document/d/1...3ZDgPKEiIc/pub

[kdewey]

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


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

[David Betz]

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!

[Peter Jakacki]

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?

[David Betz]

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. :-)

[Peter Jakacki]

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.

[David Betz]

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.

[D.P]

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.

[Peter Jakacki]

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

[D.P]

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.

[Peter Jakacki]

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 ;

[David Betz]

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:

--- 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 )

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: Attachment 111433

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!

[Peter Jakacki]

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:

--- 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 )

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

[Peter Jakacki]

Do you have a WS2812 driver for Tachyon?

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
    ;

[Peter Jakacki]

Do you have a WS2812 driver for Tachyon?

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.

[David Betz]

Do you have a WS2812 driver for Tachyon?

[David Betz]

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!

[Peter Jakacki]

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!

[MJB]

Thanks for the code review Peter.

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.

The picture @ http://thegaragelab.com/galleries/mi...lcd_memory.png might explain it better than my words.

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

[MJB]

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

[Peter Jakacki]

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.

[MJB]

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:

WORD uput
pub PUT$ ( ch -- )        DUP $0D = IF DROP CON ELSE uput W@ DUP LEN$ + C! THEN ;
pub SET: ( str -- )       ' PUT$ uemit W! DUP uput W! ERASE$ ;
pub TO:                   to$ SET: ;
pub SUBJECT:              sub$ SET: ;
pub FROM:                 from$ SET: ;

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:

--- 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
 ;

EDIT: Here is the console output when trying to connect to my local errant XMail server:

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

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$

[Peter Jakacki]

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:

WORD uput
pub PUT$ ( ch -- )        DUP $0D = IF DROP CON ELSE uput W@ DUP LEN$ + C! THEN ;
pub SET: ( str -- )       ' PUT$ uemit W! DUP uput W! ERASE$ ;
pub TO:                   to$ SET: ;
pub SUBJECT:              sub$ SET: ;
pub FROM:                 from$ SET: ;

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:

--- 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
 ;

EDIT: Here is the console output when trying to connect to my local errant XMail server:

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

[D.P]

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:

    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

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)

[Peter Jakacki]

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:

    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

[D.P]

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 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.

Neat

dp

[Peter Jakacki]

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:

" 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 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.

[D.P]

All this network stuff is for embedded use so SMTP is good for email alerts and status updates (for the record) and FTP so the device can go and automatically upload/download files. I may also look at what protocols I can use to twitter to a smartphone too.

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.

[Peter Jakacki]

I've written some basic POP3 and SMTP clients that interact with MTAs correctly, What did you have in mind, VT100 Mail client?

All this network stuff is for embedded use so SMTP is good for email alerts and status updates (for the record) and FTP so the device can go and automatically upload/download files. I may also look at what protocols I can use to twitter to a smartphone too.

[D.P]

Although I've mainly been concentrating on network servers in Tachyon I want to do some work with clients, specially for email, FTP, and NTP etc. Has anyone had any experience with implementing these on the Prop, in Tachyon or otherwise? I plan to put that functionality into the IoT5500 module which is a bit like a mini network development system in itself.

I've written some basic POP3 and SMTP clients that interact with MTAs correctly, What did you have in mind, VT100 Mail client?

[Peter Jakacki]

Although I've mainly been concentrating on network servers in Tachyon I want to do some work with clients, specially for email, FTP, and NTP etc. Has anyone had any experience with implementing these on the Prop, in Tachyon or otherwise? I plan to put that functionality into the IoT5500 module which is a bit like a mini network development system in itself.

[Peter Jakacki]

Question:
My propeller is running the parallax program when it boots up, obviously; so how do I get Tachyon
Forth on the Propeller? Do I have to have a bootloader? How do I get Tachyon on the propeller?
Thanks.

Haven't you ever loaded code onto your Prop before? With the Spin tool or BST you load your code or image an F11 it into the Prop. If you load the ".spin" file you can compile that after which you can use Tachyon to compile EXTEND.fth. Use a serial terminal set for 230,400 baud.

Easiest way though is just click on the Dropbox link in my sig and go to the binaries folder and use that binary image.

[mklrobo]

Question:
My propeller is running the parallax program when it boots up, obviously; so how do I get Tachyon
Forth on the Propeller? Do I have to have a bootloader? How do I get Tachyon on the propeller?
Thanks.

[MJB]

I want to count pulses on a pin but I don't know what to read to get the value. I setup the mode and i tried to read the phsa register var with little success. I am new to this forum so go easy..
can someone help.
Ken

you are talking about TACHYON ??
then try
PHSA SPR + SPR@
and read this: Introduction to TACHYON Forth (links to files) and the TACHYON source SPIN file of course

[kdewey]

I want to count pulses on a pin but I don't know what to read to get the value. I setup the mode and i tried to read the phsa register var with little success. I am new to this forum so go easy..
can someone help.
Ken

[MJB]

Hmmm...., mit de SD-Karte ist es noch nicht das Gelbe vom Ei.

Auf der SD-karte befinden sich die Dateien wie bei EASYFILE gefordert.
Es wird zwar alles ordentlich geladen, die beiden Programme.

Danach wir sogar ein Backup als Ordnungsgemäß durchgeführt gemeldet, aber auf der SD-Karte ist noch die alte ROM.BIN (so heißt meine Datei, habe sie umbenannt).

Da muß noch dran gehobelt werden.

Gruss

Hi Funkheld, ich bin zwar auch aus Deutschland, Peter versteht auch einiges Deutsch, aber dies ist ein englischsprachiges Forum, wenn Du also Hilfe willst ist es besser sich der Sprache zu bedienen, die die Leute verstehen.
Oder meld dich halt mal per PM bei mir.
Übrigens - was Peter mit Tachyon in den kleinen Propeller hineinpackt ist mehr Eigelb, als Du sonstwo finden kannst.
Und was bei Tachyon unerlässlich ist ... die Source Code Files lesen - ALLE ...

[funkheld]

Hmmm...., mit de SD-Karte ist es noch nicht das Gelbe vom Ei.

Auf der SD-karte befinden sich die Dateien wie bei EASYFILE gefordert.
Es wird zwar alles ordentlich geladen, die beiden Programme.

Danach wir sogar ein Backup als Ordnungsgemäß durchgeführt gemeldet, aber auf der SD-Karte ist noch die alte ROM.BIN (so heißt meine Datei, habe sie umbenannt).

Da muß noch dran gehobelt werden.

Gruss

[Peter Jakacki]

Ich habe dieses File geladen : TACHYON.binary


Dann SDCARD.FTH geladen, klappt wunderbar.
SD und die anderen Befehle funktionieren mit der SD-Karte.


Um eine SD-Karte als FAT32 zu lesen habe ich : MULTIFAT.FTH geladen.
Ich wollte mit : SAVEROM eine ROM.BIN erstellen.


Dann kommt zb diese Meldung:
--> >F83 <-- not found und


Dann ist schluss.....


GRuss

SAVEROM does not require a filename as it always saves to FIRMWARE.ROM but you can specify a name if you use SAVEIMG <name>. However the MULTIFAT is the old name and the new one is called EASYFILE, are you sure you are using the current Dropbox files??? Anyway the SDFS must have a file by that name already as it does not try to create on. The idea is that we leave the PC to worry about clusters and FAT tables etc so that is why I have a folder with files that can be copied onto a card.

[funkheld]

Ich habe dieses File geladen : TACHYON.binary


Dann SDCARD.FTH geladen, klappt wunderbar.
SD und die anderen Befehle funktionieren mit der SD-Karte.


Um eine SD-Karte als FAT32 zu lesen habe ich : MULTIFAT.FTH geladen.
Ich wollte mit : SAVEROM eine ROM.BIN erstellen.


Dann kommt zb diese Meldung:
--> >F83 <-- not found und


Dann ist schluss.....


GRuss

[funkheld]

Hallo, ich habe mit DUMPROM in TeraTerm aufgelistet.
Habe es dann copiert vom Screen und in eine forth.hex gespeichert.
Danach in eine Bin umgewandelt mit dem Namen forth.binary.

Aber die Prüfziffer stimmt nicht. Das PropTool meckert.

---------------------------------
:1000000000B4C4046F361000B07EB87E847EBC7E1F
:10001000A07E0200747E00000B1961010000000048
:100020000084030000000000000000000000000049
:100030000000000000000000000000008D20000013
:10004000000000002500000000000000000000008B
:100060000000000000000032333131303034350000
:10007000073F4241434B5550000000000000000084
:1000D000000000000000000080250000000000007B
:1000E000040000000000407D0002BE6A0000BD6AFE
:1000F000365C3E5C8018F934FC345AA5AC34000000
:100100001307200D10100D500000000004010039ED
......
.......
----------------------------------------------------------------------------------

Gruss

[Peter Jakacki]

Wie mache ich ein fertiges Binary vom Tachyon V2.3.spin wenn ich dieses Datei "EXTEND.fth" geladen habe ?

Danke.
Gruss

Since you don't have an SD card in the system you have to use the DUMPROM command which will correct the checksum and dump out the EEPROM in Intel hex format. If you copy or log that into a .hex file you can run a hex2bin utility (PC Utilities folder) which will produce a .bin file which you need to rename to .binary for the Spin tool to recognize it. Verstehen?

[funkheld]

Wie mache ich ein fertiges Binary vom Tachyon V2.3.spin wenn ich dieses Datei "EXTEND.fth" geladen habe ?

Danke.
Gruss

[Peter Jakacki]

Ja, danke.

RAM: 3309 bytes free bei Tachyon V2.3.spin ?

Da passt doch diese nicht mehr rein : EXTEND.FTH ?
Welches Forth nehme ich , wo ich die EXTEND.FTH einlesen kann?

Danke.
Gruss

I can't guess which files you have loaded so you will have to give me more information. Just copy the text from the screen and paste it into the reply and format as code (Go Advanced - use #)

[funkheld]

Ja, danke.

RAM: 3309 bytes free bei Tachyon V2.3.spin ?

Da passt doch diese nicht mehr rein : EXTEND.FTH ?
Welches Forth nehme ich , wo ich die EXTEND.FTH einlesen kann?

Danke.
Gruss

[Peter Jakacki]

Ich habe mein SD-Karte hier an den Pins angeschlossen:
DO: 1 CLK: 7 DI :0 CSP: 4


Wie kann ich die PINS mitteilen , wo werden die eingetragen in : Tachyon V2.3.spin

Danke.
Gruss

Have a look at QS.fth as this is the hardware description file for the QuickStart which is meant to be loaded before SDCARD.fth. So it's best to create a file like this to suit your hardware as this is what I do. This is the only custom file you should need to load any of the modules. Look in the "headers" folder.

I don't know why you would want to load sertially without a terminal though, In Linux you can use the "cat myfile > /dev/ttyUSB0" for instance even with a terminal session open, I know that works.

[funkheld]

Ich habe mein SD-Karte hier an den Pins angeschlossen:
DO: 1 CLK: 7 DI :0 CSP: 4


Wie kann ich die PINS mitteilen , wo werden die eingetragen in : Tachyon V2.3.spin

Danke.
Gruss

[funkheld]

Ja, danke für die Info.

Mit Datei laden meinte ich , das ich die Datei selber übertrage seriell ohne TeraTerm zu bemühen.

Danke.
Gruss

[Peter Jakacki]

Hallo, guten Tag.

Wo finde ich die neueste Version vom Forth ? Es gibt da verschiedene die ich gefunden habe, teilweise mit eingebundenen anderen Funktionen.

Ansonsten ist das ein tolles Projekt was du da gemacht hast.

Danke.

Gruss

Now you make me struggle with technical terms too!

The root level of the Tachyon Dropbox folder has the latest source and the binaries folder will always have the current binary with all the older ones in the "old" sub-folder.

The trouble with VGA is that even with 320X240 it still takes around 10K and thats also with reclaiming the VGA cog image from main memory. If I get a chance I may connect up a monitor and try out some VGA again over the next few days. A simple text VGA is what I had planned so I will go with that and then look at the 320x240.

If you want to send a file in Teraterm then that's okay you just need to do a FILE - SEND FILE from the menu.

Cheers, Peter

[funkheld]

Hallo, guten Tag.

Wo finde ich die neueste Version vom Forth ? Es gibt da verschiedene die ich gefunden habe, teilweise mit eingebundenen anderen Funktionen.

Mit dem eingebundenen VGA und die Darstellung der Grafik reicht wahscheinlich der Speicher nicht, Es sind am unteren rand ca 100 Zeilen Striche durcheinander, darüber ist der Screen leer.
Warum läuft das bei dir : VIDEOS: Enhanced bitmap graphics demo + serial
Könnte man nicht 320x200 herstellen, dann hätte man mehr Speicher.

Ich habe ein Forth ohne VGA gefunden, ganz am Anfang dieser Diskussion : 07-18-2012, 05:06 PM
Da werden die Eingaben nicht umgesetzt : 4 5 + . , da kommt zb keine Ausgabe.

Ich kann ja den fth-Text mit Copy/Paste usw in TeraTerm einbinden.
Wie kann man den fth-Text seriell dort übertragen ?

Ansonsten ist das ein tolles Projekt was du da gemacht hast.

Ich habe ein 64KB EEprom angeschlossen.

Danke.

Gruss

[Peter Jakacki]

@funkheld

Was machst du? Ich kann genug Deutsch sprechen, um mich in Schwierigkeiten zu bringen und Sie tun das gleiche mit Tachyon sind (Ich meine Mutter schuld)

It sounds like you are trying bits from different versions. So what are you trying to do, if you want to do more with VGA then I haven't touched that in a long time and you would have to stick to the old versions.

Now what do you mean "upload a file without uploading"????? Is there another way?

So perhaps you could describe your project or goals a little so that I can give you some pointers.

[funkheld]

-----------------------------------------------------------------
' \ ( -- )
' Ignore following text till the end of line.
' IMMED
COMMENT byte XCALL,xKEY,_BYTE,$0D,EQ,_UNTIL,07,XCALL,xCR,EXIT
BRACE byte XCALL,xKEY,DUP,XCALL,xEMIT,_BYTE,")",EQ,_UNTIL,10, EXIT
CURLY byte XCALL,xKEY,_BYTE,"}",EQ,_UNTIL,07,EXIT
---------------------------------------------------------------------

blocked this thing up again and the more read the "fth" !!!



I would also vga and plot to take out from the Forth system with the font !!!

-----------------------------------------------------------------------------------
FONT byte _WORD,(@font5x7+s)>>8,@font5x7+s,EXIT


' A 5x7 bitmap font designed for the 128x64 graphic lcd or 512x384 VGA bitmap
' each character takes up 7 bytes, the lsb is the rightmost pixel
'
font5x7
byte 000,000,000,000,000,000,000 ' space
byte 100,100,100,100,100,000,100 ' !
byte 010,010,010,000,000,000,000
byte 010,010,111,010,111,010,010
byte 100,111,100,110,101,110,100
byte 000,001,010,100,000,011,011
byte 100,010,100,000,101,010,101
byte 100,100,000,000,000,000,000
byte 010,100,000,000,000,100,010
byte 000,100,010,010,010,100,000
byte 000,100,101,110,101,100,000
byte 000,100,100,111,100,100,000
byte 000,000,000,000,100,100,000
byte 000,000,000,111,000,000,000
byte 000,000,000,000,000,100,100
byte 000,001,010,100,000,000,000
byte 110,001,011,101,001,001,110 '0
byte 100,100,100,100,100,100,110 '1
byte 110,001,001,010,100,000,111
byte 111,010,100,010,001,001,110
byte 010,110,010,010,111,010,010
byte 111,000,110,001,001,001,110
byte 110,000,000,110,001,001,110
byte 111,001,001,010,100,100,100
byte 110,001,001,110,001,001,110
byte 110,001,001,111,001,010,100 '9
byte 000,100,100,000,100,100,000
byte 000,100,100,000,100,100,000
byte 010,100,000,000,000,100,010
byte 000,000,111,111,000,000,000
byte 000,100,010,001,010,100,000
byte 110,001,001,010,100,000,100
byte 110,001,001,101,101,101,110 '@
byte 110,001,001,001,111,001,001 'A
byte 110,001,001,110,001,001,110
byte 110,001,000,000,000,001,110
byte 100,010,001,001,001,010,100
byte 111,000,000,110,000,000,111
byte 111,000,000,110,000,000,000
byte 110,001,000,111,001,001,111
byte 001,001,001,111,001,001,001
byte 110,100,100,100,100,100,110
byte 111,010,010,010,010,010,100
byte 001,010,100,000,100,010,001
byte 000,000,000,000,000,000,111
byte 001,011,101,101,001,001,001
byte 001,001,001,101,011,001,001
byte 110,001,001,001,001,001,110
byte 110,001,001,110,000,000,000
byte 110,001,001,001,101,010,101
byte 110,001,001,110,100,010,001
byte 111,000,000,110,001,001,110
byte 111,100,100,100,100,100,100
byte 001,001,001,001,001,001,110
byte 001,001,001,001,001,010,100
byte 001,001,001,101,101,101,010
byte 001,001,010,100,010,001,001
byte 001,001,001,010,100,100,100
byte 111,001,010,100,000,000,111 'Z
byte 100,000,000,000,000,000,100
byte 000,000,000,100,010,001,001
byte 111,001,001,001,001,001,111
byte 100,010,001,000,000,000,000
byte 000,000,000,000,000,000,111
' $60..$7f ' not all characters have been converted yet
byte 000,100,010,000,000,000,000
byte 000,000,110,001,111,001,110 'a
byte 000,000,110,001,001,001,110
byte 000,000,110,000,000,001,110
byte 001,001,101,011,001,001,111
byte 000,000,110,001,111,000,110
byte 110,001,000,110,000,000,000
byte 000,111,001,001,111,001,110
byte 000,000,110,001,001,001,001
byte 100,000,100,100,100,100,110
byte 010,000,010,010,010,010,100
byte 000,000,010,100,000,100,010
byte 000,000,000,000,000,000,111
byte 001,011,101,101,001,001,001
byte 001,001,001,101,011,001,001
byte 110,001,001,001,001,001,110
byte 110,001,001,110,000,000,000
byte 110,001,001,001,101,010,101
byte 110,001,001,110,100,010,001
byte 111,000,000,110,001,001,110
byte 111,100,100,100,100,100,100
byte 001,001,001,001,001,001,110
byte 001,001,001,001,001,010,100
byte 001,001,001,101,101,101,010
byte 001,001,010,100,010,001,001
byte 001,001,001,010,100,100,100
byte 111,001,010,100,000,000,111 'z
byte 100,000,000,000,000,000,100
byte 100,100,100,100,100,100,100
byte 111,001,001,001,001,001,111
byte 000,100,010,111,010,100,000
byte 000,010,100,111,100,010,000
----------------------------------------------------------------------------------------------------------------------------------

not in use

this is good:
text : "vga_text"


greeting

[funkheld]

hello, good day.
how can you please upload a fth in the forth without "copy / paste" or "upload file" without?


Thank you.

[funkheld]

TeraTerm does not take this character at Forth: \
Forth then stops.
How do you change in TeraTerm?


Thank you.

[funkheld]

HEX: CLKFREQ ( -- freq ) 0 @ ;: >CFA ( atr -- cfa ) 2 + C@ 2* 2* XCALLS + W@ ;

Copy/Paste in the TeraTerm : HEX: CLKFREQ
it must : HEX : CLKFREQ
Copy/Paste in the TeraTerm : ... 0 @ ;: >CFA ( a...
and the must : ... 0 @ ; : >CFA ( a...

greeting

[funkheld]

hello, thank you.

[Peter Jakacki]

if Extend.fth in TeraTerm copiere in Forth, is "not found .... not found ..."
how should the text that is formatted it is recognized by the forth? LF CR ?

Thank you.

If you downloaded a binary image then EXTEND.fth is already loaded but if you compiled from the Tachyon V2.3 source then you need to copy from EXTEND.fth and paste this into the terminal. However you must set the terminal for 20ms LINE delay as there is no handshake. You could also send the file instead of pasting under Teraterm through the FILE SEND menu. All that TF is looking for is a CR and it ignores the LF so it doesn't matter. Did you have a read of the Intro page?

Don't expect VGA.fth to be loaded for the newer versions as there is not enough memory to support the VGA bitmap but you can still download the old binaries with this in it via the Dropbox folder under binaries - old.

[funkheld]

if Extend.fth in TeraTerm copiere in Forth, is "not found .... not found ..."
how should the text that is formatted it is recognized by the forth? LF CR ?




Thank you.

[funkheld]

hello, how can you actually load the file and use in forth:
VGA.fth


or how this "fth" be loaded?


Thank you.

[funkheld]

ja, danke.
gruss

[mindrobots]

Check Peter's signature.
The (latest) binary in signature is with no vga and auto detects the 5/10 MHz Xtal. Simply connect a terminal (teraterm in Windows is a good start) and set it to 230400.

Massimo

As Massino said:

Check Peter's signature (Peter is the creator of Tachyon)

Tachyon hosting Web, FTP, and Telnet
Dropbox files and binaries (latest)
Introduction to TACHYON Forth (links to files)

[funkheld]

ok.
is the spin from Library-Propellertool

Thank you.

[funkheld]

where can I find the latest version?

thanks you

[max72]

hello, good day.
which is out the latest Archive.zip for TACHYON?

I want no vga in the forth!


Thank you.

Check Peter's signature.
The (latest) binary in signature is with no vga and auto detects the 5/10 MHz Xtal. Simply connect a terminal (teraterm in Windows is a good start) and set it to 230400.

Massimo

[funkheld]

with me is the startup screen not shown by tachyon Forth?
why is that?
which terminal you used to represent the green startup screen?


thank you

[David Betz]

Look, isn't Tachyon Forth specific to the Propeller? So I'm not talking about programming in general although I prefer the speed and small footprint of Forth in typical embedded systems. Javascript needs lots of memory and grunt to run and then it just ain't fast at all. Those embedded systems that are capable of supporting Linux etc are a different kettle of fish and I use the language that best suits that board and application. To me coding in any language is a way of getting the job done so it's a matter of picking the right tools. On really small embedded systems I prefer to just code in assembler and so I know what I'm dealing with. I don't think I've ever bothered to code any real projects in Forth on an existing O/S but only those ones where it makes sense and to me the Propeller is one of those. So pretty much any smaller 16/32-bit system with at least 32K RAM perhaps would be a good candidate for Forth IMO.

That makes a lot of sense to me.

[funkheld]

hello, good day.
which is out the latest Archive.zip for TACHYON?

I want no vga in the forth!


Thank you.

[Peter Jakacki]

I admire your courage in being freelance and able to pick what you work on. I've never had the self-confidence to do that! Good for you!

I don't want to start another language war but I think most of what you're describing is true of any interactive language. It is certainly true of that Javascript interpreter Heater is always talking about. However, I think Tachyon seems to fit the Propeller quite well and is probably a wonderful environment for someone familiar with Forth or interested in learning it.

Look, isn't Tachyon Forth specific to the Propeller? So I'm not talking about programming in general although I prefer the speed and small footprint of Forth in typical embedded systems. Javascript needs lots of memory and grunt to run and then it just ain't fast at all. Those embedded systems that are capable of supporting Linux etc are a different kettle of fish and I use the language that best suits that board and application. To me coding in any language is a way of getting the job done so it's a matter of picking the right tools. On really small embedded systems I prefer to just code in assembler and so I know what I'm dealing with. I don't think I've ever bothered to code any real projects in Forth on an existing O/S but only those ones where it makes sense and to me the Propeller is one of those. So pretty much any smaller 16/32-bit system with at least 32K RAM perhaps would be a good candidate for Forth IMO.

[Alexander (Sandy) Hapgood]

Although I could work full time as I like I prefer "my time" where I choose a balance of current work, future work, and play work which might and does result in future work. If it's so much fun then it's hardly work so could you call it a job?

I always think of what I do as more like 'structured play' rather than work.

Sandy

[David Betz]

Although I could work full time as I like I prefer "my time" where I choose a balance of current work, future work, and play work which might and does result in future work. If it's so much fun then it's hardly work so could you call it a job?

I keep my life fairly simple without stressing everyday about overheads and commitments and since I get to decide what I will or won't work on and how to do it then I choose the ones that are a balance between money and fun. But as much as you might refuse to believe that it's entirely to do with working in Forth I however find that since I have the most fun with Forth bringing new boards and chips to life that this then is also the most productive.

As I mentioned elsewhere it's not just about the "language" because you can't really compare Forth with traditional PC hosted languages/compilers, it's not the same thing. So while a target hosted Forth certainly does appear more primitive than a PC hosted Gigabyte compiler IDE it is also far more interactive and close to the silicon. I can hook-up a new chip and be "talking" to it within minutes discovering a lot more about it then can be gleaned and precompiled from a datasheet or accessing a driver or lib obect. In this manner I come up with alternative methods of accessing it and adapting the "language" so if it's the WIZnet chip for instance then I get to talk to it and it tells me all about itself and how it's coping, a real heart to heart if you could imagine it that way. So I know the things it likes, what it doesn't like, and little secrets that you can only know about if you get close and cosy. I hear it complain so I want to know what's wrong, I ask it, maybe a quick one-liner or something, and it tells me so I can make it better

Now what I said may be seem to be overly metamorphosing but it's hard to explain what that "something about Forth" thing is unless you really actually seriously get into it. I've had many traditional programmers and engineers who have watched over my shoulder as I turn a newborn shoebox prototype into a chatty can-do within hours if that even, and they are usually shaking their heads in utter disbelief. Unfortunately the greater percentage are "stuck" with their traditional ways of programming and like learning a foreign language are too caught-up in comparing back to what they already know rather than being immersed in the "culture" where when you get the way of thinking, then speaking the language follows easily.

I admire your courage in being freelance and able to pick what you work on. I've never had the self-confidence to do that! Good for you!

I don't want to start another language war but I think most of what you're describing is true of any interactive language. It is certainly true of that Javascript interpreter Heater is always talking about. However, I think Tachyon seems to fit the Propeller quite well and is probably a wonderful environment for someone familiar with Forth or interested in learning it.

[holi]

Hi holi, thought I recognized you, venturing across into Propeller land

I haven't assigned any license to Tachyon, it's more like "use it how you want" and so there is absolutely no problem with whatever you want to do with it but let us know how you go with it though.

hi, Forther
Those who are interested in this decompiled+disassembled list could find it here:
tech.groups.yahoo.com/group/armForth/files choose parallex propeller

where you can find TachyonForthLST1.f

or if you're interested in the execution file, just download
TACHYONFORTH1.EXExxx
and remove the xxx at the end of the execution file.

It can be executed under windows XP where win32for 4.2.67x resides.



++++ You have to sign in as a member to read the file. ++++

[mklrobo]

Although I could work full time as I like I prefer "my time" where I choose a balance of current work, future work, and play work which might and does result in future work. If it's so much fun then it's hardly work so could you call it a job?

I keep my life fairly simple without stressing everyday about overheads and commitments and since I get to decide what I will or won't work on and how to do it then I choose the ones that are a balance between money and fun. But as much as you might refuse to believe that it's entirely to do with working in Forth I however find that since I have the most fun with Forth bringing new boards and chips to life that this then is also the most productive.

As I mentioned elsewhere it's not just about the "language" because you can't really compare Forth with traditional PC hosted languages/compilers, it's not the same thing. So while a target hosted Forth certainly does appear more primitive than a PC hosted Gigabyte compiler IDE it is also far more interactive and close to the silicon. I can hook-up a new chip and be "talking" to it within minutes discovering a lot more about it then can be gleaned and precompiled from a datasheet or accessing a driver or lib obect. In this manner I come up with alternative methods of accessing it and adapting the "language" so if it's the WIZnet chip for instance then I get to talk to it and it tells me all about itself and how it's coping, a real heart to heart if you could imagine it that way. So I know the things it likes, what it doesn't like, and little secrets that you can only know about if you get close and cosy. I hear it complain so I want to know what's wrong, I ask it, maybe a quick one-liner or something, and it tells me so I can make it better

Now what I said may be seem to be overly metamorphosing but it's hard to explain what that "something about Forth" thing is unless you really actually seriously get into it. I've had many traditional programmers and engineers who have watched over my shoulder as I turn a newborn shoebox prototype into a chatty can-do within hours if that even, and they are usually shaking their heads in utter disbelief. Unfortunately the greater percentage are "stuck" with their traditional ways of programming and like learning a foreign language are too caught-up in comparing back to what they already know rather than being immersed in the "culture" where when you get the way of thinking, then speaking the language follows easily.

Right. The way I am trying to understand your Tachyon, is that your programming Methedology is more important that the code itself.

[Peter Jakacki]

hi, Peter
Do you mind if I pusblish the decompiled+disassembled list of Tachyon Forth based on the development system that I've designed. And if permissible I'll post the execution file so that one can see it clearly. Does Tachyon Forth follow the GPL (General Public Licience) rule?
holi

Hi holi, thought I recognized you, venturing across into Propeller land

I haven't assigned any license to Tachyon, it's more like "use it how you want" and so there is absolutely no problem with whatever you want to do with it but let us know how you go with it though.

[holi]

hi, Peter
Do you mind if I pusblish the decompiled+disassembled list of Tachyon Forth based on the development system that I've designed. And if permissible I'll post the execution file so that one can see it clearly. Does Tachyon Forth follow the GPL (General Public Licience) rule?
holi

[Peter Jakacki]

Do you have a full time job? If you do, I'm really impressed that you find enough time to do all you've done with Tachyon. Heck, even if you don't, your productivity is impressive and I refuse to believe that is entirely do to working in Forth! :-)

Although I could work full time as I like I prefer "my time" where I choose a balance of current work, future work, and play work which might and does result in future work. If it's so much fun then it's hardly work so could you call it a job?

I keep my life fairly simple without stressing everyday about overheads and commitments and since I get to decide what I will or won't work on and how to do it then I choose the ones that are a balance between money and fun. But as much as you might refuse to believe that it's entirely to do with working in Forth I however find that since I have the most fun with Forth bringing new boards and chips to life that this then is also the most productive.

As I mentioned elsewhere it's not just about the "language" because you can't really compare Forth with traditional PC hosted languages/compilers, it's not the same thing. So while a target hosted Forth certainly does appear more primitive than a PC hosted Gigabyte compiler IDE it is also far more interactive and close to the silicon. I can hook-up a new chip and be "talking" to it within minutes discovering a lot more about it then can be gleaned and precompiled from a datasheet or accessing a driver or lib obect. In this manner I come up with alternative methods of accessing it and adapting the "language" so if it's the WIZnet chip for instance then I get to talk to it and it tells me all about itself and how it's coping, a real heart to heart if you could imagine it that way. So I know the things it likes, what it doesn't like, and little secrets that you can only know about if you get close and cosy. I hear it complain so I want to know what's wrong, I ask it, maybe a quick one-liner or something, and it tells me so I can make it better

Now what I said may be seem to be overly metamorphosing but it's hard to explain what that "something about Forth" thing is unless you really actually seriously get into it. I've had many traditional programmers and engineers who have watched over my shoulder as I turn a newborn shoebox prototype into a chatty can-do within hours if that even, and they are usually shaking their heads in utter disbelief. Unfortunately the greater percentage are "stuck" with their traditional ways of programming and like learning a foreign language are too caught-up in comparing back to what they already know rather than being immersed in the "culture" where when you get the way of thinking, then speaking the language follows easily.

[David Betz]

There is a W5500 in the Dropbox and the current testing version in Google docs (via the link page). When I get away from this PC and sit down in front of my system I will tidy up the DE0 files although this isn't really required of course. I need to draw a quick diagram of the connections though.

Do you have a full time job? If you do, I'm really impressed that you find enough time to do all you've done with Tachyon. Heck, even if you don't, your productivity is impressive and I refuse to believe that is entirely do to working in Forth! :-)

[Peter Jakacki]

I had a feeling you where not couting sheep. Thanks for the W5500 additions.

I have a DEO Nano, can I play with this Tachyon super cog too and new W5500 driver?

There is a W5500 in the Dropbox and the current testing version in Google docs (via the link page). When I get away from this PC and sit down in front of my system I will tidy up the DE0 files although this isn't really required of course. I need to draw a quick diagram of the connections though.

[D.P]

While I have been playing with the P1 FPGA Verilog I've also been able to connect a few peripherals including a W5500 module that's been lying around waiting to be tested. So I have adapted the W5200 driver for this chip and it certainly is a lot easier to drive plus I like the way that they have segregated all the buffers in the W5500 so that you don't have to calculate addresses and masks all the time, just say which section you want in the control byte.

At present I am still testing this driver on the P1V @120MHz and with supercog mode where cog 0 has access to all unused hub slots but everything appears to run well. EASYNET has been updated as well to allow for the chip although I will see what I can do to have chip specifics removed from this level. The driver hasn't been optimized yet but otherwise it runs smoothly.........

I had a feeling you where not couting sheep. Thanks for the W5500 additions.

I have a DEO Nano, can I play with this Tachyon super cog too and new W5500 driver?

[funkheld]

thanks for the sd-card-report.

greeting

[Peter Jakacki]

While I have been playing with the P1 FPGA Verilog I've also been able to connect a few peripherals including a W5500 module that's been lying around waiting to be tested. So I have adapted the W5200 driver for this chip and it certainly is a lot easier to drive plus I like the way that they have segregated all the buffers in the W5500 so that you don't have to calculate addresses and masks all the time, just say which section you want in the control byte.

At present I am still testing this driver on the P1V @120MHz and with supercog mode where cog 0 has access to all unused hub slots but everything appears to run well. EASYNET has been updated as well to allow for the chip although I will see what I can do to have chip specifics removed from this level. The driver hasn't been optimized yet but otherwise it runs smoothly.

ifconfig 
************ NETWORK STATUS ************ 
HARDWARE: P1V DE0-NANO using WIZnet W5500 
LINK *UP*
CHIP VER  0004
SRC IP    192.168.016.160.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       02.FF.9C.1B.91.B0.
*** SOCKETS *** 
#0 00:00:00 MODE= CLSD PORT#             TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      
#1 00:00:00 MODE= TCP  PORT#   21        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#2 00:00:00 MODE= CLSD PORT#   20        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      
#3 00:00:00 MODE= TCP  PORT#10001        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#4 00:00:00 MODE= TCP  PORT#   80        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#5 00:00:00 MODE= CLSD PORT#  911        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      
#6 00:00:00 MODE= CLSD PORT#             TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      
#7 00:00:00 MODE= CLSD PORT#             TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      

peter@peter-Dell-System-XPS-L702X ~ $ telnet 192.168.16.160 10001
Trying 192.168.16.160...
Connected to 192.168.16.160.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!
.MODULES
 
MODULES LOADED: 
40DC: EASYNET.fth         WIZNET NETWORK SERVERS 140804.2300 
3910: W5500.fth           WIZNET W5500 driver 140817.0000 
2EBF: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140626-2100 
29F3: SDCARD.fth          SD CARD Toolkit - 140626.1400 
1901: EXTEND.fth          Primary extensions to TACHYON kernel - 140723-14OO
 ok
BYE
Connection closed by foreign host.
peter@peter-Dell-System-XPS-L702X ~ $

If you want to dump contents of the W5500 just remember that all dumps are now unified under the general DUMP variants (DUMP, DUMPW, DUMPL, DUMPA) by specifying the device but with the W5500 you also need to specify the section and socket.
These are the modifier words:
WIZ selects the WIZnet device as the default DUMP method
@COMMON
@TX
@RX
n SOCKET will select socket 0..7 and also selects the socket segment (in place of TX RX or common)

Here are some examples (hex base):
0 40 WIZ @COMMON DUMP --- dump the common registers
0 30 WIZ 2 SOCKET DUMP --- dump socket 2 registers
0 100 WIZ 3 SOCKET @TX DUMPA --- dump the first 256 bytes of socket 3 transmit buffer

Note: There is no need to continue to continue to specify WIZ or other modifiers unless necessary, so:
0 40 WIZ 4 SOCKET @RX DUMPA --- dump some of the receive buffer for HTTP
0 200 DUMPA --- dumps more of the receive buffer for HTTP

So you can also type it like this:
WIZ 4 SOCKET @RX
0 40 DUMPA
0 200 DUMPA

[mklrobo]

Peter has gotten Tachyon Forth to run as fast as it does by careful optimization ... matching how his Forth works to how the Propeller works. In particular, the most commonly used bytecodes (that Forth gets compiled into) decode easily and quickly into code addresses with a direct jump to the code involved in executing the bytecode. Secondly, he has the first few stack locations in fixed memory locations (rather than indexed via a stack pointer or index register) because the Propeller has no index registers and computed addresses have to be handled via modifying instructions. There are other optimizations, but I believe these are the most important for performance.

10-4. Very clever. Thanks.

[Mike Green]

Peter has gotten Tachyon Forth to run as fast as it does by careful optimization ... matching how his Forth works to how the Propeller works. In particular, the most commonly used bytecodes (that Forth gets compiled into) decode easily and quickly into code addresses with a direct jump to the code involved in executing the bytecode. Secondly, he has the first few stack locations in fixed memory locations (rather than indexed via a stack pointer or index register) because the Propeller has no index registers and computed addresses have to be handled via modifying instructions. There are other optimizations, but I believe these are the most important for performance.

[mklrobo]

In reference to the specific application, I will get the source code of Tachyon to give you an example.

[mklrobo]

I have been programming, but not as much as I would like.
In reference to programming in general, every programmer has learned
their own heuristics in programming. Your Forth runs faster than any other,
so I assume you have incorporated your heuristic into the program. You
must have adapted some advantage of forth to acquire this. This is what
I am focusing on. I know that you probably could not tell anyway, becuase
it is how you make your living; I understand. If it is just the perfection of
programming, why has not somebody at least come close to what you
have done?

[Peter Jakacki]

I am new to forth, but I would like to humbly submit a question..
Do you in some form or fashion use RPN to process data like you would process numbers?
I know that you must use a math model(s) to streamline your processes, in sync with
the cogs of the propeller. Am I close? warm? cold? enquiring minds want to know..............

Hi mklrobo, not too new though as you've had some experience with PropForth I guess. I'm not real sure of your question though, do you have a particular example or application in mind? Sometimes the problem is that if you knew the answer you would also know how to ask the question!
So rather than ask a question just say what it is you are trying to do, maybe what your initial goal is etc in plain simple words. As it is your question is a meaningless jumble of jargon, so I guess it would be "cold"

[mklrobo]

I am new to forth, but I would like to humbly submit a question..
Do you in some form or fashion use RPN to process data like you would process numbers?
I know that you must use a math model(s) to streamline your processes, in sync with
the cogs of the propeller. Am I close? warm? cold? enquiring minds want to know..............

[funkheld]

Hello, thanks for the Info.

Greeting

[Electrodude]

Line delay - newlines - your documentation said it was ^A T D in minicom which is labeled "Newline tx delay" in the program - it all fits together perfectly! I should really learn to follow directions... Thanks for that hint, I would have never guessed.

XON/XOFF is not properly supported on PCs it seems, they just never seem to respond since they have such huge FIFOs which do not look ahead for XOFFs.

Is that a hardware thing or a Windows thing? Will it affect me on Linux? What if nothing else is in the FIFO when the XON/XOFF comes?

I didn't even notice QS.fth... Thanks! Now I'll probably have to buy the QS W5200 addon board for the QuickStart board I just got at RadioShack for something like $7.99 instead of just using my Spinneret.

I'm very happy to learn that your web server was on a bad wifi connection - I guess I'll give vanilla Tachyon with no PASM drivers a try.

[D.P]

Now "little grasshopper", take your time and when you find that you can't understand why it's done a certain way or why it isn't working the way you think it should then think that there must be good reason for it, and if there isn't, you will find out why. Once you take the time to find out why then you start to understand. You may start trying to improve what you don't understand but will you really improve it then? The idea with Tachyon is that you don't need to write special PASM drivers, that Forth is fast enough to tackle the I/O directly or in unison with a RUNMOD which is really just a microcoded instruction anyway.

Oh I've been here befor with Tachyon a few times, "Use the source Luke"

[Peter Jakacki]

The pin configuration for an SD card is near the top of SDCARD.fth:
IFNDEF &SDCS
#P26 |< == &SDCS \ SDCARD CS
#P27 |< == &SDDO \ Data out from SDCARD
#P28 |< == &SDCK \ SDCARD clocks (Shared with SCL)
#P29 |< == &SDDI \ Data to SDCARD (Shared with SDA)
}

Change the #Pxx to whatever you want. I just figured this out 15 minutes before seeing your question.


@Peter Jakacki:
I want to use Tachyon for something resembling a home security/monitoring system. I've come up with several questions while looking at Tachyon's guts:

Why don't the SD card and Wiznet drivers run in their own PASM cogs? Wouldn't that be way faster? I was playing with your Tachyon website demo, and it seemed really slow, but that might have only been because too many people were trying to use it at once. I'm experimenting with adding PASM drivers now, even though it's probably not a good beginner's project for someone just starting FORTH.

Also, what's with the huge line delays? Are they really necessary? What's the shortest I can safely make them? It took much longer than my patience lasts for file transmission, probably around 10-20 minutes, for me to send EXTEND.fth to my propeller at 115200 baud with 20ms line delays. What's the absolute minimum for line delays? If it's to allow stuff you're dumping into it to take a while to run loops and such, could you consider adding soft flow control to the serial driver as an alternative, so delays only happen when necessary? If I get around to adding soft flow control to the serial driver, I'll give you the patch.

TRIM byte 0[$wxyz - $] should be as big as possible to still fit in hubram, right? What if it's not as big as possible? Does some ram near the top or somewhere else get wasted or what?

Thanks,
electrodude

20 ms line delay is not 20 ms character delay which should be zero, a common mistake. XON/XOFF is not properly supported on PCs it seems, they just never seem to respond since they have such huge FIFOs which do not look ahead for XOFFs.

As for the website demo I just brought it up on another PC over a weak wifi link and it came up instantly and just the other day I did the same from a remote location without any problems. But the webserver can only handle one connection at a time since the TCP/IP stack is implemented in the WIZnet although it is possible to open a socket in raw mode but then there is a lot more processing to do then.

Tachyon can work out of one cog without having to startup another cog just for a PASM function which even if it were in another cog would still require passing commands to it and waiting for responses. In many cases it is just as easy to call the function directly in the same cog which also doesn't have any problems with I/O pin conflicts that can result. Of course I could come up with a grand and complicated scheme but what am I trying to achieve then? I have a fast and fully functional system already.

Now "little grasshopper", take your time and when you find that you can't understand why it's done a certain way or why it isn't working the way you think it should then think that there must be good reason for it, and if there isn't, you will find out why. Once you take the time to find out why then you start to understand. You may start trying to improve what you don't understand but will you really improve it then? The idea with Tachyon is that you don't need to write special PASM drivers, that Forth is fast enough to tackle the I/O directly or in unison with a RUNMOD which is really just a microcoded instruction anyway.

Just getting back to the pin defintion file, it's usually best to define your own PCB (hardware definitions) file a bit like the QS.fth example so that you are not modifying a generic SDCARD.fth file directly. The defaults in SDCARD are simply in case no other pins have been defined. That way you can always use the very latest support files without modifications.

As for TRIM it is there to put the dictionary and buffers/cog image up at the top of memory where the dictionary grows down while the code space grows upwards. That space that's in there gets used as you add more modules and your application.

[Electrodude]

Hello, who is the SD-Karte on the PIN for Tachyon from Propeller?
DO DI CLK CS ?

greeting

The pin configuration for an SD card is near the top of SDCARD.fth:
IFNDEF &SDCS
#P26 |< == &SDCS \ SDCARD CS
#P27 |< == &SDDO \ Data out from SDCARD
#P28 |< == &SDCK \ SDCARD clocks (Shared with SCL)
#P29 |< == &SDDI \ Data to SDCARD (Shared with SDA)
}

Change the #Pxx to whatever you want. I just figured this out 15 minutes before seeing your question.


@Peter Jakacki:
I want to use Tachyon for something resembling a home security/monitoring system. I've come up with several questions while looking at Tachyon's guts:

Why don't the SD card and Wiznet drivers run in their own PASM cogs? Wouldn't that be way faster? I was playing with your Tachyon website demo, and it seemed really slow, but that might have only been because too many people were trying to use it at once. I'm experimenting with adding PASM drivers now, even though it's probably not a good beginner's project for someone just starting FORTH.

Also, what's with the huge line delays? Are they really necessary? What's the shortest I can safely make them? It took much longer than my patience lasts for file transmission, probably around 10-20 minutes, for me to send EXTEND.fth to my propeller at 115200 baud with 20ms line delays. What's the absolute minimum for line delays? If it's to allow stuff you're dumping into it to take a while to run loops and such, could you consider adding soft flow control to the serial driver as an alternative, so delays only happen when necessary? If I get around to adding soft flow control to the serial driver, I'll give you the patch.

TRIM byte 0[$wxyz - $] should be as big as possible to still fit in hubram, right? What if it's not as big as possible? Does some ram near the top or somewhere else get wasted or what?

Thanks,
electrodude

[KMyers]

Yes Peter I pretty much decided the terminal is much better considering the memory issue. Will study and play!

[funkheld]

Hello, who is the SD-Karte on the PIN for Tachyon from Propeller?
DO DI CLK CS ?

greeting

[Peter Jakacki]

@Peter,

Watched your videos and downloaded to my C3. Very impressive and FAST. Played with Forth back in the TRS 80 days and found I didnt retain much over the years. Still playing and have set it to the VGA port on the C3. Where would I look for that?

Nice work BTW!!!!!

If you follow the links in my sig you will find source code, binaries, and more links to the early VGA versions up to the most recent. The early versions included VGA as it was still a nascent kernel and quite small but with only 32K of RAM to play with the bit-mapped VGA made it impossible to add all the extra functionality that was later added. I may include a small text based VGA driver in my upcoming runtime OBEX but I'm leaving all the fancy memory hungry VGA stuff for P2 when I can implement a fully self-hosted development system which can also compile/assemble new kernels.

[KMyers]

@Peter,

Watched your videos and downloaded to my C3. Very impressive and FAST. Played with Forth back in the TRS 80 days and found I didnt retain much over the years. Still playing and have set it to the VGA port on the C3. Where would I look for that?

Nice work BTW!!!!!

[Peter Jakacki]

Hi Peter,

seems the END statistics has problem after a RECLAIM

{Reclaimed 1,552 bytes
NAMES:  $557A...7442 for 7880 (4294965744 bytes added)
CODE:   $0000...4CAE for 11750 (4294967286 bytes added)
CALLS:  0122 vectors free
RAM:    2252 bytes free


after load


NAMES:  $54F8...7442 for 8010 (4294965874 bytes added)
CODE:   $0000...4D42 for 11768 (0148 bytes added)
CALLS:  0102 vectors free
RAM:    1974 bytes free
}

An unintended side effect of RECLAIM but the GoogleDocs version of EXTEND at least printed this out as a signed number
Sometimes "helpful" information like this can be a bit awkward to report, as when do you count it being added and from what point etc. I think I may look at tidying this up a little and also only have it reporting after changes are made then muting any results thereafter. So perhaps even a new definition could report it's size.

[Peter Jakacki]

Peter:

The REVECTOR command does not work as described.

NickL

Nick, I'm sure you've found yourself in a situation where someone comes to you for technical assistance telling you that something "does not work". "What do you mean" you may ask. In this case is the description wrong or do you have a sample of what it is that doesn't work?

REVECTOR can only work when a word has a vector as in the case of bytecode constructed from opcodes, the kernel opcodes themselves do not have vectors so you can't revector DUP for instance.

Here is a quick demonstration of REVECTOR at work changing the low-level SPACE word to print a dot instead:

: DOT  "." EMIT ;  ok
DOT . ok
REVECTOR SPACE DOT. ok
0 20 DUMP.
0000_0000:   00.B4.C4.04. 6E.4E.10.00.  78.7E.80.7E. 4C.7E.84.7E.  ....nN..x~.~L~.~
0000_0010:   68.7E.02.00. 3C.7E.00.00.  B3.5B.70.01. 82.00.00.00.  h~..<~...[p..... ok
.STATS.
NAMES:  $5C8C...74CF for 6211 (3758 bytes added)
CODE:   $0000...35CE for 7563 (7374 bytes added)
CALLS:  0446 vectors free
RAM:    9918 bytes free
 ok

[MJB]

Peter:

The REVECTOR command does not work as described.

NickL

I used it many times - and it WORKED

you need to be more specific.

What system configuration and SW loaded.
Example of percieved problem.

[nglordi]

Peter:

The REVECTOR command does not work as described.

NickL

[MJB]

Hi Peter,

seems the END statistics has problem after a RECLAIM

{Reclaimed 1,552 bytes
NAMES:  $557A...7442 for 7880 (4294965744 bytes added)
CODE:   $0000...4CAE for 11750 (4294967286 bytes added)
CALLS:  0122 vectors free
RAM:    2252 bytes free


after load


NAMES:  $54F8...7442 for 8010 (4294965874 bytes added)
CODE:   $0000...4D42 for 11768 (0148 bytes added)
CALLS:  0102 vectors free
RAM:    1974 bytes free
}

[Loopy Byteloose]

Forth is an excellent language to explore a new device interactively. So I am getting back into Tachyon in anticipation of it helping me with the Propeller2.

I've now got my Propeller1 running over a wifl link in anticipation of doing the same with a Propeller 2. Not much else to report as I do have to really settle in and catch up will all Peter J has created (and that is a heck of a lot).

[David Betz]

why only to an unexpanded Propeller ??

the more the Propeller gets expanded the better:
WizNet -> NW, FTP, TELNET, HTTP
Loads of Sensors & Actors
PWM
Motor Controller
...

I forgot SD Filesystem, 4GB virtual memory

Sorry, what I meant was a Propeller without any extended memory like what would be needed to run something like JavaScript or even Python or Lisp. Tachyon makes very efficient use of the 32k of hub memory in P1 and packs in a lot more functionality than would likely be possible with so-called higher level languages. Of course hardware peripherals are necessary on pretty much any embedded system!

[MJB]

I've had fun playing with Tachyon today. It is certainly true that an interactive language is a very powerful tool. While Forth would probably not be my first choice, it is will suited to an unexpanded Propeller and Tachyon seems to be a very capable system. Now I need to get to work on a real Forth project! :-)

why only to an unexpanded Propeller ??

the more the Propeller gets expanded the better:
WizNet -> NW, FTP, TELNET, HTTP
Loads of Sensors & Actors
PWM
Motor Controller
...

I forgot SD Filesystem, 4GB virtual memory

[David Betz]

I've had fun playing with Tachyon today. It is certainly true that an interactive language is a very powerful tool. While Forth would probably not be my first choice, it is will suited to an unexpanded Propeller and Tachyon seems to be a very capable system. Now I need to get to work on a real Forth project! :-)

[David Betz]

Does this look like a successful load of EXTEND.fth?

00:00:00  End of source code, 1481 lines processed and .0001 errors found 
MODULES LOADED: 
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 140723-14OO


NAMES:  $5C20...7442 for 6178 (3741 bytes added)
CODE:   $0000...3511 for 7407 (7313 bytes added)
CALLS:  0452 vectors free
RAM:    9999 bytes free
. ok
\ 
EEPROM  9600d SERBAUD  ok
?BACKUP  ok
Published

I got a message in the middle saying this:

0552 

 --> Screenshot <-- not found .

0553

Is this a problem?

Thanks,
David

Never mind. My problem had to do with cutting and pasting from Safari. I went to the Tachyon DropBox folder and got EXTEND.fth directly and it loads fine. Sorry for the false alarm!

[David Betz]

Does this look like a successful load of EXTEND.fth?

00:00:00  End of source code, 1481 lines processed and .0001 errors found 
MODULES LOADED: 
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 140723-14OO


NAMES:  $5C20...7442 for 6178 (3741 bytes added)
CODE:   $0000...3511 for 7407 (7313 bytes added)
CALLS:  0452 vectors free
RAM:    9999 bytes free
. ok
\ 
EEPROM  9600d SERBAUD  ok
?BACKUP  ok
Published

I got a message in the middle saying this:

0552 

 --> Screenshot <-- not found .

0553

Is this a problem?

Thanks,
David

[D.P]

Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.

This is exactly what I was looking for recently, just bumping this for safe keeping.

[MJB]

I've been playing with Tachyon a bit today and was wondering if there is a way to list the available words without first loading EXTEND.fth? In other words, I'm looking for a list of the core words before any extensions are loaded. I had thought WORDS would do that but it doesn't seem to be one of the core words.

Hi David,

while Peter is surely right...

the curious mind whats to know.

You can easily search the kernel source for DICTIONARY to see the words.

In doing this I every now and then discover a 'new' word, which is not part of my active vocabulary yet.

so it's very educating too


btw: the Tachyon scriptable dynamic webserver with AJAX will be there soon.


AND: please, again, all of you - choose meaningful post titles - just click 'REPLY to THREAD' instead of REPLY to previous unrelated post !!!

[David Betz]

Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.

Wow! Lots of options. Tachyon is certainly a very complete package unlike the simple Basic interpreters I've created for the Propeller that are really more of a proof-of-concept. Thanks for your help!

David

[Peter Jakacki]

I guess I was looking for a way to create a binary myself with whatever collection of Forth words I want including EXTEND.fth. Not a big deal. I'll figure out my terminal settings so I can get it loaded from CoolTerm or maybe I'll just move over to Linux and use minicom.

Maybe that's where my confusion came. I think I was watching your Tachyon tutorial video that was clearly marked as being out of date.

Thanks for your help!

David

Once you load the binary you can still load in your own EXTEND.fth version and any other modules etc. Normally the modules all start with a FORGET <this module> command in case it already exists so there is no need to do anything special. However EXTEND.fth is really part of the kernel so if you try to load it in when it is already loaded it will perform a COLD which will reset the kernel in RAM back to it's precompiled state. If you want to create your own binary you can us the DUMPROM command which will fix the boot checksum in EEPROM and dump the EEPROM as a Intel hex file. I normally just copy this into a text file and save it as a .HEX file and run a HEXBIN utility then rename the BIN file to .binary to keep the Spin tool happy. Of course if you an SD card in your system then it is far simpler as you just type SAVEROM into a empty FIRMWARE.ROM file. Again, if you have EASYNET loaded and running you can easily read the FIRMWARE.ROM file over FTP and in fact this is also one way in which I disseminate new firmware.

[David Betz]

I normally use 12ms line delay and never ever a character delay but as for having EXTEND preloaded that's what the binary images are for in the DropBox.

I guess I was looking for a way to create a binary myself with whatever collection of Forth words I want including EXTEND.fth. Not a big deal. I'll figure out my terminal settings so I can get it loaded from CoolTerm or maybe I'll just move over to Linux and use minicom.

BTW, very early versions of Tachyon had WORDS and extras precompiled but as mentioned this is much better handled by Forth itself.

Maybe that's where my confusion came. I think I was watching your Tachyon tutorial video that was clearly marked as being out of date.

Thanks for your help!

David

[Peter Jakacki]

Okay, no problem. That makes a lot of sense. I had just thought I saw a video somewhere that showed a way to list the core words even before loading EXTEND.fth. I must have been dreaming! :-)

I actually did try loading EXTEND.fth but the load failed somewhere in the middle. This is probably due to using the CoolTerm terminal emulator on the Mac. I tried setting the line delay to 20ms as suggested in your document but I'm not sure that was enough. Is it possible that I also need to add a character delay? Is there any way to create a copy of Tachyon with EXTEND.fth preloaded without having to blast characters over the serial connection?

I normally use 12ms line delay and never ever a character delay but as for having EXTEND preloaded that's what the binary images are for in the DropBox. I may just update this too but there is a fairly recent one there in the binaries folder from the 8th which just includes EXTEND.fth. The startup automatically detects 5 or 10MHz crystal configurations and adjusts the PLL accordingly. Default baud is 230400 of course.

BTW, very early versions of Tachyon had WORDS and extras precompiled but as mentioned this is much better handled by Forth itself.

[David Betz]

I try to keep the precompiled kernel tight, just the minimum that's required as it's easy to write Forth in Forth rather than as "bytes" within the rather limited Spin/PASM compiler. So always consider EXTEND.fth as part of the kernel that although it gets compiled by the 1st stage kernel, it is nonetheless the other half of the kernel, albeit that there is a lot of extra stuff in there. Remember too that the EEPROM utilities are all defined in EXTEND.fth and you really need that too.

Okay, no problem. That makes a lot of sense. I had just thought I saw a video somewhere that showed a way to list the core words even before loading EXTEND.fth. I must have been dreaming! :-)

I actually did try loading EXTEND.fth but the load failed somewhere in the middle. This is probably due to using the CoolTerm terminal emulator on the Mac. I tried setting the line delay to 20ms as suggested in your document but I'm not sure that was enough. Is it possible that I also need to add a character delay? Is there any way to create a copy of Tachyon with EXTEND.fth preloaded without having to blast characters over the serial connection?

[Peter Jakacki]

I've been playing with Tachyon a bit today and was wondering if there is a way to list the available words without first loading EXTEND.fth? In other words, I'm looking for a list of the core words before any extensions are loaded. I had thought WORDS would do that but it doesn't seem to be one of the core words.

I try to keep the precompiled kernel tight, just the minimum that's required as it's easy to write Forth in Forth rather than as "bytes" within the rather limited Spin/PASM compiler. So always consider EXTEND.fth as part of the kernel that although it gets compiled by the 1st stage kernel, it is nonetheless the other half of the kernel, albeit that there is a lot of extra stuff in there. Remember too that the EEPROM utilities are all defined in EXTEND.fth and you really need that too.

[Loopy Byteloose]

Hi all,
Lately I have been fooling around with very tiny WR703N and MR3020 wireless routers as a means to load and communicate with my Propeller Protoboard. They are about 2 inches by 2 inches by 1/2 inch high.

http://wiki.openwrt.org/toh/tp-link/tl-wr703n

Yesterday, I managed to get my tiny MR3020 to download and install Tachyon V2.1 via the wifi, and then to bring up the Tachyon prompt. I did have to use a USB2SER on the USB port, but am working also on just a straight ttl RS232 setup from the MR3020 to the Propeller.

So it seems a nice fit for Forth over wifi.

These devices are only about $20USD, consume about 0.6 watts at 5VDC. and have OpenWrt firmware modifying them into a very handy custom wifi router. Someone has even claimed to use solar cells to power the wifi router, certainly seems easy enough to do.

Heater recompiled propeller-load, a command line binary loader that sits inside the wifi router's Linux OS. So it makes it possible to SCP a binary to the router, and then load it to the Propeller. I also loaded Minicom and an FTDI USB serial driver into the router, and that completes the set up to allow active Tachyon from afar.

I think I am going to enjoy this a lot. You can have a Propeller attached to anything and sitting anywhere. When you want to change something, you bring up the wifi router, enter Minicom, and you are into Tachyon of the device.

OpenWrt also adds another dimension to Tachyon as wifi can be deployed in a variety of ways to network Propellers.

[David Betz]

I've been playing with Tachyon a bit today and was wondering if there is a way to list the available words without first loading EXTEND.fth? In other words, I'm looking for a list of the core words before any extensions are loaded. I had thought WORDS would do that but it doesn't seem to be one of the core words.

[Peter Jakacki]

Tachyon moves so fast I can find words it seems, even with the help of grep. Seems it should be defined in W5100.fth but no joy?

Never mind, found it.

Try QWORDS just for a quick and compact words listing or even QW just for those last 100 or so words.
There''s also HELP <word> which in the next version will also list the stack and description etc (as long as you have >32K EEPROM or SD). Maybe I might even have it find the source for the word and list it if it's loaded onto a file.

LIKE <word> WORDS/QWORDS/QW will list all words which have the same attributes such as kernel or extended kernel etc words.
ANY <char> WORDS/QWORDS/QW will list any words that have a matching character
MY WORDS/QWORDS/QW will just list the latest module words
MATCH <chars> WORDS/QWORDS/QW will list matching words that start with the same characters

All these may be replaced with a more general pattern mask when I get a round tuit.

I can see by your post though that I may need to implement WHICH WORDS just to find out what you are talking about

(I may need to check the operation of these controls as I haven't used them in some time)

[D.P]

Tachyon moves so fast I can find words it seems, even with the help of grep. Seems it should be defined in W5100.fth but no joy?

Never mind, found it.

[Peter Jakacki]

Right again, but the code states:

\ I2C STOP CONDITION also releases I2C lines
pub I2CSTOP
    SDA OUTCLR SCL OUTSET 0 DROP SDA OUTSET        \ Patch 140319 - leave SDA as a high output (in case it's shared)
     0 DROP                        \ short delay
    ;

So I'll add

pub I2CCLR
   SDA OUTCLR SCL OUTCLR
   ;

Yes, but perhaps this could just be added to I2CSTOP after a few microseconds, but what if we let it float, so:
pub I2CSTOP
SDA OUTCLR SCLR OUTSET 0 DROP SDA OUTSET 1 us SCL INPUTS SDA INPUTS
;
Note: 1 us is actually around 10 us (overhead)

[D.P]

Right again, but the code states:

\ I2C STOP CONDITION also releases I2C lines
pub I2CSTOP
    SDA OUTCLR SCL OUTSET 0 DROP SDA OUTSET        \ Patch 140319 - leave SDA as a high output (in case it's shared)
     0 DROP                        \ short delay
    ;

So I'll add

pub I2CCLR
   SDA OUTCLR SCL OUTCLR
   ;

[Peter Jakacki]

I am missing something basic trying to use the I2C bus from another cog.

I have my allocated space for stack and regs, I am using the standard I2C bus pins which are initialized in I2CSTART,
the routine works as expected when not in a task, then in the task I get zero output as seen by my logic analyzer?

Same ol, same ol, this is the OR'd port pin from the main cog still driven high so you need to release the I2C lines before passing control to another cog. Remember, any cog can set a pin high but another cog cannot pull it down. Either keep the output low in the unused cog or release the DIRA bits. Actually it probably wouldn't really hurt leaving these lines low after an I2CSTOP so I might look at doing that instead.

[D.P]

I am missing something basic trying to use the I2C bus from another cog.

I have my allocated space for stack and regs, I am using the standard I2C bus pins which are initialized in I2CSTART,
the routine works as expected when not in a task, then in the task I get zero output as seen by my logic analyzer?

[D.P]

This inline assembler is just about complete although I still have to resolve how to handle CALL and possibly forward references (in one pass). With all PASM opcodes defined the assembler takes up around 1400 bytes including headers and code. The interesting thing with this assembler is that it just uses the normal Forth parsing technique but TF has a few flexible hooks whereby I can tell it what to do at the start and at the end of a line as well as what to do when it comes across a word that is not in the dictionary nor is it a number. So labels are unknown when Forth first parses them but the "unum" vector which optionally processes unresolvable words points to code that creates a constant using the current origin truncated to 9-bits.

So far so good, I will soon embark on allowing PASM code to be loaded in the same way as source code but have the code saved in a EEPROM or SD file for the runtime OBEX. I've kept it simple with the "corg" directive so it assembles to the BUFFERS area for instance and the lower 9-bits of the address are the same as the assembled cogs address. The object code would then be saved in a file to free up the storage and remove the label constants.The code would include an OBEX name such as "UART4" and at runtime we could load a cog simply by saying " UART4" 2 LOADCOG or " FPU" 5 LOADCOG for instance. With any existing PASM code there is very little modification required to make this work, mostly I just include a space after an immediate # for instance. Normal Forth operations and calculations can be intermixed with PASM even on the same line, this is a macro-macro-assembler!

The implications for P2 are somewhat obvious too, it also means the system can be standalone and even metacompile it's own kernel.

DAT 
 403C: 
 403C:                          corg    $41C0
 41C0:                  unext       res    1
 41C4:                  instr       res    1
 41C8:                  IP          res    1
 41CC:                  R0          res    1
 41D0:                  
 41D0:                          corg    $4000
 4000:                  doNEXT
 4000: 00BF.89C8                    rdbyte  instr,IP    
 4004: 81FF.9001                    add     IP,# 1 wc    
 4008: 5C3F.89C4                    jmp     instr        
 400C:                  
 400C:                  _STREND        
 400C: 00BF.99B1        fchlp       rdbyte  R0,tos    ( read a byte )
 4010: 84FF.9801                    sub     R0,# 1    ( end is either a null or anything >$7F )
 4014: 857F.987E                    cmp     R0,# $7E wc
 4018: 80F3.6201              if_c  add     tos,# 1
 401C: 5C70.180C              if_c  jmp     # fchlp
 4020: 5C3F.81C0                    jmp     unext
 4024:                  
 4024:                  
 4024:                  { 
 4024: 00BF.63B1        CFETCH      rdbyte  tos,tos
 4028: 5C3F.81C0                    jmp     unext
 402C:                  
 402C:                  { 
 402C: 04BF.63B1        WFETCH      rdword  tos,tos
 4030: 5C3F.81C0                    jmp     unext
 4034:                  
 4034:                  { 
 4034: 08BF.63B1        FETCH       rdlong  tos,tos
 4038: 5C3F.81C0                    jmp     unext
                        ENDDAT ok

Wow, 1400 bytes, access to obex pasm objects, P2 Tachyon being able to "self host". And all "we" did was make a little nudge for FPU pasm access. Uh looks like you are having fun so I'll just shut up and keep studying the code. Thanks Peter

[Peter Jakacki]

This inline assembler is just about complete although I still have to resolve how to handle CALL and possibly forward references (in one pass). With all PASM opcodes defined the assembler takes up around 1400 bytes including headers and code. The interesting thing with this assembler is that it just uses the normal Forth parsing technique but TF has a few flexible hooks whereby I can tell it what to do at the start and at the end of a line as well as what to do when it comes across a word that is not in the dictionary nor is it a number. So labels are unknown when Forth first parses them but the "unum" vector which optionally processes unresolvable words points to code that creates a constant using the current origin truncated to 9-bits.

So far so good, I will soon embark on allowing PASM code to be loaded in the same way as source code but have the code saved in a EEPROM or SD file for the runtime OBEX. I've kept it simple with the "corg" directive so it assembles to the BUFFERS area for instance and the lower 9-bits of the address are the same as the assembled cogs address. The object code would then be saved in a file to free up the storage and remove the label constants.The code would include an OBEX name such as "UART4" and at runtime we could load a cog simply by saying " UART4" 2 LOADCOG or " FPU" 5 LOADCOG for instance. With any existing PASM code there is very little modification required to make this work, mostly I just include a space after an immediate # for instance. Normal Forth operations and calculations can be intermixed with PASM even on the same line, this is a macro-macro-assembler!

The implications for P2 are somewhat obvious too, it also means the system can be standalone and even metacompile it's own kernel.

DAT 
 403C: 
 403C:                          corg    $41C0
 41C0:                  unext       res    1
 41C4:                  instr       res    1
 41C8:                  IP          res    1
 41CC:                  R0          res    1
 41D0:                  
 41D0:                          corg    $4000
 4000:                  doNEXT
 4000: 00BF.89C8                    rdbyte  instr,IP    
 4004: 81FF.9001                    add     IP,# 1 wc    
 4008: 5C3F.89C4                    jmp     instr        
 400C:                  
 400C:                  _STREND        
 400C: 00BF.99B1        fchlp       rdbyte  R0,tos    ( read a byte )
 4010: 84FF.9801                    sub     R0,# 1    ( end is either a null or anything >$7F )
 4014: 857F.987E                    cmp     R0,# $7E wc
 4018: 80F3.6201              if_c  add     tos,# 1
 401C: 5C70.180C              if_c  jmp     # fchlp
 4020: 5C3F.81C0                    jmp     unext
 4024:                  
 4024:                  
 4024:                  { 
 4024: 00BF.63B1        CFETCH      rdbyte  tos,tos
 4028: 5C3F.81C0                    jmp     unext
 402C:                  
 402C:                  { 
 402C: 04BF.63B1        WFETCH      rdword  tos,tos
 4030: 5C3F.81C0                    jmp     unext
 4034:                  
 4034:                  { 
 4034: 08BF.63B1        FETCH       rdlong  tos,tos
 4038: 5C3F.81C0                    jmp     unext
                        ENDDAT ok

[Peter Jakacki]

I've had a little time to play a bit more and expand and optimize the resident assembler and considering it's only taking 290 code bytes of storage so far I think I'm doing well. Here's what a listing looks like at the moment and remember that this is interactive on the Prop through the serial terminal but what I want to do is add forward referencing and try to standardize the assembler format closer to how PASM is written in Spin.

DAT     
 0200:      
 0200:                          corg    $41C0    
 41C0:              :: outmask  res    1
 41C4:              :: modeMux  res    1
 41C8:              :: freq4    res    1
 41CC:              :: lcnt     res    2
 41D4:              
 41D4:                          corg    $4000    
 4000: 80FF.6201                add    tos,# 1
 4004: 81EB.6201          if_z  add    tos,# 1 wc
 4008: 60FF.6227                and    tos,# 100111b
 400C: 00B3.63B1          if_c  rdbyte tos,tos    
 4010: 80FF.6404                add    tos 1+,# 4
 4014:              :: loop
 4014: A0FF.9908                mov    lcnt,# 264
 4018:              :: leds
 4018: 2CFF.F801                shl    PHSA,# 1        
 401C: 2CFF.F801                shl    PHSA,# 1        
 4020:              :: fspi
 4020: A0BF.EDC0                mov    DIRA,outmask
 4024: A0FF.E800                mov    OUTA,# 0
 4028: A0BF.F1C4                mov    CTRA,modeMux
 402C: A0BF.F7C8                mov    FRQB,freq4
 4030: A0FF.F200                mov    CTRB,# 0
 4034: 047F.9818                djnz   lcnt,# leds 
 4038: 5C7C.0014                jmp    # loop
 403C:            

EDIT: updated the listing again, I can see that I can remove the :: for labels if I allow the "not found" error handler to create a label, simple. Getting closer.

[Peter Jakacki]

I've been working on V2.4 of the kernel which removes the CMPSTR memory hog from the cog kernel to save memory for other things but it can still run as a RUNMOD during a block mode compiling. I've also added an OPCODE construct that works just like CONSTANT in that you can create an OPCODE word which when invoke is executed as that PASM operation.

\ Example of creating an OPCODE that runs as a PASM instruction when invoked.
$80FF6204 OPCODE ADD4 --- ADD tos,#4

Testing this:
1200 ADD4 . 1204 ok


While playing with the OPCODE word I wondered how much trouble it would be to have a simple inline assembler so I wouldn't have to work out the machine code but could type it in as normal assembly code. Yes, normal assembly code, pretty much. Here's a quick little assembler I have just been playing with and the results of a few quick test codes reveals works quick well. This may be used for assembling OBEX code for my runtime OBEX in EEPROM or SD but rather than take up code memory for something that only gets used during devlelopment I may store the mnemonics and opcodes on an SD file or EEPROM instead.

( Demo assembler for Tachyon Forth )
\ this assembler is being tested but generates code interactively from the console

\ define some conditional execution words
BYTE    ce
: CE       ce C! ;
: if_z     1010b CE ;
: if_nz    0101b CE ;
: if_c     1100b CE ;
: if_nc    0011b CE ;

\ define some PASM instructions 
LONG op
: OP    op ! ;
: add        100000_0010b OP ;
: and        011000_0010b OP ;
: rdbyte     000000_0010b OP ;

\ alias for top-of-stack
STACKS    == tos

\ define some results modifiers
BYTE sr
: SR+    sr C@ OR sr C! ;
: SR-    NOT sr C@ AND sr C! ;
( with results - zcri )
: wc    0100b SR+ ;
: wz    1000b SR+ ;
: nr    0010b SR- ;
: #     0001b SR+ ;

\ The assembler itself - console prompt is revectored to this so all final assembly is carried out on an end-of-line
: ASSEMBLE    
    BEGIN HERE 3 AND WHILE 1 ALLOT REPEAT
    op @ IF 
      SWAP 9 SHL OR op @ #22 SHL OR sr C@ #22 SHL OR ce C@ #18 SHL OR 
      4 ALLOT ( just allot the memory for now, do not store )
      "A" 1 VC SPACE HERE .WORD ." : " .LONG CR
     THEN 
    $0F CE 0 OP 0 sr C!
    ; 

: ASMCODE    ' ASSEMBLE prompt W! "," delim C! "`" NFA' # 1+ C! ' CR prompt 2+ W! ;


\ Now let's try to assemble some code 

    ASMCODE
                add    tos,#,1 
        if_z    add    tos,#,1 wc
                and    tos,#,0111
        if_c    rdbyte tos,tos     
                add    tos 1+,#,4
    

The result when run and when compared against code generated by a Spin compiler

{ Results from test code
         ASMCODE
 3758: 80FF.6201         add     tos,#,1 
 3768: 81EB.6201 if_z    add     tos,#,1 wc
 3775: 60FF.6227         and     tos,#,100111b
 3784: 00B3.63B1 if_c    rdbyte  tos,tos          
 3791: 80FF.6404         add     tos 1+,#,4
}

{ Results from Spin compiler
7E4C(0051) 01 62 FF 80 |        ADD        tos,#1
7E50(0052) 01 62 EB 81 |         if_z   ADD        tos,#1        wc
7E54(0053) 27 62 FF 60 |                AND        tos,#100111b
7E58(0054) B1 63 B3 00 |         if_c   RDBYTE     tos,tos                ' same thing as a C@
}

[max72]

Thanks Peter.
In fact my original code was a rather primitive test.
I had the two bytes composing the acceleration, and the result from the datasheet is in 2's complement. So I simply shifted left until the acceleration sign bit reached the bit 32, and let spin handle the rest...

Seeing how you code things is a great learning opportunity. The final result is so elegant and effective..
Thanks again.
Massimo

[Peter Jakacki]

: AFIX ( hb lb -- result )              SWAP B>W 16 SHL $28FF680E PASM DROP ABS ;

Here they be dragons!

Actually that should have been a $38FF680E hex dragon in this example!

I'm actually allocating a new opcode called MYOP which can be user set easily. By default I use it for fast cropping (<mask> AND) but in this example I would init MYOP with $38FF680E ' MYOP COG! after which I just run AFIX like this:
: AFIX ( hb lb -- result ) --- SWAP B>W 16 SHL MYOP ABS ;

Of course the final example used:
: AFIX ( hb lb -- result ) SWAP B>W 16 SHL $38FF6812 PASM DROP ;
So that would convert to:
: AFIX ( hb lb -- result ) SWAP B>W 16 SHL MYOP ;
In this case MYOP is preset to perform a ~>18 or SAR tos,#18

[D.P]

Thanks Peter!
I'll give it a run tonight, and I'll try to digest it all :-)

Just a question:
I was thinking about combining the two bytes and testing bit 16 for the sign. Would it works too?
After all I need to combine the two bytes, get the sign, ABS it, and have it less than say 16-18 bits.
Maybe it's the right occasion to do some experiments :-)

Massimo

: AFIX ( hb lb -- result )              SWAP B>W 16 SHL $28FF680E PASM DROP ABS ;

Here they be dragons!

[Peter Jakacki]

Thanks Peter!
I'll give it a run tonight, and I'll try to digest it all :-)

Just a question:
I was thinking about combining the two bytes and testing bit 16 for the sign. Would it works too?
After all I need to combine the two bytes, get the sign, ABS it, and have it less than say 16-18 bits.
Maybe it's the right occasion to do some experiments :-)

Massimo

I'm not quite sure what result you are looking for but I just had a look at the datasheet and the raw data is 14-bit signed left justified so that the 2 lsbs are zeros. Why are you converting these to an absolute value? Surely you would want it signed?

If raw value = $7FFC then this is the maximum positive value of 8191
$FFFC = -1

So just get the raw 16-bit word and shift it right 2 bits then test bit 13 to see if it's set and if it is then just subtract $4000 from it like this (assuming signed result though):

: AFIX ( hb lb -- result ) SWAP B>W 2 SHR DUP $2000 AND IF $4000 - THEN ;

\ test data by supplying max+ -1 max-
$7F $FC AFIX . 8191 ok
$FF $FC AFIX . -1 ok
$80 $00 AFIX . -8192 ok

An alternative AFIX using the signed shift right operator (implemented as a PASM opcode)
: AFIX ( hb lb -- result ) SWAP B>W 16 SHL $38FF6812 PASM DROP ;

[max72]

Thanks Peter!
I'll give it a run tonight, and I'll try to digest it all :-)

Just a question:
I was thinking about combining the two bytes and testing bit 16 for the sign. Would it works too?
After all I need to combine the two bytes, get the sign, ABS it, and have it less than say 16-18 bits.
Maybe it's the right occasion to do some experiments :-)

Massimo

[Peter Jakacki]

:-)
Not really..
I realised I can do with neithe FPU or trig/cordic.. :-)
That was just a post to say unconditionally thank you.. with no extra requests ;-)

I'm using also the nokia LCD, and the code available is a nice help.

I would like to convert my current relevant spin code to Tachyon... the data come in 2's complement so that would offer me the possibility to learn more.. :-)
I'm using the accelerometer to get the height of a tree. I "look" at it at known distance, and I get back an approximate height.

The key code is the following:

  repeat
      i2c.i2cstart
      k:=i2c.i2cwrite(accel_w)
      k:=i2c.i2cwrite(1)  
      i2c.i2cstart
      k:=i2c.i2cwrite(accel_r)
      accel_x:=i2c.i2cread(0)
      accel_x:=accel_x<<8
      accel_x:=accel_x+i2c.i2cread(0)
      accel_x:=accel_x<<16
      accel_y:=i2c.i2cread(0)
      accel_y:=accel_y<<8
      accel_y:=accel_y+i2c.i2cread(0)
      accel_y:=accel_y<<16
      accel_z:=i2c.i2cread(0)
      accel_z:=accel_z<<8
      accel_z:=accel_z+i2c.i2cread(1)
      accel_z:=accel_z<<16
      i2c.i2cstop
      accel_x:=accel_x~>14
      accel_y:=accel_y~>14
      accel_z:=accel_z~>14
      ||accel_z
      ||accel_y
      ||accel_x
      pst.char(13)
      pst.dec(accel_x)
      pst.char(" ")
      pst.dec(accel_y)
      pst.char(" ")
      pst.dec(accel_z)
      pst.char(" ")
      pst.str(string(" -> "))
      var1:=dist*accel_y/accel_z
      pst.dec(var1)
[

Okay, I won't take the hint then

Here is your code transposed with Forth for a nice side by side comparison and then at the end how you can code it. I noticed that I did not have the equivalent of a arithmetic right shift ~> and so I combined all those shifts and absolute ops into one definition and here is how it looks:

 repeat                                                BEGIN
      i2c.i2cstart                                        I2CSTART
      k:=i2c.i2cwrite(accel_w)                            @accel I2C!                @accel is the 8-bit i2c address
      k:=i2c.i2cwrite(1)                                  1 I2C!
      i2c.i2cstart                                        I2CSTART
      k:=i2c.i2cwrite(accel_r)                            @accel 1+ I2C!                read address is always write address+1
      accel_x:=i2c.i2cread(0)                             0 I2C@
      accel_x:=accel_x<<8                                 8 SHL
      accel_x:=accel_x+i2c.i2cread(0)                     0 I2C@ +
      accel_x:=accel_x<<16                                16 SHL #14 ~> ABS        x - justify and sign extend then convert to abs        
      accel_y:=i2c.i2cread(0)                             0 I2C@
      accel_y:=accel_y<<8                                 8 SHL
      accel_y:=accel_y+i2c.i2cread(0)                     0 I2C@ +
      accel_y:=accel_y<<16                                16 SHL #14 ~> ABS        y
      accel_z:=i2c.i2cread(0)                             0 I2C@
      accel_z:=accel_z<<8                                 8 SHL
      accel_z:=accel_z+i2c.i2cread(1)                     1 I2C@ +
      accel_z:=accel_z<<16                                16 SHL #14 ~> ABS        z
      i2c.i2cstop                                         I2CSTOP
      accel_x:=accel_x~>14                                                        combined in previous ops
      accel_y:=accel_y~>14                
      accel_z:=accel_z~>14
      ||accel_z
      ||accel_y
      ||accel_x
      pst.char(13)                                        CR
      pst.dec(accel_x)                                    ROT .DEC
      pst.char(" ")                                       SPACE
                                                          2DUP                    keep a copy of y and z
      pst.dec(accel_y)                                    SWAP .DEC
      pst.char(" ")                                       SPACE
      pst.dec(accel_z)                                    .DEC
      pst.char(" ")                                       SPACE
      pst.str(string(" -> "))                             PRINT"  -> "
      var1:=dist*accel_y/accel_z                          / dist @ *              divide x by y on stack then multiply by dist variable
      pst.dec(var1)                                       .DEC
                                                        AGAIN
 
 \ Need to define an arithmetic shift right and though I am loathe to use a hint of PASM it happens to be the most efficient way
 \ However in this case we combine all the shifting and ABS in one operation
 
 : AFIX ( hb lb -- result )              SWAP B>W 16 SHL $38FF680E PASM DROP ABS ;
 
 \ Now we define the loop anew
 : DOIT
        BEGIN
          I2CSTART @accel I2C! 1 I2C!
          I2CSTART @accel 1+ I2C!
          ackI2C@ ackI2C@ AFIX                \ x adjusted
          ackI2C@ ackI2C@ AFIX                \ y adjusted
          ackI2C@ 1 I2C@ AFIX                 \ z adjusted
          I2CSTOP
          
          <CR> ROT .DEC SPACE 2DUP SWAP .DEC SPACE .DEC SPACE 
          PRINT"  -> " / dist @ * .DEC
        AGAIN
        ;
 
 

[max72]

Yes that is a hint, I swear I see a hint in there

:-)
Not really..
I realised I can do with neithe FPU or trig/cordic.. :-)
That was just a post to say unconditionally thank you.. with no extra requests ;-)

I'm using also the nokia LCD, and the code available is a nice help.

I would like to convert my current relevant spin code to Tachyon... the data come in 2's complement so that would offer me the possibility to learn more.. :-)
I'm using the accelerometer to get the height of a tree. I "look" at it at known distance, and I get back an approximate height.

The key code is the following:

  repeat
      i2c.i2cstart
      k:=i2c.i2cwrite(accel_w)
      k:=i2c.i2cwrite(1)  
      i2c.i2cstart
      k:=i2c.i2cwrite(accel_r)
      accel_x:=i2c.i2cread(0)
      accel_x:=accel_x<<8
      accel_x:=accel_x+i2c.i2cread(0)
      accel_x:=accel_x<<16
      accel_y:=i2c.i2cread(0)
      accel_y:=accel_y<<8
      accel_y:=accel_y+i2c.i2cread(0)
      accel_y:=accel_y<<16
      accel_z:=i2c.i2cread(0)
      accel_z:=accel_z<<8
      accel_z:=accel_z+i2c.i2cread(1)
      accel_z:=accel_z<<16
      i2c.i2cstop
      accel_x:=accel_x~>14
      accel_y:=accel_y~>14
      accel_z:=accel_z~>14
      ||accel_z
      ||accel_y
      ||accel_x
      pst.char(13)
      pst.dec(accel_x)
      pst.char(" ")
      pst.dec(accel_y)
      pst.char(" ")
      pst.dec(accel_z)
      pst.char(" ")
      pst.str(string(" -> "))
      var1:=dist*accel_y/accel_z
      pst.dec(var1)
[

[D.P]

Thanks, but is that a little hint to graft in the FPU package?

BTW, do you have that section of Spin code I could look at to make sure it's covered? (when I do integrate it that is

Yes that is a hint, I swear I see a hint in there

[Peter Jakacki]

Just a quick line to say thank you.
I have a MMA845x accelerometer and I decided to test it with Tachyon.
That was easy!!
At the moment I'll revert to spin for trig calculations (I already have all the trig calculations in spin..), but the interactive mode is extremely easy.
It takes a little bit to get acquainted to it, but the sheer power of Tachyon is terrific.
Thanks again,
Massimo

Thanks, but is that a little hint to graft in the FPU package?

BTW, do you have that section of Spin code I could look at to make sure it's covered? (when I do integrate it that is

[max72]

Just a quick line to say thank you.
I have a MMA845x accelerometer and I decided to test it with Tachyon.
That was easy!!
At the moment I'll revert to spin for trig calculations (I already have all the trig calculations in spin..), but the interactive mode is extremely easy.
It takes a little bit to get acquainted to it, but the sheer power of Tachyon is terrific.
Thanks again,
Massimo

[MJB]

I meant to have a look at it a while ago but just tried it now and it did the same thing. What I noticed was that it was remounting each time and basically wiping the request. Turned out to be a single line in MOUNT that have been \\\ commented out for some memory optimization but still had to set the mount flag. Fixed it up and it's fine now.

BTW, if you load EPRINT.fth before SDCARD then it will save at least 2K of hub RAM by storing all the print strings in upper EEPROM.

how little optimizations can have strange side effects ;-)

OK works again - back to webserver development

I had a look to see if EPRINT could be loaded earlier in sequence to also save part of the strings in EXTEND.
This will be possible with my proposed restructuring of EXTEND.

Thanks Peter, Markus

[Peter Jakacki]

Hi Peter,

still struggling
I traced the problem down to DIR works, but cat <filename> gives 'not found'

with spinneret and latest google doc files up to EASYFILE

I had this SD card working before but made changes to content, so decided to reformat to have clean unfragmented image.
I did this with windows format ...
D.P. reminded me of your post to use the SDFORMATTER tool.
so I did this, copied the files back - looks ok from windows ...
but on spinneret I get this very strange behavior

this explains, why the webserver and FTP do not show the file contents ...

what can I do?
thanks, Markus

here the output

Media mounted as 5957.3321          NO NAME     FAT32    Cluster size = 2,768   Sectors = 3,600
 not found
  ok

Cluster size and Sectors look very strange for a 4GB card

I meant to have a look at it a while ago but just tried it now and it did the same thing. What I noticed was that it was remounting each time and basically wiping the request. Turned out to be a single line in MOUNT that have been \\\ commented out for some memory optimization but still had to set the mount flag. Fixed it up and it's fine now.

BTW, if you load EPRINT.fth before SDCARD then it will save at least 2K of hub RAM by storing all the print strings in upper EEPROM.

[MJB]

Hi Peter,

still struggling
I traced the problem down to DIR works, but cat <filename> gives 'not found'

with spinneret and latest google doc files up to EASYFILE

I had this SD card working before but made changes to content, so decided to reformat to have clean unfragmented image.
I did this with windows format ...
D.P. reminded me of your post to use the SDFORMATTER tool.
so I did this, copied the files back - looks ok from windows ...
but on spinneret I get this very strange behavior

this explains, why the webserver and FTP do not show the file contents ...

what can I do?
thanks, Markus

here the output

Media mounted as 5957.3321          NO NAME     FAT32    Cluster size = 2,768   Sectors = 3,600
 not found
  ok

Cluster size and Sectors look very strange for a 4GB card

[MJB]

Hi Peter,

in working on the webserver -
the lastest EASYNET is not working any more with the W5100 / Spinneret
I spottet the new virtual memory functions as the problem and try to adapt
the W5100.FTH - but I seem to miss s.th.
the request comes in - but no result page back

you surely see quickly, what's missing
thanks,
Markus

[MJB]

Wasn't sure what an EXIT does.

"search all files" will become your best friend ... ;-)

[artkennedy]

Thanks. Okay, thought it was something like that. I was getting what I could from the source. Wasn't sure what an EXIT does. Yeah, I like to wring the juice out of things that are new to me so I know what to expect.

[Peter Jakacki]

I was thinking I had the CASE structure whipped. Wrong!

Why does this work:

FORGET TEST
: TEST     \ press keys 1-9 to trigger sensor n repeated reading.
               \ when reading in progress press <esc> to return to sensor selection
               \ when in selection press <esc> to quit
   SWITCH
   "1" "9" SWITCH>< IF SWITCH@ CR EMIT BREAK
   $1B CASE CR BREAK
;


: DOTEST
   BEGIN
      KEY UPPER TEST
      SWITCH@ $1B =
   UNTIL
;
SC DOTEST

And this does not:

FORGET TEST
: TEST     \ press keys 1-9 to trigger sensor n repeated reading.
               \ when reading in progress press <esc> to return to sensor selection
               \ when in selection press <esc> to quit
   BEGIN
      KEY UPPER
      SWITCH
      "1" "9" SWITCH>< IF SWITCH@ CR EMIT BREAK
      $1B CASE CR BREAK
      SWITCH@ $1B =
   UNTIL
;
SC TEST

I think it has something to do with what BREAK does to the stack but I can't scope it.

Good work, yYou are doing well in playing with it to see what it does and doesn't do. If you have a look at the source code you will find that BREAK compiles an EXIT THEN because CASE compiles an = IF so that makes sense. The limitation with this method is of course that when a CASE is taken is that it will EXIT the definition on BREAK so it won't execute any more code in the definition after that, your loop will be broken. This is not normally a problem but it pays to know the limitation.

I suppose that I could define an OTHERWISE ..... ENDCASE where all the BREAKs could know where to jump to but that seems an unnecessary complication as I like to keep the structure open and flexible.

[artkennedy]

I was thinking I had the CASE structure whipped. Wrong!

Why does this work:

FORGET TEST
: TEST     \ press keys 1-9 to trigger sensor n repeated reading.
               \ when reading in progress press <esc> to return to sensor selection
               \ when in selection press <esc> to quit
   SWITCH
   "1" "9" SWITCH>< IF SWITCH@ CR EMIT BREAK
   $1B CASE CR BREAK
;


: DOTEST
   BEGIN
      KEY UPPER TEST
      SWITCH@ $1B =
   UNTIL
;
SC DOTEST

And this does not:

FORGET TEST
: TEST     \ press keys 1-9 to trigger sensor n repeated reading.
               \ when reading in progress press <esc> to return to sensor selection
               \ when in selection press <esc> to quit
   BEGIN
      KEY UPPER
      SWITCH
      "1" "9" SWITCH>< IF SWITCH@ CR EMIT BREAK
      $1B CASE CR BREAK
      SWITCH@ $1B =
   UNTIL
;
SC TEST

I think it has something to do with what BREAK does to the stack but I can't scope it.

[artkennedy]

Oh! I just noticed in QWORDS. \\\ *** --- ... These are defined words. Duh,oh!

But you missed some too
I use the --- a lot since it allows me to space out a comment --- --- --- --- out to where I want it --- just so forum BB code doesn't gobble up whitespace plus --- does not clutter or confuse reading code like 1405 7 / \ is confusing
There's also \\\ and *** but I use that mainly to disable lines of code and to distinguish this from a real comment although they work the same way.

[artkennedy]

I did not know about NOTEPAD++. I have just downloaded and will check it out. I have used The Semware Editor ( tsepro ) *forever* and love it. I have been keeping copies of the kernel and EXTEND loaded and switching to search. Sounds like combining for searching might be worth trying.

I was trying to get a handle on the CASE structure and got flummoxed by the old example. Think I've got it now. Just had to realize that the structure does not need an explicit closing term.

looks like an old version of CASE now changed to more C-like
SWITCH CASE -> see pub CASEDEMO

I have the whole TACHYON files - Kernel + EXTEND + ... all extensions in NOTEPAD++ and then just do a search-all-files ...
this reveals immediately what's going on ... and =[ are only in this single place

[Peter Jakacki]

I was so used to having only one or two characters to indicate comments that I hadn't noticed that ( would do it. I was using a \ before the ( . I can see now that seeing ( and not \ ( was confusing me. That's cleared up.

Here's another.
From the kernel:

{ quick test
pub TC ( ch -- )
     CASE
    "4" =[ ." Knock on the door, it's a 4" ]=
    "5" =[ ." Let's jive, it's a 5" ]=
    "7" "9" ..[ ." Pick up sticks, it's more than six" ]=
;
}

Can't determine what =[ and ]= do. Also ..[
I know the whole clip is a comment but I don't what's going on there. Help?

I will have to track those outdated examples and bring them up-to-date. As MJB mentioned the newer method is more C like using SWITCH and CASE BREAK statements etc. I will look at updating that in the document but I'm also happy to provide examples of use as well, just let me know.

[MJB]

I was so used to having only one or two characters to indicate comments that I hadn't noticed that ( would do it. I was using a \ before the ( . I can see now that seeing ( and not \ ( was confusing me. That's cleared up.

Here's another.
From the kernel:

{ quick test
pub TC ( ch -- )
     CASE
    "4" =[ ." Knock on the door, it's a 4" ]=
    "5" =[ ." Let's jive, it's a 5" ]=
    "7" "9" ..[ ." Pick up sticks, it's more than six" ]=
;
}

Can't determine what =[ and ]= do. Also ..[
I know the whole clip is a comment but I don't what's going on there. Help?

looks like an old version of CASE now changed to more C-like
SWITCH CASE -> see pub CASEDEMO

I have the whole TACHYON files - Kernel + EXTEND + ... all extensions in NOTEPAD++ and then just do a search-all-files ...
this reveals immediately what's going on ... and =[ are only in this single place

[artkennedy]

I was so used to having only one or two characters to indicate comments that I hadn't noticed that ( would do it. I was using a \ before the ( . I can see now that seeing ( and not \ ( was confusing me. That's cleared up.

Here's another.
From the kernel:

{ quick test
pub TC ( ch -- )
 	CASE
	"4" =[ ." Knock on the door, it's a 4" ]=
	"5" =[ ." Let's jive, it's a 5" ]=
	"7" "9" ..[ ." Pick up sticks, it's more than six" ]=
;
}

Can't determine what =[ and ]= do. Also ..[
I know the whole clip is a comment but I don't what's going on there. Help?

[Peter Jakacki]

There seems to be a confusing number of ways to indicate comments in the source code.

/
{ }
'
''
(

I am clear on the first two. Could use an explanation of the others.

And while I'm on a roll, what is the meaning of the vertical bar in \ test quadrant 3|4 ?

The \ (not /) is a Forth standard as is ( too except I echo anything inside a ( which is normally a stack comment but totally ignore anything after a \ up to the end of line.
The { } are intended for multi-line block comments.
' is not a comment directive in Forth but it is to the Spin compiler which is used to process the PASM and data structures that make up the precompiled kernel.
" is not a comment directive either but is used in TF either in the form of a character literal "$" or for strings such as " HELLO WORLD" PRINT$
But you missed some too
I use the --- a lot since it allows me to space out a comment --- --- --- --- out to where I want it --- just so forum BB code doesn't gobble up whitespace plus --- does not clutter or confuse reading code like 1405 7 / \ is confusing
There's also \\\ and *** but I use that mainly to disable lines of code and to distinguish this from a real comment although they work the same way.

It could also be said that IFDEF and IFNDEF are conditional comment directives too because if they fail they end up working like a block comment { up to the following }

If you're on a roll it could be dangerous, that is if you're a pig and it's a pork roll. But you mentioned a symbol being used in a comment but a comment can be anything at all, however just to satisfy your curiosity the | is just a separator referring to the quadrants 1 (top right) 2 (top left) 3 (bottom left) 4 (bottom right).

The | is also used to build bytes into a table instead of the more standard but unsightly C, as the | works more like a border in a real table so 45 | 07 | 23 | looks more like a table than 45 C, 07 C, 23 C, doesn't it?

[Peter Jakacki]

BTW, to make my table I used:

#9 WORDS: tempsens

How is that different from:

TABLE tempsens 2 9 * ALLOT

Mainly to make it easier to read and clearer to see the structure, in the first there are WORD variables, 9 of them in fact, in the second it's a table for constants or variables maybe and there are 9 words or is that 2 lots of 9 bytes? So the first example is a lot clearer.

[artkennedy]

There seems to be a confusing number of ways to indicate comments in the source code.

/
{ }
'
''
(

I am clear on the first two. Could use an explanation of the others.

And while I'm on a roll, what is the meaning of the vertical bar in \ test quadrant 3|4 ?

[artkennedy]

BTW, to make my table I used:

#9 WORDS: tempsens

How is that different from:

TABLE tempsens 2 9 * ALLOT

I just figured out how to create and access a data array for my temperature sensor readings and I had a *lot* of joy. And we all know what that means

[artkennedy]

I just figured out how to create and access a data array for my temperature sensor readings and I had a *lot* of joy. And we all know what that means

[MJB]

Peter,
FTP Rename RNFR & RNTO seem to work - see latest EASYNET.fth - still commented

[Peter Jakacki]

Peter,
in working on the Tachyon extensible scriptable WebServer I am wondering.

If the webserver is not intended to be only static and preloaded on SD-card,
then .HTM, *.JPG etc. and .HTX script files need to also be ADDED and not only be changed remotely.

The SD filesystem and the FTP-server do not seem to be designed to create new files remotely...

I've been able to get away with it and even though I have been using dummy files and renaming them (yes), I see the need to be able to add new files. I don't think it's a big deal to add the extra sections to the file system but I do want to make sure that files are non-fragmented and even with a very basic 4GB card there is plenty of room there to allocate contiguous sectors and clusters. So you might not have to wait too long for this extra functionality to be added.

As for memory I have been using EPRINT to store text strings to the top half of a 64K EEPROM to give me extra room but I may also look at using the SD memory a little bit more, either for dictionary, precompiled blobs, or even direct "scripting" from text files. So far I've been able to add a rather largish application on top of all these layers and still have memory free! I do a RECLAIM just before I add the application though.

.STATS 
NAMES:  $539A...7442 for 8360 (0719 bytes added)
CODE:   $0000...5198 for 12528 (2177 bytes added)
CALLS:  0059 vectors free
RAM:    0514 bytes free
 ok
.MODULES 
MODULES LOADED: 
4917: DATALOGGER.fth      CE1372 DATALOGGER 140620.0000 
3EE5: EASYNET.fth         WIZNET NETWORK SERVERS 140615.2300 
38E6: W5200.fth           WIZNET W5200 driver 140517.0100 
2FE8: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140528-0000 
2B30: SDCARD.fth          SD CARD Toolkit - 140626.1400 
294C: CE1372.fth          CE1372 WIDGET HARDWARE DEFINITIONS 131109.2340 
2883: EPRINT.fth          Stores PRINT strings in EEPROM 140626.0000 
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140626-14OO

[MJB]

Peter,
in working on the Tachyon extensible scriptable WebServer I am wondering.

If the webserver is not intended to be only static and preloaded on SD-card,
then .HTM, *.JPG etc. and .HTX script files need to also be ADDED and not only be changed remotely.

The SD filesystem and the FTP-server do not seem to be designed to create new files remotely - atm at least.
trying to put a non existing file gives

Befehl:    PASV
Antwort:    227 Entering Passive Mode with port (192,168,188,157,156,152)
Befehl:    STOR NEWTEST.TXT.txt
Antwort:    550 File not available
Fehler:    Kritischer Dateiübertragungsfehler
Fehler:    Verbindung vom Server geschlossen

Just adding files should not create the full complexity of a FAT file system -
any plans ?

Or a workaround could be to have a RENAME -
then we could create a large number of DUMMY1... files of appropriate size and for use rename them
as needed.
Might simplify the effort on TACHYON side ( not much memory left anyhow).

pub RENAME$ ( new$ -- ) is already there

There are the FTP commands RNFR (rename from) RNTO (rename to )
should not be to difficult.
Haven't looked to do it myself yet - just discovering things while I'm writing ...
...

--- FTP rename file request
pub RNFR IMMEDIATE

GETFNAME DROP FTP SOCKET LANCON PRINT" 550 Feature not implemented" CR LANSEND
;

ok here it is

RNFR could just store the FN into a var RNFN$
RNTO then opens the RNFN$ and performs the RENAME$ to the new name

[Peter Jakacki]

Just done a quick little update and consolidated the DUMP words for RAM, EEPROM, and SD so that you specify which when you DUMP memory. I might even add COG to the fray too.

DUMP words are:
DUMP ( addr cnt -- ) Dump memory as hex bytes along with an ASCII listing on each line
DUMPW ( addr cnt -- ) Dump memory as hex words along with an ASCII listing on each line
DUMPL ( addr cnt -- ) Dump memory as hex longs along with an ASCII listing on each line
DUMPA ( addr cnt -- ) Dump memory as 64 ASCII characters per line

RAM --- latching prefix to select normal RAM (or ROM) memory for DUMP listing
EE --- latching prefix to select EEPROM for DUMP listing
SD --- latching prefix to select SD memory for DUMP listing

$8000 $200 RAM DUMPA 
0000.8000: .............................@UU.@U..@U..@U..@U..@...@...@...@..
0000.8040: .@...@...@...@...@U..@U..@U..@U..@UU............................
0000.8080: ..............................................(.....@..........?
0000.80C0: ...?....@.........(.............................................
0000.8100: .................................................._.@._.P._.....
0000.8140: ................../.............................................
0000.8180: ..........................@..*P...T...W..._....................?
0000.81C0: ...?.................._...W...T..*P...@......................... ok
$8000 $200 EE DUMPA 
0000.8000: CE1372 WIDGET HARDWARE DEFINITIONS 131109.2340 .FAT32 Virtual Me
0000.8040: mory Access File System Layer V1.1 140528-0000 .Media mounted as
0000.8080:  . Cluster size = .   Sectors = . Mounted SD Card . *Format Erro
0000.80C0: r* .*Card Error* . *No Card inserted!* ....opened at . not found
0000.8100:  . to .No file opened ././.:.:.........NAME    .EXT ATRS   SECTO
0000.8140: R       DATE       TIME       SIZE .#.#. Saving EEPROM image to 
0000.8180: .Loading EEPROM image . to EEPROM ..............................
0000.81C0: ................................................................ ok
$8000 $200 SD DUMPA 
0000.8000: ................................................................
0000.8040: ............................................................ ...
0000.8080: !..."...#...$...%...&...'...(...)...*...+...,...-......./...0...
0000.80C0: 1...2...3...4...5...6...7...8...9...:...;...<...=...>...?...@...
0000.8100: A...B...C...D...E...F...G...H.......J...K...L...M...N...O...P...
0000.8140: Q...R...S...T...U...V...W...X...Y...Z...[...\...]...^..._...`...
0000.8180: a...b...c...d...e...f...g...h...i...j...k...l...m...n...o...p...
0000.81C0: q...r...s...t...u...v...w...x...y...z...{...|...}...~........... ok
@ROOT $200 SD DUMPA 
0076.3400: CE1067     ......D.D.....D......DEBUG   ROM .d...D.D.....D......
0076.3440: FAVICON ICO .d...D.D..<O.C......FIRMWAREROM .d...D.D.....D......
0076.3480: HELP    TXT .d...D.D..!r.D%.....HOME    HTM ..-..D.D.....D.A....
0076.34C0: HTTP404 HTM .d...D.D..TO.C7.4...MENU    TXT .d...D.D.....D8.....
0076.3500: PREVIOUSROM .d...D.D.....D9.....CANB0001LOG .d...D.D...sXDI.....
0076.3540: CANB0002LOG .d...D.D...sXDI.....CANB0003LOG .d...D.D...sXDI.....
0076.3580: CANB0004LOG .d...D.D...sXDI.....CANB0005LOG .d...D.D...sXDI.....
0076.35C0: CANB0006LOG .d...D.D...sXDI.....CANB0007LOG .d...D.D...sXDI..... ok

[artkennedy]

Yep, shouda read the comment. Thanks.

We know that every time we make assumptions that we get caught time and time again
.HEX is really an internal word for printing nibbles in HEX characters.

From the Tachyon 2.3 source code:

' .HEX ( n -- ) print nibble n as a hex character
PRTHEX  ' ( n -- ) print n (0..$0F) as a hex character
         byte    toNIB
         byte    PUSH1,$30,PLUS
         byte    DUP,PUSH1,$39,GT,_IF,03,_BYTE,7,PLUS                      'Adjust for A..F
PRTCH    byte    XCALL,xEMIT,EXIT

I know that I later created a word called .DEC to print out a number in decimal so perhaps the name choice for .HEX could have been different in hindsight but numbers are normally forced to print in hex notation using either .LONG or .WORD or .BYTE plus a few other methods. Normally in Forth there is just the dot word and variations ( . .R U. U.R ) for printing numbers and you normally have to change the base beforehand. I have added those hex print words as mentioned plus .DEC and also a number format routine .NUM for specifying how a number should be printed by passing a control parameter which specifies:
b07..00 = base
b12..08 = digits
b13 = use spaces in place of leading zeros
b14 = force separators (decimals have a , every 3 places while others have a _ every 4 places)
b15 = force sign (always + or - depending upon the number)


Have fun!

[Peter Jakacki]

Is there a bug in .HEX ?

We know that every time we make assumptions that we get caught time and time again
.HEX is really an internal word for printing nibbles in HEX characters.

From the Tachyon 2.3 source code:

' .HEX ( n -- ) print nibble n as a hex character
PRTHEX  ' ( n -- ) print n (0..$0F) as a hex character
         byte    toNIB
         byte    PUSH1,$30,PLUS
         byte    DUP,PUSH1,$39,GT,_IF,03,_BYTE,7,PLUS                      'Adjust for A..F
PRTCH    byte    XCALL,xEMIT,EXIT

I know that I later created a word called .DEC to print out a number in decimal so perhaps the name choice for .HEX could have been different in hindsight but numbers are normally forced to print in hex notation using either .LONG or .WORD or .BYTE plus a few other methods. Normally in Forth there is just the dot word and variations ( . .R U. U.R ) for printing numbers and you normally have to change the base beforehand. I have added those hex print words as mentioned plus .DEC and also a number format routine .NUM for specifying how a number should be printed by passing a control parameter which specifies:
b07..00 = base
b12..08 = digits
b13 = use spaces in place of leading zeros
b14 = force separators (decimals have a , every 3 places while others have a _ every 4 places)
b15 = force sign (always + or - depending upon the number)


Have fun!

[artkennedy]

Is there a bug in .HEX ?

DECIMAL ok
69 .S Data Stack (1)
$0000.0045 - 69
$0000.0000 - 0 ok
.HEX 5 ok
69 CR .HEX
5 ok
HEX ok
#69 . 45 ok

[Peter Jakacki]

Are you able to put the server online? Maybe just PM me an IP and have ports forwarded?

[MJB]

Well the Tachyon system isn't exactly a sealed black box is it!?

that's why I like it

Apply the EVAL$ (well done) to yourself and you should be able to step through parts of the code that would execute but at the very basic level just check /HOME.HTM works or even try it via FTP. Let me know what you find out.

I did a complete rebuild from the latest Google sources ...

FTP all fine
HTTP from Firefox still 404
I peeked at GET$ after the request and find a strange string.
GET$ PRINT$ allax, Inc. ----------------www.parallax.com=============== ok
A search for this in my whole Tachyon folders does not show s.th. relevant ... hmm ???

  ok

  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 Cold start - no user code - setting defaults
----------------------------------------------------------------
CREATE SMALL  ok
( EXTEND.fth )  ok
IFDEF EXTEND.fth  ok
  ok
  ok
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok
0000  okCLR
0001  ok
0002  ok

0003  ok
0004  ok
0005  ok
0006  ok
0007  ok
0008  ok

0009  ok
0010  ok
0011
0012
0013  ok
0014
0015
0016  ok
0017  ok

0018  ok
0019  ok

0020  ok
0021  ok

0022  ok
0023  ok

1192  ok
\
1193

00:00:00  End of source code, 1194 lines processed and 0000 errors found
MODULES LOADED:
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $6145...7442 for 4861 (2415 bytes added)
CODE:   $0000...2831 for 5428 (4016 bytes added)
CALLS:  0603 vectors free
RAM:    14612 bytes free
 ok
\
EEPROM  9600d SERBAUD  ok
?BACKUP  ok
  ok
  ok

  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000

NAMES:  $6145...7442 for 4861 (2415 bytes added)
CODE:   $0000...2831 for 5428 (4016 bytes added)
CALLS:  0603 vectors free
RAM:    14612 bytes free

MODULES LOADED:
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO
BOOT: EXTEND.boot

----------------------------------------------------------------
( SPINNERET.fth )  ok
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok
0000  ok
0109  okINNERET.fth not found
0110  ok
0111

00:00:00  End of source code, 0112 lines processed and 0000 errors found
MODULES LOADED:
2831: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $602C...7442 for 5142 (0281 bytes added)
CODE:   $0000...29B4 for 5534 (0387 bytes added)
CALLS:  0572 vectors free
RAM:    13944 bytes free
 ok
Von  --> Von <-- not found
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok
0310  SDCARD.fth not found

00:00:00  End of source code, 0311 lines processed and 0000 errors found
MODULES LOADED:
29B4: SDCARD.fth          SD CARD Toolkit - 140121.2200
2831: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $5D97...7442 for 5803 (0661 bytes added)
CODE:   $0000...2EDE for 6195 (1322 bytes added)
CALLS:  0501 vectors free
RAM:    11961 bytes free
 ok
  ok
  ok
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok
0398  okSYFILE.fth not found
\
0399

00:00:00  End of source code, 0400 lines processed and 0000 errors found
MODULES LOADED:
2EDE: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140528-0000
29B4: SDCARD.fth          SD CARD Toolkit - 140121.2200
2831: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $59AE...7442 for 6804 (1001 bytes added)
CODE:   $0000...391C for 7816 (2622 bytes added)
CALLS:  0397 vectors free
RAM:    8338 bytes free
 ok
?BACKUP  ok
\
\
  ok
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok
0340  ok100.fth not found
0341

00:00:00  End of source code, 0342 lines processed and 0000 errors found
MODULES LOADED:
391C: W5100.fth           WIZNET W5100 driver 140615.0000
2EDE: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140528-0000
29B4: SDCARD.fth          SD CARD Toolkit - 140121.2200
2831: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $54A6...7442 for 8092 (1288 bytes added)
CODE:   $0000...4088 for 8428 (1900 bytes added)
CALLS:  0264 vectors free
RAM:    5150 bytes free
 ok
?BACKUP  ok
  ok
  ok
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok
0537  okSYNET.fth not found
0538

00:00:00  End of source code, 0539 lines processed and 0000 errors found
MODULES LOADED:
4088: EASYNET.fth         WIZNET NETWORK SERVERS 140615.2300
391C: W5100.fth           WIZNET W5100 driver 140615.0000
2EDE: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140528-0000
29B4: SDCARD.fth          SD CARD Toolkit - 140121.2200
2831: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $50B6...7442 for 9100 (1008 bytes added)
CODE:   $0000...4EC2 for 11062 (3642 bytes added)
CALLS:  0159 vectors free
RAM:    0500 bytes free
 ok
  ok
{   ok
{  ok
  ok
  ok
\
\
---
\
?BACKUP  ok
  ok
\
\
  ok
GO
*** Tachyon Forth Network and File Server ***

 Mounted SD Card
Media mounted as 5957.3321 MSDOS5.0 NO NAME     FAT32    Cluster size = 2,768   Sectors = 3,600

Listing directory
NO NAME

POPCORN .WAV   ROM     .BIN   SDCARD  .FTH   SYSLOG  .TXT   TACHYON .JPG
TACHYON .LST   W5200   .FTH   CE1372  .FTH   EXTEND  .FTH   FAVICON .ICO
HOME    .HTM   HTTP001 .HTM   HTTP404 .HTM   LOG0001 .TXT   LOG0002 .TXT
LOG0003 .TXT   LOG0004 .TXT   LOG0005 .TXT   LOG0006 .TXT   LOG0007 .TXT
LOG0008 .TXT   LOGON   .      LOGON   .TXT   MULTIFAT.FTH   NETWORK .FTH
PARALLAX.PNG    ... ready!

************ NETWORK STATUS ************
HARDWARE: SPINNERET using WIZnet W5100 (indirect mode)
SRC IP    192.168.188.157.
MASK      255.255.255.000.
GATEWAY   192.168.188.001.
MAC       02.FF.BE.AE.70.FD.
*** SOCKETS ***
#0 14:06:50 MODE= CLSD PORT#   80        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED
#1 14:06:50 MODE= TCP  PORT#   21        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN
#2 14:06:50 MODE= TCP  PORT#   80        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN
#3 14:06:50 MODE= TCP  PORT#   23        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN

* WEB, FTP, and TELNET servers running *
 ok
 Mounted SD Card
Media mounted as 5957.3321 MSDOS5.0 NO NAME     FAT32    Cluster size = 2,768   Sectors = 3,600

#2 14:07:22 MODE= TCP  PORT#   80 56876  TXRW=ADC0.ADC0.RXRW=    . 12A.RXSZ= 12A.IR=04 ST=17 ESTABLISHED    192.168.188.021.
HTTP/1.1
Host: 192.168.188.157
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive


#2 14:07:23 MODE= TCP  PORT#   80 56877  TXRW=F58B.F58B.RXRW=    . 135.RXSZ= 135.IR=04 ST=17 ESTABLISHED    192.168.188.021.
HTTP/1.1
Host: 192.168.188.157
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

  ok
GET$ PRINT$ allax, Inc. ----------------www.parallax.com=============== ok

EDIT: found the string here:

0000_FF10:   20 43 6F 70  79 72 69 67   68 74 20 32  30 30 35 20    Copyright 2005
0000_FF20:   20 50 61 72  61 6C 6C 61   78 2C 20 49  6E 63 2E 20    Parallax, Inc.
0000_FF30:   2D 2D 2D 2D  2D 2D 2D 2D   2D 2D 2D 2D  2D 2D 2D 2D   ----------------
0000_FF40:   77 77 77 2E  70 61 72 61   6C 6C 61 78  2E 63 6F 6D   www.parallax.com
0000_FF50:   3D 3D 3D 3D  3D 3D 3D 3D   3D 3D 3D 3D  3D 3D 3D 3D   ================

[Peter Jakacki]

Hi Peter,

I had a running version on my Spinneret and while loading experimental stuff I got Dictionary full.
Without reading the full doc I remembered RECLAIM and issued it.
Apparently it reclaimed a lot - too much for me.
So I tried to rebuild from latest sources.
After a few attempts getting all right PCB, IP, loading sequence ... :-(
I had a running system again -
ftp and telnet are fine,
but on trying http via Firefox by just typing the IP address I get this:



anything obvoius I do wrong ?

as said - previous build worked fine, including HTTP

btw: I have a EVAL$ ready, that can eval a string containing Tachyon code,
will be useful for evaluating FORTH$.
Also decoding of encoded URL messages .. the -> BL stuff is more or less working.
Just couldn't test it yet... see above..

Thanks, Markus

Well the Tachyon system isn't exactly a sealed black box is it!? Apply the EVAL$ (well done) to yourself and you should be able to step through parts of the code that would execute but at the very basic level just check /HOME.HTM works or even try it via FTP. Let me know what you find out.

[MJB]

Hi Peter,

I had a running version on my Spinneret and while loading experimental stuff I got Dictionary full.
Without reading the full doc I remembered RECLAIM and issued it.
Apparently it reclaimed a lot - too much for me.
So I tried to rebuild from latest sources.
After a few attempts getting all right PCB, IP, loading sequence ... :-(
I had a running system again -
ftp and telnet are fine,
but on trying http via Firefox by just typing the IP address I get this:

Not Found

The requested page was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

GO
*** Tachyon Forth Network and File Server ***

Mounted SD Card
Media mounted as 5957.3321 MSDOS5.0 NO NAME FAT32 Cluster size = 2,768 Sectors = 3,600

Listing directory
NO NAME

POPCORN .WAV ROM .BIN SDCARD .FTH SYSLOG .TXT TACHYON .JPG
TACHYON .LST W5200 .FTH CE1372 .FTH EXTEND .FTH FAVICON .ICO
HOME .HTM HTTP001 .HTM HTTP404 .HTM LOG0001 .TXT LOG0002 .TXT
LOG0003 .TXT LOG0004 .TXT LOG0005 .TXT LOG0006 .TXT LOG0007 .TXT
LOG0008 .TXT LOGON . LOGON .TXT MULTIFAT.FTH NETWORK .FTH
PARALLAX.PNG ... ready!

************ NETWORK STATUS ************
HARDWARE: SPINNERET using WIZnet W5100 (indirect mode)
SRC IP 192.168.188.157.
MASK 255.255.255.000.
GATEWAY 192.168.188.001.
MAC 02.FF.BE.AE.70.FD.
*** SOCKETS ***
#0 04:39:15 MODE= CLSD PORT# 80 TXRW= . .RXRW= . .RXSZ= .IR=00 ST=00 CLOSED
#1 04:39:15 MODE= TCP PORT# 21 TXRW= . .RXRW= . .RXSZ= .IR=00 ST=14 LISTEN
#2 04:39:15 MODE= TCP PORT# 80 TXRW= . .RXRW= . .RXSZ= .IR=00 ST=14 LISTEN
#3 04:39:15 MODE= TCP PORT# 23 TXRW= . .RXRW= . .RXSZ= .IR=00 ST=14 LISTEN

* WEB, FTP, and TELNET servers running *
ok
Mounted SD Card
Media mounted as 5957.3321 MSDOS5.0 NO NAME FAT32 Cluster size = 2,768 Sectors = 3,600

#2 04:39:25 MODE= TCP PORT# 80 49848 TXRW=E6F8.E6F8.RXRW= . 12A.RXSZ= 12A.IR=04 ST=17 ESTABLISHED 192.168.188.021.
HTTP/1.1
Host: 192.168.188.157
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive


#2 04:39:25 MODE= TCP PORT# 80 49849 TXRW=27DC.27DC.RXRW= . 135.RXSZ= 135.IR=04 ST=17 ESTABLISHED 192.168.188.021.
HTTP/1.1
Host: 192.168.188.157
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

ok
ok

anything obvoius I do wrong ?

as said - previous build worked fine, including HTTP

btw: I have a EVAL$ ready, that can eval a string containing Tachyon code,
will be useful for evaluating FORTH$.
Also decoding of encoded URL messages .. the %20 -> BL stuff is more or less working.
Just couldn't test it yet... see above..

Thanks, Markus

[D.P]

Since this is the Tachyon thread I will give you a Tachyon specific answer in this regard. You mentioned in another concurrent post tacked onto a 9 year old thread about assembly language for the Basic Stamp. Dude, the Basic Stamp is about Basic, and Tachyon Forth is about Forth although the source code is a good place to learn more about Propeller Assembly code, but assembly language is very specific to the processor, and they are all different. We are very helpful here on the Parallax forum but you might have to be a bit more specific about what you want to know as long as it is specifically about Parallax products

But his post does add to the thread count so it's not all for not

@Pilot0315 Welcome to fight club, I mean the forums.

[Peter Jakacki]

I am looking for a good beginners book on assembly language do you have any suggestions?

Since this is the Tachyon thread I will give you a Tachyon specific answer in this regard. You mentioned in another concurrent post tacked onto a 9 year old thread about assembly language for the Basic Stamp. Dude, the Basic Stamp is about Basic, and Tachyon Forth is about Forth although the source code is a good place to learn more about Propeller Assembly code, but assembly language is very specific to the processor, and they are all different. We are very helpful here on the Parallax forum but you might have to be a bit more specific about what you want to know as long as it is specifically about Parallax products

[pilot0315]

I am looking for a good beginners book on assembly language do you have any suggestions?

[D.P]

I haven't had a look at Mike G's webserver .. pointer?
Very soon after I discovered the Propeller I was a witness of the advent of Tachyon and therefore didn't do a lot in SPIN
only some PASM for timecritical parts.
I am also very interested in your gauges, as I am thinking the same direction.
Currently I am working with Peter on a Forth-scriptabe webserver, which will make AJAX and dynamic page creation in general very simple and flexible. This will be really fun. It also offloads the script code from the image to the SD card.
If you send me a PM (with email address) - I'd love to cooperate on this.

PM Sent,

Mike G's WebServer is in the this entire section:
http://forums.parallax.com/forumdisp...ret-Web-Server

[MJB]

Thanks, Markus. That is an outstanding link. I have seen them before and shied away because I know the AD590 so well and have not been eager to take on interfaces that are new to me. I am beginning to get over that. Tachyon helps. I will look into it.

just load Peter's 1-WIRE.fth from DROPBOX or web-files
there is a working example for the DS18B20 - you only have to get the one pin number right ;-)

[artkennedy]

Thanks, Markus. That is an outstanding link. I have seen them before and shied away because I know the AD590 so well and have not been eager to take on interfaces that are new to me. I am beginning to get over that. Tachyon helps. I will look into it.

Hi Art,

I am perfectly happy with DS18B20 temperature sensors.
They require only 3 - 5 V supply and give digital results.
NO ADCs and the disturbances on long lines ...
you can even run them with 2 wires - 1-wire + GND in parasitic mode.
- and got them cheap, ready with cables and steel caps in the dozend from EBAY
http://www.ebay.com/itm/10pcs-New-DS...item257d4515b7


Just recently tried Peters 1-Wire driver for Tachyon and have a multi-bus extension ready, but not yet fully documented.

A little Propeller Board can drive a LCD or even VGA display,
does not need much power - great for a 24*365 application like yours.

And now with the telnet & webserver in Tachyon, you can monitor and control everything from the WEB.

really great
Markus

[MJB]

Hi Art,

I am perfectly happy with DS18B20 temperature sensors.
They require only 3 - 5 V supply and give digital results.
NO ADCs and the disturbances on long lines ...
you can even run them with 2 wires - 1-wire + GND in parasitic mode.
- and got them cheap, ready with cables and steel caps in the dozend from EBAY
http://www.ebay.com/itm/10pcs-New-DS...item257d4515b7


Just recently tried Peters 1-Wire driver for Tachyon and have a multi-bus extension ready, but not yet fully documented.

A little Propeller Board can drive a LCD or even VGA display,
does not need much power - great for a 24*365 application like yours.

And now with the telnet & webserver in Tachyon, you can monitor and control everything from the WEB.

really great
Markus

[artkennedy]

In case anyone is wondering what this retired bus driver is up to in Tachyon. Here it is.


Goal #1 a controller for my solar hydronic heat system.
Goal #2 a system base on this controller which might be of interest to others.


A bit of history. In about 1980 I designed and installed a solar heating system for my home. It is composed of six 4 x 8 foot collectors on a freestanding vertical wall on the roof of a new addition. There is a 2' over 12' roof sloping to the south which acts as a reflector to concentrate the sun. Storeage is in an insulated 1250 gallon tank buried under the kitchen. Heat was to be utilized by a 100' coil of copper pipe in the tank to preheat cold water on the way to the electric water heater and also for space heating via a heat exchanger in the return air of an external natural gas furnace. The space heating didn't work out well because of the many feet of moderately insulated ducts and the ancient furnace which finally croaked at the same time my marriage did the same. The water heating works quite well with tank temperatures of 178F observed with good weather in the fall. By 1982 I had made a decent controller using a 68HC11 board from New Micros Inc which had Forth resident. I whomped up a system with the NMI board at the heart and a lot of amazingly functional and durable point-to-point wired circuitry that I designed myself, with the help of some manuals and spec sheets, of course. It had a 2 line LCD display but required a PC to do real data collection and set parameters. And it had a really clunky power supply.


About 5 years ago I re-engineered the power supply just before leaving town for 30 days. While I was gone one of the connections to the PS slipped out and the system was very unhappy. As we said in the USAF "INOP". So I decided to revive an old dream of a much simpler system with an HP48 calculator as the user interface. Meanwhile I have been operating the collector pump and drain valve using an HP48 connected to an X-10 powerline modem and appropriate relays. So operation is on a time of day basis without reference to any temperature measurements. Non-optimal. I won't go into all the false starts, including purchase of a newer board from New Micros just as they were going into bankruptcy, and other times I just lost my resolve ( not so young anymore ). However when I finally decided to try the Propeller and found Propforth and then Tachyon I kind of got my fire lit again.


At first I was determined to have a system using the hp48 as above with a DMM for reading sensors and X-10 for control. The Prop is necessary because the calculator only has one port and no control lines for switching a port multiplexer. As I slogged ahead the points started adding up against the DMM idea even though the hp48 and the DMM could converse easily. I wanted to use the DMM because it would allow me to read my favorite sensors directly in degrees Kelvin. The AD590 temperature sensors require only 2 wires and may be powered by any voltage from 4 to 30, returning the reading as a regulated current of 1 microamp per deg K. One of my early discoveries with this sensor was that it should be strobed at a small duty cycle to prevent self-heating. This was done easily with the NMI board - more on this later. One of the big points against the DMM was when I learned that very few DMMs are really good at measuring microamps and I was pretty sure my Protek 506 was not one of them. So very recently I ditched the DMM and learned to use the TI-1115 16 bit ADC. This was my first attempt to use an interface other than RS-232. Thanks to Tachyon it wasn't very hard. I'm not measuring current anymore but a bonus is that with a carefully constructed resistor network I get a reading from the ADC identical to degrees F. Yeah, Celcius is more scientific - call me a troglodyte. The 16 bits may be overkill but it lets me measure a very wide range and place the important stuff near the center of the range.


X-10 because the relays are cheap and I finally found a reliable powerline modem by JV Digital Engineering < jvde.us >. Already using X-10 with an HP-48. Will need to transfer that function to the Prop.


HP48 because:
- it has a serial port
- it has a date/time system that can do very fancy things by running programs on a schedule in which the schedule can be
modified under software control.
- it has a very accessable and powerful programming environment at which I am skilled.
- there are customizable menus, keyboard, display, port, strings, clock and heavy duty math and analysis functions.
- I prefer the programming environment on the 48 but by moving to the HP50 data can be stored on SD memory.
- all this in an extremely low power moderately expensive package.


Alright, enough justification. Current status is a Prop with 3 RS-232 ports tested functional ( now only need 2 ), an Adafruit TI-1115 ADC board and a special counter circuit for addressing the sensors. 'Art, why do you need that?' Because I was thinking that the voltage needed to drive the AD590 was 3-30v but when I rechecked the specs I saw that it was 4-30. Dang! So I regressed to my glue chip days and put in a 74HC4017 decade counter. Powered from Vin on the Prop it supposedly needs more than the 3.3 volts from the Prop ports to clock it but I correctly guessed that it would work. I have pins Q1 through Q9 to drive sensors with Q0 reserved for 'all off'. To address all 9 sensors in sequence I only need to send a reset pulse ( should already be reset, but init anyway to be sure ) and a clock pulse for each sensor in turn, pausing 20ms to let the little feller wake up. Sensor 'n' can be individually addressed with a reset and 'n' clocks. Only two Prop ports are required - and 4017s can be chained indefinitely.


So the hardware is all prototyped on a reasonably neat board ( see photo ) and is reasonably well tested for function. Software is next, Bwahahaha! My last heavy lifting in Forth or really any environment except HP User code was about 30 years ago. I want to do the project in Forth because that is what I know best outside of QuickBasic. So when I started with the Prop I only touched SPIN lightly before plunging into PropForth and then Tachyon, recommended by Loopy Byteloose. This causes me some extra effort in reading the Tachyon code sometimes. I like Tachyon and while I could use documentation that is more friendly to my skill level I understand why it is not that way and I have gotten better at combing the code files and creating my own.

I comment heavily to aid in understanding code while writing it and for understanding when revisiting it later. Out of luck otherwise. Thanks to Peter for code improvements to some of my posts. Recently learned about B>W and W>B that way. I also sometimes give words names that are quirky and need improvement, i.e., EXT16 instead of 2s>R for a function to convert a twos-complement number to a real. Such assistance is welcome whenever someone feels so inclined. However I will admit to liking my own ideas a lot. Can you tell?

[MJB]

As far as the webserver/AJAX goes this should be very straight forward once I get my head around this basic HTTP server. It's just another header type that needs the correct handler to create the correct response header back to the browser. I have a set of java powered guages that I use with the current spin webserver, all the ajax request does is query for a few variables that are updated server side and sent back that control the guages browser side. Everything is 8.3 file format already for the webserver in spin that Mike G wrote.

I haven't had a look at Mike G's webserver .. pointer?
Very soon after I discovered the Propeller I was a witness of the advent of Tachyon and therefore didn't do a lot in SPIN
only some PASM for timecritical parts.
I am also very interested in your gauges, as I am thinking the same direction.
Currently I am working with Peter on a Forth-scriptabe webserver, which will make AJAX and dynamic page creation in general very simple and flexible. This will be really fun. It also offloads the script code from the image to the SD card.
If you send me a PM (with email address) - I'd love to cooperate on this.

[D.P]

actually, when I want to play/work Propeller I have a laptop or tablet anyhow with a serial, ethernet / future Bluetooth (you have it already Peter)
with all my other things (mail internet etc...)
but I usually have no extra VGA plus kbd/mouse with me ... so I can't see a need for a real standalone.
Intermediate option would be kind of texteditor based on ANSI-Terminal, that can run over serial, bluetooth, telnet - but a simple editor is everywhere ..
so I think effort is better spent on other enhancements before the standalone idea.
Like webserver with cgi/js/AJAX/xml support ... to write nice interactive WEB-GUIs
m2c

And just to chime in: loadable PASM modules so we can have access to F32 and the rest of PASM OBEX

As far as the webserver/AJAX goes this should be very straight forward once I get my head around this basic HTTP server. It's just another header type that needs the correct handler to create the correct response header back to the browser. I have a set of java powered guages that I use with the current spin webserver, all the ajax request does is query for a few variables that are updated server side and sent back that control the guages browser side. Everything is 8.3 file format already for the webserver in spin that Mike G wrote.

[MJB]

LOL

But as I sit in front of my Tachyon systems connecting to them easily via the Ethernet, transfer files up and down on FTP, manipulate virtual memory files on the SD file system and access webpages stored on them while I write some test code through Telnet I just think "this is pretty cool". All I need now is a P2 or another Prop as the terminal (+editor) and it's stand-alone. Maybe I might even try to tackle a simple text VGA + editor on the same Prop I'm not aware of any other Prop systems that can do all this on an unenhanced Prop, and I'm really only using the one cog! (at the moment). Or is that too "chip head" for you

actually, when I want to play/work Propeller I have a laptop or tablet anyhow with a serial, ethernet / future Bluetooth (you have it already Peter)
with all my other things (mail internet etc...)
but I usually have no extra VGA plus kbd/mouse with me ... so I can't see a need for a real standalone.
Intermediate option would be kind of texteditor based on ANSI-Terminal, that can run over serial, bluetooth, telnet - but a simple editor is everywhere ..
so I think effort is better spent on other enhancements before the standalone idea.
Like webserver with cgi/js/AJAX/xml support ... to write nice interactive WEB-GUIs
m2c

[Peter Jakacki]

Thanks for your comments and improved code, Peter. Your changes are good learning for me. I have been away from this code long enough to need to study it again to understand. When I first looked at Tachyon I made this comment to myself in a note file: "NOT F****** AROUND WITH THIS ANYMORE. Tachyon is for chip heads that are way deeper than me. Bye bye . . ." but this environment is too beguiling so I came back. I'm still dog paddling but it's good.

LOL

But as I sit in front of my Tachyon systems connecting to them easily via the Ethernet, transfer files up and down on FTP, manipulate virtual memory files on the SD file system and access webpages stored on them while I write some test code through Telnet I just think "this is pretty cool". All I need now is a P2 or another Prop as the terminal (+editor) and it's stand-alone. Maybe I might even try to tackle a simple text VGA + editor on the same Prop I'm not aware of any other Prop systems that can do all this on an unenhanced Prop, and I'm really only using the one cog! (at the moment). Or is that too "chip head" for you

[artkennedy]

Hi Art, I had a look at this code when you first posted it ...

--- extend sign of 16-bit word into a long
: EXT16 ( sign16 -- sign32 ) DUP $8000 AND IF $1.0000 - THEN  \ convert 16 bit twos complement number to real decimal
;

This is way better than my 2s>R. I got a bit carried away trying to make it flexible per byte length - not really called for.

[artkennedy]

Thanks for your comments and improved code, Peter. Your changes are good learning for me. I have been away from this code long enough to need to study it again to understand. When I first looked at Tachyon I made this comment to myself in a note file: "NOT F****** AROUND WITH THIS ANYMORE. Tachyon is for chip heads that are way deeper than me. Bye bye . . ." but this environment is too beguiling so I came back. I'm still dog paddling but it's good.

[D.P]

What do you want to change the terminal type to? The default on my system (via "echo $TERM") is xterm-256color, which seems to work with the ANSI-emitting words in Tachyon Forth at least on my system. If you wanted to change it to something else, take a look at the output of "toe -a" to see a listing of terminals ncurses knows about on your mac... since Tachyon Forth isn't using termcap or ncurses to influence what how it sends ANSI commands, I'm not sure it has much effect, but maybe I'm making too many assumptions about how you're using minicom.

Mine is xterm-color.

Everything works just fine on quickstarts and PBOEs but I get the "error" on spinneret and PPDB. But everything work correctly using TeraTerm so it must be my minicom config.

I can work without minicom, no worries, but a solution is always welcome.

[base2design]

minicom is running fine, it's trying to change the term setting from the command line with -t parameter. do you know how to do this?

What do you want to change the terminal type to? The default on my system (via "echo $TERM") is xterm-256color, which seems to work with the ANSI-emitting words in Tachyon Forth at least on my system. If you wanted to change it to something else, take a look at the output of "toe -a" to see a listing of terminals ncurses knows about on your mac... since Tachyon Forth isn't using termcap or ncurses to influence what how it sends ANSI commands, I'm not sure it has much effect, but maybe I'm making too many assumptions about how you're using minicom.

[D.P]

If you use "homebrew" (http://brew.sh) you can pretty easily install minicom on your Mac (I use both picocom and minicom from brew, btw).

minicom is running fine, it's trying to change the term setting from the command line with -t parameter. do you know how to do this?

[base2design]

Yes, you are correct once again. minicom doesn't want to play well with some devices for some reason. Zterm was no better. After firing up TeraTerm in a VM everything works just fine. Now I will just run my VM in Coherence Mode and leave minicom and the others alone, I use a Mac.

Thanks for the help.

If you use "homebrew" (http://brew.sh) you can pretty easily install minicom on your Mac (I use both picocom and minicom from brew, btw).

[D.P]

Don't get frustrated, you wouldn't want to know what I have to endure most of the time ....... treat it as a learning exercise

The funny thing is I use minicom all the time but remember that you can configure minicom not just from the menu but there are also other settings that must be done through the command line to SET or UNSET etc.
I may add some checking to EXTEND to test whether the terminal is ANSI or not and to switch off any ANSI stuff if the terminal can't handle it.

Well this is the command line I use to launch minicom:

minicom -D /dev/tty.usbserial-0000103D -b 230400

I just can't seem to find the parameters for the -t <term> parameter.

I'll keep moving on.

[Peter Jakacki]

Yes, you are correct once again. minicom doesn't want to play well with some devices for some reason. Zterm was no better. After firing up TeraTerm in a VM everything works just fine. Now I will just run my VM in Coherence Mode and leave minicom and the others alone, I use a Mac.

Thanks for the help.

Don't get frustrated, you wouldn't want to know what I have to endure most of the time ....... treat it as a learning exercise

The funny thing is I use minicom all the time but remember that you can configure minicom not just from the menu but there are also other settings that must be done through the command line to SET or UNSET etc.
I may add some checking to EXTEND to test whether the terminal is ANSI or not and to switch off any ANSI stuff if the terminal can't handle it.

[D.P]

OFF CURSOR is meant for ANSI compatible terminals such as Teraterm, minicom etc but it is possible that a non-standard terminal may respond to all those escape sequences. Have you tried this with a standard ANSI (VT100 compatible) terminal?

Yes, you are correct once again. minicom doesn't want to play well with some devices for some reason. Zterm was no better. After firing up TeraTerm in a VM everything works just fine. Now I will just run my VM in Coherence Mode and leave minicom and the others alone, I use a Mac.

Thanks for the help.

[Peter Jakacki]

Comment out BACKUP? no joy

Comment out BUTORUN EXTEND.boot I am booted.

OFF CURSOR is meant for ANSI compatible terminals such as Teraterm, minicom etc but it is possible that a non-standard terminal may respond to all those escape sequences. Have you tried this with a standard ANSI (VT100 compatible) terminal?

[D.P]

No idea except it seems that Tachyon does run on the PPDB in that it compiles EXTEND.fth, but where does it fail, during or after or compiling, or after boot? The 1796 at the top of the screen almost looks like a line number right at the end, try commenting out ?BACKUP etc and see if that helps. If it's during boot then comment out the AUTORUN EXTEND.boot part, put it's still a mystery to me though but if you can be a bit more detailed and what does work, what doesn't and at what point etc then that may help narrow it down. There's nothing special about the hardware of the PPDB but perhaps some volunteer with one could try the same.

Comment out BACKUP? no joy

Comment out BUTORUN EXTEND.boot I am booted.

Stepping through boot line by line and:

pub EXTEND.boot
	RND boot !                                         \ OKAY
 	keypoll W~ --- stop any background polling in case it's been locked in      \ OKAY
	' TIMERTASK 7 RUN			\ always run this in cog 7      \ OKAY
 	OFF CURSOR              \ REBOOT
 	SPLASH          \  didn't try by itself
	.STATS           \ REBOOT
	.MODULES     \ didn't try
 	.BOOTS          \ didn't try
	uboot W@ ?DUP IF DUP PFA>NFA IF DUP .AUTORUN CALL ELSE DROP THEN THEN	\ disregard invalid or expired boot     \ didn't try
 	CR
	;

[Peter Jakacki]

My PBOE works as well, just not the P Professional Dev Board?

No idea except it seems that Tachyon does run on the PPDB in that it compiles EXTEND.fth, but where does it fail, during or after or compiling, or after boot? The 1796 at the top of the screen almost looks like a line number right at the end, try commenting out ?BACKUP etc and see if that helps. If it's during boot then comment out the AUTORUN EXTEND.boot part, put it's still a mystery to me though but if you can be a bit more detailed and what does work, what doesn't and at what point etc then that may help narrow it down. There's nothing special about the hardware of the PPDB but perhaps some volunteer with one could try the same.

[D.P]

D.P.
just loaded the very latest into PropBOE

 
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok

00:00:00  End of source code, 1797 lines processed and 0000 errors found
MODULES LOADED:
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $5C92...743E for 6060 (3623 bytes added)
CODE:   $0000...3481 for 7381 (7169 bytes added)
CALLS:  0467 vectors free
RAM:    10257 bytes free
 ok
\
EEPROM  9600d SERBAUD  ok
?BACKUP  ok
  ok
  ok

My PBOE works as well, just not the P Professional Dev Board?

[MJB]

D.P.
just loaded the very latest into PropBOE

 
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23140617.0000
 ok

00:00:00  End of source code, 1797 lines processed and 0000 errors found
MODULES LOADED:
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO


NAMES:  $5C92...743E for 6060 (3623 bytes added)
CODE:   $0000...3481 for 7381 (7169 bytes added)
CALLS:  0467 vectors free
RAM:    10257 bytes free
 ok
\
EEPROM  9600d SERBAUD  ok
?BACKUP  ok
  ok
  ok

[D.P]

Just downloaded fresh copies of both Tachyon and Extend, twice, double checked twice. Complied twice and I get this stuff again?

1796

00
  Propeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

ropeller .:.:--TACHYON--:.:. Forth V23140616.0000

And the version of Extend is: pub EXTEND.fth ." Primary extensions to TACHYON kernel - 140604-02OO" ;

[D.P]

That sounds more like a hardware problem for some reason but please check your V2.3 copy, there was one a while ago that I had let the txd line float high in but decided to revert back as not all boards have pull-ups. I've just updated all the Dropbox files anyway so it should see that they have been modified recently, just in case you account is not synching. The other thing to do is just go back to the basics and measure the power rails while all this is happening, even put your meter on AC in case of ripple etc.

Fixed.

These files built correctly so it was a version of 2.3 I must have had with the "float high" configuration.

[Peter Jakacki]

I have been having problems with the current Kernel and Extend. I can complie and download the Kernel just fine with BST but when I go and load Extend the system goes into a constant RESET before executing the BACKUP command in Extend? In another thread I read this from PhiPi



Also I can load a V2.1 Kernel and associated Extend just fine so I am really stumped about this. Luckily Peter has provided the binaries for me that allow me to continue on.

That sounds more like a hardware problem for some reason but please check your V2.3 copy, there was one a while ago that I had let the txd line float high in but decided to revert back as not all boards have pull-ups. I've just updated all the Dropbox files anyway so it should see that they have been modified recently, just in case you account is not synching. The other thing to do is just go back to the basics and measure the power rails while all this is happening, even put your meter on AC in case of ripple etc.

[D.P]

I have been having problems with the current Kernel and Extend. I can complie and download the Kernel just fine with BST but when I go and load Extend the system goes into a constant RESET before executing the BACKUP command in Extend? In another thread I read this from PhiPi

When this happens with the PropPlug plugged in, is the USB cable to the computer also connected? If not, this is a known issue, wherein the P30 output from the Prop tries to power the PropPlug which, in turn, resets the Prop via the USB chip's DTR line. This will happen continuously if your program starts one of the serial I/O objects, keeping your program from getting any kind of start. The remedy is to not start serial I/O under this condition or to add a 2.2K-4.7K pull-up to P30, which will keep the PropPlug powered all the time.

Also I can load a V2.1 Kernel and associated Extend just fine so I am really stumped about this. Luckily Peter has provided the binaries for me that allow me to continue on.

[Peter Jakacki]

The Spinneret is now accessible via the internet at tachyonforth.com:81 as well as the W5200 at normal port 80. The Spinneret binary is in the dropbox account (see my sig)

[Peter Jakacki]

Very nice Peter, I need to review the code and keep learning.

Could you post a binary please, thanks

I feel asleep before I could finish tweaking it! I still need to sift through the operation of it as some parts aren't responding consistently but overall the functionality appears sound. I will pop a current binary into Dropbox, updating the current Spinneret binary.

[D.P]

Now that I've spent a couple of good hours looking at the W5100 again and converting W5200.fth down into a W5100 driver I have been able to load up a Spinneret with all the filesystem and network drivers. I am slowly going through the code tweaking any little differences but I basically have FTP, WEB, and Telnet running. The published source code webpage document is here. Build your system as indicated at the end of the document and remember to CREATE SMALL before you first load EXTEND.fth.

This is the boot screen.

  Propeller .:.:--TACHYON--:.:. Forth V23140606.2000

NAMES:  $50B9...740D for 9044 (0910 bytes added)
CODE:   $0000...4EEB for 11159 (3803 bytes added)
CALLS:  0165 vectors free
RAM:    0462 bytes free

MODULES LOADED: 
4010: EASYNET.fth         WIZNET NETWORK SERVERS 140517.0100 
38B5: W5100.fth           WIZNET W5100 driver 140613.0000 
2E8B: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140528-0000 
29D0: SDCARD.fth          SD CARD Toolkit - 140121.2200 
286D: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200 
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO
BOOT: EXTEND.boot
BOOT: EASYNET

*** Tachyon Forth Network and File Server *** 

 Mounted SD Card 
Media mounted as CAC0.660D          NO NAME     FAT32    Cluster size = 2,768   Sectors = 6,320

Listing directory 
NO NAME    

TEST0001.TXT   SYSLOG  .TXT   FAVICON .ICO   HOME    .HTM   HTTP404 .HTM   
FIRMWARE.ROM    ... ready! 

************ W5100 STATUS ************ 
LINK DOWN
CHIP VER  0000
SRC IP    192.168.016.151.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       02.FF.0B.FA.F3.78.
*** SOCKETS *** 
#0 40:42:41 MODE= TCP  PORT#   80        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#1 40:42:41 MODE= TCP  PORT#   21        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#2 40:42:41 MODE= CLSD PORT#             TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      
#3 40:42:41 MODE= TCP  PORT#10001        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      

* WEB, FTP, and TELNET servers running * 

Very nice Peter, I need to review the code and keep learning.

Could you post a binary please, thanks

[MJB]

Now that I've spent a couple of good hours looking at the W5100 again and converting W5200.fth down into a W5100 driver

I had the honor of watching Peter in this ...
meanwhile I undusted my Spinneret, found the PropStick and with little movement to limit my back pain loaded all the modules.
Started and ... no SD-card found ... I remember there is Peters SD image on dropbox - will have a look later ...
ok take one from a smartphone I just had available
startup again ... directory gets listet
... aha I need to type GO ;-)
webserver started ... and I can connect from Browser - no .htm files found ... because non are there
Filezilla started ... shows the dir, but nothing more ... connection timeout ...
Telnet startet ... connection times out
not bad, given that I have not read the documentation completely

i.o.w. very impressive - thanks Peter

[Peter Jakacki]

Now that I've spent a couple of good hours looking at the W5100 again and converting W5200.fth down into a W5100 driver I have been able to load up a Spinneret with all the filesystem and network drivers. I am slowly going through the code tweaking any little differences but I basically have FTP, WEB, and Telnet running. The published source code webpage document is here. Build your system as indicated at the end of the document and remember to CREATE SMALL before you first load EXTEND.fth.

This is the boot screen.

  Propeller .:.:--TACHYON--:.:. Forth V23140606.2000

NAMES:  $50B9...740D for 9044 (0910 bytes added)
CODE:   $0000...4EEB for 11159 (3803 bytes added)
CALLS:  0165 vectors free
RAM:    0462 bytes free

MODULES LOADED: 
4010: EASYNET.fth         WIZNET NETWORK SERVERS 140517.0100 
38B5: W5100.fth           WIZNET W5100 driver 140613.0000 
2E8B: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 140528-0000 
29D0: SDCARD.fth          SD CARD Toolkit - 140121.2200 
286D: SPINNERET.fth       Spinneret + W5100 HARDWARE DEFINITIONS 131204.1200 
1881: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO
BOOT: EXTEND.boot
BOOT: EASYNET

*** Tachyon Forth Network and File Server *** 

 Mounted SD Card 
Media mounted as CAC0.660D          NO NAME     FAT32    Cluster size = 2,768   Sectors = 6,320

Listing directory 
NO NAME    

TEST0001.TXT   SYSLOG  .TXT   FAVICON .ICO   HOME    .HTM   HTTP404 .HTM   
FIRMWARE.ROM    ... ready! 

************ W5100 STATUS ************ 
LINK DOWN
CHIP VER  0000
SRC IP    192.168.016.151.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       02.FF.0B.FA.F3.78.
*** SOCKETS *** 
#0 40:42:41 MODE= TCP  PORT#   80        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#1 40:42:41 MODE= TCP  PORT#   21        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      
#2 40:42:41 MODE= CLSD PORT#             TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=00 CLOSED      
#3 40:42:41 MODE= TCP  PORT#10001        TXRW=    .    .RXRW=    .    .RXSZ=    .IR=00 ST=14 LISTEN      

* WEB, FTP, and TELNET servers running * 

[Peter Jakacki]

You are correct on all counts. I didn't put enough effort toward this goal. I had such an easy go using Tachyon and the Air Sense K30 CO2 sensor. That sensor is running just fine in it's own task. This mis-step has been a case of impatience with my learning Tachyon and Forth. Appreciate the reminder.

I spent about 30 minutes on it and added the bus interface words for the indirect registers as well as the 16-bit registers plus a quick test method. Still not quite right but you are welcome to play with it until I can get back to it later. Just use the section in red.

[D.P]

You will always have luck with anything you manage to achieve in Forth, even if you didn't get the W5100 running, you should be able to access the registers. As you know, the interactive environment of Forth permits all kinds of testing and development. Once you have that working right you take the next step and the next and before you know it, it's done. That's the way I got it working in the first place. I don't have much time at the moment but I will see what I can achieve in 30 minutes then!

BTW, if you already have permission to edit you also have permission to add others as well. Here is the link to the read-only webpage document.

You are correct on all counts. I didn't put enough effort toward this goal. I had such an easy go using Tachyon and the Air Sense K30 CO2 sensor. That sensor is running just fine in it's own task. This mis-step has been a case of impatience with my learning Tachyon and Forth. Appreciate the reminder.

[Peter Jakacki]

I didn't have any luck with my W5100.fth attempt. I'm just gonna be patient and help test the new spinneret W5100 driver when it's ready. There are so many enhancements in the lastest kernel and extend that I will wait for the new design.

You will always have luck with anything you manage to achieve in Forth, even if you didn't get the W5100 running, you should be able to access the registers. As you know, the interactive environment of Forth permits all kinds of testing and development. Once you have that working right you take the next step and the next and before you know it, it's done. That's the way I got it working in the first place. I don't have much time at the moment but I will see what I can achieve in 30 minutes then!

BTW, if you already have permission to edit you also have permission to add others as well. Here is the link to the read-only webpage document.

[MJB]

I think the link is a google docs link.
dp

see PM

[D.P]

there doesn't seem to be too much differences between W5100 and W5200.
if you don't need all new functionality from W5200.

Peter made a start from his W5200.fth to the new W5100.fth, where I am working on right now.
If he sends you the link you can watch, assist, contribute with your experience.
I don't know how to do this.

I think the link is a google docs link.

If so you could cut and paste the link in a PM. I don't think Peter would mind, I believe he just doesn't want it in the wild before it's ready to compile.

No worries I can wait though, plenty to do.

dp

[MJB]

I didn't have any luck with my W5100.fth attempt. I'm just gonna be patient and help test the new spinneret W5100 driver when it's ready. There are so many enhancements in the lastest kernel and extend that I will wait for the new design.

there doesn't seem to be too much differences between W5100 and W5200.
if you don't need all new functionality from W5200.

Peter made a start from his W5200.fth to the new W5100.fth, where I am working on right now.
If he sends you the link you can watch, assist, contribute with your experience.
I don't know how to do this.

[D.P]

thanks

W5100, W5200 and even W5500 seem to have a lot in common.
Do you think it would make sense to have separate lower layers for the 3 of them
and a shared upper layer, instead of keeping 3 seperate drivers, that have to be kept current
if one of them gets extended?

I didn't have any luck with my W5100.fth attempt. I'm just gonna be patient and help test the new spinneret W5100 driver when it's ready. There are so many enhancements in the lastest kernel and extend that I will wait for the new design.

[MJB]

That's basically it and later on I will probably transfer the block send routines from easynet over to the drivers instead. I will send you a link to the new W5100.fth which I haven't started working with yet but just setting up the page which was copied from W5200.fth.

thanks

W5100, W5200 and even W5500 seem to have a lot in common.
Do you think it would make sense to have separate lower layers for the 3 of them
and a shared upper layer, instead of keeping 3 seperate drivers, that have to be kept current
if one of them gets extended?

[Peter Jakacki]

I had a look at Peters W5200.fth, Spinneret schema and W5100 datasheet.

To me it looks like there are only minor changes/additions required.

replace those low level routines with parallel ones:

---

Peter, do I miss anything?

D.P. did you notice s.h. relevant?

That's basically it and later on I will probably transfer the block send routines from easynet over to the drivers instead. I will send you a link to the new W5100.fth which I haven't started working with yet but just setting up the page which was copied from W5200.fth.

[MJB]

I had a look at Peters W5200.fth, Spinneret schema and W5100 datasheet.

To me it looks like there are only minor changes/additions required.

replace those low level routines with parallel ones:

The single read / write

\ Write to the WIZnet register via SPI
pub WIZX! ( data address cnt -- )

\ Read from the WIZnet register via SPI
pri WIZX@ ( address cnt -- data )

and the block read / write

\ Read a block of memory from the WIZnet
pub LREAD ( src dst cnt -- )

\ Write a block to the WIZnet - 3.2ms/512 bytes = = 6.25us/byte = 160kB/sec
pub LWRITE ( src dst cnt -- )

and an Init:

\ Init the SPI for the WIZnet chip
pub !WIZIO

Clean layering has it's benefits ;-)

The block operations can be done with the fast auto increment mode of the indirect address mode.


##### in WIZNET.fth for the W5100 I see:

\ Write to the WIZnet register via SPI
pub WIZ! ( data address -- )

\ Read from the WIZnet register via SPI
pub WIZ@ ( address -- data )

\ Init the SPI for the WIZnet chip
pub !WIZIO


Peter, do I miss anything?

D.P. did you notice s.h. relevant?

[D.P]

I didn't have any problems but I loaded in the file system as well and made an image for the Spinneret which you can find in the Dropbox folder.

Well that worked just fine? Thanks.

[Peter Jakacki]

I didn't have any problems but I loaded in the file system as well and made an image for the Spinneret which you can find in the Dropbox folder.

[Peter Jakacki]

My feeling is that the I2C bus is really "busy" with items on the spinneret and maybe the new I2C stuff is wonky on this board?

"140602 Add in delays into I2CSTART and I2CSTOP, add timeout for @EEWAIT."

I'll fire up the Spinneret and get back to you

[D.P]

My feeling is that the I2C bus is really "busy" with items on the spinneret and maybe the new I2C stuff is wonky on this board?

"140602 Add in delays into I2CSTART and I2CSTOP, add timeout for @EEWAIT."

[D.P]

Can't see why you would be having that problem but I've updated the Dropbox files just in case. There was one little thing to do with constants that relied on the position of the bytecode for a constant but other than that it should be fine. EXTEND.fth was modified to detect this though.

I'll give it a try and postback.

UPDATE: no joy

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

ropeller .:.:--TACHYON--:.:. Forth V23140606.2000

[Peter Jakacki]

Was about to try my hacked W5100 WizNet.fth driver with a current kernel: V2.3 140606-2000 and the current Extend.fth, but after loading extend before BACKUP it goes into a reboot boot loop until I press reset.

This is on a spinneret. I've been working with 2.1 kernels with no problem, also the V2.3 kernel seems fully functional as well?

Can't see why you would be having that problem but I've updated the Dropbox files just in case. There was one little thing to do with constants that relied on the position of the bytecode for a constant but other than that it should be fine. EXTEND.fth was modified to detect this though.

[D.P]

Was about to try my hacked W5100 WizNet.fth driver with a current kernel: V2.3 140606-2000 and the current Extend.fth, but after loading extend before BACKUP it goes into a reboot boot loop until I press reset.

This is on a spinneret. I've been working with 2.1 kernels with no problem, also the V2.3 kernel seems fully functional as well?

[Peter Jakacki]

just had my first experiments with SD/EASYFILE working - great

D.P. I'd love to have a look on the changes you made in the W5100.fth file
My Spinneret still is waiting ...
Have you thought about using the parallel interface?
Since it is hardwired on the spinneret, it is of no other use anyhow.
And should be quite faster than SPI. (just realized W5200 is up to 80MHz SPI vs. 4MHz the W5100 - which is 20!!)
Parallel could give a speedup by 10 I would guess.

Yes, it might be worthwhile to use the parallel interface considering that the pins are already dedicated on the Spinneret then. So there's no reason why a Spinneret couldn't be used as a webserver as well as FTP an Telnet. I've just added the extra STOR functionality to FTP to allow me to upload files so I have been playing with editing the home page on LibreOffice and then FTPing up to the Prop after which I can view it.

BTW, the W5200 is quoted as running up to 80MHz SPI but I understand that around 33MHz is the tested limit. Same goes for the W5500 but I will be looking at a tight coupling with P2 to achieve full theoretical speed if possible.

[MJB]

Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.

Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.

just had my first experiments with SD/EASYFILE working - great

D.P. I'd love to have a look on the changes you made in the W5100.fth file
My Spinneret still is waiting ...
Have you thought about using the parallel interface?
Since it is hardwired on the spinneret, it is of no other use anyhow.
And should be quite faster than SPI. (just realized W5200 is up to 80MHz SPI vs. 4MHz the W5100 - which is 20!!)
Parallel could give a speedup by 10 I would guess.

[D.P]

Yes, I looked back at my W5100 code but other than half the memory and sockets which is not important the only real difference is the SPI framing in that W5100 always operates in 32-bit transfer mode which included the address each time, slow but sure. So I have started by copying the W5200.fth file into W5100.fth and changing the SPI interface layer using the newer SPI instructions that are part of the primary bytecode instructions. The W5200 is a lot snappier, especially if I get around to running at a faster SPI rate later but I also have the W5500 to do too, and that very soon.

Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.

[Peter Jakacki]

Migration from W5100 to W5200

Yes, I looked back at my W5100 code but other than half the memory and sockets which is not important the only real difference is the SPI framing in that W5100 always operates in 32-bit transfer mode which included the address each time, slow but sure. So I have started by copying the W5200.fth file into W5100.fth and changing the SPI interface layer using the newer SPI instructions that are part of the primary bytecode instructions. The W5200 is a lot snappier, especially if I get around to running at a faster SPI rate later but I also have the W5500 to do too, and that very soon.

[MJB]

Pretty sure that we should just be able to take W5200.fth and convert it down to suit the W5100. ....

Migration from W5100 to W5200
http://openmicrolab.com/wp/wp-content/uploads/1/cfile3.uf.1221F0404EE59A7B11507B.pdf

Impressive the 80 instead 4 MHz SPI clock and 32 instead of 16kB RAM + 8 Sockets

Changes: Different SPI command format, so driver is not fully compatible.

[Peter Jakacki]

Been trying to get this first ethernet driver to compile, seems to be just the lack of COGREGS word in the current kernel.

Looks like I can just assign the pins without this I guess.

Since you are talking SPI above anything else I should look for.

Would like to bring the few spinnerets I bought to life with a 2.3 kernel.

Pretty sure that we should just be able to take W5200.fth and convert it down to suit the W5100. I may have some time tonight so I will have a look. The old COGREGs word was replaced with SETPINS which is used by SPIPINS and MODPINS.
Passing a mask to specify up to 4 pin is handy but I may add words that allow us to specify the 4 parameters like this:
myCE mySI mySO myCK SPIPINS
and then for the mask I would:
mySPIMASK SPIMASK

[D.P]

Been trying to get this first ethernet driver to compile, seems to be just the lack of COGREGS word in the current kernel.

Looks like I can just assign the pins without this I guess.

Since you are talking SPI above anything else I should look for.

Would like to bring the few spinnerets I bought to life with a 2.3 kernel.

[Peter Jakacki]

Thanks for the code review Peter.

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:
<snip>
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.

Actually SPI instructions don't require a chip enable so it's quite redundant as you might not want the CE to return high after a transfer. You could just set the masks manually with:
SCLK |< @SPISCK COGREG!
SDIN |< @SPISCK 1+ COGREG!
So doing it this way means it won't try to set these pins low during setup.
Of course the easy way to throttle the SPI is simply to insert a delay after each write since the actual clock speed seems to work, it's just the transfer rate that needs to be reduced.
So if the clear loop is too fast just try this (adjust delay if necessary):
pub lcdwr ( data reg -- ) DC PIN! SCE PINCLR SPIWRB DROP #10 us SCE PINSET ;

If you added a character generator word then LCD could be made to work like a regular output word. I've done similar things with VGA and graphic LCDs. Let me know if you need some tips with that and also SIDCOG.

BTW, just found the datasheet for the PCD8544 chip and it does work to 4Mbit okay and there is no mention of having to slow it down anywhere.
According to the datasheet it's possible to transmit several bytes in which case a clear screen function would simply be:
0 0 goto SCE PINCLR 0 $1F8 FOR SPIWR NEXT DROP SCE PINSET
which would only take 1.4ms to clear the whole screen!

[base2design]

Thanks for the code review Peter.

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.

The picture @ http://thegaragelab.com/galleries/mi...lcd_memory.png might explain it better than my words.

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.

[Peter Jakacki]

Hey all. Finally spending some quality time with Tachyon and having fun. I've "transliterated" a small piece of Jason Dorie's Nokia 5110 spin LCD driver from OBEX (http://obex.parallax.com/objects/700/) to TF. I'm not versed in TF's idioms for things like SPI so this is the best I could do so far. Any tips from TF'ers to make this better?

\ establish pin settings
0 CONSTANT RST
1 CONSTANT SCE
2 CONSTANT DC
3 CONSTANT SDIN
4 CONSTANT SCLK
pub _write ( data -- )
    8 0 DO DUP
        7 I - SHR 1 AND SDIN PIN!
        SCLK DUP
        PINCLR
        PINSET
    LOOP
    SCE PINSET DROP
;
pub cwrite ( data -- ) SCE PINCLR 0 DC PIN! _write ;
pub dwrite ( data -- ) SCE PINCLR 1 DC PIN! _write ;
pub goto ( x y -- )
    $40 + cwrite
    $80 + cwrite
;
pub clear ( byte -- )
    0 0 goto
    $1F8 0 DO DUP dwrite LOOP
;
pub init ( -- )
    \ make pins high before setting direction
    RST  PINSET
    SCE  PINSET
    DC   PINSET
    SDIN PINSET
    SCLK PINSET
    \ set pins to outputs
    RST  MASK OUTSET
    SCE  MASK OUTSET
    DC   MASK OUTSET
    SDIN MASK OUTSET
    SCLK MASK OUTSET
    \ reset the lcd
    RST PINCLR
    RST PINSET
    $21 cwrite \ PD=0=active, V=0=normal mode, H=1=extended commands follow
    $C8 cwrite \ Vop=$48 (contrast)
    $06 cwrite \ Temp=$02
    $12 cwrite \ Bias=$02
    $20 cwrite \ PD=0=active, V=0=normal mode, H=0=normal commands follow
    $0C cwrite \ DE=10=normal display
    \ for testing only use the next two inits
    \ $0D cwrite \ DE=11=inverse
    \ $09 cwrite \ DE=01=all segments on
    0 clear
;

The built-in SPI instructions were created to make things like this a breeze, and also fast. Also the PINxxx and OUTxxx instructions always set the pin to an output as there is no sense in not making it an output, so there is never a need to explicitly set a pin to an output. Also a good technique to use in any language is not to have multiple routines which basically do the same thing, such as cwrite and dwrite, but have one and just pass the parameter as to which you want, in this case it was a simple 1 or 0 to say whether it was data or control.

Tachyon Forth also allows code "fall-through" in that if you don't place a semi-colon at the end of the definition then it won't exit but execute the next instruction of the next defintion and all TF code is code, there are no code field pointers in the way. So rather than saying 1 lcdwr for characters it just passes the character to lcdch which pushes a 1 and falls through to lcdwr. Of course I could have made 0 lcdwr work like that instead.

Here's my take:

\ establish pin settings
0 == RST
1 == SCE
2 == DC
3 == SDIN
4 == SCLK


pub lcdch ( char -- ) 1
pub lcdwr ( data reg -- ) DC PIN! SCE PINCLR SPIWRB DROP SCE PINSET ;

pub goto ( x y -- )
    $40 + 0 lcdwr
    $80 + 0 lcdwr
;
pub clear    0
pub lcdfill ( byte -- ) --- it's not really a clear since you specify the character to fill it with
    0 0 goto
    $1F8 FOR DUP lcdch NEXT
    DROP
;
pub init ( -- )
    \ make pins high before setting direction
    RST  PINCLR --- Note* PINxxx and OUTxxx always makes the pin an output
    SCE  PINSET
    DC   PINSET
    SDIN PINSET
    SCLK PINSET
    SDIN |< 8 SHL SCLK |< + SPIPINS --- setup masks for SPIWR
    \ reset the lcd
    RST PINSET --- now release RST which generated a longer reset
    $21 0 lcdwr \ PD=0=active, V=0=normal mode, H=1=extended commands follow
    $C8 0 lcdwr \ Vop=$48 (contrast)
    $06 0 lcdwr \ Temp=$02
    $12 0 lcdwr \ Bias=$02
    $20 0 lcdwr \ PD=0=active, V=0=normal mode, H=0=normal commands follow
    $0C 0 lcdwr \ DE=10=normal display
    \ for testing only use the next two inits
    \ $0D 0 lcdwr \ DE=11=inverse
    \ $09 0 lcdwr \ DE=01=all segments on
    clear
;

BTW, the multiple PINSET operations in init could all be replaced with a single OUTSET.
BTW, glad to hear you are having fun!

BTW, try this and have some more fun.

--- configure LCD as a regular output device (improved output could use control character handling)
: LCD    ' lcdch uemit W! ;
init
LCD PRINT" HELLO WORLD" CON

[base2design]

Hey all. Finally spending some quality time with Tachyon and having fun. I've "transliterated" a small piece of Jason Dorie's Nokia 5110 spin LCD driver from OBEX (http://obex.parallax.com/objects/700/) to TF. I'm not versed in TF's idioms for things like SPI so this is the best I could do so far. Any tips from TF'ers to make this better?

\ establish pin settings
0 CONSTANT RST
1 CONSTANT SCE
2 CONSTANT DC
3 CONSTANT SDIN
4 CONSTANT SCLK
pub _write ( data -- )
    8 0 DO DUP
        7 I - SHR 1 AND SDIN PIN!
        SCLK DUP
        PINCLR
        PINSET
    LOOP
    SCE PINSET DROP
;
pub cwrite ( data -- ) SCE PINCLR 0 DC PIN! _write ;
pub dwrite ( data -- ) SCE PINCLR 1 DC PIN! _write ;
pub goto ( x y -- )
    $40 + cwrite
    $80 + cwrite
;
pub clear ( byte -- )
    0 0 goto
    $1F8 0 DO DUP dwrite LOOP
;
pub init ( -- )
    \ make pins high before setting direction
    RST  PINSET
    SCE  PINSET
    DC   PINSET
    SDIN PINSET
    SCLK PINSET
    \ set pins to outputs
    RST  MASK OUTSET
    SCE  MASK OUTSET
    DC   MASK OUTSET
    SDIN MASK OUTSET
    SCLK MASK OUTSET
    \ reset the lcd
    RST PINCLR
    RST PINSET
    $21 cwrite \ PD=0=active, V=0=normal mode, H=1=extended commands follow
    $C8 cwrite \ Vop=$48 (contrast)
    $06 cwrite \ Temp=$02
    $12 cwrite \ Bias=$02
    $20 cwrite \ PD=0=active, V=0=normal mode, H=0=normal commands follow
    $0C cwrite \ DE=10=normal display
    \ for testing only use the next two inits
    \ $0D cwrite \ DE=11=inverse
    \ $09 cwrite \ DE=01=all segments on
    0 clear
;

[MJB]

Analysis of filein of EXTEND.fth

  
  
BCA>
total:
1732617860



CODE
NAME
COUNT
           1/1000


64:
W@
295306346
170


2B:
1-
236119899
136


CE:
(IF)
178126589
103


EB:
(REG)
177604603
103


16:
?DUP
176934635
102


17:
DUP
119574066
69


21:
SWAP
118367537
68


CD:
(UNTIL)
60190163
35


89:
0
59852344
35


1A:
OVER
59660067
34


0F:
EXIT
59616073
34


C2:
XCALL
59579351
34


57:
=
59420289
34


13:
2DROP
58909676
34


29:
+
2380270
1


59:
0=
1558047
1


62:
C@
1370575
1


87:
3
958984
1


5F:
C@++
939283
1


04:
XOP
893429
1


93:
CLOCK
736182
0


7E:
(BYTE)
666296
0


3A:
AND
449040
0


E2:
NEXT
327414
0


11:
NOP
327220
0


A6:
SHROUT
327192
0


6A:
C!
282122
0


2C:
1+
196180
0


86:
2
173066
0


5C:
>
159745
0


28:
-
145626
0


C1:
YCALL
120608
0


14:
DROP
111498
0


7D:
(WORD)
100052
0


6E:
W!
96724
0


85:
4
95812
0


55:
>B
93620
0


3E:
OR
88797
0


8A:
(CON)
75711
0


81:
BL
67896
0


95:
OUTSET
52968
0


83:
8
45504
0


9A:
INPUTS
44612
0


D6:
FOR
40936
0


4E:
REV
40899
0


8F:
IN@
40899
0


0D:
0EXIT
40758
0


B8:
I
31249
0


DC:
LOOP
29760
0


33:
U/MOD
25322
0


E6:
>R
18389
0


E9:
R>
18389
0


40:
XOR
17884
0


CA:
(ELSE)
14896
0


36:
NIP
14068
0


84:
1
13773
0


BD:
JUMP
12982
0


88:
ON
12560
0


6C:
W+!
12191
0


97:
OUTCLR
11604
0


C9:
(AGAIN)
10571
0


68:
C+!
10228
0


42:
SHR
9189
0


1C:
3RD
7028
0


77:
CLR
6362
0


8C:
(VAR)
4288
0


4C:
2*
4170
0


82:
16
3716
0


25:
ROT
3078
0


BC:
CALL
2214
0


D7:
>L
1799
0


D9:
L>
1799
0


66:
@
1521
0


DB:
+LOOP
1489
0


07:
STREND
1260
0


FB:
UM*
1162
0


72:
!
998
0


4A:
2/
816
0


76:
SET
801
0


D2:
ADO
467
0


7C:
(TRYTE)
465
0


F3:
DELTA
465
0


31:
NEGATE
408
0


7B:
(LONG)
271
0


2F:
?NEGATE
257
0


44:
SHL
221
0


3C:
ANDN
75
0


54:
>N
26
0


70:
+!
17
0


50:
MASK
8
0


C0:
ZCALL
6
0


BF:
VCALL
4
0


F9:
ABS
4
0


2E:
-NEGATE
2
0


35:
U/
2
0


74:
BIT!
2
0


EF:
LAP
1
0

[Peter Jakacki]

Peter,
where has !BCA & .BCA from EXTEND gone to?

I sent you the link for the edit document but here's the published Google web page too for anyone who's interested. I'm still getting around to performing a sort by count but to get it to run now you just insert your code between the <BCA code BCA> like this:

<BCA 0 40 DUMP BCA>                                                             
0000_0000:   00 B4 C4 04  6F E3 10 00   A0 7E A8 7E  74 7E AC 7E   ....o....~.~~
0000_0010:   90 7E 02 00  64 7E 00 00   FE 18 61 01  D0 07 00 00   .~..d~....a..
0000_0020:   00 84 03 00  00 48 00 00   00 00 00 00  00 00 00 00   .....H.......
0000_0030:   00 00 00 00  00 00 00 00   00 00 00 00  8D 20 00 00   .............
CODE NAME      COUNT                                                            
04:  XOP       405                                                              
0D:  0EXIT     34                                                               
0F:  EXIT      1630                                                             
13:  2DROP     4                                                                
14:  DROP      152                                                              
16:  ?DUP      428                                                              
17:  DUP      396                                                              
1A:  OVER      233                                                              
21:  SWAP      216                                                              
28:  -         151                                                              
29:  +         406                                                              
2C:  1+        64                                                               
31:  NEGATE    64                                                               
33:  U/MOD     34                                                               
36:  NIP       41                                                               
3A:  AND       206                                                              
3E:  OR        40                                                               
40:  XOR       64                                                               
42:  SHR       72                                                               
44:  SHL       4                                                                
54:  >N        128                                                              
55:  >B        8                                                                
57:  =         160                                                              
59:  0=        440                                                              
5C:  >         308                                                              
5F:  C@++      52                                                               
62:  C@        396                                                              
64:  W@        340                                                              
66:  @         208                                                              
68:  C+!       40                                                               
6A:  C!        61                                                               
72:  !         74                                                               
77:  CLR       4                                                                
7D:  (WORD)    5                                                                
7E:  (BYTE)    665                                                              
81:  BL        200                                                              
82:  16        12                                                               
83:  8         17                                                               
84:  1         34                                                               
85:  4         225                                                              
86:  2         68                                                               
87:  3         128                                                              
88:  ON        40                                                               
89:  0         154                                                              
8C:  (VAR)     145                                                              
B8:  I         324                                                              
BA:  LSTACK    64                                                               
C0:  ZCALL     1                                                                
C1:  YCALL     300                                                              
C2:  XCALL     1479                                                             
C9:  (AGAIN)   44                                                               
CA:  (ELSE)    4                                                                
CE:  (IF)      1010                                                             
D2:  ADO       5                                                                
D5:  DO        8                                                                
D6:  FOR       20                                                               
DB:  +LOOP     68                                                               
DC:  LOOP      96                                                               
E2:  NEXT      32                                                               
E6:  >R        68                                                               
E9:  R>        68                                                               
EB:  (REG)     740                                                              
ED:  REG       114                                                              
------------------------ ok

[MJB]

The BCA loads a small RUNMOD <snip>

Peter,
where has !BCA & .BCA from EXTEND gone to?

[Peter Jakacki]

A few days ago mjb mentioned that it would be good to be able to analyse bytecode in realtime so I thought up of a Q&D method that was next to realtime, just a little slower. The BCA loads a small RUNMOD which then redirects doNEXT via unext to the BCA which then looks after those functions plus it uses 256 longs in BUFFERS to count each code. I just got around to really testing now and I happened to have a gate card-reader controller running and grabbed the results and then pasted that into a spreadsheet.

These are the sorted results, just for interest and note that since it just sits around reading the I2C RTC that there are some skewed results.

EGATE software running - system info

.TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: SERIN.TASK                      379B 01 00 00 00 00 00 
0007: TIMERTASK                       2F74 01 00 00 00 00 00  ok
.TIMERS  ticks = 1/1000
3AD8: master              000,000ms =0000.0000 L3B64 
3B64: operation           000,000ms =0000.0000 L3B74 
3B74: delay               000,000ms =0000.0000 L3D38 
3D38: checktimer          079,236ms =0001.3583 L2E00 
2E00: wdt                 029,913ms =0000.74D7 L0001 ALARM=REBOOT ok
.MODULES 
MODULES LOADED: 
364A: EGATE.fth           RFID Gate Access interface V1.0 140605.1700 - Peter Jakacki & Jack Stubbs 
3461: MCP79410-RTC.fth    MCP79410 I2C DECIMAL RTC DRIVER - 140422.0000 
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 140604-02OO

CODE	NAME	COUNT
93:	CLOCK	117085896
E2:	NEXT	52039352
A3:	SHRINP	39011640
7E:	BYTE	20654363
11:	NOP	19527126
C1:	YCALL	18734587
0F:	EXIT	16953988
8A:	CON	15999567
89:	0	13336702
A6:	SHROUT	13297219
9A:	INPUTS	12736736
17:	DUP	10178693
21:	SWAP	9720988
CE:	IF	9108331
C2:	XCALL	9031175
14:	DROP	8685744
83:	8	7323679
97:	OUTCLR	7317844
42:	SHR	6508626
D6:	FOR	6505507
4E:	REV	6504772
59:	0=	6257384
BF:	VCALL	5686467
1A:	OVER	5077834
8C:	VAR	4878459
25:	ROT	4876571
B8:	I	4350596
6A:	C!	4350415
DC:	LOOP	4340910
C0:	ZCALL	4332014
29:	+	4207290
95:	OUTSET	3800051
3A:	AND	3615721
62:	C@	3458983
CD:	UNTIL	3167818
FB:	UM*	2977644
04:	XOP	2510320
5F:	C@++	2358507
5C:	>	2324733
57:	=	2196607
64:	W@	1839204
85:	4	1633370
66:	@	1630539
16:	?DUP	1383374
2B:	1-	1277622
2C:	1+	1257434
7D:	WORD	1050279
84:	1	1005054
EB:	REG	895974
86:	2	736835
13:	2DROP	543457
D2:	ADO	541536
7B:	LONG	541366
4C:	2*	513905
87:	3	443141
0D:	0EXIT	279914
8F:	IN@	274867
72:	!	272809
BC:	CALL	270744
F3:	DELTA	270688
50:	MASK	270683
98:	OUTPUTS	270683
1C:	3RD	180464
28:	-	172347
40:	XOR	172111
3E:	OR	16125
81:	BL	10629
C9:	AGAIN	10416
ED:	REG	9263
88:	ON	8124
68:	C+!	7759
DB:	+LOOP	5827
54:	>N	5728
44:	SHL	4831
33:	U/MOD	4712
E9:	R>	4018
E6:	>R	4017
36:	NIP	2810
82:	16	2526
55:	>B	2326
6E:	W!	1261
77:	CLR	894
31:	NEGATE	822
BA:	LSTACK	818
D5:	DO	769
CA:	ELSE	685
6C:	W+!	447
76:	SET	438
07:	STREND	108
D7:	>L	93
D9:	L>	93
2F:	?NEGATE	31
4A:	2/	18
7C:	TRYPE	5
35:	U/	2

EDIT: Or how about just what happens when we run 10 iterations of the Sieve of Eratosthenes:

!BCA SIEVE 1 $1A5 COG! .BCA
CODE    COUNT        NAME
B8:    296031        I
17:    169211        DUP
29:    160632        +
6A:    150041        C!
89:    150005        0
DB:    149960        +LOOP
CE:    101261        IF
8C:    96314        VAR
BF:    96312        VCALL
62:    82017        C@
DC:    81911        LOOP
8A:    26210        CON
C0:    26210        ZCALL
C2:    19467        XCALL
0F:    19434        EXIT
5C:    19155        >
21:    19061        SWAP
14:    19003        DROP
2C:    19000        1
84:    18991        3
1A:    7276        OVER
D5:    7211        DO
EB:    422        REGADR
7E:    341        BYTE
16:    249        ?DUP
04:    170        XOP
5F:    162        C@++
64:    155        W@
C9:    132        AGAIN
59:    115        0=
3A:    92        AND
3E:    61        OR
68:    58        C+!
88:    58        ON
CD:    50        UNTIL
0D:    46        0EXIT
33:    46        U/MOD
C1:    13        YCALL
E6:    13        >R
E9:    13        R>
13:    12        2DROP
87:    12        1
2B:    11        -1
77:    11        CLR
1C:    10        3RD
28:    4        -
07:    3        STREND
42:    2        SHR
57:    2        =
66:    2        @
72:    2        !
7D:    2        WORD
83:    2        8
BA:    2        LSTACK
CA:    2        ELSE
EF:    2        LAP
35:    1        U/
36:    1        NIP
44:    1        SHL
7C:    1        TRYTE
81:    1        BL
D2:    1        ADO
FB:    1        UM*

[D.P]

hi D.P. I have an idle Spinneret sitting here waiting for Tachyon as well :-)
I want to use it as the internet gateway to my sensor/actor network I am setting up here.

The kernel, Extend and Wiznet versions are from DROPBOX ?
Original or did you have to adapt things?

As I understand the WIZNET.fth for W5100 does not run with Tachyon2.3 ??
That's why I postponed my Spinneret experiments atm. ( busy with construction site, house in the mountains ..)
Thanks MJB

Here are the files I use on the spinneret. It would be great as Peter says if we get a new driver that supports the 5100 stuff too. That chip will be a buck very soon now and great for simple network devices with a 64K eeprom, prop 1, magjack, basic IO.

The zip file contains Tachyon V2.1 with a modified extend so that both SPI and I2C work well together and the appropriate WIZnet.fth driver include with added support for client sockets i.e. DIP, DPORT words to support destination port and ip.

I am using the spinneret in a UDP client CO2 monitoring application with the Air Sense K30 10K PPM sensor, let me know if you want that finicky K30 I2C base forth driver, what a mess of a device that just doesn't follow its own datasheet. I worked for a week to get the K33 (CO2, TEMP, RH) to work with I2C in spin quite a while back, took me less than 2 hours to get the K30 working with Tachyon. THANKS PETER.

Enjoy

[base2design]

Thanks Peter and sorry about the thread header too. I guess I know too little about the underlying operation of the Prop to understand how "machine code" (PASM) gets executed natively, much less under TF. As far as exploring existing PASM code, is it productive to look at the SPI/I2C implementation on TF compared to spin/pasm stuff to understand things better?

As far as "pressure", hell dude, until I'm writing you a check, there's no pressure. Thanks though!

-joe

[Peter Jakacki]

So I'm breaking into Tachyon again and I've still not figured out how to include PASM code from OBEX into the system... is there an example of how to do this buried in this thread? I specifically wanted to pull the PASM portion of SIDcog into it and Peter had implied it was easy but I'm too thick to see the path.

Can anyone point me to an example?

Regards!

Please make sure you change your thread title to reflect the subject matter, you are discussing the sidcog but the thread is still titled "Spinneret .......".

Now on the subject of the sidcog I had replied at the time and even created a Google doc with most of the code done but I think this was waiting on my target resident obex where TF can find and load pasm objects from upper eeprom. I might be able to convert the sidcog code by passing the compiler generated listing through TF itself which can extract the machine code and write it to a eeprom (or SD) file. I probably would have finished this at the time had you been chasing me about it but I've got plenty of things to do so "no pressure, no results"

[base2design]

So I'm breaking into Tachyon again and I've still not figured out how to include PASM code from OBEX into the system... is there an example of how to do this buried in this thread? I specifically wanted to pull the PASM portion of SIDcog into it and Peter had implied it was easy but I'm too thick to see the path.

Can anyone point me to an example?

Regards!

[max72]

The link to the Google doc is here

https://docs.google.com/document/d/1...SQeZSy-Nvg/pub

Massimo

[Dave Hein]

There's a link to the Tachyon Dropbox in Peter's signature.

Thanks, that's what I was looking for. I usually ignore the stuff in people's signatures. It might be a good idea to add that link to beginning of the Tachyon documents pages in BIG letters.

[Dave Hein]

Here's the Fast Forth PASM code that implements the kernel code used for words that are created using CREATE. It loads the address of the body onto the stack, and then checks for a non-zero pointer. If the pointer is zero it just exits the word. Otherwise, it jumps to the DOES> code by setting the PC equal to the pointer. To prevent normal variables by being slowed down by the DOES> code you use a kernel word that does not support the pointer, and have another kernel word that is only used for words that do have a DOES> pointer. CREATE could default to the non-does kernel word, and the DOES> word could replace it with the other word that supports DOES>.

_var                    wrlong  nos, dstackptr
                        mov     nos, tos
                        mov     tos, pc
                        rdbyte  temp1, pc
                        add     pc, #1
                        add     tos, #3
                        rdbyte  pc, pc
                        shl     temp1, #8
                        or      pc, temp1       wz
                        add     dstackptr, #4
      if_z              jmp     #exit
                        jmp     #innerloop

[mindrobots]

Yes, I've run into that page a few times, but where's the link to the Spin files or a zip file?

There's a link to the Tachyon Dropbox in Peter's signature.

[Dave Hein]

Here are a few words that I use to implement DOES> in the Fast forth interpreter. The word DOES> is used only during compilation, and it inserts the word _DOES into the compiled word, which is a runtime word. _DOES is followed by EXIT, and then followed by the code defined after DOES>. The _DOES word will add a pointer to this code to the header of the last word defined.

\ WORD HEADER ACCESSORS
: >does 1+ ;
: >body 4 + ;
: link>does link>xt 1+ ;
: link>body link>xt 4 + ;

\ DEFINE DOES> WORDS
: cc! over 8 rshift over c! 1+ c! ;
: _does r> dup >r 1+ last @ link>does cc! ;
: does> compile _does [compile] exit ; immediate

\ WORDS THAT USE DOES>
: marker create last @ , does> @ dup dp ! @ last ! ;
: defer  create 0 , does> @ execute ;
: value create , does> @ ;
: 2constant create swap , , does> dup @ swap cellsize + @ ;

[Dave Hein]

Yes, I've run into that page a few times, but where's the link to the Spin files or a zip file?

[Peter Jakacki]

I was going to try implementing DOES> in Tachyon, but I can't seem to find the Tachyon source code. I have been able to download it before, but I can't recall where I got it. Every link I click on sends me to web pages with lots of documentation on Tachyon, and I can't find a link for the source. The link is probably buried somewhere in the documentation. Does anybody know the direct link to the source code?

Yes, the intro points to the links page and it's in there but here it is as well

[Dave Hein]

I was going to try implementing DOES> in Tachyon, but I can't seem to find the Tachyon source code. I have been able to download it before, but I can't recall where I got it. Every link I click on sends me to web pages with lots of documentation on Tachyon, and I can't find a link for the source. The link is probably buried somewhere in the documentation. Does anybody know the direct link to the source code?

[Peter Jakacki]

hi D.P. I have an idle Spinneret sitting here waiting for Tachyon as well :-)
I want to use it as the internet gateway to my sensor/actor network I am setting up here.

The kernel, Extend and Wiznet versions are from DROPBOX ?
Original or did you have to adapt things?

As I understand the WIZNET.fth for W5100 does not run with Tachyon2.3 ??
That's why I postponed my Spinneret experiments atm. ( busy with construction site, house in the mountains ..)
Thanks MJB

I will revisit the W5100 and see if I can modify W5200.fth to work with it. That way it will just fit in with all the new stuff, even the microSD.

[MJB]

I have a version of Tachyon running on the spinneret with the appropriate Wiznet.fth module.

  Propeller .:.:--TACHYON--:.:. Forth V21130620.0000

MODULES LOADED:
2ED5: K30.fth             Air Sense C02 Sensor Driver 140602-11:00
2B31: WIZNET.fth          WIZNET 5100/5200 driver 130216.1500
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 130722.0000
 ok

<snip>

hi D.P. I have an idle Spinneret sitting here waiting for Tachyon as well :-)
I want to use it as the internet gateway to my sensor/actor network I am setting up here.

The kernel, Extend and Wiznet versions are from DROPBOX ?
Original or did you have to adapt things?

As I understand the WIZNET.fth for W5100 does not run with Tachyon2.3 ??
That's why I postponed my Spinneret experiments atm. ( busy with construction site, house in the mountains ..)
Thanks MJB

[MJB]

\MJB thoughts about create does> for Tachyon
{
 : CONSTANT  CREATE  ,  DOES>  @  ; 

       and used as 

           53 CONSTANT PRIME  <cr> ok 

       Now test it:

           PRIME . <cr>  53  ok . 
}

: ` [COMPILE] [COMPILE] ;

: mjbCREATE  
\ will be stored in the ucreate vector so can be used by new code ...
\ not sure if this is good ... or need to use another name since create and CREATE are in use already ...
\ maybe Create  ;-)
    ` CREATEWORD 
    \ insert CFA of NEXT definition - which will be created by does> 
    \ so either does> does the substitution and places it's newly created dummy word PFA here,
    \ or we start from this word and search at runtime for the next words PFA
    \ then continue compiling the create part of the create does> pair.
    
    \ DOES> first performs a ; to finish the definition, the CREATE is part of.
    \ then DOES> starts a new dummy definition  pri  dummyXYZ
    \ and stores the PFA into the previous definition, so at each execution of the creation of a new 
    \ child word, the child words PFA gets set correctly.
    \ can the dummy definitions NAME be removed from the dictionary already now, before it is completed ???

    \ now all code following DOES> gets compiled into the dummy definition
    \ which is automatically completed with the next  ;

[D.P]

I see that you are using an earlier kernel and I think that since I2C uses the CLOCK word which uses a mask in a COGREG to toggle the SCL line that this also overwrites one of the SPIO COGREGs. V2.3 uses a separate COGREG for CLOCK but maybe as a quick hack you could patch your I2C routines by replacing any reference to CLOCK sequences such as CLOCK NOP CLOCK with SCL PINSET SCL PINCLR just as a quick suggestion. The timing is a little slower but that shouldn't matter.

You are correct, all is well in spinneret land, thanks.

This comment made me not question any conflicts in the older kernel.

130605        Modified the CLOCK instruction which is used by I2C routines to use COGREG 4 as the clock mask rather than 0 to prevent conflict with SPI routines which may be operating at the same time.

[Peter Jakacki]

I have a version of Tachyon running on the spinneret with the appropriate Wiznet.fth module. The module works properly. I have a K30 CO2 senor connected to the I2C bus same as standard EEPROM.
I have words that access the sensor correctly. I can redirect output via the Lan connection just fine, but as soon as I issue any I2C commands i.e. I2CSTART, the networking hangs completely. I don't see any conficts in the ESPIO section in the source or in the Wiznet.fth driver.

I see that you are using an earlier kernel and I think that since I2C uses the CLOCK word which uses a mask in a COGREG to toggle the SCL line that this also overwrites one of the SPIO COGREGs. V2.3 uses a separate COGREG for CLOCK but maybe as a quick hack you could patch your I2C routines by replacing any reference to CLOCK sequences such as CLOCK NOP CLOCK with SCL PINSET SCL PINCLR just as a quick suggestion. The timing is a little slower but that shouldn't matter.

[Dave Hein]

On the subject of DOES>, pfth includes a 16-bit address in the dictionary entry for each word that points to the DOES> code. This value is normally set to zero unless DOES> is specified. The variable kernel function will load the address of the word's body onto the stack, and then jump to the DOES> code if the pointer is non-zero. You may want to have two different variable kernel functions where one is used when DOES> is specified and the other is used when DOES> is not specified.

[D.P]

I have a version of Tachyon running on the spinneret with the appropriate Wiznet.fth module. The module works properly. I have a K30 CO2 senor connected to the I2C bus same as standard EEPROM.
I have words that access the sensor correctly. I can redirect output via the Lan connection just fine, but as soon as I issue any I2C commands i.e. I2CSTART, the networking hangs completely. I don't see any conficts in the ESPIO section in the source or in the Wiznet.fth driver.

?

Thanks

  Propeller .:.:--TACHYON--:.:. Forth V21130620.0000

MODULES LOADED:
2ED5: K30.fth             Air Sense C02 Sensor Driver 140602-11:00
2B31: WIZNET.fth          WIZNET 5100/5200 driver 130216.1500
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 130722.0000
 ok

Here's the code in question, you can see the debugging in BEGIN UNTIL loop. Commenting out the I2CSTART I2CSTOP line and the networking runs correctly.

The rc2 word that reads the sensor works correctly as well.

pub lanC
  #27 #26 I2CPINS              \ set i2c pins other than eeprom - conflict testing
  DECIMAL                      \ set us in decimal mode
  CR ." Setting up networking.... " CR
  !WIZIO                        \ initialize the wiznet SPI setup for spinnerette
  #20 ms
  &192.168.10.1 GATEWAY         \ set the gateway
  &255.255.255.0 SUBNET         \ subnet
  &192.168.10.80 SRCIP          \ source ip
  $00.08 $DC.01.02.03 SHAR      \ mac
  #50 ms
  0 SOCKET CLOSE		\ select socket 0 and force it into life with CLOSE
  #50 ms
  UDP		   	  \ enable socket MODE UDP
  #33333 PORT             \ source port
  #22222 DPORT		  \ destination  port  22222
  &192.168.10.10 DIP      \ destination  ip
  #50 ms
  OPEN                    \ open the socket
  #50 ms
  lEmit                   \ redirect output to lan
  BEGIN
     I2CSTART I2CSTOP
\     rc2 DROP                         \ get a co2 reading
\    0= IF CO2? W@ DUP #10000 <        \ if the ack flag from the IC2 write is zero make sure value < #10K
\       IF  co2$ .STR  CO2? W@ . CR            \ then write the banner and the value
      co2$ .STR  CO2? W@ . CR            \ then write the banner and the value
\
\      ELSE DROP                       \ num > #10K drop the dup
\      THEN
\    THEN
  #1500 ms
  ESC? UNTIL                   \ esc key pressed ?
  CON                                 \ redirect back to console
  EEPROM                              \ set i2c pins back to eeprom
;

[D.P]

My understanding:
CREATE DOES> is used to create so called DEFINING WORDS like
: VARIABLE CONSTANT and the like.

from FORTH PRIMER:

Michael Ham has called the word pair CREATE...DOES>, the “pearl of Forth”. 
CREATE is a component of the compiler, whose function is to make a new 
dictionary entry with a given name (the next name in the input stream) 
and nothing else. 
DOES> assigns a specific run-time action to a newly CREATEd word.  
a. Defining “defining” words          
CREATE finds its most important use in extending the powerful class of         
Forth words called “defining” words. The colon compiler  ":"  is such         
a word, as are VARIABLE and CONSTANT.          
The definition of VARIABLE in high-level Forth is simple              
: VARIABLE  CREATE   1 CELLS  ALLOT ;         
We have already seen how VARIABLE is used in a program. (An 
alternative definition found in some Forths is             
: VARIABLE  CREATE   0  ,  ;         —these variables are initialized to 0.)         
Forth lets us define words initialized to contain specific values: for        
example, we might want to define the number 17 to be a word. 
CREATE        and "," ("comma") can do this:             
17 CREATE SEVENTEEN  ,  <cr>  ok         
Now test it via             
SEVENTEEN @ .  <cr>  17 ok .          
Remarks:            
> The word , ("comma") puts TOS into the next cell of the dictionary
and increments the dictionary pointer by that number of bytes.           
> A word "C," ("see-comma") exists also — it puts a character into            
the next character-length slot of the dictionary and increments            
the pointer by 1 such slot. (In the ASCII character representation            
the slots are 1 byte long; Unicode characters require 2 bytes.)          

b. Run-time vs. compile-time actions         
 In the preceding example, we were able to initialize the variable         
SEVENTEEN to 17 when we CREATEd it, but we still have to fetch it to         
the stack via SEVENTEEN  @ whenever we want it. This is not quite what        
we had in mind. We would like to find 17 in TOS when SEVENTEEN is         
named. The word DOES> gives us the tool to do this.          
The function of DOES> is to specify a run-time action for the “child”         
words of a defining word.  Consider the defining word CONSTANT , 
defined in high-level (of course CONSTANT is usually defined in machine        
code for speed) Forth by             
: CONSTANT  CREATE  ,  DOES>  @  ;          
and used as              
53 CONSTANT PRIME  <cr> ok          
Now test it:             
PRIME . <cr>  53  ok .           
What is happening here?            
> CREATE (hidden in CONSTANT) makes an entry named PRIME 
(the first word in the input stream following CONSTANT). Then ","             
places the TOS (the number 53) in the next cell of the dictionary.           
> Then DOES> (inside CONSTANT) appends the actions of all words 
between it and ";" (the end of the definition) —in this case, "@"—             
to the child word(s) defined by CONSTANT.

in TACHYON there is CREATE ( precompiled kernel code )
which creates the dictionary entry,
reads the next word as a name for the newly created word
and then assigns the default BEHAVIOR - which is the code of VARB - makes it a variable,
means, it just puts it's address on the stack at runtime.

' CREATE <name> - Create a name in the dictionary and also a code entry 
CREATE    byte    REG,createvec,WFETCH,QDUP,_IF,01,AJMP        ' execute extended or user CREATE?
     byte    XCALL,xCREATEWORD            ' 
    byte    _BYTE,VARB,XCALL,xBCOMP,_0        ' set default bytecode as a VARIABLE
' ALLOT ( bytes -- )
ALLOT    byte    REG,codes,WPLUSST
ALLOCATED
     byte    REG,codes,WFETCH,REG,here,WSTORE
     byte    EXIT

so a DOES> could just create a dummy word, compile the code following DOES> to it
AND then put the new byte code to the previous definitions PFA.

But I do not see the relation to the new PRINT" word.

I think PRINT" is not a normal defining word since it does not define a new word each time it is called,
as compared to what VARIABLE or CONSTANT do.

To me it belongs into the category of compiler extension words,
like the IF DO LOOP etc. words.
Those have a compile time behavior (like PRINT" copying the chars to EE) and leave BYTECODES
in the compiled code (like PRINT" retrieving the chars from EE and printing them ).

I don't feel having a solid grasp on CREATE DOES> so maybe discussing it here a little helps.

I've been reading through material on CREATE DOES> as well. This is very powerful and I can see it as a way to create arrays that have indexing methods, create words that parse themselves etc.

Also when I stumble upon syntax such as this I am humbled by its eligance and brevity although the mental gymnastics of pushing a few parameters around in headspace can be hard for the beginner it is getting easier all the time.

So I am not qualified to give input on an approach for CREATE DOES> implementation in Tachyon, yet!

--- revision 140602 - Added timeout loop counter to prevent hanging

pub @EEWAIT ( adr --  )

          #50 BEGIN 1- OVER @EE 0= OVER 0= OR UNTIL 2DROP

        ;

[MJB]

My EPRINT routine which stores literal print strings to spare EEPROM instead of program memory is the reason I'm looking into it.
<snip>
So back to the CREATE DOES, I trying to think how best to implement this in TF given it's internal quirks. If you see a way that works, such as in EPRINT then by all means please suggest it!
<snip>

My understanding:
CREATE DOES> is used to create so called DEFINING WORDS like
: VARIABLE CONSTANT and the like.

from FORTH PRIMER:

Michael Ham has called the word pair CREATE...DOES>, the “pearl of Forth”. 
CREATE is a component of the compiler, whose function is to make a new 
dictionary entry with a given name (the next name in the input stream) 
and nothing else. 
DOES> assigns a specific run-time action to a newly CREATEd word.  
a. Defining “defining” words          
CREATE finds its most important use in extending the powerful class of         
Forth words called “defining” words. The colon compiler  ":"  is such         
a word, as are VARIABLE and CONSTANT.          
The definition of VARIABLE in high-level Forth is simple              
: VARIABLE  CREATE   1 CELLS  ALLOT ;         
We have already seen how VARIABLE is used in a program. (An 
alternative definition found in some Forths is             
: VARIABLE  CREATE   0  ,  ;         —these variables are initialized to 0.)         
Forth lets us define words initialized to contain specific values: for        
example, we might want to define the number 17 to be a word. 
CREATE        and "," ("comma") can do this:             
17 CREATE SEVENTEEN  ,  <cr>  ok         
Now test it via             
SEVENTEEN @ .  <cr>  17 ok .          
Remarks:            
> The word , ("comma") puts TOS into the next cell of the dictionary
and increments the dictionary pointer by that number of bytes.           
> A word "C," ("see-comma") exists also — it puts a character into            
the next character-length slot of the dictionary and increments            
the pointer by 1 such slot. (In the ASCII character representation            
the slots are 1 byte long; Unicode characters require 2 bytes.)          

b. Run-time vs. compile-time actions         
 In the preceding example, we were able to initialize the variable         
SEVENTEEN to 17 when we CREATEd it, but we still have to fetch it to         
the stack via SEVENTEEN  @ whenever we want it. This is not quite what        
we had in mind. We would like to find 17 in TOS when SEVENTEEN is         
named. The word DOES> gives us the tool to do this.          
The function of DOES> is to specify a run-time action for the “child”         
words of a defining word.  Consider the defining word CONSTANT , 
defined in high-level (of course CONSTANT is usually defined in machine        
code for speed) Forth by             
: CONSTANT  CREATE  ,  DOES>  @  ;          
and used as              
53 CONSTANT PRIME  <cr> ok          
Now test it:             
PRIME . <cr>  53  ok .           
What is happening here?            
> CREATE (hidden in CONSTANT) makes an entry named PRIME 
(the first word in the input stream following CONSTANT). Then ","             
places the TOS (the number 53) in the next cell of the dictionary.           
> Then DOES> (inside CONSTANT) appends the actions of all words 
between it and ";" (the end of the definition) —in this case, "@"—             
to the child word(s) defined by CONSTANT.

in TACHYON there is CREATE ( precompiled kernel code )
which creates the dictionary entry,
reads the next word as a name for the newly created word
and then assigns the default BEHAVIOR - which is the code of VARB - makes it a variable,
means, it just puts it's address on the stack at runtime.

' CREATE <name> - Create a name in the dictionary and also a code entry 
CREATE    byte    REG,createvec,WFETCH,QDUP,_IF,01,AJMP        ' execute extended or user CREATE?
     byte    XCALL,xCREATEWORD            ' 
    byte    _BYTE,VARB,XCALL,xBCOMP,_0        ' set default bytecode as a VARIABLE
' ALLOT ( bytes -- )
ALLOT    byte    REG,codes,WPLUSST
ALLOCATED
     byte    REG,codes,WFETCH,REG,here,WSTORE
     byte    EXIT

so a DOES> could just create a dummy word, compile the code following DOES> to it
AND then put the new byte code to the previous definitions PFA.

But I do not see the relation to the new PRINT" word.

I think PRINT" is not a normal defining word since it does not define a new word each time it is called,
as compared to what VARIABLE or CONSTANT do.

To me it belongs into the category of compiler extension words,
like the IF DO LOOP etc. words.
Those have a compile time behavior (like PRINT" copying the chars to EE) and leave BYTECODES
in the compiled code (like PRINT" retrieving the chars from EE and printing them ).

I don't feel having a solid grasp on CREATE DOES> so maybe discussing it here a little helps.

[D.P]

My EPRINT routine which stores literal print strings to spare EEPROM instead of program memory is the reason I'm looking into it.

TF is setup for compactness as well as speed and certain decisions were made at the time in this regard. I'm not quite sure why I ended up using bytecode rather than a pointer in the header field but this made sense since bytecodes are compiled, not pointers. Some bytecode are calls via a vector table which then points to the code, once again this keeps the actual code compact at 2 bytes rather than 3 but adds the overhead of a table. The advantage of the table is that addresses can be extended to beyond 64K and still compile no more than 2 bytes, something that makes the transition to P2 easier.

So back to the CREATE DOES, I trying to think how best to implement this in TF given it's internal quirks. If you see a way that works, such as in EPRINT then by all means please suggest it!

I've just trimmed the kernel again by removing some fast constants such as 5,6,7 and optimizing the code. I added >N and >B to perform quick nibble and byte masking ops as it is quite common to say $0F AND or $FF AND but this would take 3 bytes and 2.6us but now uses only a single byte and takes 400ns.

EDIT: Just thought of another way to generate fast literals, so instead of adding to an accumulator I use the pasm MIN instead to load the literal accumulator ACC which is normally zeroed and then set the carry which is normally cleared on every bytecode. So this works a treat and lets me put in any value in any order.

7704(0081) 21 4E CF 49 | BL        if_nc         min        ACC,#32+1 wc
7708(0082) 11 4E CF 49 | _16       if_nc         min        ACC,#16+1 wc
770C(0083) 09 4E CF 49 | _8        if_nc         min        ACC,#8+1 wc
7710(0084) 04 4E CF 49 | _3        if_nc         min        ACC,#3+1 wc
7714(0085) 05 4E CF 49 | _4        if_nc         min        ACC,#4+1 wc
7718(0086) 03 4E CF 49 | _2        if_nc         min        ACC,#2+1 wc
771C(0087) 02 4E CF 49 | _1        if_nc         min        ACC,#1+1 wc
7720(0088)             | _TRUE
7720(0088) 01 4E FF 84 | MINUS1                  sub        ACC,#1
7724(0089)             | _FALSE
7724(0089) 7F 00 7C 5C | _0                      jmp        #PUSHACC

Neat!

I have a few spinnerettes that I would like to use. Do you have any backups of Tachyon V2.1 and W5100.fth that support UDP clients? I have tried links on the drop box but couldn't get any UDP client "action" to work. I have telnet, ftp working but no UDP client. My current build is:

Propeller .:.:--TACHYON--:.:. Forth V21130620.0000

NAMES:  $5D96...7444 for 5806 (19120 bytes added) with 21546 bytes free
CODE:   $0000...2ECB for 6173 (0922 bytes added) with 20789 bytes free
CALLS:  0511 vectors free

AUTORUN BOOT
MODULES LOADED:
2B31: WIZNET.fth          WIZNET 5100/5200 driver 130216.1500
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 130722.0000
----------------------------------------------------------------

I can't find what I did to get UDP clients working during this timeframe.

UPDATE: oh snap, the version of W5100 driver doesn't have these two helper words to set destination and port

pub DIP ( ip -- )  sDIP WIZ4! ;   \ destination IP
pub DPORT ( port -- ) sDPORT WIZ2! ; \ destination PORT

Got confused with the UIP and UPORT words. All better, it's funny how just posting a question to the forum help to resolve issues without any feedback!

[Peter Jakacki]

I see the beginnings of CREATE DOES in the comments section of tachyon 06/02, hmmm.

My EPRINT routine which stores literal print strings to spare EEPROM instead of program memory is the reason I'm looking into it.

TF is setup for compactness as well as speed and certain decisions were made at the time in this regard. I'm not quite sure why I ended up using bytecode rather than a pointer in the header field but this made sense since bytecodes are compiled, not pointers. Some bytecode are calls via a vector table which then points to the code, once again this keeps the actual code compact at 2 bytes rather than 3 but adds the overhead of a table. The advantage of the table is that addresses can be extended to beyond 64K and still compile no more than 2 bytes, something that makes the transition to P2 easier.

So back to the CREATE DOES, I trying to think how best to implement this in TF given it's internal quirks. If you see a way that works, such as in EPRINT then by all means please suggest it!

I've just trimmed the kernel again by removing some fast constants such as 5,6,7 and optimizing the code. I added >N and >B to perform quick nibble and byte masking ops as it is quite common to say $0F AND or $FF AND but this would take 3 bytes and 2.6us but now uses only a single byte and takes 400ns.

EDIT: Just thought of another way to generate fast literals, so instead of adding to an accumulator I use the pasm MIN instead to load the literal accumulator ACC which is normally zeroed and then set the carry which is normally cleared on every bytecode. So this works a treat and lets me put in any value in any order.

7704(0081) 21 4E CF 49 | BL        if_nc         min        ACC,#32+1 wc
7708(0082) 11 4E CF 49 | _16       if_nc         min        ACC,#16+1 wc
770C(0083) 09 4E CF 49 | _8        if_nc         min        ACC,#8+1 wc
7710(0084) 04 4E CF 49 | _3        if_nc         min        ACC,#3+1 wc
7714(0085) 05 4E CF 49 | _4        if_nc         min        ACC,#4+1 wc
7718(0086) 03 4E CF 49 | _2        if_nc         min        ACC,#2+1 wc
771C(0087) 02 4E CF 49 | _1        if_nc         min        ACC,#1+1 wc
7720(0088)             | _TRUE
7720(0088) 01 4E FF 84 | MINUS1                  sub        ACC,#1
7724(0089)             | _FALSE
7724(0089) 7F 00 7C 5C | _0                      jmp        #PUSHACC

[D.P]

Hi Art, I had a look at this code when you first posted it but I've been a bit busy since, as always. The code looks clean and tidy and the only real critique I would have is that you should always standardize the get and put method as you have ADC16! requiring a 16-bit word for the data yet ADC16@ returns with that same word split into two bytes. Here's my take on your original code.

I see the beginnings of CREATE DOES in the comments section of tachyon 06/02, hmmm.

[Peter Jakacki]

I changed 2s>R to allow designated bit lengths.
I imagine this has been done before but I didn't find it so I did it again. Good practice.

"2s>R" might not be the best name.
Should it be called something else?

FORGET ADC16@


: ADC16@           \ read contents from a TI-1115 register ( rp --- msb lsb ) rp = TI-1115 register pointer
   I2CSTART        \ wakeup call
   $90 I2C!        \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   I2CSTART        \ not done yet
   $91 I2C!        \ send address $48 plus read bit
   ackI2C@         \ get MSB of target register
   ackI2C@         \ get LSB
   I2CSTOP         \ that's all for now
;


: ADC16!           \ get write n to TI-1115 register rp ( n rp --- n )
   I2CSTART        \ wakeup call
   $90 I2C!        \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   DUP 8 SHR       \ get MSB
   I2C!            \ write to target register
   $FF AND I2C!    \ write LSB
   I2CSTOP         \ that's all for now
;


$8BA3 CONSTANT ADcfg


: ADC16cfg         \ ( 16b --- ) \ configure per 16bit input value
                   \    see table of values in C:\Users\Art\Documents\Tech\!Propeller\ADC Add On\ADC_Board.txt
   1 ADC16!        \ point to config register and write
;


: ADC16ss          \ get Single-Shot reading from TI-1115  ( 16b --- MSBrd LSBrd ) configuration --- result
   ADcfg ADC16cfg  \ config and trigger conversion - temp, hard coded configuration
   BEGIN           \ repeat
      1 ADC16@     \    config register, bit 15
      DROP $80 AND \    returns HI indicating completion of conversion
   UNTIL           \ until
   0 ADC16@        \ read data register for conversion result
   SWAP            \ pop MSB
   8 SHL +         \ shift MSB and combine with LSB
;


: 2s>R      \ ( n len --- n1 ) n = twos complement number, len = bit length, n1 = converted to signed decimal number
1- 2 SWAP ^ \ compute 2 ^ (bitlen - 1)
2DUP        \ copy for test
=> IF       \ if n greater it is negative
   2 * -    \    n - 2 ^ len
ELSE        \ else n is positive
   DROP     \    no change necessary
THEN        \ then
;

Hi Art, I had a look at this code when you first posted it but I've been a bit busy since, as always. The code looks clean and tidy and the only real critique I would have is that you should always standardize the get and put method as you have ADC16! requiring a 16-bit word for the data yet ADC16@ returns with that same word split into two bytes. Here's my take on your original code.

FORGET ADC16@

$90    == @ADC --- adc 8-bit I2C address

: ADC16@ ( reg -- dat16 )           \ read contents from a TI-1115 register
   I2CSTART        \ wakeup call
   @ADC I2C!       \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   I2CSTART        \ not done yet
   @ADC 1+ I2C!    \ send address $48 plus read bit
   ackI2C@         \ get MSB of target register
   ackI2C@         \ get LSB
   SWAP B>W        \ combine bytes into a word
   I2CSTOP         \ that's all for now
;


: ADC16! ( dat16 reg -- )           \ get write n to TI-1115 register rp ( n rp --- n )
   I2CSTART        \ wakeup call
   @ADC I2C!       \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   W>B             \ Split word into high and low bytes ( bytel byteh )
   I2C!            \ write MSB to target register
   I2C!            \ write LSB
   I2CSTOP         \ that's all for now
;


$8BA3 CONSTANT ADcfg


: ADC16ss ( config -- data16 ) \ get Single-Shot reading from TI-1115
   ADcfg 1 ADC16!  \ config and trigger conversion - temp, hard coded configuration
   BEGIN          \ repeat
      1 ADC16@     \    config register, bit 15
      $8000 AND    \    returns HI indicating completion of conversion
   UNTIL          \ until
   0 ADC16@        \ read data register for conversion result
;

--- extend sign of 16-bit word into a long
: EXT16 ( sign16 -- sign32 ) DUP $8000 AND IF $1.0000 - THEN  \ convert 16 bit twos complement number to real decimal
;

[artkennedy]

Thanks. Did that.

you can go back EDIT POST / Go ADVANCED and change the title

[MJB]

My last two posts are not really replies to Re: MAX31855 SPI ADC for Thermocouples DRIVER

But to the ongoing Tachyon thread.

Oops!

you can go back EDIT POST / Go ADVANCED and change the title

[D.P]

My last two posts are not really replies to Re: MAX31855 SPI ADC for Thermocouples DRIVER

But to the ongoing Tachyon thread.

Oops!

Hi Art,

I saw your post in the other thread with Tracy responding with the spin objects he wrote for the chip (ADS1111).

Looking forward to see how you go about the "math" that Tracy provided.

I'm sure as soon as Peter gets some more Tachyon cycles we will see F32 as a loadable module, I plan to just use this in an empty cog as a full time floating point math engine
since I want to calculate saturation dew point temperatures and hence RH using standard saturation vapor point equations.

[artkennedy]

My last two posts are not really replies to Re: MAX31855 SPI ADC for Thermocouples DRIVER

But to the ongoing Tachyon thread.

Oops!

[artkennedy]

I changed 2s>R to allow designated bit lengths.
I imagine this has been done before but I didn't find it so I did it again. Good practice.

"2s>R" might not be the best name.
Should it be called something else?

FORGET ADC16@


: ADC16@           \ read contents from a TI-1115 register ( rp --- msb lsb ) rp = TI-1115 register pointer
   I2CSTART        \ wakeup call
   $90 I2C!        \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   I2CSTART        \ not done yet
   $91 I2C!        \ send address $48 plus read bit
   ackI2C@         \ get MSB of target register
   ackI2C@         \ get LSB
   I2CSTOP         \ that's all for now
;


: ADC16!           \ get write n to TI-1115 register rp ( n rp --- n )
   I2CSTART        \ wakeup call
   $90 I2C!        \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   DUP 8 SHR       \ get MSB
   I2C!            \ write to target register
   $FF AND I2C!    \ write LSB
   I2CSTOP         \ that's all for now
;


$8BA3 CONSTANT ADcfg


: ADC16cfg         \ ( 16b --- ) \ configure per 16bit input value
                   \    see table of values in C:\Users\Art\Documents\Tech\!Propeller\ADC Add On\ADC_Board.txt
   1 ADC16!        \ point to config register and write
;


: ADC16ss          \ get Single-Shot reading from TI-1115  ( 16b --- MSBrd LSBrd ) configuration --- result
   ADcfg ADC16cfg  \ config and trigger conversion - temp, hard coded configuration
   BEGIN           \ repeat
      1 ADC16@     \    config register, bit 15
      DROP $80 AND \    returns HI indicating completion of conversion
   UNTIL           \ until
   0 ADC16@        \ read data register for conversion result
   SWAP            \ pop MSB
   8 SHL +         \ shift MSB and combine with LSB
;


: 2s>R      \ ( n len --- n1 ) n = twos complement number, len = bit length, n1 = converted to signed decimal number
1- 2 SWAP ^ \ compute 2 ^ (bitlen - 1)
2DUP        \ copy for test
=> IF       \ if n greater it is negative
   2 * -    \    n - 2 ^ len
ELSE        \ else n is positive
   DROP     \    no change necessary
THEN        \ then
;

[artkennedy]

Hell-o Tachy World,

I've been away for a while taking care of non-code and chip kinds of things. Recently working real hard on learning to use my new AdaFruit TI-ADS1115 16 bit ADC breakout. Yep, I dumped the DMM idea. The points against started adding up too fast.

The TI-ADS1115 is my first foray into the I2C world. Thanks to Peter and Tachyon the lowest level stuff was not hard.

Here is the code I have done so far:

FORGET ADC16@


: ADC16@           \ read contents from a TI-1115 register ( rp --- msb lsb ) rp = TI-1115 register pointer
   I2CSTART        \ wakeup call
   $90 I2C!        \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   I2CSTART        \ not done yet
   $91 I2C!        \ send address $48 plus read bit
   ackI2C@         \ get MSB of target register
   ackI2C@         \ get LSB
   I2CSTOP         \ that's all for now
;


: ADC16!           \ get write n to TI-1115 register rp ( n rp --- n )
   I2CSTART        \ wakeup call
   $90 I2C!        \ send address $48 plus write bit
   I2C!            \ write rp to pointer register
   DUP 8 SHR       \ get MSB
   I2C!            \ write to target register
   $FF AND I2C!    \ write LSB
   I2CSTOP         \ that's all for now
;


$8BA3 CONSTANT ADcfg


: ADC16cfg         \ ( 16b --- ) \ configure per 16bit input value
                   \    see table of values in C:\Users\Art\Documents\Tech\!Propeller\ADC Add On\ADC_Board.txt
   1 ADC16!        \ point to config register and write
;


: ADC16ss          \ get Single-Shot reading from TI-1115  ( 16b --- MSBrd LSBrd ) configuration --- result
   ADcfg ADC16cfg  \ config and trigger conversion - temp, hard coded configuration
   BEGIN           \ repeat
      1 ADC16@     \    config register, bit 15
      DROP $80 AND \    returns HI indicating completion of conversion
   UNTIL           \ until
   0 ADC16@        \ read data register for conversion result
   SWAP            \ pop MSB
   8 SHL +         \ shift MSB and combine with LSB
;


: 2s>R DUP #32767 > IF #65536 - THEN  \ convert 16 bit twos complement number to real decimal
;

If anyone sees where it could be improved - have at it. If it is useful to anyone . . . enjoy.

I have also written a Excel sheet to assist in compiling the configuration value . . . which I have just attempted to attach and get an "Invalid File" error. Does the Forum not allow *.xlsx files? It sure is useful to me.

[MJB]

Thanks for the review, still learning.

me too - we can review each others code if you like

I have no SPI HW set up, so I can not test it here ATM

Updated:

TACHYON

FORGET MAX31855.fth  

pub MAX31855.fth  ." MAX31855 DRIVER - 140525-16:00 " ;
 \  update after mjb comments 

( MAX31855 ThermoCouple DRIVER )
[~

BYTE sbit             \ sign bit
#P5 |< == MCLK        \ clock mask    
#P3 |< == MCS         \ chip select mask
#P1 == MDO            \ data input pin

MCS OUTSET            \ initialize these pins
MCLK OUTSET
MDO |< INPUTS

pub maxtc@  ( -- 32bitsMSBFirst )    \ bit bang to read MAX31855
\ here the SPI words should help:
\ I propose the kernel embedded SPI here, since it seems sufficient.
\ for more complex SPI requirements, like bidirectional, the loadable RUNMOD modules can be used
\ like
{   \ Define COGREG constants for most SPI operations based on kernel code, usually not for RUNMODs
-5 CONSTANT @SPISCK
-2 CONSTANT @SPICE
-1 CONSTANT @SPICNT
}
32 @SPICNT COGREG!              \ set SPI to 32 bits at once
MCS  @SPICE  COGREG!          \ define CS mask
MCLK   @SPISCK  COGREG!     \ define SCK mask
-3 CONSTANT @SPIINP                     \  definition is missing in EXTEND ( I'll try to add it )
MDO |<  @SPIINP   COGREG!      \ define input mask 

{  let Tachyon do the work ...      from Tachyon.spin
' Receive data and shift into existing stack parameter
' If MOSI needs to be in a certain state then this should be set beforehand
' Clock will simply pulse from it's starting state - normally low
' Useage:  0 SPIRX     'read 32-bits as one long
' SPIRD ( data -- data<<8 )        ' 11.2us for 32 bits ==   2.8 MHz  ( sensor is specified up to 5 MHz )
}
{ your code ...
   MCLK OUTCLR     \ just following what worked on Arduino, no joy with SHRINP
  1 ms
  MCS OUTCLR
  1 ms
  0   \ data destination placeholder
  #32 FOR 
    MCLK OUTCLR
    1 ms
    1 SHL         \ bump it over
    MDO PIN@
    IF 1 OR THEN  \ set bit accordingly
    MCLK OUTSET
    1 ms
  NEXT
  MCLK OUTCLR
  MCS OUTSET
}
\ set defined start conditions
MCLK OUTCLR
MCS OUTCLR
0 SPIRDX    \ inputs 32 bits at once  -- done
\ not sure if those are needed
MCLK OUTCLR
MCS OUTSET
;

pub inttemp@  ( -- degreeC )
 maxtc@
  4 SHR               \ drop 4 lsb bits
  DUP
  $800 AND
  sbit C!             \ save sign bit
  $7FF AND            \ get 11 bits
  #625 * #10000 /     \ convert the temp
  sbit C@             \ get the sign bit, could use stack :-)
  ?NEGATE             \ negate if sign bit
;

pub tctemp@   ( -- degreeC )
  maxtc@
  #18 SHR       \ shift upper 14 bits right 
  DUP           \ two copies
  $2000 AND     \ get bit 14 the sign bit 
  sbit C!       \ save sign bit
  $1FFF AND     \ get other 13 bits
  #25 * #100 /  \ convert the temp
  sbit C@
  ?NEGATE       \ negate if sign bit
;

pub C>F  ( C -- F )  \ convert C degrees to F
  #40 + #9 * 5 / #40 - 
; 

pub .inttemp      \ display internal MAX31855 temp
  inttemp@
  DUP
  ." Cold Junc. Temp: " $240A .NUM ."  C  "  C>F $240A .NUM ."  F  " \ .NUM 4 digits, leading blanks base 10
;

pub .tctemp      \ display tc temp
  tctemp@ 
  DUP
  CR ." TC Temp: "  $240A .NUM ."  C  "  C>F $240A .NUM ."  F  "
;

pub .runtc       \ routine to display readings to console every 2 seconds until ESC key hit
  BEGIN
    2 seconds
    .tctemp  
    .inttemp 
  ESC? UNTIL
;

{ .runtc
TC Temp: 21 C  69 F  Cold Junc. Temp: 22 C 71 F
.
.
.
}
]~
END

p.s. I changed the title to s.th. meaningful
ALL:
unfortunately most writers just leave the previous post title, so the title says nothing about the new post itself - this is bad for searching later - so I'd like to encourage use of meaningful post titles !! thanks MJB

[D.P]

little comments

Thanks for the review, still learning.

Updated:

TACHYON

FORGET MAX31855.fth  

pub MAX31855.fth  ." MAX31855 DRIVER - 140525-16:00 " ;
 \  update after mjb comments 

( MAX31855 ThermoCouple DRIVER )
[~

BYTE sbit             \ sign bit
#P5 |< == MCLK        \ clock mask    
#P3 |< == MCS         \ chip select mask
#P1 == MDO            \ data input pin

MCS OUTSET            \ initialize these pins
MCLK OUTSET
MDO |< INPUTS

pub maxtc@  ( -- 32bitsMSBFirst )    \ bit bang to read MAX31855
  MCLK OUTCLR     \ just following what worked on Arduino, no joy with SHRINP
  1 ms
  MCS OUTCLR
  1 ms
  0   \ data destination placeholder
  #32 FOR 
    MCLK OUTCLR
    1 ms
    1 SHL         \ bump it over
    MDO PIN@
    IF 1 OR THEN  \ set bit accordingly
    MCLK OUTSET
    1 ms
  NEXT
  MCLK OUTCLR
  MCS OUTSET
;

pub inttemp@  ( -- degreeC )
 maxtc@
  4 SHR               \ drop 4 lsb bits
  DUP
  $800 AND
  sbit C!             \ save sign bit
  $7FF AND            \ get 11 bits
  #625 * #10000 /     \ convert the temp
  sbit C@             \ get the sign bit, could use stack :-)
  ?NEGATE             \ negate if sign bit
;

pub tctemp@   ( -- degreeC )
  maxtc@
  #18 SHR       \ shift upper 14 bits right 
  DUP           \ two copies
  $2000 AND     \ get bit 14 the sign bit 
  sbit C!       \ save sign bit
  $1FFF AND     \ get other 13 bits
  #25 * #100 /  \ convert the temp
  sbit C@
  ?NEGATE       \ negate if sign bit
;

pub C>F  ( C -- F )  \ convert C degrees to F
  #40 + #9 * 5 / #40 - 
; 

pub .inttemp      \ display internal MAX31855 temp
  inttemp@
  DUP
  ." Cold Junc. Temp: " $240A .NUM ."  C  "  C>F $240A .NUM ."  F  " \ .NUM 4 digits, leading blanks base 10
;

pub .tctemp      \ display tc temp
  tctemp@ 
  DUP
  CR ." TC Temp: "  $240A .NUM ."  C  "  C>F $240A .NUM ."  F  "
;

pub .runtc       \ routine to display readings to console every 2 seconds until ESC key hit
  BEGIN
    2 seconds
    .tctemp  
    .inttemp 
  ESC? UNTIL
;

{ .runtc
TC Temp: 21 C  69 F  Cold Junc. Temp: 22 C 71 F
.
.
.
}
]~
END

[MJB]

little comments

Here's a basic driver for the AdaFruit MAX31855 breakout Thermocouple board.

Peter you can by all means cut and paste the code to place it in the Tachyon dropbox as you see fit.

TACHYON

FORGET MAX31855.fth  

pub MAX31855.fth  ." MAX31855 DRIVER - 140525-15:00 " ;

( MAX31855 ThermoCouple DRIVER )
[~

BYTE sbit             \ sign bit
#P5 |< == MCLK        \ clock mask    
#P3 |< == MCS         \ chip select mask
#P1 == MDO            \ data input pin

MCS OUTSET            \ initialize these pins
MCLK OUTSET
MDO |< INPUTS

pub maxtc@  ( -- 32bitsMSBFirst )    \ bit bang to read MAX31855
  MCLK OUTCLR     \ just following what worked on Arduino, no joy with SHRINP
  1 ms
  MCS OUTCLR
  1 ms
  0   \ data destination placeholder
  #32 FOR 
    MCLK OUTCLR
    1 ms
    1 SHL         \ bump it over
    MDO PIN@
    IF 1 OR THEN  \ set bit accordingly
    MCLK OUTSET
    1 ms
  NEXT
  MCLK OUTCLR
  MCS OUTSET
;

pub inttemp@  ( -- degreeC )
 maxtc@
  4 SHR               \ drop 4 lsb bits
  DUP
  $800 AND
  sbit C!             \ save sign bit
  $7FF AND            \ get 11 bits
  #625 * #10000 /     \ convert the temp
  sbit C@             \ get the sign bit, could use stack :-)
\  IF -1 * THEN        \ convert for sign bit
   ?NEGATE   \ is faster
;

pub tctemp@   ( -- degreeC )
  maxtc@
  #18 SHR       \ shift upper 14 bits right 
  DUP           \ two copies
  $2000 AND     \ get bit 14 the sign bit 
  sbit C!       \ save sign bit
  $1FFF AND     \ get other 13 bits
  #25 * #100 /  \ convert the temp
  sbit C@
\  IF -1 * THEN  \ convert for sign bit
   ?NEGATE   \ is faster
;


pub .inttemp      \ display internal MAX31855 temp
  inttemp@
  DUP
  ." Cold Junc. Temp: " . ."  C " #40 + #9 * 5 / #40 - . ."  F" CR
;

pub .tctemp      \ display tc temp
  tctemp@ 
  DUP
  CR ." TC Temp: " . ."  C  "  #40 + #9 * 5 / #40 - . ."  F  "
\  : C>F   #40 + #9 * 5 / #40 - ; 
;

pub .runtc       \ routine to display readings to console every 2 seconds until ESC key hit
  #10 >RADIX   \ instead of switching radix you can use   the .NUM formatting see EXTEND 
  BEGIN
\    #1000 ms
    .tctemp  
    .inttemp \ #1000 ms
    2 seconds
  ESC? UNTIL
  RADIX>
;

{ .runtc
TC Temp: 21 C  69 F  Cold Junc. Temp: 22 C 71 F
.
.
.
}
]~
END

[D.P]

Here's a basic driver for the AdaFruit MAX31855 breakout Thermocouple board.

Peter you can by all means cut and paste the code to place it in the Tachyon dropbox as you see fit.

TACHYON

FORGET MAX31855.fth  

pub MAX31855.fth  ." MAX31855 DRIVER - 140525-15:00 " ;

( MAX31855 ThermoCouple DRIVER )
[~

BYTE sbit             \ sign bit
#P5 |< == MCLK        \ clock mask	
#P3 |< == MCS         \ chip select mask
#P1 == MDO            \ data input pin

MCS OUTSET            \ initialize these pins
MCLK OUTSET
MDO |< INPUTS

pub maxtc@  ( -- 32bitsMSBFirst )    \ bit bang to read MAX31855
  MCLK OUTCLR     \ just following what worked on Arduino, no joy with SHRINP
  1 ms
  MCS OUTCLR
  1 ms
  0   \ data destination placeholder
  #32 FOR 
    MCLK OUTCLR
    1 ms
    1 SHL         \ bump it over
    MDO PIN@
    IF 1 OR THEN  \ set bit accordingly
    MCLK OUTSET
    1 ms
  NEXT
  MCLK OUTCLR
  MCS OUTSET
;

pub inttemp@  ( -- degreeC )
 maxtc@
  4 SHR               \ drop 4 lsb bits
  DUP
  $800 AND
  sbit C!             \ save sign bit
  $7FF AND            \ get 11 bits
  #625 * #10000 /     \ convert the temp
  sbit C@             \ get the sign bit, could use stack 
  IF -1 * THEN        \ convert for sign bit
;

pub tctemp@   ( -- degreeC )
  maxtc@
  #18 SHR       \ shift upper 14 bits right 
  DUP           \ two copies
  $2000 AND     \ get bit 14 the sign bit 
  sbit C!       \ save sign bit
  $1FFF AND     \ get other 13 bits
  #25 * #100 /  \ convert the temp
  sbit C@
  IF -1 * THEN  \ convert for sign bit
;


pub .inttemp      \ display internal MAX31855 temp
  inttemp@
  DUP
  ." Cold Junc. Temp: " . ."  C " #40 + #9 * 5 / #40 - . ."  F" CR
;

pub .tctemp      \ display tc temp
  tctemp@ 
  DUP
  CR ." TC Temp: " . ."  C  "  #40 + #9 * 5 / #40 - . ."  F  "
;

pub .runtc       \ routine to display readings to console every 2 seconds until ESC key hit
  #10 >RADIX
  BEGIN
    #1000 ms
    .tctemp  
    .inttemp #1000 ms
  ESC? UNTIL
  RADIX>
;

{ .runtc
TC Temp: 21 C  69 F  Cold Junc. Temp: 22 C 71 F
.
.
.
}
]~
END

[MJB]

Hi Peter,

I have a basic version of the 1-Wire ROM search procedure running.
And while cleaning up I came across a point, that I come across every now and then.
It is the missing namespaces in Tachyon, to make sure that I don't accidentally overwrite
an existing word.
Besides the effort of a technical solution, there would be a very simple
organisational solution.
Like prefixing all the words of the package with a code like '1W.'
then it would be clear for everybody, and no name conflicts could occure.
It would cost a few chars more in name space dictionary, but since most words already contain 1W in the name
it would be only the '.'.

so 1W.RESET instead of 1WRESET ...
what do you think?
Markus

[Peter Jakacki]

Mike:

Since txd & rxd are constants, why not do the following: e.g., #6 TO txd #7 TO rxd BACKUP, then reboot.

TO is defined as : TO ' 2+ ! ;

NickL

But this will be the result:
txd --> txd <-- NOT FOUND 
rxd --> rxd <-- NOT FOUND 
0 20 DUMP 
0000_0000:   D0 1D B9 04  6E A7 10 00   AC 7E B4 7E  80 7E B8 7E   ....n....~.~.~.~
0000_0010:   00 00 00 00  70 7E 00 00   3F 18 61 01  00 00 00 00   ....p~..?.a..... ok
#6 TO rxd  ok
0 20 DUMP 
0000_0000:   06 00 00 00  6E A7 10 00   AC 7E B4 7E  80 7E B8 7E   ....n....~.~.~.~
0000_0010:   00 00 00 00  70 7E 00 00   3F 18 61 01  00 00 00 00   ....p~..?.a..... ok
CLKFREQ . 6 ok

So since txd and rxd do not exist at the Forth level you will find that TO happily obliges but since TF always leaves a zero for any failed tick operation you end up saying "#6 0 1+ !" (it's a 1+, not 2+) and the poor clkfreq word gets clobbered.

[D.P]

Mike:

Since txd & rxd are constants, why not do the following: e.g., #6 TO txd #7 TO rxd BACKUP, then reboot.

TO is defined as : TO ' 2+ ! ;

NickL

Right! Forgot about this feature of Tachyon "contants", thanks.

[nglordi]

Mike:

Since txd & rxd are constants, why not do the following: e.g., #6 TO txd #7 TO rxd BACKUP, then reboot.

TO is defined as : TO ' 2+ ! ;

NickL

[max72]

Mike, I had issues connecting with my router when using the wrong crypt. The Wifly supports "WPA-PSK (TKIP), and WPA2-PSK
but not WPA2-TKIP"
My router's default settings were WPA2-TKIP, so I had to change to WPA2-PSK. After that everything worked.
Maybe there is a similar issue..
Massimo

[Peter Jakacki]

The WiFly module is an experiment. Using USB serial for the setup and testing is much easier than trying to download EXTEND and the other modules via WiFi. I may try that otherwise.

@Peter,
There's one place in TERMINAL's initialization where you convert txd to a mask and do an OUTSET. All other references to the serial I/O pins use txmask and rxpin for txd and rxd respectively. It would be easy to just fetch txmask to do the OUTSET, then only txmask and rxpin would need to be patched in the EEPROM to get them to be used on a reboot. The high speed serial driver is already launched and would have to be relaunched with the updated rxpin and that's too much work for something that only needs to change on a reboot.

The OUTSET is not required anymore but neither does it do any harm either as once I was skint for a cog long and I left out setting the pin as an output. I will get onto updating the source to allow boot-time console assignment. In the meantime, you can cheat

[Mike Green]

Massimo,
I have not been able to connect via Telnet using my home WiFi network which seems to work well otherwise. There may be something about the default router configuration that's interfering. If I configure the WiFly module as a soft AP, then it works, but I have to change networks on my desktop Mac to get to the WiFly AP and that is awkward because of other stuff I'm doing. I'll figure something out.

[max72]

I loaded the modules using teraterm and wifly and the process I experienced is equivalent to the "wired" one, so I'm probably missing something.
The eeprom patch looks intriguing...
Massimo

[Mike Green]

The WiFly module is an experiment. Using USB serial for the setup and testing is much easier than trying to download EXTEND and the other modules via WiFi. I may try that otherwise.

@Peter,
There's one place in TERMINAL's initialization where you convert txd to a mask and do an OUTSET. All other references to the serial I/O pins use txmask and rxpin for txd and rxd respectively. It would be easy to just fetch txmask to do the OUTSET, then only txmask and rxpin would need to be patched in the EEPROM to get them to be used on a reboot. The high speed serial driver is already launched and would have to be relaunched with the updated rxpin and that's too much work for something that only needs to change on a reboot.

[max72]

Mike,
Why you prefer to load the modules via USB and not directly via the Wifly?
Massimo

[D.P]

Don't forget to add a header file after extend, a bit like QS.fth so that any peripherals are automatically configured although you can still force them using the SDPINS at runtime.
.
.
.

A cheat would be to patch the EEPROM directly if you know the address of the mask which in this version is $7E40 so that "mypin MASK $7E40 E!" would patch the EEPROM. The txd mask is at $7B94. If I put these two masks in fixed locations then it should be a breeze to patch them so that you change the default.
.
.
.

Diabolical, I like how you think/work Peter! Get it working, then optimize.

[Peter Jakacki]

I would like to load in EXTEND, SDCARD, and MULTIFAT via the USB programming port, then permanently switch to another pair of I/O pins connected to a WiFly module so that Tachyon comes out of reset talking to the WiFly module.

Don't forget to add a header file after extend, a bit like QS.fth so that any peripherals are automatically configured although you can still force them using the SDPINS at runtime.

I don't seem to have a mechanism for redirecting the actual serial receive cog although the serial output is very easily redirected by setting the transmit mask in COGREG 6 ( mypin MASK 6 COGREG!). It would seem that if you did change the serial receive cog's rxpin after compile that you might lose the ability to talk to it again from USB. If that's not a problem then I will look at what can be done.

Of course there is redirection too but if you are intending to wipe and reload code from the WiFly module then redirection is no good.

A cheat would be to patch the EEPROM directly if you know the address of the mask which in this version is $7E40 so that "mypin MASK $7E40 E!" would patch the EEPROM. The txd mask is at $7B94. If I put these two masks in fixed locations then it should be a breeze to patch them so that you change the default.

EDIT: The other approach is to simply tie the Prop's TXD to both the USB and WiFly module and then connect the TXDs from the USB and WiFly through diodes to the P31 with a pullup as well.

[Mike Green]

I would like to load in EXTEND, SDCARD, and MULTIFAT via the USB programming port, then permanently switch to another pair of I/O pins connected to a WiFly module so that Tachyon comes out of reset talking to the WiFly module.

[max72]

Mike,
in the past I changed the pin assignement in the source too, but if you check the getting started guide there is a "REDIRECTING OUTPUT", so I'm rather confident you can do it on the fly.

Massimo

[D.P]

Peter,
It's probably a simple question answered before, but how do you switch the console to another pair of I/O pins?

Hi Mike, nice to see you around here.

Don't know about switching the console post boot but in the Tachyon source you will find this block:

' Standard Port assignments
scl                   = 28
sda                   = 29
txd                   = 30
rxd                   = 31

Seems very straight forward to change the assignments here, compile/load the kernel again onto the target and add in Extend.fth and other goodies as required.

Have fun

https://docs.google.com/document/d/1...3ZDgPKEiIc/pub

[Mike Green]

Peter,
It's probably a simple question answered before, but how do you switch the console to another pair of I/O pins?

[D.P]

I never got around to finishing the code for that, I had a problem with how they wrote the flowchart I think, such a convoluted nightmare as if it were translated from a mix of Fortran and Cobol!! So I was going to redo the algorithm until it flowed more like a world of goo and fitted in one line, well close to that anyway.

I just found some C code for this, it is only 430 lines long, I had thought I was doing something wrong when my Forth code grew to 64 lines. Maybe there's hope.

Wow you are right about being convoluted. Found these examples/code to be not so ugly except for the second link, one wire advance search. Funny they make a chip as a 1-wire master that can be interfaced via serial (understandable) but I2C too? Nothing like layering complexity.

http://www.maximintegrated.com/app-n...ex.mvp/id/126]
http://www.maximintegrated.com/app-n...dex.mvp/id/187

[Peter Jakacki]

Hi Peter,
I was thinking of extending 1wire to multiple sensors, found a forth implementation for SEARCHROM
and then discovered, that at the bottom of your file is some commented out code for it.

I just tried to run 1WIRE version 121025 with single DS1820+ and works fine.

The searchrom code did nur work.
1WBIT@ and 1WBIT! are not defined.
I used 1WBITRD and !WBITWR instead ... but SEARCHROM just prints "Search ROM" repeatedy
and never stops ...

is this version 121025 the latest out there?
Is SEARCHROM still untested? - looks like.
or is still some code missing?

thanks, MJB

p.s. Brian Riley - did you try more than 1 sensor?

I never got around to finishing the code for that, I had a problem with how they wrote the flowchart I think, such a convoluted nightmare as if it were translated from a mix of Fortran and Cobol!! So I was going to redo the algorithm until it flowed more like a world of goo and fitted in one line, well close to that anyway.

I just found some C code for this, it is only 430 lines long, I had thought I was doing something wrong when my Forth code grew to 64 lines. Maybe there's hope.

[MJB]

Hi Peter,
I was thinking of extending 1wire to multiple sensors, found a forth implementation for SEARCHROM
and then discovered, that at the bottom of your file is some commented out code for it.

I just tried to run 1WIRE version 121025 with single DS1820+ and works fine.

The searchrom code did nur work.
1WBIT@ and 1WBIT! are not defined.
I used 1WBITRD and !WBITWR instead ... but SEARCHROM just prints "Search ROM" repeatedy
and never stops ...

is this version 121025 the latest out there?
Is SEARCHROM still untested? - looks like.
or is still some code missing?

thanks, MJB

p.s. Brian Riley - did you try more than 1 sensor?

[max72]

That would be a great feature.
I'm a very lame programmer, so using existing code is mandatory.
I also miss a multiple serial (4 port serial style). Obviously the proposed approach would open all the obex. If the users will be able to adapt the objects in the obex and share them of will be a real boost.
Thanks for your efforts!
Massimo

[Peter Jakacki]

@Peter

If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?

All of this under control of your Forth language.

regards,
rich

It is my intention to have the facility to load a PASM module by name either from EEPROM or SD card into a specified cog, Quite possibly it would take this format when invoked:
" VGATEXT.COG" 5 LOADCOG
or something similar. I have played with a method of loading the EEPROM or SD in the first place by pasting a copy of the PASM listing which I know BST can do. The information is fairly easy to extract as lines of actual code are always in this format:

0018(0000) F0 97 BF 0A | getCommand              rdlong  cmdPtr, par wz          ' wait for command

We only really need the cog address (0000) and the long F0 97 BE 0A etc and the name of the module can be extracted from the header:
Object Address : 0010 : Object Name : F32PASM
So this is one method of loading the files as source code into TF where it can generate a binary file that can be loaded into a cog at runtime.

I may have some time this month to actually test it out fully and then it would be a matter of converting code from the OBEX by stripping away all the Spin fluff and insert the few changes for hub access. This means that each cog needs to have it's own hub area for parameters which at present is already in place but there are only 8 bytes (tasks) which will need to be expanded to around 32. Perhaps this could even be a simple pointer in a fixed location that points to a parameter block so that TF could define the area and set the pointer when it loads the cog.

I will post more about how this works as I nut it out, and of course I will try to make referencing it as smooth as possible.

EDIT: just imagine, a pick and choose OBEX library loadable at runtime, all target resident and it only needs a 64k or more EEPROM instead.

[D.P]

@Peter

If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?

All of this under control of your Forth language.

regards,
rich

Peter has mentioned he is working on "loadable modules" so that we can use say F32 pasm as a loadable module for full float support. The idea I believe is that we (tachyon users) will be able to create our own modules to use this way. Hello OBEX!!

[richaj45]

@Peter

If i have a driver that fit in a cog and was written in pasm, could i load the image for that cog in the upper region of the 64kB eeprom and then with tachyon commands load it into a unused cog and start interfacing to it with a tachyon program?

All of this under control of your Forth language.

regards,
rich

[artkennedy]

Really nice for you to share so much of your time with Jack and the results with us, thanks Peter.

Absolutely!

[D.P]

I've had a 14 year old boy, a son of a friend wanting to spend some time during his school holidays learning about what I do. He is a very bright boy and even the "gifted" programs at his well equipped school have been too dumbed down so I thought it practical if we did a project from scratch together so that he could get a taste for the various aspects of it. Earlier in the year I had him over for a half-day and gave him a quick intro and a run-through with stepper motor control using when of my Prop boards hooked into those cheap Ebay baby steppers and "Forth" I gave him that system so that he could experiment further.

Anyway, I have been meaning to do an RFID access control for a dumb electric gate which just uses the normal "clickers" and to also add automatic timers so that the gate would definitely be closed by late at night in case someone forgot. So after running through some design decisions I had him pasting a board, placing parts (explaining what each part did), cooking it up, soldering parts etc as well as testing various sections then bringing a board to life with a TF kernel.

Bit by bit we tested out the hardware, the RFID, the EEPROM file system, the reporting functions etc. Now he's got a really good taste of it even though it took me about six times longer to do the project! Plus he can even interrogate the unit at anytime with his phone using Blueterm. I have now tasked him in his spare time with writing a smartphone app using Bluetooth serial.

For anyone who is interested in RFID or even just control systems written in TF then this source code document may be useful.

Really nice for you to share so much of your time with Jack and the results with us, thanks Peter.

[Peter Jakacki]

I've had a 14 year old boy, a son of a friend wanting to spend some time during his school holidays learning about what I do. He is a very bright boy and even the "gifted" programs at his well equipped school have been too dumbed down so I thought it practical if we did a project from scratch together so that he could get a taste for the various aspects of it. Earlier in the year I had him over for a half-day and gave him a quick intro and a run-through with stepper motor control using when of my Prop boards hooked into those cheap Ebay baby steppers and "Forth" I gave him that system so that he could experiment further.

Anyway, I have been meaning to do an RFID access control for a dumb electric gate which just uses the normal "clickers" and to also add automatic timers so that the gate would definitely be closed by late at night in case someone forgot. So after running through some design decisions I had him pasting a board, placing parts (explaining what each part did), cooking it up, soldering parts etc as well as testing various sections then bringing a board to life with a TF kernel.

Bit by bit we tested out the hardware, the RFID, the EEPROM file system, the reporting functions etc. Now he's got a really good taste of it even though it took me about six times longer to do the project! Plus he can even interrogate the unit at anytime with his phone using Blueterm. I have now tasked him in his spare time with writing a smartphone app using Bluetooth serial.

For anyone who is interested in RFID or even just control systems written in TF then this source code document may be useful.

[Peter Jakacki]

Back after a time out for taxes and cortex rest.

Still trying to get that DMM reading into Tachyon

With an automated input from the DMM in the format: "DC 12.34 uA<CR>" the forth input function loses the dp position because the value is accepted as a number and DPL must be used on strings. Is there a way around this?

I was wondering how you went but the dp position is available at the time it encounters the units such as uA etc. I can give you code that works but if you just want a hand then post your code so we can tell you where the problem is.

[artkennedy]

Back after a time out for taxes and cortex rest.

Still trying to get that DMM reading into Tachyon

With an automated input from the DMM in the format: "DC 12.34 uA<CR>" the forth input function loses the dp position because the value is accepted as a number and DPL must be used on strings. Is there a way around this?

[Peter Jakacki]

Some time ago I started playing with handling infix notation in Forth, at least in the text interpretive stage. Here is a simple demonstration of this but it looks like I should also be able to compile this as well since the operations are stacked and execute at the end of each statement, in fact they are compiled prior to execution anyway.

LONG pbj ok
ok
PRINT pbj ok
0
ok
pbj := 1234 ok
PRINT pbj ok
1,234
ok
pbj := pbj @ * 100 ok
PRINT pbj ok
123,400
ok
PRINT 15 + 23 * 10 - 2 ok
199
PRINT 15 + DUP ok
30
PRINT " THIS IS A STRING" ok
THIS IS A STRING

If we always expect a space or more between all symbols then I think it's possible to have Forth appear as Basic, maybe even PBASIC (but a lot lot faster)
BTW, I'm not intending to write a Basic in Forth, when I look at some of the PBASIC source code rather than follow GOTO I just shudder but maybe someone might be keen.

[D.P]

The PBOE AD7993 is comming alive in Tachyon. I still question the 2 byte read ack/nak sequencing for this chip.

Continuing Peter's intial code here's a simple Mode 2 A2D read word , CH@

pub AD! ( byte reg -- ) I2CSTART $42 I2C! I2C! I2C! I2CSTOP ;
pub AD@ ( reg -- byte ) I2CSTART $42 I2C! I2C! I2CSTART $43 I2C! 0 I2C@ ;
pub AD2@ ( reg -- byte byte ) AD@ 1 I2C@ ;    \ 2 byte read
pub CH@  ( channel -- value )                  \ use 1,2,3 or 4 to read the appropriate A2D channel
  3 + 1 SWAP SHL                           \ create reg/mask for AD@       
  AD2@                                    \ read two bytes of data  
  SWAP 8 SHL OR  $0FFF AND 2 SHR           \ format the results to get the 10 bits we want
  CR .                                         \ let's see it
;

[Peter Jakacki]

@Peter:

A little of topic but can you tell me why you chose to put Tachyon Forth on the Prop and not a conventional micro-controller, like a PIC or AVR?

Just curious.

regards,
rich

It's more of a case of using the Prop with Spin and PASM and wanting faster and more compact code as well as interactive development. Before coming to the Prop I had previously used the ARM chips in some designs and I had written a bytecode Forth for that which enabled to develop very compact and fast applications and in fact my entry to the Circuit Cellar ARM Design contest was based around this Forth and generating bit-banged VGA (I still get enquiries about this).

So initially I was quite happy to use Spin and borrow from the OBEX as well and I couldn't quite see how I might write a Forth for this Chip, certainly not in the same manner as I had done with the ARM chip. After I started using BST instead of the Spin tool it was possible to view the listing and make adjustments to the code to make it fit where I wanted it to go. Also, rethinking about how Forth bytecode itself (not the PASM) could be coded within the limits of the Spin tool syntax was another hurdle that was overcome by reducing all bytecode references to "bytes" that directly addressed the first 256 longs of the VM cog.

So to answer your questions I never considered ever using PICs or AVRs for running Forth as these architectures are normally 8-bit and too limited whereas the 32-bit architectures were ideal for Forth. PICs and AVRs I only used in very low-end applications, usually as a peripheral and at this level resources are limited but assembler is more than adequate.

[richaj45]

@Peter:

A little of topic but can you tell me why you chose to put Tachyon Forth on the Prop and not a conventional micro-controller, like a PIC or AVR?

Just curious.

regards,
rich

[D.P]

I just had a quick look at this chip but it looks very straightforward to configure and read. Have you tried to at all?
The general form of writing to this would be:
pub AD! ( byte reg -- ) I2CSTART $40 I2C! I2C! I2C! I2CSTOP ;
pub AD@ ( reg -- byte ) I2CSTART $40 I2C! I2C! I2CSTART $41 I2C! 1 I2C@ ;

I was confused from the data sheet: Because it is the register to which the first data byte of every write operation is written automatically, the address pointer register does not have an address and does not reqire an address.

I have frobbed at the chip a bit, I will continue to do so.

[Peter Jakacki]

Looking for AD7993 A2D IC (PBOE) Tachyon words?

I just had a quick look at this chip but it looks very straightforward to configure and read. Have you tried to at all?
The general form of writing to this would be:
pub AD! ( byte reg -- ) I2CSTART $40 I2C! I2C! I2C! I2CSTOP ;
pub AD@ ( reg -- byte ) I2CSTART $40 I2C! I2C! I2CSTART $41 I2C! 1 I2C@ ;

[D.P]

Looking for AD7993 A2D IC (PBOE) Tachyon words?

[D.P]

EDIT: Dropbox files are up-to-date and I have created a FRUNS folder where these files can be copied to the SD card and are useful when you have a fully loaded system. It feels a bit like running batch files from floppy

There's been quite a few improvements on many fronts and some not so obvious. The network servers have been fixed up as there was a problem with the disconnection procedure but I believe that is sorted out now, it seems to run smoothly from remote sites. I have even been using ftp from the browser just as you enter ftp://tachyonforth.com it will come up with a file listing etc. Mind you I still intend to leave a Prop server running permanently although at present this system is under tests and constantly being bombarded by bing bots.

There are so many things to list but one of the things that I have been looking at doing is extending TF code into the SD file system. Well it turns out that there is a very very simple mechanism where if I type in a word that's unknown that it fails the dictionary search, the number conversion and finally bombs to an exception vector, which if set can find and open it as a file name and input it into TF. This may mean it is a simple script or it compiles a definition and runs it. For instance when I create a small build of EXTEND.fth there are some words that have been left out that I would like to use sometimes but I can't afford to have them hogging the little hub memory that remains.

So using a simple definition FRUN and tying to the exception vector then typing the unknown TASKS word automatically does what I need it to do:

pub FRUN word FOPEN$ IF FINPUT THEN ;  ok
  ok
' FRUN unum W!  ok
  ok
TASKS  ok
[~       ok
.TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: RS232.TASK                      51F4 01 00 00 00 00 00 
0007: TIMERTASK                       24F4 01 00 00 00 00 00  ok
FORGET .TASKS  ok

and so with MAP which is only ever used from the console rarely:

MAP  ok
[~       ok
.MAP  
REGISTERS x16
0024: 01 04 .. .. 01 .. .. .. .. .. 01 01 02 04 01 .. 
VECTORS x64
0124: 0F 11 14 10 12 18 11 12 14 13 0D 14 10 14 18 16 
0524: 14 17 16 18 15 18 0F 18 18 1B 1C 1F 01 .. .. .. 
KERNEL CODE x256
0928: 64 5F 87 89 60 58 61 6F 70 69 6F 60 65 71 63 40 
CODE x256
1881: 68 57 4A 5E 78 66 65 5F 64 6B 74 77 58 63 6D 37 
2881: 86 2E 51 82 7C 7E 29 55 40 63 44 67 5B 5D 69 65 
3881: 5A 66 86 66 5E 52 60 5D 6F 61 69 67 5B 5F 5F 6D 
4881: 65 5D 75 78 66 77 6B 7C 77 50 87 66 5A 2F 62 64 
SPARE @5567: for 154
DICTIONARY x256
5601: 62 61 61 5D 5A 59 55 53 5C 55 6B 62 62 64 62 5E 
6601: 5F 5C 57 54 48 43 44 4B 52 59 52 55 70 59 14 13 
SPARE @7423: for 221
BUFFERS x64
7500: 0D 06 .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7900: 14 11 12 12 10 0F 14 0E 14 07 .. .. .. .. .. .. 
RX BUFFER x64
7D00: .. 15 23 1D 1E 04 1E .. 
HUB STACK x16
7F60: .. 02 01 .. .. .. .. .. .. .. 
 ok
FORGET (MAP)  ok

I will no doubt make this more general and may even allow precompiled code to run from the file system. There are a lot of diagnostics and "shell" commands that are well suited to this approach which will allow me to cram even more functionality into TF that goes beyond 32K.

EDIT: If I type .MAP which ends up searching the dictionary, number processing, file searching, loading, compiling, running (including scanning 32K hub RAM), then forgetting the functions just compiled, the whole process takes less than a second.
EDIT: What this automatic file search mechanism allows is that I can load code simply by typing the modules name, I no longer need to specifically type FLOAD <name>, now I just type <name>.

Very nice indeed, this will allow the SMALL build of EXTEND to get SMALL-ER. Lots of user code could be run in this fashion as well! Now TACHYON can pack around 2gigs worth of utilities/examples, erh that ought to be enough? Time for me to write a few TACHYON "shell" scripts, thanks Peter

[Peter Jakacki]

EDIT: Dropbox files are up-to-date and I have created a FRUNS folder where these files can be copied to the SD card and are useful when you have a fully loaded system. It feels a bit like running batch files from floppy

There's been quite a few improvements on many fronts and some not so obvious. The network servers have been fixed up as there was a problem with the disconnection procedure but I believe that is sorted out now, it seems to run smoothly from remote sites. I have even been using ftp from the browser just as you enter ftp://tachyonforth.com it will come up with a file listing etc. Mind you I still intend to leave a Prop server running permanently although at present this system is under tests and constantly being bombarded by bing bots.

There are so many things to list but one of the things that I have been looking at doing is extending TF code into the SD file system. Well it turns out that there is a very very simple mechanism where if I type in a word that's unknown that it fails the dictionary search, the number conversion and finally bombs to an exception vector, which if set can find and open it as a file name and input it into TF. This may mean it is a simple script or it compiles a definition and runs it. For instance when I create a small build of EXTEND.fth there are some words that have been left out that I would like to use sometimes but I can't afford to have them hogging the little hub memory that remains.

So using a simple definition FRUN and tying to the exception vector then typing the unknown TASKS word automatically does what I need it to do:

pub FRUN word FOPEN$ IF FINPUT THEN ;  ok
  ok
' FRUN unum W!  ok
  ok
TASKS  ok
[~       ok
.TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: RS232.TASK                      51F4 01 00 00 00 00 00 
0007: TIMERTASK                       24F4 01 00 00 00 00 00  ok
FORGET .TASKS  ok

and so with MAP which is only ever used from the console rarely:

MAP  ok
[~       ok
.MAP  
REGISTERS x16
0024: 01 04 .. .. 01 .. .. .. .. .. 01 01 02 04 01 .. 
VECTORS x64
0124: 0F 11 14 10 12 18 11 12 14 13 0D 14 10 14 18 16 
0524: 14 17 16 18 15 18 0F 18 18 1B 1C 1F 01 .. .. .. 
KERNEL CODE x256
0928: 64 5F 87 89 60 58 61 6F 70 69 6F 60 65 71 63 40 
CODE x256
1881: 68 57 4A 5E 78 66 65 5F 64 6B 74 77 58 63 6D 37 
2881: 86 2E 51 82 7C 7E 29 55 40 63 44 67 5B 5D 69 65 
3881: 5A 66 86 66 5E 52 60 5D 6F 61 69 67 5B 5F 5F 6D 
4881: 65 5D 75 78 66 77 6B 7C 77 50 87 66 5A 2F 62 64 
SPARE @5567: for 154
DICTIONARY x256
5601: 62 61 61 5D 5A 59 55 53 5C 55 6B 62 62 64 62 5E 
6601: 5F 5C 57 54 48 43 44 4B 52 59 52 55 70 59 14 13 
SPARE @7423: for 221
BUFFERS x64
7500: 0D 06 .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7900: 14 11 12 12 10 0F 14 0E 14 07 .. .. .. .. .. .. 
RX BUFFER x64
7D00: .. 15 23 1D 1E 04 1E .. 
HUB STACK x16
7F60: .. 02 01 .. .. .. .. .. .. .. 
 ok
FORGET (MAP)  ok

I will no doubt make this more general and may even allow precompiled code to run from the file system. There are a lot of diagnostics and "shell" commands that are well suited to this approach which will allow me to cram even more functionality into TF that goes beyond 32K.

EDIT: If I type .MAP which ends up searching the dictionary, number processing, file searching, loading, compiling, running (including scanning 32K hub RAM), then forgetting the functions just compiled, the whole process takes less than a second.
EDIT: What this automatic file search mechanism allows is that I can load code simply by typing the modules name, I no longer need to specifically type FLOAD <name>, now I just type <name>.

[Chameleon]

Unless I had a ultra-fast dictionary search method the number preprocessor does certainly speed up compilation speeds otherwise all numbers suffer from an exhaustive dictionary search first. Although I have fairly lax rules regarding number format I think I would like at least one decimal digit or a leading zero to make it acceptable as a number, so $A would not be a number but $0A would.

Kind of what I guessed-creating a big problem to fix an otherwise small one, creating a notable performance sag while trying to fix a niche problem.

Therefore $GPGGA etc will not be accepted as numbers and so a match in the dictionary would be found. Yes, it is possible to just strip the $ from the sentence but I'm not altogether happy with $GPGGA being processed as a number because it doesn't look anything like one. Maybe I might even only allow symbols mixed in # type decimal numbers as come to think of it I never mix symbols with hex numbers.

I like the ability to use #PIN8, and am pretty sure we have a notable number of projects among the forum that would be affected by changing decimal processing. This may be tunnel vision on my (our) part, but I can see using the alpha prefixes in decimals (like #PIN8) massively more useful and common than in HEX, if it is used at all in HEX Anyone please chime in if you do this with HEX numbers. Pushing my limits of logic, I could see annotating a group of IOs like Global Pin Group "G" Pin A => $GPGGA, but that seems more like creating an excuse than really being practical...

If no one is prefixing their HEX numbers like #PIN8 (I would definately use #PIN10 rather than $PINA), I'd think that it would speed up preprocessing globally to eliminate this as part of permissible number formats (assuming there's not some magic/logic/strategy in the preprocessor I'm missing) and leaving the decimal preprocessing alone. I wouldn't mind needing to change from #PIN8 to #PIN08 on my stack of projects as I need to, but certainly don't want to force everyone unless it's more than my drooling over NMEA that is spawning it.

Requiring a change from Global Pin Group "G" Pin A => $GPGGA to $GPGG0A seems like it'd be a small sacrifice to open up NMEA communications! NMEA is the (American) National Marine Electronics Association, all of their protocols prefix their sentences with "$," and they standardize communications for GPS, depth finders, SONAR, some radio equipment, weather monitoring, on-ship radar just to name a few technologies, and NMEA is THE standard if any is selected for any of these types of devices.

[D.P]

Let's just say that we leave that other cog to just buffer the data and then we have the main cog switch it's input to the buffered serial stream as if we were typing it in from the console. This isn't any different then what FLOAD does for instance, in that it opens a file, then redirects console input to FGET reading in a byte at a time from the file "stream" vs the RS232 "stream".

So give this snippet:

WORD rxrd,rxwr
#128 == rxsize
rxsize BYTES buf232
12 LONGS stack232
#11 == prx

\ Buffer data from the RS232 port - nothing else
pub RS232.TASK
    stack232 SP! !SP                     \ init data stack to 0, assign stack to this task
    #9600 SERBAUD                        \ how fast are we going
    rxrd W~ rxwr W~ buf232 rxsize ERASE  \ clear rxrd, rxwr and erase buf232
    BEGIN 
       prx SERIN rxwr W@        \ get serial byte, fetch rxwr buf232 index( -- 0 datadr )    
       rxsize 1- AND buf232 + C! \ compute buf232 addr and write data to buffer
       rxwr W++                  \ increment buffer pointer
     AGAIN  
    ;

\ You can read the buffered data with this

pub GET232 ( -- ch|0 ) 
     rxrd W@ rxsize 1- AND rxwr W@ rxsize 1- AND <>   \ compute if the buffer is empty
     IF 
       rxrd W@ rxsize 1- AND buf232 + C@
       rxrd W++ 
     ELSE 0 
     THEN
    ;

\ We can do this

pub start232 '  RS232.TASK 4 RUN ;

pub getstream ' GET232 ukey ! ;

start232
100 ms
getstream

It can't be that easy? Really? If so no wonder I'm confused, constantly over engineering the solution. Seem though GET232 needs to return nothing if the buffer is empty?

[Peter Jakacki]

Recovering from the whiplash thanks to artkennedy's DMM pursuit. There's a demolished paradigm I didn't even notice.

Looking at NMEA sentence parsing, would it be better to strip the "$" from the sentences while following D.P's stream of thought, or seeking some kind of exception for NMEA sentences...$GPGGA, $GPGSA, $GPRMC are all very common NMEA sentences, and will be interpreted as $A or $C. I'm assuming that Peter had a good reason to screen for numbers before commands (small fix may break much more).

Unless I had a ultra-fast dictionary search method the number preprocessor does certainly speed up compilation speeds otherwise all numbers suffer from an exhaustive dictionary search first. Although I have fairly lax rules regarding number format I think I would like at least one decimal digit or a leading zero to make it acceptable as a number, so $A would not be a number but $0A would.

Therefore $GPGGA etc will not be accepted as numbers and so a match in the dictionary would be found. Yes, it is possible to just strip the $ from the sentence but I'm not altogether happy with $GPGGA being processed as a number because it doesn't look anything like one. Maybe I might even only allow symbols mixed in # type decimal numbers as come to think of it I never mix symbols with hex numbers.

[Loopy Byteloose]

Sorry to say this but as brilliant as Chuck is he should just work at some pure research establishment as I rarely see any of his designs as being practical, whereas he started off as extremely practical. The GA144 is a case in point, while it's a fun project to get 144 micro-CPUs onto one chip it is a nightmare to get it to do anything useful. If in doubt then have a look at the appnotes and software downloads, or more correctly the almost entire lack or usefulness of them. Even if they got 10baseT working if ever then what's the point?

Now to be a little tacky Loo Pee even though it's pronounced the same way, you know it's Tachyon as in Tachometer etc

As for the I2C LCD it looks like it might just be a dumb 8-bit I/O expander so just make sure you write the low-level routines so that it looks like the software is just talking directly to the display, and of course there is never ever any need to read the busy bit. Then you can use as much of my character LCD code as you want.

A. Chuck Moore's GA144 is indeed a dismal failure.

But it does make Forth on the Propeller absolutely brilliant. Where he failed, Chip Gracy has excelled in creating an excellent Forth microcontroller, and it appears to be an unintentional development.

B. The Funzino I2C to LCD certainly does appear to be a generic I2C port expander with some added features on the tiny board (power take off for back-lighting the LCD, contrast adjustment, and jumpers for addressing multiple units).

The underlying chip is a PCF8574 and Johnny Mac just provided some Spin code for it. That is a big help as the Arduino library stuff is harder for me to understand.

I may have something working soon.

[Chameleon]

So if we wanted to input our serial stream to the Tachyon interpreter in the RS232.TASK how would we revector the input so we could parse let's say the NMEA string example in that cog? I.E. the RS232.TASK cog is accepting the serial input from the gps module and parsing the strings? Here they be dragons.

Recovering from the whiplash thanks to artkennedy's DMM pursuit. There's a demolished paradigm I didn't even notice.

Looking at NMEA sentence parsing, would it be better to strip the "$" from the sentences while following D.P's stream of thought, or seeking some kind of exception for NMEA sentences...$GPGGA, $GPGSA, $GPRMC are all very common NMEA sentences, and will be interpreted as $A or $C. I'm assuming that Peter had a good reason to screen for numbers before commands (small fix may break much more).

[Peter Jakacki]

Having done a tour of duty with Sal's PropForth and Dave Hein's pfth, I am now willing to join the fun with Tachyon.

Along the way, studied eForth's idea of how to create an inner and outer interpreter for any microcontroller.

About all, I have learned that Forth on 8 cogs is light years ahead of any other chip, including Chuck Moore's GA144 (of which I have two).

It has been a rather long journey to get here, but I really have enjoyed it all. So now I am going to try to get a Funduino I2C to LCD up and running in Tackyon. I get I have to port an Arduino library into Tackyon Forth.

Should be fun.

Sorry to say this but as brilliant as Chuck is he should just work at some pure research establishment as I rarely see any of his designs as being practical, whereas he started off as extremely practical. The GA144 is a case in point, while it's a fun project to get 144 micro-CPUs onto one chip it is a nightmare to get it to do anything useful. If in doubt then have a look at the appnotes and software downloads, or more correctly the almost entire lack or usefulness of them. Even if they got 10baseT working if ever then what's the point?

Now to be a little tacky Loo Pee even though it's pronounced the same way, you know it's Tachyon as in Tachometer etc

As for the I2C LCD it looks like it might just be a dumb 8-bit I/O expander so just make sure you write the low-level routines so that it looks like the software is just talking directly to the display, and of course there is never ever any need to read the busy bit. Then you can use as much of my character LCD code as you want.

[Peter Jakacki]

So if we wanted to input our serial stream to the Tachyon interpreter in the RS232.TASK how would we revector the input so we could parse let's say the NMEA string example in that cog? I.E. the RS232.TASK cog is accepting the serial input from the gps module and parsing the strings? Here they be dragons.

Let's just say that we leave that other cog to just buffer the data and then we have the main cog switch it's input to the buffered serial stream as if we were typing it in from the console. This isn't any different then what FLOAD does for instance, in that it opens a file, then redirects console input to FGET reading in a byte at a time from the file "stream" vs the RS232 "stream".

[D.P]

So if we wanted to input our serial stream to the Tachyon interpreter in the RS232.TASK how would we revector the input so we could parse let's say the NMEA string example in that cog? I.E. the RS232.TASK cog is accepting the serial input from the gps module and parsing the strings? Here they be dragons.

[Loopy Byteloose]

Having done a tour of duty with Sal's PropForth and Dave Hein's pfth, I am now willing to join the fun with Tachyon.

Along the way, studied eForth's idea of how to create an inner and outer interpreter for any microcontroller.

About all, I have learned that Forth on 8 cogs is light years ahead of any other chip, including Chuck Moore's GA144 (of which I have two).

It has been a rather long journey to get here, but I really have enjoyed it all. So now I am going to try to get a Funduino I2C to LCD up and running in Tackyon. I get I have to port an Arduino library into Tackyon Forth.

Should be fun.

[Peter Jakacki]

WAITHILO --> WAITHILO <-- NOT FOUND

Since WAITLOW has been ' commented out and replaced with WAITHILO as per the kernel source, for some reason it won't resolve in the dictionary?
Also I have a peripheral (like artkennedy) that needs async comms. I guess the best approach is to use a seperate cog for async Rx (SERIN, which blocks) and "share" the data.

Try (WAITHILO) instead as it does not use the stack but needs a mask in COGREG3 and returns the count in COGREG0. It uses (WAITPNE) and (WAITPEQ).

For asynch I've just been using SERIN running in it's own cog so that it stores to a buffer and does whatever it needs to do.

WORD rxrd,rxwr
#128 == rxsize
rxsize BYTES buf232
12 LONGS stack232

\ Buffer data from the RS232 port - nothing else
pub RS232.TASK
    stack232 SP! !SP
    #9600 SERBAUD
    rxrd W~ rxwr W~ buf232 rxsize ERASE 
    BEGIN 
       9 SERIN rxwr W@ rxsize 1- AND buf232 + C! rxwr W++ 
     AGAIN  
    ;

\ You can read the buffered data with this

pub GET232 ( -- ch|0 ) 
     rxrd W@ rxsize 1- AND rxwr W@ rxsize 1- AND <>
     IF 
       rxrd W@ rxsize 1- AND buf232 + C@
       rxrd W++ 
     ELSE 0 
     THEN
    ;

I may just integrate a serial port module into TF but it just hasn't been pressing enough, I was basically waiting until I implement my PASM module loader which holds a library of objects in EEPROM (or SD) and you just pick and choose at runtime by module name.

[Peter Jakacki]

That is sweet. Here it is incorporated with the rest:

Problem #2: I had forgotten that with this meter the string is transmitted as 7-bits data 2-stop bits and thus arrives with the high bit of each byte set. Is it possible to clear the high bit for the whole string or must it be done byte by byte?
Ouch! Still not "there".

Just to be clear. As I did earlier I can load the input into a string with the high bit stripped if necessary but how is it then "fed" into Forth's wonderful word processor.

What should happen is that GETDMM should not bother returning to the console via CON, rather it should stay in DMMIO and you can add a CON to the end of SCALE so that it's all complete and automatic.

Now it would help if you posted your complete code but I looked back in the thread and found this definition : INfmDMM #22 SERIN ; which is the revectored KEY routine set by DMMIO.

What this should do is strip the 8th bit at that time so that you have #22 SERIN $7F AND so that Forth just finds normal characters.
So SCALE ends up being av C! DPL + scalefact ! dmmval ! and GETDMM is just DMMIO #13 EMIT without the CON.

That should work nicely and later on you could even add a timeout to return to the console in case the meter is not responding.

[D.P]

WAITHILO --> WAITHILO <-- NOT FOUND

Since WAITLOW has been ' commented out and replaced with WAITHILO as per the kernel source, for some reason it won't resolve in the dictionary?
Also I have a peripheral (like artkennedy) that needs async comms. I guess the best approach is to use a seperate cog for async Rx (SERIN, which blocks) and "share" the data.

[artkennedy]

You can count me in ( for the good headache brigade ).

[artkennedy]

That's good, it looks like there is a lot of common functionality being duplicated there though. How about this?

That is sweet. Here it is incorporated with the rest:

FORGET acdc
DECIMAL       \ without a base designation character Tachyon BASE must agree with input

BYTE acdc                           \ 0 = DC, -1 = AC
LONG scalefact                      \ scale value by 10^(negate(scalefact))
LONG dmmval                         \ store the dmmvalue
BYTE av \ 0 = volts, -1 = amperes   \ current or voltage
: DC acdc C~ ;                                  \ first word from input stream is run and specifies the type of reading
: AC acdc C~~ ;                                 \   in this case DC or AC
: SCALE ( val scale av -- ) av C! DPL + scalefact ! dmmval ! ;
: mA  3 1 SCALE ;     \ second word from input stream is the quantity read by the meter and is
: uA  6 1 SCALE ;     \   processed based on the third word, in this case mA or uA
: mV  3 0 SCALE ;     \ scalefact is postive rather than negative to agree with output of DPL
: uV  6 0 SCALE ;     \   when reconstituting reading negate scalefact

It was fun and quite an education to whip the "dmmval" word into shape but then I returned to the task of actually getting the reading from the DMM via the serial port instead of pasting the string to the console input.

Problem #1: After switching the input stream to the serial port, how is input different from the console via typing or pasting?

: GETDMM          \ get reading from DMM, sends CR to trigger response, gets bytes until CR
   DMMIO                \ redirect I/O to DMM
   #13 EMIT             \ send request for data
                  \ ?? what has to happen here ??
   CON                  \ return I/O to console
;

Problem #2: I had forgotten that with this meter the string is transmitted as 7-bits data 2-stop bits and thus arrives with the high bit of each byte set. Is it possible to clear the high bit for the whole string or must it be done byte by byte?
Ouch! Still not "there".

Just to be clear. As I did earlier I can load the input into a string with the high bit stripped if necessary but how is it then "fed" into Forth's wonderful word processor.

[Chameleon]

So we almost have an NMEA parser... :-)
Great stuff.

Epiphany! I've been trying to parse out raw GPS data for a total of three weeks now...figurative reams of paper that can fit on a postcard. That's one of the things I love about Forth...I'm just encumbered with several decades of "bad" habits from other programming languages.

I spent the last three weeks slammed in preparation for the Seattle Mini MakerFaire, and one of the main items we presented showcased Tachyon as a key part. I got lots of wows when I amateurishly and briefly explained Tachyon (even from some pretty militant Arduino developers).

I agree with D.P - it makes my head hurt in a good way too - kind of a 2x4 to the forehead, showing a huge paradigm I never conceived of questioning.

[Peter Jakacki]

Page 67 of this thread causes my head to hurt in a great way.

thanks peter

Why? Did you print it out and try to stick it in your ear? Remember, nothing smaller than a elbow.
Link?

[D.P]

That's good, it looks like there is a lot of common functionality being duplicated there though. How about this?

: SCALE ( val scale av -- ) av C! DPL + scalefact ! dmmval ! ;

: mA  3 1 SCALE ;     \ second work from input stream is the quantity read by the meter and is
: uA  6 1 SCALE ;     \   processed based on the third word, in this case mA or uA
: mV  3 0 SCALE ;      \ scalefact is postive rather than negative to agree with output of DPL
: uV  6 0 SCALE ;      \   when reconstituting reading negate scalefact

Page 67 of this thread causes my head to hurt in a great way.

thanks peter

[Peter Jakacki]

Made code changes as suggested.



New code for GETDMM.fth

That's good, it looks like there is a lot of common functionality being duplicated there though. How about this?

: SCALE ( val scale av -- ) av C! DPL + scalefact ! dmmval ! ;

: mA  3 1 SCALE ;     \ second work from input stream is the quantity read by the meter and is
: uA  6 1 SCALE ;     \   processed based on the third word, in this case mA or uA
: mV  3 0 SCALE ;      \ scalefact is postive rather than negative to agree with output of DPL
: uV  6 0 SCALE ;      \   when reconstituting reading negate scalefact

[artkennedy]

Made code changes as suggested.

The less I see the better it gets. When code or ideas are just converted from another language it can look quite unreadable (and awkward) but with a little Forth Zen it becomes too simple to be considered real software

Here's a tip too because it looks like you are doing a -6 - which is the same as a 6 + plus you can factor the common section like this:

: DC acdc C~ ;
: AC acdc C~~ ;
: uA    6
: +A    DPL + scalefact ! dmmval ! av C~~   ;
: mA    3 +A ;

New code for GETDMM.fth

FORGET acdc
DECIMAL       \ without a base designation character Tachyon BASE must agree with input


BYTE acdc                           \ 0 = DC, -1 = AC
LONG scalefact                      \ scale value by 10^(negate(scalefact))
LONG dmmval                         \ store the dmmvalue
BYTE av \ 0 = volts, -1 = amperes   \ current or voltage
: DC acdc C~ ;                                  \ first word from input stream is run and specifies the type of reading
: AC acdc C~~ ;                                 \   in this case DC or AC
: mA  DPL 3 + scalefact ! av C~~ dmmval ! ;     \ second work from input stream is the quantity read by the meter and is
: uA  DPL 6 + scalefact ! av C~~ dmmval ! ;     \   processed based on the third word, in this case mA or uA
: mV  DPL 3 + scalefact ! av C~ dmmval ! ;      \ scalefact is postive rather than negative to agree with output of DPL
: uV  DPL 6 + scalefact ! av C~ dmmval ! ;      \   when reconstituting reading negate scalefact

[Peter Jakacki]

Peter - if one were worried about malicious inputs, would it be easy to limit the dictionary to NMEA words while parsing input in the manner that you show above?

Yes, you can indeed and it's a very easy thing to do of course with one of the ways simply to have a control word/passphrase which terminates the dictionary links early. I need to do the same with Ethernet servers so I will probably build in something just for this as well as vocabulary support.

[KeithE]

Peter - if one were worried about malicious inputs, would it be easy to limit the dictionary to NMEA words while parsing input in the manner that you show above?

[max72]

Thanks!
Great stuff...
Massimo

[Peter Jakacki]

So we almost have an NMEA parser... :-)
Great stuff.

That's not hard at all, there are several different approaches but if we just try to process it naturally it looks a bit like this (terminal session):

LONG lat,lon,alt  ok
  ok
: S      NEGATE 
: N      lat ! ;  ok
: W      NEGATE  
: E      lon ! ;   ok
: M      alt ! ;   ok
  ok
BYTE gpssum  ok
: ?GPS           word C@ "*" = IF word 1+ NUMBER DROP gpssum C! THEN     ;  ok
: GPGGA          DECIMAL ' ?GPS unum W! ; IMMEDIATE  ok
"," delim C!  ok
  ok
GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47  ok
  ok
( Horz dilution ) . 9 ok
( Satellites ) . 8 ok
( Fix quality ) . 1 ok
( UTC ) . 123519 ok
  ok
lat @. 4807038 ok
lon @. 1131000 ok
alt @. 469 ok
gpssum C@ . 47 ok

Of course it's not quite perfect but that's just a bit of Q&D code. I stripped the $ symbol first as $GPPGA was resolving as $A or 10, so that's something I might fix up in my number preprocessor but the ideas there. It would pay to have the decimal places latched so that this could be used as well.

EDIT: actually it's possible to execute postfix fashion so that we can also grab and store the other parameters like this:

LONG lat,lon,alt
LONG sum,horz,sats,fix,utc

: S    NEGATE
: N    lat ! ;
: W    NEGATE 
: E    lon ! ; 
: M    alt ! ; 

: ?GPS        word C@ "*" = IF word 1+ NUMBER DROP sum ! THEN    ;

: &GPGGA    horz ! sats ! fix ! utc ! prompt W~ ;
: GPGGA        DECIMAL ' ?GPS unum W! ' &GPGGA prompt W! ; IMMEDIATE
"," delim C!

\ our sample data
GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

\ report what we found
lat @.
lon @.
alt @.
sum @.
horz @.
sats @.
fix @.
utc @.


{ which looks like this:
lat @. 4807038 ok
lon @. 1131000 ok
alt @. 469 ok
sum @. 47 ok
horz @. 9 ok
sats @. 8 ok
fix @. 1 ok
utc @. 123519 ok
}

[max72]

So we almost have an NMEA parser... :-)
Great stuff.

[Peter Jakacki]

actually, a while back I had to parse a command of the form:
!CMD123;456;789;1011<crlf>
see: http://forums.parallax.com/showthrea...=1#post1126867
unfortunately there are no spaces and no uniform separator at all.
So then again luckily, there were no spaces - so Forth will take the whole command as a new word and throw the word-not-found-error.
I did a little modification to the Tachyon kernel and set up a word-not-found handler.
This will simply check for the starting !, take the first 3 command characters,
then replaces the ";" separator with spaces in word buffer. and then I
just stuff the string back to the front of the input buffer.
so from !CMD123;456;789;1011
I create "123 456 789 1011 CMD "
and put this back to the input buffer (since I was new to forth I modified the Tachyon kernel for this - but I think it could have been done without).
Then Tachyon takes over again, takes the numbers (0 .. 5 in my case)
and then executes the command word.
This is very elegant since I can easily extend the language with the many commands I need - one by one. No big case or parser required.
http://forums.parallax.com/showthrea...=1#post1128483


links to my example code and modified Tachyon1.0

TF allows you to change the delimiter so that you could make a ; a delimiter if you like. Here's a terminal session:

!CMD123;456;789;1011 --> !CMD123;456;789;1011 <-- NOT FOUND 
: !CMD123 ;  ok
";" delim C!  ok
!CMD123;456;789;1011  ok
.S  Data Stack (3)
$0000.1011 - 4113
$0000.0789 - 1929
$0000.0456 - 1110
$0000.0000 - 0 ok
0D delim C!  ok

Of course it didn't separate the 123 from CMD but it's a start.

[Peter Jakacki]

Much appreciated this submission from MJB. It helped me get my thoughts organized on this.
I found a few things I thought should be changed.
Please let me know if I am missing something.

The less I see the better it gets. When code or ideas are just converted from another language it can look quite unreadable (and awkward) but with a little Forth Zen it becomes too simple to be considered real software

Here's a tip too because it looks like you are doing a -6 - which is the same as a 6 + plus you can factor the common section like this:

: DC acdc C~ ;
: AC acdc C~~ ;
: uA    6
: +A    DPL + scalefact ! dmmval ! av C~~   ;
: mA    3 +A ;

[artkennedy]

Much appreciated this submission from MJB. It helped me get my thoughts organized on this.
I found a few things I thought should be changed.
Please let me know if I am missing something.


Changes:

BYTE scalefact  \ scale value by 10^scalefact


: mA  -3 DPL - scalefact C! 1 av C! dmmval ! ;
: uA   -6 DPL - scalefact C! 1 av C! dmmval ! ;


Changed to :


LONG scalefact  \ scale value by 10^scalefact       \ must use LONG for negative values, is this true for other Forths?


: mA  DPL -3 - scalefact ! 1 av C! dmmval ! ;       \ DPL must be first in order to operate on the input number
: uA  DPL -6 - scalefact ! 1 av C! dmmval ! ;       \ ditto


Dropped:


\ don't think these are needed - works fine without.


0 acdc C!
1 scalefact !


Added:


DECIMAL   \ without a base designation character in input string Tachyon BASE must agree with input

Here it is with changes made:

FORGET acdc
DECIMAL       \ without a base designation character Tachyon BASE must agree with input


BYTE acdc   \ 0 = DC, 1 = AC
LONG scalefact  \ scale value by 10^scalefact
LONG dmmval      \ store the dmmvalue
BYTE av \ 0 = volts, 1 = amperes
: DC 0 acdc C! ;
: AC 1 acdc C! ;
: mA  DPL -3 - scalefact ! 1 av C! dmmval ! ;
: uA  DPL -6 - scalefact ! 1 av C! dmmval ! ;
\ now after typing AC 12.3 mA you have
\ acdc = 1
\ scalefact = -4
\ dmmval = 123  == 123*10^-4 == 12.3mA
\ av = 1  == Amperes

My immediate project will always take DMM readings on the same scale without negative results so it will have no need for 'acdc' or 'scalefact' which will make for simpler code. However, I hope that there will be wider interest and more general code will be needed. This will be useful. Thanks.


And especial thanks to Peter for Tachyon and showing me how simple this part could be. Kenobi-san, I shall remember.
Forth On!

[MJB]

Hi Art,

you could have:

BYTE acdc   \ 0 = DC, 1 = AC
0 acdc C!
BYTE scalefact  \ scale value by 10^scalefact
1 scalefact  C!  \ 
LONG dmmval      \ store the dmmvalue
BYTE av \ 0 = volts, 1 = amperes
: DC 0 acdc C! ;
: AC 1 acdc C! ;
: mA  -3 DPL - scalefact C! 1 av C! dmmval ! ;
: uA   -6 DPL - scalefact C! 1 av C! dmmval ! ;
\ now after typing AC 12.3 mA you have
\ acdc = 1
\ scalefact = -4
\ dmmval = 123  == 123*10^-4 == 12.3mA 
\ av = 1  == Amperes

so no parser required !!!

getting this was one of the heureca monemts about forth
thanks Peter :-)

actually, a while back I had to parse a command of the form:
!CMD123;456;789;1011<crlf>
see: http://forums.parallax.com/showthrea...=1#post1126867
unfortunately there are no spaces and no uniform separator at all.
So then again luckily, there were no spaces - so Forth will take the whole command as a new word and throw the word-not-found-error.
I did a little modification to the Tachyon kernel and set up a word-not-found handler.
This will simply check for the starting !, take the first 3 command characters,
then replaces the ";" separator with spaces in word buffer. and then I
just stuff the string back to the front of the input buffer.
so from !CMD123;456;789;1011
I create "123 456 789 1011 CMD "
and put this back to the input buffer (since I was new to forth I modified the Tachyon kernel for this - but I think it could have been done without).
Then Tachyon takes over again, takes the numbers (0 .. 5 in my case)
and then executes the command word.
This is very elegant since I can easily extend the language with the many commands I need - one by one. No big case or parser required.
http://forums.parallax.com/showthrea...=1#post1128483


links to my example code and modified Tachyon1.0

[MJB]

Peter,

I have a short question... when you write something on the terminal to for example add a word, are the IDLE cogs being used ? or the terminal COG does everything ? (Could I spare cogs 2 to 6?)

there is one special COG dedicated to receiving - at the moment (I remember Peter talking about joining Rx & Tx in one COG for multiple serial connections).
The writing is done from the kernel, so can be done from ANY COG running the Tachyon interpreter. All done by EMIT and the higher level words, that build on it.
Just directly bitbanged out.

I am just wondering what will happen if several COGs try to write by EMIT -
I would expect some garbage ... you would have to implement some cooperation between different writers.

[Ale]

Peter,

I have a short question... when you write something on the terminal to for example add a word, are the IDLE cogs being used ? or the terminal COG does everything ? (Could I spare cogs 2 to 6?)

[artkennedy]

Hi Art,

you could have:

BYTE acdc   \ 0 = DC, 1 = AC
0 acdc C!
BYTE scalefact  \ scale value by 10^scalefact
1 scalefact  C!  \ 
LONG dmmval      \ store the dmmvalue
BYTE av \ 0 = volts, 1 = amperes
: DC 0 acdc C! ;
: AC 1 acdc C! ;
: mA  -3 DPL - scalefact C! 1 av C! dmmval ! ;
: uA   -6 DPL - scalefact C! 1 av C! dmmval ! ;
\ now after typing AC 12.3 mA you have
\ acdc = 1
\ scalefact = -4
\ dmmval = 123  == 123*10^-4 == 12.3mA 
\ av = 1  == Amperes

so no parser required !!!

getting this was one of the heureca monemts about forth
thanks Peter :-)

Wow! This is cool. Thanks all around. There are more lights in the room now.

[Peter Jakacki]

NEWCNT and .LAP have been the two words that have been used when it comes to timing TF as to how fast or slow it is running. Recently the VM instruction LAP was added which attempted to be more precise as it would calculate the delta since the last LAP and left the result in a COGREG rather than push the result on the stack as it would not be deterministic or needed the first time. So I was using LAP followed by .LAP with a compensation factor so that an empty LAP .LAP combo would report zero, expect it varied. This was because .LAP is bytecode and sits in the hub and so introduced hub delays. So now I use the combination of LAP <code> LAP .LAP instead and I have also used independent registers for LAP so that RUNMODs etc don't interfere. The timing calculations have also been optimized so that now it can time events up to 5.368 seconds maximum as this is limited by the maximum counter value of 53.687 seconds which has to be divided by 80 to calculate microseconds but what I do is multiply by 10 first then shift right 3 hence the *10 reduction.

Here are some raw results:
LAP LAP .LAP 0.00us ok
LAP NOP LAP .LAP 0.40us ok
LAP NOP NOP LAP .LAP 0.80us ok
DECIMAL ok
LAP 0 LAP .LAP 1.00us ok
LAP 0 LAP .LAP 1.00us ok
LAP 0 LAP .LAP 1.00us ok
LAP 0 LAP .LAP 1.00us ok
LAP 0 LAP .LAP 1.20us ok
!SP ok
LAP 0 LAP .LAP 1.00us ok
LAP 8 LAP .LAP !SP 1.40us ok
LAP 1234 LAP .LAP !SP 2.20us ok
LAP $FFFF_FFFF LAP .LAP !SP 3.40us ok
10 0 LAP DO LOOP LAP .LAP 10.00us ok
100 0 LAP DO LOOP LAP .LAP 64.00us ok
1,000 0 LAP DO LOOP LAP .LAP 604.00us ok
10,000 0 LAP DO LOOP LAP .LAP 6.00ms ok
100,000 0 LAP DO LOOP LAP .LAP 60.00ms ok
1,000,000 0 LAP DO LOOP LAP .LAP 600.00ms ok
10,000,000 0 LAP DO LOOP LAP .LAP 631.29ms ok
5,000,000 0 LAP DO LOOP LAP .LAP 3000.00ms ok
1234 10 LAP * LAP .LAP 2.60us ok
1234 10 LAP U/ LAP .LAP 9.20us ok
!SP ok
1234 5678 LAP + LAP .LAP 1.00us ok
$A5 LAP SPIWR LAP .LAP 2.40us ok


Notice just before the first !SP that the same 0 operation was now taking 1.2us and that's because the stack had overflowed into hub stack, the subsequent !SP brought it back again.The 10,000,000 DO LOOP line should report 6,000ms but instead reports 631.29ms as the counter has overflowed and that's the difference between 6 seconds and 5.368 seconds.

LAP <code> LAP .LAP is the recommended and precise way of timing code. NEWCNT has been deprecated but is at present still an alias for LAP.

So here is the iterative Fibonacci being timed again:
DECIMAL ok
47 6 DO CR ." fibo(" I . ." ) = " I LAP fibo LAP .LAP ." result =" . 10 +LOOP
fibo(6) = 8.60us result =8
fibo(16) = 11.60us result =987
fibo(26) = 14.60us result =121393
fibo(36) = 17.60us result =14930352
fibo(46) = 20.60us result =1836311903 ok

[D.P]

Hi Art,

you could have:

BYTE acdc   \ 0 = DC, 1 = AC
0 acdc C!
BYTE scalefact  \ scale value by 10^scalefact
1 scalefact  C!  \ 
LONG dmmval      \ store the dmmvalue
BYTE av \ 0 = volts, 1 = amperes
: DC 0 acdc C! ;
: AC 1 acdc C! ;
: mA  -3 DPL - scalefact C! 1 av C! dmmval ! ;
: uA   -6 DPL - scalefact C! 1 av C! dmmval ! ;
\ now after typing AC 12.3 mA you have
\ acdc = 1
\ scalefact = -4
\ dmmval = 123  == 123*10^-4 == 12.3mA 
\ av = 1  == Amperes

so no parser required !!!

getting this was one of the heureca monemts about forth
thanks Peter :-)

YES, this also was the ah-ha moment for me, use the problems "language" to define the FORTH words. Thanks!

[max72]

Insane!!
Thanks both for the tools and the tutorials!
Massimo

[MJB]

Sonuvagun!

DECIMAL  ok
GETWORD : DC 4.321 uA  --> uA <-- NOT FOUND
;  ok
DC .S  Data Stack (1)
$0000.10E1 - 4321
$0000.0000 - 0 ok

Oh (again). Predefine : uA reading ! ; (or something similar) I get it. That is excellent!

Hi Art,

you could have:

BYTE acdc   \ 0 = DC, 1 = AC
0 acdc C!
BYTE scalefact  \ scale value by 10^scalefact
1 scalefact  C!  \ 
LONG dmmval      \ store the dmmvalue
BYTE av \ 0 = volts, 1 = amperes
: DC 0 acdc C! ;
: AC 1 acdc C! ;
: mA  -3 DPL - scalefact C! 1 av C! dmmval ! ;
: uA   -6 DPL - scalefact C! 1 av C! dmmval ! ;
\ now after typing AC 12.3 mA you have
\ acdc = 1
\ scalefact = -4
\ dmmval = 123  == 123*10^-4 == 12.3mA 
\ av = 1  == Amperes

so no parser required !!!

getting this was one of the heureca monemts about forth
thanks Peter :-)

[Peter Jakacki]

Sonuvagun!

DECIMAL  ok
GETWORD : DC 4.321 uA  --> uA <-- NOT FOUND
;  ok
DC .S  Data Stack (1)
$0000.10E1 - 4321
$0000.0000 - 0 ok

Oh (again). Predefine : uA reading ! ; (or something similar) I get it. That is excellent!

No, actually it's simplier than that, just let Forth interpret the text as it normally does. Of course Forth doesn't know DC or uA or anything like that but that's why you just define those words as I mentioned.
The first word such as DC or AC etc could just leave a number on the stack so therefore thses words would be constants. The V and mV and uA are all words that expect two numbers to be on the stack and handle it accordingly. To go and write a routine to parse the string is almost like bypassing Forth itself, just let it do it's thing.

To give an example, I have WEB/FTP/TELNET servers running in Forth and they must "parse" commands from clients, yet I don't have any special parser, I just define words like GET RETR USER PASS LIST PASV etc and that's it. There is no central parser.
Remember, use the Forth Luke

[artkennedy]

Sonuvagun!

DECIMAL  ok
GETWORD : DC 4.321 uA  --> uA <-- NOT FOUND
;  ok
DC .S  Data Stack (1)
$0000.10E1 - 4321
$0000.0000 - 0 ok

Oh (again). Predefine : uA reading ! ; (or something similar) I get it. That is excellent!

[artkennedy]

GETWORD only has one buffer for a word so it can't stack them as in GETWORD GETWORD so you need to copy them perhaps. You might have to remind me what you are trying to do again, what does the string look like? Hold on, I went back through your posts so I will assume it is this one "DC 399.9 uA<cr>"

If that is all you are trying to read then why don't you let Forth parse it normally rather than wrangling with it? For instance you define DC which sets a variable/flag then 399.9 ends up on the stack and then you could have uA mA etc which will expect a number already on the stack etc. If the decimal point is important I could easily make sure that that information is made available in a variable.

That example string is only for one of the ranges of the DMM, the DC micoramp range. I would like to make a word that works for all the ranges. They have in common, in order, a type designator, <space>, number, <space>, range designator. The length of the first and third fields may vary slightly. Therefore I would like to parse the string using the spaces as delimiters. Wow, it just occurred to me - that is what GETWORD does. Right? I could just use GETWORD three times assigning the result sequentially to type$, reading$, and range$ and then using STR>NUM on reading$.

As for how to use the result of GETWORD I'm not sure I understand how that is done ( that's not right - I am sure I don't understand ). What I have tried using @PAD was just a fake based on experimentation. Is that the proper way to access the result of a GETWORD event?

DPL looks good. I had thought I might go back and add that to STR>NUM.

I am rather cloudy about your suggestion re letting FORTH parse the input string. Thinking . . . -- holy cow! Do you mean by adding a colon and space to the front and a space and semi-colon to the end?!? Oh, I love tricks! Scratching head . . . how would that work? :-)

This Tachyon environment is vast and I feel like a blind person feeling his way around the room from chair to chair. I really appreciate your patience and assistance.

[Peter Jakacki]

Originally Posted by artkennedy Best I can do so far with what I have been able to discover about GETWORD:

GETWORD only has one buffer for a word so it can't stack them as in GETWORD GETWORD so you need to copy them perhaps. You might have to remind me what you are trying to do again, what does the string look like? Hold on, I went back through your posts so I will assume it is this one "DC 399.9 uA<cr>"

If that is all you are trying to read then why don't you let Forth parse it normally rather than wrangling with it? For instance you define DC which sets a variable/flag then 399.9 ends up on the stack and then you could have uA mA etc which will expect a number already on the stack etc. If the decimal point is important I could easily make sure that that information is made available in a variable.

I've implemented detecting decimal places in the kernel which can be read out with DPL and is valid for the last number entered. Numbers cannot start or end in a decimal point, here are some examples:
12.345 DPL . 3 ok
0.12345 DPL . 5 ok
12345. --> 12345. <-- NOT FOUND
12345.0 DPL . 1 ok
.12345 --> .12345 <-- NOT FOUND

[Peter Jakacki]

Best I can do so far with what I have been able to discover about GETWORD:

: TEST       \ assign portion of input stream between spaces to string
    GETWORD        \ accept first segment of input stream
    GETWORD        \ accept second segment of input stream
    @PAD #11 +     \ point to segment in input buffer
    DMMINP$ COPY$  \ copy to variable
;

Pretty clunky . . . tips?

GETWORD only has one buffer for a word so it can't stack them as in GETWORD GETWORD so you need to copy them perhaps. You might have to remind me what you are trying to do again, what does the string look like? Hold on, I went back through your posts so I will assume it is this one "DC 399.9 uA<cr>"

If that is all you are trying to read then why don't you let Forth parse it normally rather than wrangling with it? For instance you define DC which sets a variable/flag then 399.9 ends up on the stack and then you could have uA mA etc which will expect a number already on the stack etc. If the decimal point is important I could easily make sure that that information is made available in a variable.

[artkennedy]

Best I can do so far with what I have been able to discover about GETWORD:

: TEST       \ assign portion of input stream between spaces to string
    GETWORD        \ accept first segment of input stream
    GETWORD        \ accept second segment of input stream
    @PAD #11 +     \ point to segment in input buffer
    DMMINP$ COPY$  \ copy to variable
;

Pretty clunky . . . tips?

[Peter Jakacki]

I need an array for storing 16 sensor readings. Two bytes are needed for each.

I find that his works fine:
8 LONGS sensor
or
32 BYTES sensor

But when I use:
16 WORDS sensor
WORDS lists the dictionary.

I can just use the BYTES way - thought you might not have noticed this . . .

LOL, missed that!

The files have been updated so that WORDS followed by a CR will perform a listing while WORDS followed by a space(s) or tab will work like BYTES and LONGS. The binary has been updated.

[artkennedy]

This has been upgraded to:
30 BYTES dmmbuf
which also initializes the array to zeros. There are also the corresponding WORDS and LONGS you can use to create an array

I need an array for storing 16 sensor readings. Two bytes are needed for each.

I find that his works fine:
8 LONGS sensor
or
32 BYTES sensor

But when I use:
16 WORDS sensor
WORDS lists the dictionary.

I can just use the BYTES way - thought you might not have noticed this . . .

[artkennedy]

Also the loop in STR>NUM looks like it's begging for the use of a <CMOVE which moves a block of memory just like CMOVE does but it calculates the end addresses and works backwards so it's safe to use for moving a block up a few bytes.
BTW, the NUMBER routine in the kernel has been fixed so it just accepts any string now without expecting a count byte.

Sure is nice to have NUMBER upgraded and to use <CMOVE.
Here is the new STR>NUM:

: STR>NUM             \ ( str chb -- num ) shift string 2 cells right, append len and base flag character
   SWAP DUP LEN$      \ ( str chb -- chb str len )
   1+                 \ ( chb str len -- chb str len1+ ) expand loop counter to include <null> at end of string
   OVER DUP 1+        \ ( chb str len1+ -- chb str len1+ str str1+ )
   ROT <CMOVE         \ ( chb str len1+ str str1+ -- chb str )
   SWAP OVER          \ ( chb str -- str chb str )
   C!                 \ ( str chb str -- str )
   NUMBER             \ ( str -- num flag ) flag = 0 if bad else ct of num chars, num = number to base of chb
;

[Peter Jakacki]

Neat, is EXTEND.fth built with SMALL or not in the pre-comipled version? One less layer of complexity removed, thanks.

dp

I'm guessing the ones that will be using the binary the most are the ones who just want to try it out with the minimum of fuss so it's the normal EXTEND with over 11KB free. Once you have loaded in EXTEND yourself on a small build it shouldn't worry again in that if you ever have to reload another module it is normally set to forget itself if it is already loaded.

If you want to make a binary yourself just bear in mind that I changed the name to DUMPROM and also if you have an SD card in your system you can use SAVEROM to save to a preset file called ROM.BIN.

[D.P]

I use 10Mhz crystals in practically all my designs but all the Parallax boards are 5MHz and this means that when I am compiling Tachyon source for myself I need to change this figure otherwise I like to leave it set for standard 5MHz for everyone else. But it would be nice to have the code check to see which crystal it is running on and so I got around to integrating PhiPi's CLKSET object into Tachyon as a RUNMOD called when Tachyon is initializing. I've tested this on a couple of boards and it works well so now I can leave the settings as if it were 10MHz but you don't have to change this if you compile for 5MHz.

My sig also now includes a direct link to the latest binary which is the precompiled kernel plus EXTEND.fth. The default baudrate is 230400 baud and btw I use 12ms line delay.

Neat, is EXTEND.fth built with SMALL or not in the pre-comipled version? One less layer of complexity removed, thanks.

That was lazy of me since .TASKS is there the binary in not SMALL.


UPDATE: The binary works great on the PBOE.

[Peter Jakacki]

I use 10Mhz crystals in practically all my designs but all the Parallax boards are 5MHz and this means that when I am compiling Tachyon source for myself I need to change this figure otherwise I like to leave it set for standard 5MHz for everyone else. But it would be nice to have the code check to see which crystal it is running on and so I got around to integrating PhiPi's CLKSET object into Tachyon as a RUNMOD called when Tachyon is initializing. I've tested this on a couple of boards and it works well so now I can leave the settings as if it were 10MHz but you don't have to change this if you compile for 5MHz.

My sig also now includes a direct link to the latest binary which is the precompiled kernel plus EXTEND.fth. The default baudrate is 230400 baud and btw I use 12ms line delay.

[artkennedy]

I want to use GETWORD. I have looked it up in the kernel. Ooof! Too deep for me.

I'm putting on my waders. Somebody point me to the 'stream' ;-)

[artkennedy]

Good stuff.

[Peter Jakacki]

One thing I noticed:

"A" . 41 ok
" " . 3489 ok

Is that intentional?

Yep, absolutely......

As you already know all "words" in Forth are separated by one or more spaces and "A" is neither a word nor a normal number but is processed by the number routine a little further to see if it qualifies as a character literal etc. In this it qualifies as a character literal.

Now " is a word in Forth and it is used to build a string as you already know " this is a string" . So I guess you know what " " does then!?
The blank character is also a VM instruction called BL and I also use it as a decimal 32 in loops etc. I suppose I could put in extra checks to see if it is an empty string but where do you stop?

[artkennedy]

One thing I noticed:

"A" . 41 ok
" " . 3489 ok

Is that intentional?

[artkennedy]

Hey Art thanks for all the comments, makes it a pleasure to follow your code.

Smiling, gotta do that to understand it myself. I've written a lot of code for the hp48 and lost the ability to use and understand it because I did it on the calculator and did not document - had to stop that.

Watch my stuff if you will and let me know if where it can be improved. It has been about 30 years since the last time I wrote forth code and then only one big personal project and Tachyon is way different - lot to learn.

[D.P]

Thanks for the props. Yes, use the CMID$ etc in EXTEND, my pleasure. And thanks for the other tips - will use.

Hey Art thanks for all the comments, makes it a pleasure to follow your code.

[artkennedy]

Thanks for the props. Yes, use the CMID$ etc in EXTEND, my pleasure. And thanks for the other tips - will use.

[Peter Jakacki]

I was about to give and ask for help again ( gawd, makes me feel like such a beggar ) when something clicked and I went a little bit crazy. After 3 or 4 days this popped out. Voila:

<snip>

I was tired but happy when I got to bed today at 3:45 AM but I have a lot to learn so if you have anything helpful to say about strategy, technique, terminology etc. just let 'er rip.

Also I am new to forums like this so if there is a more appropriate way to present such a long utterance please point me in that direction.

Glad to see you having fun, I've been a bit time poor lately and haven't had enough time to look at it but the code looks very neatly written.

A couple of things I noticed was that you have a special routine to input a string from the DMM but if you simply define INfmDMM to strip the 8th bit then you could just use GETWORD to read in the string and COPY$ to the dmmbuf after. Also the loop in STR>NUM looks like it's begging for the use of a <CMOVE which moves a block of memory just like CMOVE does but it calculates the end addresses and works backwards so it's safe to use for moving a block up a few bytes.
BTW, the NUMBER routine in the kernel has been fixed so it just accepts any string now without expecting a count byte.

Your use of BEFORE$ AFTER$ BETWEEN$ makes me think that these could be more general-purpose as they work similar to LEFT$ RIGHT$ MID$ except they use a character match rather than a count. So if I rename them to say CLEFT$ CRIGHT$ CMID$ then I might add them to EXTEND if you like.

Although you can still use the TABLE expression for arrays as such:
TABLE dmmbuf 30 ALLOT
dmmbuf 30 0 FILL
This has been upgraded to:
30 BYTES dmmbuf
which also initializes the array to zeros. There are also the corresponding WORDS and LONGS you can use to create an array whereas the TABLE word is good for building a table of constants.

That's more than I had time for at the moment but well done, I will find some more time later.

[artkennedy]

I was about to give and ask for help again ( gawd, makes me feel like such a beggar ) when something clicked and I went a little bit crazy. After 3 or 4 days this popped out. Voila:

I am trying to get three serial ports working with the Propeller on this beautiful (to me) kludgey project.

Right now the goal is to read the output of a DMM connected to AD590 temperature sensors. These sensors operate with voltage as low as 3 volts and source current at 1 microamp per degree Kelvin. My Protek 506 DMM has a range for up to 399.9 uA. Which translates to 125C or 260F - enough for direct readings without need for op amps etc. I have successfully connected this DMM to my XP Netbook and to my hp48g calculators - not yet to the Prop. Meanwhile I have written a program on an hp48 to simulate the output from the meter 'FAKEDMM' and connected at 1200 BAUD like the meter. The format is 7 bits with 2 stop bits which can be read by 8 and no stop bits by stripping the high bit from incoming data. I have written a word that receives this data and stores it in a buffer, dmmbuf.

The meter sends data as a string with a prefix and suffix to indicate scales and type of reading. The format for the scale I want to read is "DC 399.9 uA<cr>". Next is to turn this string into a number in the Prop. I would never hook up the system with negative polarity (adding another character for the minus ) so for my purposes I could just pluck characters 4 through 8 and send the string to NUMBER, after adding a char count to the front. However, I have the crazy idea that someone else might get interested in using this in another way using a different scale with a different format and I would like to make this useful in such a case. Fortunately the scales all delimit the number with spaces. So, use the spaces to extract the number. And so began my introduction to Tachyon strings.

I was pretty clueless at first but as I say, something finally clicked and here is what I came up with.
This code is rather extravagantly commented. That is me trying to keep track of what I am doing.

First this to load the buffer from the DMM:

FORGET dmmbuf
TABLE dmmbuf 30 ALLOT
dmmbuf 30 0 FILL
dmmbuf 30 DUMP

#1200 SERBAUD

: OUT2DMM #23 SEROUT ;

: INfmDMM #22 SERIN ;

: DMMIO
    ' OUT2DMM uemit W!   \  redirects I/O to OUT2DMM
    ' INfmDMM ukey W!    \  redirects I/O to INfmDMM
;

: GETDMM         \ get reading from DMM, sends CR to trigger response, gets bytes until CR
   DMMIO                \ redirect I/O to DMM
   #13 EMIT             \ send request for data
   dmmbuf 1 -           \ init store address
   BEGIN                \ get bytes
      1 +               \    increment store address
      KEY #128 -        \    get byte, clear hi bit
      DUP 3RD           \    save copy for exit testing, pick address to top leaving a copy
      C!                \    store key
      #13 =             \    check for CR ( #141 was sent by DMM, it was converted to #13 above )
   UNTIL                \ finished
   0 SWAP C!            \ end string with a null
   CON                  \ return I/O to console
;

Then string words to select parts of strings based on the position of characters in the strings - in this case spaces.

: AFTER$      \  ( str ch -- str \points to portion of input string to the right of first instance of ch )
   OVER LEN$     \ ( str ch -- str ch len ) length of input string
   SWAP 3RD      \ ( str ch len -- str len ch str )
   LOCATE$ 3RD   \ ( str len chr str -- str len chptr str ) chptr-address of target ch
   - - 1-        \ ( str len chptr str -- str lenrem ) chptr - str = choffset, len - choffset - 1 = length of remainder of string
   RIGHT$        \ ( str lenrem -- rtstr ) rtstr = address of remainder of string
;

: BEFORE$     \ ( str ch -- str \portion of input string to the left of first instance of ch )
   OVER LOCATE$   \ ( str ch -- str chptr ) find the marker char
   OVER -         \ ( str chptr -- str len ) string and len of new string
   LEFT$          \ ( str len -- str ) there is now a <null> at the former address of the space
;

: BETWEEN$        \ ( str ch -- str \portion of input string enclosed by first two instances of ch )
   SWAP OVER      \ ( str ch -- ch str ch )  save copy of enclosing ch
   AFTER$ SWAP    \ ( ch rtstr -- rtstr ch )
   BEFORE$        \ ( rtstr ch -- btwstr ) address of target string
;

And finally the one to make an honest number out of it. The string needed to be shifted two cells to the right for NUMBER. One for the character count byte and one for the number base prefix character. Again I wanted the work to have the potential for general use so input to the word is ( str chb -- ) with chb being "#" in this case.

"#"
FORGET STR>NUM
: STR>NUM             \ ( str chb -- num ) shift string 2 cells right, append len and base flag character
   SWAP DUP LEN$      \ ( str chb -- chb str len )
   SWAP OVER          \ ( chb str len -- chb len str len )
   1+                 \ ( chb len str len -- chb len str len1+ ) expand loop counter to include <null> at end of string
   2DUP +             \ ( chb len str len1+ -- chb len str len1+ endptr ) save copy of len and str
   SWAP 0             \ ( chb len str len1+ endptr -- chb len str endptr len1+ 0 )
   DO                 \ ( chb len str endptr len1+ 0 -- chb len str endptr )
      DUP I              \ ( chb len str endptr -- chb len str endptr endptr I )
      1+ - DUP           \ increase loop counter by one then subtract - pointing to source cell, save a copy
      C@                 \ ( -- chb len str endptr source sd ) fetch contents of source cell (sd)
      SWAP 2+            \ ( chb len str endptr source sd -- chb len str endptr sd dest ) increment pointer to destination cell
      C!                 \ ( chb len str endptr sd dest -- chb len str endptr ) store
   LOOP               \ next cell
   DROP               \ ( chb len str endptr -- chb len str ) drop endptr
   SWAP 1+ OVER C!    \ ( chb len str -- chb str ) incr len, copy str, store len at str ( in vacated first position )
   SWAP OVER 1+       \ ( chb str -- str chb str1+ ) copy str, point to second cell of string
   C!                 \ ( str chb str1+ -- str ) store base flag char there
   1+ NUMBER          \ ( str -- num flag ) flag = 0 if bad else ct of num chars, num = number to base of chb
;

I was tired but happy when I got to bed today at 3:45 AM but I have a lot to learn so if you have anything helpful to say about strategy, technique, terminology etc. just let 'er rip.

Also I am new to forums like this so if there is a more appropriate way to present such a long utterance please point me in that direction.

[D.P]

Tachyon has many ways to communicate to peripherals, what would be a good approach to modify the kernel to support Tachyon as a I2C slave device? Timmoore and Hippy have done alot of work in this area, my idea is to map the Tachyon Slave as a set of I2C Read/Write Registers into a Tachyon TABLE. This approach allows the Tachyon/Prop/Forth to just update the TABLE leaving the display to update all the graphics. One TASK for the console, one as the i2c slave to send recieve data from the TABLE/Registers, one TASK for the timmers, the rest used as the Target project requires.

More.

Holding the "state machine" as a series of bytes in upper eeprom allows the machine to recover from power downs into a known state. Upon reboot the state machine would be written to the TABLE, when the display reads the TABLE/REGISTERS upon its reboot it will know what to do instead the prop telling it to go to this page, clear yourself, update these widgets like this.... This logic can/should be part of these "intelligent" displays, the 4DSystem's displays are getting less expensive and more powerful all the time and with the soon to come full hd video diablo processor the 32PTUs will drop in price again.

I've attached the pasm version of timmoore's I2C code from obex for mutual reference if any one else is interested in this idea.


Update:
I found this Peter, has this been done to Tachyon? Heck with I2C if so.

I can tweak my SPI module in Tachyon Forth to handle slave mode. That way you get the speed, the interactivity, without delving into PASM.

http://forums.parallax.com/showthrea...=1#post1144225

[artkennedy]

Got it. Thanks again.

Number has to return a flag as well and this flag also happens to be the number of digits that it managed to convert, zero meaning it's not a number.
In your case it said it had 4 digits.

num$ 1+ NUMBER ok
.S Data Stack (02)
$0000.0004 - 4
$0000.0F9F - 3999 ok

BTW, NUMBER will be modified to handle normal strings but even the GETWORD string is still a normal null terminated string, it's just that it also happens to have the count preceding the address of the string, just as we faked with num$ 1+ NUMBER

[Peter Jakacki]

Am I doing something wrong again?
I'm working hard on this and not just firing off questions.

Number has to return a flag as well and this flag also happens to be the number of digits that it managed to convert, zero meaning it's not a number.
In your case it said it had 4 digits.

num$ 1+ NUMBER ok
.S Data Stack (02)
$0000.0004 - 4
$0000.0F9F - 3999 ok

BTW, NUMBER will be modified to handle normal strings but even the GETWORD string is still a normal null terminated string, it's just that it also happens to have the count preceding the address of the string, just as we faked with num$ 1+ NUMBER

[artkennedy]

I was going by this from the Introduction to Tachyon:

"Typically strings are terminated with a null character which is universally accepted as a $00.
Tachyon follows this method for terminating strings rather than the normal Forth method of preceding it with a count byte."

But I now see from your reply and the source that is not the case for the NUMBER word:

_NUMBER    ' ( cstr -- value digits | false )

I followed the link you provided to the suggested NUMBER workaround.
I include it here with comments I have added as I understand the way it works.

\ Create a string variable to hold the longest number (binary with separators)
" 1234" #40 STRING num$
pub STR>NUM ( str -- num digits | false )
    num$ 1+ $!            \ input string copied to num$ beginning at second byte
    num$ 1+ LEN$ num$ C!  \ length of string stored in first byte of num$
    num$ 1+ NUMBER        \ string submitted to NUMBER
    ;

Did I get that right?


It does not seem to work:

FORGET num$  ok
" 1234" #40 STRING num$  ok
pub STR>NUM
    num$ 1+ $!
    num$ 1+ LEN$ num$ C!
    num$ 1+ NUMBER
    ;  ok
" 399.9" STR>NUM . 4 ok
num$ $10 DUMP
0000_3390:   05 33 39 39  2E 39 00 20   63 74 17 B8  C7 06 74 16   .399.9. ct....t. ok

Am I doing something wrong again?
I'm working hard on this and not just firing off questions.

[Peter Jakacki]

What I do wrong daddy?

[code]dmmbuf 10 DUMP
0000_3364: 44 43 20 31 32 33 2E 34 00 75 41 00 00 00 00 00 DC 123.4.uA.....
dmmbuf 3 + NUMBER . 0 ok
dmmbuf 3 + PRINT$ 123.4 ok;[\code]

Also what wrong with BBcode??

. . . sigh . . .

I thought we answered that question a few weeks ago but it's due to NUMBER expecting a string with a preceding count as in the case of GETWORD. However as I mentioned I may change NUMBER to handle a normal string but there is a workaround that involves copying the string to another string and inserting a count.

If you click the "Go Advanced" button you can select a block of text and click the # symbol enclose it in code tags or you can do it manually but you need to use forward slash /, not back slash \.

some sample code

[Peter Jakacki]

I have posted a TACHYON based robot control language in the Robotics forum. I include the RCL Core here for comment.

pub  BOEPAB.fth   ." TACHYON Robot Control for BOE Platform & Prop Activity Board "   ;

{
 Motor drivers and utilities.
}

#P12 2 MASKS  ==  pwmpins

#1495 #80 * == ld0  \ sets zero position of left servo

#1504 #80 * == rd0  \ sets zero position of right servo

LONG lduty, rduty

pub .duty ( -- ) \ displays current right & left duties
    lduty @ . SPACE rduty @ . CR ;

pub M1 ( duty -- ) \ sets left servo duty: -1000 - 1000
  #10 * ld0 + lduty !  ;
    
pub M2 ( duty -- ) \ sets right servo duty: -1000 - 1000
  NEGATE #10 * rd0 + rduty !  ;

pub S ( -- ) \ abruptly stops bot motion 
    0 M1  0 M2  ;

pub D1 ( -- )  \ toggles left wheel direction
    lduty @ ld0 - NEGATE ld0 + lduty ! ;

pub D2 ( -- )  \ toggles right wheel direction
    rduty @ rd0 - NEGATE rd0 + rduty ! ;

pri rc_motors ( -- ) \ left and right servo pwm drivers
    pwmpins OUTCLR  S
    A NCO #P12 APIN  1 FRQ 0 PHSA COG!
    B NCO #P13 APIN  1 FRQ 0 PHSB COG!    
    BEGIN
      lduty @ NEGATE PHSA COG!
      rduty @ NEGATE PHSB COG!

      20 ms
    0 UNTIL  ;

pub MSTART  ( -- ) \ executes servo drivers in a cog
    ' rc_motors TASK? RUN  50 ms  ;

 
      
{
  Encoders record current total counts per wheel. 
}

#P14  2 MASKS  ==  encpins

LONG lenc, renc, xl, xr

pub .enc ( -- ) \ lists current  encoder counter values
    lenc @  . SPACE  renc @ . CR ;

pub zenc ( -- ) \ set left and right encoder counters to 0
    0 lenc !  0 renc !  ;

pri rc_enc ( -- ) \ simple encoder drivers based on basic stamp boebot program
    TRUE xl ! TRUE xr !  encpins INPUTS  zenc 
    BEGIN
      #P14 PIN@ DUP xl @ = IF DROP ELSE xl ! lenc ++  THEN
      #P15 PIN@ DUP xr @ = IF DROP ELSE xr ! renc ++  THEN
    0 UNTIL ; 
 
pub ESTART  ( -- ) \ executes encoder drivers in a cog
     ' rc_enc TASK? RUN 50 ms ; 

{
 Ping ultrasonic distance measurement (inches).
}

#1400 == p0   \ sets standard servo 0 position
#8 == dist?   \ sets ping stop condition in inches

LONG (dist), pos

pub !pos  ( angle -- ) \ where angle is -90 - 90 degrees (right to left)
   #10 * p0 + #80 * pos !  ;

pub dist ( -- value ) \ places current ping value (inches) on stack
    (dist) @ ;

pub .dist ( -- ) \ displaces current ping value (inches)
    dist . CR  ;

BYTE (stp)  \ stores stop flag

pub restp ( -- ) \ resets stop flag to TRUE
    TRUE (stp) C!  ;

pub stp ( -- flag ) \ places stop flag on stack
    (stp) C@  ;

pri rc_ping ( -- ) \ ping driver - automatic stop condition 
   #P17 PINCLR 0 !pos
   B #P17 APIN  NCO  1 FRQ
   A 1 FRQ
   BEGIN
     #P16 PINCLR
     A #P16 APIN NCO #400 NEGATE PHSA COG!
       #1000 CTRMODE 0 PHSA COG! #P16 PININP
     pos @ NEGATE PHSB COG!
     50 ms
     PHSA COG@ #11800 / DUP (dist) !
     dist? < stp  AND IF
        FALSE (stp) C! S THEN 
   0 UNTIL  ;
  

: PSTART  ( -- ) \ executes ping driver in a cog
   restp ' rc_ping TASK? RUN 50 ms ;

{
  User parameters.
}


\ user constants - 2.625 inch wheel diameter  4.312 inch between wheels

   #8   ==   wcirc   \ wheel circumference in inches
 
  #64   ==   counts  \ number of counts per wheel rotation

   #8   ==   ctin    \ counts per inch
 
 #136   ==   rcirc  \ rotation circumfirence in 0.1 inch units

 #271   ==   tcirc  \ turn circumfirence in 0.1 inches

pub R  ( -- )  \ hardware reset - execute START to continue
    #P9 PINCLR  ;

pub START
    MSTART  ESTART  PSTART  DECIMAL ;



{
********************************************************************************
This completes the RCL Core.    

Simple (indefinite) motion commands, which use indexed tables to select duties.
}

NickL

Hi Nick, I must have missed a few posts there back in January, I've just come across a couple of yours including the helpful tip for the Forfiter terminal too, thanks.

I'm wondering whether the 32 channel PWM can be adapted to RC servo control simply by introducing a 20ms frame WAITCNT after every 256 cycles and adding in a 1ms minimum pulse. That would mean the PWM module could be used for either then.

Your coding style looks good but I noticed in your code that you are using a 0 UNTIL rather than simply saying AGAIN. Also you have a delay of 50ms after each RUN which btw does not require a coginit as it's ready and waiting for a task to execute, but I guess you might be waiting for other things to settle.

There are also many Spin-like shortcuts like ~ and ~~ to clear and set a variable rather then 0 variable ! you would just say variable ~

Look forward to seeing more code from you. If you like I can include you modules on the links page.

[artkennedy]

What I do wrong daddy?

[code]dmmbuf 10 DUMP
0000_3364: 44 43 20 31 32 33 2E 34 00 75 41 00 00 00 00 00 DC 123.4.uA.....
dmmbuf 3 + NUMBER . 0 ok
dmmbuf 3 + PRINT$ 123.4 ok;[\code]

Also what wrong with BBcode??

. . . sigh . . .

[Peter Jakacki]

Okaaay, I was thinking that the Useage note that I copied from EXTEND.FTH seemed to disagree with the parameter field above. Should have tried that. Thanks.

BTW, there are several aliases for certain dot words where I find the dot is not very distinct as a character in formatted source code so I have used the word PRINT instead. So therefore .STR is also PRINT$ and the dot itself is also PRINT etc and this is what you will see in many source code documents.

I will check my usage notes to make sure they are correct.

[artkennedy]

Okaaay, I was thinking that the Useage note that I copied from EXTEND.FTH seemed to disagree with the parameter field above. Should have tried that. Thanks.

[Peter Jakacki]

I am back from some time off for a trip and another urgent task.

I have researched BBCode now that I know what it is and will be trying it out.

The use of a defining word within another word was not too bright. I am recently back to Forth after about 35 years off. Thanks for straightening me out on that.

In combing the source I found .STR and decided to try it out. So I clipped the example code:

$20 " This is a string." STRING A$  ok
A$ 20 DUMP
0000_33D8:   00 00 53 20  08 08 08 08   08 54 68 69  73 20 69 73   ..S .....This is
0000_33E8:   20 61 20 73  74 72 69 6E   67 2E 00 06  06 20 00 06    a string.... .. ok
A$ 9 + .STR This is a string. ok

I'm wondering why the string is offset 9 bytes from its address.

I'm also wondering if the BBcode above will work the way I intend. 'nyuk nyuk - I guess it did.

Oh, is that where you've been, I thought that all that tackling dialects of Forth had sent you off into cuckoo land! Now that you've been released you are coming back for some more punishment!

Okay, to make it easy for you the STRING word takes a string and a maximum size as arguments but it's in this format:
" MY STRING" 0 STRING A$
So it's string,count, not count,string and the 0 just sets the maximum size to the current string length. Specify another size if this string is meant to be rewritten and it may need more room.

[artkennedy]

I am back from some time off for a trip and another urgent task.

I have researched BBCode now that I know what it is and will be trying it out.

The use of a defining word within another word was not too bright. I am recently back to Forth after about 35 years off. Thanks for straightening me out on that.

In combing the source I found .STR and decided to try it out. So I clipped the example code:

$20 " This is a string." STRING A$  ok
A$ 20 DUMP
0000_33D8:   00 00 53 20  08 08 08 08   08 54 68 69  73 20 69 73   ..S .....This is
0000_33E8:   20 61 20 73  74 72 69 6E   67 2E 00 06  06 20 00 06    a string.... .. ok
A$ 9 + .STR This is a string. ok

I'm wondering why the string is offset 9 bytes from its address.

I'm also wondering if the BBcode above will work the way I intend. 'nyuk nyuk - I guess it did.

[D.P]

Hey David I meant what I said!!! I think you are really talented, I've followed your work here! No dig at all just saying it's probably the code that's all!

[Peter Jakacki]

Okay, I'll stop trying to have a reasonable conversation. Not possible on these forums I guess.

Hi Dave, we respect your opinions and I didn't read DPs post as having a dig at you, he just simply acknowledged your considerable talent but also acknowledged that the xbee is not very fast. Now that DP is an expert on WIZnet then maybe we can get him to do some debugging

[David Betz]

Try and only write to the buffer when it's empty then. I know you're very talented but I bet it's your implementation, xbee is a solid little gadget but may not be very fast.

Okay, I'll stop trying to have a reasonable conversation. Not possible on these forums I guess.

[D.P]

Try and only write to the buffer when it's empty then. I know you're very talented but I bet it's your implementation, xbee is a solid little gadget but may not be very fast.

[David Betz]

I have not had any issues using either the spin/pasm drivers or Tachyon with the W5200 chips.

That's good to know. Maybe I should try that chip but I'd kind of like to have Wi-Fi capability.

[D.P]

Thanks! I've played with the Xbee Wi-Fi module some and it doesn't seem to handle TCP/IP flow control well. You have to pace data being sent to it or it gets thrown away if the internal buffer overflows. Does the WizNet chip have this problem? I think the buffer size on the Xbee is < 2K bytes.

I have not had any issues using either the spin/pasm drivers or Tachyon with the W5200 chips.

[Peter Jakacki]

This speed is quite impressive but I'm not sure how useful it is as a benchmark when it uses the iterative algorithm. Maybe we should find some other function/word calling benchmark that won't overflow Tachyon's COG-based stack for a better comparison. How many programs really do nothing but sit in a small loop?

Exactly how I feel too, but I am using the benchmark as a way of comparing and improving TF against itself. But of course as DP pointed out, it can do it inside a TF Telnet session while writing to a file! So it's not just a benchmark which btw also means when a compiler uses a recursive algorithm it doesn't prove whether it can do the job either.

One of the improvements I made was with looping, this is already fast and has the loop address held in a cog stack so that it doesn't have to read a displacement from hub ram each loop (conventional Forth) which slows things down. However in addition I created a REPS instruction from the extra longs that kuroneko gleaned so that it caches the instruction we want repeated, so each loop runs a cached instruction and in the case of the iterative fibo that takes IIRC 200ns/loop. So the REPS instruction even at this stage has also come in handy for instructions such as SPIWRB instruction etc in cutting down the low overhead even further.

The other thing I changed was putting in a check on the data stack to see if it really needed to access the hub or not so that when the stack depth is less than 5 it is not being slowed down by hub accesses. But these are techniques made possible by all these extra longs that kuroneko manages to squeeze out and in the process I've learned some neat tricks like unconventional jmpret's and even just sumc has proved useful. Even jumping via the address field of a return rather than jumping to the return instruction itself saves cycles.

Internally I have changed the hard coded jmp #doNEXT with a jmp unext so that I can make the VM instructions return where I want as in the case of REPS but also good for debugging purposes.

I had a 32 channel 8-bit PWM module that ran up to 5kHz or so and kuroneko wrote a version that runs up to 7.6kHz and still fitted in the module limits of 18 longs.

Next step is having modules and cogs loaded from an object repository in upper 64kB EEPROM at runtime, just select the objects you want and run, this also includes the F32 floating point object.

So yeah, having a challenge is a good thing if it leads to not a cause for boasting but to self-improvement (code-wise) that benefits many while having fun.

[David Betz]

The wiznet 5500 is a hardware/ethernet based IP stack with 8 sockets. The Xbee 802.11n wi-if and has at max 2 sockets:

"API mode
When the UART is configured for API mode using the ATAP command the module will open two listening sockets,
one for each IP type (UDP and TCP) "

So while not as robust as the Wiznet socket wise, it is 802.11n and does have security! (WPA-PSK,WPA2-PSK and WEP) Cool chip.

ftp://ftp1.digi.com/support/temp/XBe...ation_BETA.pdf

It has a 6Mb SPI and 1Mb UART interface. I'm sure a driver for Tachyon could be made and if I needed wi-fi I would begin one and post it here for Peter et al to help me structure correctly, being more of an art than engineering it seems sometimes with my limited experience in Tachyon/FORTH.

The Tachyon Wiznet stuff is in exactly two small-ish FORTH files. W5200.fth and NETWORK.fth, serious idea compression inside, fair warning.

Thanks! I've played with the Xbee Wi-Fi module some and it doesn't seem to handle TCP/IP flow control well. You have to pace data being sent to it or it gets thrown away if the internal buffer overflows. Does the WizNet chip have this problem? I think the buffer size on the Xbee is < 2K bytes.

[D.P]

Actually, since you mention Telnet, FTP, and web server, I was wondering if that network support would work with the Xbee Wi-Fi module that Parallax now sells? I assume Tachyon currently uses a WizNet chip?

The wiznet 5500 is a hardware/ethernet based IP stack with 8 sockets. The Xbee 802.11n wi-if and has at max 2 sockets:

"API mode
When the UART is configured for API mode using the ATAP command the module will open two listening sockets,
one for each IP type (UDP and TCP) "

So while not as robust as the Wiznet socket wise, it is 802.11n and does have security! (WPA-PSK,WPA2-PSK and WEP) Cool chip.

ftp://ftp1.digi.com/support/temp/XBe...ation_BETA.pdf

It has a 6Mb SPI and 1Mb UART interface. I'm sure a driver for Tachyon could be made and if I needed wi-fi I would begin one and post it here for Peter et al to help me structure correctly, being more of an art than engineering it seems sometimes with my limited experience in Tachyon/FORTH.

The Tachyon Wiznet stuff is in exactly two small-ish FORTH files. W5200.fth and NETWORK.fth, serious idea compression inside, fair warning.

[David Betz]

Actually, since you mention Telnet, FTP, and web server, I was wondering if that network support would work with the Xbee Wi-Fi module that Parallax now sells? I assume Tachyon currently uses a WizNet chip?

[David Betz]

Well then how about the functional program just described? Telnet session, program a fibo routine, execute it, have it save its results to SD, read the results back from SD and transmit them via Telnet back in one cog. You may say that's not fair and you are right, FORTH is not fair, it's a lean and mean threaded interpretive language and should not be compared with anything else. It has been expertly ported onto the Prop architecture via the Tachyon VM. Use the tools that make you most productive no matter what they are! I sure don't care what tools people use, Tachyon is just an option.

Save us all now that Kuroneko is casting his gaze upon the assembler with Peter and F32 is about to be cast into the VM.

You win that benchmark because there is currently no way to do Telnet with PropGCC. Congratulations.

[D.P]

Yes, I know the GCC program was also iterative. I'm not sure that the GCC version is a very useful benchmark either. For evaluating Tachyon, I think something other than fibo is required.

Well then how about the functional program just described? Telnet session, program a fibo routine, execute it, have it save its results to SD, read the results back from SD and transmit them via Telnet back in one cog. You may say that's not fair and you are right, FORTH is not fair, it's a lean and mean threaded interpretive language and should not be compared with anything else. It has been expertly ported onto the Prop architecture via the Tachyon VM. Use the tools that make you most productive no matter what they are! I sure don't care what tools people use, Tachyon is just an option.

Save us all now that Kuroneko is casting his gaze upon the assembler with Peter and F32 is about to be cast into the VM.

[D.P]

Getting a compile error here:

TABLE fred $09B0 ALLOT

fred HEXLOAD

:100000001B5B34306D1B5B324A1B5B3134431B5B23        \ <---- first line throws an error
.
.
.
.

Something is whack in this syntax, no space after colon operator not sure what you mean. HEXLOAD is a new word for me.

[David Betz]

The GCC test program referred to was iterative as well. Let's just leave the speed stuff alone okay. Now how about executing this fibo via a telnet session, writing the results to SD, reading the results back from SD and transmitting them back via telnet, in one cog. That's the real benchmark for usefulness I think.

Yes, I know the GCC program was also iterative. I'm not sure that the GCC version is a very useful benchmark either. For evaluating Tachyon, I think something other than fibo is required.

[D.P]

This speed is quite impressive but I'm not sure how useful it is as a benchmark when it uses the iterative algorithm. Maybe we should find some other function/word calling benchmark that won't overflow Tachyon's COG-based stack for a better comparison. How many programs really do nothing but sit in a small loop?

The GCC test program referred to was iterative as well. Let's just leave the speed stuff alone okay. Now how about executing this fibo via a telnet session, writing the results to SD, reading the results back from SD and transmitting them back via telnet, in one cog. That's the real benchmark for usefulness I think.

[David Betz]

Anyone who is using TeraTerm or Hyperterminal can compile the latest kernel and EXTEND.fth and my avatar should appear on boot. My minicom doesn't handle these characters properly but I still need to fully activate the automatic terminal test software so that it only displays on compatible terminals.

Here are some of the latest fibonacci results:

fibo(2) = 6us result =1
fibo(3) = 6us result =2

fibo(23) = 12us result =28657
fibo(24) = 13us result =46368
fibo(25) = 13us result =75025
fibo(26) = 13us result =121393

fibo(46) = 19us result =1836311903 ok

This speed is quite impressive but I'm not sure how useful it is as a benchmark when it uses the iterative algorithm. Maybe we should find some other function/word calling benchmark that won't overflow Tachyon's COG-based stack for a better comparison. How many programs really do nothing but sit in a small loop?

[D.P]

Anyone who is using TeraTerm or Hyperterminal can compile the latest kernel and EXTEND.fth and my avatar should appear on boot. My minicom doesn't handle these characters properly but I still need to fully activate the automatic terminal test software so that it only displays on compatible terminals.

Here are some of the latest fibonacci results:

fibo(2) = 6us result =1
fibo(3) = 6us result =2

fibo(23) = 12us result =28657
fibo(24) = 13us result =46368
fibo(25) = 13us result =75025
fibo(26) = 13us result =121393

fibo(46) = 19us result =1836311903 ok

No comment on the speed 13-6, I'm laying low and avoiding the radar, but the last pillar just fell, did it make any noise? Gonna build the new kernel and fire up teraterm now, seeing how I usually use minicom.

[Peter Jakacki]

Good come back Mike, hi5!

My avatar was taken from an ANSI graphics that I would display on compatible terminals, such as TeraTerm, even Hyperterminal. I will post a special edition of EXTEND.fth which will test to see if the terminal is compatible and then display my avatar on boot. In fact I can even test the terminal's baud rate settings etc to automatically adapt.

Anyone who is using TeraTerm or Hyperterminal can compile the latest kernel and EXTEND.fth and my avatar should appear on boot. My minicom doesn't handle these characters properly but I still need to fully activate the automatic terminal test software so that it only displays on compatible terminals.

Here are some of the latest fibonacci results:

fibo(2) = 6us result =1
fibo(3) = 6us result =2

fibo(23) = 12us result =28657
fibo(24) = 13us result =46368
fibo(25) = 13us result =75025
fibo(26) = 13us result =121393

fibo(46) = 19us result =1836311903 ok

[Peter Jakacki]

You got me curious ... how to display your Avatar on a serial terminal? Or did you mean to display "yabba dabba doo"?

I do use different languages also, my last fulltime Cobol Job was somewhere at the end of the last century. Over the years I needed usually to change the Language when changing the Job. But say switching from VB.net to C#.net is not a really big task, the framework stays the same, just the syntax varies a bit. Things like C might be no big thing either - I hadn't had the need for yet. Since a couple of weeks I use JavaScript since @Heater talked me into it, but all of those languages are very alike in the way they handle stuff. Forth is quite different.

As to my Avatar ... that picture was probably taken while I was trying to understand FORTH.

Enjoy!

Mike

Good come back Mike, hi5!

My avatar was taken from an ANSI graphics that I would display on compatible terminals, such as TeraTerm, even Hyperterminal. I will post a special edition of EXTEND.fth which will test to see if the terminal is compatible and then display my avatar on boot. In fact I can even test the terminal's baud rate settings etc to automatically adapt.

EDIT: Didn't want to make a new post but I shaved a few more microseconds from my fibo, still going for more:
fibo(22) = 12us result =17711
fibo(23) = 12us result =28657
fibo(24) = 13us result =46368
fibo(25) = 13us result =75025
fibo(26) = 13us result =121393
and
fibo(46) = 19us result =1836311903 ok

kuroneko has written fibo in PASM and gets 3.6us for fibo(46)

[D.P]

You got me curious ... how to display your Avatar on a serial terminal? Or did you mean to display "yabba dabba doo"?

I do use different languages also, my last fulltime Cobol Job was somewhere at the end of the last century. Over the years I needed usually to change the Language when changing the Job. But say switching from VB.net to C#.net is not a really big task, the framework stays the same, just the syntax varies a bit. Things like C might be no big thing either - I hadn't had the need for yet. Since a couple of weeks I use JavaScript since @Heater talked me into it, but all of those languages are very alike in the way they handle stuff. Forth is quite different.

As to my Avatar ... that picture was probably taken while I was trying to understand FORTH.

Enjoy!

Mike

It was incredibly hard for me at first. Now it's fun. Hairless monkeys hate "to change", confirmation bias and peer packing can ruin the mind.

[msrobots]

Ah,... Whereas my avatar (which btw is reproducible on the serial terminal -prop) is going yabba dabba doo!

You got me curious ... how to display your Avatar on a serial terminal? Or did you mean to display "yabba dabba doo"?

I do use different languages also, my last fulltime Cobol Job was somewhere at the end of the last century. Over the years I needed usually to change the Language when changing the Job. But say switching from VB.net to C#.net is not a really big task, the framework stays the same, just the syntax varies a bit. Things like C might be no big thing either - I hadn't had the need for yet. Since a couple of weeks I use JavaScript since @Heater talked me into it, but all of those languages are very alike in the way they handle stuff. Forth is quite different.

As to my Avatar ... that picture was probably taken while I was trying to understand FORTH.

Enjoy!

Mike

[Peter Jakacki]

OK.

17-9=8. Did not look at it this way. Sad that me and forth do not get along. Seems my brain is indoctrinated by non prefix languages. I tried but cant wrap my head around it.

Enjoy!

Mike

Ah, I see Mike, you can't wrap your head around it, but I see from your avatar that perhaps your head's bin rappin' da PC C.
It's so much more fun that way hey? Whereas my avatar (which btw is reproducible on the serial terminal -prop) is going yabba dabba doo!

My first languages were "machine code", assembler, Basic, even Fortran, then C, with my introduction to Forth in there somewhere.

[msrobots]

OK.

17-9=8. Did not look at it this way. Sad that me and forth do not get along. Seems my brain is indoctrinated by non prefix languages. I tried but cant wrap my head around it.

Enjoy!

Mike

[D.P]

As generally I am impressed with TF. Even if reading Forth code is as useful for me as reading spin-binary's in HEX.

But 7 code bytes IS impressive. What I am missing here is D.P.'s excitement over the speed. Heaters Fibo in compiled C finishes 26 iteration before TF does ONE?

Enjoy!

Mike

One (GCC) is a compiled to benchmark one off program, does nothing more.
The other is able to run along side FTP, HTTP, TELNET, SD CARD and console access in ONE cog! I thought that the TF fibo just being 9 us slower than the almighty GCC was fantastic, but now I understand it runs at the same speed. Do you understand?

[Peter Jakacki]

As generally I am impressed with TF. Even if reading Forth code is as useful for me as reading spin-binary's in HEX.

But 7 code bytes IS impressive. What I am missing here is D.P.'s excitement over the speed. Heaters Fibo in compiled C finishes 26 iteration before TF does ONE?

Enjoy!

Mike

What's also very interesting is the loop time, if we look at the difference in timing between 1 and 26 iterations it is 17-9 for TF which is of course 8us vs GCC's 8us, the same! So not having the cog dedicated to a benchmark means the other 9us is spent in TF coming from doing something useful, calling the function, stacking the parameters, unstacking, and returning back to something useful again up to 17us later. Oh well.....

EDIT: just thinking about this abysmal 17us to run a fibo(26), I think Spin could almost run one and a half bytecode instructions in this same amount of time!

[msrobots]

As generally I am impressed with TF. Even if reading Forth code is as useful for me as reading spin-binary's in HEX.

But 7 code bytes IS impressive. What I am missing here is D.P.'s excitement over the speed. Heaters Fibo in compiled C finishes 26 iteration before TF does ONE?

Enjoy!

Mike

[D.P]

So just a few days ago I managed to get 36us for 26 iterations of the fibonacci sequence. Now I have added some more instructions and some bytecode magic.... the fibo routine takes just 7 code bytes and runs how fast?

DECIMAL ok
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo .LAP ." result =" . LOOP
fibo(1) = 9us result =1
fibo(2) = 10us result =1
fibo(3) = 10us result =2
fibo(4) = 10us result =3
fibo(5) = 10us result =5
fibo(6) = 11us result =8
fibo(7) = 11us result =13
fibo(8) = 11us result =21
fibo(9) = 12us result =34
fibo(10) = 12us result =55
fibo(11) = 12us result =89
fibo(12) = 13us result =144
fibo(13) = 13us result =233
fibo(14) = 13us result =377
fibo(15) = 13us result =610
fibo(16) = 14us result =987
fibo(17) = 14us result =1597
fibo(18) = 14us result =2584
fibo(19) = 15us result =4181
fibo(20) = 15us result =6765
fibo(21) = 15us result =10946
fibo(22) = 16us result =17711
fibo(23) = 16us result =28657
fibo(24) = 16us result =46368
fibo(25) = 16us result =75025
fibo(26) = 17us result =121393 ok

Here's the iterative results from Heater's GCC LMM code.
I'm happy to have this speed without the need for C. And so much more!

fibo( 1) =      1 (  24 ticks) (0us)
fibo( 2) =      1 (  20 ticks) (0us)
fibo( 3) =      2 (  68 ticks) (0us)
fibo( 4) =      3 (  84 ticks) (1us)
fibo( 5) =      5 ( 116 ticks) (1us)
fibo( 6) =      8 ( 148 ticks) (1us)
fibo( 7) =     13 ( 180 ticks) (2us)
fibo( 8) =     21 ( 196 ticks) (2us)
fibo( 9) =     34 ( 228 ticks) (2us)
fibo(10) =     55 ( 260 ticks) (3us)
fibo(11) =     89 ( 292 ticks) (3us)
fibo(12) =    144 ( 308 ticks) (3us)
fibo(13) =    233 ( 340 ticks) (4us)
fibo(14) =    377 ( 372 ticks) (4us)
fibo(15) =    610 ( 404 ticks) (5us)
fibo(16) =    987 ( 420 ticks) (5us)
fibo(17) =   1597 ( 452 ticks) (5us)
fibo(18) =   2584 ( 484 ticks) (6us)
fibo(19) =   4181 ( 516 ticks) (6us)
fibo(20) =   6765 ( 532 ticks) (6us)
fibo(21) =  10946 ( 564 ticks) (7us)
fibo(22) =  17711 ( 596 ticks) (7us)
fibo(23) =  28657 ( 628 ticks) (7us)
fibo(24) =  46368 ( 644 ticks) (8us)
fibo(25) =  75025 ( 676 ticks) (8us)
fibo(26) = 121393 ( 708 ticks) (8us)

[mindrobots]

Gee, you only cut it in half??

Wow!!

[Peter Jakacki]

So just a few days ago I managed to get 36us for 26 iterations of the fibonacci sequence. Now I have added some more instructions and some bytecode magic.... the fibo routine takes just 7 code bytes and runs how fast?

DECIMAL ok
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo .LAP ." result =" . LOOP
fibo(1) = 9us result =1
fibo(2) = 10us result =1
fibo(3) = 10us result =2
fibo(4) = 10us result =3
fibo(5) = 10us result =5
fibo(6) = 11us result =8
fibo(7) = 11us result =13
fibo(8) = 11us result =21
fibo(9) = 12us result =34
fibo(10) = 12us result =55
fibo(11) = 12us result =89
fibo(12) = 13us result =144
fibo(13) = 13us result =233
fibo(14) = 13us result =377
fibo(15) = 13us result =610
fibo(16) = 14us result =987
fibo(17) = 14us result =1597
fibo(18) = 14us result =2584
fibo(19) = 15us result =4181
fibo(20) = 15us result =6765
fibo(21) = 15us result =10946
fibo(22) = 16us result =17711
fibo(23) = 16us result =28657
fibo(24) = 16us result =46368
fibo(25) = 16us result =75025
fibo(26) = 17us result =121393 ok

[Peter Jakacki]

Just sorted through some problems on my side with kuroneko and then fired up his version of PWM32 and now that runs up to 6.940kHz. no make that 7.6kHz
Controlling individual pins or groups of pins is easy and of course you can always create your methods like these
75 % 2 SETPWM ( set P2 to 75% duty)
or
32 16 8 SETPWMS ( set P16..P23 to 32/256 duty cycle)
or you might like to specify the range like Spin in which case we could modify SETPWMS
32 16 23 SETPWMS
etc
These methods calculate the entries in a 1K byte table for all 256 samples of 32 channels which the PWM cog just reads from. So it's also possible to put arbitrary waveforms in the table too or even higher frequencies with less resolution, for instance if I set the channel bit in each alternate long I would have a 6.94kHz * 128 or 888.32kHz square wave on that pin (now 972.8kHz)

As mentioned earlier these PWM outputs are table based and jitter free.

7.6kHz 25% waveform

[D.P]

Kuroneko has been helping out today with tweaking some of the PASM code which has freed up a handful of longs, and also the 8 channel PWM. So that's prompted me to tidy up some other stuff too and also fully implement and test the 32 channel PWM. These outputs are jitter free as best as they can be measured, there is a scope trace in the kernel source document you can look at but what I did was zoom in to 25ns/div at 50 ms after the trigger and leave the scope on infinite persistence. There was no jitter at all even though you can see the hairy rise time etc and the only thing that crept in was about 10ns of drift over 10 minutes or more, but no jitter, just rock steady. The reason for 32 channels is so that you can make any and as many pins as you like a PWM output
You need 256 longs for a table that can be used to store all the calculated duty cycles for 32 channels over 256 samples (8-bit). The init code looks like this:

TABLE pwms #1024 ALLOT    \ allocate a 256 longs table for the PWM map    

#5000 PWMFREQ        \ Set the frequecy
    
\ Start up PWM using from P0..7, P16..P23 for 16 channels    
$FF00FF pwms RUNPWM32        

#50 % 2 MASK PWM32!    \ set P2 to 50 % duty
#25 % $0F0000 PWM32!    \ set P16..P19 to 25 % duty

Attachment 107233


The signed divide also runs faster from 47us down to 18us whereas the unsigned divide U/ takes 10us. The multiply ops take around 4 or 5 us.

Don't forget there's the serial LCD rolling odometer demo too.

uh WOW comes to mind,

Notice the online kernel has 5 MHz crytal settings now.

Looks good here.

00:00:00  End of source code, 2926 lines processed and 0000 errors found 
Load time = 5,841ms

 Propeller .:.:--TACHYON--:.:. Forth V23140228.0000

NAMES:  $5D99...7488 for 5871 (3288 bytes added)
CODE:   $0000...315D for 6766 (6429 bytes added)
CALLS:  0497 vectors free
RAM:    11324 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 140227-1430

[Peter Jakacki]

Kuroneko has been helping out today with tweaking some of the PASM code which has freed up a handful of longs, and also the 8 channel PWM. So that's prompted me to tidy up some other stuff too and also fully implement and test the 32 channel PWM. These outputs are jitter free as best as they can be measured, there is a scope trace in the kernel source document you can look at but what I did was zoom in to 25ns/div at 50 ms after the trigger and leave the scope on infinite persistence. There was no jitter at all even though you can see the hairy rise time etc and the only thing that crept in was about 10ns of drift over 10 minutes or more, but no jitter, just rock steady. The reason for 32 channels is so that you can make any and as many pins as you like a PWM output
You need 256 longs for a table that can be used to store all the calculated duty cycles for 32 channels over 256 samples (8-bit). The init code looks like this:

TABLE pwms #1024 ALLOT    \ allocate a 256 longs table for the PWM map    

#5000 PWMFREQ        \ Set the frequecy
    
\ Start up PWM using from P0..7, P16..P23 for 16 channels    
$FF00FF pwms RUNPWM32        

#50 % 2 MASK PWM32!    \ set P2 to 50 % duty
#25 % $0F0000 PWM32!    \ set P16..P19 to 25 % duty

The signed divide also runs faster from 47us down to 18us whereas the unsigned divide U/ takes 10us. The multiply ops take around 4 or 5 us.

Don't forget there's the serial LCD rolling odometer demo too.

[D.P]

I added a new instruction to the PASM kernel that takes just one extra long and now I run the Fibonacci benchmark with much faster results. I might never use the new instruction in anything else but then again I might. It just replaces the OVER + SWAP operation and since it only added one extra long in the kernel I thought why not.

DECIMAL ok
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo .LAP ." result =" . LOOP
fibo(1) = 11us result =1
fibo(2) = 12us result =1
fibo(3) = 13us result =2
fibo(4) = 14us result =3
fibo(5) = 15us result =5
fibo(6) = 16us result =8
fibo(7) = 17us result =13
fibo(8) = 18us result =21
fibo(9) = 19us result =34
fibo(10) = 20us result =55
fibo(11) = 21us result =89
fibo(12) = 22us result =144
fibo(13) = 23us result =233
fibo(14) = 24us result =377
fibo(15) = 25us result =610
fibo(16) = 26us result =987
fibo(17) = 27us result =1597
fibo(18) = 28us result =2584
fibo(19) = 29us result =4181
fibo(20) = 30us result =6765
fibo(21) = 31us result =10946
fibo(22) = 32us result =17711
fibo(23) = 33us result =28657
fibo(24) = 34us result =46368
fibo(25) = 35us result =75025
fibo(26) = 36us result =121393 ok

Based on the previous results I would say 1 long went a long way. As far as the F32 "hack" (the optimal way to connect a rotary phone switch to cause the best track switching to occur with the least fuss, "tech model railroad club") I can't wait to start using it. I agree with max72 it would be nice to be able to push our own "mods" this way but not necessary. I think F32 now gives Tachyon just about everything one could need. Telnet, FTP, HTTP, Sockets, Floating Point, Strings, RTC provisions, SD access, partial FAT16/32, I2C, SPI, ASync and best of all a console to rule them all! I was gathering UI needs from co-workers the other day and even they said "hey wait don't you have to go rebuild the software or something before you show us again" as I worked directly on the console as the equipment was running! Thanks Peter.

fibo(1) = 13us result =1                                                                                        
fibo(2) = 16us result =1                                                                                        
fibo(3) = 19us result =2                                                                                        
fibo(4) = 22us result =3                                                                                        
fibo(5) = 25us result =5                                                                                        
fibo(6) = 28us result =8                                                                                        
fibo(7) = 31us result =13                                                                                       
fibo(8) = 34us result =21                                                                                       
fibo(9) = 37us result =34                                                                                       
fibo(10) = 40us result =55                                                                                      
fibo(11) = 43us result =89                                                                                      
fibo(12) = 46us result =144                                                                                     
fibo(13) = 49us result =233                                                                                     
fibo(14) = 52us result =377                                                                                     
fibo(15) = 55us result =610                                                                                     
fibo(16) = 58us result =987                                                                                     
fibo(17) = 61us result =1597                                                                                    
fibo(18) = 64us result =2584                                                                                    
fibo(19) = 67us result =4181                                                                                    
fibo(20) = 70us result =6765                                                                                    
fibo(21) = 73us result =10946                                                                                   
fibo(22) = 76us result =17711                                                                                   
fibo(23) = 79us result =28657                                                                                   
fibo(24) = 82us result =46368                                                                                   
fibo(25) = 85us result =75025                                                                                   
fibo(26) = 88us result =121393 ok

[Peter Jakacki]

I added a new instruction to the PASM kernel that takes just one extra long and now I run the Fibonacci benchmark with much faster results. I might never use the new instruction in anything else but then again I might. It just replaces the OVER + SWAP operation and since it only added one extra long in the kernel I thought why not.

DECIMAL ok
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo .LAP ." result =" . LOOP
fibo(1) = 11us result =1
fibo(2) = 12us result =1
fibo(3) = 13us result =2
fibo(4) = 14us result =3
fibo(5) = 15us result =5
fibo(6) = 16us result =8
fibo(7) = 17us result =13
fibo(8) = 18us result =21
fibo(9) = 19us result =34
fibo(10) = 20us result =55
fibo(11) = 21us result =89
fibo(12) = 22us result =144
fibo(13) = 23us result =233
fibo(14) = 24us result =377
fibo(15) = 25us result =610
fibo(16) = 26us result =987
fibo(17) = 27us result =1597
fibo(18) = 28us result =2584
fibo(19) = 29us result =4181
fibo(20) = 30us result =6765
fibo(21) = 31us result =10946
fibo(22) = 32us result =17711
fibo(23) = 33us result =28657
fibo(24) = 34us result =46368
fibo(25) = 35us result =75025
fibo(26) = 36us result =121393 ok

[max72]

I think it is a great addition.
The 4 serial ports is a good candidate too, but probably the best would be to have a small how to in order to implement our object or add an existing one.
Tell me if I'm wrong, but after all the 2 main configurations are the coprocessor style (where the pasm cog waits for the arguments and executes one of the possible operations) and the silently running, where the pasm code is doing its work independently, and in case shares data in and out via a HUB array.
If we were able to create the code we could be able to speed up the obex translation, and also adding our own pasm modules.
Massimo

[Peter Jakacki]

I'm integrating floating point into TF but if I do this at compile time it adds another 2K to the memory footprint that while acceptable during evaluation stage is really wasteful when you start cramming in other modules and your application. What I am thinking of doing is specifying that the image of the floating point module and other modules reside in the top 32k of a 64kB EEPROM so that main hub memory is not lost. Normally a Prop loads a cog from an image in hub memory and that 2K or so area is normally waster afterwards. In the case of TF the hub memory area that held the TF cog image is reused at runtime for buffers, as is also the smaller receive cog image as it is reused for serial buffers. This is fine as when I do a backup of the TF system it bypasses these areas as it doesn't need to backup buffers which of course it shouldn't anyway as it needs to have the TF and serial images available at boot-time.

Anyhow, getting back to allowing TF to make efficient use of it's hub memory without imposing extra hardware on the system other than using a 64kB EEPROM instead of the normal 32kB, I need to have any additional cog images out of the way but readily accessible at boot time. The logical place for this is in the top 32kB of the 64kB EEPROM where a boot-time program can load the images that are required into cogs without messing with hub memory. Since coginit requires the image to be in hub ram I just load the EEPROM image into the 2K buffer area vacated by the TF image. This would allow me to be able to load the floating-point image as well as others such as VGA, serial, etc into cogs while TF is booting. Of course these images could also reside on SD instead but that may not be present while EEPROM always is.

Does that scheme sound acceptable? Are there other cog objects that you would like? In the case of floating point I just use the PASM from F32 as would be the case with serial, VGA etc.

BTW, the image is initially loaded into EEPROM in a similar manner to extending the kernel, except we load a hex file.

EDIT: in the case of a VGA/TV text driver I could compile and load the module normally as I could reuse the image ram for the display buffer. But the EEPROM scheme is more flexible.

EDIT: Rather than a pure hex file I could use the listing generated by BST and paste that into my TF module source, that's uncomplicated and readable, and TF could just filter out the code it needs to load into EEPROM. There's lot's of information in the listing, here's a sample:

|===========================================================================|
Object DAT Blocks
|===========================================================================|
0018(0000)             |                         org
0018(0000) F0 97 BF 0A | getCommand              rdlong  cmdPtr, par wz          ' wait for command
001C(0001) 00 00 68 5C |           if_z          jmp     #getCommand
0020(0002) CB 89 BF A1 |                         mov     t2, cmdPtr wc           ' load fnumA
0024(0003) C4 9D BF 08 |                         rdlong  fnumA, t2
0028(0004) 04 88 FF 80 |                         add     t2, #4

Have a look at what the hybrid source code document will look like, here's one here, it's unfinished but might work out.

[D.P]

While it is true that NUMBER will take a string from GETWORD and convert it, it does not appear to work with strings in general and this is simply because NUMBER is expecting a string with a preceding count as is used in GETWORD. It stills looks like a string, it's that it just happens to have the count of the string in the byte preceding it.

I may change the operation of NUMBER to work with strings in general but in the meantime this will work:

\ Create a string variable to hold the longest number (binary with separators)
" 1234" #40 STRING num$
pub STR>NUM ( str -- num digits | false )
    num$ 1+ $!
    num$ 1+ LEN$ num$ C!
    num$ 1+ NUMBER
    ;

This is what works for me

" "     #40 STRING buf$ 
pub STR>NUM ( str -- num digits | false ) 
    buf$ ERASE$ 
    buf$ 1+ $! 
    buf$ 1+ LEN$ buf$ C! 
    buf$ 1+ NUMBER 
    ; 
" $DEADBEEF" STR>NUM .S 
STACK: 0000.0000 0000.0000 DEAD.BEEF 0000.0008  ok

[Peter Jakacki]

NUMBER in my version doesn't seem to work according to the comments in the Tachyon V2.3 source regarding valid conversion forms. Else my syntax is wrong?

NUMBER ' ( str -- value digits | false )

Acceptable forms are:
$1000 hex number
1000h

#1000 decimal number
1000d

00 binary number
1000b

While it is true that NUMBER will take a string from GETWORD and convert it, it does not appear to work with strings in general and this is simply because NUMBER is expecting a string with a preceding count as is used in GETWORD. It stills looks like a string, it's that it just happens to have the count of the string in the byte preceding it.

I may change the operation of NUMBER to work with strings in general but in the meantime this will work:

\ Create a string variable to hold the longest number (binary with separators)
" 1234" #40 STRING num$
pub STR>NUM ( str -- num digits | false )
    num$ 1+ $!
    num$ 1+ LEN$ num$ C!
    num$ 1+ NUMBER
    ;

[D.P]

About the forum formating, it uses BBCode and you can enter this directly or press the ADVANCED button down the bottom right of the edit window and you get a whole lot of other options. So when you paste code into the window then select that section and click the # button which will enclose the text in code tags.

The STRING word is a defining word, that is it creates a new defintion and the rule is that you do not create new definitions inside another one, so logically these should be defined before .DMM . So STRING and FORGET etc are all defining words that execute immediately even during compile so no Forth ever expects to use them in the way that you have defined .DMM

Anyway, you are doing it the hard way, all the parsing and conversion is built into TF, don't assemble the whole line into a buffer just parse it word by word (direct key input) and use GETWORD DECIMAL NUMBER when you are expecting data from the DMM. The AC/DC part of the message would also be handled by a preceding GETWORD and storing that result in a string like this GETWORD dmm$ COPY$ etc.

I could write the code for you but it is simpler than you think so I will let you have a bit more of a play with TF. Of couse if you have to have it in a bufffer to parse just remember that NUMBER will parse a string but define that string just like any variable or constant, outside of another defintion.

EDIT: You would never say in any Forth
: MyTest 1234 CONSTANT mycon mycon . ;
But of course you do it like this:
1234 CONSTANT mycon
: MyTest mycon . ;
So STRING is similar to CONSTANT and VARIABLE and so on. Even if the first example compiled somehow what would happend each time you ran it is that it would create another new definition called mycon, after testing that ten times you would have 10 new "mycons" in the dictionary, clearly not what you would want to happen.

BTW, any use of the BACKUP word is normally safe, it skips those areas it would never want to overwrite in EEPROM.

NUMBER in my version doesn't seem to work according to the comments in the Tachyon V2.3 source regarding valid conversion forms. Else my syntax is wrong?

  Propeller .:.:--TACHYON--:.:. Forth V23140216.1600

NAMES:  $5DC9...74EF for 5926 (3412 bytes added)
CODE:   $0000...3352 for 7212 (6994 bytes added)
CALLS:  0482 vectors free
RAM:    10871 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140216-1400 
----------------------------------------------------------------
" 1234d" $10 STRING D$  ok
.S 
STACK: 0000.0000 0000.0000 FFFF.F9FF 0000.0010  ok
D$ TYPE$ 1234d ok
.S 
STACK: 0000.0000 0000.0000 FFFF.F9FF 0000.0010  ok
D$ NUMBER  ok
.S 
STACK: 0000.0000 FFFF.F9FF 0000.0010 0000.0000  ok

NUMBER ' ( str -- value digits | false )

Acceptable forms are:
$1000 hex number
1000h

#1000 decimal number
1000d

%1000 binary number
1000b

[nglordi]

While searching for a pic32 forth, I came across the program FORFITER (Lubos Pekny www.forth.cz). It is a terminal program designed to use with FORTH. It combines a terminal with an editor. It effectively eliminates copy/paste as a tool to entend forth. I am now using forfiter instead of tera term.

NickL

[Peter Jakacki]

I am working to interface a DMM to the Propeller. It communicates with 7 bits and 2 stop bits. I have tested it with an hp48 calculator at 8.1. Works fine if you clear the high bit of incoming data. For some reason PropForth would not cooperate with this although I did a successful test using the calculator to simulate the DMM by transmitting the same string with the high bits set. Maybe something I overlooked.

Currently I am learning to use Tachyon and testing still with the calculator doing the FakeDMM thing. I have established communication and get the string in to the prop. The test string is "DC 4.321 V". I have written code to extract the numeric part of the string "4.321" or "-1.234", as the case may be, so I need to find the spaces. Of course I could just assume ;-) the result to always be positive and it would always be in the same place - easy. But I would rather make a more general method. And after I get the number as a string I will want to make it a number - don't know how yet - have ideas - surely been done before.

Here is the code and the problems: [ how do I put code in one of those nice little windows? ]

dmmbuf .STR DC 4.321 V ok

: .DMM
dmmbuf $20 STRING D$ \ assign DMM reading to D$
BL D$ LOCATE$ 1+ $20 STRING N$ \ drop left side of string before number
N$ DUP BL OVER LOCATE$ \ find trailing space
SWAP - LEFT$ \ drop all after number
N$ D$ COPY$
FORGET N$
;

Problems:

Won't run. Can't FORGET it. It places the strings in the dictionary before it is even executed. Arrrrh!

About the forum formating, it uses BBCode and you can enter this directly or press the ADVANCED button down the bottom right of the edit window and you get a whole lot of other options. So when you paste code into the window then select that section and click the # button which will enclose the text in code tags.

The STRING word is a defining word, that is it creates a new defintion and the rule is that you do not create new definitions inside another one, so logically these should be defined before .DMM . So STRING and FORGET etc are all defining words that execute immediately even during compile so no Forth ever expects to use them in the way that you have defined .DMM

Anyway, you are doing it the hard way, all the parsing and conversion is built into TF, don't assemble the whole line into a buffer just parse it word by word (direct key input) and use GETWORD DECIMAL NUMBER when you are expecting data from the DMM. The AC/DC part of the message would also be handled by a preceding GETWORD and storing that result in a string like this GETWORD dmm$ COPY$ etc.

I could write the code for you but it is simpler than you think so I will let you have a bit more of a play with TF. Of couse if you have to have it in a bufffer to parse just remember that NUMBER will parse a string but define that string just like any variable or constant, outside of another defintion.

EDIT: You would never say in any Forth
: MyTest 1234 CONSTANT mycon mycon . ;
But of course you do it like this:
1234 CONSTANT mycon
: MyTest mycon . ;
So STRING is similar to CONSTANT and VARIABLE and so on. Even if the first example compiled somehow what would happend each time you ran it is that it would create another new definition called mycon, after testing that ten times you would have 10 new "mycons" in the dictionary, clearly not what you would want to happen.

BTW, any use of the BACKUP word is normally safe, it skips those areas it would never want to overwrite in EEPROM.

[D.P]

r

I am working to interface a DMM to the Propeller. It communicates with 7 bits and 2 stop bits. I have tested it with an hp48 calculator at 8.1. Works fine if you clear the high bit of incoming data. For some reason PropForth would not cooperate with this although I did a successful test using the calculator to simulate the DMM by transmitting the same string with the high bits set. Maybe something I overlooked.

Currently I am learning to use Tachyon and testing still with the calculator doing the FakeDMM thing. I have established communication and get the string in to the prop. The test string is "DC 4.321 V". I have written code to extract the numeric part of the string "4.321" or "-1.234", as the case may be, so I need to find the spaces. Of course I could just assume ;-) the result to always be positive and it would always be in the same place - easy. But I would rather make a more general method. And after I get the number as a string I will want to make it a number - don't know how yet - have ideas - surely been done before.

Here is the code and the problems: [ how do I put code in one of those nice little windows? ]

dmmbuf .STR DC 4.321 V ok

: .DMM
dmmbuf $20 STRING D$ \ assign DMM reading to D$
BL D$ LOCATE$ 1+ $20 STRING N$ \ drop left side of string before number
N$ DUP BL OVER LOCATE$ \ find trailing space
SWAP - LEFT$ \ drop all after number
N$ D$ COPY$
FORGET N$
;

Problems:

Won't run. Can't FORGET it. It places the strings in the dictionary before it is even executed. Arrrrh!

I can't declare a STRING in a definition so Peter will have the answer, but this does work so your logic is right

 " DC 4.321 V" $20 STRING dmmbuf  ok
 NULL$ $20 STRING D$  ok
 NULL$ $20 STRING N$    ok
: DMM 
 dmmbuf D$ COPY$ 
 BL D$ LOCATE$ 1+ N$ COPY$  \ 
 N$ DUP BL OVER LOCATE$ \ 
 SWAP - LEFT$ \ 
 N$ D$ COPY$ 
;  ok
DMM  ok
N$ .STR 4.321 ok
D$ .STR 4.321 ok

Pretty sure you could refactor one string and use the temporary buffers if memory is of concern.
"Add BUFFERS word which points to the 2K VM image (reusable as temporary buffers - do not backup as Tachyon will not be able to boot)"

[artkennedy]

I am working to interface a DMM to the Propeller. It communicates with 7 bits and 2 stop bits. I have tested it with an hp48 calculator at 8.1. Works fine if you clear the high bit of incoming data. For some reason PropForth would not cooperate with this although I did a successful test using the calculator to simulate the DMM by transmitting the same string with the high bits set. Maybe something I overlooked.

Currently I am learning to use Tachyon and testing still with the calculator doing the FakeDMM thing. I have established communication and get the string in to the prop. The test string is "DC 4.321 V". I have written code to extract the numeric part of the string "4.321" or "-1.234", as the case may be, so I need to find the spaces. Of course I could just assume ;-) the result to always be positive and it would always be in the same place - easy. But I would rather make a more general method. And after I get the number as a string I will want to make it a number - don't know how yet - have ideas - surely been done before.

Here is the code and the problems: [ how do I put code in one of those nice little windows? ]

dmmbuf .STR DC 4.321 V ok

: .DMM
dmmbuf $20 STRING D$ \ assign DMM reading to D$
BL D$ LOCATE$ 1+ $20 STRING N$ \ drop left side of string before number
N$ DUP BL OVER LOCATE$ \ find trailing space
SWAP - LEFT$ \ drop all after number
N$ D$ COPY$
FORGET N$
;

Problems:

Won't run. Can't FORGET it. It places the strings in the dictionary before it is even executed. Arrrrh!

[D.P]

I can fix the blank line thing, it's just that I keep forgetting about it but if you leave out the end-of-line comment it also works fine too. Just place the comment up above it. It has to do with termination of looking for more names although TABLE itself should never need to do this but it's based on AVARIABLE which does.

As long as nothing has set the LCD serial data pin high such as during testing then your task should be able to run but I will hook-up one of my serial LCDs and try it out anyway.

EDIT: you could also release the LCD serial data pin after transmit as the LCD should have a pullup.
pub LCDEMIT 9 PINSET 9 SEROUT 9 PININP ;

Everything works after the additional line between the TABLE definitions. I will remember/document about the comments and the release of the serial pin.
Thanks

[Peter Jakacki]

I am really liking the way Tachyon parses as soon as you enter a space and reports "NOT FOUND" so that you can then press ESC and not even disturb the stack. *Slick*

I did have that changed to ??? during normal interactive mode but to make the error pop out a bit more during a source code load I did the --> badword <-- NOT FOUND message instead. So don't be surprised if it seems to revert back to ??? because that is less invasive when we are typing whereas the NOT FOUND is useful during a TACHYON ...... END type load.

The parsing as you type is really compile as you type so you don't have to create a definition just to run "compile only" words as they work the same outside of a definition as they do inside, an example:
$80 BL DO I EMIT LOOP
Will execute immediately you hit the enter key without having to put this inside a definition.

BTW, You don't even need to hit ESC as it is quite happy just to continue on. Clearing the stack on an error seems to be a standard Forth thing but I always found it to be more of a nuisance, type type doh, retype retype doh and so on.

EDIT: The compile as you go approach also means I don't have to have a text input buffer large enough to accommodate the longest line, I only need a word buffer wide enough to accommodate the longest word (32 characters).

[Peter Jakacki]

This has been elusive for me for some reason. I'm just now proceding from FORTH/Tachyon syntax to more "how it works" stuff.
Getting past this hurdle has helped me greatly, I just couldn't glean what I needed from within the source.
Now I have renewed motivation, thanks for the "thorn removal"

UPDATE, while this has removed the keyboard issue the LCD is "no op", LCD checked with console testing? I've tried with $20,$30 ALLOT for regs1

UPDATE2****** NEED TO HAVE A BLANK LINE BETWEEN EACH ALLOT STATEMENT, ARRG I BEEN BITTEN BY THIS BEFORE! BEWARE

TABLE regs1         $20 ALLOT           \ some room for temp register + uemit and ukey
TABLE stacktsk     $40 ALLOT

\ shoud be 

TABLE regs1         $20 ALLOT           \ some room for temp register + uemit and ukey

TABLE stacktsk     $40 ALLOT

I can fix the blank line thing, it's just that I keep forgetting about it but if you leave out the end-of-line comment it also works fine too. Just place the comment up above it. It has to do with termination of looking for more names although TABLE itself should never need to do this but it's based on AVARIABLE which does.

As long as nothing has set the LCD serial data pin high such as during testing then your task should be able to run but I will hook-up one of my serial LCDs and try it out anyway.

EDIT: you could also release the LCD serial data pin after transmit as the LCD should have a pullup.
pub LCDEMIT 9 PINSET 9 SEROUT 9 PININP ;

[artkennedy]

I am really liking the way Tachyon parses as soon as you enter a space and reports "NOT FOUND" so that you can then press ESC and not even disturb the stack. *Slick*

[D.P]

I was going to leave that exercise to you but I have included the extra line or two to show you what I would do in this circumstance.

TABLE regs1         $20 ALLOT           \ some room for temp register + uemit and ukey
TABLE stacktsk     $40 ALLOT

: LCDEMIT        9 SEROUT ;             \ define emit word for this output
: LCD        ' LCDEMIT uemit W! ;       \ vector it to uemit
  " THE 2nd STRING" 0 STRING B$         \ tachyon string variable
  " HOW IS LONG IS" 0 STRING A$

: MYTASK             \ task to demonstrate  LCD output 
  regs1  TASKREGS       \  <----- setup separate task registers for this task
  stacktsk SP! !SP   \ assign this task a local stack and initialize to a depth of 0
  9600d SERBAUD      \ set this task's BAUD
  LCD                \ re-vector output          
  BEGIN
    CLS              \ clr lcd
    #17 EMIT         \ turn on bl
    #100 ms 
    "0" #10 ADO I EMIT LOOP   "A" 6 ADO I EMIT LOOP    \ output 0-1A-F
    2 seconds 
    A$ PRINT$
    2 seconds
    CLS
    B$ PRINT$
    2 second
    CLS
    " any old string" PRINT$
    1 second
    CLS
    CR PRINT" That's all folks!"
    1 second
    CLS
    #18 EMIT      \ turn off bl
   1 second
  AGAIN
;

This has been elusive for me for some reason. I'm just now proceding from FORTH/Tachyon syntax to more "how it works" stuff.
Getting past this hurdle has helped me greatly, I just couldn't glean what I needed from within the source.
Now I have renewed motivation, thanks for the "thorn removal"

UPDATE, while this has removed the keyboard issue the LCD is "no op", LCD checked with console testing? I've tried with $20,$30 ALLOT for regs1

UPDATE2****** NEED TO HAVE A BLANK LINE BETWEEN EACH ALLOT STATEMENT, ARRG I BEEN BITTEN BY THIS BEFORE! BEWARE

TABLE regs1         $20 ALLOT           \ some room for temp register + uemit and ukey
TABLE stacktsk     $40 ALLOT

\ shoud be 

TABLE regs1         $20 ALLOT           \ some room for temp register + uemit and ukey

TABLE stacktsk     $40 ALLOT

[Peter Jakacki]

So how to structure this code with TASKREGS then?

I was going to leave that exercise to you but I have included the extra line or two to show you what I would do in this circumstance.

TABLE regs1         $20 ALLOT           \ some room for temp register + uemit and ukey
TABLE stacktsk     $40 ALLOT

: LCDEMIT        9 SEROUT ;             \ define emit word for this output
: LCD        ' LCDEMIT uemit W! ;       \ vector it to uemit
  " THE 2nd STRING" 0 STRING B$         \ tachyon string variable
  " HOW IS LONG IS" 0 STRING A$

: MYTASK             \ task to demonstrate  LCD output 
  regs1  TASKREGS       \  <----- setup separate task registers for this task
  stacktsk SP! !SP   \ assign this task a local stack and initialize to a depth of 0
  9600d SERBAUD      \ set this task's BAUD
  LCD                \ re-vector output          
  BEGIN
    CLS              \ clr lcd
    #17 EMIT         \ turn on bl
    #100 ms 
    "0" #10 ADO I EMIT LOOP   "A" 6 ADO I EMIT LOOP    \ output 0-1A-F
    2 seconds 
    A$ PRINT$
    2 seconds
    CLS
    B$ PRINT$
    2 second
    CLS
    " any old string" PRINT$
    1 second
    CLS
    CR PRINT" That's all folks!"
    1 second
    CLS
    #18 EMIT      \ turn off bl
   1 second
  AGAIN
;

[D.P]

Okay, as you can see from the code the only vector that was changed was the emit vector, not the key vector, so the LCD word only redirects output. What also happens though is that your task may use other common areas however what you can do is allocate memory for the Forth task variables or what I call registers. Each TF cog can point to it's own set of registers if it wants and the registers are so structured that you don't have to implement them all, the basic ones to do with redirection and number base etc are near the start of the register memory. Here is a snippet from the source:

{TASK REGISTERS}

' Task registers can be switched easily by setting "regptr" ( 7 COGREG! )
' New tasks may only need room for the first 32 or 72 bytes


registers        long 0[64]        'Variables used by kernel + general-purpose

    org  0
' register offsets within "registers". Access as    REG,delim   ...  REG,base ... etc
'
' Minimum registers required for a new task - other registers after the ' ---- are not needed other than by the console
temp        res 12    ' general purpose
cntr        res 4    ' hold CNT or temp
' @16
uemit        res 2
ukey        res 2
keypoll        res 2    ' poll user routines - low priority background task
unum        res 2    ' User number processing routine - executed if number failed and UNUM <> 0
baudcnt        res 4    ' baud cnt value where baud = clkfreq/baudcnt
uswitch        res 4    ' target parameter used in CASE structures
' @32
padwr        res 1        ' write index (builds characters down from lsb to msb in MODULO style)
numpad        res numpadsz    ' Number print format routines assemble digit characters here

Notice there are 16 bytes reserved for temp and cntr and then you have uemit and ukey so you can allocate just the memory you need. I also notice that I could still rearrange some of the other registers to move closer to the start, including base etc. To set a new register base there is the TASKREGS word in EXTEND which just performs a 7 COGREG!.

So how to structure this code with TASKREGS then?

TABLE stacktsk     $40 ALLOT

: LCDEMIT        9 SEROUT ;             \ define emit word for this output
: LCD        ' LCDEMIT uemit W! ;       \ vector it to uemit
  " THE 2nd STRING" 0 STRING B$         \ tachyon string variable
  " HOW IS LONG IS" 0 STRING A$

: MYTASK             \ task to demonstrate  LCD output 
  \  TASKREGS       \ what is it about this I don't understand,   need to allocate space for these I guess
  stacktsk SP! !SP   \ assign this task a local stack and initialize to a depth of 0
  9600d SERBAUD      \ set this task's BAUD
  LCD                \ re-vector output          
  BEGIN
    CLS              \ clr lcd
    #17 EMIT         \ turn on bl
    #100 ms 
    "0" #10 ADO I EMIT LOOP   "A" 6 ADO I EMIT LOOP    \ output 0-1A-F
    2 seconds 
    A$ PRINT$
    2 seconds
    CLS
    B$ PRINT$
    2 second
    CLS
    " any old string" PRINT$
    1 second
    CLS
    CR PRINT" That's all folks!"
    1 second
    CLS
    #18 EMIT      \ turn off bl
   1 second
  AGAIN
;

[Brian Riley]

I tried some older code on the latest Dropbox (Tachyon 2.3.spin plus EXTEND and followed the "8 bit PWM" commentary and this is what happened ... every time

  Propeller .:.:--TACHYON--:.:. Forth V23140216.1600

NAMES:  $5E70...74EF for 5759 (3245 bytes added)
CODE:   $0000...3101 for 6786 (6401 bytes added)
CALLS:  0500 vectors free
RAM:    11631 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140216-1400 

----------------------------------------------------------------
  ok
TABLE pwm #256 ALLOT	 	   ok
 #1000 PWMFREQ  ok
0 8 RUNPWM  ok
Ä¿
  -->  <-- NOT FOUND 

à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿
à¿"
à¿"
à¿"
à¿"
à¿"®¿"
à¿"
à¿"
à¿
à¿
à¿
DATA STACK 
01B6: 0000.01B6 0000.0000 
01B8: 0000.0000 0000.0000 
RETURN STACK 
01BA: 0000.162C 0000.144B 
01BC: 0000.13A7 0000.0A69 0000.0A32 0000.09CB 
01C0: 0000.095D 0000.095D 0000.0955 0000.094D 
01C4: 0000.0000 0000.0000 0000.0000 0000.0000 
01C8: 0000.0000 0000.0000 0000.0000 0000.0000 
01CC: 0000.0000 0000.0000 0000.0000 0000.0000 
LOOP STACK 
01D0: 0000.0000 0000.0000 0000.0000 0000.0000 
01D4: 0000.0000 0000.0000 0000.0000 0000.0000 
BRANCH STACK 
01D8: 0000.0000 0000.0000 0000.0000 0000.0000 
01DC: 0000.0000 0000.0000 
REGISTERS
0024: 00 00 DE 01 00 00 00 00 00 00 00 00 C5 3A A6 5D    .............:.]
0034: 00 00 00 00 00 00 00 00 8D 20 00 00 00 00 00 00    ......... ......
0044: 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    %...............
0054: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0064: 00 00 00 32 33 31 31 31 36 33 31 00 0A 10 88 C0    ...23111631.....
0074: 13 14 01 10 88 C0 13 10 88 C0 22 01 10 88 C0 22    .........."...."
0084: A8 C0 22 01 10 88 C0 22 01 10 88 C0 22 01 10 88    .."...."...."...
0094: C0 13 12 01 00 00 00 00 00 00 00 00 00 00 00 00    ................
00A4: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00    ................
00B4: 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00    ................
00C4: 00 00 01 00 00 00 00 00 52 2E 01 00 00 00 00 00    ........R.......
00D4: 2C 2D 01 00 00 00 00 00 00 00 00 00 00 00 00 00    ,-..............
00E4: 00 00 00 00 00 00 48 7D 00 02 1E 6B 00 00 1D 6B    ......H}...k...k
00F4: 69 5E 70 5E 00 18 0A 32 0A 32 5A A5 E4 30 01 00    i^p^...2.2Z..0..
0104: 4E 06 20 04 10 10 04 13 00 00 00 00 04 01 80 01    N. .............
0114: 04 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00    .H..............

COMPILATION AREA
320A: 7F 7B B7 FE 06 06 06 00 00 00 00 00 00 00 00 00    .{..............
321A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
322A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
323A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿CH
à¿¿C
H
à¿¿C!H
à¿¿C
à¿¿C
à¿¿C
à¿¿K
à¿¿!à¿¿!à¿¿!à¿¿
à¿¿
à¿¿
à¿¿"
à¿¿"
à¿¿"
à¿¿"
à¿¿"
à¿¿"
à¿¿$"(à¿¿
à¿¿
à¿¿
à¿¿à¿¿à¿¿à¿¿à¿¿#"
à¿¿#"
à¿¿#"
à¿¿#
à¿¿#
à¿¿#
à¿¿#
à¿¿#
à¿¿#!
à¿¿


*** Manual Hardware Reset Done Here ***


  Propeller .:.:--TACHYON--:.:. Forth V23140216.1600

[Peter Jakacki]

Okay so I am able to start tasks with there own stack as you demonstrated in the RS232 snipet.

The serial task that outputs to a LCD works correctly now.

Something I'm not understanding about uemit and ukey though.

The LCD serial task starts and continously loops through the messages but the console keyboard input is vectored to the LCD
,which cause the LCD to freeze, and does not remain in the console. Issuing a CON gets the keyboard back but now the system is unstable and requires a reboot.

I thought that "calling" LCD from within the task would not vector the console's keyboard input to the LCD

: LCDEMIT        9 SEROUT ;             \ define emit word for this output
: LCD        ' LCDEMIT uemit W! ;       \ vector it to uemit

Obviously it's my lack of understanding of uemit and ukey in tasks.

Okay, as you can see from the code the only vector that was changed was the emit vector, not the key vector, so the LCD word only redirects output. What also happens though is that your task may use other common areas however what you can do is allocate memory for the Forth task variables or what I call registers. Each TF cog can point to it's own set of registers if it wants and the registers are so structured that you don't have to implement them all, the basic ones to do with redirection and number base etc are near the start of the register memory. Here is a snippet from the source:

{TASK REGISTERS}

' Task registers can be switched easily by setting "regptr" ( 7 COGREG! )
' New tasks may only need room for the first 32 or 72 bytes


registers        long 0[64]        'Variables used by kernel + general-purpose

    org  0
' register offsets within "registers". Access as    REG,delim   ...  REG,base ... etc
'
' Minimum registers required for a new task - other registers after the ' ---- are not needed other than by the console
temp        res 12    ' general purpose
cntr        res 4    ' hold CNT or temp
' @16
uemit        res 2
ukey        res 2
keypoll        res 2    ' poll user routines - low priority background task
unum        res 2    ' User number processing routine - executed if number failed and UNUM <> 0
baudcnt        res 4    ' baud cnt value where baud = clkfreq/baudcnt
uswitch        res 4    ' target parameter used in CASE structures
' @32
padwr        res 1        ' write index (builds characters down from lsb to msb in MODULO style)
numpad        res numpadsz    ' Number print format routines assemble digit characters here

Notice there are 16 bytes reserved for temp and cntr and then you have uemit and ukey so you can allocate just the memory you need. I also notice that I could still rearrange some of the other registers to move closer to the start, including base etc. To set a new register base there is the TASKREGS word in EXTEND which just performs a 7 COGREG!.

[D.P]

Okay so I am able to start tasks with there own stack as you demonstrated in the RS232 snipet.

The serial task that outputs to a LCD works correctly now.

Something I'm not understanding about uemit and ukey though.

The LCD serial task starts and continously loops through the messages but the console keyboard input is vectored to the LCD
,which cause the LCD to freeze, and does not remain in the console. Issuing a CON gets the keyboard back but now the system is unstable and requires a reboot.

I thought that "calling" LCD from within the task would not vector the console's keyboard input to the LCD

: LCDEMIT        9 SEROUT ;             \ define emit word for this output
: LCD        ' LCDEMIT uemit W! ;       \ vector it to uemit

Obviously it's my lack of understanding of uemit and ukey in tasks.

[Peter Jakacki]

Thanks Peter on the "s" info. I would not have figured that out.

BTW what do mean by old header. Is there a newer file i should be studying?

cheers,
rich

old as in "ole familiar" header

The offset gets used in Tachyon when it needs to know the absolute address at compile time (it's a compiler work-around). Here the vector table needs to have the absolute address compiled so that at runtime it can just load the address from the table. The Spin operator @ returns with the address and the +s adds in the extra 16 bytes.

xFILL                long @FILL+s
xERASE               long @ERASE+s

[richaj45]

Thanks Peter on the "s" info. I would not have figured that out.

BTW what do mean by old header. Is there a newer file i should be studying?

cheers,
rich

[Peter Jakacki]

Thanks, Peter. I guess I should have searched for DEPTH in the word list. That's a no brainer - same as the hp calculators I love. I'm trying to research this stuff myself as much as possible because I know that is the best way to learn but there is an awful lot and sometimes nothing in the Intro to go on. I have "Starting Forth" standing by, the word list captured from Tachyon, and the source files and extensions. I try to check those before I post.

Bearing in mind that the Introduction to Tachyon Forth is not really an Introduction to Forth in general please feel free to make suggestions, even compiling the suggestions into a list and posting these. If some of the suggestions are more general to Forth in nature and too wordy to include then I may just link to that material instead.

In addition to the Intro page Tachyon also needs a reference manual I guess but the reason that I haven't done one is that it is a lot of work and also the source code documents are readily available and formatted with some usage examples etc.

[Peter Jakacki]

\ Here is an extremely basic Inter Task Communication example, not optimized, I didn't know if it should go into the intro doc or not.
It uses BEGIN AGAIN to run the TASK continuously.

Didn't I give you edit rights to that document? You just have to start exercising that great responsibility now!

[Peter Jakacki]

@Peter

Looking through the v2.3 code i see a "+s" in many places being added to a label.

I did not notice were it was defined so what is that offset and why is it there?

Thanks for the education.
rich

That's the old header offset that's needed as the Spin compiler (we really only compile PASM) generates absolute addresses offset by $10 as the first 16 bytes of memory hold the clock freqency, code and stack initialization parameters etc. So any PASM source needs to add this offset if it wants the real absolute memory address.

The "s" is a lot less distracting than $10 or the like, it is defined just before the cog VM kernel about 75% through the source:

                        org        $10

s                        ' just an offset to be used in DAT sections rather than the distracting +$10

[artkennedy]

Cool. Tried it out instead of colon - it works. Knowing this will make the kernel source more understandable.

[artkennedy]

I don't (cog-wise) waste time trying to determine if the stack is greater then 4 levels deep, it always overflows into hub RAM even if there is only one item, so the depth is determined from the stack write index. Before when I had a 12 level deep cog RAM stack all the pushing and popping was done by moving memory and there was no depth pointer. So interestingly the change to a hybrid stack hasn't actually slowed anything down as the time lost to hub access is made up for the time gained from not moving 8 cog locations. So DROP will continue to drop until the stack is empty but will stop there, the DEPTH word will tell you how deep the stack is.

As for BEGIN UNTIL vs BEGIN REPEAT, that's really BEGIN WHILE REPEAT and although I would have preferred to say BEGIN WHILE AGAIN in keeping with the simpler BEGIN AGAIN construct, it is however been a standard to use REPEAT to match up with a WHILE. So BEGIN AGAIN is a forever loop typically used in a task, BEGIN UNTIL for a conditional exit from the loop, BEGIN WHILE REPEAT for an infinite loop (REPEAT == AGAIN) except the WHILE determines what it will do and for how long. i.e. BEGIN ANY_DATA? WHILE PROCESS_DATA REPEAT

Thanks, Peter. I guess I should have searched for DEPTH in the word list. That's a no brainer - same as the hp calculators I love. I'm trying to research this stuff myself as much as possible because I know that is the best way to learn but there is an awful lot and sometimes nothing in the Intro to go on. I have "Starting Forth" standing by, the word list captured from Tachyon, and the source files and extensions. I try to check those before I post.

[D.P]

\ Here is an extremely basic Inter Task Communication example, not optimized, I didn't know if it should go into the intro doc or not.
It uses BEGIN AGAIN to run the TASK continuously.

WORD  BLINKRUN                 \ global variable to save the state of the blinky task

#13 MASK CONSTANT RDYLED       \ define a constant mask for the led pin, define your pin

: BLINKY 
    BEGIN
      ATN@ DUP 0= 
      IF DROP                 \ no command, drop the 0 returned by ATN@ and continue
        BLINKRUN W@           \ read the global variable to see what we need to do 
        IF              
          RDYLED OUTSET 100d ms RDYLED OUTCLR 100d ms \ it was ON we are running blink
        ELSE
          RDYLED OUTSET         \ else it was OFF just set the led on
        THEN
      ELSE              \ got a command let's check it
        DUP #33 =       \ dup it and check it against #33 our blink on command
        IF      
          #33 ENQ!            \ send the command back to the task that called us  
          ON BLINKRUN W!      \ set the global variable state
        THEN
        #66 =                 \ check it against #66, use last stack item, stack clean
        IF                    \ if so set blink off 
          #66 ENQ!            \ echo back the command again
          OFF BLINKRUN W!     \ set the global variabl state
        THEN
      THEN
    AGAIN                     \ do it forever

   ;

: BLKYINIT ' BLINKY 4 RUN     \ start the BLINKY Task in COG 4  and start blinking
              #33 4 ATN! 
;

: BLKYSTOP #66 4 ATN! 100 ms 4 ENQ@ . ;  \ send stop command,read response
: BLKYSTART #33 4 ATN! 100 ms 4 ENQ@ . ;  \ send start command, read response

\   USAGE
{
DECIMAL  ok
BLKYINIT  ok
BLKYSTOP   66 ok
BLKYSTART 33 ok
BLKYSTOP    66 ok
}

[richaj45]

@Peter

Looking through the v2.3 code i see a "+s" in many places being added to a label.

I did not notice were it was defined so what is that offset and why is it there?

Thanks for the education.
rich

[Peter Jakacki]

If the data stack can exceed 4 levels by overflowing into hub memory how can you determine the size of the stack? DROP does decrease the size of the stack doesn't it?
What is the difference between BEGIN . . . UNTIL and BEGIN . . . REPEAT ?

I don't (cog-wise) waste time trying to determine if the stack is greater then 4 levels deep, it always overflows into hub RAM even if there is only one item, so the depth is determined from the stack write index. Before when I had a 12 level deep cog RAM stack all the pushing and popping was done by moving memory and there was no depth pointer. So interestingly the change to a hybrid stack hasn't actually slowed anything down as the time lost to hub access is made up for the time gained from not moving 8 cog locations. So DROP will continue to drop until the stack is empty but will stop there, the DEPTH word will tell you how deep the stack is.

As for BEGIN UNTIL vs BEGIN REPEAT, that's really BEGIN WHILE REPEAT and although I would have preferred to say BEGIN WHILE AGAIN in keeping with the simpler BEGIN AGAIN construct, it is however been a standard to use REPEAT to match up with a WHILE. So BEGIN AGAIN is a forever loop typically used in a task, BEGIN UNTIL for a conditional exit from the loop, BEGIN WHILE REPEAT for an infinite loop (REPEAT == AGAIN) except the WHILE determines what it will do and for how long. i.e. BEGIN ANY_DATA? WHILE PROCESS_DATA REPEAT

[artkennedy]

If the data stack can exceed 4 levels by overflowing into hub memory how can you determine the size of the stack? DROP does decrease the size of the stack doesn't it?

[artkennedy]

What is the difference between BEGIN . . . UNTIL and BEGIN . . . REPEAT ?

[Peter Jakacki]

What is the meaning of "pub", "pri", and "code" within the Tachyon context? Of course I know that it is "public", "private" and so on but what are the implications for the use of those words?

The colon word is the normal Forth defining word and pub and pri do the same thing except that pri sets a private bit in the attribute flags of the header. This does nothing normally but when I run RECLAIM it scans for any names that have the private attribute and strips them from the dictionary thus saving both precious memory and also preventing the misuse of these words normally. So pub is exactly the same as the colon but the other reason I use pub and pri is simply to make it easier to see in documents, much like the PRINT word does and also to make it recognizable to anyone who has programmed in Spin as that is the "native HLL language" of the Prop.

The "code" tag only shows up when you do a WORDS listing to identify what type of word it is.

[Peter Jakacki]

I am finding these references to aliases confusing. The only PRINT I am finding in the WORDS list is PRINT" and yet in the code you post you use PRINT" and refer to PRINT as an alias for the dot word. By this do you mean that using PRINT" instead of ." is just for clarity when communicating about code rather than writing code for execution?

Geez. I getting all muddled up just trying to ask the question.

The aliases are actually meant to make it clearer, not get you muddled!!! Just make sure you have the latest kernels compiled, the aliases are something I've added recently. As I mentioned the reason I have done so is because the dot symbol is hard to see in a lot of documents but PRINT punches you in the face and is well recognized.

standard       -- alias
.              -- PRINT
."             -- PRINT"
TYPE$          -- PRINT$

[artkennedy]

What is the meaning of "pub", "pri", and "code" within the Tachyon context? Of course I know that it is "public", "private" and so on but what are the implications for the use of those words?

[D.P]

If you disable the LCD word in MYTASK it emits to the console which I checked a couple of different ways, it all works, the strings print etc. It doesn't matter that it runs in another task either except you need to allocate a data stack for it these days as the cog only has a depth of 4 levels and the rest is external. Here's an example of starting up a task to do nothing more than buffer some RS232 data. You can follow the way it creates a datastack and assigns that memory to the cog task.

TABLE stack232     $40 ALLOT
TABLE buf232    $80 ALLOT
BYTE rxrd,rxwr
LONG logrcd

\ Buffer data from the RS232 port - nothing else
pub RS232_TASK
    stack232 SP! !SP        \ Set the stack pointer for this cog and make sure it's initalized (optional)
    logbaud @ SERBAUD
    DTR232 PINSET
    RTS232 PINSET
    TXD232 PINSET
    rxrd C~ rxwr C~ buf232 $80 ERASE 
    BEGIN 
      logport C@ SERIN 
      rxwr C@ $7F AND buf232 + C! 
      rxwr C++ 
    AGAIN  
    ;

So when you are debugging stuff like your code always try to run it in the main console cog first and even direct output back to the console too. Then try the redirect to the LCD, and then finally as a task when you know everything else is working fine.

ACKnowledged, understood, thanks.

[artkennedy]

I am finding these references to aliases confusing. The only PRINT I am finding in the WORDS list is PRINT" and yet in the code you post you use PRINT" and refer to PRINT as an alias for the dot word. By this do you mean that using PRINT" instead of ." is just for clarity when communicating about code rather than writing code for execution?

Geez. I getting all muddled up just trying to ask the question.

[Peter Jakacki]

Maybe I didn't explain myself well.

' MYTASK 4 RUN \ trying to run this in a task, guess I shouldn't have left out that info. This is why I took the approach I did, I do realize all the aliases that have been created.

Update: everything runs but the string values.

If you disable the LCD word in MYTASK it emits to the console which I checked a couple of different ways, it all works, the strings print etc. It doesn't matter that it runs in another task either except you need to allocate a data stack for it these days as the cog only has a depth of 4 levels and the rest is external. Here's an example of starting up a task to do nothing more than buffer some RS232 data. You can follow the way it creates a datastack and assigns that memory to the cog task.

TABLE stack232     $40 ALLOT
TABLE buf232    $80 ALLOT
BYTE rxrd,rxwr
LONG logrcd

\ Buffer data from the RS232 port - nothing else
pub RS232_TASK
    stack232 SP! !SP        \ Set the stack pointer for this cog and make sure it's initalized (optional)
    logbaud @ SERBAUD
    DTR232 PINSET
    RTS232 PINSET
    TXD232 PINSET
    rxrd C~ rxwr C~ buf232 $80 ERASE 
    BEGIN 
      logport C@ SERIN 
      rxwr C@ $7F AND buf232 + C! 
      rxwr C++ 
    AGAIN  
    ;

So when you are debugging stuff like your code always try to run it in the main console cog first and even direct output back to the console too. Then try the redirect to the LCD, and then finally as a task when you know everything else is working fine.

[D.P]

This is exactly why we have character I/O redirection for EMIT and KEY, so that we don't have to have special routines for all these displays etc.
Here's the code using redirection and also the STRING word is a defining word, you don't use it inside another definition, that was your main problem. Otherwise you can just use a literal string inside the definition without defining it.

\ Define the emit word for this output
: LCDEMIT        9 SEROUT ;
: LCD        ' LCDEMIT uemit W! ;
  " THE 2nd STRING" 0 STRING B$ 
  " HOW IS LONG IS" 0 STRING A$
: MYTASK  
  9600d SERBAUD
  LCD
  CLS     \ clr lcd
  #17 EMIT    \ turn on bl
  #100 ms 
  "0" #10 ADO I EMIT LOOP   "A" 6 ADO I EMIT LOOP    \ output 0-1A-F
  2 seconds 
  A$ PRINT$
  2 seconds
  B$ PRINT$
  1 second
  " any old string" PRINT$
  1 second
  CR PRINT" That's all folks!"
  1 second
  CLS
  #18 EMIT
  CON
;

EDIT: I've added a couple of lines showing a literal string and what I normally do, just print what I want to say. Notice that there are PRINT aliases for many normal Forth words, so PRINT is the "dot" word, and PRINT$ is TYPE$ and PRINT" is ." as I find that the . itself barely stands out in forums and on documents so I chose PRINT as that is instantly recognizable to anyone.

Maybe I didn't explain myself well.

' MYTASK 4 RUN \ trying to run this in a task, guess I shouldn't have left out that info. This is why I took the approach I did, I do realize all the aliases that have been created.

Update: everything runs but the string values.

[Peter Jakacki]

Output of strings over serial in tasks? Can you point out the bugz, wyht (when you have time)
Not sure what I can and can't do here re strings, the other parts work as expected

Thanks

This is exactly why we have character I/O redirection for EMIT and KEY, so that we don't have to have special routines for all these displays etc.
Here's the code using redirection and also the STRING word is a defining word, you don't use it inside another definition, that was your main problem. Otherwise you can just use a literal string inside the definition without defining it.

\ Define the emit word for this output
: LCDEMIT        9 SEROUT ;
: LCD        ' LCDEMIT uemit W! ;
  " THE 2nd STRING" 0 STRING B$ 
  " HOW IS LONG IS" 0 STRING A$
: MYTASK  
  9600d SERBAUD
  LCD
  CLS     \ clr lcd
  #17 EMIT    \ turn on bl
  #100 ms 
  "0" #10 ADO I EMIT LOOP   "A" 6 ADO I EMIT LOOP    \ output 0-1A-F
  2 seconds 
  A$ PRINT$
  2 seconds
  B$ PRINT$
  1 second
  " any old string" PRINT$
  1 second
  CR PRINT" That's all folks!"
  1 second
  CLS
  #18 EMIT
  CON
;

EDIT: I've added a couple of lines showing a literal string and what I normally do, just print what I want to say. Notice that there are PRINT aliases for many normal Forth words, so PRINT is the "dot" word, and PRINT$ is TYPE$ and PRINT" is ." as I find that the . itself barely stands out in forums and on documents so I chose PRINT as that is instantly recognizable to anyone.

[D.P]

@MAX72

Tracy Allen made an integer only version of the sensirion (in spin). Maybe you can check it.

The application is a far end (90 - 100%) RH sensor in a condensing, dirty environment and sensirion, honeywell .... just can't handle the abuse. These "membrane" sensors have extremely poor resolution at the high end, not to mention drift and downright failure. Thus I must use the Saturation VP to get the best resolution via wet/dry bulb temps and ambient pressure. Tracy knows about this application and its issues.

[D.P]

Output of strings over serial in tasks? Can you point out the bugz, wyht (when you have time)
Not sure what I can and can't do here re strings, the other parts work as expected

Thanks

" THE 1st STRING" $10 STRING A$  
: STROUT ( str -- ) DUP LEN$ ADO I C@ 9 SEROUT LOOP ;

: MYTASK  
  9600d SERBAUD
  " THE 2nd STRING" $10 STRING B$ 
  #12 9 SEROUT     \ clr lcd
  #17 9 SEROUT    \ turn on bl
  #100 ms 
  $3A $30 DO I 9 SEROUT LOOP $47 $41 DO I 9 SEROUT LOOP    \ output 0-1A-F
  #2000 ms 
  A$ STROUT     \ no joy
  #2000 ms
  B$ STROUT    \ not this way either
  #1000 ms
  #12 9 SEROUT   
  #18 9 SEROUT 
;

[Peter Jakacki]

In attempting to understand some of the words in Tachyon I have opened Tachyon V2.3.spin and the extension files looking for clues. When I do I often get a warning "Not all unicode characters could be converted to ASCII". My favorite editor is The Semware Editor - known as QEdit with I first started using it. I have also noticed some characters that the editor displays as upper 128 code ASCII. I have also looked at the file in WordPad and seen those upper characters. Am I endangering the contents of those files if I have to save, for instance if I must customize a parameter? What would be a better editor to use? I luv my TSE.

That's a new one on me, I've never seen or had any problems with text editors, I have plenty to choose from in Linux where I mainly use medit but on Windows I have used Context with a Forth highlighter, both of which you will find in the Tachyon dropbox folder (see my sigs) under PC utilities. When you mentioned QEdit it brought back images of the clunky old DOS days!!! As long as a text editor can open a file I'm happy, if it has sensible shortcut keys, I'm happy. If it has highlighting, I'm happy. Sure there are other things to look for but that's a start, otherwise I don't really have a favorite.

[artkennedy]

In attempting to understand some of the words in Tachyon I have opened Tachyon V2.3.spin and the extension files looking for clues. When I do I often get a warning "Not all unicode characters could be converted to ASCII". My favorite editor is The Semware Editor - known as QEdit with I first started using it. I have also noticed some characters that the editor displays as upper 128 code ASCII. I have also looked at the file in WordPad and seen those upper characters. Am I endangering the contents of those files if I have to save, for instance if I must customize a parameter? What would be a better editor to use? I luv my TSE.

[max72]

Tracy Allen made an integer only version of the sensirion (in spin). Maybe you can check it.

[D.P]

Would something like this be okay, assuming I had it ready to release?

pub  SatVP ( temp -- satVP )
    F32
    17.67 OVER F* 
    OVER 243.5 F+
    F/ FExp
    ;
pub CalcHumidity ( Atm Dryc Wetc -- rh )
    F32 3 LOCAL                      '' Select F32 notation and save inputs as locals (X1=Wetc)
    X2 SatVp                         '' dry bulb satVP
    X1 SatVp                         '' wet bulb satVP
    X2 X1 F- X3 F*
    0.00115 X1 F* 1.0 F+ ROT F*
    0.00066 F* F-                    '' VPa
    SWAP F/ 100.0 F*
    3 RELEASE
    ;

This is one way of doing it so you wouldn't need all those variables and that basically looks right I think.

Absolutely, I was looking at how many table entries I had to input and it's enormous. The problem gets real tricky around 95-100% consending RH, the saturation vapor equations become the most accurate.
Also your code makes perfect sense, I'm feeling the procedural syntax parasite leaving this host finally. One thing though is I don't see the DONATE button. [8>}

[Peter Jakacki]

I see what I did - omitted the "#P" in front of the port numbers. I guess that is a holdover from PF.

A multiple serial object sounds great. I am going to be running three serial peripherals. If you could include support for 7 bit with 2 stop bits that would be sweet. I know that stuff is oooold but I am building a kludge that needs it, maybe. The 7 bits would be for a Protek 506 DMM. I had run successful tests with the DMM and the hp48 using 8 bits on the calculator and just clearing the hi bit of data received. I expected the same to work on the Propeller but I couldn't get it going with PropForth even with very extensive experimentation which I believe eliminated all other possible causes. I'm hoping Tachyon is different in that respect.

Cheers . . .

The # forces the number to decimal and the P is ignored as these prefix number modes allow symbols to be intermixed in a number, writing #P6 just helps us to see it is P6, the port pin.

There is really no problem with running this at the moment using SERIN and SEROUT with the SERIN as part of a little buffer code running in their own cogs. I got some code I've used in other applications that I will post back up on the Intro page, so have a look back there soon. It's very easy to custom craft your own serial I/O in this fashion as it is all high level Forth, no PASM, and their are plenty of cogs available.

[Peter Jakacki]

I asked about fixed point math operators in Tachyon because I'm having difficulty with an approach to translate some of my spin code.

UPDATE: Let's just forget this I'm gonna implement a table lookup method with smoothing, for the Buck method below I probably should use an off board MCU

Would something like this be okay, assuming I had it ready to release?

pub  SatVP ( temp -- satVP )
    F32
    17.67 OVER F* 
    OVER 243.5 F+
    F/ FExp
    ;
pub CalcHumidity ( Atm Dryc Wetc -- rh )
    F32 3 LOCAL                      '' Select F32 notation and save inputs as locals (X1=Wetc)
    X2 SatVp                         '' dry bulb satVP
    X1 SatVp                         '' wet bulb satVP
    X2 X1 F- X3 F*
    0.00115 X1 F* 1.0 F+ ROT F*
    0.00066 F* F-                    '' VPa
    SWAP F/ 100.0 F*
    3 RELEASE
    ;

This is one way of doing it so you wouldn't need all those variables and that basically looks right I think.

[artkennedy]

I see what I did - omitted the "#P" in front of the port numbers. I guess that is a holdover from PF.

A multiple serial object sounds great. I am going to be running three serial peripherals. If you could include support for 7 bit with 2 stop bits that would be sweet. I know that stuff is oooold but I am building a kludge that needs it, maybe. The 7 bits would be for a Protek 506 DMM. I had run successful tests with the DMM and the hp48 using 8 bits on the calculator and just clearing the hi bit of data received. I expected the same to work on the Propeller but I couldn't get it going with PropForth even with very extensive experimentation which I believe eliminated all other possible causes. I'm hoping Tachyon is different in that respect.

Cheers . . .

[Brian Riley]

I sell a kit for the MT8870 chip for $5 plus $2 S&H ... it includes the chip, crystal, socket and three 1% precision resistors and two caps. You can find it here at my website.

[D.P]

I asked about fixed point math operators in Tachyon because I'm having difficulty with an approach to translate some of my spin code.

UPDATE: Let's just forget this I'm gonna implement a table lookup method with smoothing, for the Buck method below I probably should use an off board MCU

{{
Calculate the relative humidity from a dry buld and wet bulb pair using the calculated staturation
vapor pressure at each bulb.
}}


CON
  _CLKMODE = XTAL1 + PLL16X
  _XINFREQ = 5_000_000

OBJ
  f32           : "F32"

VAR
  Long  VPa     'Actual Vapor Pressure
  Long  Sd      'Saturation VP at dry bulb
  Long  Sw      'Saturation VP at wet bulb
  Long  Dryc    'Dry bulb temp in C
  Long  Wetc    'Wet bulb temp in C
  Long  Atm     'Atmospheric pressure in millibars
  Long  PerHum  'Percent Humidity

PUB  CalcHumidity
        'Saturation Vapour Pressure at Dry Temp in millibars
        Sd := 6.112 * f32.Exp(f32.FDiv(f32.FMul(17.67, Dryc), f32.FAdd(243.5, Dryc)))

        'Saturation Vapour Pressure at Wet Bulb in millibars
        Sw := 6.112 * f32.Exp(f32.FDiv(f32.FMul(17.67,  Wetc), f32.FAdd(243.5, Wetc)))

        'Actual Vapour Pressure in millibars
	VPa  := f32.FSub(Sw, f32.FMul(0.00066, f32.FMul(f32.FAdd(1.0, f32.FMul(0.00115,Wetc)), f32.FMul(f32.FSub(Dryc, Wetc),Atm))))

        'Humidity Percentage
	PerHum := f32.FMul(100.0, f32.FDiv(VPa, Sd))

[Peter Jakacki]

Or the BU8872 from DigiKey for a couple of bucks, it has 3-wire serial data interface.

[D.P]

A task which may be interesting to someone on this thread, the Forth skills for which I am currently lacking: DTMF decoding. There are chips which can perform this function, but they require 6 I/O pins (D0...D3, ENA#, Dataready). For the overall project I'm working on, I have a "spare cog" which could spend its time doing this if it's doable and reliable (1 pin certainly is nicer than 6).

For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).

I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.

For the HT9170B at 2.45 a chip and 4 IOs not counting ENB or PWRdn (both could be held static)
http://www.ebay.com/itm/HT9170B-HT91...-/200494796632

[Peter Jakacki]

A task which may be interesting to someone on this thread, the Forth skills for which I am currently lacking: DTMF decoding. There are chips which can perform this function, but they require 6 I/O pins (D0...D3, ENA#, Dataready). For the overall project I'm working on, I have a "spare cog" which could spend its time doing this if it's doable and reliable (1 pin certainly is nicer than 6).

For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).


I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.

Phil Pilgrim did a BELL 202 1200 baud modem object a while back so you could apply some of those techniques I guess but Phil also did some DTMF work here too.

BTW: if you need any of those 8870 and 8880 (I think) DTMF chips I think I still have tubes of them from years back.

[Chameleon]

A task which may be interesting to someone on this thread, the Forth skills for which I am currently lacking: DTMF decoding. There are chips which can perform this function, but they require 6 I/O pins (D0...D3, ENA#, Dataready). For the overall project I'm working on, I have a "spare cog" which could spend its time doing this if it's doable and reliable (1 pin certainly is nicer than 6).

For those not familiar with DTMF (Dual-tone Multi-frequency), it's the touch tones used in phone dialers, which is ubiquitous in Amateur radio control in addition to landline phones. It is a 4x4 matrix of non harmonically related tones between 697 and 1633 Hz mixed to create 16 sinusoidal waveforms. Thankfully, the tones were well thought out to avoid problems with harmonics and intermod, and the specs for tone accuracy are nice and tight (<1.8% deviation).

I have barely started thinking about how to determine frequency of a single-frequency square wave via Forth, let alone a dual tone sinusoidal wave. Anyone have any thoughts, or is it better to spend the 6 pins? I tend to jump in with both feet, and have done so with Forth, so easier to develop isn't necessarily better, if the end result is reliable with a smaller pin count. I'm definitely not looking for anyone to do it for me (where's the fun of learning in that?), but would be thankful for some pointers.

[D.P]

Any plans to add fixed point math operators to Tachyon?

OH HOLY COW you really cleaned up the loader in the lastest kernel, really nice.

00:00:00  End of source code, 2889 lines processed and 0000 errors found 
Load time = 2,714ms

NAMES:  $5E70...74EF for 5759 (3245 bytes added)
CODE:   $0000...3101 for 6786 (6401 bytes added)
CALLS:  0500 vectors free
RAM:    11631 bytes free

[Peter Jakacki]

I have been testing for output on a serial port I have set up on P27-Tx P26-Rx at 9600 baud. I have successfully made this test in PropForth.

I did the test shown under REDIRECTING OUTPUT.

I found that currently the correct entry is "9600 SERBAUD" by consulting the WORDS list.

Seemed to run okay on the Prop side but I received no output using an hp48 calculator as I have before.

I'm wondering if the fact I'm running with a 5 MHz clock and 16x PLL means I need to alter the parameter for SERBAUD.

An example of redirecting output is shown in the Intro where we need to define an EMIT or output word that the emit vector can point to and then we have an example of creating a word that sets that vector, in the case of a serial LCD we just say LCD ." whatever I tell you" CON and it will appear on the LCD. The 9600 SERBAUD only refers to setting the baudrate for the SEROUT word, nothing more. There are many many things in common between PropForth and Tachyon and perhaps many more differences, so consult the Intro as I try to cover the basics in this plus I just update it on the fly as required so it's always up-to-date as are all the Google webpage documents.

Say the HP calc is on P27 we can define the output as
: HPEMIT #P27 SEROUT ;
: HPKEY #P267 SERIN ;
: HP ' HPEMIT uemit W! ' HPKEY ukey W! ;
This may need some refinement and it's probably not as nice as having a proper multiport serial object running, but it's what I have used until now. There will be an upgrade soon to the serial cog to handle multiple serial ports.

[artkennedy]

I have been testing for output on a serial port I have set up on P27-Tx P26-Rx at 9600 baud. I have successfully made this test in PropForth.

I did the test shown under REDIRECTING OUTPUT.

I found that currently the correct entry is "9600 SERBAUD" by consulting the WORDS list.

Seemed to run okay on the Prop side but I received no output using an hp48 calculator as I have before.

I'm wondering if the fact I'm running with a 5 MHz clock and 16x PLL means I need to alter the parameter for SERBAUD.

[Peter Jakacki]

Thanks you two. All good now. Time to start playing with the code.

BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?

Not quite sure what you mean when you mean when you say it stop incrementing the lines etc as EXTEND.fth ends up processing 1615 lines but it doesn't count any comment blocks in there as the editor says that there are 2662 lines altogether. There are some words that echo even during a load and I suppose it would be really nice if they didn't maybe and that line numbers reflected the actual line itself and so on but normally these things aren't of great concern itself. Certainly if I was producing this Forth as a commercial product I would clean it up but the big emphasis in development is on actual use and runtime performance etc. That doesn't mean I won't tidy up some of these cosmetic details though as I would find them useful too, but there are only so many hours in a day to maintain and improve Tachyon and also to get my work done

But thanks for the feedback, I do take note and it's always good to get someone's first impressions, the hiccups they come across etc. I'm looking into a few of these things right at this moment.

EDIT: originally the tilde sequences [~ and ]~ were interpreted by the serial driver as well but these have since been removed. It may well be that I remove the requirement for tilde words altogether in updates and just have dummy words for them for legacy source.

EDIT: I see the bug with the load time report, I had introduced proper handling of nested braces a little while ago and that used the same spare location as the lap counter for counting the nesting levels. Fixed that up in the kernel so it's all good now.

[D.P]

Thanks you two. All good now. Time to start playing with the code.

BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?

Artifacts of the terminal session where [~ and ]~ suppress console "interaction", from extend.fth below. As long as you get 0000 errors every thing is nice.

\ start of load symbol - suppress console interaction

pub [~                  OFF ECHO OFF OK ' LEMIT uemit W! ;        

\ end of load symbol - reenable interactive console

pub ]~                  ON ECHO ON OK 0 uemit W! ;

[artkennedy]

Thanks you two. All good now. Time to start playing with the code.

BTW, I've noticed something strange when loading the *.fth files. The console echo of the loading process stops incrementing lines at the bottom of the page and just screen prints over and over on the same line. Any idea why?

[Peter Jakacki]

The file in the drop box has a tick in it where it shouldn't it seems

\ ----- RTC has been tested
( S-35390A RTC )`         \ <--- remove that tick

Also I had to increase my line delay to 40ms, maybe because, well let's just let Peter answer this.

00:00:10  End of source code, 0084 lines processed and 0000 errors found 
Load time = 45,285ms

I fired up a Win7 system with TeraTerm and a standard Parallax Prop demo board and cleaned up the tick in QS.FTH. Everything loaded fine with the standard Prop tool and with TeraTerm set to 20ms. Load time for QS.FTH was 4.2 secs so everything is fine so far. Since QS.fth does not automatically perform a BACKUP then any reset at this stage will lose QS.fth. I have just added the ?BACKUP word to the end of the document now so that it locks itself into EEPROM.

I can't see why there should be any other problems though. It doesn't matter if QS has the pin definitions for parts that haven't been loaded, it won't hurt.

EDIT: updated the versions and checked them though there seems to be an error in reporting the loading time, the actual time is much shorter, so I will check that but I think it is probably a temporary Forth register problem.

Note: It looks like extend.fth is not hte most current version as I removed QWORDS from the current version and extended WORDS with an optional control switch to modify the listing. Maybe I will change that back so that I still have one definition for WORDS but add QWORDS name to do the same thing as it did before.

[D.P]

Back again . . . I am using a QuickStart board - so after installing Tachyon and EXTEND.FTH I also attempted to install QS.FTH without success.
After ^C it does not show as a Module Loaded.

Do I need to edit the W5200 stuff out of the QS.FTH file?

The file in the drop box has a tick in it where it shouldn't it seems

\ ----- RTC has been tested
( S-35390A RTC )`         \ <--- remove that tick

Also I had to increase my line delay to 40ms, maybe because, well let's just let Peter answer this.

00:00:10  End of source code, 0084 lines processed and 0000 errors found 
Load time = 45,285ms

[artkennedy]

Back again . . . I am using a QuickStart board - so after installing Tachyon and EXTEND.FTH I also attempted to install QS.FTH without success.
After ^C it does not show as a Module Loaded.

Do I need to edit the W5200 stuff out of the QS.FTH file?

[artkennedy]

Thanks, Peter and D.P. Did what you said and it looks like I have a good beginning.

Over on PropForth I have a thread going "Learning Forth" where I was getting a lot of help from Loopy, who suggested I try Tachyon. Posted quite a bit about what I am doing.

I have some experience *long-ago* working with Forth on a New Micros Inc. board. I have a ways to go to wake all that up but it is now forward ho!

I am sure I will have more questions and I do thank your for responding so quickly.

[Peter Jakacki]

Howdy, I have been working with (learning) PropForth and have decided to try Tachyon. My first attempts at loading it have failed.
My process:
- load Tachyon V2.3.spin in the PropTool and press f11.
- kill PropTool.
- Load TerraTerm and connect to QuickStart board.
- Find nothing on screen, press CR several times
- note typical response: "ææææææææææææææææææææææææææææææææ?øøø"
Theories:
- something "bad" is still in eeprom from working with PropForth
- Tachyon doesn't like having three Sparkfun Max232 adapters pulgged into P22-27.
- don't know what else.

Any suggestions?

[ A BIT LATER: Changed baud rate in TerraTerm from 230400 to 115200. Got "ok." Yeehaw. ]

I have been reading Introduction to TACHYON Forth
and I like what I see.

Hi art, welcome to the Tachyon Forth thread.

Remeber to change the clock setup and baud rate to suit your system, in mine it is normally set to 10MHz and 230400 baud. If you look at the published web document version you will find the section not too far down from the top that looks like this:

CON

_clkmode        = xtal1 + pll8x         ' <---------------- change to suit
_xinfreq        = 10_000_000                ' <---------------- change to suit your crystal
baud                = 230400                ' <-- change - tested from 300 baud to 3M baud

Normally the clock is 5_000_000 and the _clkmode is xtal1+pll16x


For convenience you can leave TeraTerm up when you use the Proptool, but just disconnect TeraTerm from the port first (alt+F,D from memory) and then reconnect again with alt+S, E and that makes it a lot less awkward. Just remember that the baudrate is the actual baudrate, there is no magic calculation with it. Generally when a system responds to your input but comes up with garbage you can cycle through your terminal baud rates to find out which it is set to.


So my theory is that your settings will be incorrect and once that is sorted out the welcome message will pop up on the screen. BTW, Tachyon will always respond to a break condition by rebooting so this works at any baud rate of course. In TermTerm you hit alt+B to send a break.

Don't forget to set TeraTerm to a 20ms "line" delay, no handshake mode for pasting or sending large files. Straight after you have used the Proptool to load in the compiled kernel you should load EXTEND.fth as well.

[D.P]

Tip: make sure you change your TeraTerm Setup->Port Transmit delay to around 23 msec/line, no char delay before you cut and pasted EXTEND.fth or you own code into the terminal for compilation.

.PINS
.INFO

Now back to your project (hardware, software, mechanical...) because a bunch of accidental complexity (compilers, linkers, sealed libraries, downloaders, separate terminal) has just been removed for you with this Tachyon / FORTH implementation, hat tip to PeterJ

I would recommend reading the Intro multiple times and doing each example multiple times, it can be very frustrating at first comming from a purely procedural programming background.

I can help with basic questions.

Enjoy, welcome to the fun side.

[artkennedy]

Howdy, I have been working with (learning) PropForth and have decided to try Tachyon. My first attempts at loading it have failed.
My process:
- load Tachyon V2.3.spin in the PropTool and press f11.
- kill PropTool.
- Load TerraTerm and connect to QuickStart board.
- Find nothing on screen, press CR several times
- note typical response: "ææææææææææææææææææææææææææææææææ?øøø"
Theories:
- something "bad" is still in eeprom from working with PropForth
- Tachyon doesn't like having three Sparkfun Max232 adapters pulgged into P22-27.
- don't know what else.

Any suggestions?

[ A BIT LATER: Changed baud rate in TerraTerm from 230400 to 115200. Got "ok." Yeehaw. ]

I have been reading Introduction to TACHYON Forth
and I like what I see.

[max72]

Now in saying all this I have been meaning to release a version where the high speed serial cog can switch to a slower speed but handle multiple full duplex buffered channels. At slower speeds it makes more sense to buffer transmit data so the system would switch it's emit vector over to the serial cog instead. This has uses in many applications where I don't need high speed but multiple serial ports.

That would be a great addition...

[Peter Jakacki]

Been trying to connect, sometimes I get part of the home page followed by garbled data and sometimes I get just a reset.
Probably between updates again.

Mac OSX 10.8.5 and I tried Safari, FF and Chrome

I think I need to adjust timeouts and I'm sure I have a bug in that I am disconnecting too early sometimes. Just haven't had time to check it properly, sorry. But once I fine tune it I will pile some real info onto the unit. Basically all the Tachyon support files etc. More than likely I will have more than one unit running and the RS232 and RS485 and Bluetooth ports running to some other Prop stuff. Since I have a couple of webcams floating around I could have one or two monitoring actual motor control, I'd like to do a robot arm --> pub THIRSTY REACH OPEN BEER GRASP SERVE ; . Anyway, whatever I hook up it will be educational and fun. (P.S. Parallax, C may be "educational" as in institutions, but it ain't fun).

[D.P]

I've been seeing some weird traffic come through and some of the requests are invalid with really long urls. I don't know whether a request for //log0001.txt is valid though but I will add the code to handle it as it should be /log001.txt.

2014/02/14 14:08:39 #6 CONNECT 
2014/02/14 14:08:39 #6 GET /log0001.txt
HTTP/1.1
Host: 192.168.16.150:82
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6


2014/02/14 14:08:40 #6  --> LOG0001.TXT
2014/02/14 14:08:40 #6 BLKSEND @010C.7E00  for 0000.102B
2014/02/14 14:08:40 #6 BLKSEND COMPLETE 
2014/02/14 14:08:40 #6 DISCONNECTING --- DISCONNECTED 
2014/02/14 14:08:41 #6   CLOSING   ok

Normal remote connect to tachyonforth.com

2014/02/14 14:20:11 #4 CONNECT 
2014/02/14 14:20:11 #4 GET /
HTTP/1.1
Host: tachyonforth.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: max-age=259200
Connection: keep-alive


2014/02/14 14:20:11 #4 CONTENT = text/html
2014/02/14 14:20:11 #4  --> HOME.HTM
2014/02/14 14:20:11 #4 BLKSEND @0107.5E00  for 0002.70C1
2014/02/14 14:20:13 #4 BLKSEND COMPLETE 
2014/02/14 14:20:13 #4 DISCONNECTING --- DISCONNECTED 
2014/02/14 14:20:14 #4   CLOSING 
2014/02/14 14:20:14 #4 CONNECT 
2014/02/14 14:20:14 #4 GET /image
HTTP/1.1
Host: tachyonforth.com
Accept: image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Referer: http://tachyonforth.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: max-age=259200
Connection: keep-alive


2014/02/14 14:20:14 #4  --> IMAGE
2014/02/14 14:20:14 #4 BLKSEND @0109.EE00  for 0000.3F4C
2014/02/14 14:20:14 #4 BLKSEND COMPLETE 
2014/02/14 14:20:15 #4 DISCONNECTING --- DISCONNECTED 
2014/02/14 14:20:15 #4   CLOSING

Been trying to connect, sometimes I get part of the home page followed by garbled data and sometimes I get just a reset.
Probably between updates again.

Mac OSX 10.8.5 and I tried Safari, FF and Chrome

[Peter Jakacki]

@Peter

I notice in your Tachyon V2.3 code that cog 0 is left with only the serial receive PASM code.
Why not do receive and transmit in the same cog?

Thanks
rich

At the time I first wrote Tachyon I didn't want to be limited by these relatively slow speeds, even 115k is a push for the full-duplex object and I know that the bit timing at this speed is flakey. If you want precise bit timing at high speeds for full duplex you have to dedicate a cog to receive and one to transmit. But my kernel code didn't waste time trying to buffer anything for transmit because at high speeds you are far better off just bashing out the bits yourself (cog-wise speaking that is). So when I published Tachyon it was working at 3M baud and at this speed the Tachyon cog wastes little time transmitting. For a compromise, both for Bluetooth and for users who might be baud rate limited or were using PropForth I dropped the rate to it's present standard of 230,400 baud. Even my serial routines written in Tachyon Forth itself can handle these speeds too.

Now in saying all this I have been meaning to release a version where the high speed serial cog can switch to a slower speed but handle multiple full duplex buffered channels. At slower speeds it makes more sense to buffer transmit data so the system would switch it's emit vector over to the serial cog instead. This has uses in many applications where I don't need high speed but multiple serial ports.

[richaj45]

@Peter

I notice in your Tachyon V2.3 code that cog 0 is left with only the serial receive PASM code.
Why not do receive and transmit in the same cog?

Thanks
rich

[Peter Jakacki]

I've been seeing some weird traffic come through and some of the requests are invalid with really long urls. I don't know whether a request for //log0001.txt is valid though but I will add the code to handle it as it should be /log001.txt.

2014/02/14 14:08:39 #6 CONNECT 
2014/02/14 14:08:39 #6 GET /log0001.txt
HTTP/1.1
Host: 192.168.16.150:82
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6


2014/02/14 14:08:40 #6  --> LOG0001.TXT
2014/02/14 14:08:40 #6 BLKSEND @010C.7E00  for 0000.102B
2014/02/14 14:08:40 #6 BLKSEND COMPLETE 
2014/02/14 14:08:40 #6 DISCONNECTING --- DISCONNECTED 
2014/02/14 14:08:41 #6   CLOSING   ok

Normal remote connect to tachyonforth.com

2014/02/14 14:20:11 #4 CONNECT 
2014/02/14 14:20:11 #4 GET /
HTTP/1.1
Host: tachyonforth.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: max-age=259200
Connection: keep-alive


2014/02/14 14:20:11 #4 CONTENT = text/html
2014/02/14 14:20:11 #4  --> HOME.HTM
2014/02/14 14:20:11 #4 BLKSEND @0107.5E00  for 0002.70C1
2014/02/14 14:20:13 #4 BLKSEND COMPLETE 
2014/02/14 14:20:13 #4 DISCONNECTING --- DISCONNECTED 
2014/02/14 14:20:14 #4   CLOSING 
2014/02/14 14:20:14 #4 CONNECT 
2014/02/14 14:20:14 #4 GET /image
HTTP/1.1
Host: tachyonforth.com
Accept: image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Referer: http://tachyonforth.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cache-Control: max-age=259200
Connection: keep-alive


2014/02/14 14:20:14 #4  --> IMAGE
2014/02/14 14:20:14 #4 BLKSEND @0109.EE00  for 0000.3F4C
2014/02/14 14:20:14 #4 BLKSEND COMPLETE 
2014/02/14 14:20:15 #4 DISCONNECTING --- DISCONNECTED 
2014/02/14 14:20:15 #4   CLOSING

[Peter Jakacki]

Probably got it between builds:

 *No Card inserted!* *Card Error* *Card Error*  *No Card inserted!* *Card Error* *Card Error* HTTP/1.1 200 OK
Date: Tue, 03 Dec 2013 04:19:05 GMT
Server: Tachyon Forth 
Last Modified: Tue, 08 Nov 2011 05:41:05 GMT
Accept-Ranges: bytes
Content-Length: 0000
Connection: close
Content-Type: text/html

Yep, you did. I need to implement a STOR word now so I can transfer files to the card as well. That should take about 15 mins or so. So there will be times when it doesn't seem to work but just check back at random intervals (like now).

BTW, ROM.BIN contains the binary image made by SAVEROM so if your system is 10MHz you can probably load this otherwise all the current source files are there.

[D.P]

I've gotten back into doing a little bit more with the webserver and ftp, sorting out timeouts and ftp clients. Even though I am still doing some testing and adjusting I will probably leave a Prop hooked up at tachyonforth.com as it also hosts a straight clone of the "Introduction to Tachyon Forth" as the home page (although the TOC links still point to the Google doc at present). There are various types of files I leave on the card for testing including PDFs, and images etc and I will also include all the source code pages too. So a Tachyon Forth Prop is hosting a website about itself, for itself!

The unit will also have random text selections sent to it's RS232 port so it will be logging that also and normally you can see the text file by going to tachyonforth.com/log0001.txt etc. There have been some bugs I've noticed so I will probably log all console messages to the syslog.txt file as soon as I can including all those malware hack attacks I see coming in Please please hack the Prop, I wanna see you try.

Probably got it between builds:

 *No Card inserted!* *Card Error* *Card Error*  *No Card inserted!* *Card Error* *Card Error* HTTP/1.1 200 OK
Date: Tue, 03 Dec 2013 04:19:05 GMT
Server: Tachyon Forth 
Last Modified: Tue, 08 Nov 2011 05:41:05 GMT
Accept-Ranges: bytes
Content-Length: 0000
Connection: close
Content-Type: text/html

[Peter Jakacki]

I've gotten back into doing a little bit more with the webserver and ftp, sorting out timeouts and ftp clients. Even though I am still doing some testing and adjusting I will probably leave a Prop hooked up at tachyonforth.com as it also hosts a straight clone of the "Introduction to Tachyon Forth" as the home page (although the TOC links still point to the Google doc at present). There are various types of files I leave on the card for testing including PDFs, and images etc and I will also include all the source code pages too. So a Tachyon Forth Prop is hosting a website about itself, for itself!

The unit will also have random text selections sent to it's RS232 port so it will be logging that also and normally you can see the text file by going to tachyonforth.com/log0001.txt etc. There have been some bugs I've noticed so I will probably log all console messages to the syslog.txt file as soon as I can including all those malware hack attacks I see coming in Please please hack the Prop, I wanna see you try.

[D.P]

There is the SPIOD module which works just like the SPIO module except you can specify a delay. I have been sprucing up the Intro page and I have a little section in there about it which I will expand upon. Otherwise there is some Forth code in there under the CLOCK instruction usage that you can adapt. The TTL interface for the LCD sounds the easiest though.

Found it, got SPIOD to do the job, great! Thanks and nice work on the Intro page.

[Peter Jakacki]

Okay I can bit bang one out then, no worries. I thought there may be a way to (simply) down clock the current routine in the kernel The device is a legacy LCD that is built up on a custom board with multiple interface styles: ttl, rs232, SPI. The interface list 100kBps max for SPI.

There is the SPIOD module which works just like the SPIO module except you can specify a delay. I have been sprucing up the Intro page and I have a little section in there about it which I will expand upon. Otherwise there is some Forth code in there under the CLOCK instruction usage that you can adapt. The TTL interface for the LCD sounds the easiest though.

[D.P]

It's easy enough to write one in Forth then, even then you might some extra delays. I will look at some code for you. Which device is it anyway? It doesn't sound right and also the ksps refers to the samples/second, not the bps.

Okay I can bit bang one out then, no worries. I thought there may be a way to (simply) down clock the current routine in the kernel The device is a legacy LCD that is built up on a custom board with multiple interface styles: ttl, rs232, SPI. The interface list 100kBps max for SPI.

[Peter Jakacki]

SPIWR is clocking at 4MHz, way to fast for the devices I'm trying to talk with.

How can I slow this down, looking for 100ksps max.

It's easy enough to write one in Forth then, even then you might some extra delays. I will look at some code for you. Which device is it anyway? It doesn't sound right and also the ksps refers to the samples/second, not the bps.

[D.P]

SPIWR is clocking at 4MHz, way to fast for the devices I'm trying to talk with.

How can I slow this down, looking for 100ksps max.

[Peter Jakacki]

Success!!

  Propeller .:.:--TACHYON--:.:. Forth V23140203.0000                            
                                                                                
NAMES:  $5EA5...74EB for 5702 (3188 bytes added)                                
CODE:   $0000...30F9 for 6835 (6393 bytes added)                                
CALLS:  0506 vectors free                                                       
RAM:    11692 bytes free                                                        
                                                                                
AUTORUN EXTEND.boot                                                             
MODULES LOADED:                                                                 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140211-1100

Thanks, I did not know where to put this line delay config. BTW, congrats for your 3000th forum post

Great! Have fun and don't think twice about asking a question or making a suggestion, I can always ignore it
My 3000th post!? yikes, I think I talk too much, but then I have a look at some other forum members and then I realize why they always seem to have an opinion...... but even 3000 posts are a lot, say if each one took 4 minutes average, that's 12,000 minutes or 200 hours....now I know where all the time goes, and yes, that erco character is to blame too.

[FredBlais]

Success!!

  Propeller .:.:--TACHYON--:.:. Forth V23140203.0000                            
                                                                                
NAMES:  $5EA5...74EB for 5702 (3188 bytes added)                                
CODE:   $0000...30F9 for 6835 (6393 bytes added)                                
CALLS:  0506 vectors free                                                       
RAM:    11692 bytes free                                                        
                                                                                
AUTORUN EXTEND.boot                                                             
MODULES LOADED:                                                                 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140211-1100

Thanks, I did not know where to put this line delay config. BTW, congrats for your 3000th forum post

[Peter Jakacki]

here is what I get :

Sounds like you don't have line delay set. Type ^A T D in minicom and make sure it's set to 20
D - Newline tx delay (ms) : 20

[FredBlais]

here is what I get :

  Propeller .:.:--TACHYON--:.:. Forth V23140203.0000                            
 Cold start - no user code - setting defaults                                   
----------------------------------------------------------------                
TACHYON                                                                         
  Propeller .:.:--TACHYON--:.:. Forth V23140203.0000                            
 ok                                                                             
0000  ok                                                                        
0001  ok.fth )                                                                  
0002  ok                                                                        
0003  okND.fth    ." Primary extensions to TACHYON kernel - 140203-2145 " ;     
0004  ok                                                                        
0005  ok                                                                        
0006  ok                                                                        
\                                                                               
0007  ok                                                                        
0008  ok                                                                        
0009  ok                                                                        
0010  oko the latest Tachyon kernel web document )                              
0011  ok                                                                        
0012  ok                                                                        
0013  ok                                                                        
0014  ok                                                                        
0015  ok                                                                        
0016  ok                                                                        
0017  ok                                                                        
0018  ok                                                                        
\                                                                               
0019  ok                                                                        
0020  ok ( --  \ do nothing - vectorable ) ;                                    
0021  ok                                                                        
0022  ok                                                                        
0023  ok                                                                        
0024 K ( on/off -- \ enable/disable OK prompts including the autospace )        
0025                                                                            
0026 F 0 ELSE ' NOOP THEN prompt 2+ W!                                          
0027                                                                            
0028  ok                                                                        
0029  ok                                                                        
0030 CHO ( on/off --  \ set the ECHO flag on/off for controlling output )       
0031                                                                            
0032 1 flags ROT BIT!                                                           
0033                                                                            
0034  ok                                                                        
0035  ok                                                                        
0036  ok                                                                        
0037  ok                                                                        
\                                                                               
0038  ok                                                                        
pri LEMIT       DUP $0A <> IF (EMIT) ELSin  --> ELSin <-- NOT FOUND

[Peter Jakacki]

Sorry to disrupt any discussion here,

I have loaded Tachyon in my QuickStart board EEPROM and it works. Now I would like to add the EXTEND.fth file. I read the tutorial explanations :

The file is huge and contains spin comment, table of content, etc... is it the right file? https://docs.google.com/document/d/1...UVjmWXqSCU/pub
When I do a copy paste of all the file in my terminal (minicom on linux) it fails. Any advice?

Well I think you have run afoul of one of my late night edits, I've fixed that now. Yes, just select the lot and a paste into minicom will automatically filter out any non-text and it should work fine. You can type ^A F to send a break from minicom which will reset the Prop to start a clean load. The Google docs webpage version that you have grabs the header and footer of the document as well when you select all and that is why the header title is in brackets while the footer is a "Published blah blah blah which triggers an ignore line in Tachyon.

BTW, there's always the dropbox versions but the link you have will always be the latest to work from, and sometimes, not work from

[FredBlais]

Sorry to disrupt any discussion here,

I have loaded Tachyon in my QuickStart board EEPROM and it works. Now I would like to add the EXTEND.fth file. I read the tutorial explanations :

Select All and copy the text then paste this into your serial terminal which should have a line delay of around 20ms (no character delay) to allow time for Tachyon to process each line of source.

The file is huge and contains spin comment, table of content, etc... is it the right file? https://docs.google.com/document/d/1...UVjmWXqSCU/pub
When I do a copy paste of all the file in my terminal (minicom on linux) it fails. Any advice?

[D.P]

Yes, because in the old code BLINKERS could access the I index of the calling loop of TIMERTASK to ascertain which timer had timed out. With the new linked timers there is no index, however the address of the timer in question is available on the stack. The code would look like this then:

TABLE mytimers 8 8 * ALLOT     \ allot space for 8 doubles (leave next line blank!)

pub @mytimers    2* 2* 2* mytimers + ;

#16    == ledpins
TABLE blinkrates
    #50 || #500 ||
    #50 || #300 ||
    #50 || #150 ||
    #50 || #285 ||
    #50 || #175 ||
    #50 || #335 ||
    #50 || #100 ||
    #50 || #195 ||
pub BLINKER ( timeraddr -- timeraddr ) 
     DUP mytimers - 2/ 2/ 2/ >L            \ convert timeraddr to an IX index onto loop stack
     IX 2* 2* blinkrates +                \ point to a blinkrate for this timer 
     IX ledpins +                     \ point to the ledpin to use 
     DUP PIN@ IF PINCLR 2+ ELSE PINSET THEN    \ toggle the pin and (re)point to blinkrate
     W@ L> @mytimers TIMEOUT                \ Fetch and set that blinkrate (either the on or off one)
    ;
pub clrpin       I ledpins + PINCLR ;
pub BLINKERS ( flg -- ) 
    IF ' BLINKER ELSE ' clrpin THEN
     8 0 DO DUP I @mytimers ALARM 1 I @mytimers TIMEOUT LOOP DROP
     ;

This is ugly though and there are better ways of doing this with the new linked timers but this provides the correction to the existing code so you can see how it works.

I would prefer the concept of "idea compresssion" as to ugly, this has given me insight not yet gleaned from the source, thanks.

[Peter Jakacki]

I've tried to modify the BLINKERS code to use the new linked timers but no joy so far

TABLE mytimers 8 8 * ALLOT       \ allot for 8 doubles
: mytimers@ ( index -- addr )  8 * mytimers + ;
#16        == ledpins

TABLE blinkrates
        #50 || #500 ||
        #50 || #300 ||
        #50 || #150 ||
        #50 || #285 ||
        #50 || #175 ||
        #50 || #335 ||
        #50 || #100 ||
        #50 || #195 ||

pub BLINKER ( accesses index of calling loop )
       I 2* 2* blinkrates + I ledpins + DUP PIN@ IF PINCLR 2+ ELSE PINSET THEN W@ I mytimers@ TIMEOUT
    ;

pub clrpin           I ledpins + PINCLR ;

pub BLINKERS ( flg -- ) IF ' BLINKER ELSE ' clrpin THEN 8 0 DO DUP I mytimers@ ALARM 1 I mytimers@ TIMEOUT LOOP DROP ;

{ Usage:
ON BLINKERS   \ will activate the timers and blink functions
OFF BLINKERS  \ will cause the timers to timeout in the next millisecond and turnoff the LEDs  
}

." missing something here"

Yes, because in the old code BLINKERS could access the I index of the calling loop of TIMERTASK to ascertain which timer had timed out. With the new linked timers there is no index, however the address of the timer in question is available on the stack. The code would look like this then:

TABLE mytimers 8 8 * ALLOT     \ allot space for 8 doubles (leave next line blank!)

pub @mytimers    2* 2* 2* mytimers + ;

#16    == ledpins
TABLE blinkrates
    #50 || #500 ||
    #50 || #300 ||
    #50 || #150 ||
    #50 || #285 ||
    #50 || #175 ||
    #50 || #335 ||
    #50 || #100 ||
    #50 || #195 ||
pub BLINKER ( timeraddr -- timeraddr ) 
     DUP mytimers - 2/ 2/ 2/ >L            \ convert timeraddr to an IX index onto loop stack
     IX 2* 2* blinkrates +                \ point to a blinkrate for this timer 
     IX ledpins +                     \ point to the ledpin to use 
     DUP PIN@ IF PINCLR 2+ ELSE PINSET THEN    \ toggle the pin and (re)point to blinkrate
     W@ L> @mytimers TIMEOUT                \ Fetch and set that blinkrate (either the on or off one)
    ;
pub clrpin       I ledpins + PINCLR ;
pub BLINKERS ( flg -- ) 
    IF ' BLINKER ELSE ' clrpin THEN
     8 0 DO DUP I @mytimers ALARM 1 I @mytimers TIMEOUT LOOP DROP
     ;

This is ugly though and there are better ways of doing this with the new linked timers but this provides the correction to the existing code so you can see how it works.

[D.P]

Given this linked timer code which works for me:

\ demo LED flasher which takes 5 and 3 seconds before it starts flashing every 100ms and 150ms

DOUBLE blinktimer1
DOUBLE blinktimer2

WORD blinky1
WORD blinky2

: BLINKY1
         #15 PIN@ 0= #15 PIN!                        \ toggle pin 15
         blinky1 W@ blinktimer1 TIMEOUT              \ reload timer
         ;
: BLINKY2
         #14 PIN@ 0= #14 PIN!                        \ toggle pin 14
         blinky2 W@ blinktimer2 TIMEOUT               \ reload timer
         ;

\ Setup the timeout vector for TIMER blinktimer1, 2

' BLINKY1 blinktimer1 ALARM
' BLINKY2 blinktimer2 ALARM

\ Write a reload value to timer's memory which we can change anytime

#100 blinky1 W!
#150 blinky2 W!

\ Setup timer 0 to timeout in 5 seconds

#5,000 blinktimer1 TIMEOUT
#3,000 blinktimer2 TIMEOUT

I've tried to modify the BLINKERS code to use the new linked timers but no joy so far

TABLE mytimers 8 8 * ALLOT       \ allot for 8 doubles
: mytimers@ ( index -- addr )  8 * mytimers + ;
#16        == ledpins

TABLE blinkrates
        #50 || #500 ||
        #50 || #300 ||
        #50 || #150 ||
        #50 || #285 ||
        #50 || #175 ||
        #50 || #335 ||
        #50 || #100 ||
        #50 || #195 ||

pub BLINKER ( accesses index of calling loop )
       I 2* 2* blinkrates + I ledpins + DUP PIN@ IF PINCLR 2+ ELSE PINSET THEN W@ I mytimers@ TIMEOUT
    ;

pub clrpin           I ledpins + PINCLR ;

pub BLINKERS ( flg -- ) IF ' BLINKER ELSE ' clrpin THEN 8 0 DO DUP I mytimers@ ALARM 1 I mytimers@ TIMEOUT LOOP DROP ;

{ Usage:

ON BLINKERS   \ will activate the timers and blink functions

OFF BLINKERS  \ will cause the timers to timeout in the next millisecond and turnoff the LEDs  

}

." missing something here"

[potatohead]

I think so too.

[David Betz]

Telnet, a web server, fast execution, and on and on. I find it amazing that you've been able to squeeze so much into an unexpanded Propeller using Tachyon. It is certainly a work of art.

[Peter Jakacki]

Well as I said before, benchmarks are useful tools but they don't tell you everything. It is possible to compile down to PASM and dedicate a cog to nothing else but the benchmark. How about that same benchmark running in a TELNET session perhaps? Out of the same cog too? That would be a treat!
Here it is, the raw output including pasting and compiling through telnet...

peter@peter-XPS-L702X-LM16 ~ $ telnet 192.168.16.151
Trying 192.168.16.151...
Connected to 192.168.16.151.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!

  ok

\ fibonacci - iterative method - but skip test for n = 0
: fibo ( n -- f )
  0 1                           \ Setup initial calculations "0 1"  
  ROT                           \ for n times
  FOR 
    OVER + SWAP                 \ next iteration -> result prev
  NEXT
  DROP                          \ discard the prev result, leave the current result
  ;
   
\ fibonacci test - just a Q&D one liner
DECIMAL
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo  .LAP ."  result =" . LOOP
  ok

n -- f ) 


 

 

  ok
  ok

  ok
fibo(") = " result =" 
fibo(1) = 13us result =1
fibo(2) = 16us result =1
fibo(3) = 19us result =2
fibo(4) = 22us result =3
fibo(5) = 25us result =5
fibo(6) = 28us result =8
fibo(7) = 31us result =13
fibo(8) = 34us result =21
fibo(9) = 37us result =34
fibo(10) = 40us result =55
fibo(11) = 43us result =89
fibo(12) = 46us result =144
fibo(13) = 49us result =233
fibo(14) = 52us result =377
fibo(15) = 55us result =610
fibo(16) = 58us result =987
fibo(17) = 61us result =1597
fibo(18) = 64us result =2584
fibo(19) = 67us result =4181
fibo(20) = 70us result =6765
fibo(21) = 73us result =10946
fibo(22) = 76us result =17711
fibo(23) = 79us result =28657
fibo(24) = 82us result =46368
fibo(25) = 85us result =75025
fibo(26) = 88us result =121393 ok

Note: looks like I've got some echoed stuff from the compile spitting out later than sooner in telnet, something for me to look into.

EDIT: I've done an extra test of opening and logging the results to a file then listing that. All interactively via telnet of course.

peter@peter-XPS-L702X-LM16 ~ $ telnet 192.168.16.151
Trying 192.168.16.151...
Connected to 192.168.16.151.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!
\ fibonacci - iterative method - but skip test for n = 0
: fibo ( n -- f )
  0 1                           \ Setup initial calculations "0 1"  
  ROT                           \ for n times
  FOR 
    OVER + SWAP                 \ next iteration -> result prev
  NEXT
  DROP                          \ discard the prev result, leave the current result
  ;

n -- f ) 


 

 

  ok
\ fibonacci test - just a Q&D one liner
DECIMAL
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo  .LAP ."  result =" . LOOP

  ok
fibo(") = " result =" 
fibo(1) = 13us result =1
fibo(2) = 16us result =1
fibo(3) = 19us result =2
fibo(4) = 22us result =3
fibo(5) = 25us result =5
fibo(6) = 28us result =8
fibo(7) = 31us result =13
fibo(8) = 34us result =21
fibo(9) = 37us result =34
fibo(10) = 40us result =55
fibo(11) = 43us result =89
fibo(12) = 46us result =144
fibo(13) = 49us result =233
fibo(14) = 52us result =377
fibo(15) = 55us result =610
fibo(16) = 58us result =987
fibo(17) = 61us result =1597
fibo(18) = 64us result =2584
fibo(19) = 67us result =4181
fibo(20) = 70us result =6765
fibo(21) = 73us result =10946
fibo(22) = 76us result =17711
fibo(23) = 79us result =28657
fibo(24) = 82us result =46368
fibo(25) = 85us result =75025
fibo(26) = 88us result =121393 ok
FOPEN LOG0008.TXT
...opened at 0000.3B67   ok
FOUTPUT 1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo  .LAP ."  result =" . LOOP CON 
cat LOG0008.TXT


fibo(") = " result ="  ok
...opened at 0000.3B67 

fibo(1) = 13us result =1
fibo(2) = 16us result =1
fibo(3) = 19us result =2
fibo(4) = 22us result =3
fibo(5) = 25us result =5
fibo(6) = 28us result =8
fibo(7) = 31us result =13
fibo(8) = 34us result =21
fibo(9) = 37us result =34
fibo(10) = 40us result =55
fibo(11) = 43us result =89
fibo(12) = 46us result =144
fibo(13) = 49us result =233
fibo(14) = 52us result =377
fibo(15) = 55us result =610
fibo(16) = 58us result =987
fibo(17) = 61us result =1597
fibo(18) = 64us result =2584
fibo(19) = 67us result =4181
fibo(20) = 70us result =6765
fibo(21) = 73us result =10946
fibo(22) = 76us result =17711
fibo(23) = 79us result =28657
fibo(24) = 82us result =46368
fibo(25) = 85us result =75025
fibo(26) = 88us result =121393  ok
  ok
 

[David Betz]

Tachyon maintains it stacks in cog registers, and doesn't allow for deep recursion. This is by design to provide the highest execution speed. It would be possible to implement the recursive fibo algorithm in Tachyon by implementing a secondary data stack. Prior to calling itself, fibo could move the contents of the data stack and the return address to the secondary stack. It would restore the values upon return from the recursively called fibo. This would prevent the data and return stacks from growing. It would require a few extra cycles to do this, but it would be an interesting exercise that might be useful for other applications.

No need to go to all that trouble. It's clear that Tachyon will be fast even with the recursive version of Fibo as is pfth. Both seem to be very capable languages for interactive programming of the Propeller! Congratulations to both of you!

[Dave Hein]

Tachyon maintains it stacks in cog registers, and doesn't allow for deep recursion. This is by design to provide the highest execution speed. It would be possible to implement the recursive fibo algorithm in Tachyon by implementing a secondary data stack. Prior to calling itself, fibo could move the contents of the data stack and the return address to the secondary stack. It would restore the values upon return from the recursively called fibo. This would prevent the data and return stacks from growing. It would require a few extra cycles to do this, but it would be an interesting exercise that might be useful for other applications.

[David Betz]

It's been bashed merciouly here David, over and over again. Without anyone giving it a chance, all the "gibberish" comments as if ANY computer syntax is straight forward to those not skilled in the art! I work with people just trying to make the lights blink and a Tachyon terminal lets me get them started thinking about how a computer works. For me it's about productivity and maintenance of a entire system, not about the language part that was used to develop a part of a system. I'm sick and tired of all the language wars and mine is bigger than yours BS. I've really struggled to learn Tachyon and FORTH since I was never exposed to any TIL lanaguges. I like the way I can have all my tools on the micro controller and frob chips from the terminal to get them to talk SPI, I2C and all the various vendor's hybrids of these "standards" as opposed to compile->link-download test, didn't work, do it all again!!! Look at the simplicity of some of the drivers Peter has wrote, it really shines here I think.
If you took serious offense to my comment, appologies. People are dying all over the world every second, it's only the spoiled who get to argue about what language is better than the other, just like religion. I want to build simple devices to try to help people who are much less advantaged than us. I find Tachyon / Forth is easier for me to try and accomplish my goals. I will refrain from all the noise on these forums, people are really pissed off here it seems.

I agree that Tachyon seems to be a very nice system. I never said otherwise as far as I can recall. I'd love to read about what cool things people are doing with it and with any other Propeller language or programming system. No need to try to push it on everyone else, just tell everyone about the great things you're doing with it and some will surely want to jump on board like you have.

[D.P]

It's been bashed merciouly here David, over and over again. Without anyone giving it a chance, all the "gibberish" comments as if ANY computer syntax is straight forward to those not skilled in the art! I work with people just trying to make the lights blink and a Tachyon terminal lets me get them started thinking about how a computer works. For me it's about productivity and maintenance of a entire system, not about the language part that was used to develop a part of a system. I'm sick and tired of all the language wars and mine is bigger than yours BS. I've really struggled to learn Tachyon and FORTH since I was never exposed to any TIL lanaguges. I like the way I can have all my tools on the micro controller and frob chips from the terminal to get them to talk SPI, I2C and all the various vendor's hybrids of these "standards" as opposed to compile->link-download test, didn't work, do it all again!!! Look at the simplicity of some of the drivers Peter has wrote, it really shines here I think.
If you took serious offense to my comment, appologies. People are dying all over the world every second, it's only the spoiled who get to argue about what language is better than the other, just like religion. I want to build simple devices to try to help people who are much less advantaged than us. I find Tachyon / Forth is easier for me to try and accomplish my goals. I will refrain from all the noise on these forums, people are really pissed off here it seems.

[David Betz]

Don't go hostile, the thread was all over the place, you need to chill. Learn Forth, increase idea density, prevent alzheimer's. Go play somewhere else if you can take a joke or be nice.

You don't think your comment sounded hostile or at least insulting? I'm sick of this "Forth is wonderful and better than anything else" mentality. I believe Forth has value but so do lots of other things including Spin and C/C++. This Forth cheerleading is getting tiresome.

[D.P]

This is a stupid comment. The point of the benchmark was to be able to compare various languages. That isn't possible if they don't all use the same algorithm. It isn't a statement about which algorithm is best. Of course the iterative one is the one you'd actually use if you wanted to compute Fibonacci numbers.

Don't go hostile, the thread was all over the place, you need to chill. Learn Forth, increase idea density, prevent alzheimer's. Go play somewhere else if you can take a joke or be nice.

[David Betz]

Also the comment "can you do a proper recursive version" as if the correct results are not correct because your syntax didn't curtsy correctly before emitting the results.
HA!

This is a stupid comment. The point of the benchmark was to be able to compare various languages. That isn't possible if they don't all use the same algorithm. It isn't a statement about which algorithm is best. Of course the iterative one is the one you'd actually use if you wanted to compute Fibonacci numbers.

[D.P]

Thanks for the REV SPIWR explanation Peter and:

\ fibonacci - iterative method - but skip test for n = 0
: fibo ( n -- f )
  0 1                           \ Setup initial calculations "0 1"  
  ROT                           \ rotate n to top of stack - for n times
  FOR 
    OVER + SWAP                 \ next iteration -> result prev
  NEXT
  DROP                          \ discard the prev result, leave the current result
  ;
   
\ fibonacci test - just a Q&D one liner
DECIMAL
1 26 ADO CR ." fibo(" I . ." ) = " NEWCNT I fibo  .LAP ."  result =" . LOOP

VS this Compile, Link, Download

/**
 * This is the main fiboiterative program file.
 *
 * Fibonnaci numbers skipping fibo(0).
 * Uses iterative (default) or recursive method.
 * Saves results and times in an array, then prints them.
 */
#include <stdio.h>
#include <unistd.h>
#include <propeller.h>

#define LAST 26

inline int fiboi(int num)
{
  int fibo  = 1;
  int fibo1 = 1;
  int fibo2 = 1;
  int j;
  
  if(num < 3) {
    return fibo;
  }
  else {
    fibo1 = 1;
    fibo2 = 1;
    for(j = 3; j <= num; j++) {
      fibo  = fibo1 + fibo2;
      fibo2 = fibo1;
      fibo1 = fibo;
    }
  }
  return fibo;
}

int fibor(int num)
{
  if (num < 3) {
    return 1;
  }
  return fibor(num-1) + fibor(num-2);
}

int main(void)
{
    int n;
    int times[LAST+1];
    int result[LAST+1];

    sleep(1); // startup time for SimpleIDE
    
    for(n = 1; n <= LAST; n++) {
        times[n]    = CNT;
        result[n]   = fiboi(n); // replace with fibor(n) for recursive function
        times[n]    = CNT-times[n];
    }
    if(times[LAST]*125/10000 < 100) {
        for(n = 1; n <= LAST; n++) {
            printf("fibo(%2d) = %6d (%4d ticks) (%dus)\n", n, result[n], times[n], times[n]*125/10000);
        }
    }
    else {
        for(n = 1; n <= LAST; n++) {
            printf("fibo(%2d) = %6d (%8d ticks) (%dms)\n", n, result[n], times[n], times[n]*125/10000000);
        }
    }
    return 0;
}

If I need a sub 10us Fibo routine it's time for an assembler RUNMOD, until then I have a life to live, THANK YOU Peter!!
Also the comment "can you do a proper recursive version" as if the correct results are not correct because your syntax didn't curtsy correctly before emitting the results.
HA!

[Peter Jakacki]

Okay I see what happened above.

Can you give an example of REV and SPIWR LSB please.

Thanks,

REV works exactly like the PASM REV, have a look at the kernel source here:

' REV ( n1 bits -- n2 ) Reverse LSBs of n1 and zero-extend
            rev    tos+1,tos
            jmp    #DROP

Here's a quick test loop:

$16 0 #32 ADO CR I .DEC SPACE DUP .BYTE SPACE DUP I REV .LONG LOOP                                                    
0000 16 6800.0000                                                                                               
0001 16 3400.0000                                                                                               
0002 16 1A00.0000                                                                                               
0003 16 0D00.0000                                                                                               
0004 16 0680.0000                                                                                               
0005 16 0340.0000                                                                                               
0006 16 01A0.0000                                                                                               
0007 16 00D0.0000                                                                                               
0008 16 0068.0000                                                                                               
0009 16 0034.0000                                                                                               
0010 16 001A.0000                                                                                               
0011 16 000D.0000                                                                                               
0012 16 0006.8000                                                                                               
0013 16 0003.4000                                                                                               
0014 16 0001.A000                                                                                               
0015 16 0000.D000                                                                                               
0016 16 0000.6800                                                                                               
0017 16 0000.3400                                                                                               
0018 16 0000.1A00                                                                                               
0019 16 0000.0D00                                                                                               
0020 16 0000.0680                                                                                               
0021 16 0000.0340                                                                                               
0022 16 0000.01A0                                                                                               
0023 16 0000.00D0                                                                                               
0024 16 0000.0068                                                                                               
0025 16 0000.0034                                                                                               
0026 16 0000.001A                                                                                               
0027 16 0000.000D                                                                                               
0028 16 0000.0006                                                                                               
0029 16 0000.0003                                                                                               
0030 16 0000.0001                                                                                               
0031 16 0000.0000 ok

So normally to reverse the lower 8-bits of a number we need to do a #24 REV

SPIWR is a simple word to clock out SPI data quickly but only at a fixed 8-bits at a time. SPI is normally sent MSB first so the data needs to be left justified to work so if you are sending 32-bits then it is already "left justified" in that the MSB is aligned with bit 31. To send all 32-bits just repeat the instruction like this SPIWR SPIWR SPIWR SPIWR after which there will be the shifted remains of the number left on the stack (always zero in this case). Execution time is 12us.

If you needed to shift 16-bits you would left justify first with a 16 SHL then SPIWR SPIWR which takes 8us
For 24 bits it's 8 SHL SPIWR SPIWR SPIWR which takes 11us
If you only need 8-bits there is the SPIWRB which left justifies the byte for you as this only takes one precious extra PASM instruction and is more efficient for an otherwise common operation which takes 3us

BTW, the SPIWR instruction has it's own pin mask registers, you can set them directly or else use SPIPINS ( ce-miso-mosi-clk -- ) where a long specifies the 4 pins to use.
i.e. Say we have chip enable on P27, clock on P24, MOSI on P25 and MISO on P26 (not used by SPIWR), the long is encoded as &27.26.25.24 SPIPINS which uses the Tachyon specific & byte encoded decimal notation as used in IP addresses to make it easier for us.

[mindrobots]

Hi Peter,

I have a Spinneret sitting idle and I thought I'd load Tachyon on it. My question is about the Wiznet 5100 module, it appears to have been written for kernel 2.1, has it been brought forward to work with 2.3 or would I be better off using 2.1 and a 2.1 compatible EXTEND.fth to go with it? My budget doesn't include a Wiznet 5200 for the QuickStart just now.

Thanks!

[D.P]

Okay I see what happened above.

Can you give an example of REV and SPIWR LSB please.

Thanks,

[Peter Jakacki]

This example has me stumped, going through the source trying some stuff out.

It's doing exactly what it should, once you went to print out the number pad with .DEC which uses the number pad to print itself (of course) you then went awry.
last number printed was....0050
then you did...
0048....the leading 0 of the 0050 and now the buffer has 0048
0048....the second 0 of 0048 and now the buffer has 0048
0052....the third digit 4 of 0048 and now the buffer has 0052
0050....the fourth digit 2 of 0052

See, perfect!

[D.P]

This example has me stumped, going through the source trying some stuff out.

[code]
ok
#1234 ok
<# #S #> ok
.S
STACK: 0000.0000 0000.0108 0000.04D2 0000.006B ok
$6B PRINT$ 1234 ok
$6B 4 ADO I C@ .DEC LOOP 0049004800520050 ok
$6B 4 ADO I C@ CR .DEC LOOP
0048
0048
0052
0050 ok
"1" .DEC 0049 ok
"2" .DEC 0050 ok
"3" .DEC 0051 ok
"4" .DEC 0052 ok
." Houston we have a stack problem?" Houston we have a stack problem? ok
." with ADO and I" with ADO and I ok
TACHYON
Propeller .:.:--TACHYON--:.:. Forth V23140203.0000
ok
0000 LES
MODULES LOADED:
1800: EXTEND.fth Primary extensions to TACHYON kernel - 140203-2145
ok


[\code]

[Peter Jakacki]

OK !!!!!!! I have a good load from the Dropbox files taken less than an HOUR ago.
--------------


Question #1 - I formatted the uSD using SD Format The volume name is TACHYON, Why does MOUNT command say it has no name ??

QUESTION #2 - Whats with FTP, I thought was working ... enclosed is my FileZilla session log while trying to d/l ROM.BIN

There are two names, the oemname and the volume name (and also the FAT name too):
MOUNT Mounted SD Card
Media mounted as E2C4.0203 mkdosfs SDL001 FAT32 Cluster size = 4,096 Sectors = 7,744,449 ok
Here the volume name is SDL001 and it's entry is in the root directory as well as the boot block:

@ROOT $40 XDUMP                                                                                           
0076_BE00:   53 44 4C 30  30 31 20 20   20 20 20 08  00 00 67 88   SDL001     ...g.                       
0076_BE10:   37 44 37 44  00 00 67 88   37 44 00 00  00 00 00 00   7D7D..g.7D......                       
0076_BE20:   4C 4F 47 30  30 30 38 20   54 58 54 20  00 00 77 88   LOG0008 TXT ..w.                       
0076_BE30:   37 44 37 44  00 00 29 0B   64 43 03 00  00 00 02 00   7D7D..).dC...... ok                    
7E00 100 XDUMP                                                                                            
0000_7E00:   EB 58 90 6D  6B 64 6F 73   66 73 00 00  02 08 20 00   .X.mkdosfs.... .                       
0000_7E10:   02 00 00 00  00 F8 00 00   10 00 04 00  00 00 00 00   ................                       
0000_7E20:   C1 2B 76 00  80 1D 00 00   00 00 00 00  02 00 00 00   .+v.............                       
0000_7E30:   01 00 06 00  00 00 00 00   00 00 00 00  00 00 00 00   ................                       
0000_7E40:   00 01 29 4A  88 38 EB 53   44 4C 30 30  31 20 20 20   ..)J.8.SDL001                          
0000_7E50:   20 20 46 41  54 33 32 20   20 20 0E 1F  BE 77 7C AC     FAT32   ...w|.                       
0000_7E60:   22 C0 74 0B  56 B4 0E BB   07 00 CD 10  5E EB F0 32   ".t.V.......^..2                       
0000_7E70:   E4 CD 16 CD  19 EB FE 54   68 69 73 20  69 73 20 6E   .......This is n                       
0000_7E80:   6F 74 20 61  20 62 6F 6F   74 61 62 6C  65 20 64 69   ot a bootable di                       
0000_7E90:   73 6B 2E 20  20 50 6C 65   61 73 65 20  69 6E 73 65   sk.  Please inse                       
0000_7EA0:   72 74 20 61  20 62 6F 6F   74 61 62 6C  65 20 66 6C   rt a bootable fl                       
0000_7EB0:   6F 70 70 79  20 61 6E 64   0D 0A 70 72  65 73 73 20   oppy and..press                        
0000_7EC0:   61 6E 79 20  6B 65 79 20   74 6F 20 74  72 79 20 61   any key to try a                       
0000_7ED0:   67 61 69 6E  20 2E 2E 2E   20 0D 0A 00  00 00 00 00   gain ... .......                       

I think what name gets set depends upon the formatting software that is used.

As for the FTP server, ahhhem, I had updated the main document with some improvements from my dev copy but it wasn't quite right it seems. There are older versions in dropbox you can used that are zipped up in the backups folder. It may be a day or two until I update the files with a stable version. The changes are mainly to improve client interoperability, speed, connection issues, timeouts etc.

BTW: the ECONNREFUSED message seems to happen with Filezilla but not with gFTP but it looks like FIleZilla sends out a SYN which is refused because it is already connected. I will have to check this out later but my software did work before.

[Brian Riley]

OK !!!!!!! I have a good load from the Dropbox files taken less than an HOUR ago.
--------------


Question #1 - I formatted the uSD using SD Format The volume name is TACHYON, Why does MOUNT command say it has no name ??

QUESTION #2 - Whats with FTP, I thought was working ... enclosed is my FileZilla session log while trying to d/l ROM.BIN

Status:	Connecting to 10.0.1.107:21...
Status:	Connection established, waiting for welcome message...
Response:	220 WELCOME TO THE TACHYON WIZNET FTP SESSION!
Command:	USER anonymous
Response:	 --> cUSER <-- NOT FOUND 
Error:	Could not connect to server
Status:	Waiting to retry...
Status:	Connecting to 10.0.1.107:21...
Status:	Connection established, waiting for welcome message...
Response:	220 WELCOME TO THE TACHYON WIZNET FTP SESSION!
Command:	USER anonymous
Response:	331 User admin OK. Password required
Command:	PASS **************
Response:	230 OK. Current restricted directory is /
Command:	SYST
Response:	215 Unix Type: L8
Command:	FEAT
Response:	211 Features supported
Status:	Server does not support non-ASCII characters.
Status:	Connected
Response:	UTF8
Response:	211 End
Status:	Retrieving directory listing...
Command:	PWD
Response:	257 "/" is your current location
Command:	TYPE I
Response:	200 TYPE is now I
Command:	PASV
Response:	227 Entering Passive Mode with port (10,0,1,107,179,240)
Command:	LIST
Response:	150 Here comes the directory listing
Response:	226 Directory send OK
Status:	Directory listing successful
Status:	Connecting to 10.0.1.107:21...
Status:	Connection attempt failed with "ECONNREFUSED - Connection refused by server".
Error:	Could not connect to server
Status:	Delaying connection for 5 seconds due to previously failed connection attempt...
Status:	Connecting to 10.0.1.107:21...
Status:	Connection attempt failed with "ECONNREFUSED - Connection refused by server".
Error:	Could not connect to server
Status:	Delaying connection for 5 seconds due to previously failed connection attempt...
Status:	Connecting to 10.0.1.107:21...
Status:	Connection attempt failed with "ECONNREFUSED - Connection refused by server".
Error:	Could not connect to server

[Peter Jakacki]

Yes, Peter, you did say in that thread, that you moved ".LIST" from MULTIFAT to NETWORK. But look again at what you had in NETWORK ... you defined a WORD "LIST" with no "." in its name and one of the words in the script is ".LIST" with a "." and it is nowhere else to be found.

pub LIST
      ON LANLED
    ." 150 Here comes the directory listing" CR
    CON CR REVERSE ." LIST REQUEST " PLAIN CR
    FTPDAT SOCKET CONNECT
    LAN .LIST                                \ Send off the directory listing in compatible format
    DISCONNECT
    FTP SOCKET LAN ." 226 Directory send OK" CR
    ;
IMMEDIATE

Yes, LIST is an FTP command and the word .LIST was made for it so that is why it was moved back to NETWORK although .LIST could be used directly there are the DIR and ls words. The move was only done a few days ago, do you have the current versions? I will double check the dropbox versions just to sure.

[Brian Riley]

See this post where I mentioned I had moved .LIST away from MULTIFILE over to NETWORK so I can fine tune this word as some FTP clients are fussy. The dropbox versions should be current.

Yes, Peter, you did say in that thread, that you moved ".LIST" from MULTIFAT to NETWORK. But look again at what you had in NETWORK ... you defined a WORD "LIST" with no "." in its name and one of the words in the script is ".LIST" with a "." and it is nowhere else to be found.

pub LIST
      ON LANLED
    ." 150 Here comes the directory listing" CR
    CON CR REVERSE ." LIST REQUEST " PLAIN CR
    FTPDAT SOCKET CONNECT
    LAN .LIST                                \ Send off the directory listing in compatible format
    DISCONNECT
    FTP SOCKET LAN ." 226 Directory send OK" CR
    ;
IMMEDIATE

[mindrobots]

Congratulations on creating an obvious success in the Propeller Community!!

[Peter Jakacki]

It's official, this thread has now had 77,777 views.

Couldn't believe it even got past 1,000 or even 10,000

[Peter Jakacki]

I am running 24 msecs in CoolTerm on my iMac ...

( S-35390A)' <--- this is a typo

TACHYON <--- another typo, it had the wrong "O", both easily fixed

BUTTTTTTTTT

NETWORK.FTH Line 220

pub LIST
      ON LANLED
    ." 150 Here comes the directory listing" CR
    CON CR REVERSE ." LIST REQUEST " PLAIN CR
    FTPDAT SOCKET CONNECT
    LAN .LIST                                \ Send off the directory listing in compatible format
    DISCONNECT
    FTP SOCKET LAN ." 226 Directory send OK" CR
    ;
IMMEDIATE

'.LIST' - I did some grep-ing and it does not seem to appear anywhere but here.

See this post where I mentioned I had moved .LIST away from MULTIFILE over to NETWORK so I can fine tune this word as some FTP clients are fussy. The dropbox versions should be current.

BTW, I've got no idea why you have the wrong O in TACHYON etc.

[Brian Riley]

Missing a ` and .LIST and TACHYON, all known good words, seems as if your line delay is not long enough during compilation, try adding some ms to your terminal line delay. I use 23ms in minicomm on my Macbook Pro, no char delay

I am running 24 msecs in CoolTerm on my iMac ...

( S-35390A)' <--- this is a typo

TACHYON <--- another typo, it had the wrong "O", both easily fixed

BUTTTTTTTTT

NETWORK.FTH Line 220

pub LIST
      ON LANLED
    ." 150 Here comes the directory listing" CR
    CON CR REVERSE ." LIST REQUEST " PLAIN CR
    FTPDAT SOCKET CONNECT
    LAN .LIST                                \ Send off the directory listing in compatible format
    DISCONNECT
    FTP SOCKET LAN ." 226 Directory send OK" CR
    ;
IMMEDIATE

'.LIST' - I did some grep-ing and it does not seem to appear anywhere but here.

[D.P]

OK

QS.FTH Line 91 --> ` <-- NOT FOUND

NETWORK.FTH LINE 1 --> TACHYON <-- NOT FOUND
LINE 220 --> .LIST <-- NOT FOUND

... darned if I know why a was wrong with "TACHYON" ... the Oh looked hinky so I simply retyped the word and it went through.

Missing a ` and .LIST and TACHYON, all known good words, seems as if your line delay is not long enough during compilation, try adding some ms to your terminal line delay. I use 23ms in minicomm on my Macbook Pro, no char delay

[Brian Riley]

OK

QS.FTH Line 91 --> ` <-- NOT FOUND

NETWORK.FTH LINE 1 --> TACHYON <-- NOT FOUND
LINE 220 --> .LIST <-- NOT FOUND

... darned if I know why a was wrong with "TACHYON" ... the Oh looked hinky so I simply retyped the word and it went through.

[Peter Jakacki]

To input a Time to TIME! you must encode 9:15:00pm as $15.0F.00 to get 21:15:00 on the console.

But the DATE! encoding is $14.02.02 to get 2014/02/02.

Is this intended or should TIME! use $21.15.00 as an input?

Good stuff with the updates!

I haven't used that feature so I haven't really checked it out either until now. I've been in a bit of a quandary as to how I want to store and handle the time but I have decided to keep it all in BCD format so now everything including the soft counting expects it to be BCD as that is how RTCs mostly handle it and very rarely do we need to do calculations or conversions.
$235950 TIME! ok
.TIME 23:59:51 ok
23:59:52 ok
23:59:53 ok
23:59:54 ok
23:59:56 ok
23:59:57 ok
23:59:58 ok
23:59:59 ok
23:59:59 ok
00:00:00 ok
00:00:01 ok
00:00:02 ok
00:00:02 ok

EDIT: repeat lines are reexecuted with ^X

EDIT: update also includes basic calendar functions so date will be maintained which also includes a backup to it's image in EEPROM so that it is maintained during resets etc.
2014/02/28 23:50:53 ok
2014/03/01 00:02:14 ok

[D.P]

Good stuff Brian, I will update those network files etc soon as well as I have been making some improvements.

UPDATES:
KERNEL: A few minor changes to the kernel for error reporting etc
EXTEND: Added HELP and REVECTOR where you can say REVECTOR CON MYCON and all compiled references to the old CON will now point to MYCON for instance.
MULTIFAT: Removed .LIST and added it to NETWORK so that this part can be customized for FTP
NETWORK: improved client interoperability etc, posting after I run some more tests.

I'm also looking at adding specialized dictionaries especially with reference to HTTP and FTP commands. For instance, I get caught trying to use the kernel word TYPE but it ends up with the immediate FTP word TYPE !!!

To input a Time to TIME! you must encode 9:15:00pm as $15.0F.00 to get 21:15:00 on the console.

But the DATE! encoding is $14.02.02 to get 2014/02/02.

Is this intended or should TIME! use $21.15.00 as an input?

Good stuff with the updates!

REBOOT 
  Propeller .:.:--TACHYON--:.:. Forth V23140203.0000

NAMES:  $5E9E...74EB for 5709 (3195 bytes added)
CODE:   $0000...30E0 for 6803 (6368 bytes added)
CALLS:  0505 vectors free
RAM:    11710 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140203-1300 
----------------------------------------------------------------
.DT 2000/00/00 00:00:12 ok
$14.02.02 DATE!  ok
.DT 2014/02/02 00:00:43 ok
$21.15.00 TIME!  ok
.DT 2014/02/02 33:21:02 ok
$15.0F.00 TIME!  ok
.DT 2014/02/02 21:15:01 ok

[Peter Jakacki]

EUREKA!!! IT WORKS

**almost** on the first try!!

File: QS.FTH, line 91 - extraneous tick to right of right paren

  Propeller .:.:--TACHYON--:.:. Forth V23140130.0000

NAMES:  $57C7...74EA for 7459 (4294966891 bytes added)
CODE:   $0000...4B26 for 11779 (2484 bytes added)
CALLS:  0224 vectors free
RAM:    3233 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
4172: NETWORK.fth         WIZNET NETWORK SERVERS 140128.1730 
3B09: W5200.fth           WIZNET W5200 driver 131211.1530 
31BC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
2A6C: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 140131.2130 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140131-1300 

----------------------------------------------------------------
GO 
NAMES:  $57C7...74EA for 7459 (4294966891 bytes added)
CODE:   $0000...4B26 for 11779 (2484 bytes added)
CALLS:  0224 vectors free
RAM:    3233 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
4172: NETWORK.fth         WIZNET NETWORK SERVERS 140128.1730 
3B09: W5200.fth           WIZNET W5200 driver 131211.1530 
31BC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
2A6C: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 140131.2130 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140131-1300 

*** Tachyon Forth Network and File Server *** 

Mounted SD Card 
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888
Listing directory 
NO NAME    

LOG0002 .TXT     LOG0001 .TXT     FAVICON .ICO     PARALLAX.PNG     HOME    .HTM     NETWORK .FTH     EXTEND  .FTH     CE1372  .FTH     
SDCARD  .FTH     MULTIFAT.FTH     W5200   .FTH     TACHYON .JPG     HTTP404 .HTM     LOGON   .        LOGON   .TXT     SYSLOG  .TXT     
ROM     .BIN     ROM3    .BIN     ROM2    .BIN     ROM1    .BIN     ROM0    .BIN     TACHYON .LST     LOG0008 .TXT     LOG0007 .TXT     
LOG0006 .TXT     LOG0005 .TXT     LOG0004 .TXT     LOG0003 .TXT     SPOTLI~1.        ~1      .TRA     TRASHE~1.        FSEVEN~1.        

Waiting for Ethernet to come up  ... ready! 

************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    010.000.001.107.
MASK      255.255.255.000.
GATEWAY   010.000.001.001.
MAC       00.08.80.C1.38.B6.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00     STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00     STAT=14 LISTEN 
4: MODE= TCP    PORT#00080 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00     STAT=14 LISTEN 
5: MODE= TCP    PORT#00081 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00     STAT=14 LISTEN 
6: MODE= TCP    PORT#00082 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00     STAT=14 LISTEN 
7: MODE= TCP    PORT#00083 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00     STAT=14 LISTEN 

* WEB, FTP, and TELNET servers running * 
 ok
Mounted SD Card 
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888
CONNECT   SOCKET #02000/01/04 55:00:11

Good stuff Brian, I will update those network files etc soon as well as I have been making some improvements.

UPDATES:
KERNEL: A few minor changes to the kernel for error reporting etc
EXTEND: Added HELP and REVECTOR where you can say REVECTOR CON MYCON and all compiled references to the old CON will now point to MYCON for instance.
MULTIFAT: Removed .LIST and added it to NETWORK so that this part can be customized for FTP
NETWORK: improved client interoperability etc, posting after I run some more tests.

I'm also looking at adding specialized dictionaries especially with reference to HTTP and FTP commands. For instance, I get caught trying to use the kernel word TYPE but it ends up with the immediate FTP word TYPE !!!

[Brian Riley]

EUREKA!!! IT WORKS

**almost** on the first try!!

File: QS.FTH, line 91 - extraneous tick to right of right paren

  Propeller .:.:--TACHYON--:.:. Forth V23140130.0000

NAMES:  $57C7...74EA for 7459 (4294966891 bytes added)
CODE:   $0000...4B26 for 11779 (2484 bytes added)
CALLS:  0224 vectors free
RAM:    3233 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
4172: NETWORK.fth         WIZNET NETWORK SERVERS 140128.1730 
3B09: W5200.fth           WIZNET W5200 driver 131211.1530 
31BC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
2A6C: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 140131.2130 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140131-1300 

----------------------------------------------------------------
GO 
NAMES:  $57C7...74EA for 7459 (4294966891 bytes added)
CODE:   $0000...4B26 for 11779 (2484 bytes added)
CALLS:  0224 vectors free
RAM:    3233 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
4172: NETWORK.fth         WIZNET NETWORK SERVERS 140128.1730 
3B09: W5200.fth           WIZNET W5200 driver 131211.1530 
31BC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
2A6C: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 140131.2130 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140131-1300 

*** Tachyon Forth Network and File Server *** 

Mounted SD Card 
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888
Listing directory 
NO NAME    

LOG0002 .TXT     LOG0001 .TXT     FAVICON .ICO     PARALLAX.PNG     HOME    .HTM     NETWORK .FTH     EXTEND  .FTH     CE1372  .FTH     
SDCARD  .FTH     MULTIFAT.FTH     W5200   .FTH     TACHYON .JPG     HTTP404 .HTM     LOGON   .        LOGON   .TXT     SYSLOG  .TXT     
ROM     .BIN     ROM3    .BIN     ROM2    .BIN     ROM1    .BIN     ROM0    .BIN     TACHYON .LST     LOG0008 .TXT     LOG0007 .TXT     
LOG0006 .TXT     LOG0005 .TXT     LOG0004 .TXT     LOG0003 .TXT     SPOTLI~1.        ~1      .TRA     TRASHE~1.        FSEVEN~1.        

Waiting for Ethernet to come up  ... ready! 

************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    010.000.001.107.
MASK      255.255.255.000.
GATEWAY   010.000.001.001.
MAC       00.08.80.C1.38.B6.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00	 STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00	 STAT=14 LISTEN 
4: MODE= TCP    PORT#00080 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00	 STAT=14 LISTEN 
5: MODE= TCP    PORT#00081 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00	 STAT=14 LISTEN 
6: MODE= TCP    PORT#00082 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00	 STAT=14 LISTEN 
7: MODE= TCP    PORT#00083 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00	 STAT=14 LISTEN 

* WEB, FTP, and TELNET servers running * 
 ok
Mounted SD Card 
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888
CONNECT   SOCKET #02000/01/04 55:00:11

[Peter Jakacki]

Dunno ...... it happened during copy/paste

I checked Spinnaret and WizNet schematics ... YES, same RTC chip for both Seiko S-35390a

Okay, so while I get around to testing the RTC you can either just define a dummy .DT or enable that untested code which won't hurt anything either.


EDIT: I have now tested the RTC code, that chip is really wired back-to-front and very non I2C standard but there it is. Seems to work well enough for now. Have updated dropbox too.

[Brian Riley]

Good, just delete that line in QS so it will at least compile the RTC words even if they don't report the time correctly. I will get to check it out soon though.
BTW, how come your console message is in lower case?

Dunno ...... it happened during copy/paste

I checked Spinnaret and WizNet schematics ... YES, same RTC chip for both Seiko S-35390a

[Peter Jakacki]

Yup!!!! All set ... Bring er on!

0040 
0041 
connect   socket #" --> .dt <-- not found

Good, just delete that line in QS so it will at least compile the RTC words even if they don't report the time correctly. I will get to check it out soon though.
BTW, how come your console message is in lower case?

[Brian Riley]

Yup!!!! All set ... Bring er on!

0040 
0041 
connect   socket #" --> .dt <-- not found

[Peter Jakacki]

THIS IS GETTING FRUSTRATING!!!!

I loaded the spin kernel, then typed "CREATE SMALL" . Then loaded in order, EXTEND, QS, SDCARD, MULTIFAT, typed "BACKUP REBOOT" ( 5597 bytes free). Then loaded NETWORK which choked at line 41 each time.

I found this puzzling since this choke point occurs several 100 lines before it choked when I wasn't doing "CREATE SMALL"

ok
REBOOT 

  Propeller .:.:--TACHYON--:.:. Forth V23140128.0000

NAMES:  $56A7...74DC for 7733 (1024 bytes added)
CODE:   $0000...40CA for 8853 (1641 bytes added)
CALLS:  0297 vectors free
RAM:    5597 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
3A61: W5200.fth           WIZNET W5200 driver 131211.1530 
3114: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
29C3: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 

----------------------------------------------------------------
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23140128.0000
 ok
[~ 
0000  Not found 
0001 
0002 WIZNET NETWORK SERVERS 140128.1730 "
<snip>
0040 
0041 
CONNECT   SOCKET #" .DT

Your modules look fine as they are very similar to mine.

MODULES LOADED: 
4182: NETWORK.fth         WIZNET NETWORK SERVERS 140128.1730 
3B19: W5200.fth           WIZNET W5200 driver 131211.1530 
31CC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
2A7C: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: CE1372.fth          CE1372 WIDGET HARDWARE DEFINITIONS 131109.2340 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 
-

So I decided to backtrack and load in QuickStart.fth since that was the only difference. It stopped at .DT
TACHYON
Propeller .:.:--TACHYON--:.:. Forth V23140128.0000
ok
CONNECT SOCKET #" .DTVERS 140128.1730 "

which is the word to print the date and time, so it seems QS needs to be patched with a dummy version or else the RTC section in that file needs to be enabled, the line:
{ -----RTC not tested yet !!!!!!!!

needs to be deleted and the RTC words tested. I think this is the same chip on the Spinneret in which case I can test it but in the meantime just insert a dummy stub in QS for .DT.
I think my next task might also to be to improve this error reporting as even I find it a little frustrating sometimes

EDIT: I've just patched EXTEND with a simple error handler which should make errors more visible.
EDIT: Unpatched EXTEND and made a change to the kernel so now that same error comes up like this:
CONNECT SOCKET #" --> .DT <-- NOT FOUND
@Brian: Just make sure it performs the same way on your system before we define .DT

[richaj45]

Yes, i know the book has error cause i used it to write TIL for a Z80 CP/M system.
I would get stuck and realize the book either left steps out or was wrong but the ideas were solid.
I did my assembly coding at lunch time at work since i did not have a CP/M system at home.

Took me over two months and i was so thrilled when it worked. It was like a discover something that no one had ever discovered before.

cheers,
rich

[OldFartRadioman]

@Loopy

Nice reference doc.
Have you read the book "Threaded Interpretive Languages" by Loeliger?

It is also a very good reference.



I am just trying to understand the inner workings of Tachyon. I am thinking it may be the best way to use the Prop.

Always trying to learn but not always succeeding.
rich

What a blast from the past. Back in the 80's implimented the TIL from this book on a SD Systems Z80 Starter Kit, with 8K of ram hand wire wrapped on a S100 expansion card, Hand assembled the code on a legal pad ( and yes back in the day I could do hex arithmatic in my head ) entered the hex code on a keypad until I boot strapped the monitor over to a TI 800 series printing terminal. Will never forget the feeling of seeing that first OK prompt, 2 in the morning and yelling so loud I woke my new bride up. BTW: the code in that book ( unless corrected in a later printing ) is full of errors.

[Brian Riley]

THIS IS GETTING FRUSTRATING!!!!

I loaded the spin kernel, then typed "CREATE SMALL" . Then loaded in order, EXTEND, QS, SDCARD, MULTIFAT, typed "BACKUP REBOOT" ( 5597 bytes free). Then loaded NETWORK which choked at line 41 each time.

I found this puzzling since this choke point occurs several 100 lines before it choked when I wasn't doing "CREATE SMALL"

ok
REBOOT 

  Propeller .:.:--TACHYON--:.:. Forth V23140128.0000

NAMES:  $56A7...74DC for 7733 (1024 bytes added)
CODE:   $0000...40CA for 8853 (1641 bytes added)
CALLS:  0297 vectors free
RAM:    5597 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
3A61: W5200.fth           WIZNET W5200 driver 131211.1530 
3114: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
29C3: SDCARD.fth          SD CARD Toolkit - 140121.2200 
2818: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
1801: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 

----------------------------------------------------------------
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23140128.0000
 ok
[~ 
0000  Not found 
0001 
0002 WIZNET NETWORK SERVERS 140128.1730 "
0003 
0004 
0005 
0006 
0007 
0008 
0009 
0010 
0011 
0012 
0013 
0014 
0015 
0016 




0017 
0018 
0019 
0020 
0021 
0022 
0023 
0024 
0025 
0026 
0027 

0028 
0029 
0030 

0031 
0032 
0033 
0034 
0035 
0036 
0037 
0038 
0039 


0040 
0041 
CONNECT   SOCKET #" .DT

[richaj45]

@Loopy

Nice reference doc.
Have you read the book "Threaded Interpretive Languages" by Loeliger?

It is also a very good reference.

I am just trying to understand the inner workings of Tachyon. I am thinking it may be the best way to use the Prop.

Always trying to learn but not always succeeding.
rich

[Loopy Byteloose]

@Peter

Is there a ways to list the dependances of a word.

That is, start with a word and list all the other words it calls down to the root of the word.

Thanks
rich

@Rich,
If you want to trace Forth lexicon back to the least number of primitives, eForth has done this already. I am sure it doesn't conform with any of the versions of Forth on the Propeller as each developer has selected to optimize the lower levels of lexicon in different ways. Everything runs faster in PASM, so creating a Forth with the least number of primitives is more of an academic exercise than a way to code a fast Forth interpreter.

Here is the document. It is a good read and has loads of interesting insights.

[Loopy Byteloose]

Yuck, Xmodem I hated although Zmodem was a lot better and Kermit I have tackled in the distant past. File transfers via the serial port normally mean that you have a file system on your Prop and if you have an FS then you normally have a memory card that can be removed etc. For remote access I favor FTP using the cheap W5200 chip. Notwithstanding, a simple Xmodem receive could even be built into the serial cog so that it automatically entered Xmodem on an SOH but would need to know beforehand where to put the file or else use the block 0 method to name it. How and on what are you thinking of using it?

I have run into a couple of Propeller users that are using HP calculators with RS232 serial interface and these support Xmodem and Kermit. It seems that Xmodem is easier to deploy, so I guess that would be enough if a rational need arises. For now I am not sure. The calculators also provide a generic RS232 mode.

[Peter Jakacki]

As with dating and courting so it is with hardware/software: "Date what you see, not the potential". I truly appreciate your focus and attention to detail regarding P1 and Tachyon Peter.

Thanks Dave, On the "other" forum I am amazed at all the energy and activity being put into a product that hasn't yet coalesced into something tangible. It's like a farmer spending all his time planning super silos for fields of wheat that the land hasn't even been bought for yet, and yet real farmers have real farms that need real work every day, otherwise no more super silos. There is an old saying "while the grass is growing the cow is starving". Yes, it will be good when it gets here but the reality is you also need something now otherwise there will be no cow.

[Peter Jakacki]

Just to add to your long list of todo items...
Is there any chance Tackyon might support serial file transfers via packets? Such as Xmodem or Kermit.

This might open up some interesting avenues for development.

Yuck, Xmodem I hated although Zmodem was a lot better and Kermit I have tackled in the distant past. File transfers via the serial port normally mean that you have a file system on your Prop and if you have an FS then you normally have a memory card that can be removed etc. For remote access I favor FTP using the cheap W5200 chip. Notwithstanding, a simple Xmodem receive could even be built into the serial cog so that it automatically entered Xmodem on an SOH but would need to know beforehand where to put the file or else use the block 0 method to name it. How and on what are you thinking of using it?

[Peter Jakacki]

@Peter

Is there a ways to list the dependances of a word.

That is, start with a word and list all the other words it calls down to the root of the word.

Thanks
rich

I started a long reply and then scrubbed it as I am a little confused as to what you are asking. A decompilation will list all the words it calls although source code is open and easily accessed for this purpose. I think where I am confused is when you talk about calling down to "the root" of a word which might mean iteratively decompiling perhaps? Do you have an example or maybe just understanding what it is you are trying to achieve would help.

[Loopy Byteloose]

Just to add to your long list of todo items...
Is there any chance Tackyon might support serial file transfers via packets? Such as Xmodem or Kermit.

This might open up some interesting avenues for development.

[D.P]

If I had spent all my time on P2 development then it would be very interesting academically but like all other P2 software it would be practically useless for now. With all fingers crossed we would hope for more than just a few sample chips when they become available if we are to deploy even a small quantity of preproduction units based on P2 out there. Certainly the Ethernet side of things will be much better still. If I can drag myself away from real and immediate use of P1 then I may start firing up my DE2 as I want to test out some of this Ethernet stuff. Since P1 has lots of uses as it is it just makes sense to keep developing TF for it and it may be at least a year assuming everything happens as we hope before P2 really starts to make it into commercial product anyway.

As with dating and courting so it is with hardware/software: "Date what you see, not the potential". I truly appreciate your focus and attention to detail regarding P1 and Tachyon Peter.

[richaj45]

@Peter

Is there a ways to list the dependances of a word.

That is, start with a word and list all the other words it calls down to the root of the word.

Thanks
rich

[Peter Jakacki]

Tackyon keeps getting more and more interesting. It is still my intention to jump over to Tachyon when the Propeller 2 arrives.

PropForth was just for getting started, Pfth has been very good to help me learn PASM by studying the eForth model of assembler Forth code and comparing it to what Pfth has done.

But I suspect that your deployment on the Propeller 2 will lead the way. I am looking forward to it.

If I had spent all my time on P2 development then it would be very interesting academically but like all other P2 software it would be practically useless for now. With all fingers crossed we would hope for more than just a few sample chips when they become available if we are to deploy even a small quantity of preproduction units based on P2 out there. Certainly the Ethernet side of things will be much better still. If I can drag myself away from real and immediate use of P1 then I may start firing up my DE2 as I want to test out some of this Ethernet stuff. Since P1 has lots of uses as it is it just makes sense to keep developing TF for it and it may be at least a year assuming everything happens as we hope before P2 really starts to make it into commercial product anyway.

[Loopy Byteloose]

Tackyon keeps getting more and more interesting. It is still my intention to jump over to Tachyon when the Propeller 2 arrives.

PropForth was just for getting started, Pfth has been very good to help me learn PASM by studying the eForth model of assembler Forth code and comparing it to what Pfth has done.

But I suspect that your deployment on the Propeller 2 will lead the way. I am looking forward to it.

[Peter Jakacki]

My bad again, I still had the slow debug versions of certain block words in NETWORK which I have just changed back to the faster version so FTP and HTTP block transfers should work a lot faster. Maybe I will look at doing a faster version still. The dropbox version has been updated.

[Peter Jakacki]

Peter:

 ok
DECIMAL  ok
200 5 / . 40 ok
-200 5 / . 858993419 ok
200 -5 / . 0 ok
-200 -5 / . 0 ok
  ok
-100 10 / . 429496719 ok
-200 10 / . 429496709 ok
  ok

There is a problem with dividing negative numbers in TACHYON???


NickL

The / is actually a U/ so I need to separate this into / and U/. I will patch the kernel now so that the / in the PASM kernel actually becomes U/ and / will be defined like this (for now):
: / OVER ABS OVER ABS U/ ROT 1 ROL ROT 1 ROL XOR 1 AND ?NEGATE ;

EDIT: the dropbox files have been updated

[nglordi]

Peter:

 ok
DECIMAL  ok
200 5 / . 40 ok
-200 5 / . 858993419 ok
200 -5 / . 0 ok
-200 -5 / . 0 ok
  ok
-100 10 / . 429496719 ok
-200 10 / . 429496709 ok
  ok

There is a problem with dividing negative numbers in TACHYON???


NickL

[Peter Jakacki]

I am still having trouble loading NETWORK.FTH. Load's clean as a whistle all the way through and including W5200.FTH then when I try to load NETWORK it hiccups at the same spot every time .

  Propeller .:.:--TACHYON--:.:. Forth V23140126.0000

NAMES:  $5349...74DB for 8594 (1037 bytes added)
CODE:   $0000...49BD for 10283 (1748 bytes added)
CALLS:  0198 vectors free
RAM:    2444 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
42E9: W5200.fth           WIZNET W5200 driver 131211.1530 
399C: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
324D: SDCARD.fth          SD CARD Toolkit - 140121.2200 
30A8: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 

----------------------------------------------------------------
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23140126.0000
 ok
[~ 
0000  Not found 
0001 
0002 WIZNET NETWORK SERVERS 140121.2000 "
0003 
0004 
0005 
0



{   200 OR SO LINES OF NETWORK.FTH LOAADNG DELETED    }



0253 
JPG"image/jpg"
ICO"PNG"
0254 
image/png"
HTM"text/html"

0255 

0256 
0257 
0258 
0259 

0260 
/:"

0261 


0262 

0263 
0264 
0265 
/"
HOME.HTM" GET$

There's a ton of fat in EXTEND and by the time you start loading all these modules in you are running out of memory so on a cold start before you have loaded in EXTEND just define a word called SMALL, I type CREATE SMALL then load in EXTEND, hardware headers, SD, FAT, W5200, NETWORK and end up with around 3K free which is plenty enough for the application itself.

[Brian Riley]

I am still having trouble loading NETWORK.FTH. Load's clean as a whistle all the way through and including W5200.FTH then when I try to load NETWORK it hiccups at the same spot every time .

  Propeller .:.:--TACHYON--:.:. Forth V23140126.0000

NAMES:  $5349...74DB for 8594 (1037 bytes added)
CODE:   $0000...49BD for 10283 (1748 bytes added)
CALLS:  0198 vectors free
RAM:    2444 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
42E9: W5200.fth           WIZNET W5200 driver 131211.1530 
399C: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 140123-0000 
324D: SDCARD.fth          SD CARD Toolkit - 140121.2200 
30A8: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 

----------------------------------------------------------------
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23140126.0000
 ok
[~ 
0000  Not found 
0001 
0002 WIZNET NETWORK SERVERS 140121.2000 "
0003 
0004 
0005 
0



{   200 OR SO LINES OF NETWORK.FTH LOAADNG DELETED    }



0253 
JPG"image/jpg"
ICO"PNG"
0254 
image/png"
HTM"text/html"

0255 

0256 
0257 
0258 
0259 

0260 
/:"

0261 


0262 

0263 
0264 
0265 
/"
HOME.HTM" GET$

[Peter Jakacki]

This has not fixed the reported bug listed in post 1092. After calling SPRS all other words are "broken" ??? CLS .MODULES APIN ....

This bug was caused by a reduction in the size of numpad down to 39 to allow other task variables (REG) to be long aligned. The long formatted binary number exceeded its buffer and zapped the write index for that buffer so the next character wrote elsewhere in memory!! I have now given that numpad 4 extra bytes which keeps the alignment and have removed allocation for defunct color and pixel pointers (from V1.0).

This bug never showed up as I haven't done an SPRS (now .SPRS) for quite some time. I am running some more tests but so far so good. So please note that many of the diagnostic words now begin with a dot.

.INFO 
  Propeller .:.:--TACHYON--:.:. Forth V23140122.0000

Clock frequency = 80,000,000
MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 

AUTORUN EXTEND.boot
Tasks 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       27A4 01 00 00 00 00 00 
Status 
NAMES:  $5EC1...74DB for 5658 (3159 bytes added)
CODE:   $0000...30A0 for 6790 (6304 bytes added)
CALLS:  0510 vectors free
RAM:    11809 bytes free

I2C BUS SCAN 
Fast Device at 0040  00 00 00 00 00 00 00 00 
Fast Device at 00A0  5E C9 5E 00 18 A0 30 A3 
Fast Device at 00AE  FF FF FF FF FF FF FF FF 
Fast Device at 00DE  04 89 71 1A F8 15 A9 40 

I/O Port states 
+----------u----------+
P00 <-- 1U    1 --> P31
P01 <-- *D    1 <-- P30
P02 <-- 1U   U1 --> P29
P03 <-- *D   X1 <-- P28
P04 <-- *X   X* --> P27
P05 <-- *X   U1 --> P26
P06 <-- *X   U1 --> P25
P07 <-- 1U   D* --> P24
P08 <-- 1U   X* --> P23
P09 <-- 1U   X* --> P22
P10 <-- 1U   X* --> P21
P11 <-- 1U   X* --> P20
P12 <-- *D   X* --> P19
P13 <-- 1U   X* --> P18
P14 <-- *X   X* --> P17
P15 <-- 1U   X* --> P16
+---------------------+
Special function registers 
01F0: PAR  = $0000_15D4   00_0000_0000_0000_0001_0101_1101_0100
01F1: CNT  = $AD58_07DE   10_1101_0101_1000_0000_0111_1101_1110
01F2: INA  = $F600_AF85   11_0110_0000_0000_1010_1111_1000_0101
01F3: INB  = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F4: OUTA = $5000_0000   01_0000_0000_0000_0000_0000_0000_0000
01F5: OUTB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F6: DIRA = $5000_0000   01_0000_0000_0000_0000_0000_0000_0000
01F7: DIRB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F8: CTRA = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F9: CTRB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FA: FRQA = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FB: FRQB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FC: PHSA = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FD: PHSB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FE: VCFG = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FF: VSCL = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000 ok

[Peter Jakacki]

Hello:

If i go to the Tachyon Dropbox what is the newest version. I have been taking
"Tachyon v2.3.spin" but i notice some number named files. Are they more recent?

Thanks much

rich

The plain V2.3 is always the most current with any numbered ones representing the backup files in YYMMDD format but they are all in their own folders so only the most current should be visible in the root Tachyon directory.

[richaj45]

Hello:

If i go to the Tachyon Dropbox what is the newest version. I have been taking
"Tachyon v2.3.spin" but i notice some number named files. Are they more recent?

Thanks much

rich

[Peter Jakacki]

This has not fixed the reported bug listed in post 1092. After calling SPRS all other words are "broken" ??? CLS .MODULES APIN ....

  Propeller .:.:--TACHYON--:.:. Forth V23140122.0000

MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 
 ok
0000 
t1F0: PAR  = $0000_15D4   %0
t1F1: CNT  = $3856_A188   %0
t1F2: INA  = $F270_007E   %1
t1F3: INB  = $0000_0000   %0
t1F4: OUTA = $4000_0000   %0
t1F5: OUTB = $0000_0000   %0
t1F6: DIRA = $4000_0000   %0
t1F7: DIRB = $0000_0000   %0
t1F8: CTRA = $0000_0000   %0
t1F9: CTRB = $0000_0000   %0
t1FA: FRQA = $0000_0000   %0
t1FB: FRQB = $0000_0000   %0
t1FC: PHSA = $0000_0000   %0
t1FD: PHSB = $0000_0000   %0
t1FE: VCFG = $0000_0000   %0
t ok: VSCL = $0000_0000   %0                            \ This line is suspect, time for me to look at the SPRS implementation
.MODULES ??? CLS ??? #15 APIN ???

Changing SPRS this way resolves the listed problem, seems the calls to .NUM is the issue, more digging to do

pub SPRS ( -- \ Dump the cog's SPRs with labels in both HEX and BINARY )

        #16 0 DO CR I $1F0 + .WORD ." : "

        I 2* 2* " PAR CNT INA INB OUTAOUTBDIRADIRBCTRACTRBFRQAFRQBPHSAPHSBVCFGVSCL" + 4 TYPE

        ."  = $" I SFR@ .
\ DUP $4810 .NUM ."    %" $6002 .NUM

        LOOP

        ;

I've checked this a bit further and while it appears to work first off it then starts playing up but comes good on a reset. I will back track to find out what happened.

[D.P]

The dropbox version is the same except for one error in that I2CBUS has been renamed .I2CBUS to conform to the diagnostic word naming. So I've fixed that and MODULES is of course now .MODULES.

00:00:00  End of source code, 1558 lines processed and 0000 errors found 
Load time = 30,174ms

NAMES:  $5ED6...74DB for 5637 (3138 bytes added)
CODE:   $0000...30A4 for 6815 (6308 bytes added)
CALLS:  0511 vectors free
RAM:    11826 bytes free
 ok
\ 
EEPROM ... 9600d SERBAUD  ok
runtime ~  ok
{  ok
  ok
  ok
?BACKUP  ok
  ok

This has not fixed the reported bug listed in post 1092. After calling SPRS all other words are "broken" ??? CLS .MODULES APIN ....

  Propeller .:.:--TACHYON--:.:. Forth V23140122.0000

MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 
 ok
0000 
t1F0: PAR  = $0000_15D4   %0
t1F1: CNT  = $3856_A188   %0
t1F2: INA  = $F270_007E   %1
t1F3: INB  = $0000_0000   %0
t1F4: OUTA = $4000_0000   %0
t1F5: OUTB = $0000_0000   %0
t1F6: DIRA = $4000_0000   %0
t1F7: DIRB = $0000_0000   %0
t1F8: CTRA = $0000_0000   %0
t1F9: CTRB = $0000_0000   %0
t1FA: FRQA = $0000_0000   %0
t1FB: FRQB = $0000_0000   %0
t1FC: PHSA = $0000_0000   %0
t1FD: PHSB = $0000_0000   %0
t1FE: VCFG = $0000_0000   %0
t ok: VSCL = $0000_0000   %0                            \ This line is suspect, time for me to look at the SPRS implementation
.MODULES ??? CLS ??? #15 APIN ???

Changing SPRS this way resolves the listed problem, seems the calls to .NUM is the issue, more digging to do

pub SPRS ( -- \ Dump the cog's SPRs with labels in both HEX and BINARY )

        #16 0 DO CR I $1F0 + .WORD ." : "

        I 2* 2* " PAR CNT INA INB OUTAOUTBDIRADIRBCTRACTRBFRQAFRQBPHSAPHSBVCFGVSCL" + 4 TYPE

        ."  = $" I SFR@ .
\ DUP $4810 .NUM ."    %" $6002 .NUM

        LOOP

        ;

[Peter Jakacki]

The dropbox version is the same except for one error in that I2CBUS has been renamed .I2CBUS to conform to the diagnostic word naming. So I've fixed that and MODULES is of course now .MODULES.

00:00:00  End of source code, 1558 lines processed and 0000 errors found 
Load time = 30,174ms

NAMES:  $5ED6...74DB for 5637 (3138 bytes added)
CODE:   $0000...30A4 for 6815 (6308 bytes added)
CALLS:  0511 vectors free
RAM:    11826 bytes free
 ok
\ 
EEPROM ... 9600d SERBAUD  ok
runtime ~  ok
{  ok
  ok
  ok
?BACKUP  ok
  ok

[Peter Jakacki]

I am afraid that I must add to the bad news .. The Dropbox code I took at 1500 EST today, Saturday ...

I built this far ... MOUNT works but notice the MODULES word fails even though the boot code got it to work.

* Propeller .:.:--TACHYON--:.:. Forth V23140122.0000

NAMES: *$5360...74DB for 8571 (1037 bytes added)
CODE: * $0000...49C1 for 10310 (1748 bytes added)
CALLS: *0199 vectors free
RAM: * *2463 bytes free

AUTORUN EXTEND.boot
MODULES LOADED:*
42ED: W5200.fth * * * * * WIZNET W5200 driver 131211.1530*
39A0: MULTIFILE.fth * * * FAT32/16 MultiFile Layer V1.1 140123-0000*
324F: SDCARD.fth * * * * *SD CARD Toolkit - 140121.2200*
30A4: QuickStart.fth * * *QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200*
1800: EXTEND.fth * * * * *Primary extensions to TACHYON kernel - 140121-2100*
--------------------------------------------------
  ok
MOUNT Mounted SD Card 
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888 ok
  ok
  ok
MODULES ???   ok
  ok

Then when I went to finish up ... when I loaded NETWORK.FTH it burped at the same place every time and I cannot figure what;s wrong

0256  ok
 
0257  ok
pub GETCMD 
0258 
    GET$ FORTH$ $! 
0259 
    FORTH$ 2 LEFT$ " /:" COMPARE$                            \ 
       IF 
0260 
       GET$ DUP LEN$ 2- RIGHT$ FORTH$ $!                        \ 
       THEN 
0261 
    ; 
0262  ok
 
0263  ok
pub GETPAGE 
0264 
    GET$ " /" COMPARE$                                \ 
       IF " HOME.HTM" DUP GET$  ???

Sorry guys, I'm a bit busy at the moment with social engagements and I thought I had updated the dropbox versions but the code does work from the latest Google docs. I will have a spare moment in another couple of hours and have a look then.

[Brian Riley]

I am afraid that I must add to the bad news .. The Dropbox code I took at 1500 EST today, Saturday ...

I built this far ... MOUNT works but notice the MODULES word fails even though the boot code got it to work.

* Propeller .:.:--TACHYON--:.:. Forth V23140122.0000

NAMES: *$5360...74DB for 8571 (1037 bytes added)
CODE: * $0000...49C1 for 10310 (1748 bytes added)
CALLS: *0199 vectors free
RAM: * *2463 bytes free

AUTORUN EXTEND.boot
MODULES LOADED:*
42ED: W5200.fth * * * * * WIZNET W5200 driver 131211.1530*
39A0: MULTIFILE.fth * * * FAT32/16 MultiFile Layer V1.1 140123-0000*
324F: SDCARD.fth * * * * *SD CARD Toolkit - 140121.2200*
30A4: QuickStart.fth * * *QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200*
1800: EXTEND.fth * * * * *Primary extensions to TACHYON kernel - 140121-2100*
--------------------------------------------------
  ok
MOUNT Mounted SD Card 
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888 ok
  ok
  ok
MODULES ???   ok
  ok

Then when I went to finish up ... when I loaded NETWORK.FTH it burped at the same place every time and I cannot figure what;s wrong

0256  ok
 
0257  ok
pub GETCMD 
0258 
    GET$ FORTH$ $! 
0259 
    FORTH$ 2 LEFT$ " /:" COMPARE$                            \ 
       IF 
0260 
       GET$ DUP LEN$ 2- RIGHT$ FORTH$ $!                        \ 
       THEN 
0261 
    ; 
0262  ok
 
0263  ok
pub GETPAGE 
0264 
    GET$ " /" COMPARE$                                \ 
       IF " HOME.HTM" DUP GET$  ???

[D.P]

Calling SPRS from the console renders the latest build "lost", cannot CLS or MODULES from console after, both words are ???

  Propeller .:.:--TACHYON--:.:. Forth V23140122.0000

NAMES:  $5ED6...74DB for 5637 (3138 bytes added)
CODE:   $0000...30A4 for 6815 (6308 bytes added)
CALLS:  0511 vectors free
RAM:    11826 bytes free

AUTORUN EXTEND.boot
MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 140121-2100 
----------------------------------------------------------------

 ok
SPRS 
t1F0: PAR  = $0000_15D4   %0
t1F1: CNT  = $B7D3_5196   %1
t1F2: INA  = $F270_007E   %1
t1F3: INB  = $0000_0000   %0
t1F4: OUTA = $4000_0000   %0
t1F5: OUTB = $0000_0000   %0
t1F6: DIRA = $4000_0000   %0
t1F7: DIRB = $0000_0000   %0
t1F8: CTRA = $0000_0000   %0
t1F9: CTRB = $0000_0000   %0
t1FA: FRQA = $0000_0000   %0
t1FB: FRQB = $0000_0000   %0
t1FC: PHSA = $0000_0000   %0
t1FD: PHSB = $0000_0000   %0
t1FE: VCFG = $0000_0000   %0
t ok: VSCL = $0000_0000   %0                  \ This line is suspect
MODULES ??? CLS ???

[Peter Jakacki]

First of all: Thank you for all the work! I've heard D.P fighting the Forth battle in the C world, and thought I'd give it a try.

I uploaded 140121-2100 last night and spotted a small missing update. Near the end, .INFO calls I2CBUS on line 7. Should be .I2CBUS

Thanks, I thought I checked it all but I think I was being distracted at the time and forgot. I wanted to standardize all the diagnostic words which print to the console so I decided to make them all dot type words and be done with it. I will check and update the files.

IMO I find it a big waste of time comparing languages as Forth is not just a language, it's the whole target O/S and development environment. Furthermore I can't help but compare effectiveness and efficiency of different ways of arriving at solutions. So I quietly chuckle to myself when I can see how simple a solution could be yet observe how people in general marvel at complexity.

[Chameleon]

First of all: Thank you for all the work! I've heard D.P fighting the Forth battle in the C world, and thought I'd give it a try.

I uploaded 140121-2100 last night and spotted a small missing update. Near the end, .INFO calls I2CBUS on line 7. Should be .I2CBUS

[Peter Jakacki]

Peter:

I am trying to figure out the v2.3 source code i fetched out of your drop box and i wonder about the PUB Start rountine.
That is:
<code>
repeat 6
cognew(@RESET, @IDLE)
</code>
Now as understand it RESET is the cog ID so why would want to repeat the same instruction six times with the same cog ID?

Please forgive the ignorance.
Regards,
rich

RESET is the address of the kernel cog image and IDLE is the parameter that's passed to it which then gets loaded into the Forth instruction Pointer "IP". COGNEW will do this six times so that 6 cogs will end up with the Forth kernel loaded but running an IDLE loop which waits for something to run. Finally the Spin cog that execute this gets replaced with a serial cog which then reuses the now "not needed" kernel cog image in HUB RAM as a receive buffer.

[richaj45]

Peter:

I am trying to figure out the v2.3 source code i fetched out of your drop box and i wonder about the PUB Start rountine.
That is:
<code>
repeat 6
cognew(@RESET, @IDLE)
</code>
Now as understand it RESET is the cog ID so why would want to repeat the same instruction six times with the same cog ID?

Please forgive the ignorance.
Regards,
rich

[Peter Jakacki]

That is very cool.

What does the # in front of the 32 do?

Is "\" the beginning of a line comment?

Thanks much
rich

A number preprocessor is built into Tachyon that does a quick check to see if it looks like a number and whether or not it has a suitable prefix or a suffix. Doing this first speeds up processing of numbers which would otherwise have do undergo a full dictionary search first. Besides the standard "d" and "h" suffix for decimal and hex notation TF also allows prefix notation such as $ and % for hex and binary but for decimal I chose to adopt the traditional # symbol that we use do denote a number (which is always decimal). So these prefix and suffix modes override whatever base Forth has been set to. For instance, if we have set Forth to HEX we do not need to figure out how to express decimal 5000 in hex nor do we have to use DECIMAL, instead we can just type #5000 or 5000d or even #5,000 as alphas and symbols are allowed to be embedded in numbers. This means we can express port pin 27 as #P27 if that helps us to recognize that as P27.

Using prefixed or suffixed numbers improves readability and also prevents errors if the base has been set to something different too.

\ is a comment to the end of the line (and not echoed). The two individual ticks together as used in Spin can also be used (not a single tick which is a reserved Forth word)
( is a comment to a matching )
{ is normally a multi-line comment (not echoed) to another matching } where nesting is counted.


EDIT: BTW, you can also enter ASCII and control characters using the prefix method. "?" will leave a $3F on the stack while a ^A will leave a 1 (control A).

[richaj45]

That is very cool.

What does the # in front of the 32 do?

Is "\" the beginning of a line comment?

Thanks much
rich

[Peter Jakacki]

So is there an 'array' data type or word?
An how would it be used?

Thanks for feedback.

rich

I assume you will be treating an area of memory as an array so you only need to supply the starting address. In typical Forth's you can always ALLOT extra bytes to any variable but if you use TABLE it will not allocate any storage so you just use that in conjunction with ALLOT like this:
TABLE freq_sweet_points #32 4 * ALLOT \ allocate a table/array of 32 longs

[richaj45]

So is there an 'array' data type or word?
An how would it be used?

Thanks for feedback.

rich

[Peter Jakacki]

Hello:

I want to have a Forth word that stores a set of data to an array that other words can then access.
For example something like this:

freq_sweet_points [ number number number number
number number ]

So that would be word "freq_sweep_points" would read input expecting a "[" to start the array data and followed by
a stream of number, which may cross new line-boundary and finally stop collecting number when "]" is read in.

How would that be done in Tachyon Forth?

Thanks
rich

I could give you a couple of pointers, first off to read in a number from the input stream you could just use:
GETWORD NUMBER
which will return with the number of digits and the value ( -- val digits )
Here's a live test implementation of the [ word:

: [  BEGIN GETWORD NUMBER 0= UNTIL ;  ok
IMMEDIATE  ok
  ok
[ 1234 5678 9000 ]  ok
.S 
STACK: FFFF.F9FF 0000.1234 0000.5678 0000.9000  ok

So your freq_sweet_points would really just leave an address of an array which [ can be modified to store the data in after which any non-number or ] can terminate it.
More correctly then the [ word will look like this (assuming it's a long array):

: [ ( arrary -- )
    BEGIN GETWORD NUMBER WHILE OVER ! 4 + REPEAT DROP
    ;
IMMEDIATE

[richaj45]

Hello:

I want to have a Forth word that stores a set of data to an array that other words can then access.
For example something like this:

freq_sweet_points [ number number number number
number number ]

So that would be word "freq_sweep_points" would read input expecting a "[" to start the array data and followed by
a stream of number, which may cross new line-boundary and finally stop collecting number when "]" is read in.

How would that be done in Tachyon Forth?

Thanks
rich

[nglordi]

I have posted a TACHYON based robot control language in the Robotics forum. I include the RCL Core here for comment.

pub  BOEPAB.fth   ." TACHYON Robot Control for BOE Platform & Prop Activity Board "   ;

{
 Motor drivers and utilities.
}

#P12 2 MASKS  ==  pwmpins

#1495 #80 * == ld0  \ sets zero position of left servo

#1504 #80 * == rd0  \ sets zero position of right servo

LONG lduty, rduty

pub .duty ( -- ) \ displays current right & left duties
    lduty @ . SPACE rduty @ . CR ;

pub M1 ( duty -- ) \ sets left servo duty: -1000 - 1000
  #10 * ld0 + lduty !  ;
	
pub M2 ( duty -- ) \ sets right servo duty: -1000 - 1000
  NEGATE #10 * rd0 + rduty !  ;

pub S ( -- ) \ abruptly stops bot motion 
    0 M1  0 M2  ;

pub D1 ( -- )  \ toggles left wheel direction
    lduty @ ld0 - NEGATE ld0 + lduty ! ;

pub D2 ( -- )  \ toggles right wheel direction
    rduty @ rd0 - NEGATE rd0 + rduty ! ;

pri rc_motors ( -- ) \ left and right servo pwm drivers
    pwmpins OUTCLR  S
    A NCO #P12 APIN  1 FRQ 0 PHSA COG!
    B NCO #P13 APIN  1 FRQ 0 PHSB COG!    
    BEGIN
      lduty @ NEGATE PHSA COG!
      rduty @ NEGATE PHSB COG!

      20 ms
    0 UNTIL  ;

pub MSTART  ( -- ) \ executes servo drivers in a cog
    ' rc_motors TASK? RUN  50 ms  ;

 
      
{
  Encoders record current total counts per wheel. 
}

#P14  2 MASKS  ==  encpins

LONG lenc, renc, xl, xr

pub .enc ( -- ) \ lists current  encoder counter values
    lenc @  . SPACE  renc @ . CR ;

pub zenc ( -- ) \ set left and right encoder counters to 0
    0 lenc !  0 renc !  ;

pri rc_enc ( -- ) \ simple encoder drivers based on basic stamp boebot program
    TRUE xl ! TRUE xr !  encpins INPUTS  zenc 
    BEGIN
      #P14 PIN@ DUP xl @ = IF DROP ELSE xl ! lenc ++  THEN
      #P15 PIN@ DUP xr @ = IF DROP ELSE xr ! renc ++  THEN
    0 UNTIL ; 
 
pub ESTART  ( -- ) \ executes encoder drivers in a cog
     ' rc_enc TASK? RUN 50 ms ; 

{
 Ping ultrasonic distance measurement (inches).
}

#1400 == p0   \ sets standard servo 0 position
#8 == dist?   \ sets ping stop condition in inches

LONG (dist), pos

pub !pos  ( angle -- ) \ where angle is -90 - 90 degrees (right to left)
   #10 * p0 + #80 * pos !  ;

pub dist ( -- value ) \ places current ping value (inches) on stack
    (dist) @ ;

pub .dist ( -- ) \ displaces current ping value (inches)
    dist . CR  ;

BYTE (stp)  \ stores stop flag

pub restp ( -- ) \ resets stop flag to TRUE
    TRUE (stp) C!  ;

pub stp ( -- flag ) \ places stop flag on stack
    (stp) C@  ;

pri rc_ping ( -- ) \ ping driver - automatic stop condition 
   #P17 PINCLR 0 !pos
   B #P17 APIN  NCO  1 FRQ
   A 1 FRQ
   BEGIN
     #P16 PINCLR
     A #P16 APIN NCO #400 NEGATE PHSA COG!
       #1000 CTRMODE 0 PHSA COG! #P16 PININP
     pos @ NEGATE PHSB COG!
     50 ms
     PHSA COG@ #11800 / DUP (dist) !
     dist? < stp  AND IF
        FALSE (stp) C! S THEN 
   0 UNTIL  ;
  

: PSTART  ( -- ) \ executes ping driver in a cog
   restp ' rc_ping TASK? RUN 50 ms ;

{
  User parameters.
}


\ user constants - 2.625 inch wheel diameter  4.312 inch between wheels

   #8   ==   wcirc   \ wheel circumference in inches
 
  #64   ==   counts  \ number of counts per wheel rotation

   #8   ==   ctin    \ counts per inch
 
 #136   ==   rcirc  \ rotation circumfirence in 0.1 inch units

 #271   ==   tcirc  \ turn circumfirence in 0.1 inches

pub R  ( -- )  \ hardware reset - execute START to continue
    #P9 PINCLR  ;

pub START
    MSTART  ESTART  PSTART  DECIMAL ;



{
********************************************************************************
This completes the RCL Core.    

Simple (indefinite) motion commands, which use indexed tables to select duties.
}

NickL

[Peter Jakacki]

Some of you may have been using the countdown timers that are built into EXTEND.fth that run in their own cog. Some changes have been made to improve integration with modules as previously a fixed table of 8 counters were assigned and a module would be assigned one or more manually. I then tried a dynamic assignment method a week ago but I wasn't all that happy with it so I have now scrapped the fixed table approach and introduced a linked timer method. Initially no timers are assigned but as soon as a "timer" address is passed to TIMEOUT then this is linked into the timer list and maintained accordingly. Normally these timers are simple countdown to zero and execute an ALARM condition if set or else do nothing style counters but they can now also be set to up-count as well.

As with before there are 8 bytes required for each timer and they are:
timer value (4)
alarm (2)
link (2)

DOUBLE timer1

To startup (and link) a timer it is the same as retriggering it:
#1000 timer1 TIMEOUT

So there is no need to specially link in the new timer as TIMEOUT will check this. You can use as many timers as would be practical.but now you specify the variable/address to use, that's it.
Here's a quick test of it in operation:

DOUBLE timer1  ok
DOUBLE timer2  ok
  ok
-1 timer1 TIMEOUT  ok
-1 2/ timer2 TIMEOUT  ok
TIMERS?  ticks = 1/1000
30B4: timer2              =7FFF.FFEC L30A8 
30A8: timer1              =FFFF.FFD0 L0001  ok
DOUBLE lockout      ok
#10,000 lockout TIMEOUT  ok
  ok
TIMERS?  ticks = 1/1000
30C0: lockout             =0000.02C0 L30B4 
30B4: timer2              =7FFF.DB66 L30A8 
30A8: timer1              =FFFF.DB49 L0001  ok

[Peter Jakacki]

Fast Pulse Generation in TACHYON FORTH

This code will produce two 1 us pulses, once every milisecond.

When I make just one pulse this way, it appears to be 1 us (or less) on the scope.

This code makes two pulses with a short delay between them. Together, they seem to fit within a 2 us division on the scope.

: FOUNTAIN 
 
$FFFF_FFFF $1F6 COG!   \ set pins as outputs

#80_000 DELTA   \ WAITCNT every 1 ms
 
BEGIN
   $0000_0000 $1F4
   $00FF_0000 $1F4
   COG! COG!
   
   $0000_0000 $1F4
   $00FF_0000 $1F4
   COG! COG!
   
   WAITCNT 
AGAIN 
;

If you want longer pulses, you can put some NOP's between the two COG!

If you want longer delay between the two pulses, put some NOP's after the first two COG!

I hope this is useful to someone (like me) who needs to do some precise timing

That code looks all wrong as you are setting ALL the port pins to outputs plus you don't have to explicitly set any pins as outputs as the OUTSET and OUTCLR instructions already take a mask for this purpose, set or clear those pins and make sure the pin is an output. Even so the timing is much longer than 2us as a literal pushed to the stack plus just one OUTxxx instruction can take from 2.4us (fast literal) to 4.8us (user constant).

Writing directly to the DIR and OUT registers using cog addresses is slow and inefficient and unnecessary. I will look at some code that will give you precise timing (measured) and let you know.

EDIT: Here's some tested code that produces 5us high then a 2.4us gap then 3us high at 1kHz

#P16 |< == P16
#P17 |< == P17
P16 P17 OR == P1617

: FOUNTAIN
   P1617 OUTCLR
   #80,000 DELTA
   P16 P17                                 \ setup port masks on stack for faster access
   BEGIN
     OVER OUTSET 8 DROP OVER OUTCLR        \ 5us hi
                                           \ 2.4us gap
     DUP OUTSET NOP ?DUP OUTCLR            \ 3us hi
     ESC? IF EXIT THEN                     \ allow an escape back to the console
     WAITCNT
   AGAIN
   ;

[Ivy Christiansaan]

Fast Pulse Generation in TACHYON FORTH

This code will produce two 1 us pulses, once every milisecond.

When I make just one pulse this way, it appears to be 1 us (or less) on the scope.

This code makes two pulses with a short delay between them. Together, they seem to fit within a 2 us division on the scope.

: FOUNTAIN 
 
$FFFF_FFFF $1F6 COG!   \ set pins as outputs

#80_000 DELTA   \ WAITCNT every 1 ms
 
BEGIN
   $0000_0000 $1F4
   $00FF_0000 $1F4
   COG! COG!
   
   $0000_0000 $1F4
   $00FF_0000 $1F4
   COG! COG!
   
   WAITCNT 
AGAIN 
;

If you want longer pulses, you can put some NOP's between the two COG!

If you want longer delay between the two pulses, put some NOP's after the first two COG!

I hope this is useful to someone (like me) who needs to do some precise timing

[Peter Jakacki]

Peter,

I understand the code you posted, but I could not get it to work correctly.

I believe that the "us" word messes up WAITCNT.

I was able to achieve what I wanted to do by using only WAITCNT several times.

Here is a simplified version of the code you posted:

  Propeller .:.:--TACHYON--:.:. Forth V23131230.0000                 
                                                                               
AUTORUN BOOT                                                                   
MODULES LOADED:                                                                
306B: sean4th.fth         Some FORTH for Sean 01/13/13                         
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200   
----------------------------------------------------------------       

: FT

   #16 PINCLR
   
   #80,000 DELTA

   BEGIN
      
      #16 PINSET
      #100 us
      #16 PINCLR
      
      WAITCNT
      
   AGAIN
;

' FT 3 RUN

When I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.

It appears that the "us" word is resetting the value of DELTA.

If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.


The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:

: FT

   #16 PINCLR
   
   #20,000 DELTA

   BEGIN
      
      #16 PINSET
      WAITCNT
      #16 PINCLR
      WAITCNT
      WAITCNT
      WAITCNT
      
   AGAIN
;

Also COGSTOP does not seem to work.

  ok
' FT 3 RUN  ok
TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: FT                              30E2 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       2738 01 00 00 00 00 00  ok

3 COGSTOP  ok

TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: FT                              30E2 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       2738 01 00 00 00 00 00  ok

My bad, I did this away from my system so I just did a quick code of it but yes, the us and ms both use DELTA so that won't work just like that. Sometimes for small delays it's better just to use some dummy instructions instead of the small delays and then just use WAITCNT for the 1kHz timing.

COGSTOP only stops the cog itself and effectively freezes the process so this can still show up in the task list. Normally once a task is started it is left to run unless it exits back to the IDLE loop.I may do some more work on this at least to make the TASK list reflect what's going on a bit better, it's just a simple listing really.

[Ivy Christiansaan]

Peter,

I understand the code you posted, but I could not get it to work correctly.

I believe that the "us" word messes up WAITCNT.

I was able to achieve what I wanted to do by using only WAITCNT several times.

Here is a simplified version of the code you posted:

  Propeller .:.:--TACHYON--:.:. Forth V23131230.0000                 
                                                                               
AUTORUN BOOT                                                                   
MODULES LOADED:                                                                
306B: sean4th.fth         Some FORTH for Sean 01/13/13                         
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200   
----------------------------------------------------------------       

: FT

   #16 PINCLR
   
   #80,000 DELTA

   BEGIN
      
      #16 PINSET
      #100 us
      #16 PINCLR
      
      WAITCNT
      
   AGAIN
;

' FT 3 RUN

When I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.

It appears that the "us" word is resetting the value of DELTA.

If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.


The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:

: FT

   #16 PINCLR
   
   #20,000 DELTA

   BEGIN
      
      #16 PINSET
      WAITCNT
      #16 PINCLR
      WAITCNT
      WAITCNT
      WAITCNT
      
   AGAIN
;

Also COGSTOP does not seem to work.

  ok
' FT 3 RUN  ok
TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: FT                              30E2 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       2738 01 00 00 00 00 00  ok

3 COGSTOP  ok

TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: FT                              30E2 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       2738 01 00 00 00 00 00  ok

[Peter Jakacki]

Hello,

I am using a Parallax Propeller Quick Start running TACHYON FORTH.

I would like to do this:


1. Pin 16 and Pin 17 are both LOW
2. At time t=0, pin 16 goes HIGH
3. 5 u-sec elapse
4. Pin 16 goes LOW
5. 2 u-sec elapse
6. Pin 17 goes HIGH
7. 3 u-sec elapse
8. Pin 17 goes LOW
9. At this point, a total of 10 u-sec have elapsed
10. Now 990 u-sec elapse, and the process repeats

Thus the two pulses are given 1000 times each second.


I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.


Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?


I like FORTH very much Thank you Peter!

I wouldn't say that this is the best way to do it but I couldn't resist just converting your steps into Forth code. Obviously you have some small delays of a few microseconds and these would need to be trimmed to account for the instruction timing etc but it gives you an idea. What I would probably be more inclined to do is to have a small PASM module that gets LOADMOD'd just for the fast pulse sequences and then use the WAITCNT loop but try replacing some of the delays with NOPs instead to get your timing. I don't know how critical the timing should be but if it is very critical then a PASM module might be the way to go. When I get to sit down in front of a board I might try some other methods including counter methods.

( 1. Pin 16 and Pin 17 are both LOW )
    #P16 PINCLR #P17 PINCLR
     #80,000 DELTA        \ 1 ms WAITCNT @80MHz
( 2. At time t=0, pin 16 goes HIGH )
    BEGIN
       #P16 PINSET
( 3. 5 u-sec elapse )
       5 us
( 4. Pin 16 goes LOW )
       #P16 PINCLR
( 5. 2 u-sec elapse )
       2 us
( 6. Pin 17 goes HIGH )
       #P17 PINSET
( 7. 3 u-sec elapse )
      3 us
( 8. Pin 17 goes LOW )
       #P17 PINCLR
( 9. At this point, a total of 10 u-sec have elapsed )
      WAITCNT        \ synchronized to 1ms interval for precise 1kHz operation
10. Now 990 u-sec elapse, and the process repeats
     AGAIN

[Ivy Christiansaan]

Hello,

I am using a Parallax Propeller Quick Start running TACHYON FORTH.

I would like to do this:


1. Pin 16 and Pin 17 are both LOW
2. At time t=0, pin 16 goes HIGH
3. 5 u-sec elapse
4. Pin 16 goes LOW
5. 2 u-sec elapse
6. Pin 17 goes HIGH
7. 3 u-sec elapse
8. Pin 17 goes LOW
9. At this point, a total of 10 u-sec have elapsed
10. Now 990 u-sec elapse, and the process repeats

Thus the two pulses are given 1000 times each second.


I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.


Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?


I like FORTH very much Thank you Peter!

[D.P]

Remember that if you test this out in the console cog first that it will set the pins to outputs for that cog so you either have to avoid doing this or reset the pins back to inputs with #15 PININP etc. Also each cog only has a 4 level stack now which might need to be expanded with an external stack, just as the console cog does at startup. This is certainly the case here as there are some calculations made to setup these modes and it looks like the internal stack is overflowing and returning the wrong result.

To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.

I was in the code digesting your message and now I find out you have already changed it!

Tested, working. Moving right along. BTW very nice modules, your puppy's have bones it seems. Thanks for sharing.

[Peter Jakacki]

Running this code in a separate COG does not "blink the lights" at 3 Hz but at ~164KHz?
Do I have a COGREGS issue?

  Propeller .:.:--TACHYON--:.:. Forth V23131230.0000

MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200
 
: TOG  A  #15 APIN #14 BPIN 3 Hz 5 CTRMODE  #10000 ms MUTE ;    
TOG      / RUNS AT 3 HZ  and quits after 10 seconds
' TOG 4 RUN    / RUNS AT ~164 KHz  and quits after 10 secs

Remember that if you test this out in the console cog first that it will set the pins to outputs for that cog so you either have to avoid doing this or reset the pins back to inputs with #15 PININP etc. Also each cog only has a 4 level stack now which might need to be expanded with an external stack, just as the console cog does at startup. This is certainly the case here as there are some calculations made to setup these modes and it looks like the internal stack is overflowing and returning the wrong result.

To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.

[D.P]

Running this code in a separate COG does not "blink the lights" at 3 Hz but at ~164KHz?
Do I have a COGREGS issue?

  Propeller .:.:--TACHYON--:.:. Forth V23131230.0000

MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200
 
: TOG  A  #15 APIN #14 BPIN 3 Hz 5 CTRMODE  #10000 ms MUTE ;    
TOG      / RUNS AT 3 HZ  and quits after 10 seconds
' TOG 4 RUN    / RUNS AT ~164 KHz  and quits after 10 secs

[max72]

Sorry Peter, I wasn't clear.
My approach is to program the propeller using the "traditional", tethered way, and then remotely connect.
Your modules are very cool!
Thanks for sharing.
Massimo

[max72]

With some boards the reset happens when you have a serial stream to the ftdi chip, and the usb cable is not connected.
If you send tachyon console message to other pins you avoid the issue.
a cheap option is to get the bluetooth modules, attach one to a couple of spare pins, reload tachyon after changing the console pins (not 30 and 31 but your wireless module pins) and wirelessly connect using your pc's bluetooth or your android tablet. Not ipad/iphone. With ipad there are the wifly serial to wifi modules. More expensive and a little bit more complex to use.
Anyway with a little expense you have the possibility to remotely connect to the tachyon console and avoid the reset issue.
Check the forum for threads about the cheap bluetooth modules, or propforth wiki. They are sold also by obc on propellerpowered.
Peter discussed about them too.
connecting to a remote console, even if 5 cm away, is truly a great experience offered by forth on the propeller.

[Peter Jakacki]

As an alternative to FTDI modding consider a BT of wifly module. It costs 2 pins, but worth the experience!
In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
OT: If you program with spin there is a pst dummy object to simplify debugging
Massimo

Most of my boards don't have USB embedded in them as I simply have a 4x2 PropPlug compatible header instead. The second set of 4 pins include +5V and I2C signals so it is possible to power any adaptor that is plugged in such as my own Bluetooth modules or in the case of USB allowing it to power the board. The I2C lines are handy too as I can directly access the EEPROM and this allows for field programming where I have a little module that plugs in, blinks, and reprograms boards. The I2C can also be used as an expansion header to a peripheral board.

These modules can be plugged in as required or left in permanently.



@Max: A Bluetooth module does not allow for normal program download via the Spin tool so there is no need for it to reset the Prop anyway although my Bluetooth module does include remote programming support.

[base2design]

Max, can you expand a bit on this?

[max72]

As an alternative to FTDI modding consider a BT of wifly module. It costs 2 pins, but worth the experience!
In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
OT: If you program with spin there is a pst dummy object to simplify debugging
Massimo

[D.P]

I just tie VBUS to VCC as I normally run it off USB power or external power but then again, I haven't had any problems with it that way either. The bonus is that when you are developing you don't need any external supply.

Well it cost me a quickstart board because I made a pinout mistake. But your solution works on the BOE and the PPDB and I'm sure the quickstart as soon as I purchase another (if I do) thanks for all the patience Peter. This whole experience has not won any good feelings from me toward Parallax. Hey David Carrier: don't use the FT232 design that is broken on the quickstart board, the PPDB and the BOE board on your new Spinnerette design okay. No one in the field it seems has implemented the FT232 the way parallax has on these boards.

Now back to Tachyon and my project since this accidental complexity is gone, thanks again Peter.

dp

[Peter Jakacki]

Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?

I've got sharp things and feeling like cutting something right now.

I just tie VBUS to VCC as I normally run it off USB power or external power but then again, I haven't had any problems with it that way either. The bonus is that when you are developing you don't need any external supply.

[D.P]

Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.

Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?

I've got sharp things and feeling like cutting something right now.

[Peter Jakacki]

Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.

The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.

Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.

See any stray "Puppys" looking for a good home?

Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.

[D.P]

Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.

Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.

There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.

Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.

The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.

Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.

See any stray "Puppys" looking for a good home?

[Peter Jakacki]

One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.

Here is/are the only word/s I have added:

: BLINKY BEGIN #P17 PINSET 100d ms #P17 PINCLR 100d ms KEY? AND UNTIL ;
AUTORUN BLINKY
\ then executed a backup

Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.

When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.

Let's see if we can figure out this very simple example of my "failure to understand".

Thanks

Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.

Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.

There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.

[D.P]

One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.

Here is/are the only word/s I have added:

: BLINKY BEGIN #P17 PINSET 100d ms #P17 PINCLR 100d ms KEY? AND UNTIL ;
AUTORUN BLINKY
\ then executed a backup

Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.

When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.

Let's see if we can figure out this very simple example of my "failure to understand".

Thanks

[Brian Riley]

Could it be the FTDI resetting? There are many discussion about that, and the symptoms are the same.

Massimo

Excuse me for arriving late to this thread ... this BOE Tetherless Startup is old news ... as Massimo has stated it has already generated reams of discussion elsewhere in the Prop Forums and I don't know if any solution was ever reached ... perhaps @PhiPi knows ...

[D.P]

Dang dude... do you ever sleep? I didn't mean for you to write the "whole dang thing" for me but I'll have loads of fun playing with it. I take it from the process you've indicated here that PASM parts of OBEX items will work unchanged with Tachyon but Spin parts have to be re-written. That's fair... I'm an old-time forth fan anyway so I'm up for a change of perspective. I won't be in front of a Propeller until tonight but will certainly fire up Tachyon tonight and get my bearings so I can start testing/contributing.

Thanks again!

Uh oh, you will not believe the treat you are in for. You may not be sleeping much yourself! While some of the syntax has very slightly changed in the Introduction to Tachyon webpage it is still a great way to get started and understand the layout. Look forward to your contributions.

[base2design]

Dang dude... do you ever sleep? I didn't mean for you to write the "whole dang thing" for me but I'll have loads of fun playing with it. I take it from the process you've indicated here that PASM parts of OBEX items will work unchanged with Tachyon but Spin parts have to be re-written. That's fair... I'm an old-time forth fan anyway so I'm up for a change of perspective. I won't be in front of a Propeller until tonight but will certainly fire up Tachyon tonight and get my bearings so I can start testing/contributing.

Thanks again!

[Peter Jakacki]

I have used the VGA bitmap object directly but since that is just PASM that runs in it's own cog there wasn't anything much to change whereas most of the objects available have Spin wrappers which can't be used. In many instances I find that much of this Spin code is redundant anyway. I will take a look at SIDcog though to see if there is a possibility or using it.

I have started to write the SIDcog interface for this and it looks fairly complete, now I only have to graft in the the PASM binary and the waveform table to start testing, but I probably won't have time to do anymore on this for at least a day or two. I have simplified the functions so that they can be combined easily and interactively from the serial terminal so it's very easy to experiment with SIDcog. It "sounds" like it will be a lot of fun once I can get back to finishing it.

Example of interacting with SIDcog (in one line)
0 CHAN 8 3 4 2 ADSR ON HP ON BP OFF LP ON SAWTOOTH #1000 NOTE

What that was about:
0 CHAN \ select channel 0
8 3 4 2 ADSR \ Set attack, decay, sustain, release (ADSR(
OFF HP \ Turn off highPass filter
ON BP \ Turn on bandpass filter
OFF LP \ Turn off lowpass filter
ON SAWTOOTH \ Select SAWTOOTH waveform
#1000 NOTE \ Play a note

Of course if that was a sound effect (no idea what it sounds like yet) you could just then define it as a new word.

Here's the link to the Tachyon Google webpage document for the SIDcog module.

[max72]

Could it be the FTDI resetting? There are many discussion about that, and the symptoms are the same.

Massimo

[D.P]

I've always had to have my tachyon boards tethered, POE, PPDB, Quickstart. There must be something fundamentally I'm missing here. But here are the modules loaded.

MODULES LOADED: 
46F9: RELAY8.fth          ETHRLY8 Board (WIZNET W5200) driver 140105.1630 
401A: W5200.fth           WIZNET W5200 driver 131211.1530 
3756: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
2FD7: SDCARD.fth          SD CARD Toolkit - 131114.0000 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000

And I just sent you Relay8.fth by PM

[Peter Jakacki]

Well I put

0 STOP

Into my AUTORUN "word" and it still doesn't boot without the USB cable and as a bonus ^A doesn't abort the AUTORUN either so know I need to rebuild the world to get back in.

I've had this issue with everyboard I use, I could really use a simple example of a booting tachyon system that does not rely on a USB connection.

I'm doing something wrong obviously.

I have an old Parallax demo board I could try it on, if you send me your code and I will see what is happening.

[D.P]

Well I put

0 STOP

Into my AUTORUN "word" and it still doesn't boot without the USB cable and as a bonus ^A doesn't abort the AUTORUN either so know I need to rebuild the world to get back in.

I've had this issue with everyboard I use, I could really use a simple example of a booting tachyon system that does not rely on a USB connection.

I'm doing something wrong obviously.

[Peter Jakacki]

Does Tachyon support using libraries from OBEX? I'm a little lost looking at the dropbox repository but would love to tinker around with Forth and SIDcog.

I have used the VGA bitmap object directly but since that is just PASM that runs in it's own cog there wasn't anything much to change whereas most of the objects available have Spin wrappers which can't be used. In many instances I find that much of this Spin code is redundant anyway. I will take a look at SIDcog though to see if there is a possibility or using it.


EDIT: Looks easy enough to convert the few Spin methods and load the binary straight into a cog. Here's a conversion of a Spin function:

pub setADSR ( attack, decay, sustain, release channel -- ) 
{
Sets the envelope values of a SID channel            
- channel - The SID channel to use. (0 - 2)                    
- attack - The attack value. (0 - 15)                          
- decay - The decay value. (0 - 15)                            
- sustain - The sustain value. (0 - 15)                             
- release - The release value. (0 - 15)                        
}

    3 SHL >L                             \ offs := channel<<3 (IX (top of loop stack) is the channel offset)
                                         \ STACK = ( attack decay sustain release ) 
    $0F AND SWAP $0F AND 4 SHL OR        \ (release&$F) | ((sustain&$F)<<4)
    ch1_sustainRelease IX + C!           \ byte[@ch1_sustainRelease + offs] := 
                                         \ STACK = ( attack decay )
    $0F AND SWAP $0F AND 4 SHL OR        \ (decay&$F) | ((attack&$F)<<4)
    ch1_attackDecay IX + C!              \ byte[@ch1_attackDecay + offs] := 
    L> DROP                              \ discard offset
    ;

Of course this will look even simpler once I factor out code:

pub setADSR ( attack, decay, sustain, release channel -- ) 
{
Sets the envelope values of a SID channel            
- channel - The SID channel to use. (0 - 2)                    
- attack - The attack value. (0 - 15)                          
- decay - The decay value. (0 - 15)                            
- sustain - The sustain value. (0 - 15)                             
- release - The release value. (0 - 15)                        
}

    3 SHL >L                             \ offs := channel<<3 (IX (top of loop stack) is the channel offset)
    NIB>BYTE ch1_sustainRelease IX + C!  \ byte[@ch1_sustainRelease + offs] := 
    NIB>BYTE ch1_attackDecay IX + C!     \ byte[@ch1_attackDecay + offs] := 
    L> DROP                              \ discard offset
    ;

[Peter Jakacki]

I've got the client sockets working correctly now. I need to run some untethered tests i.e. don't have a USB cable attached to the BOE.

Everything "AUTORUN"s fine as long as the USB is plugged into the computer but the BOE doesn't "BOOT" elsewise?

What am I missing?

Tachyon does serial break detection to allow for remote resetting so depending upon your hookup then this may be the case. A check is made in case the receive line is simply floating which does not result in a reset, so it has to be a valid break.Easiest way to check is to disable the receive cog in your startup with "0 STOP". You can always get back into it to reenable by holding down the ^A key during reset which will abort an autorun.

Thanks

[base2design]

Does Tachyon support using libraries from OBEX? I'm a little lost looking at the dropbox repository but would love to tinker around with Forth and SIDcog.

[D.P]

I've got the client sockets working correctly now. I need to run some untethered tests i.e. don't have a USB cable attached to the BOE.

Everything "AUTORUN"s fine as long as the USB is plugged into the computer but the BOE doesn't "BOOT" elsewise?

What am I missing?

Thanks

[MJB]

I know, it shouldn't be much effort, but if anybody has done it already - and is willing to share -, then I'll do s.th. else ...

[max72]

I agree.
at every version it looks like Peter is stripping down the kernel to a very tight and basic tool.
Everything else is loaded afterward, so I guess the latest is the best starting point.
On the tachyon pages there still is a link to version 1, by the way..
Massimo

[D.P]

Hello:

What would be the version of Tachyon that would be complete but not embellished as newer version are?
My purpose is to study and learn from the code and maybe extend it in a different direction as a new application.

cheers,
rich

I would think you would start with lastest Tachyon Kernel. You can stripe out anything you don't need once you understand the structure. It's up to you to load the rest of the goodies via extend.fth.... which could be stripped down an well. The Kernel doesn't contain all the servers etc just core words and the Tachyon VM. I have been able to load everything and the sink and still have a bunch of room for a large embedded application. Get your "project" running then optimize/refactor. Peter took a timer task example I wrote and paired it down by 75%, ouch but I did learn a bunch. Recently I've been working with different chips, SPI and I2C and poking and peeking values to them has never been easier, if I2C and SPI was ever suppose to be easy in the first place.

Peter will have the last word here, this is my basic experience so far. Good luck.

[richaj45]

Hello:

What would be the version of Tachyon that would be complete but not embellished as newer version are?
My purpose is to study and learn from the code and maybe extend it in a different direction as a new application.

cheers,
rich

[max72]

I used the proptool recently, so I guess the extra bst requirement has been relaxed.
Massimo

[richaj45]

Hello:

Does SimpleIDE compile Tachyon Forth correctly?

As i remember reading Tachyon takes advantage of some BST features so may it will not compile correctly in SimpleDE.

Has anyone tried yet since, obviously i have not?

cheers,
rich

[D.P]

I've only used this in server mode so far but I will have a look at client mode. The WIZnet chips are nice except they have lots of little idiosyncrasies such as not being able to write certain registers when you want to, only when the chip feels it's okay! Watch that IP notation as you are specifying it in hex so that it will end up as $10101210 rather than &10.10.1.210

If you create a register defintion such as sDPORT you might consider having it also perform the write to register operation. This looks cleaner IMO and you don't have to remember what width it is either.

Delving throught the WizNet C, C++ files to find how to set these registers is such a PITA. What a mess that driver is, files everywhere with overloaded functions that only a Mother could love. Now that I see how elegant FORTH is for driver work I know why my mentor would only write drivers in FORTH, even if he had to build his own FORTH first which he did many times I guess. This was before my time with him and any experience with FORTH.

Still hunting for this elusive function definition in the source: writeSnDIPR() to unlock the writing of the magic registers, gads!

Update: Jewel from WizNet Forun: "You should be write socket register value before status register is init."
Well okay I'll just try that then!

Update: No joy writing these registers after a PWR cycle, RST cycle, socket stat = 0, socket stat = init or any other combination I tried, obviously not the right combo yet. WizNet says to check the reference code, gads x 2. Better go look at the pasm driver for a while.

************** HOT TIP ******************
Before attempting to write to the following destination registers: ip, port and mac do this why the socket status is not INIT.

: setwint ( intval -- ) sINTS LC! ;
$FF setwint

you will only be able to read the registers after sOPEN, sCONNECT so it seems

Hat tip to the W5200 spin and pasm driver writers! Moving on...

[David Betz]

I know that there is this tendency in the programming language world to make the language case insensitive but that seems like a waste to me and plus I like to know a bit about the word when I read code without having to resort to really_long_names_to_describe_it. If a word is in all capitals then it's normally an action word that does something. Mostly the constants and variables are in lower case as they simple leave something on the stack. This is my basic although not strict Forth "philosophy" if you like. I bend and break my own guidelines frequently but I do try to work with some guidelines anyway.

Thanks for the explanation. I understand your philosophy since it matches the C philosophy at least with regards to case sensitivity. :-)

[Peter Jakacki]

As is obvious, I'm not a Forth expert but I think that having different behavior when using Forth interactively from what happens when you load a file is likely to be confusing. I'll just try to remember to typing DUP in uppercase. At first I thought I had installed Tachyon wrong since I got a series of question marks every time I entered "dup ". At least now I know that it was my typing error not a problem with my installation.

Thanks,
David

I know that there is this tendency in the programming language world to make the language case insensitive but that seems like a waste to me and plus I like to know a bit about the word when I read code without having to resort to really_long_names_to_describe_it. If a word is in all capitals then it's normally an action word that does something. Mostly the constants and variables are in lower case as they simple leave something on the stack. This is my basic although not strict Forth "philosophy" if you like. I bend and break my own guidelines frequently but I do try to work with some guidelines anyway.

[David Betz]

What I could do to improve interactive typing is to implement an autocase feature. If a word was not found in the dictionary and it wasn't a number then either a conversion is performed to uppercase and the dictionary is searched again or else a non case-sensitive search is performed. Since this would really only be during console interaction rather than loading source code modules it shouldn't matter that the search is a bit slower.

As is obvious, I'm not a Forth expert but I think that having different behavior when using Forth interactively from what happens when you load a file is likely to be confusing. I'll just try to remember to typing DUP in uppercase. At first I thought I had installed Tachyon wrong since I got a series of question marks every time I entered "dup ". At least now I know that it was my typing error not a problem with my installation.

Thanks,
David

[Peter Jakacki]

Using this build

GO
NAMES:  $54C1...74CB for 8202 (0532 bytes added)
CODE:   $0000...524F for 12869 (2470 bytes added)
CALLS:  0161 vectors free
RAM:    0626 bytes free

AUTORUN BOOT
MODULES LOADED:
48A9: NETWORK.fth         WIZNET NETWORK SERVERS 131211.1530
41ED: W5200.fth           WIZNET W5200 driver 131211.1530
38E0: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000
31A5: SDCARD.fth          SD CARD Toolkit - 131114.0000
3003: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200

*** Tachyon Forth Network and File Server ***

Mounted SD Card
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888

Running this build, w/o AUTORUN, I get File-Zilla to connect, and it sends a list. Then I try to transfer ROM0.BIN to my iMac and the 5200 refuses the connection.. .WHY? See FileZilla screenshot below

That passive port is all wrong, it should be a random port within a confined range. The directory listing requires the data port so the connection is refused because the port is way out of rnage. I will check my system and get back to you. Have updated the files in the meantime.

EDIT: Just checked mine and it worked fine although the port reported in decimal is incorrect although the port parameter is fine.

Command:    PASV
Response:    227 Entering Passive Mode with port 2857207046(192,168,16,150,170,77)
Command:    LIST
Response:    150 Here comes the directory listing
Response:    226 Directory send OK
Status:    Directory listing successful

EDIT: The port it tried to use in your case was port 49599 but your firewall or router may be blocking that.
Either configure the firewall/router or adjust the range:

#40,000     == #ftpmin

#50,000     == #ftpmax

The reason the decimal version was wrong is because of a a simple @ vs W@

pub PASV
     ON LANLED
    GETPAS                                        \ pick a random port in the specified range
    ." 227 Entering Passive Mode with port " dataport W@ .DEC        \ Response with msg and port
    ." (" @srcip E@ .IPD COMMA dataport 1+ C@ .BYTEDEC COMMA dataport C@ .BYTEDEC ." )" CR     
    FTPDAT SOCKET sCLOSE                                 \ Prep the data port socket
     TCP dataport W@ PORT! sOPEN sLISTEN .CONNECTED                \ Set the port and open listen for connection
    FTP SOCKET LAN                                    \ switch back to FTP socket (precaution)
    ;
IMMEDIATE

[Peter Jakacki]

I just installed Tachyon on one of my QuickStart boards and it seems to work fine! I'm wondering though if there is a way to remove the case sensitivity. It's kind of a pain to have to type "DUP" instead of "dup". Would that be contrary to the Forth philosophy?

What I could do to improve interactive typing is to implement an autocase feature. If a word was not found in the dictionary and it wasn't a number then either a conversion is performed to uppercase and the dictionary is searched again or else a non case-sensitive search is performed. Since this would really only be during console interaction rather than loading source code modules it shouldn't matter that the search is a bit slower.

[KC_Rob]

I just installed Tachyon on one of my QuickStart boards and it seems to work fine! I'm wondering though if there is a way to remove the case sensitivity. It's kind of a pain to have to type "DUP" instead of "dup". Would that be contrary to the Forth philosophy?

I don't think it's against Forth "philosophy," and I do know that many (perhaps even most) Forths are not case sensitive. (I think the ANS Forth standard says something about systems having to support core words entered in upper-case, but that's about as far as it goes.)

"And so Forth..." says that Forth is usually not case-sensitive.

Keep in mind, though -- I'm only a Forth neophyte.

[David Betz]

I just installed Tachyon on one of my QuickStart boards and it seems to work fine! I'm wondering though if there is a way to remove the case sensitivity. It's kind of a pain to have to type "DUP" instead of "dup". Would that be contrary to the Forth philosophy?

[Brian Riley]

Using this build

GO
NAMES:  $54C1...74CB for 8202 (0532 bytes added)
CODE:   $0000...524F for 12869 (2470 bytes added)
CALLS:  0161 vectors free
RAM:    0626 bytes free

AUTORUN BOOT
MODULES LOADED:
48A9: NETWORK.fth         WIZNET NETWORK SERVERS 131211.1530
41ED: W5200.fth           WIZNET W5200 driver 131211.1530
38E0: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000
31A5: SDCARD.fth          SD CARD Toolkit - 131114.0000
3003: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200

*** Tachyon Forth Network and File Server ***

Mounted SD Card
Media mounted as 3C18.8F1F          NO NAME     FAT32    Cluster size = 32,768   Sectors = 15,269,888

Running this build, w/o AUTORUN, I get File-Zilla to connect, and it sends a list. Then I try to transfer ROM0.BIN to my iMac and the 5200 refuses the connection.. .WHY? See FileZilla screenshot below

[Brian Riley]

I just checked that document and I did have a little bug in there with the "cntr" variable but the Dropbox version has also been updated I was in the middle of shuffling some of the "REG" task variables so that a task need only allocate the first 32 bytes if it needed it's own emit and key vectors etc. BTW, I'm using BST 0.19.4-pre12

I just checked the DropBox listings and the key files (Tachyon, EXTEND, QS, SDCARD, MULTIFAT, W5200 and NETWORK) are still showing "16 days old"

[Peter Jakacki]

Hi Peter,

Working with basic sockets and trying to connect to a server I can't seem to set some registers set with L! and LW!
Or I am using these words incorrectly?

\ other standard w5200 code, network.fth and IP initialization code not included in this snippet
pub sDIP        $0C @SOCKET ;    \ 4 byte dest IP address
pub sDPORT        $10 @SOCKET ;    \ 2 byte dest port

0 == MYSOC
MYSOC SOCKET 
$10.10.1.210 sDIP L!
#80 sDPORT LW!
MYSOC SOCKET sCLOSE TCP #1099 PORT! sOPEN sCONNECT

Do you have an example of settting up a socket to connect to a server? The server examples are excellent in NETWORK.fth: FTP, TELNET, HTTP BTW

I've only used this in server mode so far but I will have a look at client mode. The WIZnet chips are nice except they have lots of little idiosyncrasies such as not being able to write certain registers when you want to, only when the chip feels it's okay! Watch that IP notation as you are specifying it in hex so that it will end up as $10101210 rather than &10.10.1.210

If you create a register defintion such as sDPORT you might consider having it also perform the write to register operation. This looks cleaner IMO and you don't have to remember what width it is either.

[D.P]

Hi Peter,

Working with basic sockets and trying to connect to a server I can't seem to set some registers set with L! and LW!
Or I am using these words incorrectly?

\ other standard w5200 code, network.fth and IP initialization code not included in this snippet
pub sDIP        $0C @SOCKET ;    \ 4 byte dest IP address
pub sDPORT        $10 @SOCKET ;    \ 2 byte dest port

0 == MYSOC
MYSOC SOCKET 
$10.10.1.210 sDIP L!
#80 sDPORT LW!
MYSOC SOCKET sCLOSE TCP #1099 PORT! sOPEN sCONNECT

Do you have an example of settting up a socket to connect to a server? The server examples are excellent in NETWORK.fth: FTP, TELNET, HTTP BTW

[D.P]

Thanks for the handholding.
Got the clock & baudrade fixed.
Got BST 0.19.4-pre12 so now I can use the serial terminal and connect that way. I get an Ok prompt
When I try to connect with minicom I get on the screen:
[code]
Welcome to minicom 2.4

OPTIONS: I18n
Compiled on Jan 25 2010, 07:02:36.
Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys


Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
Cold start - no user code - setting defaults
----------------------------------------------------------------
CTRL-A Z for help |230400 8N1 | NOR | Minicom 2.4 | VT102 | Offline
[\code]
It won't talk past that.
Why does it say "Offline"
I don't get an OK prompt like I do in bst terminal.

.

On my mac here the minicom command I use to connect to one of my boards on a specific USB port.

minicom -D /dev/tty.usbserial-A100PCDJ -b 230400

you need to plug in your "board" then check the /dev directory for the usb that is connected, each board/port combo will yield a unique device.

then start minicom as above with your parameters and don't forget to set the line delay as Peter has stated, I use 40 and no char delay.

[hinv]

Thanks for the handholding.
Got the clock & baudrade fixed.
Got BST 0.19.4-pre12 so now I can use the serial terminal and connect that way. I get an Ok prompt
When I try to connect with minicom I get on the screen:
[code]
Welcome to minicom 2.4

OPTIONS: I18n
Compiled on Jan 25 2010, 07:02:36.
Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys


Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
Cold start - no user code - setting defaults
----------------------------------------------------------------
























CTRL-A Z for help |230400 8N1 | NOR | Minicom 2.4 | VT102 | Offline
[\code]
It won't talk past that.
Why does it say "Offline"
I don't get an OK prompt like I do in bst terminal.

[Peter Jakacki]

Thanks!

It works now.

I got it to compile. Two questions:

1. Do I just compile and download the kernel to eeprom to start off?

2. How do I tell minicom which port to use?

Thanks for the handholding...

Doug

You can specify the comport on the command line as "minicom ttyUSB0" and then save the setup (^A,O,"Save setup..). Alternatively you can ^A,0,"Serial port setup" if you are already running minicom. Don;t forget to set the line delay to 20ms (^A,T,D) so that pasting without handshake will work. Once you have the PC compiled kernel loaded into EEPROM and assuming the correct clock has been configured then you should copy EXTEND.fth and paste it into the terminal which will complete the kernel build with the RAM image being written to EEPROM once the load is complete.

I noticed that the clock settings in the web document version is a bit hard to read as yellow on white so I've changed it to a red font, this is the section:

CON
_clkmode        = xtal1 + pll8x         ' <---------------- change to suit
_xinfreq        = 10_000_000                ' <---------------- change to suit your crystal
baud                = 230400                ' <-- change - tested from 300 baud to 3M baud

[hinv]

Thanks!

It works now.

I got it to compile. Two questions:

1. Do I just compile and download the kernel to eeprom to start off?

Got it after fixing the clock and the baud!

2. How do I tell minicom which port to use?

Thanks for the handholding...

Doug

[Peter Jakacki]

I got my PropDongle out to see if I can get this to work. I tried copying the code from https://docs.google.com/document/d/1...3ZDgPKEiIc/pub into bst. I get a compile error:
Untiled(2826,33)Error: Unresolved symbol - last

This is the first thing I tried to do. Did I miss a step?

Thanks,
Doug

I just checked that document and I did have a little bug in there with the "cntr" variable but the Dropbox version has also been updated I was in the middle of shuffling some of the "REG" task variables so that a task need only allocate the first 32 bytes if it needed it's own emit and key vectors etc. BTW, I'm using BST 0.19.4-pre12

[hinv]

I got my PropDongle out to see if I can get this to work. I tried copying the code from https://docs.google.com/document/d/1...3ZDgPKEiIc/pub into bst. I get a compile error:
Untiled(2826,33)Error: Unresolved symbol - last

This is the first thing I tried to do. Did I miss a step?

Thanks,
Doug

[Akkarin]

Hi Peter,

thank you for the style tips. I really smashed code snippets together without thinking about readability. I like the "fall into it" in particular.

Regarding my "test" task (which istn't a task at all): I tried to free #P9 with PININP and PNCLR real quickly but then had to leave the Prop for other work. I'll do some tests later.

EDIT: Re Prop2Prop coms I would just use a single wire common to all Props as the communications "bus" Use a 220R resistor in series with the pin so there aren't any problems with more than one Prop trying to drive the line. The SERIN and SEROUT work just fine up to 250K baud for a really simple network without requiring any special drivers. In fact I might just demonstrate such an arrangement with basically a cog dedicated to listening to the line and working out if it has been selected and buffering the receive data. Serial data can be buffered and then transmitted normally once the bus signals it's ready. Since the cog is listening all the time it can timeout to say the bus is free after which if it has data to send it will send out an address character, if that is acknowledged correctly then any data can then be sent. I can't see why a specialized point-to-point high-speed object would be needed though especially with slow sensor data.

In this multi-master scheme using the single common pin it would mean that there would be no need to "interrogate" the "slaves" as the "slaves" would be sending their data when they need to. The "master" can receive these data broadcasts and determine the source and do what it needs to do with the data or just ignore it.
[DATA BROADCAST ADDRESS] <ACK> [SOURCE ADDRESS] [DATA] [EOP]

The EOP is just a way of saying the packet is finished, no need to wait for a timeout as the bus is now free.

Will do that later, thanks.

[Peter Jakacki]

Hi all,
as mentioned earlier I'm still a Prop and Tachyon noob.
So I'm playing around with it. I managed to set up a counter to count the duration of a HIGH pulse of a square wave and convert it to microsecs and a frequency (assuming perfect 50% duty cycle).
Now I wanted to run this in a seperate cog and still display the counts and frequency in the terminal (TeraTerm, set up as suggested by Peter, thanks :-))
Here are the words I created so far:
<snip>

My goal is to "copy" an application I have developed using Spin (and lots of 3rd party objects) which consists of one master Prop and 2 to 5 slave props which reside on a seperate PCB each. The slave Props use counters to evaluate capacitive sensors, do some simple processing. the master Prop collects the sensor values from the slaves using Beau's HSP2P objects and also communicate with the PC and store the data to SD card.
So the next step after learning how to run code in a seperate cog would be to establish Prop-to-Prop communication.

Since you are new to the Prop what you might not be fully aware of is that each cog has it's own I/O registers and to allow them to share pins without one trying to set a pin high and another trying to set the same pin low, the Prop simply ORs them together. So any cog can set a pin high but if another cog tries to set it low then it will stay high.

What this means is that if you want another cog to talk to say P9 then you should also let that same cog handle the initialization for that pin. At present your init is calling GutenMorgen which in the process leaves P9 high (serial idle) and then when you start the test task it tries to signal a low on that same pin but due to the OR'd nature of the I/O pins it never happens.

So simply have your test task say GutenMorgen rather than the init task or else release the P9 pin before you start the task with the sequence #P9 PININP.

BTW, Forth "layout" styles vary considerably but it seems your code is bunched up way too tight, even just having a blank line between definitions would make it easier to follow. Don't forget that you can cascade or fall-through into the next definition so instead of calling CSetup you could "fall into it" like this:

: Init
    HEX GutenMorgen A #8 APIN 1 KHZ 
: CSetup  
    B #10 APIN %01000 CTRMODE #1 FRQ
;

I haven't tried to include the code for P9 here but I did also notice that your task is not really a task as it exits (rather than BEGIN .. AGAIN ) which will put it back into the IDLE loop for that cog. I also like to say #P8 APIN rather than #8 APIN (the # is redundant for single digit decimals) as this helps us to see that it's the P8 pin. TF allows "symbols" to be interspersed with digits in a prefixed number as long as it ends with a digit.



EDIT: Re Prop2Prop coms I would just use a single wire common to all Props as the communications "bus" Use a 220R resistor in series with the pin so there aren't any problems with more than one Prop trying to drive the line. The SERIN and SEROUT work just fine up to 250K baud for a really simple network without requiring any special drivers. In fact I might just demonstrate such an arrangement with basically a cog dedicated to listening to the line and working out if it has been selected and buffering the receive data. Serial data can be buffered and then transmitted normally once the bus signals it's ready. Since the cog is listening all the time it can timeout to say the bus is free after which if it has data to send it will send out an address character, if that is acknowledged correctly then any data can then be sent. I can't see why a specialized point-to-point high-speed object would be needed though especially with slow sensor data.

In this multi-master scheme using the single common pin it would mean that there would be no need to "interrogate" the "slaves" as the "slaves" would be sending their data when they need to. The "master" can receive these data broadcasts and determine the source and do what it needs to do with the data or just ignore it.
[DATA BROADCAST ADDRESS] <ACK> [SOURCE ADDRESS] [DATA] [EOP]

The EOP is just a way of saying the packet is finished, no need to wait for a timeout as the bus is now free.

[Akkarin]

Hi all,
as mentioned earlier I'm still a Prop and Tachyon noob.
So I'm playing around with it. I managed to set up a counter to count the duration of a HIGH pulse of a square wave and convert it to microsecs and a frequency (assuming perfect 50% duty cycle).
Now I wanted to run this in a seperate cog and still display the counts and frequency in the terminal (TeraTerm, set up as suggested by Peter, thanks :-))
Here are the words I created so far:

: LCDEMIT  #9 SEROUT ;
: LCD ' LCDEMIT uemit W! ;
: clrlcd #254 #9 SEROUT #01 #9 SEROUT ;
: GutenMorgen clrlcd LCD ." Guten Morgen :-) " CON ;
: C1KHZ A #8 APIN 1 KHZ ;
: ToMuS ( counter ticks -- µs ) 2* #125 * #10000 / ; ( assuming perfect 50% duty cycle )
: ToFreq  ( µs -- freq ) #1000000 SWAP / ;
: PHSB@ DROP CR $D SFR@ DUP DUP DUP ." HEX: " $4810 .NUM SPACE ." DEC: " $000A .NUM SPACE ." microsec: " ToMuS DUP $000A .NUM SPACE ." µs " SPACE ." Freq: " ToFreq $000A .NUM SPACE ." Hz ";
: PHS! ( n -- ) PHSA ctr C@ + COG! ;
: CSetup  B #10 APIN %01000 CTRMODE #1 FRQ ;
: Init HEX GutenMorgen C1KHZ CSetup ; 
: CountHigh  #10 MASK WAITPNE B #0 PHS! #10 MASK WAITPEQ  #10 MASK WAITPNE B #0 CTRMODE PHSB@ ;
: CountLoop  #10 #0 DO CountHigh CSetup  LOOP ;
AUTORUN Init
BACKUP 


pub test 
    #5 #0 DO CR clrlcd LCD I $000A .NUM SPACE ." Test" 125 ms LOOP 
    CON  ;

So, if "test" were the code I want to run in a seperate cog, I tried

' test TASK? RUN

but nothing happens on the LCD. I guess the target cog doesn't know anything about the LCD (or the console? I tried to display on the console as well), right?

Here is my INFO output:

  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300

Clock frequency = 80,000,000
MODULES LOADED:
1900: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000


AUTORUN Init
Tasks
0001: CONSOLE                         0000 00 00 00 00 00 00
0002: IDLE                            0000 01 00 00 00 00 00
0003: IDLE                            0000 01 00 00 00 00 00
0004: IDLE                            0000 01 00 00 00 00 00
0005: IDLE                            0000 01 00 00 00 00 00
0006: IDLE                            0000 01 00 00 00 00 00
0007: IDLE                            0000 01 00 00 00 00 00
Status
NAMES:  $5D2F...7309 for 5594 (2797 bytes added)
CODE:   $0000...3017 for 6717 (5911 bytes added)
CALLS:  0523 vectors free
RAM:    11544 bytes free


I2C BUS SCAN
Fast Device at 00A0  04 6F A1 10 00 DC 7D E4


I/O Port states
+----------u----------+
P00 <-- *D    1 --> P31
P01 <-- *D    1 <-- P30
P02 <-- *X   U1 --> P29
P03 <-- *X   U1 <-- P28
P04 <-- *D   X* --> P27
P05 <-- *X   X* --> P26
P06 <-- *X   X* --> P25
P07 <-- *X   X* --> P24
P08 --> *D   X* --> P23
P09 --> 1X   X* --> P22
P10 --> *D   X* --> P21
P11 <-- *X   X* --> P20
P12 <-- *X   X* --> P19
P13 <-- *X   X* --> P18
P14 <-- *X   X* --> P17
P15 <-- *X   X* --> P16
+---------------------+
Special function registers
01F0: PAR  = $0000_16DC   %0000_0000_0000_0000_0001_0110_1101_1100
01F1: CNT  = $DD8D_2DFF   %1101_1101_1000_1101_0010_1101_1111_1111
01F2: INA  = $F000_0702   %1111_0000_0000_0000_0000_0111_0000_0010
01F3: INB  = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F4: OUTA = $5000_0200   %0101_0000_0000_0000_0000_0010_0000_0000
01F5: OUTB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F6: DIRA = $5000_0700   %0101_0000_0000_0000_0000_0111_0000_0000
01F7: DIRB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F8: CTRA = $1000_0008   %0001_0000_0000_0000_0000_0000_0000_1000
01F9: CTRB = $2000_000A   %0010_0000_0000_0000_0000_0000_0000_1010
01FA: FRQA = $0000_D1B7   %0000_0000_0000_0000_1101_0001_1011_0111
01FB: FRQB = $0000_0001   %0000_0000_0000_0000_0000_0000_0000_0001
01FC: PHSA = $BD42_410E   %1011_1101_0100_0010_0100_0001_0000_1110
01FD: PHSB = $1B37_580D   %0001_1011_0011_0111_0101_1000_0000_1101
01FE: VCFG = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FF: VSCL = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000 ok

My goal is to "copy" an application I have developed using Spin (and lots of 3rd party objects) which consists of one master Prop and 2 to 5 slave props which reside on a seperate PCB each. The slave Props use counters to evaluate capacitive sensors, do some simple processing. the master Prop collects the sensor values from the slaves using Beau's HSP2P objects and also communicate with the PC and store the data to SD card.
So the next step after learning how to run code in a seperate cog would be to establish Prop-to-Prop communication.

[D.P]

Looks like a bug with the init as the first sector read if it's zero isn't read at all. Easy fix, I'll do it shortly.


EDIT: found where the bug crept in, must have when I introduced multiple files, it's in !SD, the line:
sector 16 ERASE
just needs to be replaced with.
sector 16 $FF FILL

After the above mods and format with SD Formatter.

SD 
Card inserted 
MFG                 03
OEM                 SD
PID                 SU08G
REV                 80
S/N                 9262.AD21
DATE                2013/10
CRC                 28
  CSD REGISTER      
*SDHC CARD* 
TACC                100ns
NSAC                0bps
TRANS               50MHz
BLKLEN              512
SIZE                7,579MB

0000_0000:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0010:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0020:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0030:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0040:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0050:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0060:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0070:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0080:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0090:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0100:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0110:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0120:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0130:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0140:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0150:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0160:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0170:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0180:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0190:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 82   .............
0000_01C0:   03 00 0B 50  CA C6 00 20   00 00 00 C0  EC 00 00 00   ...P... .....
0000_01D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 55 AA   .............
0000_0200:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0210:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0220:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0230:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0240:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0250:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0260:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0270:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0280:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0290:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0300:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0310:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0320:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0330:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0340:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0350:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0360:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0370:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0380:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0390:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ............k

[Peter Jakacki]

That doesn't look right as there is no partition table at $01BE onwards. sdcard.org "STRONGLY" recommend using their SD FORMATTER rather than the one that comes with your O/S as I have had mixed results with Windows formatting myself. I may have to write my own FORMAT definition though.

Looks like a bug with the init as the first sector read if it's zero isn't read at all. Easy fix, I'll do it shortly.


EDIT: found where the bug crept in, must have when I introduced multiple files, it's in !SD, the line:
sector 16 ERASE
just needs to be replaced with.
sector 16 $FF FILL

[Peter Jakacki]

Just for comparison here's mine. All blank, works great, formatted on Win7.
401A: W5200.fth WIZNET W5200 driver 131107.0000
3756: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131207-0000
2FD7: SDCARD.fth SD CARD Toolkit - 131114.0000
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000

MOUNT Mounted SD Card 
Media mounted as 9262.AD21 MSDOS5.0 NO NAME     FAT32    Cluster size = 32,768 k
SD 
Card inserted 
MFG                 03
OEM                 SD
PID                 SU08G
REV                 80
S/N                 9262.AD21
DATE                2013/10
CRC                 28
  CSD REGISTER      
*SDHC CARD* 
TACC                100ns
NSAC                0bps
TRANS               50MHz
BLKLEN              512
SIZE                7,579MB
________________________________
0 $400 XDUMP 
0000_0000:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0010:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0020:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0030:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0040:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0050:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0060:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0070:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0080:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0090:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0100:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0110:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0120:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0130:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0140:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0150:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0160:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0170:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0180:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0190:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0200:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0210:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0220:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0230:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0240:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0250:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0260:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0270:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0280:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0290:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0300:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0310:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0320:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0330:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0340:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0350:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0360:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0370:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0380:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0390:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ............k

That doesn't look right as there is no partition table at $01BE onwards. sdcard.org "STRONGLY" recommend using their SD FORMATTER rather than the one that comes with your O/S as I have had mixed results with Windows formatting myself. I may have to write my own FORMAT definition though.

[D.P]

Just for comparison here's mine. All blank, works great, formatted on Win7.
401A: W5200.fth WIZNET W5200 driver 131107.0000
3756: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131207-0000
2FD7: SDCARD.fth SD CARD Toolkit - 131114.0000
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000

MOUNT Mounted SD Card 
Media mounted as 9262.AD21 MSDOS5.0 NO NAME     FAT32    Cluster size = 32,768 k
SD 
Card inserted 
MFG                 03
OEM                 SD
PID                 SU08G
REV                 80
S/N                 9262.AD21
DATE                2013/10
CRC                 28
  CSD REGISTER      
*SDHC CARD* 
TACC                100ns
NSAC                0bps
TRANS               50MHz
BLKLEN              512
SIZE                7,579MB
________________________________
0 $400 XDUMP 
0000_0000:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0010:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0020:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0030:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0040:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0050:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0060:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0070:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0080:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0090:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_00F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0100:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0110:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0120:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0130:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0140:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0150:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0160:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0170:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0180:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0190:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_01F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0200:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0210:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0220:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0230:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0240:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0250:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0260:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0270:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0280:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0290:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_02F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0300:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0310:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0320:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0330:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0340:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0350:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0360:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0370:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0380:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_0390:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   .............
0000_03F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ............k

[Brian Riley]

AS requested... BBR

* WEB, FTP, and TELNET servers running * 
 ok
Mounted SD Card 
Media mounted as 3C18.8F1F          TACHYON1    FAT32    Cluster size = 32,768   Sectors = 15,269,888  ok
  ok
  ok
  ok
0 $400 XDUMP 
0000_0000:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0010:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0020:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0030:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0040:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0050:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0060:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0070:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0080:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0090:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_00A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_00B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_00C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_00D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_00E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_00F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0100:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0110:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0120:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0130:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0140:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0150:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0160:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0170:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0180:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0190:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_01A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_01B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 82   ................
0000_01C0:   03 00 0B 04  CD B7 00 20   00 00 00 00  E9 00 00 00   ....... ........
0000_01D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_01E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_01F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 55 AA   ..............U.
0000_0200:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0210:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0220:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0230:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0240:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0250:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0260:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0270:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0280:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0290:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_02A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_02B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_02C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_02D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_02E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_02F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0300:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0310:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0320:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0330:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0340:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0350:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0360:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0370:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0380:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_0390:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_03A0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_03B0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_03C0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_03D0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_03E0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................
0000_03F0:   00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................ ok

[Peter Jakacki]

Latest news from the fringe GOOD NEWS ... BETTER NEWS ... and A PUZZLE ...

Hi Brian, I've found that depending upon the system that you format your cards on it might be in CHS or LBA format. Can you do a 0 $400 XDUMP and copy the output in your reply?
A normal card's partition information should have:
0000_01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 ................
0000_01C0: 03 01 0B 30 F0 C0 00 20 00 00 00 0C 76 00 00 00 ...0... ....v...
0000_01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000_01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000_01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U.

But I find that some have been formatted with no information in the first sector and this in the second ($200..$3FF)
0000_03E0: 00 00 00 00 72 72 41 61 1B BE 0E 00 02 00 00 00 ....rrAa........
0000_03F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ..............U. ok

I'm trying to track down the information on this and update the code accordingly.

[Brian Riley]

The GOOD NEWS ... but, first, the BAD NEWS ... the bleeding edge code still suffers from REBOOT when dealing with MOUNT and its related commands. I did builds morning, afternoon, and evening pulling fresh source each new load attempt.


But, on a brighter note THE GOOD NEWS is that current DropBox package comes up clean ... Peter I have two small issues . ..

- You have MULTIFAT instead of MULTIFILE ... is that an OOOPPPSS or a change of heart?

- PLEASE, PLEASE, PLEASE ( this is me groveling!!! ;-] ) update the date code in the filename line so we easily tell what file revision we are dealing with. For example in the terminal output below, the date code is 131124, but CHANGELOG buried farther into the code is 131201 ... TNX!!

Latest news from the fringe GOOD NEWS ... BETTER NEWS ... and A PUZZLE ...

- the GOOD - Drop Box load 131209 Kernal loads clean and runs

- the BETTER - while the bleeding edge code from the "Links" page is again generating reboots, substituting the MULTIFILE.fth from the DropBox folder (the file misnamed MULTIFAT.fth) ... and IT WORKED ... THE PUZZLE.

The load looks like this

  Propeller .:.:--TACHYON--:.:. Forth V23131212.1200

NAMES:  $54BA...74CB for 8209 (0532 bytes added)
CODE:   $0000...520F for 12798 (2478 bytes added)
CALLS:  0124 vectors free
RAM:    0683 bytes free

AUTORUN BOOT
MODULES LOADED: 
4861: NETWORK.fth         WIZNET NETWORK SERVERS 131211.1530 
41A6: W5200.fth           WIZNET W5200 driver 131211.1530 
38E4: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
31A9: SDCARD.fth          SD CARD Toolkit - 131114.0000 
3007: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200 

----------------------------------------------------------------
GO 
NAMES:  $54BA...74CB for 8209 (0532 bytes added)
CODE:   $0000...520F for 12798 (2478 bytes added)
CALLS:  0124 vectors free
RAM:    0683 bytes free

AUTORUN BOOT
MODULES LOADED: 
4861: NETWORK.fth         WIZNET NETWORK SERVERS 131211.1530 
41A6: W5200.fth           WIZNET W5200 driver 131211.1530 
38E4: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
31A9: SDCARD.fth          SD CARD Toolkit - 131114.0000 
3007: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200 

*** Tachyon Forth Network and File Server *** 

Mounted SD Card 
Media mounted as 3C18.8F1F          TACHYON1    FAT32    Cluster size = 32,768   Sectors = 15,269,888
Listing directory 	TACHYON1   

CE1372  .FTH     EXTEND  .FTH     FAVICON .ICO     HOME    .HTM     HTTP404 .HTM     LOG0001 .TXT     LOG0002 .TXT     LOG0003 .TXT     
LOG0004 .TXT     LOG0005 .TXT     LOG0006 .TXT     LOG0007 .TXT     LOG0008 .TXT     LOGON   .        MULTIFAT.FTH     NETWORK .FTH     
ROM     .BIN     SDCARD  .FTH     SYSLOG  .TXT     TACHYON .JPG     TRASHE~1.        TACHYON .LST     ~1      .TRA     SPOTLI~1.        
W5200   .FTH     ROM1    .BIN     ROM3    .BIN     ROM0    .BIN     ROM2    .BIN     

Waiting for Ethernet to come up

I ran a diff on the 2 files, the output was over 800 lines, but closer inspection revealed most were the same code reformatted...

[D.P]

We could just say 2048 ALLOT but here we pass the figures to Forth to calculate. The ARRAY construct would do just that but it could also take a further parameter to define the word length.
So we could say:
8 64 4 ARRAY MYARRAY
which would take the x y and word length parameters and allocate 2048 bytes for MYARRAY which at runtime would take x and y and calculate the address. If we were storing strings in such an array then we might allocate 16 bytes per record and say
8 64 16 ARRAY MYARRAY
and then end up using it like this for strings:
" Greetings" 5 3 MYARRAY $!
5 3 MYARRAY PRINT$ Greetings

When I get some time today I will quickly write (and test) the code but also outline it's usage.

Sounds great, still I'm confusing something here, in the previous example (longs) the 5th element of the 3rd record should be addressed 2 x 64 x 4 + (5 x 4) for the address i.e. 532 bytes away from the origin of myarray no?

dp

[Peter Jakacki]

Just want to clarify my understanding of this syntax. You are "allocating" 2048 bytes total, the design of the arrary is 64 long members by 8 records?

This syntax is very straight forward just wrapping my brain around it is the problem, thanks.

We could just say 2048 ALLOT but here we pass the figures to Forth to calculate. The ARRAY construct would do just that but it could also take a further parameter to define the word length.
So we could say:
8 64 4 ARRAY MYARRAY
which would take the x y and word length parameters and allocate 2048 bytes for MYARRAY which at runtime would take x and y and calculate the address. If we were storing strings in such an array then we might allocate 16 bytes per record and say
8 64 16 ARRAY MYARRAY
and then end up using it like this for strings:
" Greetings" 5 3 MYARRAY $!
5 3 MYARRAY PRINT$ Greetings

When I get some time today I will quickly write (and test) the code but also outline it's usage.

[D.P]

Taking a guess at what you want to do here's a quick example using hub RAM:
DECIMAL
\ Create an 8 x 64 long array (the 4 * for bytes/long)
TABLE myarray 8 64 * 4 * ALLOT
\ Create the array access word which returns with the element address
\ the 5 SHL as there are 8*4 bytes/record and 2* 2* as a quick way of indexing longs
pub MYARRAY ( x y -- addr ) 5 SHL SWAP 2* 2* + myarray + ;
Usage:
\ Store a long at 5th element in 3rd record
12345678 5 3 MYARRAY !
Of course a more general method can be defined such as ARRAY so that you could say:
8 64 ARRAY MYARRAY
12345678 5 3 MYARRAY !
I may add a general-purpose two dimensional array construct to EXTEND as it is very simple to do.

Just want to clarify my understanding of this syntax. You are "allocating" 2048 bytes total, the design of the arrary is 64 long members by 8 records?

This syntax is very straight forward just wrapping my brain around it is the problem, thanks.

[Peter Jakacki]

so if you come from ARM-C did you think about directly moving to PropGCC.
Most standard code should run with little or no modification.

As far as TF is concerned

the COG contains the TF kernel, so there is no space for an array of significant size.
But depending on what you want to do TF is woth a look nevertheless.
I like it very much.

Taking a guess at what you want to do here's a quick example using hub RAM:
DECIMAL
\ Create an 8 x 64 long array (the 4 * for bytes/long)
TABLE myarray 8 64 * 4 * ALLOT
\ Create the array access word which returns with the element address
\ the 5 SHL as there are 8*4 bytes/record and 2* 2* as a quick way of indexing longs
pub MYARRAY ( x y -- addr ) 5 SHL SWAP 2* 2* + myarray + ;
Usage:
\ Store a long at 5th element in 3rd record
12345678 5 3 MYARRAY !
Of course a more general method can be defined such as ARRAY so that you could say:
8 64 ARRAY MYARRAY
12345678 5 3 MYARRAY !
I may add a general-purpose two dimensional array construct to EXTEND as it is very simple to do.

[MJB]

My apologies if this is not the place to ask the following question:

While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.

Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?

Edit: The code and data arrays (smallish) would preferably reside in COG RAM.

so if you come from ARM-C did you think about directly moving to PropGCC.
Most standard code should run with little or no modification.

As far as TF is concerned

Edit: The code and data arrays (smallish) would preferably reside in COG RAM

the COG contains the TF kernel, so there is no space for an array of significant size.
But depending on what you want to do TF is woth a look nevertheless.
I like it very much.

[K2]

@KC_Rob: Thanks! Very helpful references.

[Brian Riley]

Hi Brian, I've been making that many little changes lately that even I can't keep up with it, are you expecting more!!!?

l am glad to see that I am not alone in this.

Putting aside labeling of builds I just wonder what it is about your setup that should cause a reboot? Simply disabling the autorun and interactively running sections of startup code should reveal the problem. Can you track it down this way? If you really want some interactive help I can do so via remote desktop software such as Splashtop Streamer so you can see what I'm doing and vice-versa on your system.

The REBOOT occurs in the NETWORK.fth word GO when it executes "MOUNT ls". To examine this I need only to build;

Tachyon_V23.spin EXTEND.fth QS.fth SDCARD.fth MULTIFILE.fth

At this point I need only type MOUNT. It will either "mount" the SD card or REBOOT. There is no need to load W5200 and NETWORK.

Next step ... since there is no console emission between MOUNT and the REBOOT, I will 'walk' a console message through the code and trace how far it gets before it goes kablooey!

I will look at what I can do for snapshots, perhaps putting all the files into snapshot folders which are named accordingly although the file names would still be the same.

PERFECT ... its more or less what I have started to do here, though its a greater effort since I have to do it sans your knowledge of where you have been tinkering.

[Peter Jakacki]

The GOOD NEWS ... but, first, the BAD NEWS ...

Hi Brian, I've been making that many little changes lately that even I can't keep up with it, are you expecting more!!!?

Putting aside labeling of builds I just wonder what it is about your setup that should cause a reboot? Simply disabling the autorun and interactively running sections of startup code should reveal the problem. Can you track it down this way? If you really want some interactive help I can do so via remote desktop software such as Splashtop Streamer so you can see what I'm doing and vice-versa on your system.

I will look at what I can do for snapshots, perhaps putting all the files into snapshot folders which are named accordingly although the file names would still be the same.

[KC_Rob]

My apologies if this is not the place to ask the following question: While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF. Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?

The section from "And so Forth" on multidimensional arrays might get you headed in the right direction. Of course TF is a little different, so if you haven't already, you should go through Peter's Forth Introduction. The nice thing about TF (Forth generally) is that you can burn a board and start playing with things "live" to see what works and what doesn't right away. Fully interactive. That's where Forth really shines, in my view. Anyway, I hope this helps.

[Brian Riley]

The GOOD NEWS ... but, first, the BAD NEWS ... the bleeding edge code still suffers from REBOOT when dealing with MOUNT and its related commands. I did builds morning, afternoon, and evening pulling fresh source each new load attempt.


But, on a brighter note THE GOOD NEWS is that current DropBox package comes up clean ... Peter I have two small issues . ..

- You have MULTIFAT instead of MULTIFILE ... is that an OOOPPPSS or a change of heart?

- PLEASE, PLEASE, PLEASE ( this is me groveling!!! ;-] ) update the date code in the filename line so we easily tell what file revision we are dealing with. For example in the terminal output below, the date code is 131124, but CHANGELOG buried farther into the code is 131201 ... TNX

...

RECLAIM
...
Removing (rnd)
Removing @X
Removing (NULLOUT)
Removing @ATR
Removing LEMIT
Reclaimed 735 bytes  ok
END 
0321 

00:01:08  End of source code, 0322 lines processed and 0000 errors found 
Load time = 25,211ms

NAMES:  $5AF5...74C3 for 6606 (0105 bytes added)
CODE:   $0000...4176 for 10152 (2242 bytes added)
CALLS:  0327 vectors free
RAM:    6527 bytes free
ok
AUTORUN BOOT            \ 
?BACKUP  ok
  ok
MOUNT Mounted SD Card 
Media mounted as 3C18.8F1F          TACHYON1    FAT32    Cluster size = 32,768   Sectors = 15,269,888 ok
" ROM0.BIN"  SAVEIMG  Saving EEPROM image to ROM0.BIN ok
  ok

REBOOT

  Propeller .:.:--TACHYON--:.:. Forth V23131209.1100

NAMES:  $5AF5...74C3 for 6606 (0105 bytes added)
CODE:   $0000...4176 for 10152 (2242 bytes added)
CALLS:  0327 vectors free
RAM:    6527 bytes free

AUTORUN BOOT
MODULES LOADED: 
38B4: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
3179: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2FD7: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

----------------------------------------------------------------
  ok

[K2]

Thanks for a great answer, Martin. I think I get it.

[Martin_H]

My apologies if this is not the place to ask the following question:

While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.

Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?

Edit: The code and data arrays (smallish) would preferably reside in COG RAM.

I'm still new to Forth, and can't speak for Tachyon specifically, but Forth is a lower level language. You don't get data structures like arrays out of the box like you would with C, so in this regards it is similar to assembler. But the language is interactive and extensible, so you can implement arrays easier than you would in PASM. The extensions then become part of the language, so the language becomes easier to use as you add onto it.

The joke is that if Forth were a car it would arrive as a kit, you could build any car imaginable out of it, but it will drive backwards when it is done. Which raises the obvious question why did I bother to learn how to use it?

Everyone has their own reasons, but for me where Forth shines is that you build a domain specific language to solve your problem. This language can then be scripted via a serial command window. This is really useful for developing motion scripts for my robot arms.

[K2]

My apologies if this is not the place to ask the following question:

While converting some C code (from an ARM) to PASM this morning, the need to create and then index 2D arrays got a little tedious. What is so simple to code in C was a chore in PASM. It made me wonder if it was time consider TF.

Acknowledging that there would be a steep learning curve, I simply want to know if at the end of the road there would be the sought-after payoff? Are 2D arrays convenient to create and index in Forth, and TF specifically?

Edit: The code and data arrays (smallish) would preferably reside in COG RAM.

[Peter Jakacki]

That was not an easy bug find Peter!

With all these [MODULES] we should be able to get a validation load for all new TACHYON builds. How can I help? I'm thinking the SD card could hold the results of valid operations that are tested. I used a similar "validation file" technique when I tested cross platform in-memory database engines .

These bugs are few and far between and when you consider the almost interactive nature of the source code "release", in that it always released in that sense via Google docs and webdocs, then Dropbox , then I am very surprised that there are not more problems. When you are on the bleeding edge you expect to get cut!

However if I devoted too much time to validation testing I would get far less done and everyone would have to wait for a release, maybe only twice a year! The Tachyon project as it is, is a WIP, but a very usable one at that.

I noticed that my ISP is blocking port 80 so I am going to find out if I can get it unblocked. In the meantime ports 81 and 82 are forwarded to the Prop and still work fine. tachyonforth.com:81

[D.P]

Hi Brian, don't get mad at me but I think your problems may have resulted from a vector that failed to get initialized at compile time. I just ran into the problem now but I found that whenever CARD? was invoked that it crashed. This was traced back to the "ucard" vector which is normally 0 and not taken except in this case it had garbage in it. In recent versions when I create a variable it also inits it's storage to zero but "ucard" was moved over to the DS style variable, one that is basically a constant that points to the storage area, which was not being initialized. Now that it's specifically zeroed at compile time it now works.

Sorry about that

That was not an easy bug find Peter!

With all these [MODULES] we should be able to get a validation load for all new TACHYON builds. How can I help? I'm thinking the SD card could hold the results of valid operations that are tested. I used a similar "validation file" technique when I tested cross platform in-memory database engines .

[Peter Jakacki]

Oooopppss! Here we go again ... I had this problem last night, but being tired, I waited until I could grab some shuteye as well as grab a set of fresh files from the "Links" page. The .SPIN file was edited for pll16x/5_000_000. The .FTH-files were loaded "'as-is" in this order ... EXTEND, QS, SDCARD, MULTIFILE. Upon completion I typed SAVEROM and the board rebooted. I repeated the whole load procedure with the same result. I tried typing MOUNT before SAVEROM. It rebooted. I changed QS boards ... same drill .... I reloaded, first commenting out the RECLAIM at the end of MULTIFILE ... same results ----> REBOOT!

Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.

Hi Brian, don't get mad at me but I think your problems may have resulted from a vector that failed to get initialized at compile time. I just ran into the problem now but I found that whenever CARD? was invoked that it crashed. This was traced back to the "ucard" vector which is normally 0 and not taken except in this case it had garbage in it. In recent versions when I create a variable it also inits it's storage to zero but "ucard" was moved over to the DS style variable, one that is basically a constant that points to the storage area, which was not being initialized. Now that it's specifically zeroed at compile time it now works.

Sorry about that

[Peter Jakacki]

Oooopppss! Here we go again ... I had this problem last night, but being tired, I waited until I could grab some shuteye as well as grab a set of fresh files from the "Links" page. The .SPIN file was edited for pll16x/5_000_000. The .FTH-files were loaded "'as-is" in this order ... EXTEND, QS, SDCARD, MULTIFILE. Upon completion I typed SAVEROM and the board rebooted. I repeated the whole load procedure with the same result. I tried typing MOUNT before SAVEROM. It rebooted. I changed QS boards ... same drill .... I reloaded, first commenting out the RECLAIM at the end of MULTIFILE ... same results ----> REBOOT!

Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.

...
Removing (NULLOUT)
Removing @ATR
Removing LEMIT
Reclaimed 728 bytes  ok
END 
0252 

00:00:00  End of source code, 0253 lines processed and 0000 errors found 
Load time = 20,451ms

NAMES:  $59E8...73B4 for 6604 (0112 bytes added)
CODE:   $0000...40EA for 10014 (2094 bytes added)
CALLS:  0328 vectors free
RAM:    6398 bytes free
 ok
AUTORUN BOOT                        \ 
?BACKUP  ok
  ok
SAVEROM 

  Propeller .:.:--TACHYON--:.:. Forth V23131204.0300

NAMES:  $59E8...73B4 for 6604 (0112 bytes added)
CODE:   $0000...40EA for 10014 (2094 bytes added)
CALLS:  0328 vectors free
RAM:    6398 bytes free

AUTORUN BOOT
MODULES LOADED: 
38BC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
3181: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2FDF: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

----------------------------------------------------------------

I was shuffling the kernel's memory around last night so if you used the bleeding edge web documents for source then that might have something to do with it. I'm checking it out now and making a few adjustments. If you do happen to use the bleeding edge source then it might be a good idea to keep a copy of the last files that proved stable just in case. If you do that you can also do a file compare to find out what's changed too if you are curious enough to want to know.

[Brian Riley]

Oooopppss! Here we go again ... I had this problem last night, but being tired, I waited until I could grab some shuteye as well as grab a set of fresh files from the "Links" page. The .SPIN file was edited for pll16x/5_000_000. The .FTH-files were loaded "'as-is" in this order ... EXTEND, QS, SDCARD, MULTIFILE. Upon completion I typed SAVEROM and the board rebooted. I repeated the whole load procedure with the same result. I tried typing MOUNT before SAVEROM. It rebooted. I changed QS boards ... same drill .... I reloaded, first commenting out the RECLAIM at the end of MULTIFILE ... same results ----> REBOOT!

Obviously, SAVEROM/LOADROM need a MOUNTed SDcard... I rather suspect the problem is there.

...
Removing (NULLOUT)
Removing @ATR
Removing LEMIT
Reclaimed 728 bytes  ok
END 
0252 

00:00:00  End of source code, 0253 lines processed and 0000 errors found 
Load time = 20,451ms

NAMES:  $59E8...73B4 for 6604 (0112 bytes added)
CODE:   $0000...40EA for 10014 (2094 bytes added)
CALLS:  0328 vectors free
RAM:    6398 bytes free
 ok
AUTORUN BOOT                        \ 
?BACKUP  ok
  ok
SAVEROM 

  Propeller .:.:--TACHYON--:.:. Forth V23131204.0300

NAMES:  $59E8...73B4 for 6604 (0112 bytes added)
CODE:   $0000...40EA for 10014 (2094 bytes added)
CALLS:  0328 vectors free
RAM:    6398 bytes free

AUTORUN BOOT
MODULES LOADED: 
38BC: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
3181: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2FDF: QuickStart.fth      QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

----------------------------------------------------------------

[Peter Jakacki]

LOADROM AND SAVEROM excited me. They had so much potential .... 20 minutes, a few tweaks, and about an hour of testing and here we go. LOADROM/SAVEROM are located at the bottom of MULTIFILE.FTH. Just replace them withe code below and reload.

{
    2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
    I cloned ROM.BIN  four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, 
    and ROM3.BIN.
    
    LOADROM and SAVEROM, either invoked without stack parameters reads from or 
    or writes to the file ROM.BIN just as PBJ coded it.
    
    But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
    quoted filename and you can load from or save to any 32768 byte file
    already present on the SD Card. Examples.

            LOADROM                    \ loads image from ROM.BIN to EEPROM
            " ROM2.BIN"  SAVEIMG    \ saves RAM image to ROM2.BIN
            SAVEROM                    \ saves RAM image to ROM.BIN
            " ROM1.BIN"  LOADIMG    \ loads image from ROM1.BIN to EEPROM
    
    BBR _ Underhill Center, VT  2013-12-06
}

pub SAVEROM        ( -- )
        " ROM.BIN"
        
pub SAVEIMG        ( "filename$" -- )
        1 FILE FOPEN$
         IF
        0 $8000 FIXCKSUM
           ."  Saving to File "
           0 FILE@ $8000
           ADO
             DUP BUFFERS $200 ELOAD $200 +
             BUFFERS I 9 SHR SDWR DROP                        \ write one full sector
           $200 +LOOP
           DROP
         THEN
        ;


pub LOADROM        ( -- )
        " ROM.BIN"
pub LOADIMG        ( "filename$" -- )
         FOPEN$ IF ." Loading ROM Image to EEPROM "
           FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
           DROP
         THEN         
        ;

{
    2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
    I cloned ROM.BIN  four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, 
    and ROM3.BIN.
    
    LOADROM and SAVEROM, either invoked without stack parameters reads from or 
    or writes to the file ROM.BIN just as PBJ coded it.
    
    But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
    quoted filename and you can load from or save to any 32768 byte file
    already present on the SD Card. Examples.

            LOADROM                    \ loads image from ROM.BIN to EEPROM
            " ROM2.BIN"  SAVEIMG    \ saves RAM image to ROM2.BIN
            SAVEROM                    \ saves RAM image to ROM.BIN
            " ROM1.BIN"  LOADIMG    \ loads image from ROM1.BIN to EEPROM
    
    BBR _ Underhill Center, VT  2013-12-06
}

pub SAVEROM        ( -- )
        " ROM.BIN"
        
pub SAVEIMG        ( "filename$" -- )
        1 FILE FOPEN$
         IF
        0 $8000 FIXCKSUM
           ."  Saving to File "
           0 FILE@ $8000
           ADO
             DUP BUFFERS $200 ELOAD $200 +
             BUFFERS I 9 SHR SDWR DROP                        \ write one full sector
           $200 +LOOP
           DROP
         THEN
        ;


pub LOADROM        ( -- )
        " ROM.BIN"
pub LOADIMG        ( "filename$" -- )
         FOPEN$ IF ." Loading ROM Image to EEPROM "
           FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
           DROP
         THEN         
        ;

Hi Brian, I wasn't intending to load multiple ROMs but there's no reason you can't so I have incorporated a slightly modified version of this using your SAVEIMG and LOADIMG names.

[D.P]

LOADROM AND SAVEROM excited me. They had so much potential .... 20 minutes, a few tweaks, and about an hour of testing and here we go. LOADROM/SAVEROM are located at the bottom of MULTIFILE.FTH. Just replace them withe code below and reload.

{
	2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
	I cloned ROM.BIN  four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, 
	and ROM3.BIN.
	
	LOADROM and SAVEROM, either invoked without stack parameters reads from or 
	or writes to the file ROM.BIN just as PBJ coded it.
	
	But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
	quoted filename and you can load from or save to any 32768 byte file
	already present on the SD Card. Examples.

			LOADROM					\ loads image from ROM.BIN to EEPROM
			" ROM2.BIN"  SAVEIMG	\ saves RAM image to ROM2.BIN
			SAVEROM					\ saves RAM image to ROM.BIN
			" ROM1.BIN"  LOADIMG	\ loads image from ROM1.BIN to EEPROM
	
	BBR _ Underhill Center, VT  2013-12-06
}

pub SAVEROM		( -- )
        " ROM.BIN"
		
pub SAVEIMG		( "filename$" -- )
        1 FILE FOPEN$
         IF
        0 $8000 FIXCKSUM
           ."  Saving to File "
           0 FILE@ $8000
           ADO
             DUP BUFFERS $200 ELOAD $200 +
             BUFFERS I 9 SHR SDWR DROP                        \ write one full sector
           $200 +LOOP
           DROP
         THEN
        ;


pub LOADROM		( -- )
		" ROM.BIN"
pub LOADIMG		( "filename$" -- )
	 	FOPEN$ IF ." Loading ROM Image to EEPROM "
           FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
           DROP
         THEN         
        ;

{
	2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
	I cloned ROM.BIN  four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, 
	and ROM3.BIN.
	
	LOADROM and SAVEROM, either invoked without stack parameters reads from or 
	or writes to the file ROM.BIN just as PBJ coded it.
	
	But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
	quoted filename and you can load from or save to any 32768 byte file
	already present on the SD Card. Examples.
.
.
.

Nice work Brian, very cool, I can now change from Fully Automated Pressure Sterilizer ROM0.BIN to Full TCP/IP Server mode ROM1.BIN, althought with TF I can run everything at the same time still and Peter is still busy reclaiming more memory

[Brian Riley]

LOADROM AND SAVEROM excited me. They had so much potential .... 20 minutes, a few tweaks, and about an hour of testing and here we go. LOADROM/SAVEROM are located at the bottom of MULTIFILE.FTH. Just replace them withe code below and reload.

{
	2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
	I cloned ROM.BIN  four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, 
	and ROM3.BIN.
	
	LOADROM and SAVEROM, either invoked without stack parameters reads from or 
	or writes to the file ROM.BIN just as PBJ coded it.
	
	But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
	quoted filename and you can load from or save to any 32768 byte file
	already present on the SD Card. Examples.

			LOADROM					\ loads image from ROM.BIN to EEPROM
			" ROM2.BIN"  SAVEIMG	\ saves RAM image to ROM2.BIN
			SAVEROM					\ saves RAM image to ROM.BIN
			" ROM1.BIN"  LOADIMG	\ loads image from ROM1.BIN to EEPROM
	
	BBR _ Underhill Center, VT  2013-12-06
}

pub SAVEROM		( -- )
        " ROM.BIN"
		
pub SAVEIMG		( "filename$" -- )
        1 FILE FOPEN$
         IF
        0 $8000 FIXCKSUM
           ."  Saving to File "
           0 FILE@ $8000
           ADO
             DUP BUFFERS $200 ELOAD $200 +
             BUFFERS I 9 SHR SDWR DROP                        \ write one full sector
           $200 +LOOP
           DROP
         THEN
        ;


pub LOADROM		( -- )
		" ROM.BIN"
pub LOADIMG		( "filename$" -- )
	 	FOPEN$ IF ." Loading ROM Image to EEPROM "
           FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
           DROP
         THEN         
        ;

{
	2013-12-06 - modified LOADROM/SAVEROM to allow multiple IMAGE files.
	I cloned ROM.BIN  four times, creating ROM0.BIN, ROM1.BIN, ROM2.BIN, 
	and ROM3.BIN.
	
	LOADROM and SAVEROM, either invoked without stack parameters reads from or 
	or writes to the file ROM.BIN just as PBJ coded it.
	
	But, clinb under the hood by invoking LOADIMG or SAVEIMG prefaced by the
	quoted filename and you can load from or save to any 32768 byte file
	already present on the SD Card. Examples.

			LOADROM					\ loads image from ROM.BIN to EEPROM
			" ROM2.BIN"  SAVEIMG	\ saves RAM image to ROM2.BIN
			SAVEROM					\ saves RAM image to ROM.BIN
			" ROM1.BIN"  LOADIMG	\ loads image from ROM1.BIN to EEPROM
	
	BBR _ Underhill Center, VT  2013-12-06
}

pub SAVEROM		( -- )
        " ROM.BIN"
		
pub SAVEIMG		( "filename$" -- )
        1 FILE FOPEN$
         IF
        0 $8000 FIXCKSUM
           ."  Saving to File "
           0 FILE@ $8000
           ADO
             DUP BUFFERS $200 ELOAD $200 +
             BUFFERS I 9 SHR SDWR DROP                        \ write one full sector
           $200 +LOOP
           DROP
         THEN
        ;


pub LOADROM		( -- )
		" ROM.BIN"
pub LOADIMG		( "filename$" -- )
	 	FOPEN$ IF ." Loading ROM Image to EEPROM "
           FILE@ 0 $7FE0 ADO DUP I + XADR I $40 ESAVE $40 +LOOP
           DROP
         THEN         
        ;

[D.P]

A SECOND DAY of successful builds ....

I think that I have found bug in the virtual time code

.DT 2000/00/00 00:55:43 ok
 
$131205 DATE!  ok

$202732 TIME!  ok

.DT 2013/12/05 32:39:55 ok

I am busy right now so I don't have the time to debug and see if the problem lies in .TIME or TIME!

Also, the virtual RTC doesn't seem to be updating the file date/time.

P.S. MY build today went absolutely clean .. I did a COLD on yesterday's build and applied the recently updated files from DropBox substituting QS.FTH

Never mind

[Peter Jakacki]

At present even with a RECLAIM of unnecessary dictionary word memory there is not much memory left after a full compile, although it's still plenty to play with or write a small app. So the combination of code, dictionary, file buffers, serial buffer (reclaimed kernel image), networking etc takes up most of the 32K memory. You can claw at least 3K of that back by defining SMALL before you start loading EXTEND. Just type CREATE SMALL and then load EXTEND which will leave out code that is hardly used such as PWM and MCP3208 etc and some more obscure debug words and also including QWORDS but not WORDS.

With a little more time I will move most of the dictionary to SD for those builds that are large enough that they start running out of precious 32K hub memory. I have already experimented with this and this should make around 10K or more available for application code which in my experience is way more than enough, even my current application only needs about 2K or so. When the dictionary is moved to SD it is optimized as one header per 32 bytes so that we get 16 names per sector but if we load in an application serially it will be saved directly to a file before an FLOAD is executed automatically. So the loading can go as fast as it can without having to worry about extra line delays due to slower searches. Kernel words will "cached" so there is no delay there.

I did some stats on length of headers and found that there was an average name length of 8 bytes and a maximum of 19. So 32 bytes is more than enough as each header normally has 4 other bytes as well. There is a vector associated with each header so this vector will be used to look up stack and help comments stored in another file. The byte-code vector implementation is also of great benefit for P2TF as one or two bytes is all that is needed to address the full 128K but more on that as the time draws closer.

My immediate priority is to fix up the BLKSEND as I've stuffed something up there and haven't had time to look at it. Once this is fixed then FTP should be working properly again. DHCP is another thing to do too.

[Brian Riley]

A SECOND DAY of successful builds ....

I think that I have found bug in the virtual time code

.DT 2000/00/00 00:55:43 ok
 
$131205 DATE!  ok

$202732 TIME!  ok

.DT 2013/12/05 32:39:55 ok

I am busy right now so I don't have the time to debug and see if the problem lies in .TIME or TIME!

Also, the virtual RTC doesn't seem to be updating the file date/time.

P.S. MY build today went absolutely clean .. I did a COLD on yesterday's build and applied the recently updated files from DropBox substituting QS.FTH

[TrapperBob]

SUCCESS also!!!!

Needed to "wade thru" some faulty SD cards. Now I have purchased some new ones on cyber sale week. Should have more time this weekend to explore more in TACHYON land!

Great work Peter. Hurrah!!

Bob

[Peter Jakacki]

I have assigned a domain for the Tachyon Forth server on standard ports (80 rather than 81) etc. So there is no need to specify the ip address or the :81 part anymore.
tachyonforth.com

EDIT: BTW, there's a 5 minute alarm timeout on the Telnet and FTP sessions which will reboot the server after 5 minutes if it is still connected. If you are on Telnet this is easy to circumvent but I won't tell you how, just look at the source. HTTP GET requests are limited to 1 minute (long long time).

[Brian Riley]

*** SUCCESS ***

Using the updated Dropbox files Tachyon V23 .spin, and Forth files EXTEND, QuickStart, SDCARD, MULTIFILE, W5200, and NETWORK with the following edits

Tachyon v23 - changed pll to 16 and Xin to 5 MHz

NETWORK - commented out AUTORUN GO, and changed "-1 LED!" to "!LEDS"

I paused after loading MULTIFILE did a BACKUP and tested !SD and SD then MOUNT ... all OK.

I ran an ethernet cable from the wireless router across the living room to my office to the QS Wiznet board. It in turn went via USB to my iMac and ZTerm program. I opened a terminal window inMac OSX and ran telnet and ftp and used Safari to run http. I also checked using a lightweight Telnet client from my iPhone and iPad Air

Its been up and running for 3 hours with only one 'crash' ... literally, my wife's crazy GSD tripped on the ethernet cable and the power plug pulled from the socket on the QS WizNet board.

[D.P]

Hey Brian, obviously there's a problem and so it's important then to make sure that the application doesn't autorun so you can test out and find what the problem is. Either remove the AUTORUN GO statement from the end of NETWORK or else type AUTORUN NONE BACKUP after you have loaded the modules but before you have reset it. Then I would go with the SD word to init and check the SD card itself before I would try mounting the file system.


Has anyone noticed from perusing the source code that there is not an ounce of assembler? It's all written in TF and all running from the one cog. Of course I have added certain SPI functions to the kernel but they still run from the same cog unlike many Spin objects which require another cog just for that function. This was one of the aims of Tachyon, to be fast enough to handle almost all operations without resorting to inline assembly or a variation thereof in a user application or module. I think that this current code certainly reflects that, and despite Forth being "typeless" too

* WEB, FTP, and TELNET servers running * 
----------------------------------------------------------------
TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       269C 01 00 00 00 00 00  ok

Yes, I did notice everthing is in TF but forgot about 1Cog, wow. I would say you have accomplished your goal well Peter. Also I have had 0 errors with SD with every card I have tried as one reference point on my BOE board.

[Peter Jakacki]

I was using a Kingston microSDHC, Class 4, 8 GB. This card read and MOUNTed fine with the "as-is" load of SDCARD and MULTIFILE 3-4 days ago. 2 days ago the endless reboots started.

Hey Brian, obviously there's a problem and so it's important then to make sure that the application doesn't autorun so you can test out and find what the problem is. Either remove the AUTORUN GO statement from the end of NETWORK or else type AUTORUN NONE BACKUP after you have loaded the modules but before you have reset it. Then I would go with the SD word to init and check the SD card itself before I would try mounting the file system.


Has anyone noticed from perusing the source code that there is not an ounce of assembler? It's all written in TF and all running from the one cog. Of course I have added certain SPI functions to the kernel but they still run from the same cog unlike many Spin objects which require another cog just for that function. This was one of the aims of Tachyon, to be fast enough to handle almost all operations without resorting to inline assembly or a variation thereof in a user application or module. I think that this current code certainly reflects that, and despite Forth being "typeless" too

* WEB, FTP, and TELNET servers running * 
----------------------------------------------------------------
TASKS 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0002: IDLE                            0000 01 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       269C 01 00 00 00 00 00  ok

[D.P]

post these files and let me try

[Brian Riley]

I was using a Kingston microSDHC, Class 4, 8 GB. This card read and MOUNTed fine with the "as-is" load of SDCARD and MULTIFILE 3-4 days ago. 2 days ago the endless reboots started.

[D.P]

Thanks
Bob

Thanks for checking that, the -1 LED! basically does the same thing as what !LED does, turn off all the LEDs. However that function is already implemented in !PCB so for this reason I removed the later LED reference from NETWORK. If you still have troubles just disable the autorun simply by giving AUTORUN an invalid address such as AUTORUN NONE and then running BACKUP. Of course you may not be able to get to this stage so the trick is to either comment out the AUTORUN directive at the end of the NETWORK file when it's loaded or invalidate it with AUTORUN NONE BACKUP before you reboot. The system also looks for ^As at the console input during reboot in which case it will ignore the autorun.

Anyway, once it's not caught in a boot loop you can use the Forth words themselves to find out what's going on. Try SD which will init the SD card and report it for starters.

Missed that definition, thought LED! was LED1, now I'm cleared up on this. Also I have been using 4 and 8 Gig SD Cards without issue, multiple vendors.

[Peter Jakacki]

Peter,

I have used all the latest files. I am at work right now and will not be able to check the sdcard until later this afternoon. Not swhat size it is or if it is even good.

One thing I did notice is that in the QuickStart.fth header on the web page , the LED! word was not defined and NETWORK.fth uses that word. I defined it as you did in the CE1272.fth .
NETWORK.fth loaded correctly after that. That is the point I left it at after seeing the constant reboots on powerup.

[QUOTE

Propeller .:.:--TACHYON--:.:. Forth V23131204.0300

NAMES: $544A...73B4 for 8042 (0507 bytes added)
CODE: $0000...5002 for 12440 (2297 bytes added)
CALLS: 0178 vectors free
RAM: 1096 bytes free


AUTORUN GO
MODULES LOADED:
4709: NETWORK.fth WIZNET NETWORK SERVERS 131023.1500
4086: W5200.fth WIZNET W5200 driver 131107.0000
38C4: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131111-0000
3187: SDCARD.fth SD CARD Toolkit - 131114.0000
2FBF: QuickStart.fth QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000


*** Tachyon Forth Network and File Server ***]

Thanks
Bob[/QUOTE]

Thanks for checking that, the -1 LED! basically does the same thing as what !LED does, turn off all the LEDs. However that function is already implemented in !PCB so for this reason I removed the later LED reference from NETWORK. If you still have troubles just disable the autorun simply by giving AUTORUN an invalid address such as AUTORUN NONE and then running BACKUP. Of course you may not be able to get to this stage so the trick is to either comment out the AUTORUN directive at the end of the NETWORK file when it's loaded or invalidate it with AUTORUN NONE BACKUP before you reboot. The system also looks for ^As at the console input during reboot in which case it will ignore the autorun.

Anyway, once it's not caught in a boot loop you can use the Forth words themselves to find out what's going on. Try SD which will init the SD card and report it for starters.

[TrapperBob]

Peter,

I have used all the latest files. I am at work right now and will not be able to check the sdcard until later this afternoon. Not swhat size it is or if it is even good.

One thing I did notice is that in the QuickStart.fth header on the web page , the LED! word was not defined and NETWORK.fth uses that word. I defined it as you did in the CE1272.fth .
NETWORK.fth loaded correctly after that. That is the point I left it at after seeing the constant reboots on powerup.

[QUOTE

Propeller .:.:--TACHYON--:.:. Forth V23131204.0300

NAMES: $544A...73B4 for 8042 (0507 bytes added)
CODE: $0000...5002 for 12440 (2297 bytes added)
CALLS: 0178 vectors free
RAM: 1096 bytes free


AUTORUN GO
MODULES LOADED:
4709: NETWORK.fth WIZNET NETWORK SERVERS 131023.1500
4086: W5200.fth WIZNET W5200 driver 131107.0000
38C4: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131111-0000
3187: SDCARD.fth SD CARD Toolkit - 131114.0000
2FBF: QuickStart.fth QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000


*** Tachyon Forth Network and File Server ***][/QUOTE]


Thanks
Bob

[Peter Jakacki]

Brian,

I am seeing the same REBOOT as Brian is on MOUNT on my QS and W5200. Need to check into the actual sdcard I am using.

Thanks

As mentioned it hasn't been tuned for 2GB cards and FAT16 although the low level drivers should work, I just haven't gotten around to checking FAT16, and at this point there probably isn't much point. Have you used all the latest files including the kernel?

BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll

To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.

[TrapperBob]

Brian,

I am seeing the same REBOOT as Brian is on MOUNT on my QS and W5200. Need to check into the actual sdcard I am using.

Thanks

[MJB]

Quick question to anyone who's interested in trying this out. What W5200 Prop hardware do you have? I guess it might be the combination of the QuickStart and the W5200 Ethernet board for the QuickStart. I could probably create a hardware header file for this and download a binary to suit but only if someone is going to try this out.

The SPINNERETTE is also a viable board isn't it?
After I have moved from Germany to Spain again next week and dust has settled a little, I was thinking of giving my Spinnetete a try with TF.
I also have a load of old WIZnet modules with the W5100 - will those work too?

really impressive what you create here

[Peter Jakacki]

: THX ." Thanks Peter" ;

That's the way even if the screen capture looks a little cropped (no directory etc). Just in case you are looking for some files I have made the SDCARD folder in the Tachyon Dropbox folder with those test files that I use.

[D.P]

Waiting for Ethernet to come up  ... ready! 

************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.CD.20.FD.7F.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   
3: MODE= TCP    PORT#00081 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   

* WEB, FTP, and TELNET servers running * 
----------------------------------------------------------------
Mounted SD Card 
Media mounted as 9262.AD21 MSDOS5.0 NO NAME     FAT32    Cluster size = 32,768   8
CONNECT   SOCKET #3 2000/00/00 00:AA:48
************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.CD.20.FD.7F.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   
3: MODE= TCP    PORT#00081 49267  TXRW=C50F.C50F.RXRW=0000.0134.RXSZ=0134.IR=04  .

GET REQUEST for /
HTTP/1.1
Host: 192.168.16.150:81
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

: THX ." Thanks Peter" ;

[Peter Jakacki]

I, too, am running the QS/WizNet combo. I have the SD and WN pins done and am hunting down a data sheet for the TI RTC chip and will adapt your 79410 code to it.

I update my copies of this code several times a day. For the last 36 hours the MOUNT word generates a reboot, I can do a !SD and then SD's and read card info, but any of the fuel system commands generate a reboot. The EXTEND, SDCARD and MULTIFILE codes go in "as-is" and hardware config is correct as evidenced by corrrect functioning of !SD and SD.

Any ideas?

Hi Brian, good to see you are getting stuck into it, as you do. I have done all the testing on SDHC cards, usually anything 4GB or more so don't use 2GBs, they are getting pretty hard to get anyway. The RTC words are taken care of by by the virtual RTC in EXTEND.fth so you don't have to worry about that yet. Doesn't the QS have a Seiko RTC? I have a Spinneret that I can check the Seiko chip if need be. Did you use the QuickStart header file I've done up? I will comment out the RTC code until it's ready.

[D.P]

I've already started a header file for this on Google docs and this is the web document version here. Ideally the code should be compiled on the same board. Are you able to handle that Bob?

BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll

To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.

Everything loads above except for NETWORK.fth, last symbol output is LED! around line 525? This is on the QuickStart with W5200 "Cowling" instead of a shield I guess for the Prop

UPDATE: LED! is not defined, investigating
UPDATE: LED! should be LED1 as defined in the header. error line 663 in Network.fth, I'm getting the hang of this FORTH stuff.

[Brian Riley]

I, too, am running the QS/WizNet combo. I have the SD and WN pins done and am hunting down a data sheet for the TI RTC chip and will adapt your 79410 code to it.

I update my copies of this code several times a day. For the last 36 hours the MOUNT word generates a reboot, I can do a !SD and then SD's and read card info, but any of the fuel system commands generate a reboot. The EXTEND, SDCARD and MULTIFILE codes go in "as-is" and hardware config is correct as evidenced by corrrect functioning of !SD and SD.

Any ideas?

[Peter Jakacki]

I have a BOE with an Wiznet WIZ820IO W5200 module on wired like this.

\( HARDWARE DEFINITIONS )
IFNDEF &WNCS
#P2     |< == &WNDO            '' MISO from WIZNET
#P5     |< == &WNCS            '' WIZNET CS
#P4     |< == &WNCK
#P3     |< == &WNDI            '' MOSI to WIZNET
}

Be happy to troubleshoot.

Have you tried loading those files and running it? The only extra definitions you may need are for the LEDs and WIZnet reset and power-down. I think if you don't define them that it will still compile as I have some IFNDEFs in there to cover that but you will need the reset.Have a look at the QuickStart header file I'm working on for some clues.I'm probably a bit too caught-up in an application I'm doing to do much else at the moment but that does mean that all the rough edges have to get tidied up soon. This is one of the advantages of using Tachyon as it is used to roll real-world embedded production grade applications and I make everything but the complete custom application available as OSS. I've been using Forth for this for decades and it's buried in products literally right around the world.

--------------------------------------------------------------------

BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll

To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.

[D.P]

Quick question to anyone who's interested in trying this out. What W5200 Prop hardware do you have? I guess it might be the combination of the QuickStart and the W5200 Ethernet board for the QuickStart. I could probably create a hardware header file for this and download a binary to suit but only if someone is going to try this out.

I have a BOE with an Wiznet WIZ820IO W5200 module on wired like this.

\( HARDWARE DEFINITIONS )
IFNDEF &WNCS
#P2     |< == &WNDO            '' MISO from WIZNET
#P5     |< == &WNCS            '' WIZNET CS
#P4     |< == &WNCK
#P3     |< == &WNDI            '' MOSI to WIZNET
}

Be happy to troubleshoot.

Need to read the whole post, I also have a quickstart, rebuilding the world now.

[Peter Jakacki]

Here's the current startup screen at power-up for these modules set to autorun and also showing when a webpage is accessed:

  Propeller .:.:--TACHYON--:.:. Forth V23131204.0300

NAMES:  $540A...73B4 for 8106
CODE:   $0000...510E for 12644 (0004 bytes added)
CALLS:  0140 vectors free
RAM:    0764 bytes free

AUTORUN GO
MODULES LOADED: 
4819: NETWORK.fth         WIZNET NETWORK SERVERS 131023.1500 
4196: W5200.fth           WIZNET W5200 driver 131107.0000 
3940: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131111-0000 
3202: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2FBF: CE1372.fth          CE1372 HARDWARE DEFINITIONS 131109.2340 
17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

*** Tachyon Forth Network and File Server *** 

Mounted SD Card 
Media mounted as E2C4.0203 mkdosfs PBJTECH-SDL FAT32    Cluster size = 4,096   Sectors = 7,744,512
Listing directory       PBJTECH-SDL

HOME    .HTM     FAVICON .ICO     TACHYON .JPG     HTTP404 .HTM     LOGON   .        LOGON   .TXT     SYSLOG  .TXT     NETWORK .FTH  
W5200   .FTH     EXTEND  .FTH     SDCARD  .FTH     MULTIFAT.FTH     ROM     .BIN     CE1372  .FTH     TACHYON .LST     LOG0008 .TXT  
LOG0007 .TXT     LOG0006 .TXT     LOG0005 .TXT     LOG0004 .TXT     LOG0003 .TXT     LOG0002 .TXT     LOG0001 .TXT     

Waiting for Ethernet to come up  ... ready! 

************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.03.52.40.72.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
3: MODE= TCP    PORT#00081 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 

* WEB, FTP, and TELNET servers running * 
----------------------------------------------------------------

CONNECT   SOCKET #3 2013/12/04 13:41:29
************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.03.52.40.72.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
3: MODE= TCP    PORT#00081 44699  TXRW=B852.B852.RXRW=0000.0132.RXSZ=0132.IR=04  STAT=17 ESTABLISHED    000.000.000.000.

GET REQUEST for /favicon.ico
HTTP/1.1
Host: 192.168.16.150:81
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive


CONTENT = image/png
  CLOSING SOCKET #3 2013/12/04 13:41:37

[TrapperBob]

Peter,

Yes, I can. I will continue you this in the morning after I get some sleep!

Thanks
Bob

[Peter Jakacki]

Hi Peter,

I do have the QuickStart with the W5200 Ethernet board for the QuickStart. It would be great if you created a header for this combo!

Thanks

I've already started a header file for this on Google docs and this is the web document version here. Ideally the code should be compiled on the same board. Are you able to handle that Bob?

BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll

To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.

[TrapperBob]

Hi Peter,

I do have the QuickStart with the W5200 Ethernet board for the QuickStart. It would be great if you created a header for this combo!

Thanks

[Peter Jakacki]

Quick question to anyone who's interested in trying this out. What W5200 Prop hardware do you have? I guess it might be the combination of the QuickStart and the W5200 Ethernet board for the QuickStart. I could probably create a hardware header file for this and download a binary to suit but only if someone is going to try this out.

[D.P]

My bad, really bad bad, so bad. I'm so bad that I paste in a new word and have the audacity to allow the server free access to it immediately. That's bad.


Try these files on the Tachyon IP 58.174.90.227:81
http://58.174.90.227:81/
http://58.174.90.227:81/tachyon.jpg
http://58.174.90.227:81/logon
http://58.174.90.227:81/favicon.ico
http://58.174.90.227:81/EXTEND.FTH
http://58.174.90.227:81/TACHYON.LST

There seems to be some bug with the jpg but I will look at that some other time.

If you Telnet in you can type DIR or ls or .LIST to have a look at what files are there. Of course you can also setup FileZilla but I have a little "WIZnet" bug in my block send routine which FTP uses rather than the inefficient XTYPE routine which I am using with HTTP GET at present. BLKSEND is very fast but I broke it and it's 4:30 in the morning so it might have to wait until the morning......hmmmm.....maybe later than that.

This efficiency could have all been avoided if you would have just got yourself a real Computer Science Degree you know.

[Peter Jakacki]

STOP RIGHT NOW, I want that system taken offline, I want you to compile, link and download right now like the rest of us and then see if your small little fix or large change works, then you can put it back online until the next time you have to dis-appoint your clients. How dare you work on live systems, what are you some kind of production engineer with real clients doing real work?

Really nice Peter, really!

My bad, really bad bad, so bad. I'm so bad that I paste in a new word and have the audacity to allow the server free access to it immediately. That's bad.


Try these files on the Tachyon IP 58.174.90.227:81
http://58.174.90.227:81/
http://58.174.90.227:81/tachyon.jpg
http://58.174.90.227:81/logon
http://58.174.90.227:81/favicon.ico
http://58.174.90.227:81/EXTEND.FTH
http://58.174.90.227:81/TACHYON.LST

There seems to be some bug with the jpg but I will look at that some other time.

If you Telnet in you can type DIR or ls or .LIST to have a look at what files are there. Of course you can also setup FileZilla but I have a little "WIZnet" bug in my block send routine which FTP uses rather than the inefficient XTYPE routine which I am using with HTTP GET at present. BLKSEND is very fast but I broke it and it's 4:30 in the morning so it might have to wait until the morning......hmmmm.....maybe later than that.

[D.P]

I've just come back in to do some more work that I was in the middle of before so my apologies to anyone that tried to log on as it is a bit flakey while I am in the middle of some tests and changes. I am mainly just working on serving up content and making sure the server response headers are correct for HTTP. But that said you are welcome to try to log on to any of the services while bearing in mind that it might not work properly, or it might. There's nothing like performing surgery on an athlete while they are still doing all their Olympic warm-ups!

STOP RIGHT NOW, I want that system taken offline, I want you to compile, link and download right now like the rest of us and then see if your small little fix or large change works, then you can put it back online until the next time you have to dis-appoint your clients. How dare you work on live systems, what are you some kind of production engineer with real clients doing real work?

Really nice Peter, really!

[Peter Jakacki]

I've just come back in to do some more work that I was in the middle of before so my apologies to anyone that tried to log on as it is a bit flakey while I am in the middle of some tests and changes. I am mainly just working on serving up content and making sure the server response headers are correct for HTTP. But that said you are welcome to try to log on to any of the services while bearing in mind that it might not work properly, or it might. There's nothing like performing surgery on an athlete while they are still doing all their Olympic warm-ups!

[Peter Jakacki]

Hi Peter,

I guess the trick is to save my words in a txt file then :-)

I'll give teraterm a try, any recommendations for important settings?

Yes, 230400 baud 8N1, no handshake, no character delay, and 20ms line delay. You can also grab my teraterm.ini file from Dropbox and place it in the teraterm directory.
If you use a text editor then please don't use the rubbish that comes with Windows. ConText is an older editor but very capable and I have a highlighter file for Forth (forth.chl) in Dropbox although the highlighter could probably be brought up-to-date, it's still useful.

[Akkarin]

I recommend Teraterm (SourceForge version) for Windows, it's the best terminal emulator and you have full control over all the settings.
If you load the Tachyon kernel for the first time then it takes less than a minute to paste in EXTEND.fth plus any other words you have created, there is no real need for a binary save really unless you want to generate an image for production or field upgrades.

Hi Peter,

I guess the trick is to save my words in a txt file then :-)

I'll give teraterm a try, any recommendations for important settings?

[Peter Jakacki]

Excellent!

Very nicely done. I think it says all anybody needs to know about FORTH.

Thanks "spud", though it's funny working on it while users log in and out. Sometimes that's right when I've just pasted a new definition in while it's running and sometimes it does what it's supposed to too, not always. Right at the moment I'm checking out content headers so I can send binary such favicon.ico etc. There's a little bug somewhere that's inserting a couple of extra spaces before the transmission which I think is probably from the Forth console before it switches to quiet mode.

Ah yes, this miserable Forth is not good for anything, I should have listened to the Cperts

[potatohead]

Excellent!

Very nicely done. I think it says all anybody needs to know about FORTH.

[Peter Jakacki]

i HAD MY "GO" and itt was impressive .

OBTW ... where is the FSEND Command ? Or is it still in the nursery?

So you are on Telnet and if it's a text file you can just type the Linux command "cat" as in " cat EXTEND.FTH"
If you really want an FSEND command and you want to be verbose then type this (it should work):

pub FSEND
GETWORD FOPEN$ IF FILE@ FSIZE@ XTYPE ELSE ." What file!!!" CR CR THEN ;
IMMEDIATE

Then "FSEND EXTEND.FTH"

Your session report (I masked out part of the IP)
************ W5200 STATUS ************
LINK *UP*
CHIP VER 0003
SRC IP 192.168.016.150.
MASK 255.255.255.000.
GATEWAY 192.168.016.001.
MAC 00.08.03.52.40.72.
*** SOCKETS ***
0: MODE= TCP PORT#00023 51712 TXRW=B6AF.B6AF.RXRW=0000.001B.RXSZ=001B.IR=05 STAT=17 ESTABLISHED 071.169.***.***.
1: MODE= TCP PORT#00021 00000 TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00 STAT=14 LISTEN
3: MODE= TCP PORT#00081 58708 TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00 STAT=14 LISTEN

CONNECT SOCKET #0 2013/12/03 11:33:25
CLOSING SOCKET #0 2013/12/03 11:33:53

[Brian Riley]

That prompted me to take a look at implementing HTTP the ...
If you noticed the WAN IP and port you are welcome to have a go, it's just a simple dialog at the moment but TELNET (console to Forth) and FTP (try FileZilla) are working on the normal ports although I have to fix FTP again after making some "improvements"
If I add file uploading to the FTP server then I can upload new webpages to the Prop rather than having to remove the card.

i HAD MY "GO" and itt was impressive .

achilles:~ brianbr$ telnet 58.174.90.227
Trying 58.174.90.227...
Connected to cpe-58-174-90-227.sicz1.cha.bigpond.net.au.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!
.LIST
 	PBJTECH-SDL
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0008.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0007.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0006.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0005.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0004.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0003.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0002.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0001.TXT
-rwxrwxrwx    1 502      500 1048576 Dec  3  2013 SYSLOG.TXT
-rwxrwxrwx    1 502      500   12343 Dec  3  2013 NETWORK.FTH
-rwxrwxrwx    1 502      500   11771 Dec  3  2013 W5200.FTH
-rwxrwxrwx    1 502      500   81674 Dec  3  2013 EXTEND.FTH
-rwxrwxrwx    1 502      500   16766 Dec  3  2013 SDCARD.FTH
-rwxrwxrwx    1 502      500   21466 Dec  3  2013 MULTIFAT.FTH
-rwxrwxrwx    1 502      500    3332 Nov 26  2013 CE1372.FTH
-rwxrwxrwx    1 502      500  279651 Nov 22  2013 TACHYON.LST
-rwxrwxrwx    1 502      500   32768 Nov 27  2013 ROM.BIN
-rwxrwxrwx    1 502      500     388 Dec  3  2013 HTTP001.TXT
-rwxrwxrwx    1 502      500     388 Dec  3  2013 HTTP001.HTM
-rwxrwxrwx    1 502      500     564 Dec  3  2013 HTTP404.HTM
-rwxrwxrwx    1 502      500   21603 Dec  3  2013 TACHYON.JPG
 ok

  ok
^]
telnet> q
Connection closed.
achilles:~ brianbr$ 
achilles:~ brianbr$ telnet 58.174.90.227
Trying 58.174.90.227...
Connected to cpe-58-174-90-227.sicz1.cha.bigpond.net.au.
Escape character is '^]'.
WELCOME TO THE TACHYON WIZNET TELNET SESSION!
.LIST
 	PBJTECH-SDL
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0008.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0007.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0006.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0005.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0004.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0003.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0002.TXT
-rwxrwxrwx    1 502      500  131072 Nov  4  2013 LOG0001.TXT
-rwxrwxrwx    1 502      500 1048576 Dec  3  2013 SYSLOG.TXT
-rwxrwxrwx    1 502      500   12343 Dec  3  2013 NETWORK.FTH
-rwxrwxrwx    1 502      500   11771 Dec  3  2013 W5200.FTH
-rwxrwxrwx    1 502      500   81674 Dec  3  2013 EXTEND.FTH
-rwxrwxrwx    1 502      500   16766 Dec  3  2013 SDCARD.FTH
-rwxrwxrwx    1 502      500   21466 Dec  3  2013 MULTIFAT.FTH
-rwxrwxrwx    1 502      500    3332 Nov 26  2013 CE1372.FTH
-rwxrwxrwx    1 502      500  279651 Nov 22  2013 TACHYON.LST
-rwxrwxrwx    1 502      500   32768 Nov 27  2013 ROM.BIN
-rwxrwxrwx    1 502      500     388 Dec  3  2013 HTTP001.TXT
-rwxrwxrwx    1 502      500     388 Dec  3  2013 HTTP001.HTM
-rwxrwxrwx    1 502      500     564 Dec  3  2013 HTTP404.HTM
-rwxrwxrwx    1 502      500   21603 Dec  3  2013 TACHYON.JPG
 ok

  ok
^]
telnet> q
Connection closed.
achilles:~ brianbr$

OBTW ... where is the FSEND Command ? Or is it still in the nursery?

[Peter Jakacki]

Really cool and fast FYI.

TACHYON
( EXTEND.fth )

pub EXTEND.fth ." Primary extensions to TACHYON kernel - 131124-0000 " ;

( link to the latest Tachyon kernel web document )

{
CONTENTSî¿¿

Yes, and it's all running from the one cog, Forth, SD, Network, the lot! Wait until I delegate some cogs to handle that!

FYI, this is my console output when you connected:

************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.03.52.40.72.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
3: MODE= TCP    PORT#00081 58687  TXRW=37E9.37E9.RXRW=0000.013D.RXSZ=013D.IR=05  STAT=17 ESTABLISHED    000.000.000.000.

CONNECT   SOCKET #3 2013/12/03 11:20:23
GET REQUEST for /EXTEND.FTH
HTTP/1.1
Host: 58.174.90.227:81
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive


  CLOSING SOCKET #3 2013/12/03 11:20:38
************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.03.52.40.72.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
3: MODE= TCP    PORT#00081 58688  TXRW=65CE.65CE.RXRW=0000.0120.RXSZ=0120.IR=05  STAT=17 ESTABLISHED    000.000.000.000.

CONNECT   SOCKET #3 2013/12/03 11:20:39
GET REQUEST for /favicon.ico
HTTP/1.1
Host: 58.174.90.227:81
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive


  CLOSING SOCKET #3 2013/12/03 11:20:39
************ W5200 STATUS ************ 
LINK *UP*
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.03.52.40.72.
*** SOCKETS *** 
0: MODE= TCP    PORT#00023 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
1: MODE= TCP    PORT#00021 00000  TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00  STAT=14 LISTEN 
3: MODE= TCP    PORT#00081 58692  TXRW=8FFA.8FFA.RXRW=0000.0000.RXSZ=0000.IR=01  STAT=17 ESTABLISHED    000.000.000.000.

CONNECT   SOCKET #3 2013/12/03 11:20:40
  CLOSING SOCKET #3 2013/12/03 11:20:45

[D.P]

You can try it anytime, I'm just in the process of building some basic webpages and graphics but if you know the name of one of the files on the SD card then you can request that. So at the moment there is the log on page which is just a dummy test and there is also the 404 not found page.

URL: 58.174.90.227:81

Try:
58.174.90.227:81/EXTEND.FTH
etc

As soon as I test out a home page I will set that up as the default.


If you happen to telnet into the Prop instead you can talk to it in TF, remember that most action words are all capitals.
DIR
WORDS
W
cat W5200.FTH
<etc>

Really cool and fast FYI.

TACHYON
( EXTEND.fth )

pub EXTEND.fth ." Primary extensions to TACHYON kernel - 131124-0000 " ;

( link to the latest Tachyon kernel web document )

{
CONTENTSî¿¿

[Peter Jakacki]

Can't wait to try this later: FORTH of all things

You can try it anytime, I'm just in the process of building some basic webpages and graphics but if you know the name of one of the files on the SD card then you can request that. So at the moment there is the log on page which is just a dummy test and there is also the 404 not found page.

URL: 58.174.90.227:81

Try:
58.174.90.227:81/EXTEND.FTH
etc

As soon as I test out a home page I will set that up as the default.

If you happen to telnet into the Prop instead you can talk to it in TF, remember that most action words are all capitals.
DIR
WORDS
W
cat W5200.FTH
<etc>

[D.P]

That prompted me to take a look at implementing HTTP then. Developing code for this is real easy as I can type in a new directive such as GET and it executes automatically when a browser tries to connect:

Here's a request packet that's been echoed to the console (Including the GET notification):

GET REQUEST 
/ HTTP/1.1
Host: 58.174.90.227:81
User-Agent: Mozilla/5.0 (Android; Mobile; rv:25.0) Gecko/25.0 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

The GET is interpreted by the Forth console and executes this word I typed in which looks up the webpage HTTP001.HTM to serve up from the SD card, in this case a simple security dialog:

pub GET
    CON CR REVERSE ." GET REQUEST " PLAIN        \ Let me know about a request
    CR BEGIN LAN KEY CON DUP EMIT 0= UNTIL        \ Just echo the request to the console for now
    LAN " HTTP001.HTM" FOPEN$ IF FILE@ XADR PRINT$ THEN    \ Access the webpage from the SD card and send it
   ;
IMMEDIATE

If you noticed the WAN IP and port you are welcome to have a go, it's just a simple dialog at the moment but TELNET (console to Forth) and FTP (try FileZilla) are working on the normal ports although I have to fix FTP again after making some "improvements"
If I add file uploading to the FTP server then I can upload new webpages to the Prop rather than having to remove the card.

Can't wait to try this later: FORTH of all things

[Peter Jakacki]

Yeah, those things are everywhere. Put a server up, and it often only takes minutes for the door knocking to start.

Another great fun is to accept the connection, then send them a few megabytes in response... Random numbers are a great choice. So they make the request, you answer it, take the username they give, and then just start spraying line noise their way instead of a password prompt. Often they go away for a while.

That prompted me to take a look at implementing HTTP then. Developing code for this is real easy as I can type in a new directive such as GET and it executes automatically when a browser tries to connect:

Here's a request packet that's been echoed to the console (Including the GET notification):

GET REQUEST 
/ HTTP/1.1
Host: 58.174.90.227:81
User-Agent: Mozilla/5.0 (Android; Mobile; rv:25.0) Gecko/25.0 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

The GET is interpreted by the Forth console and executes this word I typed in which looks up the webpage HTTP001.HTM to serve up from the SD card, in this case a simple security dialog:

pub GET
    CON CR REVERSE ." GET REQUEST " PLAIN        \ Let me know about a request
    CR BEGIN LAN KEY CON DUP EMIT 0= UNTIL        \ Just echo the request to the console for now
    LAN " HTTP001.HTM" FOPEN$ IF FILE@ XADR PRINT$ THEN    \ Access the webpage from the SD card and send it
   ;
IMMEDIATE

If you noticed the WAN IP and port you are welcome to have a go, it's just a simple dialog at the moment but TELNET (console to Forth) and FTP (try FileZilla) are working on the normal ports although I have to fix FTP again after making some "improvements"
If I add file uploading to the FTP server then I can upload new webpages to the Prop rather than having to remove the card.

[potatohead]

Yeah, those things are everywhere. Put a server up, and it often only takes minutes for the door knocking to start.

Another great fun is to accept the connection, then send them a few megabytes in response... Random numbers are a great choice. So they make the request, you answer it, take the username they give, and then just start spraying line noise their way instead of a password prompt. Often they go away for a while.

[Peter Jakacki]

I walked back into the workshop after midnight and noticed some activity on my Tachyon network server. My server reports back to the console if it connects via FTP, TELNET or even HTTP which has not been implemented yet.
This is what I saw:

CONNECT   SOCKET #0 2013/12/03 00:13:52
  CLOSING SOCKET #0 2013/12/03 00:13:53
CONNECT   SOCKET #0 2013/12/03 00:23:00
<etc>

Now socket 0 happens to be the TELNET server and I haven't been using that but I do have port forwarding set so that the Prop gets any requests. So I decided to look at the receive buffer for that socket:

$C000 $800 WDUMP 
0000_C000:   72 6F 6F 74  0D 0A 61 64   6D 69 6E 0D  0A F6 BB EF   root..admin.....

It seems some bot was trying to connect on port 23 using generic user and password details blindly, interesting. Maybe I will set it up so that it captures and logs connection information to the SD card. I'd like to see them hack a Prop running Tachyon Forth!!!

[Peter Jakacki]

Hi Peter,
thanks for the hex2bin, but it doesn't run on 64-bit Windows.
I copied the Dump via C&P from PuTTy screen and then deleted empty lines with NotePad++. With empty lines I mean that PuTTy puts out CR LF every second line. So, every line ends with CR LF and every second line is empty, meaning only CR LF.
The reason I'd like to save the image is, that I want to try PropForth as well and don't want to lose my new words.
Currently I don't have an SD card hooked up.

I recommend Teraterm (SourceForge version) for Windows, it's the best terminal emulator and you have full control over all the settings.
If you load the Tachyon kernel for the first time then it takes less than a minute to paste in EXTEND.fth plus any other words you have created, there is no real need for a binary save really unless you want to generate an image for production or field upgrades.

[Akkarin]

Hi Peter,
thanks for the hex2bin, but it doesn't run on 64-bit Windows.
I copied the Dump via C&P from PuTTy screen and then deleted empty lines with NotePad++. With empty lines I mean that PuTTy puts out CR LF every second line. So, every line ends with CR LF and every second line is empty, meaning only CR LF.
The reason I'd like to save the image is, that I want to try PropForth as well and don't want to lose my new words.
Currently I don't have an SD card hooked up.

[Peter Jakacki]

Hi,

I'm totally new to Forth and Tachyon. I played a little and made a BINARYDUMP. How do I get this image programmed into EEPROM? I tried hex2bin, but it fails. Can I load the hex image with BST? Ah, btw. Win8.

Attachment 105345Attachment 105346Attachment 105347

Hi Akkarin, I've copied my hex2bin.exe that I use into the Tachyon Dropbox folder so try that perhaps. After which you just rename it to .binary for the Prop tool. If it still has errors then it may have to do with your capture perhaps, are you copying from the screen buffer or straight to a file? Is there a particular reason you need a binary this early in your evaluation?

There's also another way of generating a binary now and that's via the SD card with SAVEROM if that's an option.

[Akkarin]

Hi,

I'm totally new to Forth and Tachyon. I played a little and made a BINARYDUMP. How do I get this image programmed into EEPROM? I tried hex2bin, but it fails. Can I load the hex image with BST? Ah, btw. Win8.

[Peter Jakacki]

Been tinkering under the hood a bit and moved some stuff from the kernel into EXTEND as those definitions are not used by the kernel and better coded and maintained in EXTEND. The reason for this is that I am whittling the kernel down so it's easier to get around while most of the high-level definitions are in EXTEND.

A new RECLAIM command has been added which removes all "private" headers from the dictionary and reclaims that memory, that includes those created with "pri" and those with the tag PRIVATE

RECLAIM 
Removing .VECTORS
Removing .RUNTIME
Removing .CLKFREQ
<etc>
Removing @ATR
Removing LEMIT
Reclaimed 382 bytes  ok

WORDS has also been enhanced and can now filter results not just on a character or leading string but also on it's attribute field.

So besides:

ANY * WORDS 
NFA  PFA  EXT ATRS NAME 
----------------------- 
6B53 003E     ..    code 2*
6BE3 00F7     ..    code UM*
6FDC 0000     ..    codx *
73EE 185E     ..    codx *end*   ok

MATCH PIN WORDS 
NFA  PFA  EXT ATRS NAME 
----------------------- 
62A5 24FD YBE ..    pub  PINS
62AD 24CB XBE ..    pub  PINLOAD?
6938 18FB Y1B ..    pub  PINS@
694B 18F5 Y19 ..    pub  PINCLR
6974 18E5 Y14 ..    pub  PIN!    ok

We can also:

LIKE IF WORDS 
NFA  PFA  EXT ATRS NAME 
----------------------- 
5E9F 2FB4 YF6 .imm  pub  FORGET
631B 2264 XB8 .imm  pub  LIKE
6355 2149 YB4 .imm  pub  ANY
6363 2129 YB3 .imm  pub  MATCH
644E 1FB2 YA7 .imm  pub  STRING
67AF 1A88 Y4E .imm  pub  ==
67B5 1A7C Y4D .imm  pub  DS

HELP comments will also find a place in the top 32K of a 64K EEPROM. To make that work for words defined in the kernel and earlier in EXTEND I am allowing the comments to be compiled inline with the headers. Yikes!, that'll take a lot of the hub RAM but only up to the point that the EEPROM words become active and the help comments can be shunted up to EEPROM with MAKEHELP where WORDS and HELP will draw comments from. If you are typing in interactive mode then I may include a hint mode which will list the stack comment with a ^? and further comments with further ^? (control ? = $1F)

At present there are about 14 PASM longs taken up by the instruction CMPSTR which is mostly only used during compile. I want to free up that space for some more useful tricks in PASM so this instruction will be moved to bytecode which is slower but when the load control word TACHYON is executed then CMPSTR will vector to PASM CMPSTR loaded as a RUNMOD instruction.

The other compile-time/runtime optimization I am looking at is the console receiver cog in that I want it as a multi-channel serial port when it's not dedicated to high-speed serial receive during source-code compile. That way I can have COM1 COM2 COM3 COM4 I/O redirection without necessarily requiring another cog, although that's optional.

Also let me know if there is any sample code you might need for such things like the file system etc. The best sample code is actually to have a solution to a real requirement, so let me know.

[D.P]

Hi Brian,

There is an FSEND word that you can use to set the output to write sequentially into a file. Normally when a file is opened a write pointer is set to append to the file and FSEND takes the emit characters and does a simple append character by character. So bear in mind that the way I have decided to setup the file system may be at odds to traditional thinking, but it makes way more sense to me to treat the card like virtual memory and also to "preformat" the card with blanks files that are more than large enough that they never need to have extra clusters added or file size entries update continually. This takes away a lot of the problems associated with file systems and SD cards for embedded use vs PC HDDs or even camera SD file access. I will explain a bit more about this in the MULTIFAT document itself.

" MYFILE.TXT" FOPEN$ FSEND <do your voodoo> CON FCLOSE

Please note that the FSEND word is still a WIP and I will include a lot more features with it, at the moment there is only one FSEND pointer rather than one for each file and it resets to the start of the file when it's opened. I'm just looking at a way that I can avoid writing a file pointer to the card continually which is not a good thing for Flash. I do have my own methods for finding the end of a file which does not involve writing any pointer to Flash, would you be interested in a method I use?

BTW, the Dropbox links are not always the most up-to-date although I do try to update them often. If you go to the links page (via the Intro page) you will find a new entry called "suggested build" which has an entry for all the links to web document pages that I would use in a build. These are the same links
I mentioned in post #933.

Yes some documentation and a simple example (or did I miss this) would help right now. I've gotten this far but can see EXTEND.FTH on the FAT32 formated 2 GIG drive?

SD 
Card inserted 
MFG                 03
OEM                 SD
PID                 SU08G
REV                 80
S/N                 9262.AD21
DATE                2013/10
CRC                 28
  CSD REGISTER      
*SDHC CARD* 
TACC                100ns
NSAC                0bps
TRANS               50MHz
BLKLEN              512
SIZE                7,579MB
________________________________
 ok
ls      NO NAME    
LOG0008 .TXT     ROM     .BIN     SYSLOG  .TXT     
LOG0001 .TXT     LOG0002 .TXT     LOG0003 .TXT     LOG0004 .TXT     LOG0005 .TXk
DIR     NO NAME    

LOG0008 .TXT .....a 0000.4040    29/11/2013 00:11:00   131,072
ROM     .BIN .....a 0000.4140    29/11/2013 00:12:54   32,768
SYSLOG  .TXT .....a 0000.4180    29/11/2013 00:12:24   1,048,562
LOG0001 .TXT .....a 0000.4980    29/11/2013 00:11:36   131,072
LOG0002 .TXT .....a 0000.4A80    29/11/2013 00:11:32   131,072
LOG0003 .TXT .....a 0000.4B80    29/11/2013 00:11:26   131,072
LOG0004 .TXT .....a 0000.4C80    29/11/2013 00:11:22   131,072
LOG0005 .TXT .....a 0000.4D80    29/11/2013 00:11:16   131,072
LOG0006 .TXT .....a 0000.4E80    29/11/2013 00:11:12   131,072
LOG0007 .TXT .....a 0000.4F80    29/11/2013 00:11:06   131,072 ok

Well RTFM/Code helped alot, very nice Peter.

[Peter Jakacki]

I am OK now. I spent a good part of the last 36 hours trying various combinations of baud rates, line delays, boards, compilers ... etc.

IN the end I not only got it loaded but it was done at 230400 baud w/21ms line delay ..... up from 115200 baud and 60 ms.

Peter ... have you some sample code for redirecting output of .NUM to write to SD?

Hi Brian,

There is an FSEND word that you can use to set the output to write sequentially into a file. Normally when a file is opened a write pointer is set to append to the file and FSEND takes the emit characters and does a simple append character by character. So bear in mind that the way I have decided to setup the file system may be at odds to traditional thinking, but it makes way more sense to me to treat the card like virtual memory and also to "preformat" the card with blanks files that are more than large enough that they never need to have extra clusters added or file size entries update continually. This takes away a lot of the problems associated with file systems and SD cards for embedded use vs PC HDDs or even camera SD file access. I will explain a bit more about this in the MULTIFAT document itself.

" MYFILE.TXT" FOPEN$ FSEND <do your voodoo> CON FCLOSE

Please note that the FSEND word is still a WIP and I will include a lot more features with it, at the moment there is only one FSEND pointer rather than one for each file and it resets to the start of the file when it's opened. I'm just looking at a way that I can avoid writing a file pointer to the card continually which is not a good thing for Flash. I do have my own methods for finding the end of a file which does not involve writing any pointer to Flash, would you be interested in a method I use?

BTW, the Dropbox links are not always the most up-to-date although I do try to update them often. If you go to the links page (via the Intro page) you will find a new entry called "suggested build" which has an entry for all the links to web document pages that I would use in a build. These are the same links
I mentioned in post #933.

[MJB]

Hi Brian,

Peter ... have you some sample code for redirecting output of .NUM to write to SD?

redirecting EMIT to the SD write routine should do the job, after the SD card is prepared, LOADMOD etc...

 ' SD! uemit W! 
\ then do normal .NUM or what ever output you desire
0 uemit W!  \ or   uemit W~  will set it back
CON   \ should set it back too

\ maybe you need to do s.th. in the end to clean up, close the file or whatever you do normally
\ - I have never used SD before - yet ...

maybe you can post a snipped you use to initialize, write and close ... thanks

[Brian Riley]

I am OK now. I spent a good part of the last 36 hours trying various combinations of baud rates, line delays, boards, compilers ... etc.

IN the end I not only got it loaded but it was done at 230400 baud w/21ms line delay ..... up from 115200 baud and 60 ms.

Peter ... have you some sample code for redirecting output of .NUM to write to SD?

----------------------------------------------------------------
REBOOT 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300

NAMES:  $5633...7309 for 7382 (0744 bytes added)
CODE:   $0000...402F for 9049 (2025 bytes added)
CALLS:  0334 vectors free
RAM:    5636 bytes free

AUTORUN BOOT
MODULES LOADED: 
3846: MULTIFAT.fth        FAT32/16 MultiFile Layer V1.1 131111-0000 
30D7: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2F21: EXT_BBR.fth         BBR I/O re-dir & Extensions   - 20130728.0000
1900: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

----------------------------------------------------------------

I am OK now. I spent a good part of the last 36 hours trying various combinations of baud rates, line delays, boards, compilers ... etc.

IN the end I not only got it loaded but it was done at 230400 baud w/21ms line delay ..... up from 115200 baud and 60 ms.

Peter ... have you some sample code for redirecting output of .NUM to write to SD?

----------------------------------------------------------------
REBOOT 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300

NAMES:  $5633...7309 for 7382 (0744 bytes added)
CODE:   $0000...402F for 9049 (2025 bytes added)
CALLS:  0334 vectors free
RAM:    5636 bytes free

AUTORUN BOOT
MODULES LOADED: 
3846: MULTIFAT.fth        FAT32/16 MultiFile Layer V1.1 131111-0000 
30D7: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2F21: EXT_BBR.fth         BBR I/O re-dir & Extensions   - 20130728.0000
1900: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

----------------------------------------------------------------

I am OK now. I spent a good part of the last 36 hours trying various combinations of baud rates, line delays, boards, compilers ... etc.

IN the end I not only got it loaded but it was done at 230400 baud w/21ms line delay ..... up from 115200 baud and 60 ms.

Peter ... have you some sample code for redirecting output of .NUM to write to SD?

----------------------------------------------------------------
REBOOT 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300

NAMES:  $5633...7309 for 7382 (0744 bytes added)
CODE:   $0000...402F for 9049 (2025 bytes added)
CALLS:  0334 vectors free
RAM:    5636 bytes free

AUTORUN BOOT
MODULES LOADED: 
3846: MULTIFAT.fth        FAT32/16 MultiFile Layer V1.1 131111-0000 
30D7: SDCARD.fth          SD CARD Toolkit - 131114.0000 
2F21: EXT_BBR.fth         BBR I/O re-dir & Extensions   - 20130728.0000
1900: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 

----------------------------------------------------------------

[D.P]

I'm assuming you have a new and clean system because the E! was introduced recently. I must report the load errors in a clearer fashion though. As a test I copied the web document and pasted that in without any problems.

FORGET W5200.fth  ok
  ok
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300
 ok
0000  ok
0470  ok          egisters "gisters " ." ******* "07!!"            
0471  ok
0472 

00:00:19  End of source code, 0473 lines processed and 0000 errors found 
Load time = 15,683ms

NAMES:  $5293...7309 for 8310 (0945 bytes added)
CODE:   $0000...46DF for 9833 (1652 bytes added)
CALLS:  0233 vectors free
RAM:    2996 bytes free

EDIT: Just tried the Dropbox version and it works fine too although it only reports half the lines. I know the web document version seems to paste two LFs rather than a CRLF and previously I would ignore LFs altogether but now my system converts LFs to CRs if they are not part of a CRLF, hence the double line thing. BTW, don't use the zip files anymore, just the online versions, Dropbox seems to be working fine now.

Arrg, the last zip that was posted didn't have E!, verions mismatch, all better, thx Peter

!WIZIO  ok
!WIZIP  ok
WIZ? 
************ W5200 STATUS ************ 
LINK DOWN
CHIP VER  0003
SRC IP    192.168.016.150.
MASK      255.255.255.000.
GATEWAY   192.168.016.001.
MAC       00.08.83.68.0D.76.
*** SOCKETS *** 
0: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
1: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
2: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
3: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
4: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
5: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
6: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
7: MODE= CLOSED PORT#0000 0000   TXRW=0000.0000.RXRW=0000.0000.RXSZ=0000.IR=00   STAT=00 CLOSED
 ok

[Peter Jakacki]

That makes "error" sense.

Now it keeps hanging at line 217.

MODULES LOADED: 
3624: MULTIFAT.fth        FAT32/16 MultiFile Layer V1.1 131111-0000 
2ECD: SDCARD.fth          SD CARD Toolkit - 131114.0000 
18C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 
----------------------------------------------------------------
( W5200.fth )  ok
  ok
FORGET W5200.fth Not found   ok
  ok
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300
 ok
0000  ok
0217    addr -- )                    E!

I'm assuming you have a new and clean system because the E! was introduced recently. I must report the load errors in a clearer fashion though. As a test I copied the web document and pasted that in without any problems.

FORGET W5200.fth  ok
  ok
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300
 ok
0000  ok
0470  ok          egisters "gisters " ." ******* "07!!"            
0471  ok
0472 

00:00:19  End of source code, 0473 lines processed and 0000 errors found 
Load time = 15,683ms

NAMES:  $5293...7309 for 8310 (0945 bytes added)
CODE:   $0000...46DF for 9833 (1652 bytes added)
CALLS:  0233 vectors free
RAM:    2996 bytes free

EDIT: Just tried the Dropbox version and it works fine too although it only reports half the lines. I know the web document version seems to paste two LFs rather than a CRLF and previously I would ignore LFs altogether but now my system converts LFs to CRs if they are not part of a CRLF, hence the double line thing. BTW, don't use the zip files anymore, just the online versions, Dropbox seems to be working fine now.

[MJB]

... so that you could type HELP .NUM for instance and it will display MJB plans mainly to have this info extracted in hardcopy form, whereas I like to have it at my fingertips.

I like 'at my fingertips' too but my screens are too small ;-)

well - new to Google-Docs I discovered the scripts (which is kind of JavaScript) - was happy -
and wondered if I could write a converter to strip the stuff of (e.g. the code itself) that I do not want in my overview document.
Well - it would have been only a few lines of code - if Google had not decided to implement only a subset of REGEXP in it's
JavaScript version - how stupid.
If I find a good solution I let you know.

[D.P]

Ah yes, I mentioned somewhere that I use hardware header files which define the pins and also any special functions of which WRESET and WPWRDN are in my system as they are accessed over I2C. But what I will do is include some IFNDEFs in the source to make sure it compiles properly if these have not been defined. I will also put one of my header files in the Tachyon folder for reference. There is also the function !PCB which is hardware specific initialization which is just a dummy word unless a new one is defined.

EDIT: I had updated the W5200.fth code and I notice that I already have a header file in there, the CE1372.fth file.

If you access the web document versions you will find the formatting and diagrams etc in there help.

Web document versions of the various modules are:
Tachyon V2.3
EXTEND.fth
CE1372.fth
SDCARD.fth
MULTIFAT.fth
W5200.fth
NETWORK.fth

That makes "error" sense.

Now it keeps hanging at line 217.

MODULES LOADED: 
3624: MULTIFAT.fth        FAT32/16 MultiFile Layer V1.1 131111-0000 
2ECD: SDCARD.fth          SD CARD Toolkit - 131114.0000 
18C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 
----------------------------------------------------------------
( W5200.fth )  ok
  ok
FORGET W5200.fth Not found   ok
  ok
TACHYON 
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300
 ok
0000  ok
0217    addr -- )                    E!

[Peter Jakacki]

FROM W5200.fth in the zip file (and dropbox) this word (!WIZIO) does not complie? No WRESET, WPWRDN defined anywhere?

\ Init the SPI for the WIZnet chip
pub !WIZIO
    !PCB
    wizpins $00FFFFFF AND SPIPINS
    &WNCS OUTSET                \ Chip select is an output - active low
    &WNCK OUTCLR                \ Clock is an output - leave low
    &WNDI OUTCLR                \ MOSI is an output
    ON WRESET OFF WPWRDN OFF WRESET
;

Ah yes, I mentioned somewhere that I use hardware header files which define the pins and also any special functions of which WRESET and WPWRDN are in my system as they are accessed over I2C. But what I will do is include some IFNDEFs in the source to make sure it compiles properly if these have not been defined. I will also put one of my header files in the Tachyon folder for reference. There is also the function !PCB which is hardware specific initialization which is just a dummy word unless a new one is defined.

EDIT: I had updated the W5200.fth code and I notice that I already have a header file in there, the CE1372.fth file.

If you access the web document versions you will find the formatting and diagrams etc in there help.

Web document versions of the various modules are:
Tachyon V2.3
EXTEND.fth
CE1372.fth
SDCARD.fth
MULTIFAT.fth
W5200.fth
NETWORK.fth

[D.P]

Hi Brian, were you able to resolve what was causing the problem?

BTW, all the current files have been updated in Dropbox.

FROM W5200.fth in the zip file (and dropbox) this word (!WIZIO) does not complie? No WRESET, WPWRDN defined anywhere?

\ Init the SPI for the WIZnet chip
pub !WIZIO
    !PCB
    wizpins $00FFFFFF AND SPIPINS
    &WNCS OUTSET                \ Chip select is an output - active low
    &WNCK OUTCLR                \ Clock is an output - leave low
    &WNDI OUTCLR                \ MOSI is an output
    ON WRESET OFF WPWRDN OFF WRESET
;

[Peter Jakacki]

I have it working now on QS board ... a lot of effort. still need to check The PAB and PropPlat boards.. and I am still not exactly sure what/why it's working.


@D.P. what terminal program ware you using on the Mac?

Hi Brian, were you able to resolve what was causing the problem?

BTW, all the current files have been updated in Dropbox.

[Brian Riley]

I have also confirmed that the zip archive files are okay. QuikStart 230400 Baud pll16x 5MHz no edits at all just copy/paste

Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


NAMES: $5DA9...72F9 for 5456 (2659 bytes added)
CODE: $0000...2ECD for 6525 (5645 bytes added)
CALLS: 0537 vectors free
RAM: 11996 bytes free


AUTORUN BOOT
MODULES LOADED:
18C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000

Seems to be something on your end Brian. Let us know what we can do to help.



----------------------------------------------------------------

I have it working now on QS board ... a lot of effort. still need to check The PAB and PropPlat boards.. and I am still not exactly sure what/why it's working.


@D.P. what terminal program ware you using on the Mac?

[Peter Jakacki]

There have been quite a few improvements to the kernel and extension files but part of this is also an attempt at improving the source code documentation. Many of my driver module source code pages have diagrams and datasheet clippings to help me along as well. MJB has started to tidy up some of the function descriptions that are meant to be included in the target at some point so that you could type HELP .NUM for instance and it will display MJB plans mainly to have this info extracted in hardcopy form, whereas I like to have it at my fingertips.

I have also tidied up EXTEND.fth and added a contents table as well so this is best viewed as a webpage document so no sign in is required.

[TrapperBob]

I have also confirmed that the zip archive files are okay. QuikStart 230400 Baud pll16x 5MHz no edits at all just copy/paste

Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


NAMES: $5DA9...72F9 for 5456 (2659 bytes added)
CODE: $0000...2ECD for 6525 (5645 bytes added)
CALLS: 0537 vectors free
RAM: 11996 bytes free


AUTORUN BOOT
MODULES LOADED:
18C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000

Seems to be something on your end Brian. Let us know what we can do to help.



----------------------------------------------------------------

[D.P]

Using files from the above posted ZipArchive.

V2.3 spin - compiled with pll16x, 5 mHz, 115200 baud

EXTEND.FTH - copy/pasted unchanged except commented out [~ of subsequent runs

produces same problem on Activity Board, Prop Platform, and QuickStart - reads/processes whole copy/paste then hits the "END" directive and starts spewing endless repetitions of the kernel ID as was stated in my message #921 and shown at the bottom of the code section in msg 921

When I get home I'll compile these and post. If they work we gotta figure out what's up on you end Brian, I'll be using a QuickStart board.


UPDATE: Peter's latest as attached above:

QuickStart P8X32A 4000 Rev A
BST 0.19.3 Compiler: 0.15.4.-pre5
Mac OSX 10.8.5
minicom 230400 20ms line delay

Propeller .:.:--TACHYON--:.:. Forth V23131125.0300

NAMES: $5DA9...72F9 for 5456 (2659 bytes added)
CODE: $0000...2ECD for 6525 (5645 bytes added)
CALLS: 0537 vectors free
RAM: 11996 bytes free

AUTORUN BOOT
MODULES LOADED:
18C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000
----------------------------------------------------------------


@Brian it is something on your end. How can we help?

[Brian Riley]

I'm having an issue with Dropbox at the moment on a remote computer which I am accessing directly via Splashtop to see what's going on. I've checked all the Dropbox settings but it seems the files are not being updated. Just in case here is a zip of the latest files

Using files from the above posted ZipArchive.

V2.3 spin - compiled with pll16x, 5 mHz, 115200 baud

EXTEND.FTH - copy/pasted unchanged except commented out [~ of subsequent runs

produces same problem on Activity Board, Prop Platform, and QuickStart - reads/processes whole copy/paste then hits the "END" directive and starts spewing endless repetitions of the kernel ID as was stated in my message #921 and shown at the bottom of the code section in msg 921

[Peter Jakacki]

I am now checking internal version numbers of all files I download from dropbox, I have been burned by the box too many times now. No one's fault it's just the web.

I'm having an issue with Dropbox at the moment on a remote computer which I am accessing directly via Splashtop to see what's going on. I've checked all the Dropbox settings but it seems the files are not being updated. Just in case here is a zip of the latest files

[D.P]

There are two ways to access Dropbox files, download through a web browser or access the Dropbox folder directly. Either way may require a refresh but I set my folder view to always show the most recent and V2.2 is not the most recent either. As a side note all the recent .fth Dropbox files were updated to ensure that they were CRLF line terminated files and that the file names were 8.3 short name friendly (capitals only).

So start with refreshing the folder, setting it show most recent first, and then use the 2.3 kernel, then EXTEND.FTH.

I am now checking internal version numbers of all files I download from dropbox, I have been burned by the box too many times now. No one's fault it's just the web.

[Peter Jakacki]

The exact same problem as I reported in my last message occurs with the v2.2 kernel

  Propeller .:.:--TACHYON--:.:. Forth V22131115.1400
 Cold start - no user code - setting defaults
----------------------------------------------------------------
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V22131115.1400
 ok
0000  ok
0001  ok
0002  okND.fth    ." Primary extensions to TACHYON kernel - 131124-0000 " ;
0003  ok
\

There are two ways to access Dropbox files, download through a web browser or access the Dropbox folder directly. Either way may require a refresh but I set my folder view to always show the most recent and V2.2 is not the most recent either. As a side note all the recent .fth Dropbox files were updated to ensure that they were CRLF line terminated files and that the file names were 8.3 short name friendly (capitals only).

So start with refreshing the folder, setting it show most recent first, and then use the 2.3 kernel, then EXTEND.FTH.

[Brian Riley]

The exact same problem as I reported in my last message occurs with the v2.2 kernel

  Propeller .:.:--TACHYON--:.:. Forth V22131115.1400
 Cold start - no user code - setting defaults
----------------------------------------------------------------
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V22131115.1400
 ok
0000  ok
0001  ok
0002  okND.fth    ." Primary extensions to TACHYON kernel - 131124-0000 " ;
0003  ok
\

[Brian Riley]

That is the EXTEND.fth one that was linked to in the dropbox, thought you might have forgot to update the VER .

Update:
Now that's better, I'm sure Brian's issue will be resolved as well. Thanks Peter

End of source code, 1305 lines processed and 0000 errors found
Load time = 45,587ms

Brian's issue will be resolved -- YES ... AND ... NO. The "come to a screeching halt" .... gone!

New problem - TACHYON is essentially done and goes to execute "END" .... aaaannnndddd KAPLOOEY it endlessly loops spitting startup headers ad nauseam (see below)

Repeatable on Activity board, Prop Platform and QUICKSTART

  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300
 Cold start - no user code - setting defaults
----------------------------------------------------------------
TACHYON
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300
 ok
0000  ok
0001  ok
0002  okND.fth    ." Primary extensions to TACHYON kernel - 131124-0000 " ;
0003  ok
\
\
0004  okT       DUP $0A <> IF $100 OR 2* (EMIT) ELSE DROP THEN ;
0005  ok
\
0006  ok ( --  \ do nothing ) ;
0007 K ( on/off -- \ enable/disable OK prompts including the autospace )
0008 F 0 ELSE ' NOOP THEN prompt 2+ W!
0009  ok
0010 CHO ( on/off --  \ set the ECHO flag on/off for controlling output )
0011 1 flags ROT BIT!
0012  ok
\
0013  ok      OFF ECHO OFF OK ' LEMIT uemit W! ;
0014  ok
\
0015  ok      ON ECHO ON OK 0 uemit W! ;
0016  ok
[~        \
0349    ce-miso-mosi-clk -- \ masks are created to COGREGs from pin positions given as 4 byte fields inside
0360    ce-miso-mosi-clk -- \ masks are created to COGREGs from pin positions given as 4 byte fields inside
   -- cmdWord \ read in a 16 bit command from the tasks variable and return with it and also clear the tasks
0446    str maxsize --  \ Create a string constant and specify size of string allocation else use 0 = defaul
   n -- \ Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the co
1305  ok  t found "    registers "   )  into the dst area )ort )el PWM "object" ))
\
1306

00
  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300


  Propeller .:.:--TACHYON--:.:. Forth V23131125.0300

[MJB]

I stumbled across the Succesive Aproximation Normalization (SAN) Filter
while commenting Peters EXTEND.fth file ...
and wondered about the real timings of the different versions of to solve this problem

so I made some experiments, first in Tachyon then in SPIN.
see SPIN version here http://forums.parallax.com/showthrea...=1#post1221763

What is still missing is a straight forward SPIN implementation using the FLOAT library
which I expect to be really slow.
Maybe someone can provide the numbers.

this is the problem we want to solve:

1) Data = [(Data-RefLOW)/(RefHIGH-RefLOW)]*(2^BitResolution)

if we rearrange it a little we get rid of the requirement for float immediately

2) Data = (Data-RefLOW) * (2^BitResolution) / (RefHIGH-RefLOW)

and then replace the * 2^n with shift left

3) Data = ((Data-RefLOW) SHL BitResolution) / (RefHIGH-RefLOW)

I get the following timings: @80MHz
Beau's filter in PASM 26 us
Beau's filter in SPIN 579 us ( Peter writes around 1300us in his EXTEND.fth, I don't know how he measured it)
EQ3 in SPIN 34 us
from Tachyon
Beau's filter in TForth 205 us
EQ2 in a lazy impl. in TF 208 us
EQ2 fast impl. in TF 28 us
EQ3 fast TF impl. 24 us faster than the PASM implementation of the SAN-Filter
-- I assume this speed is the result of Peter's fast kernel divide instruction.
SPIN FLOAT-LIB ?? the horrible example of NOT to do it ;-)
PASM impl. of EQ3 ?? would be a great reference - should be faster then all the others ...

/ EXTEND.fth has to be preloaded
 : norm ( data   bits low high -- result )
     \     X4     X3  X2   X1
      4 LOCAL 
      X4 X2 -
      X3 MASK *
      X1 X2 - / 
      4 RELEASE ;
   
: norm3            ( data   bits low high -- result )
     OVER -       ( data   bits low high-low ) 
     SWAP        ( data   bits high-low low ) 
     4TH SWAP ( data   bits high-low data low )  
     -                 ( data   bits high-low data-low )   
     3RD MASK  
     *  
     SWAP /  
     NIP ;
    
: norm4            ( data   bits low high -- result )
     OVER -       ( data   bits low high-low ) 
     SWAP        ( data   bits high-low low ) 
     4TH SWAP ( data   bits high-low data low )  
     -                 ( data   bits high-low data-low ) 
     3RD   SHL      
     SWAP /  
     NIP ;    

/ tests
/  NORMALIZE  is Peter's Tachyon  implementation of Beau's SPIN code
 #2834    #12 #204 #8453 NEWCNT NORMALIZE .LAP SPACE .DEC     /    205us 1306 ok
 #2834    #12 #204 #8453 NEWCNT norm .LAP SPACE .DEC                /    208us 1305 ok
 #2834    #12 #204 #8453 NEWCNT norm3 .LAP SPACE .DEC              /      28us 1305 ok
 #2834    #12 #204 #8453 NEWCNT norm4 .LAP SPACE .DEC              /      24us 1305 ok

[D.P]

I think you got me in the middle of an edit/debug as I had the same problem, it was just a compile-time memory allocation problem, the receive buffer and hub stack was too close to the end of RAM. But it's been fixed in the Google document about 5 hours ago. I've also updated the Dropbox files. How come you are not using the latest EXTEND.fth? It is 131124.

BTW, the change was to fix a dictionary extension method so that I could easily move the dictionary or part thereof to EEPROM or SD and it would still be accessible although slower but a fair chunk of hub RAM would be freed up.

That is the EXTEND.fth one that was linked to in the dropbox, thought you might have forgot to update the VER .

Update:
Now that's better, I'm sure Brian's issue will be resolved as well. Thanks Peter

End of source code, 1305 lines processed and 0000 errors found
Load time = 45,587ms

[Peter Jakacki]

Lastest Tachyon V2.3 and Extend.fth does not work on Quickstart. Kernel complies (BST), downloads and runs, EXTEND.fth will not load. I have been compling kernels and extend for a while now, have tried excruciatingly slow download rates and every other "trick" I know, no joy.

TACHYON
Propeller .:.:--TACHYON--:.:. Forth V23131116.1400
ok

from Extend.fth
pri EXTEND.fth ." Primary extensions to TACHYON kernel - 131115-0000 " ;

dp

I think you got me in the middle of an edit/debug as I had the same problem, it was just a compile-time memory allocation problem, the receive buffer and hub stack was too close to the end of RAM. But it's been fixed in the Google document about 5 hours ago. I've also updated the Dropbox files. How come you are not using the latest EXTEND.fth? It is 131124.

BTW, the change was to fix a dictionary extension method so that I could easily move the dictionary or part thereof to EEPROM or SD and it would still be accessible although slower but a fair chunk of hub RAM would be freed up.

[D.P]

Just now using current DRopBox files V2.3 spin (5 days old) and EXTEND.fth (3 hours old) - same thing - chokes to a halt about 3/4's through in vicinity of line 1969.

Lastest Tachyon V2.3 and Extend.fth does not work on Quickstart. Kernel complies (BST), downloads and runs, EXTEND.fth will not load. I have been compling kernels and extend for a while now, have tried excruciatingly slow download rates and every other "trick" I know, no joy.

TACHYON
Propeller .:.:--TACHYON--:.:. Forth V23131116.1400
ok

from Extend.fth
pri EXTEND.fth ." Primary extensions to TACHYON kernel - 131115-0000 " ;

dp

[Brian Riley]

Hi Brian, have you tried using the latest 2.3 kernel? It has a deep hybrid stack plus dedicated SPI support instructions.
Anyway that EXTEND_131121.fth isn't a current file and was really jsut a case conflict with Dropbox at the time, so I left it there and just renamed it.

Just now using current DRopBox files V2.3 spin (5 days old) and EXTEND.fth (3 hours old) - same thing - chokes to a halt about 3/4's through in vicinity of line 1969.

[Peter Jakacki]

I am having trouble loading EXTEND_131121 ... it loads clean until in the vicinity of line 1679

1678:  pub .RUNTIME 
1679:        CR ." Runtime since last reset = " runtime @ $400A .NUM ." ms "
1680:        ;

It just stops and is repeatable. EXTEND.fth loads fine.


OH YEAH ... you all may know this already ... the SD pins and card detect code for the BOE work on the Activity Board.

Hi Brian, have you tried using the latest 2.3 kernel? It has a deep hybrid stack plus dedicated SPI support instructions.
Anyway that EXTEND_131121.fth isn't a current file and was really jsut a case conflict with Dropbox at the time, so I left it there and just renamed it.

[Brian Riley]

@DP I started commenting, have a look and check my comments for readability and correctness and put in a note where required.
Everybody I think can add postit notes to the file in google docs.
thanks MJB
here the link again.
https://docs.google.com/document/d/1...it?usp=sharing

I am having trouble loading EXTEND_131121 ... it loads clean until in the vicinity of line 1679

1678:  pub .RUNTIME 
1679:        CR ." Runtime since last reset = " runtime @ $400A .NUM ." ms "
1680:        ;

It just stops and is repeatable. EXTEND.fth loads fine.


OH YEAH ... you all may know this already ... the SD pins and card detect code for the BOE work on the Activity Board.

[D.P]

@DP I started commenting, have a look and check my comments for readability and correctness and put in a note where required.
Everybody I think can add postit notes to the file in google docs.
thanks MJB
here the link again.
https://docs.google.com/document/d/1...it?usp=sharing

Nice, I'll review your comments.

[MJB]

Well I would really like to see EXTEND.fth highly commented, I'm sure there are others. I will try to help.

@DP I started commenting, have a look and check my comments for readability and correctness and put in a note where required.
Everybody I think can add postit notes to the file in google docs.
thanks MJB
here the link again.
https://docs.google.com/document/d/1...it?usp=sharing

[Peter Jakacki]

I just came across <CR> and TAB and was wondering why the <> in one case ...
after some research I collected some character words vs. character output words

character words push the character ASCII byte or number on the stack, but character output words send them to EMIT

number words: 0 1 2 3 4 5 6 7 8 16
character words: BL = 32 or $20
character output words:
CLS = $0C clear screen
SPACE = BL outputs a $20
BELL = $07
TAB = $09

wouldn't this
CR = $0D0A = CrLf
<CR> = $0D
read more consistently as
CR = $OD
CRLF = $0D0A ??
but never mind, now I know it ...

CR is one of those words that remain the same but may do different things on different systems, perhaps it's a CR or a CRLF or just an LF, but CR is synonymous with line endings. I do agree that CRLF and CR would be more sensible though. In other Forths the BELL etc are only constants so you still have to EMIT them but that never made any sense to me as that is all you would want to do with them, just like CR.

The single digits 0 to 8 are fast single bytecode constants as are 16 and BL (or 32) although the larger constants are a fraction slower due to the accumulate method of creating a fast constant using just one instruction each.



Now if anyone wants to comment EXTEND.fth then click this link and request edit access for the Google document.

[MJB]

I just came across <CR> and TAB and was wondering why the <> in one case ...
after some research I collected some character words vs. character output words

character words push the character ASCII byte or number on the stack, but character output words send them to EMIT

number words: 0 1 2 3 4 5 6 7 8 16
character words: BL = 32 or $20
character output words:
CLS = $0C clear screen
SPACE = BL outputs a $20
BELL = $07
TAB = $09

wouldn't this
CR = $0D0A = CrLf
<CR> = $0D
read more consistently as
CR = $OD
CRLF = $0D0A ??
but never mind, now I know it ...

[D.P]

if pub lines get a good inline doc it is easy to extract a manual from it
like here with notepad++ find applied to EXTEND.fth
Maybe some convention on { pub --- comments ---- } cold give some additional documentation lines to help group by topic

Search "pub" (224 hits in 1 file)
  F:\Tachyon 2013-11-19 V23\EXTEND.FTH (224 hits)
{ pub --------------------------- TEXT & IO words ------------------------------------------------ }
    Line 119: pub <CR>    $0D EMIT ;
    Line 120: pub TAB    9 EMIT ;
    Line 122: pub UPPER
    Line 125: pub ECHO ( on/off -- )        1 flags ROT BIT! ;
    Line 126: pub NOOP ;
    Line 127: pub OK ( on/off -- )        IF 0 ELSE ' NOOP THEN prompt 2+ W! ;
    Line 141: pub (             \ stack comment - store details in extra EEPROM if available 
    Line 157: pub HELP ( addr -- )
{ pub --------------------  Variable & Const declaration ---------------------------------------- 
Create fixed variables by borrowing from assembler syntax using an origin and specify number of bytes for each variable
This allows us to work from a fixed area in RAM and the variables end up being defined as constants.
Usage: 
    $4000 ORG
    2    DS readptr        \ allocates 2 bytes for readptr at $4000
    2    DS writeptr        \ allocates 2 bytes for writeptr at $4002
    #64    DS mybuffer        \ allocates 64 bytes for mybuffer at $4004

or
    TABLE myvars #64 6 * ALLOT    \ allocate long aligned memory for 6 sets of 64 bytes
    myvars ORG                \ work from the start of the table
    #12    DS name
    4    DS offset
    \ etc
.
.
.

If you like, Peter, I could do some commenting - as far as I understand it - so you can spend your time on new stuff.
I helps me learn a lot.

Well I would really like to see EXTEND.fth highly commented, I'm sure there are others. I will try to help. I agree Peter's efforts are best spent "adjusting" Tachyon.

[MJB]

if pub lines get a good inline doc it is easy to extract a manual from it
like here with notepad++ find applied to EXTEND.fth
Maybe some convention on { pub --- comments ---- } cold give some additional documentation lines to help group by topic

Search "pub" (224 hits in 1 file)
  F:\Tachyon 2013-11-19 V23\EXTEND.FTH (224 hits)
{ pub --------------------------- TEXT & IO words ------------------------------------------------ }
    Line 119: pub <CR>    $0D EMIT ;
    Line 120: pub TAB    9 EMIT ;
    Line 122: pub UPPER
    Line 125: pub ECHO ( on/off -- )        1 flags ROT BIT! ;
    Line 126: pub NOOP ;
    Line 127: pub OK ( on/off -- )        IF 0 ELSE ' NOOP THEN prompt 2+ W! ;
    Line 141: pub (             \ stack comment - store details in extra EEPROM if available 
    Line 157: pub HELP ( addr -- )
{ pub --------------------  Variable & Const declaration ---------------------------------------- 
Create fixed variables by borrowing from assembler syntax using an origin and specify number of bytes for each variable
This allows us to work from a fixed area in RAM and the variables end up being defined as constants.
Usage: 
    $4000 ORG
    2    DS readptr        \ allocates 2 bytes for readptr at $4000
    2    DS writeptr        \ allocates 2 bytes for writeptr at $4002
    #64    DS mybuffer        \ allocates 64 bytes for mybuffer at $4004

or
    TABLE myvars #64 6 * ALLOT    \ allocate long aligned memory for 6 sets of 64 bytes
    myvars ORG                \ work from the start of the table
    #12    DS name
    4    DS offset
    \ etc

Test it out:
myvars . 2E30 ok
offset . 2E3C ok
}
    Line 189: pub ORG ( addr -- )        org !    ;
    Line 192: pub DS+            org +! ;
    Line 194: pub DS ( bytes <name> -- )
    Line 206: pub ==                    [COMPILE] CONSTANT ;
{ pub ------------------------- Math words ----------------------------------------------- }
    Line 209: pub ABS ( val -- absval )        DUP 0< ?NEGATE ;
    Line 213: pub /ROUND ( val1 divisor -- val2 )
    Line 220: pub LBIT! ( mask addr state -- )
    Line 225: pub LONGFILL ( addr cnt longval -- ) 
    Line 235: pub MOD ( n1 mod -- rem )         
    Line 243: pub RND ( -- n)
    Line 251: pub COS ( angle -- cosine )
    Line 253: pub SIN ( angle -- sine )
    Line 262: pub ^2  DUP * ;
    Line 263: pub ^ ( n pwr -- n^pwr )
    Line 282: pub SQR ( value -- sqr )
    Line 296: pub HYPOT ( A B -- hypot )
    Line 302: pub QHYPOT ( A B -- hypot )
    Line 309: pub HDEMO ( addr -- )
    Line 324: pub ALIGN ( n align -- n1 )
    Line 330: pub U!    ( long addr -- )
    Line 333: pub U@    ( addr -- long )
    Line 338: pub |< ( bit -- mask )
    Line 342: pub >| ( mask -- bit )        
    Line 347: pub =>    ( n1 n2 -- flg )         1- > ;
    Line 348: pub <=    ( n1 n2 -- flg )        SWAP => ;
    Line 352: pub ++ ( addr -- )        1 SWAP +! ;
    Line 353: pub -- ( addr -- )        -1 SWAP +! ;
    Line 354: pub W++ ( addr -- )        1 SWAP W+! ;
    Line 355: pub W-- ( addr -- )        -1 SWAP W+! ;
    Line 356: pub C++ ( addr -- )        1 SWAP C+! ;
    Line 357: pub C-- ( addr -- )        -1 SWAP C+! ;
    Line 360: pub ~ ( addr -- )        0 SWAP ! ;
    Line 361: pub ~~ ( addr -- )        -1 SWAP ! ;
    Line 362: pub W~ ( addr -- )        0 SWAP W! ;
    Line 363: pub W~~ ( addr -- )        -1 SWAP W! ;
    Line 364: pub C~    ( addr -- )        0 SWAP C! ;
    Line 365: pub C~~ ( addr -- )        -1 SWAP C! ;
    Line 368: pub @.    ( addr -- )        @ U. ;
    Line 386: pub UNLOOP
    Line 390: pub ESC? ( -- flg \ true if an escape has been pressed )
{ pub ---------------------- FORMATTING --------------------------- }
    Line 395: pub TYPE ( str cnt -- )
    Line 400: pub EMITS ( ch cnt -- )         0 DO DUP EMIT LOOP DROP ;
    Line 401: pub SPACES ( cnt -- )         BL SWAP EMITS ;
    Line 405: pub .HEAD ( str -- )        DUP #100 < IF ' indent 1+ ! ELSE CR DUP .STR STRLEN indent SWAP - SPACES THEN ;
    Line 439: pub .NUM  ( sign+sep+digits;base -- ) 
    Line 460: pub .DECX                $400A .NUM ;
    Line 461: pub .INDEX                CR I .WORD ." : " ;
    Line 462: pub .ADDR ( addr -- )         CR $4810 .NUM ." : " ;
    Line 463: pub U.N ( data digits -- )
    Line 474: pub XY ( x y -- )            ";" SWAP VC "H" VP ;
    Line 476: pub HOME                "H"
    Line 478: pub ERLINE            "2" ESCB "K" EMIT ;
    Line 479: pub VCLS                HOME
    Line 480: pub ERSCN                "2" ESCB "J" EMIT ;
    Line 481: pub CURSOR ( on/off -- )        "?" ESCB ." 25" IF "h" ELSE "l" THEN EMIT ;
    Line 482: pub PLAIN                "0"
    Line 483: pub (VA) ( ch -- )        ESCB "m" EMIT ;
    Line 484: pub REVERSE            $37 (VA) ;
    Line 485: pub BOLD                $31 (VA) ;
    Line 501: pub RECT ( x1 y1 width height -- )
    Line 509: pub X1                locals @ ;
    Line 510: pub X2                1 @X @ ;
    Line 511: pub X3                2 @X @ ;
    Line 512: pub X4                3 @X @ ;
    Line 514: pub LOCAL ( n -- )             locals OVER @X 3RD 2* 2* $40 SWAP - <CMOVE 0 DO I @X ! LOOP ;
    Line 515: pub RELEASE ( n -- )        DUP @X locals ROT 2* 2* $40 SWAP - CMOVE ;
    Line 520: pub PFA>NFA ( pfa -- nfa )
    Line 531: pub CLKFREQ ( -- freq ) 
    Line 534: pub COGREG! ( dat ix -- )
    Line 537: pub COGREG@ ( ix -- dat )
    Line 548: pub MASK? ( n -- mask )
    Line 552: pub MODPINS ( ce-miso-mosi-clk -- )
    Line 562: pub WAITPNE ( mask -- )            3 COGREG! (WAITPNE) ;
    Line 563: pub WAITPEQ ( mask -- )            3 COGREG! (WAITPEQ) ;
    Line 569: pub COGINIT ( cog code par -- )
    Line 576: pub COGSTOP ( cog -- )
    Line 582: pub RESET        
    Line 584: pub CLKSET ( n -- )
    Line 588: pub RCFAST    0 CLKSET ;
    Line 589: pub RCSLOW    1 CLKSET ;
    Line 590: pub CLK ( multiple0..4 -- ) 3 + 4 C@ 7 ANDN OR CLKSET ;
{ ------------------------------ TASKS ---------------------------------------------------------------------------------------------- }
    Line 604: pub TASK? ( -- task | Find the next available cog that's free to run a task - ready and in IDLE )
    Line 608: pub RUN ( pfa cog -- | USAGE: ' MYTASK TASK? RUN )
    Line 620: pub ATN?    \ alias for newer command ATN@
    Line 621: pub ATN@ ( -- cmd \ read in a command from the tasks variable and return with it and also clear the tasks variable )        
    Line 626: pub ENQ! ( data -- )
    Line 631: pub ATN! ( cmd cog -- \ Send data to another task )
    Line 635: pub ENQ@ ( cog -- data )
    Line 641: pub TASKS
{ pub ----------------------  STRING ----------------------------------------------------------------------------------------------- }
    Line 678: pub STRING ( str max -- ) \ Specify max size of string else use 0 for string length
    Line 694: pub LEN$ ( str -- len )    STRLEN ;
    Line 695: pub TYPE$ ( str -- )    .STR ;
    Line 703: pub COPY$ ( str1 str2 -- )
    Line 711: pub APPEND$ ( str1 str2 -- )
    Line 719: pub +CHAR ( ch str2 -- )
    Line 722: pub MID$ ( str offset len -- str )
    Line 725: pub LEFT$ ( str len -- str )
    Line 728: pub RIGHT$ ( str len -- str )
    Line 732: pub ERASE$ ( str -- )
    Line 736: pub LOCATE$ ( ch str -- str )
    Line 742: pub COMPARE$ ( str1 str2 -- flg )
    Line 752: pub PRINT$        .STR ;

    Line 764: pub NORMALIZE ( data   bits low high -- result )
    Line 791: pub !ADC ( pins -- )            \ long encoded pin descriptor &ce.miso.mosi.sck (i.e. &00.01.02.03)
    Line 805: pub ADC@ ( ch -- data )
    Line 816: pub ADCBUF ( buffer -- )    \ Read all 8 ADC channels into specified word buffer
    Line 820: pub VOLTS@ ( ch -- volts.00 )    \ Read back the pin as a voltage scaled to 2 decimals
    Line 826: pub LSADC
{ pub -------------------- IO ----------------------------- }
    Line 842: pub PINSET ( pin -- )
    Line 845: pub PINCLR ( pin -- )
    Line 849: pub PININP ( pin -- )        
    Line 853: pub PINS@ ( pin for -- ) 
    Line 860: pub MASKS ( pin cnt -- mask )

    Line 867: pub second ( n1 - )
    Line 868: pub seconds ( n1 -- )
    Line 888: pub MATCH
    Line 898: pub ANY        KEY DUP EMIT any C! ;
    Line 920: pub MY
    Line 924: pub QWORDS
    Line 950: pub .ATRS 
    Line 958: pub WORDS
    Line 992: pub MODULES
    Line 1012: pub BOOTS
    Line 1021: pub MAP ( src cnt -- )
    Line 1030: pub RMAP     0 $8000 MAP ;
    Line 1033: pub BDUMP ( addr cnt buffer -- )
    Line 1050: pub LB ( cnt -- ) \ Dump the buffer
    Line 1054: pub DUMP ( addr cnt -- )     OVER BDUMP ;
    Line 1062: pub SERBAUD ( baud -- ) 
    Line 1070: pub SEROUT ( data pin -- ) 
    Line 1079: pub SERIN ( pin -- data )
    Line 1088: pub CON        
    Line 1093: pub NULLOUT        ' (NULLOUT) uemit W! ;
    Line 1096: pub .LAP        
    Line 1110: pub SPRS 
    Line 1121: pub PINLOAD? ( pin# -- flg )
    Line 1131: pub PINS            \ prefer to keep this the same as other similar words as a ? denotes a return flag
    Line 1132: \ pub PINS?
{ pub ----------------------------- COUNTERS --------------------------------------- }
    Line 1174: pub A        ctr C~ ;
    Line 1175: pub B         1 ctr C! ; 
    Line 1178: pub NCO     4 
    Line 1179: pub CTRMODE ( n -- | Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the counter )
    Line 1188: pub DUTY
    Line 1191: pub PLL
    Line 1194: pub PLLDIV ( n -- )
    Line 1203: pub APIN ( pin -- | Set the APIN of the current CTR )
    Line 1208: pub BPIN ( pin -- | Set the BPIN of the current CTR )
    Line 1214: pub FRQ ( n -- | Set the value of the current FRQ either A or B )
    Line 1219: pub DAC! ( byte pin -- )
    Line 1228: pub MHZ ( MHz -- )
    Line 1230: pub KHZ ( khz -- )
    Line 1232: pub HZ ( hz -- )
    Line 1235: pub MUTE
    Line 1285: pub .TIME
    Line 1287: pub .ASTIME ( hhmmss -- )
    Line 1290: pub .HHMMSS
    Line 1295: pub TIMER ( channel -- addr )
    Line 1298: pub TIMEOUT ( ms channel -- )
    Line 1301: pub TIMEOUT? ( channel -- flg )
    Line 1304: pub ALARM ( pfa channel -- ) 
    Line 1344: pub RUNTIMERS ( table cnt -- )
    Line 1390: pub RUNPWM ( pin channels table -- | Start up a task to run the multichannel PWM "object" )
    Line 1397: pub PWMFREQ ( hz --  )
    Line 1407: pub PWM! ( duty8 channel -- )
    Line 1419: pub PWM! ( duty8 channel -- )
    Line 1424: pub % ( %duty -- dutyval )
    Line 1441: pub EEPROM
    Line 1444: pub I2CPINS ( sda scl -- ) 
    Line 1451: pub I2CSTART
    Line 1459: pub I2CSTOP
    Line 1465: pub I2C!? ( data -- flg )         \ write a byte to the I2C bus and return with the ack (0=ack)    
    Line 1478: pub I2C! ( data --  )            \ write a byte to the I2C bus     
    Line 1489: pub ackI2C@
    Line 1492: pub I2C@    ( ack -- data )    
    Line 1502: pub SI2C!?     ( data -- )         \ write a byte to the I2C bus and return with the ack (0=ack)    
    Line 1512: pub SI2C!  SI2C!? DROP ;
    Line 1516: pub SI2C@    ( ack -- data )    
    Line 1525: pub I2CBUS
    Line 1565: pub EE! ( byte addr -- )
    Line 1569: pub EE@ ( addr -- byte ) 
    Line 1579: pub ESAVE ( ram eeprom cnt -- )
    Line 1592: pub ESAVEB ( ram eeprom cnt -- ) 
    Line 1598: pub ELOAD ( eeprom ram cnt -- )
    Line 1605: pub ECOPY ( eesrc eedst cnt -- )
    Line 1612: pub EFILL ( src cnt ch -- )
    Line 1621: pub EVERIFY ( ram cnt -- )
    Line 1631: pub 64K? ( -- flg )
    Line 1643: pub BURNROM
    Line 1647: pub BACKUP
    Line 1654: pub ?BACKUP    
    Line 1658: pub RESTORE
    Line 1663: pub EDUMP ( addr cnt -- )
    Line 1678: pub (LOAD)
    Line 1683: pub ALOAD ( addr -- )
    Line 1691: pub LOAD ( <name> -- )
    Line 1700: pub ASAVE ( dst -- )
    Line 1710: pub @EFREE ( -- addr )
    Line 1714: pub SAVE ( <name> -- )
    Line 1751: pub HEXLOAD ( dst -- \ Load an Intel Hex file into the dst area )
    Line 1770: pub IDUMP ( src cnt --- )
    Line 1793: pub FIXCKSUM ( src cnt -- )
    Line 1804: pub BINARYDUMP
    Line 1813: pub CONBAUD ( baud -- )    VER 8 + SWAP OVER !  4 ADO I C@ I EE! #10 ms LOOP ;
    Line 1816: pub INTERRUPT ( state index -- )
    Line 1819: pub INTVEC ( addr index -- )
    Line 1822: pub INTMASK ( mask -- )
    Line 1825: pub INH ( on/off -- )    9 COGREG@ #31 MASK ROT IF OR ELSE ANDN THEN 9 COGREG! ;
    Line 1831: pub .RUNTIME 
    Line 1835: pub .VECTORS
    Line 1839: pub END
    Line 1846: pub STATS
    Line 1867: pub INFO
    Line 1884: pub AUTOBAUD
    Line 1901: pub BOOT
    Line 1909: pub FORGET ( <name> -- )
    Line 1928: pub COLD

If you like, Peter, I could do some commenting - as far as I understand it - so you can spend your time on new stuff.
I helps me learn a lot.

[MJB]

since we have no explicit namespaces in TF it is important to use pri for everything that is not really needed globaly.
Otherwise all good and short names will be gone very fast,
And writing modular SW is difficult, if you have unexpected name clashes.
So while pub/pri is not a complete solution it at least reduces the probability.

and yes - this applies for variables, tables and constants as well.

within a module the default could be private and only carefully selected symbols get explicitly and consciously exported.

[Peter Jakacki]

Hi Peter,
while reading Extend.fth I encountered several pri definitions that I would assume should be around
to be used in other modules as well.
So while at the moment it doesn't matter, just for my understanding ... I think those should be pub

pri IMMEDIATE        e.g. used in MultiFAT.fth
pri ok ;    
pri Published
pri ... ;

Well, how'd that happen? I've also been thinking about variables and constants as to how to define them as "pri" so that they can also be targeted for dictionary removal. I could have a directive that switches the pri and pub modes I guess and then all definitions could follow that unless specifically overridden, maybe "PRIVATE" and "PUBLIC" would do.

[MJB]

Hi Peter,
while reading Extend.fth I encountered several pri definitions that I would assume should be around
to be used in other modules as well.
So while at the moment it doesn't matter, just for my understanding ... I think those should be pub

pri IMMEDIATE        e.g. used in MultiFAT.fth
pri ok ;    
pri Published
pri ... ;

[Peter Jakacki]

OK, success with BST. "WORDS" and "QWORDS" don't work, must I still apply "EXTEND.FTH"? What's the best way to do this, I have not had good luck uploading code via serial, e.g. Teraterm.

Oh yeah "DEBUG" works and the stack works correctly.

Rick.

Although EXTEND.FTH has lots of stuff in it and some may consider it optional to the "kernel" that is not really the case. Really the kernel should just be the basic words needed to allow it to compile further Forth words itself. It is far easier to code Forth in Forth than Forth in Spin syntax. So always load EXTEND.fth and consider it part of the kernel, even if it is a little podgy.

Teraterm should work fine if you use the safe setting of 20ms line delay, 0 seconds character delay, and no handshaking. Just make sure you are using the SourceForge version of TeraTerm and not some old 90's version. Just copy the source code and paste it always works fine.
DEBUG can also be called by hitting ^D (control D).

[RickInTexas]

OK, success with BST. "WORDS" and "QWORDS" don't work, must I still apply "EXTEND.FTH"? What's the best way to do this, I have not had good luck uploading code via serial, e.g. Teraterm.

Oh yeah "DEBUG" works and the stack works correctly.

Rick.

[RickInTexas]

I had no problem running it in GEAR, so maybe you have a bad download.
Did you check your crystal settings match those of the binary 10MHz PLL8x?
My system has 5MHz Pll16x so I did compile the .spin in BST and PropTool myself after changing those settings - all fine

All my boards are 5MHz Pll16x, so I will have to compile with BST. Still, I should be able to open the Dropbox binary in the Prop Tool, no?

EDIT: I re-downloaded the binary and now it does open in the Prop Tool, and shows as 10MHz PLL8x.

Thanks,

Rick

[MJB]

I had no problem running it in GEAR, so maybe you have a bad download.
Did you check your crystal settings match those of the binary 10MHz PLL8x?
My system has 5MHz Pll16x so I did compile the .spin in BST and PropTool myself after changing those settings - all fine

[RickInTexas]

When I open the latest "Tachyon V2.3.binary" from Dropbox the Propeller Tool v. 1.3.2 gives me this error message.

Rick.

[Peter Jakacki]

with all those great extensions I just want to remind you that there are still small / minimal systems around with just PROP and 32kEEPROM.
So I would hate to see TACHYON following the Windows road and getting more and more resource hungry each version.
I am running it still on PPDB or P-DIP systems only.

Not to worry because it will always handle the minimal system but many of my designs have SD or even SPI Flash so it's a resource I would like to consume a bit more of so that I may have more hub RAM available at least. 32k is all there is and I don't believe in piling banked RAM or multiple Props together to achieve what I could do more efficiently with another type of CPU. But those CPUs are boring and transitory, barely staying around for a couple of years before they are hard to get. Big learning curves on their hardware and tools too. Prop ticks all the boxes.

[MJB]

with all those great extensions I just want to remind you that there are still small / minimal systems around with just PROP and 32kEEPROM.
So I would hate to see TACHYON following the Windows road and getting more and more resource hungry each version.
I am running it still on PPDB or P-DIP systems only.

[Peter Jakacki]

I think I saw a comment stating there could be multiple dictionaries searched one after the other.
Putting the pri headers in such a seperate dictionary would make it very easy to reset it on END.
Just reset the dict for the 'ephemeral' dictionary (taken from LISP garbage collection mechanisms ...), no searching, deleting, compacting required.

Well it may well be that assuming either SD card or SPI Flash is used that the source code would also be compiled from SD even if it is downloaded serially first as the card write routines can easily keep up with the high baud rates. Compiling from a files system means it's easy to have include directives and also it will compile as fast as it can rather than a serial download that has to have line delays because there is no handshaking. Perhaps I could even fetch the files from the PC via FTP, now that would be nice or simply copy the files across via FTP.

Yes, the pri headers could just be routed into their own dictionary which could be wiped after a load. Even though there is plenty of storage when you have an SD card there is still the inefficiency of searching a large dictionary so removing or ignoring the pri headers would still be advantageous. Of course it would also be possible to give each header a fixed amount of space, say 32 or 64 bytes each so that it would be possible to do simple compares on longs and skip to the next fixed length header without having to process the header any further in case of a mismatch. The longest name I have in the dictionary is 18 characters long so allowing the usual 4 extra bytes for count,code, and attributes that still leaves 28 characters if I use 32 bytes per entry.

[MJB]

V3 will also make more use of the pri vs pub declaration so that it knows it can remove the pri heads from the dictionary when it encounters an END directive.

I think I saw a comment stating there could be multiple dictionaries searched one after the other.
Putting the pri headers in such a seperate dictionary would make it very easy to reset it on END.
Just reset the dict for the 'ephemeral' dictionary (taken from LISP garbage collection mechanisms ...), no searching, deleting, compacting required.

[Peter Jakacki]

@Peter:
you placed the extended stack for the TERMINAL-COG fixed at $7720 with nothing above.
which gives a total stack of 60 longs - nothing to complain about.
and if need be can be made any size - great.

for other cog processes stack needs to be allocated manually as shown in new EXTEND.fth

TABLE timerstk  #12 4 * ALLOT     \ allot space for timer data stack
 
 pri TIMERTASK  
   !SP                  ' init COG stack
   timerstk SP!      '  set external stack start,   stack size is not set explicitly anywhere and not checked, so beware of stack overflows !!

thanks a lot ...

It's fairly rare that I need a stack more than 12 levels deep but it's also good that it has plenty of room to move or if I have junk being left on the stack then I can still see what's happened. I can't see how I would use 32 levels though even though I have pushed some extra check numbers onto it and ran it through my FTP/TELNET stuff. I can see a real need to get that dictionary out of hub ram though and I've looked at it before and know how I will handle it by using a small unused area of the SD card for this as I only need one sector buffer at a time for dictionary searches with a cache for all the recent hits. But this is significant enough to become V3 although I will still allow for slow EEPROM, or fast SPI Flash to be used instead otherwise the default is as it is now. V3 will also make more use of the pri vs pub declaration so that it knows it can remove the pri heads from the dictionary when it encounters an END directive.

[MJB]

@Peter:
you placed the extended stack for the TERMINAL-COG fixed at $7720 with nothing above.
which gives a total stack of 60 longs - nothing to complain about.
and if need be can be made any size - great.

for other cog processes stack needs to be allocated manually as shown in new EXTEND.fth

TABLE timerstk  #12 4 * ALLOT     \ allot space for timer data stack
 
 pri TIMERTASK  
   !SP                  ' init COG stack
   timerstk SP!      '  set external stack start,   stack size is not set explicitly anywhere and not checked, so beware of stack overflows !!

thanks a lot ...

[Peter Jakacki]

Just a quick note to say that I jumped from V2.2 the other day to V2.3 which essentially added new opcodes for SPIWR and SPIRD which have their own I/O mask registers apart from RUNMOD modules. I have been able to squeeze these in thanks in part to the freeing up of room by removing most of the data stack except for 4 top items which are always accessed as fixed registers, and also in part due to optimizations to the SPI code. To get the most out of SPI without reverting to the counter I have a dedicated write and a dedicated read instruction which default to 8-bits although you can override this. The SPIWR will always shift the msbs from a long so you can chain 4 SPIWR instructions together to get it to shift 32-bits in one go. The SPIRD requires a stack input parameter which is normally set to zero but by chaining 4 SPIRD instructions together you can perform a 32-bit shift. There is also a SPIWRB for writing bytes without having to left justify first as this is faster in PASM and only takes one extra instruction.

The reason for the dedicated SPI instructions is so that I can run two sets of SPI devices easily and efficiently from the one cog and in this case it is the SDCARD using the RUNMOD loadable PASM modules and the WIZnet using the SPI instructions.

[Peter Jakacki]

As mentioned in the last post I have upgraded the kernel with a hybrid stack which keeps 4 levels internally in fixed positions using the seemingly cumbersome memory move method but now supplemented with an external stack beyond this. What this means is that Tachyon is not any slower for having an external stack as it is never referenced directly, it just exists as the overflow buffer. The Tachyon VM still directly references the top 4 items as if they were fixed registers which simplifies addressing and contributes to the speed and compactness of TF.

The downside of this is that each cog that runs a Tachyon VM needs an external stack allocated. By default the pointer to this stack is zero which effectively turns off writing to hub RAM on a push and confines the VM to a 4 level stack which in some cases may be all that it needs. However the idea is that a new task will set the stack pointer for it's cog just as the main console cog does at startup, another example of which is in EXTEND.FTH where TIMERTASK is started up at boot time. Here a timer stack is created for 12 levels and it passes this address to SP!

TABLE timerstk    #12 4 * ALLOT            \ allot space for timer data stack
\ 118us for 8 empty timers
pri TIMERTASK
     timerstk SP!

New words added or updated are:

WORD.....STACK..........PRONOUNCED AS.............DESCRIPTION
!SP      ( -- )         Init Stack Pointer        Initialize the data stack (Note: this is now a native VM bytecode, part of the PASM kernel)
SP!      ( addr -- )    Stack Pointer Store       Store the address in the stack pointer - the stack builds up from here.
DEPTH    ( -- levels )  Depth                     Return with the depth of the data stack (not including the depth parameter itself)

Since the stack is a fundamental part of the VM and it now operates a bit differently I have upgraded this source as V2.2 and I have placed all the new files in Dropbox. The webpage versions will have links updated or inserted into the links page.

Note: Popping an empty stack will not cause the SP to go negative (Stack Pointer base address - depth index) but it is now possible to overflow the stack, so beware.

[Peter Jakacki]

I've updated a couple of files in Dropbox and the links pages and these include the current SDCARD and FAT virtual memory drivers. The links page now has sections so this will be updated some more yet.
There's also the W5200 driver but I haven't uploaded the network server layer yet as I am working on the glitches although I can telnet and ftp at present.

EDIT: The data stack will probably get an upgrade in the form of a hybrid with all the advantages of fixed positions for the first 4 items or so and a non-addressable push/pop overflow in hub memory.

[D.P]

Clean and straight forward in Tachyon/FORTH style, look forward to using File@ etc..
Thx, Peter

[Peter Jakacki]

I've tweaked the FAT32 layer to handle multiple files, four in fact. The files are accessed as virtual memory rather than the traditional seek and read/write. At a later stage I will add FAT16 and more functions for FORMAT, DEL, MKDIR, etc
Once I've done a bit more testing within an application I will release these source files, probably within the week.

MOUNT 
E2C4_0203: mkdosfs PBJTECH     FAT32   
Sectors = 7,739,392 ok
DIR     PBJTECH    

LOG0001 .TXT .....a 0000.4318    04/11/2013 01:25:18   131,072
LOG0002 .TXT .....a 0000.4418    04/11/2013 01:25:18   131,072
LOG0003 .TXT .....a 0000.4518    04/11/2013 01:25:18   131,072
LOG0004 .TXT .....a 0000.4618    04/11/2013 01:25:18   131,072
LOG0005 .TXT .....a 0000.4718    04/11/2013 01:25:18   131,072
LOG0006 .TXT .....a 0000.4818    04/11/2013 01:25:18   131,072
LOG0007 .TXT .....a 0000.4918    04/11/2013 01:25:18   131,072
LOG0008 .TXT .....a 0000.4A18    04/11/2013 01:25:18   131,072
LOG0009 .TXT .....a 0000.4B18    04/11/2013 01:25:18   131,072
LOG0010 .TXT .....a 0000.4C18    04/11/2013 01:25:18   131,072
LOG0011 .TXT .....a 0000.4D18    04/11/2013 01:25:18   131,072
LOG0012 .TXT .....a 0000.4E18    04/11/2013 01:25:18   131,072
LOG0013 .TXT .....a 0000.4F18    04/11/2013 01:25:18   131,072
LOG0014 .TXT .....a 0000.5018    04/11/2013 01:25:18   131,072
LOG0015 .TXT .....a 0000.5118    04/11/2013 01:25:18   131,072
LOG0016 .TXT .....a 0000.5218    04/11/2013 01:25:18   131,072
MULTIFAT.FTH .....a 0000.5318    12/11/2013 10:48:50   7,778
SDCARD  .FTH .....a 0000.5328    12/11/2013 10:02:02   14,684
CHARLCD .FTH .....a 0000.5348    12/11/2013 10:01:48   18,440
EXTEND  .FTH .....a 0000.5370    12/11/2013 10:01:42   57,915
NETWORK .FTH .....a 0000.53E8    12/11/2013 10:01:36   8,109
W5200   .FTH .....a 0000.53F8    12/11/2013 10:01:26   9,732
MCP79410.FTH .....a 0000.5410    12/11/2013 10:01:20   1,357 ok
0 FILE  ok
FOPEN SDCARD.FTH...opened at 0000.5328  ok
1 FILE  ok
FOPEN EXTEND.FTH...opened at 0000.5370  ok
2 FILE  ok
FOPEN MULTIFAT.FTH...opened at 0000.5318  ok
3 FILE  ok
FOPEN W5200.FTH...opened at 0000.53F8  ok
FILES 
#0 SDCARD  .FTH .....a 0000.5328    12/11/2013 10:02:02   14,684
#1 EXTEND  .FTH .....a 0000.5370    12/11/2013 10:01:42   57,915
#2 MULTIFAT.FTH .....a 0000.5318    12/11/2013 10:48:50   7,778
#3 W5200   .FTH .....a 0000.53F8    12/11/2013 10:01:26   9,732 ok
0 FILE FILE@ 20 XDUMP 
00A6_5000:   54 41 43 48  59 4F 4E 0A   5B 7E 0A 7B  20 53 44 20   TACHYON.[~.{ SD 
00A6_5010:   43 41 52 44  20 54 4F 4F   4C 4B 49 54  20 7D 20 20   CARD TOOLKIT }   ok
1 FILE FILE@ 20 XDUMP 
00A6_E000:   54 41 43 48  59 4F 4E 0A   7B 20 45 58  54 45 4E 44   TACHYON.{ EXTEND
00A6_E010:   2E 66 74 68  20 7D 0A 0A   70 72 69 20  45 58 54 45   .fth }..pri EXTE ok
2 FILE FILE@ 20 XDUMP 
00A6_3000:   54 41 43 48  59 4F 4E 0A   5B 7E 0A 46  4F 52 47 45   TACHYON.[~.FORGE
00A6_3010:   54 20 46 41  54 33 32 2E   66 74 68 0A  3A 20 46 41   T FAT32.fth.: FA ok
3 FILE FILE@ 20 XDUMP 
00A7_F000:   54 41 43 48  59 4F 4E 0A   5B 7E 0A 7B  20 20 20 20   TACHYON.[~.{    
00A7_F010:   20 20 20 20  20 20 20 20   20 20 20 20  20 20 2A 2A                 ** ok

EDIT: This is just a simple (and inefficient) demo to show how we can copy one file into another - here we copy from file #1 to file #0.
FILE@ returns with the virtual address of the beginning of the currently selected file
FILE accepts a parameter to set the currently selected file
XC@ works just like a C@ except the address is a virtual 4GB address
XC! works the same but also flags the buffer as modified
FCLOSE is optional and just flushes any modified buffers and resets file pointers

0 FILE  ok
FOPEN LOG0001.TXT...opened at 0000.3B28  ok
1 FILE  ok
FOPEN EXTEND.FTH...opened at 0000.4B80  ok
  ok
0 #57915 ADO 1 FILE FILE@ I + XC@ 0 FILE FILE@ I + XC! LOOP  ok
0 FILE FILE@ 40 XDUMP 
0076_5000:   54 41 43 48  59 4F 4E 0A   7B 20 45 58  54 45 4E 44   TACHYON.{ EXTEND
0076_5010:   2E 66 74 68  20 7D 0A 0A   70 72 69 20  45 58 54 45   .fth }..pri EXTE
0076_5020:   4E 44 2E 66  74 68 20 20   20 20 2E 22  20 50 72 69   ND.fth    ." Pri
0076_5030:   6D 61 72 79  20 65 78 74   65 6E 73 69  6F 6E 73 20   mary extensions  ok
FCLOSE  ok

[Peter Jakacki]

I didn't have my Prop board with me and gave GEAR a try.

AND IT WORKED

yes, it took some time to boot up a standard Tachyon 2.1 image from Peters dropbox
but I think this can be made much faster by not running all COGs
AND by reducing the startup delay (to run the about 40 000 000 cycles it takes about half an hour -
so don't give up to early.

I used Gear V 9.10.26.7 dated 26. Oktober 2009, 12:31:00 - this is not the original version, but the extended one.

you find it here: http://forums.parallax.com/showthrea...highlight=GEAR

and I loaded the SerialIO.xml plugin, configured it to the correct baudrate and there you go.

Unfortunately I didn't find a way to suppress the autoecho, so typed characters get echoed twice
from the terminal and as usual from Tachyon itself.
EDIT: within serialIO.xml just comment out a few lines

  private void txt_KeyPress(object sender, System.Windows.Forms.KeyPressEventArgs e)
  {
    if ((Control.ModifierKeys & Keys.Control) != 0) {
      return;
    }
    
    e.Handled = true;

    txBuffer += e.KeyChar;
    
//    if (e.KeyChar == '\n' || e.KeyChar == '\r') {
//      displayBuffer += "\r\n";
//    }
//    else {
//      displayBuffer += e.KeyChar;
//    }
    
    this.bodyField.Text = displayBuffer;
    this.bodyField.SelectionStart = this.bodyField.Text.Length;
    this.bodyField.ScrollToCaret();
    
    if (txPhase == 0) {
      txPhase = 1;
    }
  }

And the you can set breakpoints in the cogs and watch whats is going on - at the PASM level ...

Why didn't I try this before ??

I've just updated Dropbox with a newer version of the kernel and extend. You will find the echo function can be turned off and on normally with "OFF ECHO" and "ON ECHO". Turning off the echo also suppresses the space character that is emitted after a line has been accepted.
There is no real need to have any startup delay if you are running Gear so you can just comment out the last line of this section.

TERMINAL

    byte    InitRP
     byte    XCALL,xInitStack
    byte    _WORD,00,50,XCALL,xms            ' a little startup delay (also wait for serial cog)

[MJB]

I didn't have my Prop board with me and gave GEAR a try.

AND IT WORKED

yes, it took some time to boot up a standard Tachyon 2.1 image from Peters dropbox
but I think this can be made much faster by not running all COGs
AND by reducing the startup delay (to run the about 40 000 000 cycles it takes about half an hour -
so don't give up to early.

I used Gear V 9.10.26.7 dated 26. Oktober 2009, 12:31:00 - this is not the original version, but the extended one.

you find it here: http://forums.parallax.com/showthrea...highlight=GEAR

and I loaded the SerialIO.xml plugin, configured it to the correct baudrate and there you go.

Unfortunately I didn't find a way to suppress the autoecho, so typed characters get echoed twice
from the terminal and as usual from Tachyon itself.
EDIT: within serialIO.xml just comment out a few lines

  private void txt_KeyPress(object sender, System.Windows.Forms.KeyPressEventArgs e)
  {
    if ((Control.ModifierKeys & Keys.Control) != 0) {
      return;
    }
    
    e.Handled = true;

    txBuffer += e.KeyChar;
    
//    if (e.KeyChar == '\n' || e.KeyChar == '\r') {
//      displayBuffer += "\r\n";
//    }
//    else {
//      displayBuffer += e.KeyChar;
//    }
    
    this.bodyField.Text = displayBuffer;
    this.bodyField.SelectionStart = this.bodyField.Text.Length;
    this.bodyField.ScrollToCaret();
    
    if (txPhase == 0) {
      txPhase = 1;
    }
  }

And the you can set breakpoints in the cogs and watch whats is going on - at the PASM level ...

Why didn't I try this before ??

[KC_Rob]

Tachyon is not a Forth for learning as some of you have found out , it's a Forth for getting things done with the Propeller, and I've been doing a lot of products in the past year with Forth embedded in them. I even did a little 1" module used in gripper arms of picker robots and boy was I glad I did it with the Prop and TF as it made it so easy to debug and fine tune this on the factory floor while the production line was running and people breathing down my neck. I think the engineers there thought I was running Linux or something on it because I could interact with it at a high level via a terminal and do all sorts of changes on the spot as well as provide realtime debug information as needed (within moments).

Cool! There is something to be said for being able to work that way.

[D.P]

Many have been asking for a FORGET word which I just keep forgetting to implement but now I have remembered to forget! This is in EXTEND.fth and performs a decremental forget operation ensuring that the correct deallocation is performed on the code, dictionary, and vector space. So don't forget to use it as I include it in the header of my modules to automatically forget that module in case it is already loaded. There is one caveat with any forget operation and that is to ensure that any code that is running in another cog or under keypoll is stopped before forgetting. Perhaps I might just add this to FORGET just in case.

I will probably also release some updated drivers soon including the unreleased FAT32 and WIZnet W5200 drivers which also includes the network servers for TELNET, FTP, and HTTP. The FAT32 is aimed primarily at datalogging where I like to preset the card beforehand with fixed file sizes and even fixed line sizes (128 bytes/line). At startup I just find the last file and binary search through this until I find the last non-blank line and set a virtual memory pointer to this in RAM without changing anything on the card. Since these files are not dynamically allocated or grown then we have no need for writing to the cluster file or worrying about fragmentation. When I save data to the card I only have to write into a preset and known position so it is not possible to corrupt the card (even with removal during writes) nor does the card suffer from premature wear because of FAT32 file size updates etc.
.
.
.
.

[/FONT][/CODE]

This will make for a wonderful Xmas season, thanks in advance!

[Peter Jakacki]

Many have been asking for a FORGET word which I just keep forgetting to implement but now I have remembered to forget! This is in EXTEND.fth and performs a decremental forget operation ensuring that the correct deallocation is performed on the code, dictionary, and vector space. So don't forget to use it as I include it in the header of my modules to automatically forget that module in case it is already loaded. There is one caveat with any forget operation and that is to ensure that any code that is running in another cog or under keypoll is stopped before forgetting. Perhaps I might just add this to FORGET just in case.

I will probably also release some updated drivers soon including the unreleased FAT32 and WIZnet W5200 drivers which also includes the network servers for TELNET, FTP, and HTTP. The FAT32 is aimed primarily at datalogging where I like to preset the card beforehand with fixed file sizes and even fixed line sizes (128 bytes/line). At startup I just find the last file and binary search through this until I find the last non-blank line and set a virtual memory pointer to this in RAM without changing anything on the card. Since these files are not dynamically allocated or grown then we have no need for writing to the cluster file or worrying about fragmentation. When I save data to the card I only have to write into a preset and known position so it is not possible to corrupt the card (even with removal during writes) nor does the card suffer from premature wear because of FAT32 file size updates etc.

My FTP can decide to strip trailing whitepsace when uploading a file but essentially the SD card is treated as flat memory for the first 4GB (more than enough) without regard to fragmentation (since it doesn't exist in this controlled environment). With the virtual memory access words the first 4GB is treated as virtual memory where file handles are actually sector addresses which translate in virtual memory address with a 9 SHL operation. There are of course a lot of words specifically designed for interactive CLI operation such as DIR, ls, cat, FOPEN <name>, etc and FLOAD <name> to load a source file. But don't expect a full FAT32 driver, at least not at present, since it's not my priority and besides FAT32 is horrible, compatible, but horrible especially for SD cards and embedded work. I will add functionality for having several files open though as I only need a minimum of one sector buffer and directory entry per file.

Tachyon is not a Forth for learning as some of you have found out , it's a Forth for getting things done with the Propeller, and I've been doing a lot of products in the past year with Forth embedded in them. I even did a little 1" module used in gripper arms of picker robots and boy was I glad I did it with the Prop and TF as it made it so easy to debug and fine tune this on the factory floor while the production line was running and people breathing down my neck. I think the engineers there thought I was running Linux or something on it because I could interact with it at a high level via a terminal and do all sorts of changes on the spot as well as provide realtime debug information as needed (within moments).

Here's a method from the FAT32 module for opening files.

'' Fetch the address of the currently open file

pub FILE@ ( -- xadr )    file @ 9 SHL    ;


'' Open the file with the name and return with it's sector (0=fail)  

pub FOPEN$ ( namestr -- sector )
    >F8.3 DIR? DUP                                        \ Convert to 8.3 format and search directory
     IF                                                    \ found an entry (virtual address)
       DUP diradr !                                        \ save address of directory entry
       XADR DUP dirbuf BL CMOVE                            \ map sector to hub RAM and copy directory entry to local buffer
       CLUSTER@ CLUST>SECT                                 \ fetch starting cluster of file and find file's start sector
       DUP file !                                          \ save start sector of file 
      THEN
    ;

Interacting with it:

FOPEN EXTEND.FTH...opened at 00024440  ok
FILE@ 40 XDUMP 
0488_8000:   54 41 43 48  59 4F 4E 0A   7B 20 45 58  54 45 4E 44   TACHYON.{ EXTEND
0488_8010:   2E 66 74 68  20 7D 0A 0A   70 72 69 20  45 58 54 45   .fth }..pri EXTE
0488_8020:   4E 44 2E 66  74 68 20 20   20 20 2E 22  20 50 72 69   ND.fth    ." Pri
0488_8030:   6D 61 72 79  20 65 78 74   65 6E 73 69  6F 6E 73 20   mary extensions  ok

[Peter Jakacki]

Is there anything in particular that you would like to do with this board and Forth?[/QUOTE]

Hi Peter,

I was thinking more of using the C3 as a small development platform. Another thing I was wondering about regarding Tachyon is the apparent absence of MARKER, FORGET, etc. Are the definitions for these words available? They're certainly an important part of the code-development cycle.

Regards,

Michael
K6MLE[/QUOTE]

Let's not forget that there are many standard Forth words that are really part of a PC standard yet the vast majority of Forth uses are embedded and non-standard and have totally different goals and resources. FORGET is easy enough to implement with a standard Forth and other Forths I have written but I haven't needed it for development at all as normally I just perform a COLD start and load the source back again. I do concede that this model is a bit of a pain sometimes when I have many modules to reload so for systems that have 64K of EEPROM I just hold a stable image in the top 32K ready to RESTORE.

That said I could still implement a FORGET but it might have to go through each word to deallocate the code, dictionary, and vector space individually to be on the safe side. The way I would use FORGET is not at an interactive testing level where it is just as easy to just write a new word but when it comes to reloading a module such as SDCARD.fth etc where I would include the word FORGET at the start of the file. Any failure to find the word would simply issue a warning and continue.

[Peter Jakacki]

you mean that many/most modern mice/kbd support PS/2 protocol on their USB connector and detect automatically wheather they are connected to UB or PS/2 port.
So the option is - cheap new mouse/kbd at micro with convenient USB connector AND simple PS/2 protocol.
The connection is like this:
http://pinouts.ru/InputCables/usb_ps...e_pinout.shtml
Connecting USB-mouse to PS/2 connector of computer. It works only with device which supports both interfaces (USB & PS/2).

USB Pin Name	USB Pin Number	Direction	Usb Color	PS/2 mouse controller Pin Number	PS/2 mouse controller Pin Name	Description	PS/2 Color
VDC +5V	1	<--	Red	4	VDC +5V		Red
Data-	2	-?-	White	1	Data		White
Data+	3	-?-	Green	5	Clock		Brown
Ground	4	-?-	Black	3	Ground		Black

Very nice to have one more empty USB connector .
It's good practice to pull up data/clock lines with some resistors of 10k or so. Especially when connecting to newer motherboards. In some cases signal has levels between 1.5 and 2.5 volts, and mouse don't work. Pulling up helps in that situations and doesn't harm if unnecessary.

Yes, the devices that are compatible with either usually come with a USB to PS/2 adaptor so that you can plug your USB HID into a PS/2 socket. That's handy for an ancient motherboard but for new designs it makes more sense to plug the device directly into a USB socket without the unwieldy adaptor which is just a dumb gender-bender. For PS/2 mode you need pull-ups but if you want to implement USB drivers then you should pull the data lines down for slow-speed mode. I use tiny SPDT solder pads about the size of an 0805 so that I just blob on my selection with a warm iron although you could tie the pull-up common to an I/O to make it software selectable.

[K6MLE]

[/QUOTE]Is there anything in particular that you would like to do with this board and Forth?[/QUOTE]

Hi Peter,

I was thinking more of using the C3 as a small development platform. Another thing I was wondering about regarding Tachyon is the apparent absence of MARKER, FORGET, etc. Are the definitions for these words available? They're certainly an important part of the code-development cycle.

Regards,

Michael
K6MLE

[MJB]

I noticed that they for some reason some designers insist on using physical PS/2 connectors although real PS/2 keyboard and mice are hard to come by ($$) although PS/2 compatible USB HIDs are far more common, which is why I just use USB connectors and dispense with any bulky wiring adapters. Besides, it gives you an option to implement USB drivers if necessary.

you mean that many/most modern mice/kbd support PS/2 protocol on their USB connector and detect automatically wheather they are connected to UB or PS/2 port.
So the option is - cheap new mouse/kbd at micro with convenient USB connector AND simple PS/2 protocol.
The connection is like this:
http://pinouts.ru/InputCables/usb_ps...e_pinout.shtml
Connecting USB-mouse to PS/2 connector of computer. It works only with device which supports both interfaces (USB & PS/2).

USB Pin Name	USB Pin Number	Direction	Usb Color	PS/2 mouse controller Pin Number	PS/2 mouse controller Pin Name	Description	PS/2 Color
VDC +5V	1	<--	Red	4	VDC +5V		Red
Data-	2	-?-	White	1	Data		White
Data+	3	-?-	Green	5	Clock		Brown
Ground	4	-?-	Black	3	Ground		Black

Very nice to have one more empty USB connector .
It's good practice to pull up data/clock lines with some resistors of 10k or so. Especially when connecting to newer motherboards. In some cases signal has levels between 1.5 and 2.5 volts, and mouse don't work. Pulling up helps in that situations and doesn't harm if unnecessary.

[Peter Jakacki]

I've just received a Propeller C3 and would like to know if there is any Forth code that specifically supports it's various features? Having been away from Forth for a couple of decades, I'm not too sure of myself as far as writing it from scratch!

It doesn't look like anything special in terms of I/O and at the most they would just require C3 pin definitions. What is missing at present is any sort of built-in VGA which although present in V1 was removed die to the memory requirements, but then again it was 512x384 bitmap and there is probably no reason why we can't build in a nice little text VGA object that can be activated easily. Me feeling is that the driver should be somewhat runtime configurable as to resolution, text or graphics mode etc. With Tachyon being fast enough to handle the high level requirements of a VGA driver then the PASM code footprint for the video display cog would be minimal.

I noticed that they for some reason some designers insist on using physical PS/2 connectors although real PS/2 keyboard and mice are hard to come by ($$) although PS/2 compatible USB HIDs are far more common, which is why I just use USB connectors and dispense with any bulky wiring adapters. Besides, it gives you an option to implement USB drivers if necessary.

Is there anything in particular that you would like to do with this board and Forth?

[K6MLE]

I've just received a Propeller C3 and would like to know if there is any Forth code that specifically supports it's various features? Having been away from Forth for a couple of decades, I'm not too sure of myself as far as writing it from scratch!

[Brian Riley]

The DSRTC code I posted had several non stack-neutral words. Most of them got away without mucking things up, but the two most heavily used display words were fouling up anytime they were in a sequence of words where a DUP was being used to carry data or an address forward. The short version is, I goofed and I found and fixed the problem.

This code has been running on one of my Propeller Platform Through-Hole boards with the DS3231 backed up by a CR2032 lithium battery and also on a Prop Activity Board backed up by a .3F supercap charge from the 3.3 supply lines via a 1N4148 diode. Both boards are powered from about 0900 to 0100 and from 0100 to 0900 the DS3231s are maintaining via their respective backup sources. In the well over a week of this testing neither RTC differs from the NNTP set time on my iMac by more than a second. Since the discrepancy does not creep I am inclined to think its mostly due to my Parkinson impaired reflexes when I whacked the "Enter" key when I set it 10 days ago!

All in all the DS3231 looks to be an excellent all around choice for RTC

PROs
- operates on 1.8 to 5.5 volts
- pullups on SDA/SCL can be different voltage than Vcc
- built in TXCO resonator
- 5 ppm accuracy

CONs
- $8+ in small quantities



The code can still be used, altering a pair of CONSTANTs, either by the DS1307 or DS3231

[Brian Riley]

I*wrote some sample code in ARDUINO for the Innovations ID series RFID reader several years ago and even after all this time I still get queries and it still attracts 40-60 downloads a month.

I figured it was time to do it in Tachyon. I played with it a bit a couple months back with poor results. I was using SERIN and trying to do some of the parsing on the fly. I was spinning my wheels ... so I put it aside. In the interim I pondered some advice that Peter had given me about the RTC. It went something like "... dump all the RTC registers to RAM ... THEN ... process the data." I scrapped 90% of what I had done and concentrated on getting 16 bytes from RFID chip to RFID reader to Prop Hub RAM ... accurately! I got that right on the first try so all that was left was support, display, etc words.

One thing that you need to understand is that a given family of RFID tags, in this case the EM4000 used by Innovations ID series and the Parallax 28140/28340/28440 from Joe Grand has a fixed format for its ID number, BUT the output of each reader, while containing the ID in recognizable form may vary in its START//STOP bytes, may or may not have a checksum, etc


This is the layout of the Innovations ID Series


[STX] [Data (10 ASCII)] [CHECKSUM (2 ASCII)] [CR] [LF] [ETX]

16 BYTES TOTAL
STX (0x02) - Start Transmission
Data 10 ASCII-HEX characters "0"-"9"/"A"-"F"
CHECKSUM - break data to five 2 byte pairs each rep-
resenting a byte and XOR
CR (0x0D) - carriage return
LF (0x0A) - linefeed
ETX (0x03) - End Transmission

This is the Parallax readers

[START] [Data (10 ASCII)] [STOP]

12 BYTES TOTAL
START (0x0A) - linefeed
Data 10 ASCII-HEX characters "0"-"9"/"A"-"F"
STOP (0x0D) - carriage return


The code below is simple enough to adapt to any reader's output format. Then go and grab Peter's RFID.fth, which is setup for the Parallax reader, but has a more complete user application.

I seem to remember that some one had re-written SERIN to be non-blocking, that is you call SERIN with a time out parm. Can someone tell me where to look?

Peter, can you explain how the second parameter to ADO works when you have a "2 +LOOP" Look at my code word ID12cksum.

TACHYON

: RFID_ID12.fth 	." RFID Innovations ID12 ToolKit - 20130908.1830" ;


BYTE IDbuf $20 ALLOT

#P9	CONSTANT 	IDpin	

#9600  SERBAUD		\  Innovations ID-12 runs at 9600,8,n,1

:	IDpin!		( serpin -- )	' IDpin 1+  ! ;

:	decodehex	( ch -- val)
		DUP  "0" "9" WITHIN IF "0" - EXIT THEN
		DUP  "A" "F" WITHIN IF $37 - EXIT THEN
		;

			\  Read the RFID reader ... uses stock, unmodified SERIN. SERIN
			\  will block anything while waiting for each of 16 bytes
			\  received bytes directly placed in buffer

:	ID@			( bufadr -- )	#16 ADO IDpin SERIN I C! LOOP ;

			\  EM4000 series RFID chips send 10 HEX digits which must be
			\  paired to make 5 bytes which have to be XORed for the 
			\  checksum

:	MAKEHEX		( addr -- hexlong )
		DUP		C@  decodehex $10 *
		SWAP 1+ C@  decodehex + 
		;
	
			\  0 XOR number = number ... so we 'prime' the loop with 0
			\  watch out for ADO in the "2 +LOOP" mode. 9 doesn't yield
			\  9 iterations, rather 5 .... I = 1, 3, 5, 7, 9
			
:	ID12cksum	( bufadr -- chksum )
		0  SWAP 1+ 9 ADO I MAKEHEX  XOR 2 +LOOP ;

:	.ID12	( bufadr -- )
		." - ID read [ " 1+ 9 ADO I MAKEHEX .BYTE  SPACE  2 +LOOP "]" EMIT ;

:	ID12cksumValid?	( bufadr -- flag )
		DUP  ID12cksum  SWAP #11 + MAKEHEX = ;


\  Shortcuts and example uses

:	IDB	( -- ) 	IDbuf $20 DUMP ;	\  dump i/o buffer

:	IDD	( -- )	IDbuf ID12cksum ;	\  compute checksum of ID

:	IDI	( -- )	IDbuf ID@ ;			\  wait for 16 byte ID strong

:	IDQ	( -- )		\  SIMPLISTIC APP - get ID, validate the checksum, display
				CR CR	#9600 SERBAUD
				BEGIN
					IDbuf  DUP  DUP  ID@ CR .DATES SPACE .TIME SPACE .ID12 SPACE
					ID12cksumValid? IF ." -< VALID >- " ELSE ." **Invalid** " THEN ." Checksum " CR 
				KEY? UNTIL
				DROP
				;	
END

[max72]

Thanks!
For both posts..

Massimo

[Peter Jakacki]

I have an application where my Prop is part of another board and only has 20ma allocated for it so I need to observe this. So I've added some clock mode instructions as well as COGSTOP and by stopping 6 cogs and still running the serial RX cog and the Tachyon console the current drops down to 28ma. If I execute a 2 CLK instruction (0=x1 1=x2 2=x4 3=x8 4=x16) to take my 10MHz crystal down to x4 XTAL mode the current drops to 15ma, well within the allocation. So I tried a couple of other modes too and these are the results:

CRYSTAL	MODE	FREQ	COGS	CURRENT	TACHYON CODE
10MHz	XTAL8	80MHz	8	65ma
10MHz	XTAL8	80MHz	2	28ma	STANDBY
10MHz	XTAL4	40MHz	2	15ma	STANDBY 2 CLK
10MHz	XTAL2	20MHz	2	8.4ma	STANDBY 1 CLK
10MHz	XTAL1	10MHz	2	5.2ma	STANDBY 0 CLK
10MHz	XTAL1	10MHz	8	9.8ma	0 CLK
	RCFAST	~!2MHz	8	9.2ma	RCFAST
	RCFAST	~12MHz	2	2.2ma	STANDBY RCFAST
	RCSLOW	~20kHz	8	215ua	RCSLOW
	RCSLOW	~20kHz	2	205ua	STANDBY RCSLOW
	RCSLOW	~20kHz	2	130ua*	1 1 TEMP! STANDBY RCSLOW

BTW, the hardware configuration is a AT30TS750 I2C temperature sensor, a 24LC512 EEPROM and a W25Q80 SPI Flash. The 3.3V regulator quiescent current accounts for around 50ua.
*EDIT: Added figure for putting temperature sensor into standby.
EDIT: Noting how WAITCNT (used by ms) saves power I have added a 32ms wait within the IDLE task loop - this reduces normal power down from 65ma to 23ma (CONSOLE,TIMING, and SERIAL cogs running)

[Peter Jakacki]

I don't know how useful this might me to others but I wanted to detect ambient light levels on a board using just it's status indicator LED. On this board it just happens to be a tiny 0805 yellow amber LED tied to ground through a 1K resistor. An LED can generate a voltage at very minute current levels if you can shine a bright enough light into it. So therefore just by monitoring an LED as an input you will read a high on a grounded LED if there is a strong light shone into it. To make it more sensitive without any hardware modifications we simply pulse the LED briefly then float it. The capacitance of the circuit will mean that we can read back a high that will discharge quickly before reading a low but how fast it discharges depends upon the amount of ambient light. So by using the system counter and a WAITPNE instruction we can measure this interval and detect bright light and the level of it.

Here's the code in Tachyon Forth but it should be very easy to write in Spin or PASM etc.

\ Measure ambient light using LED (grounded).

\ Pulse the LED briefly to bias it, float it, then read back how long it takes to turn off
pub LED@ ( pin -- val )
    MASK DUP OUTSET DUP INPUTS CNT@ SWAP WAITPNE CNT@ SWAP -
    ;

\ Poll the LED for ambient light and when detected then just flash the same LED 
pub DEMO
    $1000                                               \ init a black level (much higher than any normal reading)
     BEGIN 
       #50 ms #P3 LED@ DUP 4 SHR CR FOR "*" EMIT NEXT   \ Simple text graph of ambient light level
       SWAP OVER MIN SWAP OVER $20 + >                  \ Update black level and look for anything above noise level ($20)
       IF #P3 PINSET THEN                               \ Flash the LED back to indicate light detected 
     AGAIN
     ; 

[Brian Riley]

I asked Peter if he had any code for the ADC124S021 A2D on the Prop Activity Board. He looked over the specs and whipped me up a !ADC word and a ADC@ word. I took them and adapted the supporting display/scaling words.

Using a 9v battery with a pot as my variable supply and a good DMM I tested the whole 0-5 range and never had a discrepancy greater than 3 1/100ths. Most of the time the reading was 2 1/100ths lower than the DMM and zero was zero.

Here's the code. It replaces the ADC code in EXTEND.fth ... enjoy

cheers ... BBR

[Brian Riley]

I wish I knew what went wrong. Throughout this whole investigation the troubles came from a copy of Peter's file in which I made but a single change, @rtc, the chip address. Now it all works.

I moved over the TIME! and DATE! words of Peter's code and cleaned up a few things.

[Peter Jakacki]

I2CBUS was what tipped me off to the discrepancy.

Below is a snippet from MCP79410.fth from your webpage. TIME! and DATE! are your setting words ... they both look to me like they are writing a long to rtcbuf and the resulting write location was 'off'' by the 2 bytes shift of whatever-Endian byte order.

pub TIME! ( $hh.mm.ss -- ) \ write time in bcd format
        $2000.0080 OR rtcbuf ! WRRTC
        ;
\ Usage: $130630 DATE! \ set the date to the 30th June 2013
pub DATE! ( $yy.mm.dd -- )
        rtcbuf 4 + ! WRRTC
        ;

If I am wrong, please show me where. I would much rather use your "$110400 TIME!" than my "$11 $04 $00 TIME!"

Just because it is passed as a long doesn't mean it is written as a long or can be. Surely time should be a single parameter with each byte of the long representing hh mm ss. A simple L>W to split the long into two words and then W>B operations to extract the bytes which are then written sequentially using the chip's automatic register autoincrement.

P.S. remember that the DS32 doesn't have those other bit flags mixed up with the time.

[Brian Riley]

From my post #817

So I checked the datasheet again and it is supposed to be $D0 so I don't know why I typed $B0, I suppose just to get you to check the datasheet yourself I guess! BTW, an I2CBUS command would have revealed the device address anyway. There is no writing of longs, only a sequence of bytes which are acknowledged by the RTC after which it autoincrements its register pointer. I will order some of these chips and test them myself though.

I2CBUS was what tipped me off to the discrepancy.

Below is a snippet from MCP79410.fth from your webpage. TIME! and DATE! are your setting words ... they both look to me like they are writing a long to rtcbuf and the resulting write location was 'off'' by the 2 bytes shift of whatever-Endian byte order.

pub TIME! ( $hh.mm.ss -- ) \ write time in bcd format
        $2000.0080 OR rtcbuf ! WRRTC
        ;
\ Usage: $130630 DATE! \ set the date to the 30th June 2013
pub DATE! ( $yy.mm.dd -- )
        rtcbuf 4 + ! WRRTC
        ;

If I am wrong, please show me where. I would much rather use your "$110400 TIME!" than my "$11 $04 $00 TIME!"

[Peter Jakacki]

Here's a project I just did for a local client that uses Tachyon. Since it's only a small and simple project I can share some details of it with the forum. Basically it's a pump control unit with large LCD screens mounted in a factory area where the operators can see the display from a distance as they move through the factory floor with a very long hose from machine to machine. Other monitors can be added easily without any configuration necessary. Tachyon is running on a small DIN rail control unit and communicating with the displays over RS485. Each display has a small Prop board (Pixie) plugged directly into the back of the monitor as shown and can have a keypad plugged directly into each monitor. The Pixies are interconnected via a multidrop 4-core phone cable which provides power for the Pixies as well. I tested multiple units over 100 metres of cable without a single hitch. This is connected back to a high-pressure pump unit where the master Prop resides and connects to encoders and pressure sensor and control valve solenoid.

The main application program is totally written in Tachyon Forth without any assembly and consumes less than 4K of code space despite the fact that I have a lot of diagnostic messaging built in over Bluetooth. Each monitor can have a keypad which the control application reads directly over RS485 and writes to the the Pixie's 512x384 tiled bitmap driver. A cog task continually checks the encoder inputs and processes these as well. There are also 12 bicolor LEDs via shift registers on the control unit that are continually updated from the main code, the write update time is 21us for 24 bits (12 LEDS).

What does the code look like? I'll just share one tiny snippet for the moment which updates the machine number when it's in the run mode (vs program mode):

pub .MACHINE ( n -- )
    MSG ." MACHINE " DUP .DEC                                   \ Echo diagnostics to console
    YELLOW PEN BLACK PAPER 0 1 9 #10 PAINT                      \ paint tiles in machine number area x y xwidth ywidth
    9 #11 SIZE 0 0 @XY 1+ .DIGITS                               \ Large digits
    NORMAL PRESSURE? IF GREEN ELSE RED THEN PEN BLACK PAPER     \ Reflect pressure status in machine title
    0 #10 8 1 PAINT                                             \ paint tiles for title
    #50 #158 @XY ." MACHINE "                                   \ display title
    CON                                                         \ return I/O to console in case we run interactively
    ;

Here's another where the keypad codes are processed:

pub [KEYPAD]
     >B SWITCH
      $1B     CASE step ~ [HOLD]  BREAK       \ HOLD START/STOP
     "/"    CASE [SET] BREAK
     "*"    CASE [RECALL] BREAK    
     "-"    CASE [STEP-] BREAK                \ step down
     "+"    CASE [STEP+] BREAK                \ step up
     8    CASE [CE] BREAK                     \ clear entry
     ^M     CASE [ENTER] LIST_STATS BREAK
     "."    CASE [CLEAR] BREAK
     BL     CASE [STEP0] BREAK
       \ numeric key
     SWITCH@ $30 $39 WITHIN IF SWITCH@ NUMERIC BREAK
     ;

Bench shots (I/O module missing)

[Peter Jakacki]

Not too long ago Peter suggested that the DalSemi RTC, DS-3231, should work with his code for the Microchip MCP79410. Well ... he wasn't quite right .. but far more right than wrong ... first of all the DS-3231 has an I2C address of $D0 not $B0! When I notice this I remembered that the DS1307 had the same address and the register configuration looked the same. So I re-booted and loaded the RTC code for the DS1307 that I posted last December, with no changes of any kind! It all worked with no problems of any kind.

Now back to Peter's MCP79410 code ... I pulled the backup battery so I would be starting fresh and after replacing the battery I set Date and Time. When I went to print time and/or date it all blew up forcing a reboot and cyber-vomit on the console screen.

I checked a few things and I suspect what initially seemed like a terribly clever idea .... writing to the RTC buffer a long at a time rather than 4 byte write commands when setting hrs/mins/secs or yr/mon/day. I think that long write is getting caught up in that Little Endian / Big Endian byte order thingy. When I have more time this weekend, I'll look to confirm my suspicions.

Any way. I rewrote a lot of my DS1307 code borrowing liberally from some of Peter's code. This module will do either chip ... the venerable old DS1307 or the slick new DS3231.

The DS3231M at eight dollars plus in quantity 1-9 is not cheap but it has aTXCO resonator onboard and its rated 5 ppm accuracy. It will run on 2.9 to 5.5 v and tolerate 5v pull-ups even when Vcc is 3.3v . It comes in 8 or 16 pin SOIC. ( I soldered two them to Sparkfun 8 pin SOIC Breakout boards yesterday. It took me under 10 minutes for the two, including 2 4 pin male headers per board. If I can do that despite the shakes from Parkinson's most of you should be able to handle it.)

I have attached the code and the DS3231 Data Sheet

cheers .... BBR

From my post #817

The DS3231 is compatible enough with the MCP79410 that you should be able to use it as is, just change the device address. The first 7 registers are compatible although the 79410 does uses some of the otherwise unused bits for control purposes but that won't affect the 3231. Try it and let me know how is goes.

The device address can be changed either in the source code:
$DE == @rtc
to

$B0 == @rtc

So I checked the datasheet again and it is supposed to be $D0 so I don't know why I typed $B0, I suppose just to get you to check the datasheet yourself I guess! BTW, an I2CBUS command would have revealed the device address anyway. There is no writing of longs, only a sequence of bytes which are acknowledged by the RTC after which it autoincrements its register pointer. I will order some of these chips and test them myself though.

What I like to see standardized between RTC chips is the read and write methods and formats for time and date. I like the BCD method as that is normally how RTC chips handle the data. So to set the time to 1:35PM it becomes $13:35:00 TIME! Printing the time and date become simple operations too.

[Brian Riley]

Not too long ago Peter suggested that the DalSemi RTC, DS-3231, should work with his code for the Microchip MCP79410. Well ... he wasn't quite right .. but far more right than wrong ... first of all the DS-3231 has an I2C address of $D0 not $B0! When I notice this I remembered that the DS1307 had the same address and the register configuration looked the same. So I re-booted and loaded the RTC code for the DS1307 that I posted last December, with no changes of any kind! It all worked with no problems of any kind.

Now back to Peter's MCP79410 code ... I pulled the backup battery so I would be starting fresh and after replacing the battery I set Date and Time. When I went to print time and/or date it all blew up forcing a reboot and cyber-vomit on the console screen.

I checked a few things and I suspect what initially seemed like a terribly clever idea .... writing to the RTC buffer a long at a time rather than 4 byte write commands when setting hrs/mins/secs or yr/mon/day. I think that long write is getting caught up in that Little Endian / Big Endian byte order thingy. When I have more time this weekend, I'll look to confirm my suspicions.

Any way. I rewrote a lot of my DS1307 code borrowing liberally from some of Peter's code. This module will do either chip ... the venerable old DS1307 or the slick new DS3231.

The DS3231M at eight dollars plus in quantity 1-9 is not cheap but it has aTXCO resonator onboard and its rated 5 ppm accuracy. It will run on 2.9 to 5.5 v and tolerate 5v pull-ups even when Vcc is 3.3v . It comes in 8 or 16 pin SOIC. ( I soldered two them to Sparkfun 8 pin SOIC Breakout boards yesterday. It took me under 10 minutes for the two, including 2 4 pin male headers per board. If I can do that despite the shakes from Parkinson's most of you should be able to handle it.)

I have attached the code and the DS3231 Data Sheet

cheers .... BBR

[Peter Jakacki]

Hi Peter.

So, any chance of a Forth word that will load some PASM code into a Cog and then allow access via parameters ...
There is some clever PASM code out there I would like to interface Forth to, but the code is hundreds of longs ..

Cheers,
B.

PS. Thought I'd ask as the thread has gone a bit quite ..

I may put a coginit instruction in there but you can also use the LOADMOD instruction but specify a count >24 and it will load into address 0 of the current cog and automatically run from there once loaded.Normally LOADMOD just loads into the reserved module area which is limited to 24 longs. Use the Google version for this though, it's also the one with the newer serial driver I'm still playing with that is optimized for 100% burst throughput at 2M baud (and counting).

[bmentink]

Hi Peter.

So, any chance of a Forth word that will load some PASM code into a Cog and then allow access via parameters ...
There is some clever PASM code out there I would like to interface Forth to, but the code is hundreds of longs ..

Cheers,
B.

PS. Thought I'd ask as the thread has gone a bit quite ..

[caskaz]

Thanks Peter.
I downloaded TACHYON-V2.1.spin.

[Peter Jakacki]

Hi Peter.
Thanks.

But it takes very much time to display webpage( formatted Google document) under my PC.
So it seems it very very very much time to copy code.
I gave up to copy them on the way.
Maybe because my PC is old and internet is poor.

Cannot you upload TACHYON kerenel source as spin.file?

Although Google docs works well it does need a decent internet connection and/or PC but as mentioned there are the plain text and Spin files in the dropbox section so just click on the link in my signature at the bottom of this post.

[caskaz]

Hi Peter.
Thanks.

But it takes very much time to display webpage( formatted Google document) under my PC.
So it seems it very very very much time to copy code.
I gave up to copy them on the way.
Maybe because my PC is old and internet is poor.

Cannot you upload TACHYON kerenel source as spin.file?

[Peter Jakacki]

Peter, fellow Tachyonists

I need your help -
I am getting frustrated, feeling alone in this Tachyon world and need somebody to talk to me ...
-- there are many C-People around that I could easily team up with ... but that is not what I want .. yet

I posted a number of messages here, to show what I am experimenting in the hope to get some feedback,
have some discussion or even find a fellow Tachyon / Forth / Propeller newcomer to share the learning curve,
but with little/no resonance. (thanks Peter for the fast response to nRF24L01)

So, what are you working / playing with Tachyon?
What are your interrests, your experiments, your findings?

I was thinking of a project thread like:

"The unofficial TACHYON documentation project"
since I am going through the Tachyon.spin and Extend.fth code for myself adding comments to better understand what Peter is doing there.
Maybe others would be interrested in s.th. like this as well.
But of course, since I am new to this world, maybe / surely some of my guesses are wrong.
collaborating on it could be a great learning experience.
Of course Peter could do this - but he probably better spends his time on V3 and all the big new stuff like FAT32 ...
as he does.
What makes it difficult though is the moving target, repeatedly merging new Tachyon versions with my commented previous version.

I also started to scan this big thread for gems and extract those to a separate document ...
Of course some of the posts are outdated and superceeded by new versions of Tachyon,
but sometimes still give valuable insight in how this system evolved to how it is now.

so ... waiting for some response ...

Markus from Germany

here some of my experiments:

HEX Strings to byte strings

Re: Strings - COMMENTED

http://forums.parallax.com/showthrea...91#post1197891
TACHYON - circular byte buffer words

evaluate the FORTH sentence in a null-teminated string

http://forums.parallax.com/showthrea...27#post1197527

The nRF24L01 project will continue hopefully soon, when I am done with my relocation and the modules arrive.
http://forums.parallax.com/showthrea...37#post1194837

Hi Markus,

I've tried to follow your post and I'm not quite sure where or what to reply to yet If it's one thing then I manage to gouge out the time to check it out and reply.

I originally wrote Tachyon because I liked using Forth and needed something that could run fast enough for me to use for real work projects. So Tachyon has not been standard in many respects and yet it's tailored for the Prop and it's peculiarities which makes it very non-standard for a non-standard processor chip (which we love). Now in saying this I'm just hoping to draw your attention to the "real work projects" phrase Yes, I have real work I need to get done and Tachyon has the speed and compactness as well as the productivity and fun that comes with it's interactive nature. So Tachyon is certainly not a test tube baby, born and bred and sheltered in a lab, sorry, it's a wild child that has to deal with the real world so what it lacks in social graces it makes up for in getting things done. When it comes across something it doesn't know how to handle then I train it, and so Tachyon grows in response, not to artificial academic stimuli but real-world needs.

So as much as I appreciate forum chat I just find my time is a little limited sometimes but I will attempt to address each of your questions, although maybe not all in one or two posts.

BTW, you are welcome to be a collaborator so you can edit and document the main Tachyon 2.1 document or any other document for that matter. At the very least you could write up your own document pages and simply link to them from the source code document.

[Peter Jakacki]

Hi.
I always read this thread.
BTW, how does TACHION install on Propeller board?
Where is install-procedure?

Hi caskaz, there is no special install procedure with Tachyon as the complete source for the kernel is on a single page, either the formatted Google document (or the webpage verison) which is always up-to-date (even as I am editing it) or the Dropbox folder version. If you use the Google document then just select all, copy and paste into your Spin tool and hit F11 to load into your board. There's only one section you might customize to suit and that's the clock and baudrate which is about 5% into the document here:

CON

_clkmode    = xtal1 + pll8x     ' <---------------- change to suit
_xinfreq    = 10_000_000        ' <---------------- change to suit your crystal


baud        = 230400        ' <-- change - tested from 300 baud to 3M baud

Once you have the compiled kernel loaded onto your board it is talking but you should paste or send the EXTEND.fth file for all the standard extras. I use Minicom with a 12ms line delay as there is no handshaking. If you look at the bottom of the Intro page (links in my sig) it will point you to the links page. Here is the main Dropbox page which I try to keep up-to-date.

[caskaz]

Hi.
I always read this thread.
BTW, how does TACHION install on Propeller board?
Where is install-procedure?

[MJB]

Peter, fellow Tachyonists

I need your help -
I am getting frustrated, feeling alone in this Tachyon world and need somebody to talk to me ...
-- there are many C-People around that I could easily team up with ... but that is not what I want .. yet

I posted a number of messages here, to show what I am experimenting in the hope to get some feedback,
have some discussion or even find a fellow Tachyon / Forth / Propeller newcomer to share the learning curve,
but with little/no resonance. (thanks Peter for the fast response to nRF24L01)

So, what are you working / playing with Tachyon?
What are your interrests, your experiments, your findings?

I was thinking of a project thread like:

"The unofficial TACHYON documentation project"
since I am going through the Tachyon.spin and Extend.fth code for myself adding comments to better understand what Peter is doing there.
Maybe others would be interrested in s.th. like this as well.
But of course, since I am new to this world, maybe / surely some of my guesses are wrong.
collaborating on it could be a great learning experience.
Of course Peter could do this - but he probably better spends his time on V3 and all the big new stuff like FAT32 ...
as he does.
What makes it difficult though is the moving target, repeatedly merging new Tachyon versions with my commented previous version.

I also started to scan this big thread for gems and extract those to a separate document ...
Of course some of the posts are outdated and superceeded by new versions of Tachyon,
but sometimes still give valuable insight in how this system evolved to how it is now.

so ... waiting for some response ...

Markus from Germany

here some of my experiments:

HEX Strings to byte strings

Re: Strings - COMMENTED

http://forums.parallax.com/showthrea...91#post1197891
TACHYON - circular byte buffer words

evaluate the FORTH sentence in a null-teminated string

http://forums.parallax.com/showthrea...27#post1197527

The nRF24L01 project will continue hopefully soon, when I am done with my relocation and the modules arrive.
http://forums.parallax.com/showthrea...37#post1194837

[MJB]

I did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)

As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..

I don't see this, since the kernel is packet very tight and little to remove to make such a big space.
But the question is if you need the COG to have a Tachyon VM at all, if you want to run specialized PASM anyhow.

[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?

there is no support currently to reload a complete COG from forth,
but have a look at VGA (commented out in tachyon.spin) to see how a PASM COG can be started from SPIN at startup
and how to communicate via HUB ram

PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......

see EXTEND.fth

[Peter Jakacki]

I can hardly wait until you guys have 128K in the prop2 for the kernel.

dp

Well there will still only be 8 cogs and each cog is limited to 512 longs or RAM but at least I have the extra stack space and efficient method of writing to hub RAM. A lot of the stuff I'm doing with V3 where the dictionary is mostly held in Flash and objects included from the library held on SD as well as binary modules loaded directly into cogs will of course be of great benefit both now and when P2 is available (this year). Making a stand-alone system then is worthwhile for P2 whereas it is not what I am interested in with trying to make P1 into something it's not except maybe with another Prop handling the video at least.

[D.P]

I did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)

As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..
[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?

PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......

I can hardly wait until you guys have 128K in the prop2 for the kernel.

dp

[bmentink]

in the Tachyon.spin file just search for RUNMOD and you will find Peter's reloadable PASM modules, which are great examples of how to do it.
Including passing parameters to them via COGREGS
The size of each module is restricted, but the comments about the max length vary from 16 to 24 longs / PASM inctructions.
But if you could live without some of the kernel features this could be made a little larger.
Problem is to understand what could be removed without breaking the kernel.

I did see the RUNMOD and LOADMOD functions, but as they only allow PASM of 16 LONGS, I could not see how to use it to implement the PWMx8 module as that is more like 134 LONGS and 80 VARIABLE longs. (according to the BST tool)

As you say, we need guidance from Peter as to how to make room in the kernel, so we can add bigger PASM modules ..
[EDIT] Or do we have a Forth word that allows a custom (non Forth) COG to be loaded with PASM, that interfaces to other COG's running Forth?

PS: I looked up the word COGREGS in the kernel, it shows it in the WORDS list, but I see no code for it ......

[MJB]

I am trying to have a way to specify a HEX-string, that is converted to a byte-string and stored as a STRING.

The following converts a " FF13BE3C" hex string literal to a byte string of length.
But when I want to convert it into a STRING it breaks ...

\ some extensions fur local variables
pub X1!                                locals ! ;  ok
pub X2!                                1 @X ! ;  ok
pub X3!                                2 @X ! ;  ok
pub X4!                                3 @X ! ;  ok
  ok
  ok
\ ======== Hex String to Byte String ==================================
pub "2$ ( strPtr -- StrPtr size )
 \ X1 = strAddr    string pointer to original HEX string
 \ X2 = storeAddr  pointer for writing the assembled bytes
 \ X3 = readAddr   pointer to read the hex bytes from string
 DUP DUP 3 LOCAL  \  store 3 stack elements to local vars X1..X3
 BEGIN
    X3 C@  .S \ get first hex char
    DUP 0= IF 
        0 X2 C!    \ write terminating null char
        X2 X1 -      \ length of byte string
        X1 SWAP           ( StrPtr size )
        .S 3 RELEASE EXIT
    ELSE
        >DIGIT 0= IF ( handle error )  THEN 
        4 SHL X2 C!
    THEN
    X3 1+ X3!
    X3 C@
    ?DUP 0= IF
        X1 3 RELEASE 0 EXIT
    ELSE
       >DIGIT 0= IF ( handle error )  THEN 
       X2 C@  +
       X2 C! 
       X3 1+ X3!
       X2 1+ X2!
    THEN
 AGAIN
 ;
  ok
   ok
   ok
" FF1E34A1" "2$ .S  DROP 5 DUMP
STACK: 00000000 00000000 00000004 00000046
STACK: 00000000 00000000 00000004 00000031
STACK: 00000000 00000000 00000004 00000033
STACK: 00000000 00000000 00000004 00000041
STACK: 00000000 00000000 00000004 00000000
STACK: 00000004 00000000 00002E47 00000004
STACK: 00000004 00000000 00002E47 00000004
2E47: FF 1E 34 A1 00 34 41 31 00 BA D6 BA 20 0B 7A BA    ..4..4A1.... .z.
 ok
  ok
" FF1E34A1" "2$ .S  STRING
STACK: 00000000 00000004 00000000 00000046
STACK: 00000000 00000004 00000000 00000031
STACK: 00000000 00000004 00000000 00000033
STACK: 00000000 00000004 00000000 00000041
STACK: 00000000 00000004 00000000 00000000
STACK: 00000000 00000000 00002E47 00000004
STACK: 00000000 00000000 00002E47 00000004 fs  ok
fs 7 DUMP
2E4C: FF FF 31 00 B9 D6 78 BA 23 03 03 23 03 03 00 00    ..1...x.#..#....
 ok
   ok
" FF1E34A1" "2$ STRING fs
STACK: 00000000 00000000 00000004 00000046
STACK: 00000000 00000000 00000004 00000031
STACK: 00000000 00000000 00000004 00000033
STACK: 00000000 00000000 00000004 00000041
STACK: 00000000 00000000 00000004 00000000
STACK: 00000004 00000000 00002E52 00000004 ok
fs 7 DUMP
2E54: FF FF 00 34 BA D7 78 BA 23 03 03 00 00 00 00 00    ...4..x.#.......
 ok

[MJB]

So in summary some guidelines on:
1. How to incorporate my own PASM modules into the Kernel, and how to pass parameters to/from it from Forth ..
2. I need to understand what code runs in COG memory and how it is copied there (i.e what part of the Kernel is in COG, all of it?)..

B.

in the Tachyon.spin file just search for RUNMOD and you will find Peter's reloadable PASM modules, which are great examples of how to do it.
Including passing parameters to them via COGREGS
The size of each module is restricted, but the comments about the max length vary from 16 to 24 longs / PASM inctructions.
But if you could live without some of the kernel features this could be made a little larger.
Problem is to understand what could be removed without breaking the kernel.

[bmentink]

Distillation of the video generators and advanced counter modes for mere mortals would be most welcome. Nothing beats hooking up a scope and issuing words to see the effects. Some can draw these traces in their heads by looking at the documents, not me. I'm very interested in BLDC motors and such.

Yes, I was just looking at the PWMx8 Spin/PASM module and that looks like it will do for my application (it uses the video hardware) ....
but I will need to port it into a Forth/PASM module ... understanding how it works would be awesome too ..
Peter, I guess I am coming back to my previous unanswered question: How much memory is left in the Kernel to for example, fit in the PASM code for the PWMx8 module I am referring too ... it would be good to know how we mere mortals can customize the kernel for our own needs .. e.g for the Sensorless BLDC motor control which I want to implement in Forth, I need the above PASM PWM code, some custom PASM code that implements a retriggerable monostable and the rest in high level Forth ..

So in summary some guidelines on:
1. How to incorporate my own PASM modules into the Kernel, and how to pass parameters to/from it from Forth ..
2. I need to understand what code runs in COG memory and how it is copied there (i.e what part of the Kernel is in COG, all of it?)..
3. Some tuition on the COG high speed timers and video ..

All the above will help tremendously in implementing a Sensorless BLDC controller in Forth .. which will then of course be returned back to you complete, for sharing with everyone ..

Cheers,
B.

[D.P]

That would be cool .. thanks Peter

Distillation of the video generators and advanced counter modes for mere mortals would be most welcome. Nothing beats hooking up a scope and issuing words to see the effects. Some can draw these traces in their heads by looking at the documents, not me. I'm very interested in BLDC motors and such.

[bmentink]

It's hard to get you Kiwi's back, you know, as most of them are over here
As for the ? I've always wondered what that meant. Seeing you had already answered the question by your phrasing I take the point as moot and no need to discuss it further unless of course you didn't understand your own question. hehe

Okay, a little bit more seriously now (if you Kiwis can handle that) I will have to look into higher frequency PWM modes using the counters or even possibly the video register. Us Aussies don't always know the answer but when we see what you Kiwis are doing wrong we figure out a better way (sorry, couldn't help it). Hey Bernie, would you like me to do up a little bit of a section in the intro page about this? Maybe you could provide some material to add as well, that'll be good. Just about to have some lunch and then I'll take a look at the counters and take some screenshots of the waveforms and write this up this afternoon. It might be an ongoing article about experiments with the counters and video etc.

That would be cool .. thanks Peter

[Peter Jakacki]

Ok, I will do the translate ...

TRANSLATION ON


the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..


the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..

He he ..

TRANSLATION OFF

It's hard to get you Kiwi's back, you know, as most of them are over here
As for the ? I've always wondered what that meant. Seeing you had already answered the question by your phrasing I take the point as moot and no need to discuss it further unless of course you didn't understand your own question. hehe

Okay, a little bit more seriously now (if you Kiwis can handle that) I will have to look into higher frequency PWM modes using the counters or even possibly the video register. Us Aussies don't always know the answer but when we see what you Kiwis are doing wrong we figure out a better way (sorry, couldn't help it). Hey Bernie, would you like me to do up a little bit of a section in the intro page about this? Maybe you could provide some material to add as well, that'll be good. Just about to have some lunch and then I'll take a look at the counters and take some screenshots of the waveforms and write this up this afternoon. It might be an ongoing article about experiments with the counters and video etc.

[bmentink]

Ah, I see, looking at your previous post I must remember you are speaking Kiwi
For instance: no example of how to access DUTY mode either ..
That was answered however if you meant how to use them rather than access them then that is a little different but DUTY mode is not the same thing as PWM which I have implemented using a dedicated cog as mentioned previously. I will have to get back to you later as Google translate doesn't handle Kiwi <-> Aussie

Ok, I will do the translate ...

TRANSLATION ON

I have managed to work out that you use the GOG! word to indirectly access these registers right?

the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..

... so to access the PHSA register I must do something like this right?

the "right?" above is asking you for confirmation, ... is my assumption correct? the "?" in Kiwi means a question , You respond with yes,no ... if no, details would be good ..

He he ..

TRANSLATION OFF

[Peter Jakacki]

Yes, I understand all of the above Peter.

But I don't want to get a pseudo duty variation by varying the pulse frequency .... I want fixed frequency and variable duty, I don't see words to do that easily in your word set ...

Now, I have seen spin examples using the PHSA/FRQA registers directly to implement this ... so I want to do the same under Forth, you havn't given an answer to my original question of how to access these registers ..
SInce the post, I have managed to work out that you use the GOG! word to indirectly access these registers right?

For example to access the FRQA Register easily you implement:
: FRQ ( n -- ) FRQA ctr C@ + COG! ;
.. which is usable after you use A or B word to setup ctr ..

... so to access the PHSA register I must do something like this right?
: PHA ( n -- ) PHSA ctr C@ + COG! ;

However, when in NCO mode, using the PHA word above does nothing, that confuses me ... the SPIN example set FRQA to 1, and adjust PHSA to implement duty cycle variation in NCO mode ..

I am lacking something in my knowledge of the counters here I feel ..

I am NOT lacking in my Forth knowledge as you have been implying, I do understand HOW to use the words you have written, it is the counters I am lacking understanding in ... ...

Thanks,
B.

Ah, I see, looking at your previous post I must remember you are speaking Kiwi
For instance: no example of how to access DUTY mode either ..
That was answered however if you meant how to use them rather than access them then that is a little different but DUTY mode is not the same thing as PWM which I have implemented using a dedicated cog as mentioned previously. I will have to get back to you later as Google translate doesn't handle Kiwi <-> Aussie

[bmentink]

Did you see the DAC! word in EXTEND.fth?

\ Write an 8-bit value to the pin as a duty cycle - filter output for a voltage
pub DAC! ( byte pin -- )
    DUP PINCLR APIN DUTY #24 SHL FRQ
    ;    

As you can see the output voltage is set by varying the frequency of a fixed width pulse which is a square wave at 40MHz. As you can imagine that as the frequency goes higher than this that only the off time gets shorter hence the duty cycle increases, conversely as the frequency drops the off time gets longer and the duty cycle decreases.

There are two counters per cog which is why you see CTRA and CTRB for instance but I just select either one with an A or a B word which just sets the channel variable. When you type CTR or PHS then it will be the last selected channel. CTR is a pain to manipulate directly as it;s broken up in the CTRMODE, PLL, BPIN, and APIN fields. This is where Forth does the work for you:

CTRMODE ( n -- | Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the counter )
PLLDIV ( n -- )
APIN ( pin -- | Set the APIN of the current CTR )
BPIN ( pin -- | Set the BPIN of the current CTR )

Some CTR modes have also been predefined such as NCO, DUTY, and PLL as you can see in the DAC! word.

The words MHZ KHZ HZ and MUTE just scale and set the frequency and mode of the counter. MUTE just stops the counter. So to generate a 1kHz signal on pin 14 using CTRA all we need to type is "A #14 APIN 1 KHZ" and immediately pin 14 is outputting a 1kHz square wave! Type 5 MHZ and it's generating a 5MHZ signal then if you type #16 APIN it will appear on P16 instead.

So Forth really lets you play with the counters in an easy and intuitive and interactive way.

Have you had a look at the intro page at the section entitled?
WARNING! INTERACTIVITY COUNTERS

Yes, I understand all of the above Peter.

But I don't want to get a pseudo duty variation by varying the pulse frequency .... I want fixed frequency and variable duty, I don't see words to do that easily in your word set ...

Now, I have seen spin examples using the PHSA/FRQA registers directly to implement this ... so I want to do the same under Forth, you havn't given an answer to my original question of how to access these registers ..
SInce the post, I have managed to work out that you use the GOG! word to indirectly access these registers right?

For example to access the FRQA Register easily you implement:
: FRQ ( n -- ) FRQA ctr C@ + COG! ;
.. which is usable after you use A or B word to setup ctr ..

... so to access the PHSA register I must do something like this right?
: PHA ( n -- ) PHSA ctr C@ + COG! ;

However, when in NCO mode, using the PHA word above does nothing, that confuses me ... the SPIN example set FRQA to 1, and adjust PHSA to implement duty cycle variation in NCO mode ..

I am lacking something in my knowledge of the counters here I feel ..

I am NOT lacking in my Forth knowledge as you have been implying, I do understand HOW to use the words you have written, it is the counters I am lacking understanding in ... ...

Thanks,
B.

[Peter Jakacki]

Hi Peter,

I had a look at the high level cog words like NCO and DUTY, but although I could get NCO mode working from the examples, I could see no way how to alter the duty in that mode .. and there is
no example of how to access DUTY mode either ..

Also, I see mention in the Kernel of the words PHSA/CTRA etc, but don't know how to access them to get finer control .. Is there some magic using COG@ and COG! to get to these registers?

Any help here appreciated ....

PS: I have my Prop board back now, so van have a play with the counters ..
PPS: How much kernel memory is available for me to write my own PASM functions?

Cheers,
B.

Did you see the DAC! word in EXTEND.fth?

\ Write an 8-bit value to the pin as a duty cycle - filter output for a voltage
pub DAC! ( byte pin -- )
    DUP PINCLR APIN DUTY #24 SHL FRQ
    ;    

As you can see the output voltage is set by varying the frequency of a fixed width pulse which is a square wave at 40MHz. As you can imagine that as the frequency goes higher than this that only the off time gets shorter hence the duty cycle increases, conversely as the frequency drops the off time gets longer and the duty cycle decreases.

There are two counters per cog which is why you see CTRA and CTRB for instance but I just select either one with an A or a B word which just sets the channel variable. When you type CTR or PHS then it will be the last selected channel. CTR is a pain to manipulate directly as it;s broken up in the CTRMODE, PLL, BPIN, and APIN fields. This is where Forth does the work for you:

CTRMODE ( n -- | Writes to the CTRMODE field of the current CTR channel without disturbing the other bits of the counter )
PLLDIV ( n -- )
APIN ( pin -- | Set the APIN of the current CTR )
BPIN ( pin -- | Set the BPIN of the current CTR )

Some CTR modes have also been predefined such as NCO, DUTY, and PLL as you can see in the DAC! word.

The words MHZ KHZ HZ and MUTE just scale and set the frequency and mode of the counter. MUTE just stops the counter. So to generate a 1kHz signal on pin 14 using CTRA all we need to type is "A #14 APIN 1 KHZ" and immediately pin 14 is outputting a 1kHz square wave! Type 5 MHZ and it's generating a 5MHZ signal then if you type #16 APIN it will appear on P16 instead.

So Forth really lets you play with the counters in an easy and intuitive and interactive way.

Have you had a look at the intro page at the section entitled?
WARNING! INTERACTIVITY COUNTERS

[bmentink]

Bernie, if you want to see what the different modes do then hook-up a scope and sit at the terminal and try the modes. It's very simple and all the words are there (in EXTEND.fth) to allow you to change things easily and of course interactively.

Hi Peter,

I had a look at the high level cog words like NCO and DUTY, but although I could get NCO mode working from the examples, I could see no way how to alter the duty in that mode .. and there is
no example of how to access DUTY mode either ..

Also, I see mention in the Kernel of the words PHSA/CTRA etc, but don't know how to access them to get finer control .. Is there some magic using COG@ and COG! to get to these registers?

Any help here appreciated ....

PS: I have my Prop board back now, so van have a play with the counters ..
PPS: How much kernel memory is available for me to write my own PASM functions?

Cheers,
B.

[Peter Jakacki]

BINARYDUMP worked fine for me ... tnx Peter.

The discussions on i/o redirection came to me today as I was editing my BBR_Extensions.fth file for the umpteenth time ... and I wondered if I could apply our ever-so-slippery "variable constant" technique to the same end result ...

#P15    CONSTANT    #SO     \ declare #SO and set default

: SO!    ( serpin -- )    ' #SO 1+ ! ;

:    LCDEMIT        #19200 SERBAUD  #SO SEROUT ;
:    LCD            ' LCDEMIT uemit W! ;

I typed

#P2  SO!  "   HELLO WORLD" .LSTR

.... it worked ... the serial LCD on Pin2 displayed the string (.LSTR word invokes LCD does a string print and returns the CONsole)

Hi Brian,
I'm scrathing my head as to why it is done this way which looks awkward plus I'm not sure what .LSTR does that's different from the normal ." word or even the .STR or TYPE$ words. However I don't really see the need for redirection unless I had multiple serial displays and that would be easy enough too. The rewritable constant is actually redundant if you see how I would handle a couple of different serial devices using SEROUT:

: LCDEMIT        #P2 SEROUT ;
\ Set baudrate for the LCD and select the txd pin used
: LCD            ' LCDEMIT uemit W! #19200 SERBAUD ;

: TTYEMIT        #P7 SEROUT ;
: TELETYPE        ' TTYEMIT uemit W! #300 SERBAUD ;

\ Test out these words
LCD ." HELLO WORLD" CON

TELETYPE ." HELLO WORLD, THIS IS " .VER CON

It's also more desirable to set the baudrate once when the output device is selected as baudrate is a redundant and time-consuming calculation that ends up repeating for every character that's sent.
If I had multiple LCDs I might add a parameter to LCD and invoke it like this:
#P2 LCD ." HELLO WORLD" #P7 LCD ." HELLO WORLD FROM ME TOO" CON

There's even this version of the LCD and TELETYPE snippet that uses a common output word that uses a variable to hold the pin.

BYTE serout
: SEROUT2        serout C@ SEROUT ;
\ Set baudrate for the LCD and select the txd pin used
: LCD            ' SEROUT2 uemit W! #19200 SERBAUD #P2 serout C! ;

: TELETYPE        ' SEROUT2 uemit W! #300 SERBAUD #P7 serout C! ;

[Brian Riley]

BINARYDUMP worked fine for me ... tnx Peter.

The discussions on i/o redirection came to me today as I was editing my BBR_Extensions.fth file for the umpteenth time ... and I wondered if I could apply our ever-so-slippery "variable constant" technique to the same end result ...

#P15	CONSTANT	#SO	 \ declare #SO and set default

: SO!	( serpin -- )	' #SO 1+ ! ;

:	LCDEMIT		#19200 SERBAUD  #SO SEROUT ;
:	LCD			' LCDEMIT uemit W! ;

I typed

#P2  SO!  "   HELLO WORLD" .LSTR

.... it worked ... the serial LCD on Pin2 displayed the string (.LSTR word invokes LCD does a string print and returns the CONsole)

[Peter Jakacki]

Peter et al.,

I need to generate a HEX file from Tachyon Forth that can be loaded and burnt to EEPROM. Which of the various "dump" words produces a bootable hex file?

TNX in advance .... cheers ... BBR

The BINARYDUMP word will dump the whole 32K less the top 32 bytes in Intel hex format with the correct Spin header checksum so you can run a HEX2BIN or equivalent on the PC end. Just make sure that the binary is named with the .binary extension so the Prop tool can handle it.

[MJB]

Peter et al.,

I need to generate a HEX file from Tachyon Forth that can be loaded and burnt to EEPROM. Which of the various "dump" words produces a bootable hex file?

TNX in advance .... cheers ... BBR

\ Adjust and dump the current Tachyon binary image in Intel hex format for conversion at the PC end to a bin file

\ The bin file should be renamed as .binary to suit the Prop tool

pub BINARYDUMP

0 $7FE0

2DUP FIXCKSUM

IDUMP

;

[Brian Riley]

Peter et al.,

I need to generate a HEX file from Tachyon Forth that can be loaded and burnt to EEPROM. Which of the various "dump" words produces a bootable hex file?

TNX in advance .... cheers ... BBR

[bmentink]

Hi Peter,

Yes of course I will do that ... just someone has stolen my Prop board for that express purpose ... to play with Forth ( a new convert) ... so I am giving him some head ..
When I get the board back I will be into it ... just thought I could get a quick answer back wile i wait ..

[Peter Jakacki]

Thanks, that makes sense .. I could not work out how it could work with a cog counter either ..
I need three of these, so guess I could use one cog to do all three in PASM as above ..



I think PWM is needed as duty mode would give some interesting motor noises as you sped up and down due to motor resonances .. I think you do need a constant frequency.
I though PWM mode (NCO mode) generated a constant frequency, with variable duty .... am I wrong?

Bernie, if you want to see what the different modes do then hook-up a scope and sit at the terminal and try the modes. It's very simple and all the words are there (in EXTEND.fth) to allow you to change things easily and of course interactively.

[bmentink]

a monoflop is very simple.
e.g.:
output is low
trigger
set output high
set timer variable / manual countdown counter with value for impuls time
looplabel
... on retrigger event reload counter variable with original value ...
djnz looplabel
set output low


using waitcnt will not work, since there must be s.th. to check for retrigger signal
so you can just use a simple tight polling loop.
I don't see how counters could be used for this.

Thanks, that makes sense .. I could not work out how it could work with a cog counter either ..
I need three of these, so guess I could use one cog to do all three in PASM as above ..

an interresting question might be:
Is PWM really needed to drive the motor - or would duty mode be useful as well?
It can be easily generated with the counters.
the important feature is to generate the appropriate average current within the time interval.
Inductivity averages it - so I wonder if the exact phase of PWM is a must have. ...???

I think PWM is needed as duty mode would give some interesting motor noises as you sped up and down due to motor resonances .. I think you do need a constant frequency.
I though PWM mode (NCO mode) generated a constant frequency, with variable duty .... am I wrong?

[MJB]

@bmentink: would something like http://obex.parallax.com/object/482 work for you (3ctrx variant)? It may need some work but everything is done inside the prop (there is at least one other implementation available).

there are some more:
http://obex.parallax.com/object/211 (looks slow)
search OBEX for PWM or MOTOR

an interresting question might be:
Is PWM really needed to drive the motor - or would duty mode be useful as well?
It can be easily generated with the counters.
the important feature is to generate the appropriate average current within the time interval.
Inductivity averages it - so I wonder if the exact phase of PWM is a must have. ...???

[MJB]

Can you elaborate with some Pseudo code on how that would work?
B.

a monoflop is very simple.
e.g.:
output is low
trigger
set output high
set timer variable / manual countdown counter with value for impuls time
looplabel
... on retrigger event reload counter variable with original value ...
djnz looplabel
set output low


using waitcnt will not work, since there must be s.th. to check for retrigger signal
so you can just use a simple tight polling loop.
I don't see how counters could be used for this.

[kuroneko]

@bmentink: would something like http://obex.parallax.com/object/482 work for you (3ctrx variant)? It may need some work but everything is done inside the prop (there is at least one other implementation available).

[bmentink]

a very simple method for gating would be setting the pins to inputs with pullup or pull downs as appropriate, while the counter-PWM continues

I don't think that would work, I need to turn those outputs on or off when they are not PWM outputs. I wonder about changing the pwm mode in a way that they go high or low?

you can easily implement a SW monoflop - if timing is sufficient.

Can you elaborate with some Pseudo code on how that would work?

Thanks,
B.

[MJB]

Hi MJB,

Thanks. I do actually need much faster PWM ... in the order of 10..15Khz, which is why I was wondering about using the Cog timers in PWM mode with complementary outputs and gating those some how,
rather than doing bit-bashing as per Peter's code ..

a very simple method for gating would be setting the pins to inputs with pullup or pull downs as appropriate, while the counter-PWM continues

My other requirement is to have a cog act as a re-triggerable mono-stable as part of the commutation side ... I wonder if that can also be done using a Cog timer.

B.

you can easily implement a SW monoflop - if timing is sufficient.

I use a COG to implement a legacy bus interface - kind a SW CPLD.
Reaction is 25 .. 50 ns for the most time critical transition.

[bmentink]

for the table driven PWM code Peter gives:

so this would work for a slow motor
and as you write, COG on/off is slow and not a good option.
Updating the PWM tables even in tha PASM version takes

which gives you a 4kHz update rate - if this is fast enough depends on your motor dynamics.

At what RPM do you run?

Adding gating to the PWM-Code module inside the Tachyon core shouldn't be to difficult.

                       org        _RUNMOD
_PWM                        mov        deltaR,tos        ' use supplied delta value from tos
                         mov        target,tos
                        add        target,cnt
                        mov        R1,#0
pwmlp              

                        mov        X,REG0        ' read base address of table
                        add        X,R1        ' add in read index
                         rdbyte        X,X
' here you can read and check a HUB variable with a gate MASK
                  rdbyte     R2,REG3     ' use e.g. REG3 to hold the gate mask HUB address for all 8 channels
                  and       X,R2                  ' mask the PWM - depending on positive or negative logic might need to be inverted
                         shl        X,REG1        ' shift up to pwmpins
                        mov        outa,X        ' update outputs
                        add        R1,#1
                        and        R1,#$FF
pwmwait          waitcnt        target,deltaR
                        jmp        #pwmlp

PWM        byte        _WORD,(@_PWM+s)>>8,@_PWM+s,_BYTE,15,XOP,xLOADMOD,EXIT    ' adapt PASM line count

Hi MJB,

Thanks. I do actually need much faster PWM ... in the order of 10..15Khz, which is why I was wondering about using the Cog timers in PWM mode with complementary outputs and gating those some how,
rather than doing bit-bashing as per Peter's code ..

My other requirement is to have a cog act as a re-triggerable mono-stable as part of the commutation side ... I wonder if that can also be done using a Cog timer.

B.

[MJB]

It took me quite some time to figure out, what STRING is really doing.
So I commented the code - hope it is right.
If not please correct somebody / Peter ...

\ commented by Markus Baer MJB ( for my understanding - hope this is correct )
pub STRING ( str max -- )                            \ Specify max size of string else use 0 for string length
        [COMPILE] GRAB                              \ execute input before STRING                   
        ?DUP 0= IF DUP STRLEN 1+ THEN SWAP   ( max str )    \ max is STRLEN+1 if max given was 0 
        codes W@ 4 ALIGN codes W! ALLOCATED ( size str )       \ make long aligned, adjust here
( since the string literal is in the place where we want to create the STRING variable, we need to save the string somewhere further up in the buffer.
CREATE not only compiles the VARB byte code, but also appends an EXIT 
because of this we can not move the string const to the final place yet,
but we need to move up 1 char more )
        HERE 5 + OVER STRLEN 1+ <CMOVE   \  move out of the way
         $80 HERE C!                                          \ set the attribute byte, first byte of the STRING header
         DUP HERE 1+ C!                                    \ store the size in the second byte of STRING header
         HERE 4 + STRLEN HERE 2+ C!             \ calc the null terminated string len and store it in third byte of STRING header
        3 ALLOT                                                 \ allocate space for the 3 header bytes, adjust here
        [COMPILE] CREATE                               \ since CREATE is immediate we need to prefix with [COMPILE]
                                                                       \ CREATE creates a variable, that returns its address to TOS
( now we need to move the string literal value to the right position replacing the EXIT byte code compiled in by CREATE, which we don't need  )    
        HERE 1+ DUP STRLEN 1+ OVER 1- SWAP CMOVE     
( now move the here pointer to the end of the string by allocating the requested length or if this was 0 then the length of the string const plus the 0 end byte.
        HERE 3 - C@ ALLOT
        ; 
IMMEDIATE    \ make this an immediate so the STRING is created direcly

reverse engineering Peter's code raises my insight, and I hope, TACHYON 3.0 will not be too different inside and I have to relearn all again ...

sorry - I just can't get the comments aligned correctly

[MJB]

No, I don't want or need 32 channels, just quoting some example code that was entirely bit bashed PASM code ...
All I need is 3Phase PWM that is gated by the commutation circuitry ..I was thinking of using a cog each for the 3 PWM, and stopping/starting cogs to gate them ..not sure if this is the best approach.

As you know BLDC is usually a six step waveform across the 3 phases, 60deg apart, and each step could be either a duty cycle controlled PWM of fully on or fully off. The commutation determines when the start of these steps happens.

So there will be 6 (3 complementary ) outputs (timers in PWM mode) and three inputs .... the three inputs really need to go through a comparator , which for the P1 looks like I will need external ones, looks like the P2 could do this with it's comparator on each pin.

So, I am going to build some interface circuitry on the Prop Proto board and would like to play around with some interfacing code and the PWM stuff ..
As far as the current PWM word, I may have some suggestions to modify it to allow gating ... that would help my application .. (instead of Cog on/off stuff)

Thanks,
Bernie

for the table driven PWM code Peter gives:

This version is set to run up to 8 channels of 8-bit PWM at 1kHz (Tested to 5kHz)

so this would work for a slow motor
and as you write, COG on/off is slow and not a good option.
Updating the PWM tables even in tha PASM version takes

New kernel module method to speed-up updates = 233us total

which gives you a 4kHz update rate - if this is fast enough depends on your motor dynamics.

At what RPM do you run?

Adding gating to the PWM-Code module inside the Tachyon core shouldn't be to difficult.

                       org        _RUNMOD
_PWM                        mov        deltaR,tos        ' use supplied delta value from tos
                         mov        target,tos
                        add        target,cnt
                        mov        R1,#0
pwmlp              

                        mov        X,REG0        ' read base address of table
                        add        X,R1        ' add in read index
                         rdbyte        X,X
' here you can read and check a HUB variable with a gate MASK
                  rdbyte     R2,REG3     ' use e.g. REG3 to hold the gate mask HUB address for all 8 channels
                  and       X,R2                  ' mask the PWM - depending on positive or negative logic might need to be inverted
                         shl        X,REG1        ' shift up to pwmpins
                        mov        outa,X        ' update outputs
                        add        R1,#1
                        and        R1,#$FF
pwmwait          waitcnt        target,deltaR
                        jmp        #pwmlp

PWM        byte        _WORD,(@_PWM+s)>>8,@_PWM+s,_BYTE,15,XOP,xLOADMOD,EXIT    ' adapt PASM line count

[bmentink]

I can't see how a 32 channel PWM could be implemented by counters or even without a cog involved. It could be possible to use the video register though for 8 channels and I'm not sure if that's been done yet but it would still need a cog dedicated to it. The present PWM runs 8-bit PWM up to around 5kHz which means it's updating every 781ns as it needs to read from a table in hub ram (slow) which can be updated by another cog. Sure you could place the table in COG RAM but how do you change it without upsetting the PWM updates? I could update the 8-bit method to read in a long each time if I want to speed it up but I'd have to time the hub access to make sure it's synchronized too.

Remember the Prop design philosopy, the cog is the peripheral, you don't have UARTs, SPI, I2C, ADC, DAC, DMA, VGA, A/V, PWM etc hardwired in, but each cog can do just that. Although each cog is a CPU, it's not necessarily THE CENTRAL processing unit and unlike prima donnas they are humble and flexible enough to be what they need to be ("be a radio"! Okay!)

BTW, Pepperjack is a very lovely red for sure but it's kinda like my baseline red Life is too short to drink cheap wine I say!

No, I don't want or need 32 channels, just quoting some example code that was entirely bit bashed PASM code ...
All I need is 3Phase PWM that is gated by the commutation circuitry ..I was thinking of using a cog each for the 3 PWM, and stopping/starting cogs to gate them ..not sure if this is the best approach.

As you know BLDC is usually a six step waveform across the 3 phases, 60deg apart, and each step could be either a duty cycle controlled PWM of fully on or fully off. The commutation determines when the start of these steps happens.

So there will be 6 (3 complementary ) outputs (timers in PWM mode) and three inputs .... the three inputs really need to go through a comparator , which for the P1 looks like I will need external ones, looks like the P2 could do this with it's comparator on each pin.

So, I am going to build some interface circuitry on the Prop Proto board and would like to play around with some interfacing code and the PWM stuff ..
As far as the current PWM word, I may have some suggestions to modify it to allow gating ... that would help my application .. (instead of Cog on/off stuff)

Thanks,
Bernie

[Peter Jakacki]

Will do ... although I had to replace the Pepperjack with a Local Merlot ..... distinct lack of Oz wines over here ....

By the way, what I am trying to do is this:

My interest is Electric Cars ... currently I am building one based on a 200HP Industrial motor running at 650V. (Biggest problem is the cost of the controller ... even when I got the power module off eBay)
That is all good, but for my next project I would like to use a BLDC motor being driven by a Prop1 (in sensorless mode) or maybe a Prop2 if I run out of resources .... seems to me I can get the cost of the controller right down ...

So I would like to start the coding based on the Prop1 and see how far I get ... and obviously I would like to do this in Tachyon Forth ..

.... So I am thinking for the 3 Phase PWM, maybe I could use 3 cogs running a low level PWM word that could be phase shifted relative to each other .... (using timers)
Another cog would interface to the sensorless circuitry (zero-crossing detector) and would self modify the phase shifting .. (phase shift is normally 60deg in a six step BLDC)
Be interested in what you think of that approach and what the best words would be to achieve the building blocks ..

NB: I have seen the 32 channel PWM code that Parallax have coded up to do this sort of thing in pure assembly, but surely we can use cog timers for this ....

Cheers,
Bernie

I can't see how a 32 channel PWM could be implemented by counters or even without a cog involved. It could be possible to use the video register though for 8 channels and I'm not sure if that's been done yet but it would still need a cog dedicated to it. The present PWM runs 8-bit PWM up to around 5kHz which means it's updating every 781ns as it needs to read from a table in hub ram (slow) which can be updated by another cog. Sure you could place the table in COG RAM but how do you change it without upsetting the PWM updates? I could update the 8-bit method to read in a long each time if I want to speed it up but I'd have to time the hub access to make sure it's synchronized too.

Remember the Prop design philosopy, the cog is the peripheral, you don't have UARTs, SPI, I2C, ADC, DAC, DMA, VGA, A/V, PWM etc hardwired in, but each cog can do just that. Although each cog is a CPU, it's not necessarily THE CENTRAL processing unit and unlike prima donnas they are humble and flexible enough to be what they need to be ("be a radio"! Okay!)

BTW, Pepperjack is a very lovely red for sure but it's kinda like my baseline red Life is too short to drink cheap wine I say!

[MJB]

circular byte buffers are a common data structure
here my attempt at a generalization of it.
comments and optimizations welcome.

 
 \ =============  BUFFER  ===========================
 \ usage  size BUFFER BufName 
pub BUFFER ( size --  
    \ create a circular buffer of size bytes, 
    \ 4 bytes size, R-index, W-index and VAR byte code preceed buffer address )
    [COMPILE] GRAB   \ force evaluation auf previous input 
    3 ALLOT          \ space for  size, Rind, Wind 
    DUP HERE 3 - C!      \ store buffer length
    HERE 2- C~       \ make sure it is 0 - maybe not needed
    HERE 1- C~       \ make sure it is 0 
    [COMPILE] CREATE   \ create a variable which returns the buffer start address
    ALLOT              \ allocate size bytes needed which are automatically 0 ??
    ;
IMMEDIATE

pub BUFEMPTY ( bufAddr -- flag ) DUP 3 - C@ SWAP 2- C@ = ;
{
#10 BUFFER mBuf
mBuf 5 - 20 DUMP
mBuf BUFEMPTY .
}
pub BUFSIZE ( bufAddr -- size ) 4 - C@ ;
{
mBuf BUFSIZE .
}
pri BUFR ( bufAddr -- rIndex ) 3 -  ;   \ address of buffer read index
pri BUFW ( bufAddr -- wIndex ) 2-  ;    \ address of buffer write index
{
mBuf BUFR .
mBuf BUFW .
}
pri BUFR@ ( bufAddr -- rIndex )  BUFR C@  ;       \  value of buffer read index
pri BUFR@@ ( bufAddr -- rByte ) DUP BUFR@ + C@ ; \  byte of buffer at read index
pri BUFW@ ( bufAddr -- wIndex )  BUFW C@ ;        \  value of buffer write index
pri BUFW@! ( wByte bufAddr --  ) DUP BUFW@ + C! ; \  store byte to buffer at write index  
{
mBuf BUFR@ .
mBuf BUFW@ .
12 mBuf BUFW@!    mBuf 4 - 20 DUMP
}
pub BUFFREE ( bufAddr -- flag ) 
    DUP BUFSIZE  ( bufAddr size )
    OVER BUFW -   ( bufAddr size-wPtr )
    SWAP BUFR +     
    ;
{
mBuf BUFFREE .
}
pub BUFFULL ( bufAddr -- flag ) BUFFREE 0= ;
{
mBuf BUFFULL .
} 
pub BUFRD ( bufAddr -- byte ) 
    DUP BUFR@@ SWAP  ( byte bufAddr ) \ get the value at buffer read pos 
    DUP BUFR C++
    DUP BUFR@ OVER    ( byte bufAddr rIndex bufAddr ) 
    BUFSIZE =  IF BUFR C~ ELSE DROP THEN   
    ;
    
pub BUFWR ( byte bufAddr --  ) 
    SWAP OVER  BUFW@!   ( bufAddr ) \ write the value to buffer at write pos 
    DUP BUFW C++ 
    DUP BUFW@ OVER    ( bufAddr wIndex bufAddr ) 
    BUFSIZE =  IF BUFW C~ ELSE DROP THEN   
    ;
{    
1 mBuf BUFWR
2 mBuf BUFWR
mBuf 4 - 20 DUMP
mBuf BUFRD .
mBuf BUFRD .

1 5 ADO I mBuf BUFWR LOOP 
mBuf 4 - 20 DUMP
3 mBuf BUFWR mBuf 4 - 20 DUMP
4 mBuf BUFWR mBuf 4 - 20 DUMP
5 mBuf BUFWR mBuf 4 - 20 DUMP
6 mBuf BUFWR mBuf 4 - 20 DUMP
17 mBuf BUFWR mBuf 4 - 20 DUMP
17 mBuf BUFWR mBuf 4 - 20 DUMP
}    
pub BUFCLR ( bufAddr -- ) \ clear buffer 
    DUP BUFR C~
    DUP BUFW C~
    DUP BUFSIZE ERASE ;
{    
mBuf 4 - 20 DUMP    
mBuf BUFCLR
mBuf 4 - 20 DUMP
}
pub BUFCNT ( bufAddr -- count ) 
    DUP BUFSIZE  ( bufAddr size )
    SWAP BUFFREE -
    ;
{
mBuf BUFFREE . 
mBuf BUFCNT .
}

[bmentink]

COG memory is very limited and Tachyon squeezes the VM and stacks in there and there's no room really left over for specialized operations that really require PASM. That's where RUNMOD comes in as I sacrifice 16 to 24 longs for specialized modules which are compiled to run at that address but only one module can be loaded at a time. These specialized modules include SPI, I2C, SD, and PWM etc. The PWM module is designed to run in it's own cog as it's an endless loop where another cog/task can control the parameters. Of course the PWM cog doesn't need all the Tachyon VM in it after that but it's easy to load the module in the normal fashion.

So PWM doesn't use the counters, only WAITCNT but you mentioned PWM in your list which is different to duty-cycle modulation ( fixed pulse width, variable frequency).

As for your head hurting can I suggest a Pepperjack Cab Sav. If that doesn't work then increase the dose.

Will do ... although I had to replace the Pepperjack with a Local Merlot ..... distinct lack of Oz wines over here ....

By the way, what I am trying to do is this:

My interest is Electric Cars ... currently I am building one based on a 200HP Industrial motor running at 650V. (Biggest problem is the cost of the controller ... even when I got the power module off eBay)
That is all good, but for my next project I would like to use a BLDC motor being driven by a Prop1 (in sensorless mode) or maybe a Prop2 if I run out of resources .... seems to me I can get the cost of the controller right down ...

So I would like to start the coding based on the Prop1 and see how far I get ... and obviously I would like to do this in Tachyon Forth ..

.... So I am thinking for the 3 Phase PWM, maybe I could use 3 cogs running a low level PWM word that could be phase shifted relative to each other .... (using timers)
Another cog would interface to the sensorless circuitry (zero-crossing detector) and would self modify the phase shifting .. (phase shift is normally 60deg in a six step BLDC)
Be interested in what you think of that approach and what the best words would be to achieve the building blocks ..

NB: I have seen the 32 channel PWM code that Parallax have coded up to do this sort of thing in pure assembly, but surely we can use cog timers for this ....

Cheers,
Bernie

[D.P]

I'm starting to get close to finishing the FAT32 file support, I've just been getting my head around where everything is and how it works by Googling bits of information and interacting with the code and card to check it all out. I know a FAT32 driver has been written but I haven't referenced it at all which may sound a bit odd seeing that the code is all there. The thing is I would have to get my head around the code and I'd much rather get my head around FAT32 and SDHC cards themselves, that way I can produce a nice clean interface and so far it's been working out that way. The code size is under 1.5K at present and probably will not increase too much more. Here's a capture of a quick session I did in mounting a card, checking the card info and performing a couple of operations on it and even accessing a file as virtual memory (me in red).

MOUNT 
655F_06B0: SYSLINUX  FAT32   
Sectors = 7,725,056 ok
SD 
Card inserted 
MFG                 27
OEM                 PH
Product ID          SD04G
REV                 20
S/N                 655F06B0
DATE                2011/4
CRC                 5B
  CSD REGISTER      
*SDHC CARD* 
TACC                100ns
NSAC                0bps
TRANS               50MHz
BLKLEN              512
SIZE                3,775 Mbytes
________________
 ok
ls 
UBNKERN .        UBNINIT .        UBNPATHL.TXT     AUTORUN .INF     MD5SUM  .TXT     UBNFILEL.TXT     LDLINUX .SYS     SYSLINUX.CFG 
MENU    .C32      ok
DIR 

UBNKERN .    .....a 00004040    27/01/2012 20:44:04   4,658,096
UBNINIT .    .....a 00006400    27/01/2012 20:44:06   20,068,855
UBNPATHL.TXT .....a 0000FFC0    07/02/2012 11:37:06   87
AUTORUN .INF .....a 00010140    09/11/2011 00:59:44   170
MD5SUM  .TXT .....a 0024AE80    27/01/2012 20:49:54   12,511
UBNFILEL.TXT .....a 0024AF40    07/02/2012 11:41:36   5,866
LDLINUX .SYS rhs..a 0024AF80    07/02/2012 11:41:36   32,256
SYSLINUX.CFG .....a 0024AFC0    07/02/2012 11:41:42   1,107
MENU    .C32 .....a 0024B000    07/02/2012 11:41:42   56,164 ok
cat AUTORUN.INF...opened at 00010140
[autorun]
open=mint4win.exe --cdmenu --skipmd5check
icon=mint4win.exe,0
label=Install Linux Mint

[Content]
MusicFiles=false
PictureFiles=false
VideoFiles=false
  ok
OPEN SYSLINUX.CFG...opened at 0024AFC0  ok
@FILE XADR 80 DUMP 
7600: 64 65 66 61 75 6C 74 20 6D 65 6E 75 2E 63 33 32    default menu.c32
7610: 0A 70 72 6F 6D 70 74 20 30 0A 6D 65 6E 75 20 74    .prompt 0.menu t
7620: 69 74 6C 65 20 55 4E 65 74 62 6F 6F 74 69 6E 0A    itle UNetbootin.
7630: 74 69 6D 65 6F 75 74 20 31 30 30 0A 0A 6C 61 62    timeout 100..lab
7640: 65 6C 20 75 6E 65 74 62 6F 6F 74 69 6E 64 65 66    el unetbootindef
7650: 61 75 6C 74 0A 6D 65 6E 75 20 6C 61 62 65 6C 20    ault.menu label 
7660: 44 65 66 61 75 6C 74 0A 6B 65 72 6E 65 6C 20 2F    Default.kernel /
7670: 75 62 6E 6B 65 72 6E 0A 61 70 70 65 6E 64 20 69    ubnkern.append i
 ok

Can't wait but I will.

Perfect for logging, writing and running profiles for my Tachyon/Forth machine.

Will this be available in V2.1? or 3.x only?

Pre thanks Peter.

[MJB]

since Peter was busy I continued my experiments and now I understand partly,
why it could only work in this special case.
I am revectoring KEY via ukey to read from a string.
which can only work at the end of the input line, when the input loop comes back to calling KEY again.

@Peter
based on your new STRING words I wanted to build an EVAL
which works - almost fine.

BUT:
1. maybe it would be better to suppress the echo of the evaluated string and show just the result
(could be done using NULLOUT & CON see below )

2. if used multiple times in one line or inside a loop, only the last EVAL seems to get executed.

seems I still miss s.th. important

\
pub (EVALSTR) ( strAddr -- )
         C@++ DUP 0= IF DROP ukey W~ $0D THEN ;  ok
           ok

pub EVAL ( strAddr -- \ evaluate the FORTH sentence in the null-teminated string starting at strAddr )
  ' (EVALSTR) ukey W! ;   ok

{ without output 
pub (EVALSTR) ( strAddr -- )
         C@++ DUP 0= IF DROP CON $0D THEN ;   
          \ just deliver one char after the other, on last one add $0D to get it executed and set reader back to CONsole

pub EVAL ( strAddr -- \ evaluate the FORTH sentence in the null-teminated string starting at strAddr )
    NULLOUT  \ suppress output 
    ' (EVALSTR) ukey W! ;  
}

" 1 1 + . " EVAL   ok
1 1 + .  2 ok
" 2 2 + . " EVAL   ok
2 2 + .  4 ok

" : TT1 $17 . ; " $20 STRING TESTSTR   ok
TESTSTR EVAL  ok
: TT1 $17 . ;   ok
TT1 17 ok
  ok

\ let's define a WORD, that generates other words ...  ( I worked many years with LISP ;-) - so I love EVAL )
: TTT
0 6 ADO  "0" I + TESTSTR 4 + C! "0" I + TESTSTR 8 + C! TESTSTR .STR CR TESTSTR EVAL LOOP
;  ok
  ok
TTT : TT0 $10 . ;
: TT1 $11 . ;
: TT2 $12 . ;
: TT3 $13 . ;
: TT4 $14 . ;
: TT5 $15 . ;
 ok
: TT5 $15 . ;   ok

so I tried the following modifications, which at least seem to work on the input line.
But it is still not possible to put this inside a loop or definition of a word.
in other words - I can not compile it.
Since now I had to define EVAL as IMMEDIATE to work at least this far.

pub (EVALSTR) ( strAddr -- )
         C@++ DUP 0= IF DROP CON  $0D  THEN   ;  
          \ just deliver one char after the other, on last one add $0D to get it executed and set reader back to CONsole

pub EVAL ( strAddr -- \ evaluate the FORTH sentence in the null-teminated string starting at strAddr )
      [COMPILE] GRAB
    \  NULLOUT  \ suppress output
    ' (EVALSTR) ukey W! ; 
IMMEDIATE    

    " 1 1 + . " EVAL  " 2 2 + . " EVAL  " 3 3  + . " EVAL 1 1 +

I assume I need to take a completely different approach for EVAL to do what I imagine.

[Peter Jakacki]

I'm starting to get close to finishing the FAT32 file support, I've just been getting my head around where everything is and how it works by Googling bits of information and interacting with the code and card to check it all out. I know a FAT32 driver has been written but I haven't referenced it at all which may sound a bit odd seeing that the code is all there. The thing is I would have to get my head around the code and I'd much rather get my head around FAT32 and SDHC cards themselves, that way I can produce a nice clean interface and so far it's been working out that way. The code size is under 1.5K at present and probably will not increase too much more. Here's a capture of a quick session I did in mounting a card, checking the card info and performing a couple of operations on it and even accessing a file as virtual memory (me in red).

MOUNT 
655F_06B0: SYSLINUX  FAT32   
Sectors = 7,725,056 ok
SD 
Card inserted 
MFG                 27
OEM                 PH
Product ID          SD04G
REV                 20
S/N                 655F06B0
DATE                2011/4
CRC                 5B
  CSD REGISTER      
*SDHC CARD* 
TACC                100ns
NSAC                0bps
TRANS               50MHz
BLKLEN              512
SIZE                3,775 Mbytes
________________
 ok
ls 
UBNKERN .        UBNINIT .        UBNPATHL.TXT     AUTORUN .INF     MD5SUM  .TXT     UBNFILEL.TXT     LDLINUX .SYS     SYSLINUX.CFG 
MENU    .C32      ok
DIR 

UBNKERN .    .....a 00004040    27/01/2012 20:44:04   4,658,096
UBNINIT .    .....a 00006400    27/01/2012 20:44:06   20,068,855
UBNPATHL.TXT .....a 0000FFC0    07/02/2012 11:37:06   87
AUTORUN .INF .....a 00010140    09/11/2011 00:59:44   170
MD5SUM  .TXT .....a 0024AE80    27/01/2012 20:49:54   12,511
UBNFILEL.TXT .....a 0024AF40    07/02/2012 11:41:36   5,866
LDLINUX .SYS rhs..a 0024AF80    07/02/2012 11:41:36   32,256
SYSLINUX.CFG .....a 0024AFC0    07/02/2012 11:41:42   1,107
MENU    .C32 .....a 0024B000    07/02/2012 11:41:42   56,164 ok
cat AUTORUN.INF...opened at 00010140
[autorun]
open=mint4win.exe --cdmenu --skipmd5check
icon=mint4win.exe,0
label=Install Linux Mint

[Content]
MusicFiles=false
PictureFiles=false
VideoFiles=false
  ok
OPEN SYSLINUX.CFG...opened at 0024AFC0  ok
@FILE XADR 80 DUMP 
7600: 64 65 66 61 75 6C 74 20 6D 65 6E 75 2E 63 33 32    default menu.c32
7610: 0A 70 72 6F 6D 70 74 20 30 0A 6D 65 6E 75 20 74    .prompt 0.menu t
7620: 69 74 6C 65 20 55 4E 65 74 62 6F 6F 74 69 6E 0A    itle UNetbootin.
7630: 74 69 6D 65 6F 75 74 20 31 30 30 0A 0A 6C 61 62    timeout 100..lab
7640: 65 6C 20 75 6E 65 74 62 6F 6F 74 69 6E 64 65 66    el unetbootindef
7650: 61 75 6C 74 0A 6D 65 6E 75 20 6C 61 62 65 6C 20    ault.menu label 
7660: 44 65 66 61 75 6C 74 0A 6B 65 72 6E 65 6C 20 2F    Default.kernel /
7670: 75 62 6E 6B 65 72 6E 0A 61 70 70 65 6E 64 20 69    ubnkern.append i
 ok

[D.P]

COG memory is very limited and Tachyon squeezes the VM and stacks in there ......

As for your head hurting can I suggest a Pepperjack Cab Sav. If that doesn't work then increase the dose.

Now my head hurts because this wine is not available in the USA!

Gonna have to place an Intl order

[Peter Jakacki]

RTC: DS3231(used in Chronodot)
Bluetooth: RN-42 http://www.parallax.com/StoreSearchR...0/Default.aspx

Getting an Asus TF300T tomorrow. Any tips on using the RN-42 with Blueterm?

The DS3231 is compatible enough with the MCP79410 that you should be able to use it as is, just change the device address. The first 7 registers are compatible although the 79410 does uses some of the otherwise unused bits for control purposes but that won't affect the 3231. Try it and let me know how is goes.

The device address can be changed either in the source code:
$DE == @rtc
to

$B0 == @rtc

Or you can write directly to the constant at runtime with:
$B0 ' @rtc 1+ !

The RN42 should just work in slave mode and you should be able to change it's default baudrate to 230400.

[Peter Jakacki]

Hmmm, been looking at the PWM code ... very confused. Code is:

                        org        _RUNMOD
_PWM                        mov        deltaR,tos        ' use supplied delta value from tos
                         mov        target,tos
                        add        target,cnt
                        mov        R1,#0
pwmlp                        mov        X,REG0        ' read base address of table
                        add        X,R1        ' add in read index
                         rdbyte        X,X
                         shl        X,REG1        ' shift up to pwmpins
                        mov        outa,X        ' update outputs
                        add        R1,#1
                        and        R1,#$FF
                        waitcnt        target,deltaR
                        jmp        #pwmlp
PWM        byte        _WORD,(@_PWM+s)>>8,@_PWM+s,_BYTE,13,XOP,xLOADMOD,EXIT

It seems to me that your only using the cog timer for a delay right? all io is bit-bashed rather than using outa,outb?
Also, I don't see how the above loop ends ... and ther is no jump to next or drop at the end of the code ... where does it go to?
Seems I am missing a big chunk of information here ... also "org _RUNMOD" confuses me as it is used above each PASM code module, doesn't that mean they will all be assembled at the same place in memory?
My head hurts.....

EDIT: Why is the code I post all mashed up ... tried copy/pasting through different editors but still rubbish ..


Bernie

COG memory is very limited and Tachyon squeezes the VM and stacks in there and there's no room really left over for specialized operations that really require PASM. That's where RUNMOD comes in as I sacrifice 16 to 24 longs for specialized modules which are compiled to run at that address but only one module can be loaded at a time. These specialized modules include SPI, I2C, SD, and PWM etc. The PWM module is designed to run in it's own cog as it's an endless loop where another cog/task can control the parameters. Of course the PWM cog doesn't need all the Tachyon VM in it after that but it's easy to load the module in the normal fashion.

So PWM doesn't use the counters, only WAITCNT but you mentioned PWM in your list which is different to duty-cycle modulation ( fixed pulse width, variable frequency).

As for your head hurting can I suggest a Pepperjack Cab Sav. If that doesn't work then increase the dose.

[bmentink]

There's the PWM code that's built in for 8 channels although it's a fairly easy matter to make it 32 channels so that you can choose arbitrary pins to suit. There's also the DAC function which could just as easily have a VOLTS function frontend to make it easier to set a voltage. So besides these and the frequency generation words that you can play with I think that it's easy enough to go to the next step of measuring etc. Have you had a look at the Introduction page? If you have something specific in mind I can work on that.

Hmmm, been looking at the PWM code ... very confused. Code is:

                        org        _RUNMOD
_PWM                        mov        deltaR,tos        ' use supplied delta value from tos
                         mov        target,tos
                        add        target,cnt
                        mov        R1,#0
pwmlp                        mov        X,REG0        ' read base address of table
                        add        X,R1        ' add in read index
                         rdbyte        X,X
                         shl        X,REG1        ' shift up to pwmpins
                        mov        outa,X        ' update outputs
                        add        R1,#1
                        and        R1,#$FF
                        waitcnt        target,deltaR
                        jmp        #pwmlp
PWM        byte        _WORD,(@_PWM+s)>>8,@_PWM+s,_BYTE,13,XOP,xLOADMOD,EXIT

It seems to me that your only using the cog timer for a delay right? all io is bit-bashed rather than using outa,outb?
Also, I don't see how the above loop ends ... and ther is no jump to next or drop at the end of the code ... where does it go to?
Seems I am missing a big chunk of information here ... also "org _RUNMOD" confuses me as it is used above each PASM code module, doesn't that mean they will all be assembled at the same place in memory?
My head hurts.....

EDIT: Why is the code I post all mashed up ... tried copy/pasting through different editors but still rubbish ..


Bernie

[RickInTexas]

I actually have the W5200 code and FAT32 file + virtual memory available soon. It's all been dragging out as a WIP until I start feeling the whip itself after which I get the job finished. Let me know if there are specific chips that need interfacing such as the RTCs and Bluetooth etc.

RTC: DS3231(used in Chronodot)
Bluetooth: RN-42 http://www.parallax.com/StoreSearchR...0/Default.aspx

Getting an Asus TF300T tomorrow. Any tips on using the RN-42 with Blueterm?

[Peter Jakacki]

Hi Peter,

Is there any more example code for the COG timers? I have studied the wave playing example and sort of understand it (been wading through the Parallax docs), would be good to
have some other other examples though ... i.e pulse PWM, motor control, Freq/Duty measurement etc ... the timers are so powerful, I would like to get my head around them ...

Cheers,
Bernie

There's the PWM code that's built in for 8 channels although it's a fairly easy matter to make it 32 channels so that you can choose arbitrary pins to suit. There's also the DAC function which could just as easily have a VOLTS function frontend to make it easier to set a voltage. So besides these and the frequency generation words that you can play with I think that it's easy enough to go to the next step of measuring etc. Have you had a look at the Introduction page? If you have something specific in mind I can work on that.

[bmentink]

Hi Peter,

Is there any more example code for the COG timers? I have studied the wave playing example and sort of understand it (been wading through the Parallax docs), would be good to
have some other other examples though ... i.e pulse PWM, motor control, Freq/Duty measurement etc ... the timers are so powerful, I would like to get my head around them ...

Cheers,
Bernie

[Peter Jakacki]

My system needs:
RTC
A2D
TCP/IP
BlueTooth
Strings
and chess, my gosh how come I don't have a chess module /SARC

dp

I actually have the W5200 code and FAT32 file + virtual memory available soon. It's all been dragging out as a WIP until I start feeling the whip itself after which I get the job finished. Let me know if there are specific chips that need interfacing such as the RTCs and Bluetooth etc.

[Dave Hein]

and chess, my gosh how come I don't have a chess module /SARC

That's funny, D.P. Good to see you're reading the pfth thread.

[D.P]

My system needs:
RTC
A2D
TCP/IP
BlueTooth
Strings
and chess, my gosh how come I don't have a chess module /SARC

dp

[Peter Jakacki]

,

Hi Peter,

It's great all the new stuff you are adding, but it is making me wonder what your view for the purpose of EXTEND.fth is?
Seems to me that it should only extend the kernel if it adds generic functionality like I2C, SPI, CAN etc and any other useful stuff, but I wonder when you start adding device drivers for particular chips
to that module ... should that not be in a separate module?

I do like the concept of modules to allow the user to pick and choose what to add for their application, it seems to me that if you add too much to EXTEND.fth, then you run the risk
of people having to strip stuff out they don't need to save space, then you have the problem of breaking things because us folk don't know all the dependencies ....

Oh, and talking about dependencies, i have loaded modules in that won't compile because they are missing some other module. Could we make sure the dependencies are listed at the
top of the module?

My 3c ....

Bernie

True, but the MCP3208 is such a little tiny thing that it felt lonely so I tucked it into a corner of EXTEND.fth. The other thing is that there is then a built-in ADC feature which means that even a newbie could plug a chip in and start working with it without having to locate the driver. So a driver like this is an exception. Of course in V3 a lot of these modules can be loaded in straight from Flash/SD.

[bmentink]

EXTEND.fth now also includes the NORMALIZE routine by Beau Schwabe as well as MCP3208 12-bit ADC words. NORMALIZE executes 12-bits in 200us. The MCP3208 communicates at the maximum sampling rate of 2MHz.

NORMALIZE ( data   bits low high -- result )

!ADC ( &ce.so.si.ck -- )            \ Init the MCP3208 driver using a long encoded pin descriptor &ce.miso.mosi.sck

ADC@ ( ch -- data )

ADCBUF ( buffer -- )               \ Read all 8 ADC channels into specified word buffer

VOLTS@ ( ch -- volts.00 )          \ Read back the pin as a voltage scaled to 2 decimals

,

Hi Peter,

It's great all the new stuff you are adding, but it is making me wonder what your view for the purpose of EXTEND.fth is?
Seems to me that it should only extend the kernel if it adds generic functionality like I2C, SPI, CAN etc and any other useful stuff, but I wonder when you start adding device drivers for particular chips
to that module ... should that not be in a separate module?

I do like the concept of modules to allow the user to pick and choose what to add for their application, it seems to me that if you add too much to EXTEND.fth, then you run the risk
of people having to strip stuff out they don't need to save space, then you have the problem of breaking things because us folk don't know all the dependencies ....

Oh, and talking about dependencies, i have loaded modules in that won't compile because they are missing some other module. Could we make sure the dependencies are listed at the
top of the module?

My 3c ....

Bernie

[D.P]

EXTEND.fth now also includes the NORMALIZE routine by Beau Schwabe as well as MCP3208 12-bit ADC words. NORMALIZE executes 12-bits in 200us. The MCP3208 communicates at the maximum sampling rate of 2MHz.

NORMALIZE ( data   bits low high -- result )

!ADC ( &ce.so.si.ck -- )            \ Init the MCP3208 driver using a long encoded pin descriptor &ce.miso.mosi.sck

ADC@ ( ch -- data )

ADCBUF ( buffer -- )               \ Read all 8 ADC channels into specified word buffer

VOLTS@ ( ch -- volts.00 )          \ Read back the pin as a voltage scaled to 2 decimals

Thanks Peter,

Back to refactor once again, module count reduced.

[Peter Jakacki]

EXTEND.fth now also includes the NORMALIZE routine by Beau Schwabe as well as MCP3208 12-bit ADC words. NORMALIZE executes 12-bits in 200us. The MCP3208 communicates at the maximum sampling rate of 2MHz.

NORMALIZE ( data   bits low high -- result )

!ADC ( &ce.so.si.ck -- )            \ Init the MCP3208 driver using a long encoded pin descriptor &ce.miso.mosi.sck

ADC@ ( ch -- data )

ADCBUF ( buffer -- )               \ Read all 8 ADC channels into specified word buffer

VOLTS@ ( ch -- volts.00 )          \ Read back the pin as a voltage scaled to 2 decimals

[MJB]

@Peter
based on your new STRING words I wanted to build an EVAL
which works - almost fine.

BUT:
1. maybe it would be better to suppress the echo of the evaluated string and show just the result
(could be done using NULLOUT & CON see below )

2. if used multiple times in one line or inside a loop, only the last EVAL seems to get executed.

seems I still miss s.th. important

\
pub (EVALSTR) ( strAddr -- )
         C@++ DUP 0= IF DROP ukey W~ $0D THEN ;  ok
           ok

pub EVAL ( strAddr -- \ evaluate the FORTH sentence in the null-teminated string starting at strAddr )
  ' (EVALSTR) ukey W! ;   ok

{ without output 
pub (EVALSTR) ( strAddr -- )
         C@++ DUP 0= IF DROP CON $0D THEN ;   
          \ just deliver one char after the other, on last one add $0D to get it executed and set reader back to CONsole

pub EVAL ( strAddr -- \ evaluate the FORTH sentence in the null-teminated string starting at strAddr )
    NULLOUT  \ suppress output 
    ' (EVALSTR) ukey W! ;  
}

" 1 1 + . " EVAL   ok
1 1 + .  2 ok
" 2 2 + . " EVAL   ok
2 2 + .  4 ok

" : TT1 $17 . ; " $20 STRING TESTSTR   ok
TESTSTR EVAL  ok
: TT1 $17 . ;   ok
TT1 17 ok
  ok

\ let's define a WORD, that generates other words ...  ( I worked many years with LISP ;-) - so I love EVAL )
: TTT
0 6 ADO  "0" I + TESTSTR 4 + C! "0" I + TESTSTR 8 + C! TESTSTR .STR CR TESTSTR EVAL LOOP
;  ok
  ok
TTT : TT0 $10 . ;
: TT1 $11 . ;
: TT2 $12 . ;
: TT3 $13 . ;
: TT4 $14 . ;
: TT5 $15 . ;
 ok
: TT5 $15 . ;   ok

[Peter Jakacki]

Thanks Peter,

I had to set xtall + pll16x ... then CLKFREQ displayed the correct frequency.
Interestingly the loop timings all were as per your published ones so I guess _clkmode is not actually used to set the PLL? I could not find another reference to it in the code... must be going blind

On another issue: Can you explain what the word DELTA does in the cog timer stuff?
Could not work out what PASM does either ..

Also, I read in this thread about the SEE de-compiler but don't see it in the kernel or EXTEND.fth ..

Thanks,
Bernie

I think the timing function just assumes it's running at 80MHz but I will take a look at that again and make sure it uses CLKFREQ.

' LAPCNT ( -- time ) Elapsed time in microseconds since NEWCNT

LAPCNT    byte    _1,SPRFETCH,REG,cntr,FETCH,XCALL,xNEWCNT,MINUS,_BYTE,80,XCALL,xDIVIDE,EXIT

DELTA accepts a count value and then performs a WAITCNT but if you want to continue in a loop you simply use WAITCNT again to synchronize. So DELTA is just used to set the timing period but also performs the first WAITCNT.

PASM takes a long from the stack and executes that PASM instruction in the cog.

The other files are available either in Google doc or webpage format or as text files on Dropbox. Where are the links? Just follow my sig but here's a quick link here

[bmentink]

Thanks Peter,

I had to set xtall + pll16x ... then CLKFREQ displayed the correct frequency.
Interestingly the loop timings all were as per your published ones so I guess _clkmode is not actually used to set the PLL? I could not find another reference to it in the code... must be going blind

On another issue: Can you explain what the word DELTA does in the cog timer stuff?
Could not work out what PASM does either ..

Also, I read in this thread about the SEE de-compiler but don't see it in the kernel or EXTEND.fth ..

Thanks,
Bernie

[Peter Jakacki]

Hi All,

I have a Prop Prototype board with a 5Mhz Crystal. The INFO word shows the clock frequency at 40Mhz, isn't it mean't to be 80Mhz? Do I have to tweak the PLL?

Cheers,
Bernie

Hi Bernie, you just need to make sure you have the right clock settings when you compile:

CON

_clkmode    = xtal1 + pll8x     ' <---------------- change to suit
_xinfreq    = 10_000_000        ' <---------------- change to suit your crystal

baud        = 230400        ' <-- change - tested from 300 baud to 3M baud

[bmentink]

Hi All,

I have a Prop Prototype board with a 5Mhz Crystal. The INFO word shows the clock frequency at 40Mhz, isn't it mean't to be 80Mhz? Do I have to tweak the PLL?

Cheers,
Bernie

[MJB]

Peter et al.,

I have had no problems reassigning i/o pins for for I2C and 1-Wire .. now what I need to attend to is console redirection. I have a Roving Networks RN XV WiFly card and it is setup to assert one pin when it has a Telnet connection then i/o is done via the di/do pins. Now I can ignore the connection pin and just hookup GND, DI, DO on the RN XV to the prop's P30/P31 and that works fine ... but what I want to do is run a task in a cog monitoring the connection pin and when it is detected reassign the console to the prop pins connected to DI/DO. Now, ideally there would be code to return the console to the local port, but typing REBOOT from the remote console will do for starters.

The ports of interest are referenced in the spin/pasm kernel as txd and rxd........ So far I don't seem to be able to find any way to get at them in Forth ...... is there any way? I'll accept quick and dirty for the moment.

cheers ... BBR

Hi Brian,
the txd side should not be a problem to change, since it is inside the running FORTH COG here:

' Registers used by PASM modules to hold parameters such as I/O masks and bit counts etc
REG0                long 0
REG1                long 0
REG2                long 0
REG3                long 0
REG4                long 0
txticks                long (80_000_000 / baud )        ' set transmit baud rate
txmask                long |<txd                ' change mask to reassign transmit

this can be changed using COG! using the REG4 address + 2 to store the new mask

newTxPin MASK 6 COGREG COG!

6 COGREG gives the address of the txmask COG register

the receive side is more difficult since the RX is running in it's own cog and the rx pin can not be changed afterwards.
IT might be possible to run a second receive cog in parallel to the first one with the second rx pin that you want to use,
if both receive alternatively.
OR you could adapt the receive cog, so you can dynamically change the rx-pin.

I'll have a closer look into the code later.

ok ... here is the start of the receive routine
I would suggest you specify a HUB location where you put the RX-mask
and use a simple

RxLoop                     
                                rdlong    rxpin, @temp+12+s   '  s.th. like this - you know PASM better than I do ...
                                                                            '  you could just use the last long of the temp register which is a 16 byte space
                                                                            '  or define an additional register long after the long registers - which I assume would work 
                                                                            '  - but I don't oversee the side effects of doing this.
                                                                            '  this might cost you a little receive speed 
                                call        #receive
         if_nc                jmp        #abreak         ' discard if framing error (no stop bits)
                               cmp        rxdata,#$7E wz         ' special TILDE sequence command?

and then you just write to this temp register

newRxMask 12 REG + !

REG gives you the start of the register space and temp is equivalent to REG(0) so to use REG(4-long) add this 12 bytes

EDIT: of course this RXMASK needs to be initialized to the standard RX-pin-mask on startup.
I would put it here:

{ ****** MAIN CONSOLE TERMINAL ******  }
        org        ' align the label
TERMINAL
        byte        InitRP
        byte        XCALL,xInitStack
        byte        _BYTE,rxd,MASK,REG,12,STORE   ' REG,12 == TEMP(3)
        byte        _WORD,00,50,XCALL,xms                        ' a little startup delay (also wait for serial cog)

but Peter might be faster with a helpful answer anyhow ;-)

[Brian Riley]

Peter et al.,

I have had no problems reassigning i/o pins for for I2C and 1-Wire .. now what I need to attend to is console redirection. I have a Roving Networks RN XV WiFly card and it is setup to assert one pin when it has a Telnet connection then i/o is done via the di/do pins. Now I can ignore the connection pin and just hookup GND, DI, DO on the RN XV to the prop's P30/P31 and that works fine ... but what I want to do is run a task in a cog monitoring the connection pin and when it is detected reassign the console to the prop pins connected to DI/DO. Now, ideally there would be code to return the console to the local port, but typing REBOOT from the remote console will do for starters.

The ports of interest are referenced in the spin/pasm kernel as txd and rxd........ So far I don't seem to be able to find any way to get at them in Forth ...... is there any way? I'll accept quick and dirty for the moment.

cheers ... BBR

[bmentink]

Hi Peter,

Just as a matter of interest, can you elaborate on what sort of fibre-optic link you used between Prop's? I am interested in connecting several CPU boards together with a "cheap" fat pipe(high bandwidth ...
It needs to have connectors that can stand a high vibration environment ...

Thanks,
Bernie

[D.P]

D.P. recently posted some example code for the 4D Systems uLCD-32PTU display module. Attached is an example of my approach to defining TACHYON drivers for the 32PTU.

nick

Neat Nick, I will post code when I'm happy with the results. I have two tasks, one that reads object messages from the lcd (ltask, I'm using the GENIE interface), and one that writes object messages with updated values from the RTC, A2D, flame sensor etc. I have found the uLCD to be really finicky in an actual application but so far the two tasks are working nicely together. Also found that I needed to use WAITLOW with a timeout instead of WAITPNE for serial in or the screen would hang during extended testing periods? I might try WAITPNE again now that I have the two tasks nicely separated.

Your Tachyon/FORTH is nice and clean, thanks for the example!!

[MJB]

cheers ... BBR

\  ------- from EXTEND.fth  -----------------

\ I/O "Constants" - variable to allow for redirection
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

\ Assign the Prop's EEPROM pins (default)
pub EEPROM       \ Brian, Peter ... 
        #P29 #P28   \ if you really want to allow for redirection this should also read  SDA SCL   
                           \ you could have another EEPROM at other pins ...       
                           \ or EEPROM is just only the BOOTEEPROM                          Markus

[nglordi]

D.P. recently posted some example code for the 4D Systems uLCD-32PTU display module. Attached is an example of my approach to defining TACHYON drivers for the 32PTU.

nick

[Peter Jakacki]

Hi Peter et All,

Has anyone used Tachyon on a Hive board? Will this Forth one day be able to support multiple Prop chips like this?
Seems to me "fun x 3" to have Tachyon running on this board .....

Cheers,
Bernie

I don't have any plans to support multiple Prop chips with Tachyon although I could probably use a similar approach that Propforth does. I have used my own version of inter-Prop coms over fibre-optic links so there is no reason that this can't be done over local links. However I like the Prop for it's simplicity and flexibility but I still regard it as a microcontroller and I can think of far better ways of implementing something like a hive board.

[bmentink]

Hi Peter et All,

Has anyone used Tachyon on a Hive board? Will this Forth one day be able to support multiple Prop chips like this?
Seems to me "fun x 3" to have Tachyon running on this board .....

Cheers,
Bernie

[bmentink]

Hi Peter,

Just browsing the above file and noticed a copy-paste error in the following function.
It calls FADC instead of the intended MADC....

Cheers,
Bernie

------------------------------------------------------------
'' Init and list all 8 channels
pub MLA                
         InitADC2 8 0
           DO CR I .BYTE ." : " I FADC@ $0A .NUM LOOP
         ;

[Peter Jakacki]

On point #1, I2CMAIN ... d'oh ... conceded!

On Point t#2, I2CBOOT vs EEPROM .. to quote the master (that's you!) "readability and consistency" ... my 'MAIN buss on P7/P6 also has an EEPROM in it ... I2CBOOT better conveys the sense of it.

No probs Brian, and sometimes the art of Forth boils down to the choice of a name, does it convey the correct thought? At times it can be frustrating trying to come up with the right name and method of operation, one that is natural enough to read and natural enough for Forth.

The other part of the art since we are on the subject is factoring, and when that factor has the right name then hopefully a novice should be able to understand the program. Wouldn't it be good if we had a little switch so we could switch ourselves to novice mode just to make sure it makes sense! Of course conversely, the novice would probably like a guru switch as well!

[Brian Riley]

Hi Brian,
I'm wondering why you aren't using the I2CPINS word and simply saying:

pub @I2CMAIN #P7 #P6 I2CPINS ;

You seem to be ignoring these functions and writing everything out in longhand.
As for @I2CBOOT isn't that what EEPROM does already?

On point #1, I2CMAIN ... d'oh ... conceded!

On Point t#2, I2CBOOT vs EEPROM .. to quote the master (that's you!) "readability and consistency" ... my 'MAIN buss on P7/P6 also has an EEPROM in it ... I2CBOOT better conveys the sense of it.

[Peter Jakacki]

I coded the 1-Wire along the lines of Peter's suggestions and added Markus' suggestion. It all worked fine. Thanks, guys!

Using this as a guideline I set up for the I2C redirection using @I2CBOOT and @I2CMAIN. It all seems to work fine. Peter? Markus? Did I miss anything this time?

FYI.... I am doing a project based on a Prop Mini, which as a 32K EEPROM and no clean access to P28/P29 ..So I built my main I2C buss on P7/P6 with a total of 4 devices.


cheers ... BBR

\  ------- from EXTEND.fth  -----------------

\ I/O "Constants" - variable to allow for redirection
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

\ Assign the Prop's EEPROM pins (default)
pub EEPROM
        #P29 #P28

\ Assign the pins to use for the I2C bus
pub I2CPINS ( sda scl -- )
        MASK ' SCL 1+ !
        MASK ' SDA 1+ !        
        ;


\  ------ I2C i/o re-direct extensions ---
\  ----- loaded at top of first file after EXTEND.fth -----

:    @I2CBOOT ( -- )        \ sets I2C pins to the default buss with P29/P28
        #P28    MASK ' SCL 1+ !
        #P29    MASK ' SDA 1+ !        
        ;

:    @I2CMAIN ( -- )        \ sets I2C pins to the alternate, in this case P7/P6
        #P6        MASK ' SCL 1+ !
        #P7        MASK ' SDA 1+ !        
        ;

Hi Brian,
I'm wondering why you aren't using the I2CPINS word and simply saying:

pub @I2CMAIN #P7 #P6 I2CPINS ;

You seem to be ignoring these functions and writing everything out in longhand.
As for @I2CBOOT isn't that what EEPROM does already?

[Brian Riley]

I coded the 1-Wire along the lines of Peter's suggestions and added Markus' suggestion. It all worked fine. Thanks, guys!

Using this as a guideline I set up for the I2C redirection using @I2CBOOT and @I2CMAIN. It all seems to work fine. Peter? Markus? Did I miss anything this time?

FYI.... I am doing a project based on a Prop Mini, which as a 32K EEPROM and no clean access to P28/P29 ..So I built my main I2C buss on P7/P6 with a total of 4 devices.


cheers ... BBR

\  ------- from EXTEND.fth  -----------------

\ I/O "Constants" - variable to allow for redirection
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

\ Assign the Prop's EEPROM pins (default)
pub EEPROM
        #P29 #P28

\ Assign the pins to use for the I2C bus
pub I2CPINS ( sda scl -- )
        MASK ' SCL 1+ !
        MASK ' SDA 1+ !        
        ;


\  ------ I2C i/o re-direct extensions ---
\  ----- loaded at top of first file after EXTEND.fth -----

:	@I2CBOOT ( -- )		\ sets I2C pins to the default buss with P29/P28
        #P28	MASK ' SCL 1+ !
        #P29	MASK ' SDA 1+ !        
        ;

:	@I2CMAIN ( -- )		\ sets I2C pins to the alternate, in this case P7/P6
        #P6		MASK ' SCL 1+ !
        #P7		MASK ' SDA 1+ !        
        ;

[D.P]

I've added some string operations to EXTEND.fth which may prove useful. Rather than the traditional counted strings I prefer null terminated strings plus they also consume less stack space. In this implementation the strings are long aligned in case that's useful and the byte before it is the bytecode which leaves the address of the string on the stack. I have also used the preceding bytes to hold the maximum allocated size of the string as well as an optional string count and attribute byte (not used at present).

To create a string constant or variable:

" MY NAME IS " $20 STRING NAME

To append to this:
" PETER" NAME APPEND$

Other operations include:
STRING Define a string
COPY$ Copy one string to another
APPEND$ Append one string to another
MID$ Return with string
LEFT$
RIGHT$
ERASE$ Erase the strings allocated space
LOCATE$ Locate the first character in the string else return with null
COMPARE$ Compare two strings and return with flag
+CHAR Append a character to the end of the string

Some of these operations may change as I seek to improve the definition of a string and how they operate.

Fantastic, going to go refactor, again. And if the words/functions change that's what :%s/oldstr/newstr/gc is for, the mouse can be crippling

Thanks Peter,

@bmentink There is Peter's SDCARD.fth library
https://docs.google.com/document/pub...Smj_fvBRhku8QY

But I have not seen any words that either A. execute via the terminal to "read" a file in from the local disk or B. Words to read and write "files" from the SD Card.
Can't speak for Peter but I'm pretty sure if you added file support to the SD library he wouldn't mind, me neither It's way beyond my FORTH at this time.

[bmentink]

Hi Peter,

Understand now, excellent. I did not realize that the Prop did not have indexed PASM instructions ..
I guess the only real trade-off is although as you say the words that don't modify the stack are now much faster, the words that do modify the stack, take the overhead of the POP or PUSH and are therefore slower ..
I guess it all boils down to which of these instructions are used the most frequent .... I am not sure myself, but Tachyon runs really fast, so I think you have made a good decision with your architecture ...

Regarding my other question, is there any file load words? or is all file loading/compiling by cut-and-paste ..

Cheers,
Bernie

[Peter Jakacki]

I've added some string operations to EXTEND.fth which may prove useful. Rather than the traditional counted strings I prefer null terminated strings plus they also consume less stack space. In this implementation the strings are long aligned in case that's useful and the byte before it is the bytecode which leaves the address of the string on the stack. I have also used the preceding bytes to hold the maximum allocated size of the string as well as an optional string count and attribute byte (not used at present).

To create a string constant or variable:

" MY NAME IS " $20 STRING NAME

To append to this:
" PETER" NAME APPEND$

Other operations include:
STRING Define a string
COPY$ Copy one string to another
APPEND$ Append one string to another
MID$ Return with string
LEFT$
RIGHT$
ERASE$ Erase the strings allocated space
LOCATE$ Locate the first character in the string else return with null
COMPARE$ Compare two strings and return with flag
+CHAR Append a character to the end of the string

Some of these operations may change as I seek to improve the definition of a string and how they operate.

[Peter Jakacki]

Hi Peter,

Just been browsing through the kernel PASM code, you have done a great job in your implementation.

An immediate standout for me regarding speed of execution is your decision to do away with the SP and go for straight MOV's in the PUSH and POP functions for example.
It seems that most of the low level words jump to the DROP function which of course calls POPX which has 12 MOV's as immediate overhead ... I apologize if this has already been discussed ..

Be interested to hear why you have taken this approach rather than a stack pointer as a stack pointer results in push and pop having a lot less instructions ..
Please note this is not a criticism, just like to know how you arrived at that decision ...

Also, are there any forth words to load file(s), or does all compiling involve cut-and-paste?

Cheers,
Bernie

Decisions decisions decisions..... The Prop is a strange beast and the lack of indexed operations in PASM not just for the pushing and popping but also for all the operations that need to reference stack elements led me to think of keeping stack elements fixed as if they were fixed registers. That way I didn't have to constantly calculate where the operands were or save and restore a TOS register etc, it's always just there. Sure it meant doing a rather brute force move method to push and pop but at least that kept it all in the cog. Look at how efficient these operations now become:

' @  ( addr -- long ) Fetch a longfrom hub memory
FETCH       rdlong    tos,tos
            jmp    #doNEXT

' 1+ ( n1 -- n1+1 )
            add    tos,#1
            jmp    #doNEXT

' SWAP ( n1 n2 -- n2 n1 ) Swap the top two items
            mov    X,tos+1
SWAPX       mov    tos+1,tos
PUTX        mov    tos,X
            jmp    #doNEXT

Sure there's a trade-off but this implementation is definitely fast (the fastest?) as is the bytecode method of indexing the first 256 longs in cog memory.

doNEXT      rdbyte    X,IP    'read byte code instruction
            add    IP,#1    'advance IP to next byte token
            jmp    X    'execute the code by directly indexing the first 256 long in cog

The other thing with any kinds of pointers is boundary checking as underflow and overflow can trash the code space so this way it intrinsically limited itself to the "stack". Can you see a better faster way of implementing PUSH and POP that always keeps it simple for all the other stack operations? I welcome the feedback and it's only a bonus if Tachyon can be made better.

The return and other stacks are implemented with self-modifying code to implement "indexed" addressing.

RPOPX       sub    rpopins,#1    ' decrement rpop's source field
            sub    _PUSHR,dst1
rpopins     mov    X,retstk
RPOPX_ret   ret

The other part of the implementation has to do with expressing the kernel in an easy to read source code form that runs in the Spin tool. That job was made a bit easier by using directly indexing bytecode so that the label corresponded to the cog address which could be written and compiled in a clear manner that kept clutter and calculations to an absolute minimum.

CLS    byte    PUSH1,$0C,XCALL,xEMIT,EXIT

[bmentink]

Hi Peter,

Just been browsing through the kernel PASM code, you have done a great job in your implementation.

An immediate standout for me regarding speed of execution is your decision to do away with the SP and go for straight MOV's in the PUSH and POP functions for example.
It seems that most of the low level words jump to the DROP function which of course calls POPX which has 12 MOV's as immediate overhead ... I apologize if this has already been discussed ..

Be interested to hear why you have taken this approach rather than a stack pointer as a stack pointer results in push and pop having a lot less instructions ..
Please note this is not a criticism, just like to know how you arrived at that decision ...

Also, are there any forth words to load file(s), or does all compiling involve cut-and-paste?

Cheers,
Bernie

[Peter Jakacki]

This was a logic error on my part ( imagine that). All is working as advertised. The 4DSystems LCD's are really touchy regarding serial, easy (for me at least) to lockup.

They do include a way to read and write to a FAT 32 file system via serial to the onboard SD. Once I have the rest of the boundary conditions identified I'll post my code

Thanks to all for the patience and help.

@Peter, I can't seem to find any info on the settings that we would use for Line rx Delay or Char rx Delay to manually configure the .minicom.dfl file, and since my install doesn't seem to want to write a .minicom.dfl file anywhere I can find with these settings (cd / sudo fgrep -R ) I can't see what they would be. Not on the MAN page, no joy with google so far.

Just check for the hidden .minirc.df1 etc files in your home directory but minicom does not store or load any tx or line delays here, it's just not built into the code. I will probably enhance and rebuild the source for minicom just to add these features.

[D.P]

Write (couldn't help that) you are. Post 771, don't mean to nag but I'm stumped, when you got a few cycles?

Oh and thanks for the 12ms delay in Minicomm, that works without any char delay, joy.

UPDATE

The delay works on my user code but when I rebuild the world not even 15ms delay works for EXTEND.fth?

This was a logic error on my part ( imagine that). All is working as advertised. The 4DSystems LCD's are really touchy regarding serial, easy (for me at least) to lockup.

They do include a way to read and write to a FAT 32 file system via serial to the onboard SD. Once I have the rest of the boundary conditions identified I'll post my code

Thanks to all for the patience and help.

@Peter, I can't seem to find any info on the settings that we would use for Line rx Delay or Char rx Delay to manually configure the .minicom.dfl file, and since my install doesn't seem to want to write a .minicom.dfl file anywhere I can find with these settings (cd / sudo fgrep -R ) I can't see what they would be. Not on the MAN page, no joy with google so far.

[Peter Jakacki]

Hi Peter,

Thanks for the welcome back, and things are cold here in Christchurch at the mo .. :-) Yes, you are right, I had forgotten all about the H8 days, that was even before GraspForth ..... I'm getting old and forgetful ;-)

Regarding the line delays .. I found that 4ms was fine at 1M baud (I can't seem to get as high as 3M, maybe because I have a 5Mhz crystal?).
So I have an old Propeller Proto Board, is there any advantage on using a 10Mhz crystal? Will it let me go to 3M baud?

My .minirc.dfl looks like this:

# Machine-generated file - use setup menu in minicom to change parameters.
pu port /dev/ttyUSB0
pu baudrate 1000000
pu rtscts No
pu addlinefeed No

Can you maybe post yours Peter?

Cheers,
Bernie

Hi Bernie, I just changed the thread title to "Minicom setup". The crystal makes no difference it's just that 10MHz are much easier to get in smaller packages such as cylindrical and very small SMD. I detest those HC49/4 SMD crystals because they are large and have legs that spread out like antennas plus they really mess up routing to pins because of this large footprint that they occupy. Through-hole HC49 are better in this respect but why bother when there are much better solutions available.

The limitation with 3M baud is not with Tachyon or the Prop but to do with the FT232R USB-serial chip so your limitation will be tied in with the hardware. As I mentioned earlier I will do up a minicom setup guide.

EDIT: I'm looking at recompiling a version of minicom from source. There's the variable vt_nl_delay which needs to be set.

[bmentink]

Hi Peter,

Thanks for the welcome back, and things are cold here in Christchurch at the mo .. :-) Yes, you are right, I had forgotten all about the H8 days, that was even before GraspForth ..... I'm getting old and forgetful ;-)

Regarding the line delays .. I found that 4ms was fine at 1M baud (I can't seem to get as high as 3M, maybe because I have a 5Mhz crystal?).
So I have an old Propeller Proto Board, is there any advantage on using a 10Mhz crystal? Will it let me go to 3M baud?

My .minirc.dfl looks like this:

# Machine-generated file - use setup menu in minicom to change parameters.
pu port /dev/ttyUSB0
pu baudrate 1000000
pu rtscts No
pu addlinefeed No

Can you maybe post yours Peter?

Cheers,
Bernie

[D.P]

P.S. I was so busy answering your query that I forgot my manners so welcome back to the Prop forum Bernie and especially the Tachyon thread
BTW, I wrote IVOS for the ARM7 which I entered into the Philips Circuit Cellar ARM design competition back in 2005 amongst many other things of course. Bit-bashing color VGA under interrupts while processing Forth apps, sound, SD, keyboards etc was a little bit harder with a single core compared to the Prop.

@D.P. Yes, the delays don't stick do they but I might look into that because it must be possible to set that surely.

Write (couldn't help that) you are. Post 771, don't mean to nag but I'm stumped, when you got a few cycles?

Oh and thanks for the 12ms delay in Minicomm, that works without any char delay, joy.

UPDATE

The delay works on my user code but when I rebuild the world not even 15ms delay works for EXTEND.fth?

[Peter Jakacki]

You have to make sure that the user is part of the serial/dialout etc groups otherwise you are stuck with invoking minicom with "minicom -s" setup each time. If you did happen to run minicom with -s then you obviously do not have permissions and any setup you save won't work. Once you have enabled permissions then you can save your minicom config as USB0 and then simply invoke "minicom USB0" next time. I find that I need around 10 to 12 ms line delay but never any character delay. Turn off hardware and software handshakes. I will look at providing a simple minicom guide shortly.

BTW, "WORDS" was part of the kernel earlier but it is easier to write and enhance these higher level functions as pure Forth source code which is why it's moved to EXTEND.fth. There are probably a lot of things in EXTEND.fth that aren't totally necessary but then again they don't take up a lot of room either so just consider this file as a necessary part of the kernel which compiled by the PC compiled kernel.

P.S. I was so busy answering your query that I forgot my manners so welcome back to the Prop forum Bernie and especially the Tachyon thread
BTW, I wrote IVOS for the ARM7 which I entered into the Philips Circuit Cellar ARM design competition back in 2005 amongst many other things of course. Bit-bashing color VGA under interrupts while processing Forth apps, sound, SD, keyboards etc was a little bit harder with a single core compared to the Prop.

@D.P. Yes, the delays don't stick do they but I might look into that because it must be possible to set that surely.

EDIT: I remember you now Bernie from the H8 days, you're a Kiwi hey. Good to see you still around.

[D.P]

Thanks D.P ..

Yes, finally got minicom working ... needed to reset the Prop for some reason.
I was following the "Getting started guide" and it stated that WORDS was in the kernel code ... hence the confusion. On further investigation I did notice that it was commented out of the kernel for some reason.
Anyway I am up and running now .. thanks.

Do you know how to make the line delays stick in minicom? I save my configuration but next boot the line delays are gone ..

Cheers,
Bernie

I'm on Mac OSX and I can't get the delays to stick either! I've tried the usual stuff just no luck, let me know if you figure it out.

[Peter Jakacki]

Thanks D.P ..

Yes, finally got minicom working ... needed to reset the Prop for some reason.
I was following the "Getting started guide" and it stated that WORDS was in the kernel code ... hence the confusion. On further investigation I did notice that it was commented out of the kernel for some reason.
Anyway I am up and running now .. thanks.

Do you know how to make the line delays stick in minicom? I save my configuration but next boot the line delays are gone ..

Cheers,
Bernie

You have to make sure that the user is part of the serial/dialout etc groups otherwise you are stuck with invoking minicom with "minicom -s" setup each time. If you did happen to run minicom with -s then you obviously do not have permissions and any setup you save won't work. Once you have enabled permissions then you can save your minicom config as USB0 and then simply invoke "minicom USB0" next time. I find that I need around 10 to 12 ms line delay but never any character delay. Turn off hardware and software handshakes. I will look at providing a simple minicom guide shortly.

BTW, "WORDS" was part of the kernel earlier but it is easier to write and enhance these higher level functions as pure Forth source code which is why it's moved to EXTEND.fth. There are probably a lot of things in EXTEND.fth that aren't totally necessary but then again they don't take up a lot of room either so just consider this file as a necessary part of the kernel which compiled by the PC compiled kernel.

[bmentink]

Thanks D.P ..

Yes, finally got minicom working ... needed to reset the Prop for some reason.
I was following the "Getting started guide" and it stated that WORDS was in the kernel code ... hence the confusion. On further investigation I did notice that it was commented out of the kernel for some reason.
Anyway I am up and running now .. thanks.

Do you know how to make the line delays stick in minicom? I save my configuration but next boot the line delays are gone ..

Cheers,
Bernie

[D.P]

Hi Peter and all,

I have not been on this forum for awhile, but was tempted back when I noticed your excellent Forth for the Prop. (.. by the way, I am the author of GraspForth ..)

I am trying to get started on my Linux box and am having a couple of issues.
I did get BST going so I have a IDE that will compile SPIN for Linux ..... well it appears to at least.
As instructed I copy/pasted the code from the web page (deleting 1st and last lines) and it compiles ok and installs on the Prop.
I launch cKermit at 230400 and I get the "ok" Forth prompt ok, but have the following issues ..

1. The Forth word "WORDS" does not exist, however I can put stuff on the stack and print them off ok ... so that is working.
2. Backspace does the wrong thing but ^H works ... guess that is a kermit thing. So I next tried minicom as you suggest, set it to the correct baud rate 230400, but I do not get the "ok" prompt.
I think characters are getting to the Prop as the blue light blinks when I press a key. I tried different baud rates to no avail.
3. Copy/paste of forth code to the kermit console causes a garbled mess and a hung Forth. Really must get miniterm working ..

Peter do you have a miniterm config file posted somewhere that has all the parameters set correctly ... especially for 3M baud rate?

I look forward to playing with this and contributing where I can ...

Cheers,
Bernie

You need to get EXTEND.fth and paste this into the terminal, make sure you set a little Line delay (4ms) and you may need t set a 1ms per char delay worst case.

The WORDS you are looking for are in EXTEND.fth, and a whole bunch more, welcome back.

Extend.fth https://docs.google.com/document/pub...IIxCUVjmWXqSCU

[D.P]

pri RDRTC ( -- )

        0 @RTC

        I2CSTART $A3 I2C!

        0 #16 ADO 0 I2C@ I rtcmasks + C@ AND I rtc + C! LOOP 1 I2C@ DROP

        I2CSTOP
;

This WORD is part of the PCF8563RTC module.
I can use the below WORD just fine in a separate task

pri WRRTC ( -- ) \ Write the rtc buffer to the RTC chip

        0 0 RTC!

        0 @RTC rtc #16 ADO I C@ I2C! LOOP I2CSTOP
;

 \ as in this word 

pub 1khz  ( -- )  \ set clockout to 1khz

        $81 $0D RTC!  WRRTC
;

Stumped, I've got the LCD, ADC reads and RTC writes all working fine from the separate task, just when I call the RDRTC WORD I loose stability?

[bmentink]

Hi Peter and all,

I have not been on this forum for awhile, but was tempted back when I noticed your excellent Forth for the Prop. (.. by the way, I am the author of GraspForth ..)

I am trying to get started on my Linux box and am having a couple of issues.
I did get BST going so I have a IDE that will compile SPIN for Linux ..... well it appears to at least.
As instructed I copy/pasted the code from the web page (deleting 1st and last lines) and it compiles ok and installs on the Prop.
I launch cKermit at 230400 and I get the "ok" Forth prompt ok, but have the following issues ..

1. The Forth word "WORDS" does not exist, however I can put stuff on the stack and print them off ok ... so that is working.
2. Backspace does the wrong thing but ^H works ... guess that is a kermit thing. So I next tried minicom as you suggest, set it to the correct baud rate 230400, but I do not get the "ok" prompt.
I think characters are getting to the Prop as the blue light blinks when I press a key. I tried different baud rates to no avail.
3. Copy/paste of forth code to the kermit console causes a garbled mess and a hung Forth. Really must get miniterm working ..

Peter do you have a miniterm config file posted somewhere that has all the parameters set correctly ... especially for 3M baud rate?

I look forward to playing with this and contributing where I can ...

Cheers,
Bernie

[Peter Jakacki]

Yes, and I was thinking about the allocation size as well, so strings could also simply be buffers or memory arrays where we have more than 255 bytes which would make it much more versatile, why not?
SIZE[2] LEN[2] STRING NULL
The null is redundant for binary strings but useful for text strings. The address that is passed is the address of the string which is also long aligned to allow for word and long elements. So the length is the word just before the string address and the allocated size is just before that. It's basically up to user code to interpret the string the way it wants but I will see if we need to do more but for the moment KISS.

[MJB]

What Tachyon needs is a string and byte string operation where you could pass multiple bytes as a string in suitable notation such as: $" 3443101001" and the address of the counted string would be stored on the stack. I will look into this with some interest as that seems the best way of handling a long length of parameters. Normally I prefer null terminated strings but binary strings would have to have a count which I might make compatible with null terminated strings by storing the count at stringaddress-1 and still null terminate anyway. Then I could have an SPI function for TxString, now wouldn't that be good? Bundle that into WriteStr24 ( str cmd -- ):

$" 3443101001" Rwr RxAddr0 + WriteStr24

like this

AND since we not only want to write predefined constant bytestrings we need some ByteString manipulation words as well.

STRING name n     \ allocates a string with n bytes, ALLOC is done internally, not after, since we want to store the allocated length

if string length in byte stringaddress-1 is 0 then treat as null terminated
if string length in byte stringaddress-1 is >0 then treat as binary string of this size
maybe we let the programmer decide how to use instead of forcing s.th.

access is straight forward

name x + C@ 
byte name x + C!

or

: "! ( byte stringName index -- ) + C! ;
: "@ ( stringName index -- byte ) + C@ ;
byte name x "!
name x "@

Manually update length:

newlen  name 1- C!

of course we can search the string for a first 0 to match with null terminated,
but this would not really be needed, since writing a 0 len field would imply this.
Now the user can decide how to use the string functions.
see stringFunctions.fth ;-)

unfortunately the allocated length is not accessible easily.
From the dictionary we can find the next word address,
but maybe we could store the allocated length in

alloclen  name 2- C!

this would allow for 255 byte strings - big enough for a micro

... and now we are back to the original question accumulating bytes to a buffer
so now the string is the buffer, and it's length field is the buffer fill counter
after creation this is 0

we define a "!++ which stores and increments count ... and leaves the string address in the stack,
like the C@++

: "!++ ( stringAddress byte -- stringAddress ) ... ;

myString $34 "!++ $43 "!++ ...   DROP

kind of ...

[D.P]

The trouble with SEROUT is that it's just a very basic function that's handy but could do with a tiny bit of tweaking to make it work with multiple instances. The on offender is "baudcnt" which is effectively a global variable even though it isn't. It's possible just to copy&paste a new version with it's own variable or if you give your cog it's own set of task registers and then baudcnt will be independant from the other cogs. Just allocate an area of memory for this and pass the address to that cog (from within the task). Here are two comments from the source codes
' Task registers can be switched easily by setting "regptr" ( 7 COGREG! )

\ baudcnt is a task register so each cog can have it's own baudrate (if used)

So do this:
TABLE task1 #32 ALLOT
then from within your task startup code do this:
task1 7 COGREG!
XXXX SERBAUD

So try this and see how it goes. Of course I could add a word called TASKREGS which just does the same as 7 COGREG! but I will look at any improvements I can make.

BTW, I'm scratching my head wondering why you need to input from a serial LCD? These are always output devices and the only requirement for reading back that I have when I design them is because of a keypad or something other than the display itself.

The device in question is a 4DSystems LCD32-PTU touch screen running async TTL serial, read it for touch input/messages, write to it to update the graphics/send commands.

The above worked correctly. Could you explain the issues of using modules such as the PFC RTC library in other tasks, seems I'm still steeping on myself trying to read from the RTC in a separate TASK.

Here are the very un-optimized routines I use to read and write to this display with lots of debug info still in place. And a few test words to see how to write to the controls.

pub SERINW ( pin -- data )
        MASK DUP INPUTS DUP
        #200000 SWAP WAITLOW  0 > IF              \ 15 ms delay
          baudcnt @ 2/ DELTA
          baudcnt @ DELTA                        \ delay to sample 1 bit later in 1st data bit
            0 8 FOR SHRINP WAITCNT NEXT
          NIP #24 SHR                            \ right justify 8-bit data
      \    DUP CR .                    \ got data
        THEN
;

pub RD_MSG
  0 flag !
  #ptx SERINW
  1+ ?DUP  IF            \ add one to return value from serinw dup if not zero now we need to remove the 1 to get
    1-                   \    original return value back
    DUP
    mcmd C!              \ store 1st byte in mcmd byte
    #rp_evt = IF         \ is this byte = to our Report Object evt?
      #ptx SERIN         \ next byte 2 bytes for object
      mobjh C!           \ move into mobjh MSB
      #ptx SERIN         \ next byte
      mobjl C!           \ move byte into mobjl LSB
      #ptx SERIN         \ next byte 2 bytes for value
      mvalh C!           \ move into mval MSB
      #ptx SERIN         \ next byte
      mvall C!           \ move into mval LSB
      #ptx SERIN
      mchks C!
      mcmd C@ mobjh C@ XOR mobjl C@ XOR
      mvalh C@ XOR mvall C@ XOR
      mchks C@ = IF
       CR CR ." Good Data "
         -1 flag !         \ got good data set flag true
      THEN
      mobjh C@ 8 SHL mobjl C@ OR mobj W!
      CR ." chks:  " mchks C@ .
      CR ." mcmd: " mcmd C@ .
      CR ." obj: H: " mobjh C@ . ."   L: " mobjl C@ .
      CR ." val: H: " mvalh C@ . ."   L: " mvall C@ .
    THEN
  THEN


: SDMSG ( val obj -- ack/nak )

    #wr_obj mchksum !
    #wr_obj #prx SEROUT     \ send write obj cmd
    W>B                     \ move obj into 2 byte msb top of stack
    DUP mchksum @ XOR mchksum !       \ add byte to checksum
    SWAP
    DUP mchksum @ XOR mchksum !       \ add other byte to checksum
    SWAP                    \ align bytes again in proper order
    #prx SEROUT             \ send first byte
    NOP
    #prx SEROUT             \ send second byte
    NOP
    W>B                     \ move val into 2 bytes
    DUP mchksum @ XOR mchksum !       \ add byte to checksum
    SWAP
    DUP mchksum @ XOR mchksum !       \ add byte to checksum
    SWAP                    \ align bytes again in proper order
    #prx SEROUT             \ send msb of val
    NOP
    #prx SEROUT             \ send lsb of val

    mchksum @ #prx SEROUT   \ send checksum
;

: RST
  $0000 $0400 SDMSG  \ GRN SLIDER
  $0000 $0401 SDMSG  \ RED
  $0000 $0800 SDMSG  \ PSI
  $0000 $1200 SDMSG  \ THERM
  $0000 $0F00 SDMSG  \ HOURS MINS
  $0000 $0F01 SDMSG  \ SECS
;
: FUL
  $00FF $0400 SDMSG  \ GRN SLIDER
  $00FF $0401 SDMSG  \ RED
  $0023 $0800 SDMSG  \ PSI
  $0078 $1200 SDMSG  \ THERM
  $0937 $0F00 SDMSG  \ HOURS MINS
  $003B $0F01 SDMSG  \ SECS
;

: GA #ptx SERINW ;

: TL
  $003B $0F01 SDMSG   \ SET SECONDS:  59
  $0423 $0F00 SDMSG   \ SET HOURS MINUTES: 1059
  $0011 $0800 SDMSG   \ SET PSI GUAGE: 17 0-35
  $0061 $1200 SDMSG   \ SET THERM: 180,  0-120 = 120-240
  $00A0 $0400 SDMSG   \ SET GRN SLIDER: 160  0-255
  $0050 $0401 SDMSG   \ SET GRN SLIDER: 80  0-255
;

: RSTLCD #P21 PINCLR 10 us #P21 PINSET ;

[Peter Jakacki]

first byte - would mean the first byte sent via SPI? so we can loop upwards ?
the nRF24L01 expects the LSByte first with bit MSBit first.

would it make sense to arrange the bytes in a way so
ESPIO could be used 32bits and then 8bits? for the 5 bytes
or would 5 times ESPIO RUNMOD be comparable in speed?

There's no great advantage in speed but it can be done and if we did then the long would be byte packed big-endian style as you mentioned. What Tachyon needs is a string and byte string operation where you could pass multiple bytes as a string in suitable notation such as: $" 3443101001" and the address of the counted string would be stored on the stack. I will look into this with some interest as that seems the best way of handling a long length of parameters. Normally I prefer null terminated strings but binary strings would have to have a count which I might make compatible with null terminated strings by storing the count at stringaddress-1 and still null terminate anyway. Then I could have an SPI function for TxString, now wouldn't that be good? Bundle that into WriteStr24 ( str cmd -- ):

$" 3443101001" Rwr RxAddr0 + WriteStr24

[MJB]

If bytes are packed into longs it's good to treat the long as a little-endian array, the LSB is the first byte.

first byte - would mean the first byte sent via SPI? so we can loop upwards ?
the nRF24L01 expects the LSByte first with bit MSBit first.

would it make sense to arrange the bytes in a way so
ESPIO could be used 32bits and then 8bits? for the 5 bytes
or would 5 times ESPIO RUNMOD be comparable in speed?

[Peter Jakacki]

@Peter
Interesting how much effort you are spending - in thought and in implementation - to keep the stack use low.
My approach is getting it to run as soon as possible and then see, where is need for improvement and optimization.
But maybe it is your experience with Forth and Tachyon and your coding speed that let you do the additional effort
while I am still thinking along ...

pushing 5 values on the stack and then immediately sending them out didn't appear a big deal to me.
So you think using 5 stack elements here will cause trouble later?
I was also thinking the stack variant would be much faster.
Just pushing the values into the COG and sending them out from there without HUB memory access.

When I see your last code line it is not immediately clear to me what the bytes mean.
is it bytes 4..1 and then byte 5 - or do we better 1..4 5 ?
without some extensive comments it is not easily visible what byte means what.
Whereas my approach was very straight forward, just push 5 .. 1 on the stack and then in a tiny loop
write them to SPI 1 .. 5 with RUNMOD where they get automatic and 'free' pops.

on the + vs. OR I agree it is visually more distinct to have the +,
but from a logic way to me an OR indicates a bitwise combination, whereas + implies s.th. different,
even when given the correct arguments as here the outcome is the same.
so this 'readability' is a matter of personal style.

nevertheless, thanks very much for your input.
it is of very great value to me and surely to others following as well
Markus

The stack approach was using 7 items (5 data + count + command) on a stack that's only 12 deep and that alarmed me because this is a lower layer of an application that is going to have have many items on the stack? Plus the actual WriteCmd24S needs stack space too before it even touches the parameters that have been passed.

As for + vs OR as I mentioned it's about readability and it is perfectly correct to add bit fields such as b7 + b5 + b1 + b0 and it's perfectly understandable too.

If bytes are packed into longs it's good to treat the long as a little-endian array, the LSB is the first byte.


EDIT: just picked up on your last post

[MJB]

reconsidering the line:

$01 $10 $10 $43 $34 5 Write_reg Rx_addr_p0 OR WriteCmd24S

this uses 8 stack entries ...
and we have a max of 12 ....
this can be critical very soon ..

so I consider

$34 $43101001 5 Write_reg Rx_addr_p0 OR WriteCmd24S
$34 1 Write_reg Rx_addr_p0 OR WriteCmd24S

with the bytes right justified in 2 longs.

[MJB]

@Peter
Interesting how much effort you are spending - in thought and in implementation - to keep the stack use low.
My approach is getting it to run as soon as possible and then see, where is need for improvement and optimization.
But maybe it is your experience with Forth and Tachyon and your coding speed that let you do the additional effort
while I am still thinking along ...

pushing 5 values on the stack and then immediately sending them out didn't appear a big deal to me.
So you think using 5 stack elements here will cause trouble later?
I was also thinking the stack variant would be much faster.
Just pushing the values into the COG and sending them out from there without HUB memory access.

When I see your last code line it is not immediately clear to me what the bytes mean.
is it bytes 4..1 and then byte 5 - or do we better 1..4 5 ?
without some extensive comments it is not easily visible what byte means what.
Whereas my approach was very straight forward, just push 5 .. 1 on the stack and then in a tiny loop
write them to SPI 1 .. 5 with RUNMOD where they get automatic and 'free' pops.

on the + vs. OR I agree it is visually more distinct to have the +,
but from a logic way to me an OR indicates a bitwise combination, whereas + implies s.th. different,
even when given the correct arguments as here the outcome is the same.
so this 'readability' is a matter of personal style.

nevertheless, thanks very much for your input.
it is of very great value to me and surely to others following as well
Markus

[Peter Jakacki]

here my work in progress
https://docs.google.com/document/d/1...UVOJczcgM/edit
still some weeks until the modules arrive.

I will see what I can do in the meantime as I do have boards that will accept the 24L01 modules directly. I noticed that you started to use the stack to pass multiple parameters to writecmd and although this would work I see you chose this because the manual buffer write method looked clumsy, which it was. How about this method instead:

BYTE ix

pub !! ( data -- ) \ add data to buffer

    ix C@ data24 + C!
    ix C++
    ;
pub Setup_rx ( )

\    buffer variant
    ix C~             \ reset buffer index
    $34 !! $43 !! $10 !! $10 !! $01 !!
    5 Write_reg  Rx_addr_p0 OR WriteCmd24 ( cnt cmd )

As you can see the stack usage is kept to a minimum and it's also possible to further improve this so that you could pass a long instead of 4 bytes etc. Since the data packing
routine would need to know the count then it automatically also knows when to stop and send the command as well. In which case we only need a combo WriteDat an WriteCmd that would be invoked like this:
$10104334 $01 5 Write_reg Rx_addr_p0 OR WriteDatCmd24
The Rx_addr_p0 style always looks very verbose and although German has a tendency toward very long concatenated names it seems to clutter the code. How about something as simple as nonunderscored names and simply rely on camelcase like this: RxAddr0
You can also use + instead of OR which further increases readability (IMO). Going a bit further and redefine Write24 this is probably how I would make it look:
$10104334 $01 5 Rwr RxAddr0 + Write24

[MJB]

here my work in progress
https://docs.google.com/document/d/1...UVOJczcgM/edit
still some weeks until the modules arrive.

[MJB]

what I would do:

\ ----- I/O Defs & redirection words (new code) -----

#P16 |< == DQID    
#P17 |< == DQTEMP

pub @1W_TEMP    ( -- )    DQTEMP ( falls through to DQ! )
pub DQ!    ( 1wmask -- )    ' DQ 1+ ! ;
pub @1W_ID    ( -- )    DQID DQ! ;

Peter, to make it really clear DQ needs to be defined as a const as well

\ ----- I/O Defs & redirection words (new code) -----

#P16 |< == DQID    
#P17 |< == DQTEMP

DQID  == DQ  \ define the DQ const and set default value

pub @1W_TEMP    ( -- )    DQTEMP ( falls through to DQ! )
pub DQ!    ( 1wmask -- )    ' DQ 1+ ! ;
pub @1W_ID    ( -- )    DQID DQ! ;

\ now DQ can be used in the code just like a normal constant
\ and it can be reassigned with DQ! to whatever you want, even other consts

[Peter Jakacki]

I have a word that uses SEROUT and one that uses SERINW ( a routine I made with SERIN using WAITLOW instead of WAITPNE) to update and query an LCD serial device.

When I try to launch SDMSG (using SEROUT) in a task and all it does it run once and complete (no loops) my system becomes unstable and I loose comms to the serial device.

What are the "rules" using SEROUT in another TASK if any. I have modified the SDMSG to first set #9600 SERBAUD reading that separate cogs can have separate SERBAUD settings.

The words run just dandy from the console cog, in loops, keypoll etc.

Maybe I'm not understanding how variables, constants et al are scoped in Tachyon.


Seems I'm corrupting more than I realize, time to look at the code again.

The trouble with SEROUT is that it's just a very basic function that's handy but could do with a tiny bit of tweaking to make it work with multiple instances. The on offender is "baudcnt" which is effectively a global variable even though it isn't. It's possible just to copy&paste a new version with it's own variable or if you give your cog it's own set of task registers and then baudcnt will be independant from the other cogs. Just allocate an area of memory for this and pass the address to that cog (from within the task). Here are two comments from the source codes
' Task registers can be switched easily by setting "regptr" ( 7 COGREG! )

\ baudcnt is a task register so each cog can have it's own baudrate (if used)

So do this:
TABLE task1 #32 ALLOT
then from within your task startup code do this:
task1 7 COGREG!
XXXX SERBAUD

So try this and see how it goes. Of course I could add a word called TASKREGS which just does the same as 7 COGREG! but I will look at any improvements I can make.

BTW, I'm scratching my head wondering why you need to input from a serial LCD? These are always output devices and the only requirement for reading back that I have when I design them is because of a keypad or something other than the display itself.

[D.P]

I have a word that uses SEROUT and one that uses SERINW ( a routine I made with SERIN using WAITLOW instead of WAITPNE) to update and query an LCD serial device.

When I try to launch SDMSG (using SEROUT) in a task and all it does it run once and complete (no loops) my system becomes unstable and I loose comms to the serial device.

What are the "rules" using SEROUT in another TASK if any. I have modified the SDMSG to first set #9600 SERBAUD reading that separate cogs can have separate SERBAUD settings.

The words run just dandy from the console cog, in loops, keypoll etc.

Maybe I'm not understanding how variables, constants et al are scoped in Tachyon.


Seems I'm corrupting more than I realize, time to look at the code again.

[Peter Jakacki]

I was working today on some 1-Wire stuff. It turned out that I had several unused pins and life would be simpler with two different 1W busses ... so I put my new found knowledge from the other day to work and came up with these mods to the 1-Wire I/O Defs. They work perfectly and required no changes to anything else.

... Peter ... are there any hidden land mines in what I've done here????

( I/O DEFINITIONS )

{ OLD CODE
LONG dq
pri DQ@                dq @ ;
pub DQ!                dq ! ;
#P16 |< DQ!                        \ set the default
}

\ ----- I/O Defs & redirection words (new code) -----

#P16 |< CONSTANT DQ        \ set default 

pri DQ@    ( -- )            ' DQ 1+ @ ;
pub DQ!    ( 1wpin -- )    MASK ' DQ 1+ ! ;

: @1W_ID    ( -- )    #P16 DQ! ;
: @1W_TEMP    ( -- )    #P17 DQ! ;

\ ---------------------------------------

One of the reasons I used constants in place of variables is that without redirection we just use constants in the first place and they are much more readable both in the pin definition and in their reference. So therefore it made sense to use rewritable constants to make it clear what was happening and what the default pins were. Alternate pins should also be defined as constants for readability too and the constant name used in the redefinition function. Of course in some applications I just use an encoded long to specify up to 4 pins and any constant definitions would be redundant but that doesn't mean you can't include them, at least as comments in your code.

So Brian you obviously missed the point of using constants as you have this defintion:

pri DQ@    ( -- )            ' DQ 1+ @ ;

Now the constant DQ if you run it will return the value of the constant whereas DQ@ tries to manually manipulate the constant and just ends up with what DQ if run would do anyway. So DQ@ is absolutely redundant and you only need to say DQ. Also to add to the confusion you were probably better off leaving it the way you had it although I would still recommend defining the pins as constants first simply for readability: However following faithfully using the constant method this is what I would do:

\ ----- I/O Defs & redirection words (new code) -----

#P16 |< == DQID    
#P17 |< == DQTEMP

pub @1W_TEMP    ( -- )    DQTEMP ( falls through to DQ! )
pub DQ!    ( 1wmask -- )    ' DQ 1+ ! ;
pub @1W_ID    ( -- )    DQID DQ! ;

[MJB]

( I/O DEFINITIONS )

{ OLD CODE
LONG dq
pri DQ@                dq @ ;
pub DQ!                dq ! ;
#P16 |< DQ!                        \ set the default
}

\ ----- I/O Defs & redirection words (new code) -----

#P16 |< CONSTANT DQ        \ set default 

pri DQ@    ( -- )            ' DQ 1+ @ ;
pub DQ!    ( 1wpin -- )    MASK ' DQ 1+ ! ;

: @1W_ID    ( -- )    #P16 DQ! ;
: @1W_TEMP    ( -- )    #P17 DQ! ;

\ ---------------------------------------

hi Brian,
where do you see the benefit of using CONSTANT vs. the following?

( I/O DEFINITIONS )
LONG dq
pri DQ@   ( -- 1wmask )            dq @ ;
pub DQ!    ( 1wpin -- )    MASK   dq ! ;
#P16  DQ!                        \ set the default

: @1W_ID          ( -- )   #P16 DQ! ;
: @1W_TEMP    ( -- )   #P17 DQ! ;

\ ---------------------------------------

[Brian Riley]

I was working today on some 1-Wire stuff. It turned out that I had several unused pins and life would be simpler with two different 1W busses ... so I put my new found knowledge from the other day to work and came up with these mods to the 1-Wire I/O Defs. They work perfectly and required no changes to anything else.

... Peter ... are there any hidden land mines in what I've done here????

( I/O DEFINITIONS )

{ OLD CODE
LONG dq
pri DQ@                dq @ ;
pub DQ!                dq ! ;
#P16 |< DQ!                        \ set the default
}

\ ----- I/O Defs & redirection words (new code) -----

#P16 |< CONSTANT DQ		\ set default 

pri DQ@	( -- )			' DQ 1+ @ ;
pub DQ!	( 1wpin -- )	MASK ' DQ 1+ ! ;

: @1W_ID	( -- )	#P16 DQ! ;
: @1W_TEMP	( -- )	#P17 DQ! ;

\ ---------------------------------------

[Iamretired]

I greatly appreciate the comments from D.P. and Peter: I understand them. I first saw what I thought was an anomaly while examining the stack using .S and .. Thank you for you patience, comments and advice.

John

[Peter Jakacki]

Everyone has been very helpful, but I am still left with the same questions.

Given the stack contents after a reset (an initial condition) and after loading stack with 12 11 10 .....3 2 1 , why the unexpected result?

I have a problem understanding the Data Stack. The Introduction to TACHYON FORTH has a table that seems to say the stack is limited to 12 elements;
At initial startup I get
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: FFFFF9FF 00000000 00000000 00000000
01AC: 00000000 00000000 00000000 00000000
01B0: 00000000 00000000
What is FFFFF9FF at address 01A8?

I put on the stack 12 11 ........ 2 1 and did a ^D DEBUG.
12 11 10 9 8 7 6 5 4 3 2 1 ok
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: 00000001 00000002 00000003 00000004
01AC: 00000005 00000005 00000005 00000005
01B0: 00000005 00000005
I don't fully understand what I see. The 12 elements are evident and the first column appear to be addresses with the first element containing its own address. I don't know why 01A7 contains 00000004 or why my TOS is 01A8, and 01AC to 01B1 contains 00000005 ( where is 00000006 and 7 thru 12? ) .

I am not questioning why it was designed this way. I want to know if there is a bug causing my unexpected result or as the questions above indicate 'what can I infer from the DEBUG listing?

Thank you,
Johnmb

I think D.P. did well by way of reply and what he says is correct. Sometimes one can get so focused on some perceived eccentricity which is not a bad thing in itself but if that same energy were instead utilized in the direction you want to go in then you would certainly progress despite these eccentricities and anomalies. The difference is that energy is being expended on the study of the implementation of the platform rather than on implementing onto that platform. The first one will get you steamed up whereas the second approach will get the steam up (D.P.’s project)

However I will provide an answer to your question although it is academic and has no real bearing on development itself.

The stack is 12 longs deep and you push 12 numbers onto it:
12 11 10 9 8 7 6 5 4 3 2 1 ok

Then type a ^D for DEBUG (BTW, your stack address indicates you have a slightly earlier version of Tachyon)

DATA STACK
01A8: 000001A8 00000001 00000002 00000003
01AC: 00000004 00000005 00000006 00000006
01B0: 00000006 00000006 00000006 00000006

Just to check the stack manually we could also print each item out:
12 11 10 9 8 7 6 5 4 3 2 1 ok
. 1 ok
. 2 ok
. 3 ok
. 4 ok
. 5 ok
. 6 ok
. 6 ok
. 6 ok
. 6 ok
. 6 ok
. 6 ok
. 6 ok

Notice the difference immediately as the 01A8 (sames as the TOS address) only exists in the DEBUG version and you will find that this is DEBUG itself using the same stack that you are trying to test, you need to take this into consideration. However the second version also shows that the stack must have had up to six levels of parameters pushed onto it forcing the 12 11 10 9 8 7 to “fall off” and then afterwards as the stack is progressively popped again while the bottom most item 6 is simply copied but not written (from where?). So at some point the same stack was being used and looked a bit like this:
(TOP OF STACK)
temp working value
temp working value
temp working value
temp working value
temp working value
temp working value
1
2
3
4
5
6
(BOTTOM OF STACK)

12 to 7 were simply overwritten one by one on the bottom of the stack as more items were added.
After a pop it would look like this:
(TOP OF STACK)
temp working value
temp working value
temp working value
temp working value
temp working value
1
2
3
4
5
6
6 ← the bottom value does not get changed during a pop
(BOTTOM OF STACK)

Then by the end we end up with what we did.

Have you ever tried to test your multimeter by getting it to measure it’s own battery? Well it won’t work the way you expect for very good reason but that does not mean the meter is faulty, just your reasoning.

BTW, My very first version of Tachyon had DEBUG and all the hex dump stuff written in PASM to help debug the nascent kernel and so DEBUG would not consume any stack resources as it used it’s own cog registers (and cog memory for code) and so you would see the stack just as it really was. But once the kernel started to grow the debug routines were hogging precious cog resources that were required for....you know...actual runtime operations. There would be no problem with a Forth written on an ARM processor having a really deep stack and a non-intrusive DEBUG but that’s another kettle of fish, well actually only one fish whereas the Prop is a kettle of fish.

So as D.P. says don’t get stuck on the details of the crumbs, just start using it as it is meant to be used.

[D.P]

Everyone has been very helpful, but I am still left with the same questions.
Given the stack contents after a reset (an initial condition) and after loading stack with 12 11 10 .....3 2 1 , why the unexpected result?

I have a problem understanding the Data Stack. The Introduction to TACHYON FORTH has a table that seems to say the stack is limited to 12 elements;
At initial startup I get
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: FFFFF9FF 00000000 00000000 00000000
01AC: 00000000 00000000 00000000 00000000
01B0: 00000000 00000000
What is FFFFF9FF at address 01A8?

I put on the stack 12 11 ........ 2 1 and did a ^D DEBUG.
12 11 10 9 8 7 6 5 4 3 2 1 ok
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: 00000001 00000002 00000003 00000004
01AC: 00000005 00000005 00000005 00000005
01B0: 00000005 00000005
I don't fully understand what I see. The 12 elements are evident and the first column appear to be addresses with the first element containing its own address. I don't know why 01A7 contains 00000004 or why my TOS is 01A8, and 01AC to 01B1 contains 00000005 ( where is 00000006 and 7 thru 12? ) .

I am not questioning why it was designed this way. I want to know if there is a bug causing my unexpected result or as the questions above indicate 'what can I infer from the DEBUG listing?

Thank you,
Johnmb

As Peter said the CONSOLE on which you are talking is using stack space, plus all the other magic that dumps the DEBUG to the CONSOLE.

Why don't you just start pushing, popping, swapping, rotating the stack with a few numbers. I can never keep more than three parameters together in my head as is. If you insist on being stuck on the details of the crumbs left in the stack by the CONSOLE and DEBUG you just won't make any progress. Have you run all the examples from Peter's intro page? Made the noises? Printed the Stars? Grabbed a chip and .fth file from the list of demo code breadboard the chip and got it working? Have you seen the power of talking SPI, I2C, Serial directly to the chip from the console. Doing this with my logic analyzer next to me has saved me untold man hours of life expectancy.

Did you see the graphics screen I'm working on? I never bothered to find out why my CONSOLE cog has stack crumbs in it and they have never stopped me or caused any issue. If I need to step through code I just put 0 0 0 0 on the stack and start stepping. Then I use .S to non destructively (nothing gets popped) show my stack manipulations. If my code does something wrong or unexpected I can post it here and either tachyon will be fixed or my code will be corrected (much more likely)

To me FORTH is not a language, it is a development enviroment that is Hardware and Software specific i.e. each one is a little different. Tachyon is not ANSI FORTH as you know, it is a way of creating embedded devices using the prop chip's unique features and a very FORTHish way of development. Oh and it is fast, I was updating my clock on that graphics screen using KEYPOLL, little did I know it would call my routine in the backgound about 20,000 times a second, not quite a lazy update and it started to swamp the async serial line. I had to break my routine so it was only run once every 20,000 times it was called. Mind you I still have 5 free cogs all waiting to run more Tachyon code and the CONSOLE to control them all.

What do you want to build/make using Tachyon/Forth and the Prop/s chip?

Willing to help, share

[Iamretired]

Everyone has been very helpful, but I am still left with the same questions.
Given the stack contents after a reset (an initial condition) and after loading stack with 12 11 10 .....3 2 1 , why the unexpected result?

I have a problem understanding the Data Stack. The Introduction to TACHYON FORTH has a table that seems to say the stack is limited to 12 elements;
At initial startup I get
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: FFFFF9FF 00000000 00000000 00000000
01AC: 00000000 00000000 00000000 00000000
01B0: 00000000 00000000
What is FFFFF9FF at address 01A8?

I put on the stack 12 11 ........ 2 1 and did a ^D DEBUG.
12 11 10 9 8 7 6 5 4 3 2 1 ok
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: 00000001 00000002 00000003 00000004
01AC: 00000005 00000005 00000005 00000005
01B0: 00000005 00000005
I don't fully understand what I see. The 12 elements are evident and the first column appear to be addresses with the first element containing its own address. I don't know why 01A7 contains 00000004 or why my TOS is 01A8, and 01AC to 01B1 contains 00000005 ( where is 00000006 and 7 thru 12? ) .

I am not questioning why it was designed this way. I want to know if there is a bug causing my unexpected result or as the questions above indicate 'what can I infer from the DEBUG listing?

Thank you,
Johnmb

[Peter Jakacki]

http://www.youtube.com/watch?v=P8Xr1p2qfPs

Says it all.

Thanks Peter

and @ LR, I didn't know anything about FORTH befor Tachyon (except that my mentor told me I'd better learn long ago) and now I am writing basic drivers with Peter's et al help and this fabulous forum. So LR just dive in and start blinking lights, making sounds, talking to chps and don't get hung up with all the details for now. As you learn more FORTH and TACHYON study EXTEND.fth and ask questions.

The video shows Tachyon on a Prop 1 running a RTC, 8 Channel ADC and driving the touch screen controlling a FORTH level tool i.e. steam. The clock is being updated lazy style using KEYPOLL.

I've got so many COGs and so much code space left I'm just in awe. Even while KEYPOLL is updating the clock I am able to interacte completely with the hardware, who needs a debugger, Tachyon is in circuit debugger.

Yes you could do all of this in spin, pasm, gcc but I bet it's not as fun (or as easy to debug). And when Prop2 comes out I don't need no fancy pasm2 or spin2 learning, just Tachyon P2 I hope.


Now for a walk and a celebratory beer, cheers Peter.

Nice looking screen there, you will have to let us know when you do a video of it in operation mit der "spitzensparken" und mit der Dampf und mit der blinklichter. Does it brew beer or do we have to get our own?

[MJB]

snip ...
I am learning FORTH
I don't know if you meant the following for me

3. TACHYON is NOT the right vehicle for stack heavy e.g. recursive algorithms

Correct, because TACHYON is designed for speed and to suit the Propeller's unique cog/hub architecture. It is a very very easy matter to have a deep stack in hub RAM but while that may be good for CS101 exercises what is more important for embedded applications is the speed. I also wanted to avoid any inline LMM style PASM code because it's either encoded as numeric mumbo-jumbo or requires a resource hungry inline assembler. Once again the actual embedded use wins over any CS exercise for which a PC is much better suited.

I am not doing CS101 exercises, and from your reply it appears I may not be your intended audience.
Let me know if I am not and I will go another route.

Johnmb

Hi John,
this depends on what you are after.
If you are interested in embedded work, blinking LEDs ;-) etc.
then your place is here - no better combination around than Prop + TACHYON
(also simple is AVR + BASCOM compiler ...)

but if you are learing FORTH to be able to use every FORTH then you might be better on a PC with a 'standard' FORTH.
Tachyon and PropForth (to a lesser extend) while being based on the FORTH idea, have quite a lot of specialties
due to the special Propeller architecture. If you don't want to do embedded on the propeller, there is no need to learn all
those specifics.
And the stack size is just one of them.
my2c
Markus

[Peter Jakacki]

We have had a lot code involving the use of the TICK on this page like this example of updating a CONSTANT from Markus

$01020304 == CB
CB .
5 ' CB 1+ !
CB .
$0102 ' CB 2 + !
CB .
$010203 ' CB 3 + !
CB .
$01020304 ' CB 4 + !
CB .

A couple of questions

1 -- what exactly does the TICK do for you that leaving it out won't do?

2 -- What is the general guideline for when to use it??

The tick is an immediate word in Forth and normally parses the following word to find it in the dictionary and pass the address of the code or parameter field. If it doesn't find it then it will return with a null rather than any error, this is intentional as I like to leave the error reporting to another layer.

Tachyon works differently and also there is no real distinction between parameter an code field addresses as Tachyon assumes that whatever is pointed to is bytecode, that's why constants have a bytecode instuction which is aligned to just before a long boundary as all constants are treated as longs and the the PASM instruction RDLONG ignores the 2 lsbs of the address which is why Markus' experiments seem to magically work. So remember the tick of a constant actually returns with the address just before a long boundary, the 1+ then makes it point to the start of the long where the constant is stored, and adding 4 instead simply points to the end of a long but RDLONG simply ignores the 2 lsbs of the address anyway.

You need to use tick anytime you need to know the absolute address in memory of the function such as when you want to run a task for instance you must pass the address of the function. Simply invoking the function will let it do whatever it is supposed to do but you really just want the address of it. Variables automatically return with the address of the storage location but they still need to be stored or fetched. Constants always fetch a long rather than the address of the long. If we want to force this constant to another value as in the case of pin redirection then we need to know the address of the storage location which is always one more than the address of the constant function.

[Brian Riley]

We have had a lot code involving the use of the TICK on this page like this example of updating a CONSTANT from Markus

$01020304 == CB
CB .
5 ' CB 1+ !
CB .
$0102 ' CB 2 + !
CB .
$010203 ' CB 3 + !
CB .
$01020304 ' CB 4 + !
CB .

A couple of questions

1 -- what exactly does the TICK do for you that leaving it out won't do?

2 -- What is the general guideline for when to use it??

[D.P]

http://www.youtube.com/watch?v=P8Xr1p2qfPs

Says it all.

Thanks Peter

and @ LR, I didn't know anything about FORTH befor Tachyon (except that my mentor told me I'd better learn long ago) and now I am writing basic drivers with Peter's et al help and this fabulous forum. So LR just dive in and start blinking lights, making sounds, talking to chps and don't get hung up with all the details for now. As you learn more FORTH and TACHYON study EXTEND.fth and ask questions.

The video shows Tachyon on a Prop 1 running a RTC, 8 Channel ADC and driving the touch screen controlling a FORTH level tool i.e. steam. The clock is being updated lazy style using KEYPOLL.

I've got so many COGs and so much code space left I'm just in awe. Even while KEYPOLL is updating the clock I am able to interacte completely with the hardware, who needs a debugger, Tachyon is in circuit debugger.

Yes you could do all of this in spin, pasm, gcc but I bet it's not as fun (or as easy to debug). And when Prop2 comes out I don't need no fancy pasm2 or spin2 learning, just Tachyon P2 I hope.


Now for a walk and a celebratory beer, cheers Peter.

[Iamretired]

Thank for your replies. I am learning FORTH so I don't anticipate 'heavy stack usage' .

I don't know if you meant the following for me

3. TACHYON is NOT the right vehicle for stack heavy e.g. recursive algorithms

Correct, because TACHYON is designed for speed and to suit the Propeller's unique cog/hub architecture. It is a very very easy matter to have a deep stack in hub RAM but while that may be good for CS101 exercises what is more important for embedded applications is the speed. I also wanted to avoid any inline LMM style PASM code because it's either encoded as numeric mumbo-jumbo or requires a resource hungry inline assembler. Once again the actual embedded use wins over any CS exercise for which a PC is much better suited.

I am not doing CS101 exercises, and from your reply it appears I may not be your intended audience.
Let me know if I am not and I will go another route.

Johnmb

[Peter Jakacki]

I had the same question last year ...

what happens is:
DEBUG and the PRINT routines use the stack themselves and push things down,
Since Tachyon does NOT give stack overflow errors it just pushes and pushes
when you pop the lowest stack value is duplicated - and not filled with 0

This means you can not expect to be able to use 12 stack entries for your program.
You can easily create variables, arrays, tables ... if you need to store temp variables

TACHYON is NOT the right vehicle for stack heavy e.g. recursive algorithms

1. This means you can not expect to be able to use 12 stack entries for your program.

True and false. When anorther cog is running your program then the full stack is available, the same is true if your code is running in turnkey mode. However if you are sitting at the console interacting with your code then the console routines require stack space too, as does the DEBUG word.

2. You can easily create variables, arrays, tables ... if you need to store temp variables

Also take a look at the use of locals in EXTEND.fth as this will move the stack parameters into variables which are referenced as if they were constants X1 X2 X3 X4. Personally I detest deep stacks and the use of PICK and ROLL as their use obfuscate the operation of the program and mentally juggling the stack in your head when you write the code is bad enough but can you understand what it is doing afterwards?

3. TACHYON is NOT the right vehicle for stack heavy e.g. recursive algorithms[/QUOTE]

Correct, because TACHYON is designed for speed and to suit the Propeller's unique cog/hub architecture. It is a very very easy matter to have a deep stack in hub RAM but while that may be good for CS101 exercises what is more important for embedded applications is the speed. I also wanted to avoid any inline LMM style PASM code because it's either encoded as numeric mumbo-jumbo or requires a resource hungry inline assembler. Once again the actual embedded use wins over any CS exercise for which a PC is much better suited.

[Brian Riley]

I almost have it licked but there's one thing that escapes me .... observe the console log below. I setup a few words to show how SCL/SDA get manipulated I can use EPROM and SI114 which use I2CPINS to correctly leaves the proper pair of pinmasks on the top of the stack. Then I try EEPROM and that works also. So then I create SI14X, which 'should be' EEPROM's functional equivalent for pins 14/15 it doesn't work ... it just leaves the pin #'s on the stack. Now I call the .PP word at the end of each test sequence, dumping the values of each of the #P-pins in question ... they never change ... EEPROM should not work, but it does ... WHY??? SI14X doesn't work .....and it shouldn't ... HOW TO MAKE IT WORK ??? or just use the routines that use I2CPINS???

tnx ... BBR

  Propeller .:.:--TACHYON--:.:. Forth V21130620.0000

NAMES:  $603D...7444 for 5127 (19942 bytes added) with 22225 bytes free
CODE:   $0000...2C36 for 6191 (0529 bytes added) with 21450 bytes free
CALLS:  0575 vectors free

AUTORUN BOOT
MODULES LOADED:
2A25: EXT_BBR.fth         BASE BBR Extensions   - 20130605.0000
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 130701.2000
----------------------------------------------------------------
  ok
: .I2CX SCL SDA .S 2DROP .S ;  ok
  ok
:  EPROM         ( sda scl -- ) #P29  #P28 I2CPINS ;  ok
:  SI114         ( sda scl -- ) #P15  #P14 I2CPINS ;  ok
  ok
: .PP            ( -- ) #P29 . SPACE  #P28 . SPACE  #P15 . SPACE  #P14 . SPACE ;  ok
.PP 1D 1C F E  ok
.I2CX
STACK: 00000000 FFFFF9FF 10000000 20000000
STACK: 00000000 00000000 00000000 FFFFF9FF  ok
  ok
.PP 1D 1C F E  ok
SI114 .I2CX .PP
STACK: 00000000 FFFFF9FF 00004000 00008000
STACK: 00000000 00000000 00000000 FFFFF9FF 1D 1C F E  ok
EEPROM .I2CX .PP
STACK: 00000000 FFFFF9FF 10000000 20000000
STACK: 00000000 00000000 00000000 FFFFF9FF 1D 1C F E  ok
  ok
: SI14X #P15 #P14 ;  ok
  ok
SI14X  .I2CX .PP
STACK: 0000000F 0000000E 10000000 20000000
STACK: 00000000 FFFFF9FF 0000000F 0000000E 1D 1C F E  ok

[MJB]

@lamretired

I had the same question last year ...

what happens is:
DEBUG and the PRINT routines use the stack themselves and push things down,
Since Tachyon does NOT give stack overflow errors it just pushes and pushes
when you pop the lowest stack value is duplicated - and not filled with 0

This means you can not expect to be able to use 12 stack entries for your program.
You can easily create variables, arrays, tables ... if you need to store temp variables

TACHYON is NOT the right vehicle for stack heavy e.g. recursive algorithms

[MJB]

@BBR see how to rewrite a CONSTANT below

@Peter ...
I can not understand what you are writing about REWRITEABLE CONSTANTS
BUT from your source it looks quite simple:

I use this 'hack' to rewrite the constant value - seems to work

$01020304 == CB
CB .
5 ' CB 1+ !
CB .
$0102 ' CB 2 + !
CB .
$010203 ' CB 3 + !
CB .
$01020304 ' CB 4 + !
CB .

why it works this way is an interesting topic

In general works

newval ' CONSTNAME 4 + !    correctly  with one, two, 3 and 4 byte values 

it is anyhow just the TOS that gets stored.
so the magic above comes from the internals of !, which does a LONG
alignment internally

[Iamretired]

I have a problem understanding the Data Stack. The Introduction to TACHYON FORTH has a table that seems to say the stack is limited to 12 elements;
At initial startup I get
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: FFFFF9FF 00000000 00000000 00000000
01AC: 00000000 00000000 00000000 00000000
01B0: 00000000 00000000
What is FFFFF9FF at address 01A8?

I put on the stack 12 11 ........ 2 1 and did a ^D DEBUG.
12 11 10 9 8 7 6 5 4 3 2 1 ok
^D DEBUG
DATA STACK
01A6: 000001A6 00000004
01A8: 00000001 00000002 00000003 00000004
01AC: 00000005 00000005 00000005 00000005
01B0: 00000005 00000005
I don't fully understand what I see. The 12 elements are evident and the first column appear to be addresses with the first element containing its own address. I don't know why 01A7 contains 00000004 or why my TOS is 01A8, and 01AC to 01B1 contains 00000005 ( where is 00000006 and 7 thru 12? ) .
Thank you,
Johnmb

[MJB]

I was offline for a short while and many new posts here
and interestingly a CONSTANT vs. VARIABLE theme as well ...

I hat a PM with Peter that triggered some 'research' that I will show here if s.o is interested

\ test  declaring CONSTANTs vs inline constants

\ !!! the following contains a major thought ERROR 
\ !!! I hope you can find it.
\ !!! if not see solution at bottom ;-)

: TCiByte NEWCNT $46 LAPCNT .DEC ;
: TCiWord NEWCNT $4647 LAPCNT .DEC ;
: TCi3Byte NEWCNT $464748 LAPCNT .DEC ;
: TCiLong NEWCNT $46474849 LAPCNT .DEC ;
TCiByte  \ 0008 ok in us
TCiWord  \ 0009 ok
TCi3Byte \ 0009 ok
TCiLong  \ 0010 ok
NEWCNT LAPCNT .DEC \ 0007 ok  empty block timing

\ ==== test with variables ====
BYTE tb1
$46 tb1 C!
WORD tw1
$4647 tw1 W!
LONG tl1
$46474849 tl1 !

: TCcByte NEWCNT tb1 LAPCNT .DEC ;
: TCcWord NEWCNT tw1 LAPCNT .DEC ;
: TCcLong NEWCNT tl1 LAPCNT .DEC ;

TCcByte     \ 0009 ok
TCcWord       \ 0009 ok
TCcLong     \ 0009 ok

NEWCNT #1000 FOR NEXT LAPCNT .DEC CR           \ 0412 ok
\ pushing 1000 times on stack will overflow, but Tachyon just ignores this ...
NEWCNT #1000 FOR $46 NEXT LAPCNT .DEC CR       \ 2012 ok  ->  1.6us
NEWCNT #1000 FOR $4647 NEXT LAPCNT .DEC CR     \ 2612 ok  ->  2.2us
NEWCNT #1000 FOR $464748 NEXT LAPCNT .DEC CR   \ 3212 ok  ->  2.8us
NEWCNT #1000 FOR $46474849 NEXT LAPCNT .DEC CR \ 3812 ok  ->  3.4us
NEWCNT #1000 FOR tb1 NEXT LAPCNT .DEC CR       \ 3012 ok  ->  2.6us
NEWCNT #1000 FOR tw1 NEXT LAPCNT .DEC CR       \ 3012 ok  ->  2.6us
NEWCNT #1000 FOR tl1 NEXT LAPCNT .DEC CR       \ 3012 ok  ->  2.6us

\  results:  byte and word inline constants execute faster then 
\  variable access. But 3 byte and 4 byte/long inlines are slower.    
    
\ ==== test with constants ====
$46 == tb1 
$4647 == tw1 
$46474849 == tl1

: TCcByte NEWCNT tb1 LAPCNT .DEC ;
: TCcWord NEWCNT tw1 LAPCNT .DEC ;
: TCcLong NEWCNT tl1 LAPCNT .DEC ;

TCcByte           0010 ok
TCcWord           0010 ok
TCcLong            0010 ok

NEWCNT #1000 FOR tb1 NEXT LAPCNT .DEC CR      \ 3412 ok  ->  3 us
NEWCNT #1000 FOR tw1 NEXT LAPCNT .DEC CR      \ 3412 ok  ->  3 us
NEWCNT #1000 FOR tl1 NEXT LAPCNT .DEC CR      \ 3412 ok  ->  3 us

\ interrestingly CONSTANTS seem to be a little slower than variables
\ the exercise to have a look at the TACHYON source to see why is left to the reader ;-)


\ so what is the effect on memory size then?  (Peter please correct if required)

\ inline constants are compiled a one BYTEcode plus the number of bytes required (1..4)
\ access to a variable compiles as one BYTEcode 

\ OK here is the solution to the above question WHERE IS THE ERROR???

\ giving the NAME of a VARIABLE of course does NOT give the VALUE
\ but only the ADDRESS (the variable does not 'know' it's size without
\ a complicated check in the dict, where the next word starts
\ this is probably the reason Tachyon does not care about it.
\ It is left to the programmer to use the correct access operator C@,W@,@ C!,W!,!

\ !! - this gives way to have word or byte access to a long variable !! 
LONG LL  
$01020304 LL !  
LL  .       \   29F0  ok      the address of LL
LL @ .      \ 1020304 ok
LL C@ .     \ 4 ok           
LL W@ .     \ 304 ok 
LL 1+ C@ .  \ 3 ok
LL 1+ W@ .  \ 304 ok     ---  this is interesting - W@ fetches word aligned !!!

\  so again the timing test from above for the VARIABLES

\ ==== test with variables AGAIN - hopefully correct now !!! ====
BYTE tb1
$46 tb1 C!
WORD tw1
$4647 tw1 W!
LONG tl1
$46474849 tl1 !

: TCcByte NEWCNT tb1 C@ LAPCNT .DEC ;
: TCcWord NEWCNT tw1 W@ LAPCNT .DEC ;
: TCcLong NEWCNT tl1 @ LAPCNT .DEC ;

TCcByte     \ 0010 ok
TCcWord       \ 0010 ok
TCcLong     \ 0010 ok

NEWCNT #1000 FOR NEXT LAPCNT .DEC CR           \ 0412 ok
\ pushing 1000 times on stack will overflow, but Tachyon just ignores this ...
NEWCNT #1000 FOR $46 NEXT LAPCNT .DEC CR       \ 2012 ok  ->  1.6us
NEWCNT #1000 FOR $4647 NEXT LAPCNT .DEC CR     \ 2612 ok  ->  2.2us
NEWCNT #1000 FOR $464748 NEXT LAPCNT .DEC CR   \ 3212 ok  ->  2.8us
NEWCNT #1000 FOR $46474849 NEXT LAPCNT .DEC CR \ 3812 ok  ->  3.4us
NEWCNT #1000 FOR tb1 C@ NEXT LAPCNT .DEC CR    \ 3012 ok  ->  2.6us correct is 3412 = 3us
NEWCNT #1000 FOR tw1 W@ NEXT LAPCNT .DEC CR    \ 3012 ok  ->  2.6us correct is 3412 = 3us
NEWCNT #1000 FOR tl1 @ NEXT LAPCNT .DEC CR     \ 3012 ok  ->  2.6us correct is 3412 = 3us

\  results:  byte and word and 3-byte inline constants execute faster then 
\  variable access. But 4 byte/long inlines are slower.    
\  
\  so defined constants execute as fast as variables with the convenience
\  of saving the @ operators.

[D.P]

The CONSTANT is being used as a rewritable constant or if you like to look at it this way it happens to be a variable that automatically reads its contents without requiring a fetch, although I think that might sound confusing. By using a constant in the first place I can declare its value at compile time whereas a variable needs to be loaded with a default and as mentioned a variable always requires a fetch operation. Most of the time we simply want the value and we don't really care about changing it. What happens if I change SCL and SDA to variables? Then the bulk of the code will be pushing the address of the variable to the stack and then fetching the contents of that address thereby replacing the address on the stack with the value. A constant simply pushes that value onto the stack in one operation and this is less convoluted IMO than using a variable. But by all means a variable could be used but I prefer the rewritable constant method for pin definitions.

Looking at the code you may also be confused by the definition of SCL and SDA as they are already set at compile to the default I2C pins.
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

Then in BACKUP I'm setting those same constants back to their default values, what gives? That's because your SI114 word might change the value of the constants and now we need them changed back to the default for the EEPROM. When we execute BACKUP we need to talk to the EEPROM as that is where we are backing up to. Sure, it might already be set to P28 and P29 but we are making sure, as it is good practice to do so and really is neither here nor there in terms of speed.

Now you both have me confused. I like to step through code and watch how the stack is modified.

Doing so with this code has me perplexed.

EEPROM      \  doesn't push anything but is defined as #P28 #P29   ?
0 0 NFA' *end*    \ pushes a couple 0s and $744C    okay with that
$40 ALIGN     \  creates $7480   okay with that
OVER        \    okay so now the stack looks like  (0  0 7480 0 -- )
-                \   and we get ( 0 0 0 7480 )    
ESAVE    \   ESAVE ( ram eeprom cnt -- )   use ram 0 eeprom 0 and cnt of 7480   okay

So my question is why doesn't the word EEPROM set the constants like

#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

instead we have #P28 #P29 in the definition of EEPROM? Extend - Primary extensions to TACHYON kernel - 130607.1600

[Peter Jakacki]

CONSTANTs/VARIABLEs ... it seems to me we had this conversation already, but indulge me a bit, if you would ... in effect the CONSTANT is being used as if it were a VARIABLE ???

I did grasp why EEPROM is used in BACKUP, but what escapes me is how EEPROM works with the subsequent line of code.

pub BACKUP
        EEPROM
        0 0 NFA' *end* $40 ALIGN OVER - ESAVE
        ;

Pardon me here for getting a little lost, but I looked over all the code I quoted and I am not sure which to use to implement my EEPROM / SI114 switching.

tnx ... BBR

The CONSTANT is being used as a rewritable constant or if you like to look at it this way it happens to be a variable that automatically reads its contents without requiring a fetch, although I think that might sound confusing. By using a constant in the first place I can declare its value at compile time whereas a variable needs to be loaded with a default and as mentioned a variable always requires a fetch operation. Most of the time we simply want the value and we don't really care about changing it. What happens if I change SCL and SDA to variables? Then the bulk of the code will be pushing the address of the variable to the stack and then fetching the contents of that address thereby replacing the address on the stack with the value. A constant simply pushes that value onto the stack in one operation and this is less convoluted IMO than using a variable. But by all means a variable could be used but I prefer the rewritable constant method for pin definitions.

Looking at the code you may also be confused by the definition of SCL and SDA as they are already set at compile to the default I2C pins.
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

Then in BACKUP I'm setting those same constants back to their default values, what gives? That's because your SI114 word might change the value of the constants and now we need them changed back to the default for the EEPROM. When we execute BACKUP we need to talk to the EEPROM as that is where we are backing up to. Sure, it might already be set to P28 and P29 but we are making sure, as it is good practice to do so and really is neither here nor there in terms of speed.

[Brian Riley]

There's no need to recode anything as setting the pin constants only takes microseconds and the real delay is just the I2C timing itself (400kHz). So your second I2C bus should be coded just as you have shown and there is no need to worry about getting rid of anything or other optimizations. I use a secondary I2C bus in one design simply because I had those extra pins on a header.

The reason that BACKUP uses the EEPROM word is simply because it can only backup to the EEPROM on the default I2C bus and because I allow for redirection we want to force it back to the default state. If it didn't and some of your code had redirected the I2C pins then BACKUP would fail as it would not be able to find the EEPROMs and even if it did find "a" EEPROM then it would be of no use as it would not be the same EEPROM that the Prop boots from. Capice?

Now getting back to this constants vs variables thing to tell the truth it's "much of a muchness" in that they both end up doing the same thing. The beauty about constants is that they read cleanly in code and there is one less operation as variables need to be fetched from their address. In V3 I will look at compile time optimizations which could see the sequence " ' SCL 1+ " which at present compiles to an inline literal plus an increment at runtime but in V3 would simply compile the incremented literal. However this once again is not totally necessary as Tachyon is very fast and the increment operation only takes an extra one byte and 400ns so it would only really be a concern if it were in a long loop.

CONSTANTs/VARIABLEs ... it seems to me we had this conversation already, but indulge me a bit, if you would ... in effect the CONSTANT is being used as if it were a VARIABLE ???

I did grasp why EEPROM is used in BACKUP, but what escapes me is how EEPROM works with the subsequent line of code.

pub BACKUP
        EEPROM
        0 0 NFA' *end* $40 ALIGN OVER - ESAVE
        ;

Pardon me here for getting a little lost, but I looked over all the code I quoted and I am not sure which to use to implement my EEPROM / SI114 switching.

tnx ... BBR

[D.P]

An alternative is if you have control of the encoding of your data is that you could always have the lsb set so that once you have detected a low all you need to do is WAITPEQ for a high after which you are guaranteed synch.

No determinism and not able to format the output of the device lsb first. I'm only using 9600.

I'll try some of your suggestions.

thanks

GOT IT!!! With interactive Tachyon I was able nail this issue, it may not be pretty (yet) but every receive chksum is correct! Thanks for the hints Peter.

Now to wrap this into it's own task and such, time for a nice walk and relaxation.

[Peter Jakacki]

Latency is always the killer with trying to do other things while waiting for asynch data. In fact if the latency was deterministic you could compensate for it but you have no way of knowing whether you sense a start bit right at the very start or perhaps it's not even the start bit but a data bit. In PASM it's still a problem for higher baud rates but you can get away with doing other things while waiting as long as the baud rate isn't too high. If 115K is pushing it for PASM then even 9600 can be flakey for non-WAITPxx interpreted code.

However, just on the off chance that there may be some determinism in there and that you would be polling somewhere in the start bit I would adjust the start bit verification time from half a bit to around a quarter (or less). This might mean you sample each data bit early but it also gives you more of a margin if the start bit were detected late in it's cycle.

An alternative is if you have control of the encoding of your data is that you could always have the lsb set so that once you have detected a low all you need to do is WAITPEQ for a high after which you are guaranteed synch.

[Peter Jakacki]

I'm trying to poll for async serail for the following bytes:

 
07:40:00:2C:00:2F
WHERE 
07 = cmd byte
40  MSB of obj word
00  LSB of obj word
2C  MSB of value word
00  LSB of value word
2F chksum byte created by XOR-ing the first five bytes

My output side to this device works great, just not having any "luck" with my attempts to use a version of SERIN with WAITLOW to poll for the async data.

Peter you mentioned a mult-port PASM module comming in V3, is there anything I else I can attempt until then? I really gave it a good shot today and learned a bunch more about Tachyon, so time very well spent in my book.

Latency is always the killer with trying to do other things while waiting for asynch data. In fact if the latency was deterministic you could compensate for it but you have no way of knowing whether you sense a start bit right at the very start or perhaps it's not even the start bit but a data bit. In PASM it's still a problem for higher baud rates but you can get away with doing other things while waiting as long as the baud rate isn't too high. If 115K is pushing it for PASM then even 9600 can be flakey for non-WAITPxx interpreted code.

However, just on the off chance that there may be some determinism in there and that you would be polling somewhere in the start bit I would adjust the start bit verification time from half a bit to around a quarter (or less). This might mean you sample each data bit early but it also gives you more of a margin if the start bit were detected late in it's cycle.

[D.P]

I'm trying to poll for async serail for the following bytes:

 
07:40:00:2C:00:2F
WHERE 
07 = cmd byte
40  MSB of obj word
00  LSB of obj word
2C  MSB of value word
00  LSB of value word
2F chksum byte created by XOR-ing the first five bytes

My output side to this device works great, just not having any "luck" with my attempts to use a version of SERIN with WAITLOW to poll for the async data.

Peter you mentioned a mult-port PASM module comming in V3, is there anything I else I can attempt until then? I really gave it a good shot today and learned a bunch more about Tachyon, so time very well spent in my book.

[Peter Jakacki]

On another subject .... for various reasons I have an I2C chip that I want on a separate buss. Now from EXTEND.fth we have

\ 121214        - Replaced I2CPINS using CONSTANT method in place of using variables

 ...

\ I/O "Constants" - variable to allow for redirection
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

\ Assign the Prop's EEPROM pins (default)
pub EEPROM
        #P29 #P28

\ Assign the pins to use for the I2C bus
pub I2CPINS ( sda scl -- )
        MASK ' SCL 1+ !
        MASK ' SDA 1+ !        
        ;

In order to switch I2C between #P29/#P28 and #P15/#P14 Do I need to get rid of SDA/SCL as CONSTANTS and restore them as LONG variables, then code something like ?

:  EEPROM  ( sda scl -- ) #P29  #P28 I2CPINS ;

:  SI114 (sda scl -- ) #P15  #P14 I2CPINS ;

I would imagine things might go faster if I created a set of constants for each buss and did the MASK once only for each.

.... and I don't understand how EEPROM works in BACKUP ...

\ V2 - Backup the current Tachyon Forth session
pub BACKUP
        EEPROM
\        64K? IF 0 $8000 $7FC0 ECOPY THEN        \ backup first 32K of EEPROM if 64 is available
        0 0 NFA' *end* $40 ALIGN OVER - ESAVE
        ;

thanks in advance for any help ... BBR

There's no need to recode anything as setting the pin constants only takes microseconds and the real delay is just the I2C timing itself (400kHz). So your second I2C bus should be coded just as you have shown and there is no need to worry about getting rid of anything or other optimizations. I use a secondary I2C bus in one design simply because I had those extra pins on a header.

The reason that BACKUP uses the EEPROM word is simply because it can only backup to the EEPROM on the default I2C bus and because I allow for redirection we want to force it back to the default state. If it didn't and some of your code had redirected the I2C pins then BACKUP would fail as it would not be able to find the EEPROMs and even if it did find "a" EEPROM then it would be of no use as it would not be the same EEPROM that the Prop boots from. Capice?

Now getting back to this constants vs variables thing to tell the truth it's "much of a muchness" in that they both end up doing the same thing. The beauty about constants is that they read cleanly in code and there is one less operation as variables need to be fetched from their address. In V3 I will look at compile time optimizations which could see the sequence " ' SCL 1+ " which at present compiles to an inline literal plus an increment at runtime but in V3 would simply compile the incremented literal. However this once again is not totally necessary as Tachyon is very fast and the increment operation only takes an extra one byte and 400ns so it would only really be a concern if it were in a long loop.

[Brian Riley]

On another subject .... for various reasons I have an I2C chip that I want on a separate buss. Now from EXTEND.fth we have

\ 121214        - Replaced I2CPINS using CONSTANT method in place of using variables

 ...

\ I/O "Constants" - variable to allow for redirection
#P28 |< CONSTANT SCL
#P29 |< CONSTANT SDA

\ Assign the Prop's EEPROM pins (default)
pub EEPROM
        #P29 #P28

\ Assign the pins to use for the I2C bus
pub I2CPINS ( sda scl -- )
        MASK ' SCL 1+ !
        MASK ' SDA 1+ !        
        ;

In order to switch I2C between #P29/#P28 and #P15/#P14 Do I need to get rid of SDA/SCL as CONSTANTS and restore them as LONG variables, then code something like ?

:  EEPROM  ( sda scl -- ) #P29  #P28 I2CPINS ;

:  SI114 (sda scl -- ) #P15  #P14 I2CPINS ;

I would imagine things might go faster if I created a set of constants for each buss and did the MASK once only for each.

.... and I don't understand how EEPROM works in BACKUP ...

\ V2 - Backup the current Tachyon Forth session
pub BACKUP
        EEPROM
\        64K? IF 0 $8000 $7FC0 ECOPY THEN		\ backup first 32K of EEPROM if 64 is available
        0 0 NFA' *end* $40 ALIGN OVER - ESAVE
        ;

thanks in advance for any help ... BBR

[MJB]

I do happen to have those modules in question but with nRF24L01s although I have never bothered to use them. Trying to port the obex code to Forth would be ugly and not very readable or efficient even if you got it to work. However looking at the datasheet it seems straightforward enough to interface this chip. I've started a Google document just to show you how I would go about it. I start off by looking at the signals, defining these, copying in the timing diagrams for reading and writing, and then writing the words to perform this low level function. In this case I decided to use the ESPIO module as I can configure that for 1 to 32 bits but in this case it is set for 8 bits so I can send 3 bytes. Of course I could have merged the bits as well and set it for 24 bit transfers. So this is where I'm at after not more than 15 minutes of work.

My thinking was in the same direction (maybe I already learned s.th. following your thread and code ;-) ... )
an I was just searching the files with your dropbox code and this thread for ESPIO, but could not find a good example.
Just was about to start from the little description in tachyon.spin.
So thanks for the start. I am following an implementation in BASCOM, the AVR basic compiler by MCSelec.com,
which I can read almost like mother tongue - and of course the datasheets I had downloaded.

Looking at someone else's code can be useful but also confusing so I try not to be confused. However sometimes when you have things well along it sometimes helpful to peer over their shoulder so to speak and compare so as to see if there some ideas that can be incorporated. Once you are at this stage it is not so confusing to look at someone else's code and you are more able to see through the clutter.

Anyway, have a look at this document and if you would like to add to it in similar fashion then just email/pm me for editing privileges. I might not have much time to play with it but I can help move it along in hopefully the best direction.

[D.P]

I do happen to have those modules in question but with nRF24L01s although I have never bothered to use them. Trying to port the obex code to Forth would be ugly and not very readable or efficient even if you got it to work. However looking at the datasheet it seems straightforward enough to interface this chip. I've started a Google document just to show you how I would go about it. I start off by looking at the signals, defining these, copying in the timing diagrams for reading and writing, and then writing the words to perform this low level function. In this case I decided to use the ESPIO module as I can configure that for 1 to 32 bits but in this case it is set for 8 bits so I can send 3 bytes. Of course I could have merged the bits as well and set it for 24 bit transfers. So this is where I'm at after not more than 15 minutes of work.

Looking at someone else's code can be useful but also confusing so I try not to be confused. However sometimes when you have things well along it sometimes helpful to peer over their shoulder so to speak and compare so as to see if there some ideas that can be incorporated. Once you are at this stage it is not so confusing to look at someone else's code and you are more able to see through the clutter.

Anyway, have a look at this document and if you would like to add to it in similar fashion then just email/pm me for editing privileges. I might not have much time to play with it but I can help move it along in hopefully the best direction.

Really nice layout Peter, I will try to follow this style when preparing my Tachyon code for general consumption.

[Peter Jakacki]

anybody already did / is thinking about a driver for the
nRF24L01+ Module

in TACHYON ?

there might be a way to use the OBEX code here.
http://forums.parallax.com/showthrea...nRF2401A/page3

but given TACHYONs fast SPI functions it might be better to implement it the FORTH-way.

Markus

I do happen to have those modules in question but with nRF24L01s although I have never bothered to use them. Trying to port the obex code to Forth would be ugly and not very readable or efficient even if you got it to work. However looking at the datasheet it seems straightforward enough to interface this chip. I've started a Google document just to show you how I would go about it. I start off by looking at the signals, defining these, copying in the timing diagrams for reading and writing, and then writing the words to perform this low level function. In this case I decided to use the ESPIO module as I can configure that for 1 to 32 bits but in this case it is set for 8 bits so I can send 3 bytes. Of course I could have merged the bits as well and set it for 24 bit transfers. So this is where I'm at after not more than 15 minutes of work.

Looking at someone else's code can be useful but also confusing so I try not to be confused. However sometimes when you have things well along it sometimes helpful to peer over their shoulder so to speak and compare so as to see if there some ideas that can be incorporated. Once you are at this stage it is not so confusing to look at someone else's code and you are more able to see through the clutter.

Anyway, have a look at this document and if you would like to add to it in similar fashion then just email/pm me for editing privileges. I might not have much time to play with it but I can help move it along in hopefully the best direction.

[MJB]

Thanks for clearing up the ITC example (inner task communication).

And please keep your cut and paste examples comming, it really helps.

I have had great sucess with Tachyon and all the example code Peter and others have offered.
The chip you show should be no problem for Tachyon.

I have sample code in SPIN, PASM, Arduino-C and what I can read most easily BASCOM AVR-BASIC- which I used for many projects.

I have been porting a driver to Tachyon from Arduino and I hear this little bird in my head saying "why don't you just do this in C, C++ and be done with it" as I stuggle learning a FORTH way of programming.

I managed to get by in my professional life mostly without C
my languages where BASIC, VB, Lisp, Smalltalk, Prolog and other exotic things.

I'm just about done with the driver and wow, how compact it has become and I continue to see more optimizations I can make! Holy cow Tachyon is fast and so much more elaborate than PASM.

what kind of driver are you creating?

Just jump into that nRF2401 and start talking to it from the console, the WORDS you will want/need will start to form in you head as you TALK to the hardware.

I might start porting the BASCOM example to TACHYON

14.99$ for a breakout module I just might have to get a pair. Thanks for the link.

no - this was long ago ...
yesterday I ordered 10 for $12 from EBAY
http://www.ebay.de/itm/121042000247?...84.m1439.l2649

[D.P]

anybody already did / is thinking about a driver for the
nRF24L01+ Module

in TACHYON ?

there might be a way to use the OBEX code here.
http://forums.parallax.com/showthrea...nRF2401A/page3

but given TACHYONs fast SPI functions it might be better to implement it the FORTH-way.

Markus

Thanks for clearing up the ITC example (inner task communication).

And please keep your cut and paste examples comming, it really helps.

I have had great sucess with Tachyon and all the example code Peter and others have offered. The chip you show should be no problem for Tachyon. I have been porting a driver to Tachyon from Arduino and I hear this little bird in my head saying "why don't you just do this in C, C++ and be done with it" as I stuggle learning a FORTH way of programming. I'm just about done with the driver and wow, how compact it has become and I continue to see more optimizations I can make! Holy cow Tachyon is fast and so much more elaborate than PASM. Just jump into that nRF2401 and start talking to it from the console, the WORDS you will want/need will start to form in you head as you TALK to the hardware.

14.99$ for a breakout module I just might have to get a pair. Thanks for the link.

[Brian Riley]

The DropBox Tachyon v21.spin, also tagged 130620, but appears to be a few lines shorter, does compile clean

Current "bleeding edge" v2.1 still IDed as 130620 but with a change log entry dated 130705 compiles clean

[MJB]

anybody already did / is thinking about a driver for the
nRF24L01+ Module

in TACHYON ?

there might be a way to use the OBEX code here.
http://forums.parallax.com/showthrea...nRF2401A/page3

but given TACHYONs fast SPI functions it might be better to implement it the FORTH-way.

Markus

[MJB]

In trying to learn TACHYON I am collecting snippets from Peters code and examples.
Here my notes on creating Arrays or Tables in TACHYON

\ creating Arrays or Tables in TACHYON

\ create a non/byte aligned byte array of size 4 bytes
\ since BYTE allocates already one BYTE we only need to ALLOT 3 additional bytes
BYTE byteArray 3 ALLOT 

\ create a word aligned word array of size 6 words
\ since WORD allocates already one WORD we only need to ALLOT 10 additional bytes
WORD wordArray 10 ALLOT

\ create a long aligned TABLE / Array of size 7 longs 
\ since TABLE does NOT allocate space we do this after
\ for 7 longs we need to allocate 28 bytes
TABLE longArray 28 ALLOT 


\ Accessing of BYTE-Arrays just by C! and C@ (with 0 based index)
value byteArray index + C!       \ store to array
byteArray index + C@             \ fetch from array

\ Accessing of WORD-Arrays just by W! and W@ (with 0 based index)
value wordArray index 2* + W!    \ store to array
wordArray index 2* + W@          \ fetch from array

\ Accessing of LONG-Arrays / TABLES just by ! and @ (with 0 based index)
value longArray index 2* 2* + !  \ store to array
longArray index 2* 2* + @        \ fetch from array

[MJB]

includes Peters latest remarks

\ Task Example V3
LONG tsk1var \ create a variable, that I will increment inside the new tasks
             \ I am thinking about using a COG register for this, but
             \ the HUB variable is easier to follow
tsk1var ~    \  equiv to: 0 tsk1var !  \ make sure it is 0      C~  W~ available as well 

\ prepare for 4 tasks
BYTE myTaskCog 3 ALLOT  \ since TABLE creates a LONG table we create a BYTE ARRAY this way
                        \ which means simply create a BYTE variable and 3 additional unnamed bytes after it
                        \ here we store the COGid of the COGs running our task

: TSK1 ( )  \ a simple task 
   \ that only adds the command value to its tsk1var variable and returns the value on read
   BEGIN
  ATN@   \ look if there is a new command
  ?DUP   \ dup if not 0
  \ 0= NOT  \ this is redundant !!   0= is the same as NOT and IF takes everything <>0 as TRUE
  IF 
  tsk1var +!     \ add command value to variable
  tsk1var @ ENQ! \ return the new value of our variable as task return message (1 long)
  THEN
   AGAIN 
   ;
   

' TSK1    \ put pointer to task word on stack
4 0 DO    \ start 4 tasks
  DUP       \ so we can reuse task pointer
  TASK?     \ get a free COG
  DUP myTaskCog I +  C!  \ store it for reference in our little table ( I like those tables .. )
  RUN       \ now run it 
LOOP



TASKS           \ have a look
myTaskCog C@ .    \ have a look
myTaskCog 1 + C@ .    \ have a look
myTaskCog 2 + C@ .    \ have a look
myTaskCog 3 + C@ .    \ have a look

\ my new universal shortcut
: TSK ( tasknumber - taskCogID ) \ tasks counting from 1
   myTaskCog + 1- C@ ;

\ now I can write:
5 1 TSK ATN!
\ and
1 TSK ENQ@ .DEC

\ or I can go next level
: TSK!  ( tasknumber - )
   TSK ATN! ;

\ and
: TSK@  ( tasknumber - )
   TSK ENQ@ ;
 
: .TSK  TSK@ .DEC ;

 
\ gives
5 1 TSK!   \ to send message to task 1
\  and
1 TSK@     \ to ask task 1 for result


\ timing
NEWCNT
1000 0 DO
    1 TSK!
    1 TSK@
LOOP
LAPCNT .DEC   \ 105us/loop

\ clear 
0 tsk1var !
tsk1var @ .DEC

\ now let's get fancy ;-)
10d 1 TSK!
1 .TSK
tsk1var @ .DEC
5 2 TSK!
tsk1var @ .DEC
3 3 TSK!
tsk1var @ .DEC
3 .TSK
2 .TSK

[Peter Jakacki]

A couple of quick tips:
0 tsk1var ! could also be written simply as tsk1var ~
The tilde operators work just like they do in Spin except in Forth fashion so ~ will accept an address and clear that long. Use the W~ and C~ if you want the word and byte equivalents. Conversely there is the tilde tilde operators to set a variable using ~~

A table is really long aligned variable that initially does not allocate any storage space. Aligned to a long boundary could waste up to 3 bytes whereas byte variables begin anywhere.
TABLE myTaskCog 4 ALLOT only creates a single long that is long aligned but you are using byte variables.
It's just as easy to say LONG myTaskCog but since you don't need this long aligned you can simply define it as a byte variable BYTE myTaskCog 3 ALLOT

The sequence 0= NOT before an IF is redundant as IF accepts any non-zero value as "true". Also NOT is an alias for 0= anyway. So simply say ?DUP IF.

[Peter Jakacki]

The DropBox Tachyon v21.spin, also tagged 130620, but appears to be a few lines shorter, does compile clean

Sorry Brian, I was in the middle of an edit and I couldn't get back to it for a few days. I was tracking down a bug at the time which I thought was in the kernel but in the process I moved COGID to the cog kernel however the hub version used the addstk method, hence the compile error. Can't tell you much about what I was doing as I've had too much going on and now I forget!

[MJB]

@ Brian, D.P

well Brian, you are right of course, using the same name for the shortcut and the task word is not a good idea.

nevertheless it worked fine here - which reveals one of the Tachyon internals.

\ here I define the task word !!!

: TSK1 ( ) \ a simple task
\ that only adds the command value to its tsk1var variable and returns the value on read
BEGIN
ATN@ \ look if there is a new command
?DUP \ dup if not 0
0= NOT
IF
tsk1var +! \ add command value to variable
tsk1var @ ENQ! \ return the new value of our variable as task return message (1 long)
THEN
AGAIN
;

\ here the task is started given the reference from the defines TSK1 word - all fine so far

' TSK1 \ pointer to task word
TASK? \ get a free COG
DUP tsk1COG C! \ store it for reference
RUN \ now run it

TASKS \ have a look
tsk1COG C@ . \ have a look

\ now here is the tricky part ( which happened by accident - but worked in this special case )
\ I redefine the TSK1 word as my shortcut.
\ But the task is still running and redefining the word is no problem --- yet ;-)

: TSK1 tsk1COG C@ ; \ good to have a shortcut

\ so this works here
5 TSK1 ATN! \ send 5 to our task
TSK1 ENQ@ .DEC \ see what the task has done

\ BUT restarting the TSK1 again will of course not work any more ...

\ Brian, you extended my little example to 4 COGS running the same code.
\ all of them incrementing the same HUB variable
\ the semantics of this could be quite 'interesting'
\ after each command a task receives the HUB variable is incremented AND
\ the CURRENT value of it stored in the tasks ENQ@ place
\ so imagine what happens if multiple ATN! to different tasks get mixed
\ with ENQ@ to those tasks ... in out of order sequence ...
\ well - it just started as a simple example ...

\ instead of the 4 separate variables I would use a little table

TABLE mytasks 4 ALLOT

complete EXTENDED example below:

\ Task Example V2
LONG tsk1var \ create a variable, that I will increment inside the new tasks
             \ I am thinking about using a COG register for this, but
             \ the HUB variable is easier to follow
0 tsk1var !  \ make sure it is 0

\ prepare for 4 tasks
TABLE myTaskCog 4 ALLOT  \ here we store the COGid of the COGs running our task

: TSK1 ( )  \ a simple task 
   \ that only adds the command value to its tsk1var variable and returns the value on read
   BEGIN
  ATN@   \ look if there is a new command
  ?DUP   \ dup if not 0
  0= NOT
  IF 
  tsk1var +!     \ add command value to variable
  tsk1var @ ENQ! \ return the new value of our variable as task return message (1 long)
  THEN
   AGAIN 
   ;
   

' TSK1    \ put pointer to task word on stack
4 0 DO    \ start 4 tasks
  DUP       \ so we can reuse task pointer
  TASK?     \ get a free COG
  DUP myTaskCog I +  C!  \ store it for reference in our little table ( I like those tables .. )
  RUN       \ now run it 
LOOP



TASKS           \ have a look
myTaskCog C@ .    \ have a look
myTaskCog 1 + C@ .    \ have a look
myTaskCog 2 + C@ .    \ have a look
myTaskCog 3 + C@ .    \ have a look

\ my new universal shortcut
: TSK ( tasknumber - taskCogID ) \ tasks counting from 1
   myTaskCog + 1- C@ ;

\ now I can write:
5 1 TSK ATN!
\ and
1 TSK ENQ@ .DEC

\ or I can go next level
: TSK!  ( tasknumber - )
   TSK ATN! ;

\ and
: TSK@  ( tasknumber - )
   TSK ENQ@ ;
 
: .TSK  TSK@ .DEC ;

 
\ gives
5 1 TSK!   \ to send message to task 1
\  and
1 TSK@     \ to ask task 1 for result


\ timing
NEWCNT
1000 0 DO
    1 TSK!
    1 TSK@
LOOP
LAPCNT .DEC   \ 105us/loop

\ clear 
0 tsk1var !
tsk1var @ .DEC

\ now let's get fancy ;-)
10d 1 TSK!
1 .TSK
tsk1var @ .DEC
5 2 TSK!
tsk1var @ .DEC
3 3 TSK!
tsk1var @ .DEC
3 .TSK
2 .TSK

[D.P]

Hi LR

Did you get any errors during the load ? The BELL in the terminal ususally dings and you see many ???. More precisely the module compile result banner displays an error count above 0 and BACKUP does not run, i.e. no swirling bar at the end of the load.

You may have to play with the line delay and char delay, seems platform, computer dependent IMHO. Here's mine for TeraTerm running in Win7 VM hosted on MAC 10.8.2 You can be sure it's not the delay if you try 3 line and 1 char delay. I have some terminals that need 1 ms per char delay no matter the line delay. If it works, see if you can remove the char delay, this will speed up the load considerably.

Also where did you get the EXTEND.fth, did you cut and paste from the google docs? If so look for stuff at the bottom from google auto publish and remove it. Same with the TACHYON image although you have the kernel loaded, you are almost home.

I have problem loading EXTEND.fth. After I compile and load Tachyon I get the following screen on Teraterm:
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600
Cold start - no user code - setting defaults
I can execute basic words. Next I try to load EXTEND.fth. The default program on my PC for the suffix fth is Win32Forth. I copy the EXTEND source from Win32Forth IDE and paste it to Teraterm screen. It appears that it is loading, and then it stops on line 40 with:
0040 hexŠêüLONG hexptr ???
pub IDUMP .®¤,ÿ ???
I waited for 30 minutes without change.

What am I missing?
John

[D.P]

Hey Brian,

Replace

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...

 \  \ \ \ WITH \ \ \ \ 

5 TASK1 ATN!                 \  ATN!  wants ( cmd cog -- )           in TSK1 -  ATN?  or ATN@ ( -- data ) receive 
TASK1 ENQ@ .DEC       \  ENQ@ wants ( cog --  data )

8 TASK1 ATN!                 \  send 8  to TASK1
TASK1 ENQ@ .DEC       \  the task really has done it's job ...  in TSK1 -  ENQ! ( data -- ) response

Maybe you had a cut and paste error here.

BTW with the example code I get 30us round trip so 333K wmsp, (work + message per second), wowza and 6 more cogs just relaxing. I'm gonna needs some NOPs .

Markus ... I tried this code and couldn't get to work ... what bothered me was you named your shortcut "TSK1" the same as your main task.



I recoded as such and it worked ... did I miss something and get lucky????

\ Task Example
LONG tsk1var	\ create a variable, that I will increment inside the new
                \   task I am thinking about using a COG register for this,
                \   but the HUB variable is easier to follow
0 tsk1var !     \ make sure it is 0
BYTE tsk1COG    \ here we store the COGid of the COG running our task
BYTE tsk2COG    \ here we store the COGid of the COG running our task
BYTE tsk3COG    \ here we store the COGid of the COG running our task
BYTE tsk4COG    \ here we store the COGid of the COG running our task

: TSK1 ( )      \ a simple task that only adds the command value to its 
				\    tsk1var variable and returns the value on read
   BEGIN
     ATN@   	\ look if there is a new command and place it on the stack,
 				\   the actual COG knows which mailbox to read from
     ?DUP    	\ dup if not 0
     0= NOT  
     IF         \ so we got a command
        tsk1var +!        \ add command value to HUB variable
        tsk1var @ ENQ!    \ return the new value of our variable as 
						  \   task return message (1 long)
     THEN
   AGAIN         \ repeat indefinitely, before here we could place exit 
				 \   code for a given command
   ;

\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk1COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk2COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk3COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk4COG C!  \ store it for reference
RUN             \ now run it
 

TASKS                   \ have a look
tsk1COG C@ .        \ have a look

: TASK1 tsk1COG C@ ;   \ good to have a shortcut
: TASK2 tsk2COG C@ ;   \ good to have a shortcut
: TASK3 tsk3COG C@ ;   \ good to have a shortcut
: TASK4 tsk4COG C@ ;   \ good to have a shortcut

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...
\ Task Example
LONG tsk1var	\ create a variable, that I will increment inside the new
                \   task I am thinking about using a COG register for this,
                \   but the HUB variable is easier to follow
0 tsk1var !     \ make sure it is 0
BYTE tsk1COG    \ here we store the COGid of the COG running our task
BYTE tsk2COG    \ here we store the COGid of the COG running our task
BYTE tsk3COG    \ here we store the COGid of the COG running our task
BYTE tsk4COG    \ here we store the COGid of the COG running our task

: TSK1 ( )      \ a simple task that only adds the command value to its 
				\    tsk1var variable and returns the value on read
   BEGIN
     ATN@   	\ look if there is a new command and place it on the stack,
 				\   the actual COG knows which mailbox to read from
     ?DUP    	\ dup if not 0
     0= NOT  
     IF         \ so we got a command
        tsk1var +!        \ add command value to HUB variable
        tsk1var @ ENQ!    \ return the new value of our variable as 
						  \   task return message (1 long)
     THEN
   AGAIN         \ repeat indefinitely, before here we could place exit 
				 \   code for a given command
   ;

\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk1COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk2COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk3COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk4COG C!  \ store it for reference
RUN             \ now run it
 

TASKS                   \ have a look
tsk1COG C@ .        \ have a look

: TASK1 tsk1COG C@ ;   \ good to have a shortcut
: TASK2 tsk2COG C@ ;   \ good to have a shortcut
: TASK3 tsk3COG C@ ;   \ good to have a shortcut
: TASK4 tsk4COG C@ ;   \ good to have a shortcut

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...

[Iamretired]

I have problem loading EXTEND.fth. After I compile and load Tachyon I get the following screen on Teraterm:
Propeller .:.:--TACHYON--:.:. Forth V21130224.1600
Cold start - no user code - setting defaults
I can execute basic words. Next I try to load EXTEND.fth. The default program on my PC for the suffix fth is Win32Forth. I copy the EXTEND source from Win32Forth IDE and paste it to Teraterm screen. It appears that it is loading, and then it stops on line 40 with:
0040 hexŠêüLONG hexptr ???
pub IDUMP .®¤,ÿ ???
I waited for 30 minutes without change.

What am I missing?
John

[Brian Riley]

Markus ... I tried this code and couldn't get to work ... what bothered me was you named your shortcut "TSK1" the same as your main task.

 ...

: TSK1 tsk1COG C@ ;   \ good to have a shortcut

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...

I recoded as such and it worked ... did I miss something and get lucky????

\ Task Example
LONG tsk1var	\ create a variable, that I will increment inside the new
                \   task I am thinking about using a COG register for this,
                \   but the HUB variable is easier to follow
0 tsk1var !     \ make sure it is 0
BYTE tsk1COG    \ here we store the COGid of the COG running our task
BYTE tsk2COG    \ here we store the COGid of the COG running our task
BYTE tsk3COG    \ here we store the COGid of the COG running our task
BYTE tsk4COG    \ here we store the COGid of the COG running our task

: TSK1 ( )      \ a simple task that only adds the command value to its 
				\    tsk1var variable and returns the value on read
   BEGIN
     ATN@   	\ look if there is a new command and place it on the stack,
 				\   the actual COG knows which mailbox to read from
     ?DUP    	\ dup if not 0
     0= NOT  
     IF         \ so we got a command
        tsk1var +!        \ add command value to HUB variable
        tsk1var @ ENQ!    \ return the new value of our variable as 
						  \   task return message (1 long)
     THEN
   AGAIN         \ repeat indefinitely, before here we could place exit 
				 \   code for a given command
   ;

\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk1COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk2COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk3COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk4COG C!  \ store it for reference
RUN             \ now run it
 

TASKS                   \ have a look
tsk1COG C@ .        \ have a look

: TASK1 tsk1COG C@ ;   \ good to have a shortcut
: TASK2 tsk2COG C@ ;   \ good to have a shortcut
: TASK3 tsk3COG C@ ;   \ good to have a shortcut
: TASK4 tsk4COG C@ ;   \ good to have a shortcut

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...
\ Task Example
LONG tsk1var	\ create a variable, that I will increment inside the new
                \   task I am thinking about using a COG register for this,
                \   but the HUB variable is easier to follow
0 tsk1var !     \ make sure it is 0
BYTE tsk1COG    \ here we store the COGid of the COG running our task
BYTE tsk2COG    \ here we store the COGid of the COG running our task
BYTE tsk3COG    \ here we store the COGid of the COG running our task
BYTE tsk4COG    \ here we store the COGid of the COG running our task

: TSK1 ( )      \ a simple task that only adds the command value to its 
				\    tsk1var variable and returns the value on read
   BEGIN
     ATN@   	\ look if there is a new command and place it on the stack,
 				\   the actual COG knows which mailbox to read from
     ?DUP    	\ dup if not 0
     0= NOT  
     IF         \ so we got a command
        tsk1var +!        \ add command value to HUB variable
        tsk1var @ ENQ!    \ return the new value of our variable as 
						  \   task return message (1 long)
     THEN
   AGAIN         \ repeat indefinitely, before here we could place exit 
				 \   code for a given command
   ;

\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk1COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk2COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk3COG C!  \ store it for reference
RUN             \ now run it
 
\ run our task 
' TSK1			\ pointer to task word
TASK?           \ get a free COG
DUP tsk4COG C!  \ store it for reference
RUN             \ now run it
 

TASKS                   \ have a look
tsk1COG C@ .        \ have a look

: TASK1 tsk1COG C@ ;   \ good to have a shortcut
: TASK2 tsk2COG C@ ;   \ good to have a shortcut
: TASK3 tsk3COG C@ ;   \ good to have a shortcut
: TASK4 tsk4COG C@ ;   \ good to have a shortcut

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...

[D.P]

SERIN amongst a few other functions were introduced as BS2 equivalents and also inheiritx their limitations. V3 will have more in the way of support for PASM objects and you will be able to select multi-port serial objects at runtime. However for now I am not devoting too much effort into doing this with V2 although you could compile the PASM part of a serial object and supply appropriate hooks to it with some Forth words.

As for a return flag/data sometimes a simple zero is appropriate but not very transparent as zero or null may be part of the data stream. I find returning -1 as data can be interpreted very easily as a negative ack flag. You simply increment the data to test if it is valid data and -1 becomes 0 which means there is no data available.

As an exercise for V3 I will look at grafting in the multiport serial object into V2 so this should be of some help to you in the meantime as the SERIN object is handy but I consider it a toy and very limited.

result DUP 1+ 0 > IF good_data ELSE no_data THEN


Thanks Peter, that's the good hint I needed. I'm fine with SERIN / OUT now, keep on your V3 path unless you really need the excerise.

[Brian Riley]

The DropBox Tachyon v21.spin, also tagged 130620, but appears to be a few lines shorter, does compile clean

[Peter Jakacki]

Looking for a non-blocking SERIN,

This is my attempt so far, I think this will WAITLOW for 15ms before timing out?

pub SERINW ( pin -- data )
        

        MASK DUP INPUTS DUP

        #10000 SWAP WAITLOW  0 > IF     \ wait for low pin 15ms

          baudcnt @ 2/ DELTA

          baudcnt @ DELTA                        \ delay to sample 1 bit later in 1st data bit

            0 8 FOR SHRINP WAITCNT NEXT

          NIP #24 SHR                                \ right justify 8-bit data
          
        ELSE
          0
        THEN
        ;

Since the device I'm trying to poll can return 0 as valid data I think I need to set a flag as well. Or DUP the return CNT and check the STACK for a non-zero CNT as the flag.

Ideas? The device is a touch screen LCD and I need to poll it for async serial messages.

Writing and receiving is working fine I.E send a message and immediately receive the ACK. Looking for the FORTH POLL, couldn't help that, Peter started it.

SERIN amongst a few other functions were introduced as BS2 equivalents and also inheiritx their limitations. V3 will have more in the way of support for PASM objects and you will be able to select multi-port serial objects at runtime. However for now I am not devoting too much effort into doing this with V2 although you could compile the PASM part of a serial object and supply appropriate hooks to it with some Forth words.

As for a return flag/data sometimes a simple zero is appropriate but not very transparent as zero or null may be part of the data stream. I find returning -1 as data can be interpreted very easily as a negative ack flag. You simply increment the data to test if it is valid data and -1 becomes 0 which means there is no data available.

As an exercise for V3 I will look at grafting in the multiport serial object into V2 so this should be of some help to you in the meantime as the SERIN object is handy but I consider it a toy and very limited.

[D.P]

Looking for a non-blocking SERIN,

This is my attempt so far, I think this will WAITLOW for 15ms before timing out?

pub SERINW ( pin -- data )
        

        MASK DUP INPUTS DUP

        #10000 SWAP WAITLOW  0 > IF     \ wait for low pin 15ms

          baudcnt @ 2/ DELTA

          baudcnt @ DELTA                        \ delay to sample 1 bit later in 1st data bit

            0 8 FOR SHRINP WAITCNT NEXT

          NIP #24 SHR                                \ right justify 8-bit data
          
        ELSE
          0
        THEN
        ;

Since the device I'm trying to poll can return 0 as valid data I think I need to set a flag as well. Or DUP the return CNT and check the STACK for a non-zero CNT as the flag.

Ideas? The device is a touch screen LCD and I need to poll it for async serial messages.

Writing and receiving is working fine I.E send a message and immediately receive the ACK. Looking for the FORTH POLL, couldn't help that, Peter started it.

[Brian Riley]

Peter,

The 'bleeding edge' 2.1 code, 130620, when compiled using SimpleIDE produces the following error

[max72]

Thanks!
Massimo

[Peter Jakacki]

Intercog communication maybe...
Cannot get ATN/ENQ usage

Finally got around to doing this so I incorporated the use of ATN in the timer blinker code. I found a bug in the meantime, well not really a bug but I changed TIMERTASK so that it would check for timing overruns and rather than wait the full 32-bit CNT cycle it now just forces it to the next millisecond. Now this example is only using ATN but ENQ is identical except it's the return channel, a bit like EMIT and KEY where ATN! is equivalent to sending data to that task and ATN@ is equivalent to KEY in that it reads the data. So ENQ! would be used by a task to send a response perhaps and it's similar to EMIT. In this simple example I have the BLINKER task look for commands that in this case we are sending from the console task but could be coming from any task.

#16    == ledpins
TABLE blinkrates
    #50 || #500 ||
    #50 || #300 ||
    #50 || #150 ||
    #50 || #285 ||
    #50 || #175 ||
    #50 || #335 ||
    #50 || #100 ||
    #50 || #195 ||

pub BLINKCMD
    ATN@ SWITCH
    "-" CASE blinkrates BL ADO I W@ 2* I W! 2 +LOOP BREAK
    "+" CASE blinkrates BL ADO I W@ 2/ I W! 2 +LOOP BREAK
    ;
pub BLINKER ( accesses index of calling loop )
    BLINKCMD
    I 2* 2* blinkrates + I ledpins + DUP PIN@ IF PINCLR 2+ ELSE PINSET THEN W@ I TIMEOUT
    ;
pub clrpin       I ledpins + PINCLR ;
pub BLINKERS ( flg -- ) IF ' BLINKER ELSE ' clrpin THEN 8 0 DO DUP I ALARM I 1+ I TIMEOUT LOOP DROP ;

ON BLINKERS

{ Demonstrates how ATN can be used to send a command to the TIMERTASK

"-" 7 ATN!        \ send a command to TIMERTASK to slow down the blinkers

"+" 7 ATN!        \ speed up the blinkers
}

[D.P]

The birth of my first Prop I Tachyon FORTH machine.

It controls a 4th level tool i.e. steam; with files, chisels, stones and such being a 1st level tools.

Thanks Peter, all

[max72]

Thanks Markus,
I'll study your example.
The figure of eight code will be reviewed with a multicog code soon..
Massimo

[MJB]

Intercog communication maybe...
Cannot get ATN/ENQ usage

it took me a while to understand the use of the I loop index in the example above -
and when I wanted to post my little EURECA I saw, that Peter was not only faster, but more in depth in his explanation.

So I will try with my little example for ATN/ENQ - Peter will surely augment it ;-)

\ Task Example
LONG tsk1var    \ create a variable, that I will increment inside the new task
                        \ I am thinking about using a COG register for this, but
                        \ the HUB variable is easier to follow
0 tsk1var !         \ make sure it is 0
BYTE tsk1COG    here we store the COGid of the COG running our task

: TSK1 ( )         \ a simple task 
                       \ that only adds the command value to its tsk1var variable and returns the value on read
   BEGIN
     ATN@   \ look if there is a new command and place it on the stack, the actual COG knows which mailbox to read from
     ?DUP    \ dup if not 0
     0= NOT  
     IF                           \ so we got a command
        tsk1var +!             \ add command value to HUB variable
        tsk1var @ ENQ!    \ return the new value of our variable as task return message (1 long)
     THEN
   AGAIN                      \ repeat indefinitely,   before here we could place exit code for a given command
   ;
 
\ run our task 
' TSK1                     \ pointer to task word
TASK?                    \ get a free COG
DUP tsk1COG C!     \ store it for reference
RUN                       \ now run it

TASKS                   \ have a look
tsk1COG C@ .        \ have a look

: TSK1 tsk1COG C@ ;   \ good to have a shortcut

5 TSK1 ATN!                 \  send 5  to our task
TSK1 ENQ@ .DEC       \  see what the task has done

8 TSK1 ATN!                 \  send 8  to our task
TSK1 ENQ@ .DEC        \  the task really has done it's job ...

Actually I'd love to see a more complex example as well ... ,
but I have no real application for it right now.

Markus

[max72]

[...] If anyone would like a few more examples or explanations of some Tachyon functions [....]

Intercog communication maybe...
Cannot get ATN/ENQ usage

[Peter Jakacki]

Always look forward to the updates. One thing about the last example, when each "alarm" gets set it reads the loop counter I from the loop stack. This "alarm" is then "compiled" and put somewhere with the value of I evaluated and retained. This is fuzzy to me, can you clear it up?

The alarm is called from inside a DO LOOP in TIMERTASK and the index of that loop corresponds to the timer. When the alarm function is called there are no parameters passed but the loop index is directly accessible at any time.

In traditional Forth implementations the loop parameters are stored on the return stack and once you call a word from inside the loop you do not necessarily know depending upon the levels where on the stack that index is. This never made any sense to me and a corruption of the return stack will surely lead to software malfunction, hence the loop stack. Now no matter how much call nesting there is you can count on being able to access the various levels of loop parameters.

I think by your question though that you may be thinking that the value of the loop index "I" is compiled but it is not. The index "I" is like a variable and when "I" is executed all it does is read this variable (from the loop stack) and place a copy on top of the data stack. Thus each time the alarm word is called it can read which timer activated the call by reading the loop index.

This is the loop from TIMERTASK and you can see when it executes the CALL that it is related to a particular timer which can be referenced with the loop index "I" as in I TIMER.

    BEGIN                              \ 172us / outer loop measured with a blinky timer or 118us for 8 empty timers
      1 runtime +!                        \ elapsed time since last reset (in ms)
      timercnt C@ 0 
       DO
        I TIMER @ ?DUP                    \ count if it's non-zero
         IF 1- DUP I TIMER !              \ update
           0= IF I TIMER 4 + W@ ?DUP      \ on timeout check for action 
             IF CALL THEN THEN            \ execute if set
         THEN
      LOOP
      WAITCNT
    AGAIN

[D.P]

Hi D.P, I've included a version of your blinkers using TIMERTASK in the Intro page as an example of using TIMEOUTs and ALARMs.

If anyone would like a few more examples or explanations of some Tachyon functions then I will be happy to include this in the Intro page and for more extensive examples they would have their own project page linked from the Intro/Links section.

Always look forward to the updates. One thing about the last example, when each "alarm" gets set it reads the loop counter I from the loop stack. This "alarm" is then "compiled" and put somewhere with the value of I evaluated and retained. This is fuzzy to me, can you clear it up?

[Peter Jakacki]

Thanks for the patience Peter, Tachyon is becoming clearer as I work through examples.

Here's a little code for anyone who wants to blinks all the lights on the quickstart board using Tachyon timers, thanks again.

Very impressed with the speed and flexibility of Tachyon. I'm sure the STOPEM word is not optimized but it works for now.

Hi D.P, I've included a version of your blinkers using TIMERTASK in the Intro page as an example of using TIMEOUTs and ALARMs.

If anyone would like a few more examples or explanations of some Tachyon functions then I will be happy to include this in the Intro page and for more extensive examples they would have their own project page linked from the Intro/Links section.

[fidolo]

just to let you know that this whole maths pack thing is being addressed in V3 which uses an auxiliary cog to process maths, dictionary, and timing so therefore the trig functions will be in PASM and I will probably interpolate for finer resolutions.

Talking about math functions, the unsigned division in Tachyon is best for speed, but when I need signed division, the following redefinition of "/" has worked well for me:

: /   \ Redefine Division, to allow for algebraic operators ( long long --- long )
            DUP 0< DUP >L  IF NEGATE THEN    \ recognize, save and normalize denominator sign 
      SWAP  DUP 0< DUP >L  IF NEGATE THEN    \ recognize, save and normalize numerator sign
      SWAP  /   L> L> XOR  IF NEGATE THEN ;  \ unsigned divide and apply appropriate sign

[Peter Jakacki]

Thanks for the patience Peter, Tachyon is becoming clearer as I work through examples.

Here's a little code for anyone who wants to blinks all the lights on the quickstart board using Tachyon timers, thanks again.

Very impressed with the speed and flexibility of Tachyon. I'm sure the STOPEM word is not optimized but it works for now.

[CODE]
\ * SIMPLE ROUTINE TO EXERCISE ALL 8 LEDS WITH TACHYON TIMERS
\ * AND ALARMS ON THE PROP QUICKSTART BOARD
\ *
\ * USE THE WORD "BLINKEM" TO START THE LIGHTS
\ * AND "STOPEM" TO STOP THE LIGHTS

Thought you'd be interested in this too, it does exactly the same as your blinker except it use a quarter of the code space (95 bytes) and much less dictionary space too (54 bytes). Both yours and this one are just demonstrators so it's good to have a few methods to show what is possible. This one has a common ALARM which reads the index of the caller which in Tachyon is possible since it keeps it's loop parameters on a loop stack vs the traditional return stack. By using a simple table lookup we cut out most of the duplicated code and I've basically left the other words the same. BLINKEM sets the ALARM for each timer to the common method and also starts up the timer with a common value.

TABLE timeouts
    #50 || #500 ||
    #50 || #300 ||
    #50 || #150 ||
    #50 || #285 ||
    #50 || #175 ||
    #50 || #335 ||
    #50 || #100 ||
    #50 || #195 ||

: BLINKER ( accesses index of calling loop )
    I 2* 2* timeouts + I 16 + DUP PIN@ IF PINCLR 2+ W@ ELSE PINSET W@ THEN I TIMEOUT
    ;

: clrpin    $FF0000 OUTCLR ;

: BLINKEM    8 0 DO ' BLINKER I ALARM 1 I TIMEOUT LOOP ;
 
: STOPEM    8 0 DO ' clrpin I ALARM LOOP ;

[fidolo]

Thanks for your input on this matter Fidolo and just to let you know that this whole maths pack thing is being addressed in V3 which uses an auxiliary cog to process maths, dictionary, and timing so therefore the trig functions will be in PASM and I will probably interpolate for finer resolutions.

Thank you Peter, for creating Tachyon Forth in the first place.

[D.P]

The timers run in their own cog which uses a WAITCNT to synchronize every 1 ms. By asking that cog to wait for 50ms you are effectively handcuffing it to a chair to do nothing in that period. When it's released WAITCNT now has to wait a complete CNT cycle of 54.6 seconds until it trips again. Don't ever delay a synchronous loop beyond it's window. The other thing is to watch out for shared outputs as running blink from the calling cog will cause the calling cog to assert control over that pin. Fortunately the outputs are or'ed and the calling cog left the pin low so that the timer cog can still override it although the pin is stuck in an output condition (in case you wanted to release it).

Thanks for the patience Peter, Tachyon is becoming clearer as I work through examples.

Here's a little code for anyone who wants to blinks all the lights on the quickstart board using Tachyon timers, thanks again.

Very impressed with the speed and flexibility of Tachyon. I'm sure the STOPEM word is not optimized but it works for now.

\ * SIMPLE ROUTINE TO EXERCISE ALL 8 LEDS WITH TACHYON TIMERS
\ * AND ALARMS ON THE  PROP QUICKSTART BOARD
\ * 
\ * USE THE WORD "BLINKEM" TO START THE LIGHTS 
\ * AND "STOPEM" TO STOP THE LIGHTS
 

0 CONSTANT #mt0
1 CONSTANT #mt1
2 CONSTANT #mt2
3 CONSTANT #mt3
4 CONSTANT #mt4
5 CONSTANT #mt5
6 CONSTANT #mt6
7 CONSTANT #mt7

: blink0 #16 PIN@ IF #16 PINCLR #500 ELSE #16 PINSET #50 THEN #mt0 TIMEOUT ;
: b0 ' blink0 #mt0  ALARM ;

: blink1 #17 PIN@ IF #17 PINCLR #300 ELSE #17 PINSET #50 THEN #mt1 TIMEOUT ;
: b1 ' blink1 #mt1  ALARM ;

: blink2 #18 PIN@ IF #18 PINCLR #150 ELSE #18 PINSET #50 THEN #mt2 TIMEOUT ;
: b2 ' blink2 #mt2  ALARM ;

: blink3 #19 PIN@ IF #19 PINCLR #285 ELSE #19 PINSET #50 THEN #mt3 TIMEOUT ;
: b3 ' blink3 #mt3  ALARM ;

: blink4 #20 PIN@ IF #20 PINCLR #175 ELSE #20 PINSET #50 THEN #mt4 TIMEOUT ;
: b4 ' blink4 #mt4  ALARM ;

: blink5 #21 PIN@ IF #21 PINCLR #335 ELSE #21 PINSET #50 THEN #mt5 TIMEOUT ;
: b5 ' blink5 #mt5  ALARM ;

: blink6 #22 PIN@ IF #22 PINCLR #100 ELSE #22 PINSET #50 THEN #mt6 TIMEOUT ;
: b6 ' blink6 #mt6  ALARM ;

: blink7 #23 PIN@ IF #23 PINCLR #195 ELSE #23 PINSET #50 THEN #mt7 TIMEOUT ;
: b7 ' blink7 #mt7  ALARM ;

: clrpin $FF0000 OUTCLR ;

: BLINKEM  b0 b1 b2 b3 b4 b5 b6 b7  8 0 DO #25 I * 1 + I TIMEOUT LOOP ;

: STOPEM    8 0 DO ' clrpin I ALARM LOOP ;

[Peter Jakacki]

I ran into the very same question a while back: This is how I resolved it: I decided to treat the sine look-up range as representing 2048 stops per quadrant (from zero for zero to 2047 for almost 90 degrees), even if the intent of the author of the lookup material was to tabulate 2049 stops per quadrant. With 2048 entries of 16-bit each, the really small errors resulting from this possible mistake will not make a noticeable difference because we have only 11 bits of resolution for the angle and 16-bit for its sine.

Instead, I elected to preserve the main character of the sine function, which is its cyclical nature, all across the board since, mathematically it applies to angles beyond 360 (just rinse and repeat), and it also applies to negative angular values, where the sine of a negative angle is the mirror image (negated value) of the sine of the (positive) mirror angle. So my code is designed to preserve these two features, even at the cost of some really small loss of accuracy.

: SINE    ( x --- sine) $1FFF AND $1000 U/MOD >L \ wrap at cycle, recognize half cycle 
                        $1000 OVER - MIN         \ reverse indexing for even quadrants
                        2* $E000 + W@            \ read sine in quadrant lookup table
                        L> IF NEGATE THEN ;      \ adjust sign for half cycle

This has worked very well for me, in an application where a 32-bit variable repeatedly accumulates angular increments. It works efficiently because the modulo divisions are replaced with trivial maskings such as

$1FFF AND

. To achieve truly expeditious execution time, someone with the right skills could write a PASM version of it, and the 2048 vs. 2049 controversy would become lost in the dusty wake of the propelled roadrunner bird. Mathematicians, please do not take offense, I don't think you are just coyotes!

Thanks for your input on this matter Fidolo and just to let you know that this whole maths pack thing is being addressed in V3 which uses an auxiliary cog to process maths, dictionary, and timing so therefore the trig functions will be in PASM and I will probably interpolate for finer resolutions.

[fidolo]

"Sin" is the fetch word. "SIN" takes the actual sine off the stack and prints it out as a decimal.

One shortcoming of the sine table is that 2049 entries divided by 90 degrees when done by integer math dropping the remainder gets you 22 entries per degree, whereas floating point gets you 22.76666... a not inconsiderable error.

If anyone can tighten this up ... please do!

... enjoy ... BBR

I ran into the very same question a while back: This is how I resolved it: I decided to treat the sine look-up range as representing 2048 stops per quadrant (from zero for zero to 2047 for almost 90 degrees), even if the intent of the author of the lookup material was to tabulate 2049 stops per quadrant. With 2048 entries of 16-bit each, the really small errors resulting from this possible mistake will not make a noticeable difference because we have only 11 bits of resolution for the angle and 16-bit for its sine.

Instead, I elected to preserve the main character of the sine function, which is its cyclical nature, all across the board since, mathematically it applies to angles beyond 360 (just rinse and repeat), and it also applies to negative angular values, where the sine of a negative angle is the mirror image (negated value) of the sine of the (positive) mirror angle. So my code is designed to preserve these two features, even at the cost of some really small loss of accuracy.

: SINE    ( x --- sine) $1FFF AND $1000 U/MOD >L \ wrap at cycle, recognize half cycle 
                        $1000 OVER - MIN         \ reverse indexing for even quadrants
                        2* $E000 + W@            \ read sine in quadrant lookup table
                        L> IF NEGATE THEN ;      \ adjust sign for half cycle

This has worked very well for me, in an application where a 32-bit variable repeatedly accumulates angular increments. It works efficiently because the modulo divisions are replaced with trivial maskings such as

$1FFF AND

. To achieve truly expeditious execution time, someone with the right skills could write a PASM version of it, and the 2048 vs. 2049 controversy would become lost in the dusty wake of the hyper-propelled roadrunner bird. Mathematicians, please do not take offense, I know you are a whole lot more intellectual than frustrated coyotes!

[Peter Jakacki]

I must be missing something with timers

0 CONSTANT #mt
: blink #18 PINSET #50 ms  #18 PINCLR  #1000 #mt TIMEOUT ;
' blink #mt  ALARM

Running blink should blink the light (it does) and reload the timer to blink the light every #1000 ms ?

I get the first blink and then one blink 1 second later and no more blinks?

Trying to start the timer with #1000 #mt TIMEOUT does nothing subsequently?

The timers run in their own cog which uses a WAITCNT to synchronize every 1 ms. By asking that cog to wait for 50ms you are effectively handcuffing it to a chair to do nothing in that period. When it's released WAITCNT now has to wait a complete CNT cycle of 54.6 seconds until it trips again. Don't ever delay a synchronous loop beyond it's window. The other thing is to watch out for shared outputs as running blink from the calling cog will cause the calling cog to assert control over that pin. Fortunately the outputs are or'ed and the calling cog left the pin low so that the timer cog can still override it although the pin is stuck in an output condition (in case you wanted to release it).

Your code should be a bit like this:

0 CONSTANT #mt
: blink #18 PIN@ IF #18 PINCLR #1000 ELSE #18 PINSET #50 THEN #mt TIMEOUT ;
' blink #mt  ALARM

\ To start the timer from the calling cog it is best just to initiate the timeout (any value)
1 #mt TIMEOUT

[D.P]

Sorry, I haven't updated the Dropbox version but just remember that all the bleeding edge stuff can be had direct from the Goggle document. Any changes I make to it are immediately reflected in any copies of the document that may have been opened by anyone. Sometimes this is a disadvantage as I am in the middle of some changes but nonetheless everyone has access to what I'm working on at that very moment. So I will just update the Dropbox file now although I am trying just to stick to V3 and carry through small improvements to V2.2 (to be published).

I must be missing something with timers

0 CONSTANT #mt
: blink #18 PINSET #50 ms  #18 PINCLR  #1000 #mt TIMEOUT ;
' blink #mt  ALARM

Running blink should blink the light (it does) and reload the timer to blink the light every #1000 ms ?

I get the first blink and then one blink 1 second later and no more blinks?

Trying to start the timer with #1000 #mt TIMEOUT does nothing subsequently?

 Propeller .:.:--TACHYON--:.:. Forth V21130620.0000

NAMES:  $61FE...744C for 4686 (22374 bytes added) with 22674 bytes free
CODE:   $0000...2A11 for 6083 (4497 bytes added) with 21999 bytes free
CALLS:  0620 vectors free

AUTORUN BOOT
MODULES LOADED: 
1880: EXTEND.fth          Primary extensions to TACHYON kernel - 130607.1600

[Peter Jakacki]

Hi Peter,

I've had very little time for TC lately. My Son is racing Velodrome this weekend, so I'll be time constrained in the next few days too.

r.e. CASE:

I've uploaded the latest binary(with ext.):

Propeller .:.:--TACHYON--:.:. Forth V21130611.0000 with Primary extensions to TACHYON kernel - 130607.1600

In a WORD listing, sorted in Excel I show these two entries for:

NFA PFA EXT ATRS NAME
------ ------ ------ ------- --------

7271	1A63		...:	CASE
6E92	1208	XAC	...:	CASE

Why two? In any case, I tried to run the "CASE" test/demo code in your post, but it chokes on the "SWITCH" word; not too shocking as it's not been defined anywhere that I can find.

Am I missing something obvious?

Looking forward to your continued efforts as usual.

Rick In Sunny Hot Texas USA

Sorry, I haven't updated the Dropbox version but just remember that all the bleeding edge stuff can be had direct from the Goggle document. Any changes I make to it are immediately reflected in any copies of the document that may have been opened by anyone. Sometimes this is a disadvantage as I am in the middle of some changes but nonetheless everyone has access to what I'm working on at that very moment. So I will just update the Dropbox file now although I am trying just to stick to V3 and carry through small improvements to V2.2 (to be published).

[RickInTexas]

Since talking about CASE statements I have had a rethink and looked at some of my apps to see what works best, is flexible ,... Demo code is included. Feedback is appreciated.

{ TACHYON CASE STRUCTURES
...

Hi Peter,

I've had very little time for TC lately. My Son is racing Velodrome this weekend, so I'll be time constrained in the next few days too.

r.e. CASE:

I've uploaded the latest binary(with ext.):

Propeller .:.:--TACHYON--:.:. Forth V21130611.0000 with Primary extensions to TACHYON kernel - 130607.1600

In a WORD listing, sorted in Excel I show these two entries for:

NFA PFA EXT ATRS NAME
------ ------ ------ ------- --------

7271	1A63		...:	CASE
6E92	1208	XAC	...:	CASE

Why two? In any case, I tried to run the "CASE" test/demo code in your post, but it chokes on the "SWITCH" word; not too shocking as it's not been defined anywhere that I can find.

Am I missing something obvious?

Looking forward to your continued efforts as usual.

Rick In Sunny Hot Texas USA

[Loopy Byteloose]

Hi,
I am still looking forward to exploring Tackyon Forth on the Propeller2. After all, what better use for a sizzling fast Forth than the best of Propellers.

In the meantime, I am still a lowly student of Forth and am finding my learning requires ANS Forth background material.

[Peter Jakacki]

Since talking about CASE statements I have had a rethink and looked at some of my apps to see what works best, is flexible, and is not too arcane. Surprisingly I decided to skip the normal Forth convention and adopt the C convention simply because it refers to a SWITCH, that is the actual target value, and it uses CASE and BREAK for normal operations which seem perfectly sensible to me. BREAK has been seen as a weakness in C because otherwise it falls through to the next line but I prefer the flexibility and these three words are very familiar to many programmers. Of course they are handled in Forth fashion and since Forth compiles exactly what you enter I have added a couple of extra words to allow for ranges and multiple values to be tested. Demo code is included. Feedback is appreciated.

{ TACHYON CASE STRUCTURES
This implementation follows the C method to some degree.
Each CASE statement simply compares the supplied value with the SWITCH and executes an IF
To prevent the IF statement from falling through a BREAK is used (also acts as a THEN at CT)
The SWITCH can be tested directly and a manual CASE can be constructed with IF <code> BREAK

SWITCH ( switch -- ) \ Save switch value used in CASE structure
CASE ( val -- ) \ compare val with switch and perform an IF. Equivalent to SWITCH= IF
BREAK \ EXIT (return) but also completes IF structure at CT. Equivalent to EXIT THEN
\ extra functions to allow the switch to be manipulated etc
SWITCH@ ( -- switch ) \ Fetch last saved switch value
SWITCH= ( val -- flg ) \ Compare val with switch. Equivalent to SWITCH@ =
SWITCH>< ( from to -- flg ) \ Compare switch within range. Equivalent to SWITCH@ ROT ROT WITHIN

Usage:

pub CASEDEMO  ( val -- )
   SWITCH                \ use the key value as a switch in the case statement
   "A" CASE CR ." A is for APPLE " BREAK
   "H" CASE CR ." H is for HAPPY " BREAK
   "Z" CASE CR ." Z is for ZEBRA " BREAK
   $08 CASE 4 REG ~ BREAK
   \ Now accept 0 to 9 and build a number calculator style
   "0" "9" SWITCH>< IF SWITCH@ $30 - 4 REG @ #10 * + 4 REG ! ." *" BREAK
   \ On enter just display the accumulated number
   $0D CASE CR ." and our lucky number is " 4 REG @ .DEC BREAK
   \ show how we can test more than one value
   "Q" SWITCH= "X" SWITCH= OR IF CR ." So you're a quitter hey?" CR CONSOLE BREAK
   CR ." I don't know what " SWITCH@ EMIT ."  is"
    ; 
pub DEMO
   BEGIN KEY UPPER CASEDEMO AGAIN  
 ;

Running DEMO and here's a screen dump:
DEMO 
A is for APPLE 
I don't know what B is
I don't know what C is
H is for HAPPY 
Z is for ZEBRA ****
and our lucky number is 8032***
and our lucky number is 8032001
So you're a quitter hey?
----------------------------------------------------------------

The compiled code for this demo is revealed here:

SEEALL CASEDEMO ...: 
2A11:  SWITCH
2A13:  $41
2A15:  SWITCH=
2A17:  IF 
2A19:    CR
2A1B:    ." A is for APPLE "
2A2D:    EXIT
2A2E:  THEN 
2A2E:  $48
2A30:  SWITCH=
2A32:  IF 
2A34:    CR
2A36:    ." H is for HAPPY "
2A48:    EXIT
2A49:  THEN 
2A49:  $5A
2A4B:  SWITCH=
2A4D:  IF 
2A4F:    CR
2A51:    ." Z is for ZEBRA "
2A63:    EXIT
2A64:  THEN 
2A64:  $08
2A66:  SWITCH=
2A68:  IF 
2A6A:    4
2A6B:    REG
2A6C:    ~
2A6E:    EXIT
2A6F:  THEN 
2A6F:  $30
2A71:  $39
2A73:  SWITCH><
2A75:  IF 
2A77:    SWITCH@
2A79:    $30
2A7B:    -
2A7C:    4
2A7D:    REG
2A7E:    @
2A7F:    $0A
2A81:    UM*
2A82:    DROP
2A83:    +
2A84:    4
2A85:    REG
2A86:    !
2A87:    ." *"
2A8B:    EXIT
2A8C:  THEN 
2A8C:  $0D
2A8E:  SWITCH=
2A90:  IF 
2A92:    CR
2A94:    ." and our lucky number is "
2AAF:    4
2AB0:    REG
2AB1:    @
2AB2:    .DEC
2AB4:    EXIT
2AB5:  THEN 
2AB5:  $51
2AB7:  SWITCH=
2AB9:  $58
2ABB:  SWITCH=
2ABD:  OR
2ABE:  IF 
2AC0:    CR
2AC2:    ." So you're a quitter hey?"
2ADD:    CR
2ADF:    CONSOLE
2AE1:    EXIT
2AE2:  THEN 
2AE2:  CR
2AE4:  ." I don't know what "
2AF9:  SWITCH@
2AFB:  EMIT
2AFD:  ."  is"
2B03:  EXIT
=0242 bytes   ok

[Peter Jakacki]

Peter -- three things

1 - does 3 actually exist yet, or is it still being sketched out ????

2 - quick rundown on CASE after the various alterations

3 - a short demo sketch for making use of the timers to control event lasting many minutes and even hours

tnx ... bbr

Only three short questions but here’s my lengthy reply.........

The V3 document was created at the start of the month and some of the optimizations were directly applied to V2.1. At present the main aim is to decouple the dictionary from the runtime cog and hand over these functions to the APC instead. So the APC has to handle the serial Flash or SD at some basic level enough to store the dictionary and search it efficiently. So it's not in a state at present for testing applications, only for testing the dictionary functions.

CASE
The use of the CASE statement has been simplified and basically works by saving the target value in a variable and implementing a transparent "fetch target, compare with compare value on stack, compile an IF .... EXIT THEN structure to handle the vector.

pub TC ( ch -- )
    CASE
    "4"         =[ ." Knock on the door, it's a 4" ]=
    "5"         =[ ." Let's jive, it's a 5" ]=
    "2"         CASE@ = "6" CASE@ = OR IF ." six or two, don’t mind a brew" ]=
    "7" "9"     ..[ ." Pick up sticks, it's more than six" ]=
    “@”         CASE@ < IF .” Alpha test “ ]=
;

In the above example the word CASE simply saves the target as a variable “case”. Next the =[ is an attempt at simplifying the comparison operation that resolves as “case C@ = IF”. Next comes the user code and then the closing bracket ]= which performs an EXIT and a THEN operation.
To handle OR operations as well as general comparisons I’ve now added the CASE= to compare the parameter with “case” and leave a flag on the stack. This flag can be used directly by an IF in place of the =[ word. For testing above or below it becomes just as easy to fetch the case variable to compare against so I have added CASE@ for that purpose. So perhaps =[ could be called CASEOF (traditional) and ]= becomes ENDCASE.

pub TC ( ch -- )
    CASE
    "4"         CASEOF ." Knock on the door, it's a 4" ENDCASE
    "5"         CASEOF ." Let's jive, it's a 5" ENDCASE
    "2"         CASE@ = “6” CASE@ = OR IF .” six or two, don’t mind a brew” ENDCASE
    "7" "9"     CASEIN ." Pick up sticks, it's more than six" ENDCASE
    "@"         CASE@ < IF .” Alpha test “ ENDCASE
;

The ENDCASE executes an EXIT so it will not return back to the statements to be processed any further.
Anything that hasn’t been filtered out by the CASE statements can be added in normally after the statements and if you need the target value again just use CASE@ to place it on the stack.

TIMERS
Since there is already a background cog which maintains timers this makes it easier to keep track of realtime events. I mostly use these as timeouts which have a timer loaded say for 500ms so that if my application checks the timer all it wants to know is if it has timed out like this:

The code that loads or retriggers the timer
#500 #mytimer TIMEOUT
In this case #mytimer is simply a constant from 0 to 7 that indexes a timer. Stack operands ( time index -- ) are time in milliseconds and timer index 0..7.

Then the code that checks the timer
#mytimer TIMEOUT? IF <timeout code> THEN

It is also possible to have the timer function execute code automatically upon a timeout like this:

Load the run address of MYALARM into #mytimer
‘ MYALARM #mytimer ALARM
To disable the alarm simply specify zero as the run address
0 #mytimer ALARM

then the timer would be loaded
#500 #mytimer TIMEOUT

After 500ms the timer would expire and MYALARM will be executed. For the action to be repeatable it is necessary for MYALARM to reload the timer itself as this is the most flexible approach. Bear in mind the MYALARM should not do too much processing as it will affect timing operations and also MYALARM is running in a separate cog from the application so output pins should not normally be shared.

Since the timers use longs and the countdown clock is 1ms it would take over 49 days before the maximum value would expire which I think is more than long enough for most events.

To set a timer for 5 hours you could do it this way:
#18,000,000 #mytimer TIMEOUT
But you might let Forth calculate the value for you:
#60,000 #60 * 5 * #mytimer TIMEOUT
So that 60,000 represented 60 seconds or a minute then multiply this by 60 to get hours then finally by 5. Notice too that the 5 like values 0..9 will never need to be forced to a number base as they will always resolve correctly if you are in hex or decimal. Besides these get compiled as fast constants if used this way.

Alternatively you could have some constants predefined so you could do it this way:
#hour 5 * #mytimer TIMEOUT
This is a little cleaner but still does not optimize the constant for runtime operation although it really doesn’t matter. V3 might allow compile time optimization so that constants such as we have seen would be evaluated and reduced to the minimum, in this case a single long. Mind you that that is not the way Forth does things but a little preprocessing couldn’t hurt and it might even be controlled by preprocessor operators.
[ #hour 5 * ] #mytimer TIMEOUT
In true Forth fashion however you could define a word called “hours” that is set as an immediate word and would evaluate the 5, calculate the constant and compile it.
5 hours #mytimer TIMEOUT


Hope that answers your questions and that you can understand it too!

[Brian Riley]

Peter -- three things

1 - does 3 actually exist yet, or is it still being sketched out ????

2 - quick rundown on CASE after the various alterations

3 - a short demo sketch for making use of the timers to control event lasting many minutes and even hours

tnx ... bbr

[Peter Jakacki]

Peter,
Can you give us a rough road map and time table of 2.1 and 3 ??? Does 3 exist yet? and will 2.1 be further developed? Or will 2.1 languish while 3 is made useful?


When coding what word or words will display to me how much room I have left? what numbers are we looking for and what do they mean?


TNX ... bbr

Hi Brian,
This is a compatible upgrade which will make V3 work just like V2 for non-enhanced systems so there is no reason to stick with V2 and all V2 apps should be compatible with V3 if they are operated in a non-enhanced system. Got that? Basically you will see no difference normally and although V2 will not continue to be maintained there is no reason not to use V3 which be compatible with V2 apps as they are now.

Since V2.1 is stable I'd rather not enhance that too much in case we run into stability problems. Once V3 has proven to be stable and the kinks knocked out of it then you can switch over to it as the default kernel. Any compatible improvements made to V3 in the meantime can be applied to a V2.2 leaving V2.1 intact. V2,2 and V3 will be accessed only as Google docs mostly with the Dropbox folder updated occasionally.

The whole idea of moving to V3 is to allow for more efficient memory usage for systems that have serial Flash or SD memory while still working with basic systems. Tachyon aims at providing a fast and compact Forth in a minimal system rather than supporting far more esoteric systems that have multiple Props or external O/S capable processors. The minimal system with maybe SD memory is fairly typical of how many actual embedded (not on the fun bench) "products" are implemented by Prop users.

As for finding out how much memory is left is a little bit harder and the current reporting words need some updating. Mostly I just type in RMAP just to see what's happening with memory:
RMAP
0000: 25 05 05 2D 0E 28 54 46 59 4B 3B 3C 47 6D 3E 4A
0400: 4B 58 10 .. .. .. .. .. .. .. .. .. .. .. .. ..
0800: .. .. .. .. .. 1B 59 65 5D 50 48 52 45 83 82 81
0C00: 89 7B 76 77 69 63 56 6D 3C 53 62 59 6A 5F 54 57
1000: 57 64 65 62 65 69 7C 60 6E 43 6A 7D 7E 74 64 7D
1400: 7A 4C 57 65 60 4A 5F 57 70 67 71 7A 62 7B 7C 6A
1800: 31 .. 4D 60 5A 4E 3A 17 56 36 54 59 65 59 51 47
1C00: 37 55 66 5D 52 45 64 5E 55 5E 63 6F 6D 62 7B 70
2000: 6E 46 66 5A 51 5D 4A 5E 64 3F 7C 6D 4F 77 69 6B
2400: 77 7C 6B 79 71 6F 71 10 71 69 6A 6C 84 75 5D 5B
2800: 63 67 5C 6B 6B 5F 15 3B .. .. .. .. .. .. .. ..
2C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
6000: .. .. .. .. .. .. .. .. 36 64 60 5E 71 5D 64 5B
6400: 59 61 6C 5A 6D 5F 5F 5A 5C 57 57 5C 60 55 5C 50
6800: 53 4F 4F 4E 53 51 52 3A 41 40 44 3A 36 3F 46 4B
6C00: 3C 46 50 49 46 42 63 60 57 66 60 53 53 58 55 48
7000: 50 50 54 4F 54 54 58 58 5A 70 74 6F 5E 5C 59 5D
7400: 5E 08 .. .. 75 70 62 56 6B 58 6A 62 6E 6D 65 6E
7800: 63 86 71 7C 69 54 6E 70 7D 9E 9F 8F 6D 23 05 ..
7C00: .. .. 1C 58 4C 6C 68 6C 74 86 54 5F 8C 09 .. .. ok

If you want a detailed byte by byte but compact look at memory you could do a wide ASCII dump using this definition:

: ADUMP ( src cnt -- )
    ADO CR I .WORD ." : " I #128 ADO I C@ DUP BL $7E WITHIN 0= IF DROP "." THEN EMIT LOOP #128 +LOOP
    ;
 

I've been down with a virus for the past week and my head feels like a gyro, I move it one way but it continues where it was but I will see what I can do with fixing up the reporting words. BTW, typing END won't hurt anything but does report the memory used (albeit incorrectly).

[Brian Riley]

Peter,
Can you give us a rough road map and time table of 2.1 and 3 ??? Does 3 exist yet? and will 2.1 be further developed? Or will 2.1 languish while 3 is made useful?


When coding what word or words will display to me how much room I have left? what numbers are we looking for and what do they mean?


TNX ... bbr

[D.P]

I've noticd the DS1302.fth file posted on the Tachyon dropbox is not functional.

Seems the bits masks for read and write were opposite for the r / w bit 0.

Also without the chip enable CE line being asserted I could not get any action from the chip.

One more thing is that the halt bit (bit 7 in the wrtsecreg) needs to be cleared as does the write disable bit in the wrtctrlreg since both are undefined at startup per the datasheet.

Below is a modified version of the file with an INIT word and my attempt to get the seconds to output from BCD per the datasheet.

Also the GET_SECONDS routine is now SHR and REV to put the bits in the right order.

The routine needs someone with more FORTH / TACHYON experience to "fix" logic errors. I will finish out the file once I see the pattern to resolve the seconds correctly.

EDIT [ going over the datasheet again I've figured out the #24 REV was un-necessary. The below code now gets seconds out correctly after unpacking with the BCD word! ] Use the INIT word to get the chip running. TACHYON is really causing me to work hard but it is worth the effort, thanks peter et al for all the help I've received.

\
\ DS1302 on PPDB
\ Routines based on SPIN Example
\
\
\ DS1302 Command codes
%10000001 CONSTANT rdsecreg
%10000000 CONSTANT wrtsecreg
%10000011 CONSTANT rdminreg
%10000010 CONSTANT wrtminreg
%10000101 CONSTANT rdhrsreg
%10000100 CONSTANT wrthrsreg
%10000111 CONSTANT rddatereg
%10000110 CONSTANT wrtdatereg
%10001001 CONSTANT rdmonreg
%10001000 CONSTANT wrtmonreg
%10001101 CONSTANT rdyrreg
%10001100 CONSTANT wrtyrreg
%10001111 CONSTANT rdctrlreg
%10001110 CONSTANT wrtctrlreg
%10010001 CONSTANT rdtrklreg
%10010000 CONSTANT wrttrklreg
%10111111 CONSTANT rdbrstreg
%10111110 CONSTANT wrtbrstreg

#P23 |< CONSTANT CE
#P24 |< CONSTANT I/O
#P25 |< CONSTANT CLK

DECIMAL


: DS1302! ( data -- )
    I/O OUTPUTS     \ set I/O PIN to OUTPUT (redundant)
    I/O SWAP     \ set up the I/O pin on DS1302 (pinmask data -- )
    CLK OUTCLR        \ force CLK lo
    8 FOR SHROUT
        CLK OUTSET
        NOP
        CLK OUTCLR 
        NEXT
    2DROP      \ drop the iomask and data, clean stack
    ;
    
: DS1302@ ( -- data )
    I/O DUP INPUTS \ set  I/O PIN to INPUT
    0			( mask data -- )
    8 FOR SHRINP
        CLK OUTSET
        NOP
        CLK OUTCLR
        NEXT
    NIP
        ;
        
: SET_SECONDS ( packed -- )
    CE OUTSET
    wrtsecreg DS1302!
    DS1302!
    CE OUTCLR
    ;

: GET_SECONDS ( -- packed )
    CE OUTSET
    rdsecreg DS1302!
    DS1302@
    CE OUTCLR
    #24 SHR   \ right justify
    \    #24 REV   \ not necessary 
    ;

: INIT
   CLK OUTCLR
   CE  OUTCLR
   #100 ms 
   
  \ Clear write-protect bit, undefined at start up
   CE OUTSET
   wrtctrlreg DS1302!  
   0 DS1302!
   CE OUTCLR

   \ Clear halt bit, undefined on startup
   CE OUTSET
   wrtsecreg DS1302!  
   0 DS1302!
   CE OUTCLR

   \ Clear trickle charger settings
   CE OUTSET
   wrttrklreg DS1302!
   0 DS1302!
   CE OUTCLR
;

: B2D DUP %01110000 AND 4 SHR #10 * SWAP %00001111 AND + ;

[D.P]

This is a very very old chip and I guess you meant the ADC0831. The datsheet says "easy interface to the COPS family of processors" which is definitely 70's vintage!
.
.
.
.

Thanks for the clarification and the nice pattern.

ADC0381.tiff

[Peter Jakacki]

Here's a simple ADC0381-N word ADC@

Please review, I'm just a little confused by the first BIT transfer, seems it's always present.

\
\ ADC0381 
\ Routines based on SPIN Example
\
\

#P20   |<  CONSTANT CS           '' chip select
#P21   |<  CONSTANT CLK          '' clock
#P22   |<  CONSTANT DOUT         '' chip data out

: ADC@ 
     DOUT INPUTS            '' set pin as input 
     CLK OUTCLR             '' set pin ouput and clr
     CS OUTSET              '' set to output and set high /CS  active low
     #100 ms
     CS OUTCLR              '' set to low   /CS active low
     #25 us                 '' conversion time
     CLK OUTSET             '' Initial clock ? 
     #10 us                  
     CLK OUTCLR
     #10 us
     DOUT  0             '' setup input mask and data for SHRINP
     #8 FOR              '' get data bits
       SHRINP            '' read and shift in next data bit
       CLK OUTSET        '' clock it, scope says 19Kz (10 - 40Kz) 
       #10 us                  
       CLK OUTCLR
       #10 us
     NEXT
     CS  OUTCLR           '' deselect
     NIP                  '' discard input mask
     #24 SHR              '' right justify data
     .                    '' show the output
;

This is a very very old chip and I guess you meant the ADC0831. The datsheet says "easy interface to the COPS family of processors" which is definitely 70's vintage!

I would have just used the [SPIOD] word which accepts a delay word, that way you just call it and then adjust the output.
However, looking at the chip itself the clock is required for the successive approximation and the ADC can't do a conversion without it, that's why the first bit
is to clock it so it can work out if the voltage is higher or lower than it's first "guess" (half). On the next clock it will refine the guess and of course output
the bit from the previous guess. After the last data bit is clocked out you don't need to clock it anymore and those extra cycles are just there to show you it doesn't
matter if you do or don't.

Putting aside the more efficient SPIOD method and looking at your code then this is what I would change.

\
\ ADC0381
\ Routines based on SPIN Example
\
\

#P20   |<  CONSTANT CS           '' chip select
#P21   |<  CONSTANT CLK          '' clock
#P22   |<  CONSTANT DOUT         '' chip data out

: ADC@ ( -- data )
     '' just a little initialization although it is only needed first time
     CS OUTSET              '' set to output and set high /CS  active low
     CLK OUTCLR             '' set pin ouput and clr
     DOUT INPUTS            '' set pin as input
     
     CS OUTCLR              '' set to low   /CS active low - 250ns min before clock so don't wait
     DOUT  0                '' setup input mask and data for SHRINP
     9 FOR                  '' get data bits + start bit Note: On the initial SAR clock - first guess - data (MSB) won't be availble yet
       CLK OUTSET           '' Clock it
       NOP NOP            '' dpn't go too fast - the chip has a 400kHz max clock                  
       CLK OUTCLR        '' The output now comes out of tristate if it's the first clock otherwise next data is available
       SHRINP               '' ( iomask data ) read and shift in next data bit ( iomask data+ )
     NEXT
     CS  OUTSET           '' deselect (was using an OUTCLR)
     NIP                  '' discard input mask
     #24 SHR              '' right justify data but it's still MSB first because of the SAR method
     #24 REV          '' flip it the right way around     
;

[D.P]

Here's a simple ADC0381-N word ADC@

Please review, I'm just a little confused by the first BIT transfer, seems it's always present.

\
\ ADC0381 
\ Routines based on SPIN Example
\
\

#P20   |<  CONSTANT CS           '' chip select
#P21   |<  CONSTANT CLK          '' clock
#P22   |<  CONSTANT DOUT         '' chip data out

: ADC@ 
     DOUT INPUTS            '' set pin as input 
     CLK OUTCLR             '' set pin ouput and clr
     CS OUTSET              '' set to output and set high /CS  active low
     #100 ms
     CS OUTCLR              '' set to low   /CS active low
     #25 us                 '' conversion time
     CLK OUTSET             '' Initial clock ? 
     #10 us                  
     CLK OUTCLR
     #10 us
     DOUT  0             '' setup input mask and data for SHRINP
     #8 FOR              '' get data bits
       SHRINP            '' read and shift in next data bit
       CLK OUTSET        '' clock it, scope says 19Kz (10 - 40Kz) 
       #10 us                  
       CLK OUTCLR
       #10 us
     NEXT
     CS  OUTCLR           '' deselect
     NIP                  '' discard input mask
     #24 SHR              '' right justify data
     .                    '' show the output
;

[RickInTexas]

So Rick what's your current status? Are you still having serial problems?

With Tera Term 4.78 and your settings, I am able to right-mouse click and upload code successfully. This terminal program is the first and only one that shows me the "spinner" while it is in progress. Joy at last.

Thanks Peter!

RickInTexas

[RickInTexas]

As some of you know the boards I primarily use for TF have 2 Atmel Megabit EEPROMs. This gives 256 KBytes of program storage..

I look at this as 8 32K Prop image slots. Slot 0 is the main boot position, slot 1 is reserve for Peter's currently troublesome RESTORE command, leaving 6 slots for more storage if you wish.

Below are three words I wrote for handling large EEPROM I think some of you may find them useful even in a single 64K

\  ------------- EPROM Boot Image tools ----------	
:	COPYIMG	( srcslot destslot -- )	$8000 3RD * SWAP $8000 * $7FC0 ECOPY DROP ;
:	STORIMG	( destslot -- ) $8000 * 0 SWAP $7FC0 ECOPY ;
:	RESTIMG	( srcslot -- )	0 $8000 3RD * SWAP $7FC0 ECOPY REBOOT ;
:	copyimg	COPYIMG	;
:	restimg	RESTIMG	;
:	storimg	STORIMG	;

Thanks for the handy code snippet.

I was going to make a Mouser order this week and that big eeprom is EOL and stock is 0.

Can you suggest a suitable replacement? SOIC is ok.

Better yet, what do I need in terms of memory organization?

I like the idea of having 32k banks for image management.

RickInTexas

[Brian Riley]

As some of you know the boards I primarily use for TF have 2 Atmel Megabit EEPROMs. This gives 256 KBytes of program storage..

I look at this as 8 32K Prop image slots. Slot 0 is the main boot position, slot 1 is reserve for Peter's currently troublesome RESTORE command, leaving 6 slots for more storage if you wish.

Below are three words I wrote for handling large EEPROM I think some of you may find them useful even in a single 64K

\  ------------- EPROM Boot Image tools ----------	
:	COPYIMG	( srcslot destslot -- )	$8000 3RD * SWAP $8000 * $7FC0 ECOPY DROP ;
:	STORIMG	( destslot -- ) $8000 * 0 SWAP $7FC0 ECOPY ;
:	RESTIMG	( srcslot -- )	0 $8000 3RD * SWAP $7FC0 ECOPY REBOOT ;
:	copyimg	COPYIMG	;
:	restimg	RESTIMG	;
:	storimg	STORIMG	;

[RickInTexas]

Not really, BACKUP has been working fine since day one...

Great. That helps a lot.

So Rick what's your current status? Are you still having serial problems? Seeing that you still had problems even with 1ms character delay seemed totally improbably that it had anything to do with the Prop or Tachyon. I will see if I can write a couple of lines of code to help debug this.

Truthfully, I have been enjoying the new version that's working quite nicely, also working through the Tachyon and EXTEND.fth modules so I can get a good grasp on what the functionality of the core system without introducing additional elements to complicate my learning.

I will get into extending the core code base in the next day or two, as obviously that's
requisite to moving to custom extensions to make it useful to do real work.

I will keep you apprised. Now that I have the right (current) tterm, that should help a lot.

RickInTexas

[Peter Jakacki]

I found "my problem" with my large application and it turned out that COLD was not clearing all the vectors which meant that after a few COLDs and reloading my apps I would find that Tachyon exhausted it's vector table. As a note there would never really be a problem with not having enough vectors as the real limit is the amount of RAM for code and data anyway. Even with my app and drivers etc I still have 357 vectors free.

V3 will allow more memory to be free because it will maintain most of the names in EEPROM/Flash but when it comes to creating a "build" during which time the system is not normally running an app it will use another cog to cache from EEPROM/Flash and search the dictionary etc. This way the runtime Tachyon cog(s) can have a few more goodies loaded as there are 24 longs taken just by the CMPSTR instruction and it's really only needed for fast loads. V3 will also introduce some other enhancements including compile-time-only headers and code (discarded at the end of a build). Seeing that serial Flash is so cheap and small it makes sense to allow source modules to be loaded from serial Flash or SD so that a build would only need user code loaded through the console and it could just ask to "include L6470.fth" for instance. If Flash or SD exists it makes sense to save new source code to that first and then compile which should be a far more efficient way of doing things. I've got some 8M byte SPI chips as well as the 1M byte ones ready for P2 and many of my systems include serial Flash as well as SD memory. To add SPI Flash to existing systems only requires 2 I/O as I frequently safely double-duty the I2C bus lines for SCK and MOSI. Then there's the P2 version which is not so restricted.....

[Peter Jakacki]

So use REBOOT for now? (Please excuse if this sounds like a noob question: it is!)

Also, can BACKUP be used without issue? Edit: I see it is an issue.



RickInTexas

Not really, BACKUP has been working fine since day one and RESTORE is only used if you have a larger EEPROM and a BACKUP also backups up the previous image although I have disabled this automatic feature (Brian?). Normally all you need to do is a BACKUP which updates the EEPROM with the current RAM image minus the parts that should not be overwritten etc. I think the problem I'm seeing is more to do with this rather large application which messes with the EEPROM but I will investigate further.

So Rick what's your current status? Are you still having serial problems? Seeing that you still had problems even with 1ms character delay seemed totally improbably that it had anything to do with the Prop or Tachyon. I will see if I can write a couple of lines of code to help debug this.

[RickInTexas]

Oh yeah, I remember now that I have been having a little problem lately with COLD then reloading applications because it's not releasing all the used vectors but that may be tied with BACKUP itself. I will have a look.

So use REBOOT for now? (Please excuse if this sounds like a noob question: it is!)

Also, can BACKUP be used without issue? Edit: I see it is an issue.



RickInTexas

[Peter Jakacki]

I retract my earlier comments about what went wrong. The more I thought about the more I was convinced it was something else.

The one repeatable symptom of was the dictionary no longer knowing "MY" I narrowed it down to the BACKUP/RESTORE. I checked after each BACKUP and "MY QWORDS" worked.. But as soon as I did a RESTORE all I got was "MY ??? QWORDS" and my secondary marker the 'fast constant' 16 was no longer evaluated as 16d but as $16. I rebuilt my kernel (130605) and EXTEND (130607) three times and three more times it did the same thing upon invoking the RESTORE word.

Now what???

Oh yeah, I remember now that I have been having a little problem lately with COLD then reloading applications because it's not releasing all the used vectors but that may be tied with BACKUP itself. I will have a look.

[Brian Riley]

I retract my earlier comments about what went wrong. The more I thought about the more I was convinced it was something else.

The one repeatable symptom of was the dictionary no longer knowing "MY" I narrowed it down to the BACKUP/RESTORE. I checked after each BACKUP and "MY QWORDS" worked.. But as soon as I did a RESTORE all I got was "MY ??? QWORDS" and my secondary marker the 'fast constant' 16 was no longer evaluated as 16d but as $16. I rebuilt my kernel (130605) and EXTEND (130607) three times and three more times it did the same thing upon invoking the RESTORE word.

Now what???

[Peter Jakacki]

BTW, this is basically the same code I posted previously but I have overlaid it with the PASM example so those unfamiliar with Forth can follow the code.

[

( TACHYON Forth COS/SIN lookup method as per PASM method - Hydra Manual p212 )

\ getcos    add        sin,sin_90         'for cosine, add 90°
pub COS ( angle -- cosine )
     $800 +
\ getsin     test        sin,sin_90 wc    'get quadrant 2|4 into c
\         test         sin_sin_180 wz     'get quadrant 3|4 into nz
\        negc         sin,sin             'if quadrant 2|4, negate offset
pub SIN ( angle -- sine )
    DUP $1000 AND SWAP                     \ test quadrant 3|4 
    DUP $800 AND IF NEGATE THEN            \ test quadrant 2|4 and negate if true 
\         or         sin,sin_table        'or in sin table address >> 1
\         shl         sin,#1              'shift left to get final word address
\         rdword     sin,sin              'read word sample from $E000 to $F000
    $7000 OR 2* W@                         \ lookup word from sin table 
\         negnz     sin,sin               'if quadrant 3|4, negate sample
\ getsin_ret
\ getcos_ret    ret                       '39..54 clock (variance is due to Hub sync on RDWORD)

    SWAP IF NEGATE THEN                    \ if quadrant 3|4, negate sample
    ;

Here is a quick look at the output by graphing it onto the terminal.

#181 0 DO CR I #45 * 2/ SIN 9 SHR 0 DO ." *" LOOP 4 +LOOP  
*
********
*****************
**************************
**********************************
*******************************************
***************************************************
***********************************************************
*******************************************************************
**************************************************************************
*********************************************************************************
****************************************************************************************
**********************************************************************************************
****************************************************************************************************
*********************************************************************************************************
**************************************************************************************************************
******************************************************************************************************************
**********************************************************************************************************************
*************************************************************************************************************************
***************************************************************************************************************************
*****************************************************************************************************************************
*******************************************************************************************************************************
*******************************************************************************************************************************
*******************************************************************************************************************************
*******************************************************************************************************************************
******************************************************************************************************************************
****************************************************************************************************************************
**************************************************************************************************************************
***********************************************************************************************************************
********************************************************************************************************************
****************************************************************************************************************
***********************************************************************************************************
******************************************************************************************************
*************************************************************************************************
*******************************************************************************************
************************************************************************************
******************************************************************************
**********************************************************************
***************************************************************
*******************************************************
***********************************************
***************************************
******************************
**********************
*************
**** ok

[Peter Jakacki]

It turns out that while working on this I had some kind of a RAM failure in my DIP--40 Prop ... just few bytes and when it loaded it scrambled things rendering a half dozen or so commands useless or "???" like "MY" an your fast constant 16. Things were degenerating, culmination in I could load EEPROM and sort of run, but if I loaded RAM only SimpleIDE would verify the RAM load and it would always fail.

I pulled the chip, replaced it. rebuilt my kernel and extensions, tested your sine stuff ... since it was all back to working, I took the bad Prop, bent up its legs and threw it into File 13

cheers ... BBR

File 13 is for the embarrassing stuff but weird stuff like "RAM failure" needs to be investigated and should be pushed to the TOS. Any chance of rebending this and finding out what happened? Could it be that it's RC oscillator is a little on the fast side and the EEPROM too slow, perhaps only because of a weak SDA pullup resistor? What value are you using because I know that you have multiple EEPROMs in your system and 10K is enough for most but 2K2 would be far better.

[Brian Riley]

It turns out that while working on this I had some kind of a RAM failure in my DIP--40 Prop ... just few bytes and when it loaded it scrambled things rendering a half dozen or so commands useless or "???" like "MY" an your fast constant 16. Things were degenerating, culmination in I could load EEPROM and sort of run, but if I loaded RAM only SimpleIDE would verify the RAM load and it would always fail.

I pulled the chip, replaced it. rebuilt my kernel and extensions, tested your sine stuff ... since it was all back to working, I took the bad Prop, bent up its legs and threw it into File 13

cheers ... BBR

[Peter Jakacki]

You forgot a # on the 16 . I added a decimal point on the display

    
    pub .SIN
        SIN2 #10,000 * #16 SHR ."  = ." .DEC 
        ;

Yes, normally you would need a # to force it to decimal but I added a 16 as a fast constant instruction so this compiles as one byte rather than a 2 byte literal since it gets used often enough I felt.
I was also thinking that I would put a "0." in front of the result but of course it is only a demo anyway. I did have a chance to look at some threads discussing the use of the sine table and see that Phil has refined the method a little so I may look at coding that too. The 16 SHR is not the same as a 65535 / but close enough for now. Perhaps while I am into this I may even write a maths library although I favor scaled integer operations normally. Are there any opinions on the most suitable method and representation and the precision required? Do I go all the way or is there a minimal requirement? It may be that I might create a floating point stack in hub ram so I am not limited by memory with what can be achieved.

[Brian Riley]

You forgot a # on the 16 . I added a decimal point on the display

	
	pub .SIN
	    SIN2 #10,000 * #16 SHR ."  = ." .DEC 
	    ;

[Peter Jakacki]

... on another topic altogether

I was reading this thread

http://forums.parallax.com/showthrea...table-question

and realized I had never seen an TF words for accessing the Prop's sine table.

So I dug into my PDF of the Hydra book (it is a great resource!) and found it on page 212.

I cobbled this together:

:    Sin    ( angle -- sine )
    DUP 1 SHL $FFE AND DUP
    OVER $800 AND 
                 IF  $F000 - ELSE   $E000 + THEN
    @ $FFFF AND
    ;

:   SIN    Sin #10000 * $FFFF / ."  ==> ." $040A .NUM CR ;

"Sin" is the fetch word. "SIN" takes the actual sine off the stack and prints it out as a decimal.

One shortcoming of the sine table is that 2049 entries divided by 90 degrees when done by integer math dropping the remainder gets you 22 entries per degree, whereas floating point gets you 22.76666... a not inconsiderable error.

If anyone can tighten this up ... please do!

... enjoy ... BBR

Thanks for bringing this up Brian, to tell the truth I've never looked into it. There are a few errors in your code but this is what I have found will work though it's not the final version. The Spin version looked weird so I found a PASM version which I used as the basis.

pub SIN ( angle -- sine )
    DUP $800 AND IF NEGATE THEN 
    $7000 OR 2* W@ 
    ;

\ This version takes the angle scaled to 2 decimal places and converts it to the 13-bit sine    
pub SIN2 ( angle.00 -- sine )
    #45 * #200 / SIN
    ;

pub .SIN
    SIN2 #10,000 * 16 SHR ."  = " .DEC 
    ;
pub SINES  #9000 0 DO CR I .DEC SPACE I .SIN #100 +LOOP ;

[Brian Riley]

... on another topic altogether

I was reading this thread

http://forums.parallax.com/showthrea...table-question

and realized I had never seen an TF words for accessing the Prop's sine table.

So I dug into my PDF of the Hydra book (it is a great resource!) and found it on page 212.

I cobbled this together:

:	Sin	( angle -- sine )
	DUP 1 SHL $FFE AND DUP
	OVER $800 AND 
                 IF  $F000 - ELSE   $E000 + THEN
	@ $FFFF AND
	;

:   SIN    Sin #10000 * $FFFF / ."  ==> ." $040A .NUM CR ;

"Sin" is the fetch word. "SIN" takes the actual sine off the stack and prints it out as a decimal.

One shortcoming of the sine table is that 2049 entries divided by 90 degrees when done by integer math dropping the remainder gets you 22 entries per degree, whereas floating point gets you 22.76666... a not inconsiderable error.

If anyone can tighten this up ... please do!

... enjoy ... BBR

[D.P]

I will hook up the scope and have a look at the timing as I can simulate a download from another Prop so that I can control the timing a little better. It may be that I need to optimize the receive post-processing to make sure it's ready for the next character. But truly, under Linux Mint (Ubuntu base) and using FT232Rs and Minicom and i7 I am not experiencing any of these problems though obviously they exist.

With the latest kernel I'm having problems with minicom and the Prop Professional Dev Board, the BOE and QuickStart boards work just dandy. Earlier version of the FTDI chip?

The symptom is no I in I/O, the banner appears but no Input to the device is possible. Not even das blinken lits on the FTDI chip during keystrokes?

The PPDB works okay in TeraTerm and ZTerm but both of these can't compare to compile speeds (uploads) I get with Minicomm. Only using 230400 8N1

One other thing is that the PPDB will only boot the kernel if the usb is plugged in to a computer. And yes I do have pwr to the PPDB via a 7.5V supply. I must be missing something here, again. doh

mac osx 10.8.2

[Peter Jakacki]

I pulled the most recent DropBox TF folder, compiled and burnt EEPROM for 230400 baud and did my copy/paste this time at 230400 8n2... still no love!!!! Soooo ... it was back to 115200 and 8n1 and all was well in Mudville once again.

My setup is a late 2012 iMac with a quad core I7 , up-to-date Mtn Lion and Zterm

cheers ... BBR

I will hook up the scope and have a look at the timing as I can simulate a download from another Prop so that I can control the timing a little better. It may be that I need to optimize the receive post-processing to make sure it's ready for the next character. But truly, under Linux Mint (Ubuntu base) and using FT232Rs and Minicom and i7 I am not experiencing any of these problems though obviously they exist.

[Brian Riley]

I pulled the most recent DropBox TF folder, compiled and burnt EEPROM for 230400 baud and did my copy/paste this time at 230400 8n2... still no love!!!! Soooo ... it was back to 115200 and 8n1 and all was well in Mudville once again.

My setup is a late 2012 iMac with a quad core I7 , up-to-date Mtn Lion and Zterm

cheers ... BBR

[RickInTexas]

Something at last, but TeraTerm Pro is the old old version and the link I gave for TeraTerm is the new new Open Source version. Thanks for the feedback, I will get back to you later.

Doh! I hit the download link and saw this page (but it was in JAPANESE on my PC)
.
http://en.sourceforge.jp/projects/ttssh2/releases/://

So I ended up with version 2.3. Sheesh, the availability of versions for DEC Apha and WinCE should have been a clue

Looking at it now on my iPad, I see the current release, 4.78, though through my carelessness I didn't see It. Need to page down to see the new release.

Well, at least I know where to get a legacy terminal should I load up Win 3.1 to show my kids what a PC looked like in the good old days.


RickInTexas

[Peter Jakacki]

Hurray! I'm very happy now. Loaded the binary from Post #654

Something at last, but TeraTerm Pro is the old old version and the link I gave for TeraTerm is the new new Open Source version. Thanks for the feedback, I will get back to you later.

[Peter Jakacki]

Since the build of 05/20/2013 <BEGIN AGAIN> has been removed.

Could you fix up this simple for word with suitable replacement syntax?

: MYPWM ( duty pin -- )
    MASK DUP OUTCLR
    @SCK COGREG!
    #100 MIN
    #1000 * #100005 OVER -    \ Scale to lower frequency ( duty off pin ) 
    <BEGIN
      CLOCK OVER DELTA
      CLOCK DUP DELTA
      KEY? AND            \ keep doing this until we hit a key
    AGAIN>    
    2DROP
    ;

The enhanced version of the PWM that runs in its own cog is built into EXTEND.fth, the usage of which is shown below and besides you would need an UNTIL instead of an AGAIN if you wanted to terminate the loop. I never really used <BEGIN and AGAIN> although the concept is good but the cog memory is limited. Just use BEGIN AGAIN UNTIL WHILE REPEAT words instead. Gotta fly now but I will get back to this thread a little later.

USAGE: 

( implement 8 PWM channels on P0..P7 )

\ setup area for PWM values

TABLE pwmtbl #252 ALLOT		

\ Set the frequecy to 5kHz

#5000 PWMFREQ			

\ Start up PWM using from P0 for 8 channels	

#P0 8 pwmtbl RUNPWM		


\ Set PWM channel 0 for 50%
$80 0 PWM!
\ Set PWM channel 7 for 25%
#25 % 7 PWM!			

}

[RickInTexas]

Hurray! I'm very happy now. Loaded the binary from Post #654
----------------------------------------------------------------
Propeller .:.:--TACHYON--:.:. Forth V21130605.0000

NAMES: $623B...7448 for 4621 (22459 bytes added) with 22735 bytes free
CODE: $0000...2999 for 6028 (4377 bytes added) with 22119 bytes free
CALLS: 0622 vectors free

AUTORUN BOOT
MODULES LOADED:
1880: EXTEND.fth Primary extensions to TACHYON kernel - 130604.1300
----------------------------------------------------------------

I am making several backups of that binary gem now.

To get the latest kernel just grab the files from the Dropbox account and compile Tachyon V2.1.spin with the correct crystal and PLL settings for your board. Once loaded you can switch to your terminal emulator and if you are using Windows I recommend TeraTerm. Make sure you configure this at 230400 baud 8N2 and 10ms line delay with char delay set to 0. Disable any handshake controls. From there just copy and paste or "File Send" EXTEND.fth. You now have your Tachyon up and running. This whole procedure from whoa to go takes less than 30 seconds. Is that what you are doing?

Oh yes, EXACTLY and then with a bunch of super-conservative settings out of desperation really.

@Brian. Interesting to see that. Serial RS-232 etc (heck I can remember those acoustically-couple modems) has always been such a basic utility that just plain works >99.9% of the time. In fact Tachyon has been most impressive, working fine now at 460_800, nice.

As for the pasting/uploading stuff, I'm pretty burned out on that. I've been thinking of a utility program that parses and input file or pasted code, EXTEND.fth et. al. and then manages the upload by waiting for an "ok" as an ACK before sending the next line.

It is frustrating to me to mess with something when I cannot see what is really going on. I don't have a serial protocol analyzer.

I guess I'm spoiled by years of electronics/avionics where I had whatever I needed to truly understand and see what is happening at the lowest level. At least a good 100Mhz scope (actually have that now) up to a $500k specialized test stack for 1030/1090 Mhz Mode-S transponders.

<end tantrum>

Thanks everyone for your patient and detailed help. I think that ttermpro was the only serial program I did not try. Damn it's old, there's a dl for Win 3.1! Hey, maybe I'll try that on Raspberry Pi!

Peter, thanks for your most excellent documentation. It is a rare duck that has the superb technical capabilities couple with top-notch docs that are great for techies yet accessible to a first-grader!

Rick In (Plano) Texas.

[D.P]

Okay, so I run at 23400 using Minicom with a 10ms delay and all's fine. When I use TeraTerm in Windows it's the same except I need 2 stop bits and this is probably because my receive cog is doing a bit of extra processing on each character and needs that little bit of time between stop and start bits. BTW, when you do a CONBAUD you don't need to BACKUP as this information is written directly into EEPROM anyway and doesn't become effective until a REBOOT (or just ^C).

I've been trying to test a binary image dump and load but it hasn't been working so I'm just digging into why it isn't. Once I do I will reactivate the binary dump method and update the binary images in Dropbox.

EDIT: Sorted out my problem with BINARYDUMP and now there is a new binary that includes EXTEND.fth set for 115200 baud and 5MHz crystal. I may put some others in there also.
EDIT: fixed link to binary - was set to 230400 baud

Since the build of 05/20/2013 <BEGIN AGAIN> has been removed.

Could you fix up this simple for word with suitable replacement syntax?

: MYPWM ( duty pin -- )
	MASK DUP OUTCLR
	@SCK COGREG!
	#100 MIN
	#1000 * #100005 OVER -	\ Scale to lower frequency ( duty off pin ) 
	<BEGIN
	  CLOCK OVER DELTA
	  CLOCK DUP DELTA
	  KEY? AND			\ keep doing this until we hit a key
	AGAIN>	
	2DROP
	;

[Peter Jakacki]

I occasionally have had a similar problem with copy/paste of EXTEND.fth choking and when I reach my self abuse limit I recompile the kernel spin file for 57,600 and EXTEND almost always goes in on the first try at that speed. EXTEND ends with a ?BACKUP, so your work is safe . Now I run at 115_200 so I do a

#115_200 CONBAUD BACKUP REBOOT

Don't forget too change your terminal baud rate to match the 115_200 or whatever you chose.

Okay, so I run at 23400 using Minicom with a 10ms delay and all's fine. When I use TeraTerm in Windows it's the same except I need 2 stop bits and this is probably because my receive cog is doing a bit of extra processing on each character and needs that little bit of time between stop and start bits. BTW, when you do a CONBAUD you don't need to BACKUP as this information is written directly into EEPROM anyway and doesn't become effective until a REBOOT (or just ^C).

I've been trying to test a binary image dump and load but it hasn't been working so I'm just digging into why it isn't. Once I do I will reactivate the binary dump method and update the binary images in Dropbox.

EDIT: Sorted out my problem with BINARYDUMP and now there is a new binary that includes EXTEND.fth set for 115200 baud and 5MHz crystal. I may put some others in there also.
EDIT: fixed link to binary - was set to 230400 baud

[Brian Riley]

I occasionally have had a similar problem with copy/paste of EXTEND.fth choking and when I reach my self abuse limit I recompile the kernel spin file for 57,600 and EXTEND almost always goes in on the first try at that speed. EXTEND ends with a ?BACKUP, so your work is safe . Now I run at 115_200 so I do a

#115_200 CONBAUD BACKUP REBOOT

Don't forget too change your terminal baud rate to match the 115_200 or whatever you chose.

[Peter Jakacki]

D.P and Peter. Thanks for the quick replies.

Still same symptoms. Loaded Latest Tachyon file "Tachyon V2.1.spin" with the following changes for QuickStart:

CON
_CLKMODE = XTALL + PLL16 ' <---------------- change to suit
_XINFREQ = 5_000_000 ' <---------------- change to suit your crystal

baud = 115_200 ' <-- change - tested from 300 baud to 3M baud

This works so far. Next I did a "File Upload" on the latest "EXTEND.fth. TeraTerm chokes with Peter's settings. I even tried a 1 MS per character delay on top of the 10 MS per line delay

Could someone possibly upload a binary with these settings to help me isolate this?.

Thanks, Rick (In Texas) Scheck@Gmail.com. First name plus Last name@gmail.com..

Sounds like something wrong with the serial setup although I've never had a problem, might even be the serial cable except it's a QuickStart. Anyway TeraTerm should be setup as indicated previously and under "Terminal setup" just make sure that "new line" is set to CR for both rx and tx. A failure on a 1ms char delay cannot be a failure of the kernel but something else seems to be going on. I will make a binary to suit and load it into Dropbox binaries folder shortly but I don't think that will solve your problem. Do you have the latest USB drivers and what version of Windows are you using not that I think that the problem could be there.

I've attached my TeraTerm ini file, just remove the .bin in the name and copy to your TeraTerm folder then run TeraTerm.

[RickInTexas]

D.P and Peter. Thanks for the quick replies.

Still same symptoms. Loaded Latest Tachyon file "Tachyon V2.1.spin" with the following changes for QuickStart:

CON
_CLKMODE = XTALL + PLL16 ' <---------------- change to suit
_XINFREQ = 5_000_000 ' <---------------- change to suit your crystal

baud = 115_200 ' <-- change - tested from 300 baud to 3M baud

This works so far. Next I did a "File Upload" on the latest "EXTEND.fth. TeraTerm chokes with Peter's settings. I even tried a 1 MS per character delay on top of the 10 MS per line delay

Could someone possibly upload a binary with these settings to help me isolate this?.

Thanks, Rick (In Texas) Scheck@Gmail.com. First name plus Last name@gmail.com..

[D.P]

Hi Peter. Great to see you're still active on Tachyon, thanks for the tremendous gift to the Propeller world!

I have been following Tachyon, mostly passively from the beginning. Your recent additions have renewed my interest in it.

I have been hoping that this issue would go away, but it has not --- I'm stuck at version " Propeller .:.:--TACHYON--:.:. Forth V20120919.1215" in the sense that in every release from there I have the following symptoms:

I can load Tachyon, and it works, but exhibits this strange behavior:

1) I hit <enter> and get the familiar "ok" prompt. Joy.

2) I enter "WORDS" <enter> and get "WORDS ???". No Joy.

I get the same "___ ???" response from all my "warm and fuzzy" test WORDS such as .VER, PINS, QWORDS etc.

I can however get working a simple test sequence like:

2 3 + .S <enter> and get "2 3 + . 5 ok".

I suspect a serial/comms issue, as I've been unable to get " EXTEND.fth" to load since the aforementioned "V20120919.1215" release. I think I uploaded that the hard way, cutting and pasting a line at a time, IIRC. Ugh. Thank God for the EEPROM backup words!

I am running a PC and have tried:

1) Several different Prop boards, most recently a Quickstart that I bought thinking that going from 32 to 64 KB, and ruling out a Prop HW issue. Nope.

2) Different terminal apps including PuTTY, "Parallax Serial Terminal", CoolTerm, Termite and "Br@y++ 1.9b".

I could not get "Minicom2.6.1" working under Windows or Linux in a VM, but I did just get a Raspberry Pi, FWIW.

Thoughts? Is anyone successfully using this under Windows?

Rick (In Texas)

P.S. I have also tried the available binaries from Dropbox; same results.

Just rebuilt the world with the lastest Tachyon files and Extend.fth, no problems.
Mac OSX 10.8.2, BST, MiniComm. I've also confirm the build / functionality with Win7, PropTool, TeraTerm
I'm sure this thread can help you figure this out.
Also I'm looking forward to more neat Tachyon stuff.
Oh and thanks Peter!

[Peter Jakacki]

Hi Peter. Great to see you're still active on Tachyon, thanks for the tremendous gift to the Propeller world!

I have been following Tachyon, mostly passively from the beginning. Your recent additions have renewed my interest in it.

I have been hoping that this issue would go away, but it has not --- I'm stuck at version " Propeller .:.:--TACHYON--:.:. Forth V20120919.1215" in the sense that in every release from there I have the following symptoms:

I can load Tachyon, and it works, but exhibits this strange behavior:

1) I hit <enter> and get the familiar "ok" prompt. Joy.

2) I enter "WORDS" <enter> and get "WORDS ???". No Joy.

I get the same "___ ???" response from all my "warm and fuzzy" test WORDS such as .VER, PINS, QWORDS etc.

I can however get working a simple test sequence like:

2 3 + .S <enter> and get "2 3 + . 5 ok".

I suspect a serial/comms issue, as I've been unable to get " EXTEND.fth" to load since the aforementioned "V20120919.1215" release. I think I uploaded that the hard way, cutting and pasting a line at a time, IIRC. Ugh. Thank God for the EEPROM backup words!

I am running a PC and have tried:

1) Several different Prop boards, most recently a Quickstart that I bought thinking that going from 32 to 64 KB, and ruling out a Prop HW issue. Nope.

2) Different terminal apps including PuTTY, "Parallax Serial Terminal", CoolTerm, Termite and "Br@y++ 1.9b".

I could not get "Minicom2.6.1" working under Windows or Linux in a VM, but I did just get a Raspberry Pi, FWIW.

Thoughts? Is anyone successfully using this under Windows?

Rick (In Texas)

P.S. I have also tried the available binaries from Dropbox; same results.

To get the latest kernel just grab the files from the Dropbox account and compile Tachyon V2.1.spin with the correct crystal and PLL settings for your board. Once loaded you can switch to your terminal emulator and if you are using Windows I recommend TeraTerm. Make sure you configure this at 230400 baud 8N2 and 10ms line delay with char delay set to 0. Disable any handshake controls. From there just copy and paste or "File Send" EXTEND.fth. You now have your Tachyon up and running. This whole procedure from whoa to go takes less than 30 seconds. Is that what you are doing?

You can also use the Google docs versions even though they have graphics and tables in there, just copy and paste, both for the kernel spin file into the Prop tool etc. BTW, I still use BST as it also outputs a listing which Is important for honing the kernel.

Anyhow, hope that gets you going otherwise I don't have a clue what's going on there.

EDIT: I've included part of the Dropbox directory listing so you can check the dates etc.


I've just checked it with TeraTerm in Windows and I had to set it to 8N2, that is 2 stop bits and then I don't have any problems pasting files through the terminal. I also tested compiling the kernel in the Spin tool and that works fine too on an old demo board.

[RickInTexas]

Hi Peter. Great to see you're still active on Tachyon, thanks for the tremendous gift to the Propeller world!

I have been following Tachyon, mostly passively from the beginning. Your recent additions have renewed my interest in it.

I have been hoping that this issue would go away, but it has not --- I'm stuck at version " Propeller .:.:--TACHYON--:.:. Forth V20120919.1215" in the sense that in every release from there I have the following symptoms:

I can load Tachyon, and it works, but exhibits this strange behavior:

1) I hit <enter> and get the familiar "ok" prompt. Joy.

2) I enter "WORDS" <enter> and get "WORDS ???". No Joy.

I get the same "___ ???" response from all my "warm and fuzzy" test WORDS such as .VER, PINS, QWORDS etc.

I can however get working a simple test sequence like:

2 3 + .S <enter> and get "2 3 + . 5 ok".

I suspect a serial/comms issue, as I've been unable to get " EXTEND.fth" to load since the aforementioned "V20120919.1215" release. I think I uploaded that the hard way, cutting and pasting a line at a time, IIRC. Ugh. Thank God for the EEPROM backup words!

I am running a PC and have tried:

1) Several different Prop boards, most recently a Quickstart that I bought thinking that going from 32 to 64 KB, and ruling out a Prop HW issue. Nope.

2) Different terminal apps including PuTTY, "Parallax Serial Terminal", CoolTerm, Termite and "Br@y++ 1.9b".

I could not get "Minicom2.6.1" working under Windows or Linux in a VM, but I did just get a Raspberry Pi, FWIW.

Thoughts? Is anyone successfully using this under Windows?

Rick (In Texas)

P.S. I have also tried the available binaries from Dropbox; same results.

[Peter Jakacki]

Here's the code for reading multiple inputs just like the Quick Start demo does in case you need it. It filters the input so that you need 32 consecutive reads of an active input to obtain a valid signal. This is probably a little bit of overkill in which case you could reduce the code to just the first line instead.
Code execution time is mainly dependant upon the decay delay which is this case is set to 500us. Tachyon reports: NEWCNT TOUCH@ .LAP 680us ok

BYTE touch #31 ALLOT
pub TOUCH@ ( -- pins )
    $FF DUP OUTSET INPUTS #500 us P@ INVERT $FF AND        \ Pulse the pins and read state after a delay
    touch DUP 1+ #31 <CMOVE                    \ make room for the new entry (shift method)
    touch C!                        \ update buffer
    $FF touch #32 ADO I C@ AND LOOP                \ Calculate filtered result
    ; 

You can run this code in it's own cog if you want constant and predictable scanning in which case you would do this:

BYTE reading    
pub TOUCHTASK
    BEGIN
      TOUCH@ ?DUP IF reading C! THEN            \ get the latest reading and update only if it's valid (easy for app to read and reset)
    AGAIN
    ;
    
\ Add this code to your startup or just run it    
' TOUCHTASK TASK? RUN

This one only has a single byte global variable as the buffer but it does prevent the reading from being overwritten by a key release in which case even a lazy app will detect the keypress after which it will clear the reading.

[Peter Jakacki]

You just need the new kernel so I've updated the Dropbox files in case you are using those.

[Brian Riley]

The reason BACKUP might not seem to work is that ....

It locks up and never gives control back to me! ... and nevr gives an "ok" ... I tried it on 3 different boards ... same everywhere.


cheers .... BBR

[Peter Jakacki]

The word works perfectly .... thank you Peter.

OBTW ... the "bleeding edge" EXTEND.fth (130603) has BACKUP broken. It gets from ?BACKUP to BACKUP and locks before it even starts to spin its little propeller. I used the next older version (CHANGELOG entry 130328) and all was well again. my base kernel was 130520

I just had a look at the "Touch Buttons.spin" file and it dedicates a cog to scanning multiple keys. Handling multiple keys is just as easy as handling one and you have a choice of whether to capture these in real time in which case a proper FIFO buffer would be in order or else for many applications polling is fine. I will check out code for multiple keys shortly and post that as a link on the intro page.

The reason BACKUP might not seem to work is that I made a decision to change the COGREG that the CLOCK instruction uses for it's mask. I2C routines use CLOCK and previously it always used 0 COGREG whereas now it uses 4 COGREG so that requires the newer kernel for the I2C routines to work. The bleeding edge files are the Google docs but I will update the text files in Dropbox. Why the change? I have SPI routines in applications that use these COGREGs to hold the masks for SCK,MOSI,MISO etc but the I2C accesses in-between were having to save and restore 0 COGREG which seemed redundant when there was a spare parameter register available.

[Brian Riley]

Hi Brian, did you try something as simple as PINS to check the state of the I/O pins. I found that this reports it's either open or else pulled-down when you touch it. Here's a simple word that checks to see if a pin is floating or loaded and you can increase the sensitivity by increasing the delay. Alternatively you can just lock the delay into the word either as a constant or as a variable. BTW, I hope to get back into Tachyon and some more enhancements as well as other things after being buried in work and life for so long.

pub TOUCH? ( level pin# -- flg )
    DUP PINSET DUP PININP SWAP us PIN@ NOT
    ;
\ demo usage (verbose)
#1,000 #P0 TOUCH? .

The word works perfectly .... thank you Peter.

OBTW ... the "bleeding edge" EXTEND.fth (130603) has BACKUP broken. It gets from ?BACKUP to BACKUP and locks before it even starts to spin its little propeller. I used the next older version (CHANGELOG entry 130328) and all was well again. my base kernel was 130520

[Brian Riley]

TNX ... I will give it a try in the morning

[Peter Jakacki]

Does anyone have any Tachyon code for reading the touchpads on a QuickStart board?

Thanks, in advance .... BBR

Hi Brian, did you try something as simple as PINS to check the state of the I/O pins. I found that this reports it's either open or else pulled-down when you touch it. Here's a simple word that checks to see if a pin is floating or loaded and you can increase the sensitivity by increasing the delay. Alternatively you can just lock the delay into the word either as a constant or as a variable. BTW, I hope to get back into Tachyon and some more enhancements as well as other things after being buried in work and life for so long.

pub TOUCH? ( level pin# -- flg )
    DUP PINSET DUP PININP SWAP us PIN@ NOT
    ;


\ demo usage (verbose)
#1,000 #P0 TOUCH? .

[Brian Riley]

Does anyone have any Tachyon code for reading the touchpads on a QuickStart board?

Thanks, in advance .... BBR

[MJB]

Thanks, I haven't found that in this long thread.
I also found nothing about intergrating assembler code in Tachyon forth.
Is it possible to integrate assembler instructions in Tachyon forth words like in propforth ?

Sven

it is different than in propforth.
The approach I took was:
- using peters PASM module mechanism to load small pieces of PASM code into the COG and the run it there, as he is doing this for various time critical modules (SPI etc.)

- adding my PASM code to the TACHYON source file and compiling with BST. Extracting the BINARY code and transferring into a byte array to be loaded later.

- it is even possible to extend the TACHYON image, that is loaded into the COG. but there is VERY little space for this - AND you really need to know what you do.

see the code for my contest entry - there has no winner been announced yet ...:
http://forums.parallax.com/showthrea...=1#post1147312

[sven98de]

Thanks, I haven't found that in this long thread.
I also found nothing about intergrating assembler code in Tachyon forth.
Is it possible to integrate assembler instructions in Tachyon forth words like in propforth ?

Sven

see: http://forums.parallax.com/showthrea...=1#post1145270

[MJB]

see: http://forums.parallax.com/showthrea...=1#post1145270

PETER wrote:
I didn't forget to forget, I just didn't forget. Got it?

Because of the way I create vector table entries with each new code entry I just haven't bothered to implement a word that is in my opinion unnecessary. If the code I have loaded is only sitting in RAM then I just hit a ^C or some other reset it so that I can reload again, it only takes a couple of seconds. Alternatively since Tachyon generates very compact code I just load new code over the top of the old.

In the event that I have done a BACKUP then that's different and at present I just load all the modules back in again. Even though this process only takes a few seconds I am looking at ways to lock the modules so that I only need to load the latest module. But once again I don't feel a pressing need to implement a FORGET which proved useful when you had to load from slow floppies and memory was limited as well.

[sven98de]

Hi,
does a "FORGET" word in Tachyon exist to remove words from the dictionary ?

Sven

[mindrobots]

CASE - it looks elegant, useable and readable....not sure we could ask for much more!

[Peter Jakacki]

I had another need for CASE structures and so I implemented one which turned out quite simple. Rather than the conventional way of handling it (whichever way that is) I simplified the way it operates. Essentially CASE just saves the parameter in the "case" variable and the =[ operator simply fetches this and compares it to the parameter then executes an IF. The matching code is terminated by a ]= which essentially executes an EXIT follow by a THEN. This is how it looks in practice:

pub Navigate ( ch -- )
    CASE
    "4" =[ speed @ PanLeft ]=
    "6" =[ speed @ PanRight ]=
    "8" =[ speed @ TiltUp ]=
    "2" =[ speed @ TiltDown ]=
    "9" =[ ZOOMIN ]=
    "3" =[ ZOOMOUT ]=
    "0" =[ SetCam master C~ ]=
    "." =[ StopCam ]=
    $0D =[ StopStop master C~ ]= 
    ;

To check for a range:

       "0" "9" ..[ case C@ EnterDigit ]=

Anything that doesn't match falls through the statements and you can process it however you like or not at all. To read the original parameter it is necessary to fetch the variable that it's stored in at "case".
So what do you think of this case structure?

On another note since this thread has gone over 632 posts I think that I will separate the hardware posts into individual posts labelled as Tachyon <hardware> and keep the software on this thread or perhaps start another.

[Peter Jakacki]

Hey that is neat Peter, BTW where can one find a winstar wh2004a lcd? No luck with my usual searches.

All your usual 20x4 LCDs use the same interface as the standard Hitachi HD44780 compatible controller (ancient) which handles up to 80 characters. The controller that WINSTAR are using is the ST7066 which has a few extra enhancements but I don't use them. The particular display that I am using just happens to be FSTN for higher contrast and transflective so it works well in really bright sunlight and the amber backlight complements that nicely.

[D.P]

I've updated the CHARLCD.fth file with a big digit mode plus a few other extras. The command codes are documented in the source code and as you may know the driver includes a lot of little extras such as tone generation, software controlled backlight brightness and contrast. The big digit mode is very handy for reading from a distance and allows up to 4 large digits on a 20x4.

The driver is meant to be used a standard output stream device so rather than call methods which although possible is not desired as you simply send through the stream of controls and characters. This means you could substitute an output device or access it as a remote serial display.

I use 8-bit parallel mode as standard but it can easily be adapted to 4-bit mode if you really want.

Attachment 100314

Hey that is neat Peter, BTW where can one find a winstar wh2004a lcd? No luck with my usual searches.

[Peter Jakacki]

I've updated the CHARLCD.fth file with a big digit mode plus a few other extras. The command codes are documented in the source code and as you may know the driver includes a lot of little extras such as tone generation, software controlled backlight brightness and contrast. The big digit mode is very handy for reading from a distance and allows up to 4 large digits on a 20x4.

The driver is meant to be used a standard output stream device so rather than call methods which although possible is not desired as you simply send through the stream of controls and characters. This means you could substitute an output device or access it as a remote serial display.

I use 8-bit parallel mode as standard but it can easily be adapted to 4-bit mode if you really want.

[Brian Riley]

TA DA !!!!!!!!!!!!!!!

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $6218...74C5 for 4781 (20572 bytes added) with 22700 bytes free
CODE:   $0000...2D47 for 6810 (1026 bytes added) with 21177 bytes free
CALLS:  0607 vectors free

AUTORUN BOOT
MODULES LOADED:
2945: DECOMPILER.fth      Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130316.1600
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
   I2CSTOP $0100 0
   DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0=
      IF  CR
         IF
            ." Fast"
            ELSE
            ." Slow"
         THEN
         ."  Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8
         FOR 0 SI2C@ .BYTE <>
            NEXT 1 SI2C@ I2CSTOP
      THEN DROP 2 +LOOP I2CSTOP
   ;
( =0090 bytes )  ok

[Peter Jakacki]

One HEXDUMP comin' right up!

I added a HEXLOAD to EXTEND.fth which loads directly into EEPROM if the destination address is not RAM (>$7FFF). So I loaded your hex file into $8000 and then did the equivalent of a restore except I kept my first 64 bytes intact for my clock settings. Anyhow, the decompiler did exactly what it did with you and I tracked this back to the fact that you were using the dropbox version of Tachyon which is never as up-to-date as the Google docs version. So just in case I updated the dropbox version as it was missing the name header for (.") which caused the decompiler to get confused.

[D.P]

One HEXDUMP comin' right up!

Hey Brian I use OSX and minicom at 234000 without any issues, I'll try ZTerm later and let you know.

[Brian Riley]

One HEXDUMP comin' right up!

[Peter Jakacki]

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $627E...74C9 for 4683 (20796 bytes added) with 22802 bytes free
CODE:   $0000...2C71 for 6694 (1032 bytes added) with 21391 bytes free
CALLS:  0618 vectors free

AUTORUN BOOT
MODULES LOADED:
2869: DECOMPILER.fth      Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
   I2CSTOP
   ." "
   ." "
   ." "
   ." " 5 us
   ." "
   ." =" =
   ." "
   ." ast"
   ELSE
   ." ow"
 THEN
 ." evice at "
 ." }" ?DUP I2CSTART
 ." "
 ." "  .BYTE <>
 NEXT 1 SI2C@ I2CSTOP
 ." " I2CSTOP
 ;
( =0090 bytes )  ok

That is the weirdest. I just tried a full build and it's all okay on this end. Any chance of the hex dump?

[Brian Riley]

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $627E...74C9 for 4683 (20796 bytes added) with 22802 bytes free
CODE:   $0000...2C71 for 6694 (1032 bytes added) with 21391 bytes free
CALLS:  0618 vectors free

AUTORUN BOOT
MODULES LOADED:
2869: DECOMPILER.fth      Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
   I2CSTOP
   ." "
   ." "
   ." "
   ." " 5 us
   ." "
   ." =" =
   ." "
   ." ast"
   ELSE
   ." ow"
 THEN
 ." evice at "
 ." }" ?DUP I2CSTART
 ." "
 ." "  .BYTE <>
 NEXT 1 SI2C@ I2CSTOP
 ." " I2CSTOP
 ;
( =0090 bytes )  ok

[Peter Jakacki]

I tried this on a fresh build ... i.e. latest kernal and EXTEND ... running Zterm on a quad core Mac at 115200. ZTerm has never had a problem keeping up at 115200. Is there a problem ... or. more likely, where have I gone wrong?

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $59AC...74C9 for 6941 (17908 bytes added) with 20544 bytes free
CODE:   $0000...361B for 6910 (2048 bytes added) with 18917 bytes free
CALLS:  0373 vectors free

AUTORUN BOOT
MODULES LOADED:
2E1B: RGB8X8.fth          8x8 RGB LED Matrix Tool Kit - 20130310.1900
2C71: EXT_BBR.fth         redirects for RFID/LCD/RGB/EMIC, UFO, et al. - 20130310.16000
2869: DECOMPILER.fth      Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
   I2CSTOP $0100
   ." "
   ." "
   ." " 5 us
   ." "
   ." =" =
   IF    +!
      ." "
      ELSE
      ." ow"
   THEN  +
   ." vice at "
   ." }" ?DUP I2CSTART I
   ." "
   ." "  .BYTE <>
   NEXT 1 SI2C@ I2CSTOP
 ." " I2CSTOP
 ;
( =0090 bytes )  ok

It's a mystery, can you do a "0 8000 IDUMP" and email me so I can check it out? Maybe if you just do a COLD and then load EXTEND.fth and then the decompiler and try it out without any of the other stuff first perhaps.

[Brian Riley]

The decompiler is mainly used for debugging and is also handy when you don't have the source code in front of you.
<Get it here>

As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.

P.S. I can see a little bug in this output, see if you can pick it and why.

I tried this on a fresh build ... i.e. latest kernal and EXTEND ... running Zterm on a quad core Mac at 115200. ZTerm has never had a problem keeping up at 115200. Is there a problem ... or. more likely, where have I gone wrong?

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $59AC...74C9 for 6941 (17908 bytes added) with 20544 bytes free
CODE:   $0000...361B for 6910 (2048 bytes added) with 18917 bytes free
CALLS:  0373 vectors free

AUTORUN BOOT
MODULES LOADED:
2E1B: RGB8X8.fth          8x8 RGB LED Matrix Tool Kit - 20130310.1900
2C71: EXT_BBR.fth         redirects for RFID/LCD/RGB/EMIC, UFO, et al. - 20130310.16000
2869: DECOMPILER.fth      Tachyon Forth decompiler V1.0 130312.1620
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
DECOMP I2CBUS
: I2CBUS
   I2CSTOP $0100
   ." "
   ." "
   ." " 5 us
   ." "
   ." =" =
   IF    +!
      ." "
      ELSE
      ." ow"
   THEN  +
   ." vice at "
   ." }" ?DUP I2CSTART I
   ." "
   ." "  .BYTE <>
   NEXT 1 SI2C@ I2CSTOP
 ." " I2CSTOP
 ;
( =0090 bytes )  ok

[D.P]

The decompiler is mainly used for debugging and is also handy when you don't have the source code in front of you.
<Get it here>

As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.

DECOMP I2CBUS
: I2CBUS
   I2CSTOP $0100 0 
   DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0= 
      IF  CR 
         IF  
            ." Fast" 
            ELSE  
            ." Slow" 
         THEN 
         ."  Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8 
         FOR 0 SI2C@ .BYTE <> 
            NEXT 1 SI2C@ I2CSTOP 
      THEN DROP 2 +LOOP I2CSTOP 
   ;
( =0090 bytes )  ok

P.S. I can see a little bug in this output, see if you can pick it and why.

Okay after a refresh and rebuild all works as advertised. Seems there is that extra space floating in the mix, haven't looked at the source to see where it may originate from though.

[Peter Jakacki]

The decompiler is mainly used for debugging and is also handy when you don't have the source code in front of you.
<Get it here>

As well as the SEE and SEEALL words which effectively list the address and code there is the DECOMP word which attempts to put it back into source code form so that in most cases you can decompile the code and simply copy, edit, and paste the modified version. Looking at the example below I copied the decompiler output and pasted it back in again and it worked perfectly.

DECOMP I2CBUS
: I2CBUS
   I2CSTOP $0100 0 
   DO I2CSTART I I2C!? 0= I2CSTART 5 us I SI2C!? 0= 
      IF  CR 
         IF  
            ." Fast" 
            ELSE  
            ." Slow" 
         THEN 
         ."  Device at " I .WORD 2 SPACES I2CSTART I 1+ SI2C! 8 
         FOR 0 SI2C@ .BYTE <> 
            NEXT 1 SI2C@ I2CSTOP 
      THEN DROP 2 +LOOP I2CSTOP 
   ;
( =0090 bytes )  ok

P.S. I can see a little bug in this output, see if you can pick it and why.

[Peter Jakacki]

I get this using minicom on my mac with ANSI terminal emulation?

  Propeller .:.:--TACHYON--:.:. Forth V21130216.1200

NAMES:  $6322...74C3 for 4513 (20978 bytes added) with 22966 bytes free
CODE:   $0000...2AD2 for 6449 (0593 bytes added) with 21806 bytes free
CALLS:  0634 vectors free

AUTORUN BOOT
MODULES LOADED: 
2881: SEE.fth             Tachyon Forth decompiler V1.0 130311.1000 
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430 

SEE I2C! ..x:                                                                  
22C7:  $18                                                                     
22C9:  ." "                                                                    
22CC:  ." x"                                                                   
22D1:  ." "                                                                    
22D5:  NEXT                                                                    
22D6:                                                                                    P
22D7:                                                                                    S
22D8:                                                                                    "
22DB:                                                                                    T
=0020 bytes   ok

Try refreshing the source code page as there have been quite a number of changes to it since, same goes for the kernel and extensions too. There's also a SEEALL word that does a two pass decompilation so that it can reveal the BEGIN structures and correct indentation etc.

[D.P]

EDIT: The problem is that they are immediate words as Tachyon compiles on the fly rather than waiting until the end of line. Try this:

: my [COMPILE] MY ;
IMMEDIATE

Hey I thought that goes without saying (that it works with QWORDS too).......

BTW, I have been working on a decompiler and it only took a few hours and I came up with this simple one. Try it.

SEE I2C!
22BB:  $18
22BD:  REV
22BE:  SDA
22C0:  DUP
22C1:  OUTSET
22C2:  SWAP
22C3:  8
22C4:  FOR
22C5:    SHROUT
22C6:    CLOCK
22C7:    NOP
22C8:    CLOCK
22C9:    NEXT
22CA:  DROP
22CB:  INPUTS
22CC:  CLOCK
22CD:  NOP
22CE:  CLOCK
22CF:  EXIT  ok

I get this using minicom on my mac with ANSI terminal emulation?

  Propeller .:.:--TACHYON--:.:. Forth V21130216.1200

NAMES:  $6322...74C3 for 4513 (20978 bytes added) with 22966 bytes free
CODE:   $0000...2AD2 for 6449 (0593 bytes added) with 21806 bytes free
CALLS:  0634 vectors free

AUTORUN BOOT
MODULES LOADED: 
2881: SEE.fth             Tachyon Forth decompiler V1.0 130311.1000 
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430 

SEE I2C! ..x:                                                                  
22C7:  $18                                                                     
22C9:  ." "                                                                    
22CC:  ." x"                                                                   
22D1:  ." "                                                                    
22D5:  NEXT                                                                    
22D6:                                                                                    P
22D7:                                                                                    S
22D8:                                                                                    "
22DB:                                                                                    T
=0020 bytes   ok

[Peter Jakacki]

I upload, after EXTEND a list of shortcut (mostky common commands aliased in lower case, like

: my MY ;

BUT ... when I tried to do it for word MATCH the system locked up hard

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $6387...74C9 for 4418 (22846 bytes added) with 23067 bytes free
CODE:   $0000...2869 for 5927 (4137 bytes added) with 22423 bytes free
CALLS:  0645 vectors free

AUTORUN BOOT
MODULES LOADED:
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
:        match   MATCH   ;

The problem is QUITE REPEATABLE ... what's going on????

EDIT: The problem is that they are immediate words as Tachyon compiles on the fly rather than waiting until the end of line. Try this:

: my [COMPILE] MY ;
IMMEDIATE

Hey I thought that goes without saying (that it works with QWORDS too).......

BTW, I have been working on a decompiler and it only took a few hours and I came up with this simple one. Try it.

SEE I2C!
22BB:  $18
22BD:  REV
22BE:  SDA
22C0:  DUP
22C1:  OUTSET
22C2:  SWAP
22C3:  8
22C4:  FOR
22C5:    SHROUT
22C6:    CLOCK
22C7:    NOP
22C8:    CLOCK
22C9:    NEXT
22CA:  DROP
22CB:  INPUTS
22CC:  CLOCK
22CD:  NOP
22CE:  CLOCK
22CF:  EXIT  ok

[Brian Riley]

As part of my plan to introduce more flexibility in listing the Forth words I have just added a simple filter that list only those words whose leading characters match the string given. This also works for QWORDS and you can use it as shown. Next step is to introduce wildcard matching.

MATCH SD WORDS

I upload, after EXTEND a list of shortcut (mostky common commands aliased in lower case, like

: my MY ;

BUT ... when I tried to do it for word MATCH the system locked up hard

  Propeller .:.:--TACHYON--:.:. Forth V21130224.1600

NAMES:  $6387...74C9 for 4418 (22846 bytes added) with 23067 bytes free
CODE:   $0000...2869 for 5927 (4137 bytes added) with 22423 bytes free
CALLS:  0645 vectors free

AUTORUN BOOT
MODULES LOADED:
1840: EXTEND.fth          Primary extensions to TACHYON kernel - 130303.1430
----------------------------------------------------------------
:        match   MATCH   ;

The problem is QUITE REPEATABLE ... what's going on????

[Brian Riley]

Also added a simple wildcard that matches on any single character which is useful to find all words for instance that might have to do with adding:
ANY + WORDS
NFA PFA EXT ATRS NAME
-----------------------
6842 1B40 Y43 ...: C++
...
7065 19BB ...: 2+
7475 1218 X9F ...: +CALL ok

You didn't mention it, but it also works wIth QWORDS ... neat! THANK YOU!

ANY ! QWORDS
EE! SI2C! SI2C!? I2C! I2C!? TIME!
DAC! CTR! LBIT!
ATN! ENQ! @CNT! COGREG! U!
EE! SI2C! SI2C!? I2C! I2C!? PWM! TIME! DAC!
CTR! LBIT! ATN! ENQ!
@CNT! COGREG! U!
C+! C! W+! W! +! ! BIT! IC! OUT! P! COG!
SPR! [PWM!] !SP PIN!
AUTO!  ok

[Peter Jakacki]

Also added a simple wildcard that matches on any single character which is useful to find all words for instance that might have to do with adding:
ANY + WORDS
NFA PFA EXT ATRS NAME
-----------------------
6842 1B40 Y43 ...: C++
6850 1B38 Y41 ...: W++
685D 1B30 Y3F ...: ++
6B15 0024 ...$ 1+
6B21 0020 ...$ +
6B40 00D8 ...$ +LOOP
6BFB 0059 ...$ C+!
6C08 0065 ...$ C@++
6C10 005D ...$ W+!
6C1D 0061 ...$ +!
7065 19BB ...: 2+
7475 1218 X9F ...: +CALL ok

[Peter Jakacki]

As part of my plan to introduce more flexibility in listing the Forth words I have just added a simple filter that list only those words whose leading characters match the string given. This also works for QWORDS and you can use it as shown. Next step is to introduce wildcard matching.

MATCH SD WORDS
NFA PFA EXT ATRS NAME
-----------------------
6146 2DA0 YDC ...: SDPOLL
6150 2D74 XDC ...: SD
615F 2CCD XDB ...: SDWR
6167 2CB0 YDA ...: SDRD
6180 2C8F YD9 ...: SDRDBLK
620C 2A8E XD2 ...: SDDAT!
6216 2A71 YD1 ...: SDERR?
6254 29F0 XCE ...: SDBUSY
6267 29E4 XCD ...: SDCLK
627B 29CB XCC ...: SD4@
6283 29C3 YCB ...: SD2@
628B 29BC XCB ...: SD!
6292 29B5 YCA ...: SD@
62AA 2992 XC9 ...: SDSEL
62B3 2988 YC8 ...: SDPINS
62D4 296B YC6 ...: SDCS
62DC 2940 XC6 ...: SDMASKS
63A0 281B YBB ...: SDBUF
63B3 27F1 YBA ...: SDCARD.fth
6585 21EB Y97 ...: SDA ok
MATCH [ WORDS
NFA PFA EXT ATRS NAME
-----------------------
6A64 1889 Y02 ...: [~
6FFF 0BC8 X3B ...: [SSD]
7008 0B78 X3C ...: [ESPIO]
7013 0BF8 X3D ...: [SPIO]
701D 0C30 X3E ...: [SPIOD]
7028 0C6C X3F ...: [SDRD]
7032 0CA4 X40 ...: [SDWR]
703C 0CE0 X41 ...: [PWM]
7045 0D14 X42 ...: [PWM!]
704F 0D40 X43 ...: [PLOT]
73F2 13D1 X9C .I.: [COMPILE] ok

[KC_Rob]

Thanks for all your help and feedback, Peter.

Right now I'm especially relieved to know the LCD problems are resolved. I was at a loss trying to figure out what, exactly, I could be doing wrong.

[Peter Jakacki]

Thank you for taking a look at this. I'll give the changes a try tomorrow.

Now that it is working, I would say yes. (And that is more or less what I had in mind anyway: a single word that would take a string and direct it to some specified output - in this case LCDCHAR.)

Okay, here is the situation. Right now it appears that I have two CHARLCD.fth modules stored, two versions. Probably this shouldn't be the case (I guess I did a BACKUP when I shouldn't have). Nor is it that big a deal, other than the clutter I get when I do QWORDS or MODULES. There's always the option, too, of wiping everything and starting over. Still, I couldn't help but wonder if there is a way to delete a word or module that has already been saved without having to go that route.

Well I only feel the pain when I have backed up the module too It means that I need to type in COLD and reload EXTEND.fth and any other modules required. Bear in mind however that if you have a 64K EEPROM that you can RESTORE to back before the previous BACKUP. Maybe I will do something that at least makes loading in an edited module easier so that it forgets the previous module automatically when you load in the new one. The module is identified by the ".fth" suffix so this could trigger an automatic module search and replace.

FORGET'ing words in Tachyon involves reclamation of the vectors and header space as well as the code space but it mightn't be so messy any more like it seemed to be in the beginning.

BTW, you are always free to define your own specialized handlers for such things as sending strings directly to the LCDCHAR word but another of the advantages of keeping it as a single entry point (via EMIT) is that the display can be accessed over serial links as in the example at the end of the code document. So you can create your own custom serial LCD displays.

In this regard I could add many more functions to the LCD which I have done for my MultiLCD product (OEM) which emulates various industry standard serial LCDs as well as adds key matrix encoding, PS/2 keyboard interface, audio out, piezo transducer for tones, and SD card as well as RS485 etc.

[KC_Rob]

Seems that there was a bug or two in this code...

Thank you for taking a look at this. I'll give the changes a try tomorrow.

Isn't it easy to type in: LCD ." Number 5 is alive, need input" rather than having duplicated methods for each device?

Now that it is working, I would say yes. (And that is more or less what I had in mind anyway: a single word that would take a string and direct it to some specified output - in this case LCDCHAR.)

FORGET FORGET

Okay, here is the situation. Right now it appears that I have two CHARLCD.fth modules stored, two versions. Probably this shouldn't be the case (I guess I did a BACKUP when I shouldn't have). Nor is it that big a deal, other than the clutter I get when I do QWORDS or MODULES. There's always the option, too, of wiping everything and starting over. Still, I couldn't help but wonder if there is a way to delete a word or module that has already been saved without having to go that route.

[Peter Jakacki]

Peter:

I've been playing with CHARLCD.fth and discovered that WriteLCD works correctly only when #dbus starts at P0. That there is a definition for this suggests, to me anyway, that it was meant to work more generally. I got around the limitation for the time being by multiplying the stack data by 256 prior to OUTSET (my dbus is wired starting at P8).

Another thing: for some reason, when I redirect EMIT on my setup (ie, > LCD ." MultiLCD V1.0 ") I get a few garbage characters on the LCD and TACHYON goes out to lunch, like it's stuck in a loop calling LCDEMIT. I'm sure something is wrong on my end, but right now I have no idea what (still looking into it).

How hard would it be to create a simple word that can output a string to the LCD by calling LCDCHAR directly?

Finally, are there any built-in words for cleaning the dictionary (like, eg, "FORGET")?

I'm sorry for all the questions, and especially sorry if I've overlooked something obvious. Please keep in mind that I'm something of a Forth neophyte.

Thanks once more for all your good efforts. I've played with Forths for several micros (eg, AMFORTH), and TACHYON has been the easiest to get into and most productive thus far. I can actually see where you might do real work with it. Fun stuff too!

Seems that there was a bug or two in this code. First off the WriteLCD word was not aligning the data to the correct bit position if the default data pins were not used. All this basically required was a SHL operation but it also meant a few little changes to the code to better support user pins so now there is the LCDPINS word plus tips on changing any other pins easily.

Second, there was a bug in the control code vector table as LOOKUP assumes that all vectors are 2 bytecodes long however I had a NOP for the null vector which is a single VM kernel bytecode and so this would have caused havoc, hence the out to lunch thing. Simply putting in two NOPs or another dummy definition is all that was required.

The reason that I don't create special words for LCD to output strings directly to it is because I find it so clunky for every I/O device to have named methods when there is no need to, hence the redirection words. This means that any output formatting capability that Tachyon has can been used to output to the LCD. Isn't it easy to type in: LCD ." Number 5 is alive, need input" rather than having duplicated methods for each device?

FORGET FORGET
I have been asked a few times about a FORGET word but as I pointed out at the time it doesn't matter if you load edited definitions when the old ones are still there. Since I use an editor or Google docs it's simply a matter of typing a ^C (or equivalent) to wipe out the stuff I've been playing with and then copy and paste. It's very quick that way, only takes seconds and there is no confusion. In the case of CHARLCD.fth it takes 3 seconds and I'm sure typing in FORGET CHARLCD.fth would probably take that long anyway. There's also some technical under the hood reasons why I don't bother with a FORGET and taking into consideration that while not having it does not impact anything or on productivity I therefore choose to forget FORGET.

[KC_Rob]

Peter:

I've been playing with CHARLCD.fth and discovered that WriteLCD works correctly only when #dbus starts at P0. That there is a definition for this suggests, to me anyway, that it was meant to work more generally. I got around the limitation for the time being by multiplying the stack data by 256 prior to OUTSET (my dbus is wired starting at P8).

Another thing: for some reason, when I redirect EMIT on my setup (ie, > LCD ." MultiLCD V1.0 ") I get a few garbage characters on the LCD and TACHYON goes out to lunch, like it's stuck in a loop calling LCDEMIT. I'm sure something is wrong on my end, but right now I have no idea what (still looking into it).

How hard would it be to create a simple word that can output a string to the LCD by calling LCDCHAR directly?

Finally, are there any built-in words for cleaning the dictionary (like, eg, "FORGET")?

I'm sorry for all the questions, and especially sorry if I've overlooked something obvious. Please keep in mind that I'm something of a Forth neophyte.

Thanks once more for all your good efforts. I've played with Forths for several micros (eg, AMFORTH), and TACHYON has been the easiest to get into and most productive thus far. I can actually see where you might do real work with it. Fun stuff too!

[MJB]

what is the difference between (from TACHYON Kernel - STRLEN ' ( str -- len ))

byte    DUP,CFETCHINC,DEC,_BYTE,$7E,SWAP,XCALL,xULT

and

byte    DUP,CFETCHINC,_BYTE,$7F,SWAP,XCALL,xULT

i.o.w. why is the first used and not the second ??

Do I miss s.th. important?

EDIT: yes I did miss s.th. ...
this is a combined check for the 2 end of string conditions
either 0-terminated or 8-th bit terminated
if the char == 0 then DEC makes $FFFFFFFF so the loop terminates -> end found
if the char is not 0 then we compare the decremented char code with the $7E instead of $7F to check for the 8th bit. - pulling my hat Peter

if I still miss s.th. ... please correct ...
MJB

[Peter Jakacki]

EXTEND.fth does have lots of little things added to it bit by bit and the changelog should reflect this. When I added MYWORDS I then changed it again so that MY set a termination pattern. Now I have just added assembler style words for variables which use an origin and specify the number of bytes per "variable". The variable is actually compiled as a constant so that the variable memory area is purely data without any bytecodes so it can be erased or copied etc. WORDS will gradually be enhanced to permit searching based on character match parameters and also attributes.

{ Create fixed variables by borrowing from assembler syntax using an origin and specify number of bytes for each variable
This allows us to work from a fixed area in RAM and the variables end up being defined as constants.
Usage: 
	$4000 ORG
	2	DS readptr		\ allocates 2 bytes for readptr at $4000
	2	DS writeptr		\ allocates 2 bytes for writeptr at $4002
	#64	DS mybuffer		\ allocates 64 bytes for mybuffer at $4004

or
	TABLE myvars #64 6 * ALLOT	\ allocate long aligned memory for 6 sets of 64 bytes
	myvars ORG				\ work from the start of the table
	#12	DS name
	4	DS offset
	\ etc

and when we check this...
myvars . 2E30 ok
offset . 2E3C ok
} 

[Brian Riley]

MY WORDS and MY QWORDS

typo in the doc

THE MY PREFIX WORKS FOR WORDS AS WELL AS QWORDS .. NEAT! (and already very handy in the 5 minutes since I read your reply. TNX and THANK YOU, Peter!)

[D.P]

EXTEND.fth (130216) states

CHANGELOG:
130216	- Added MYWORDS which lists new words to start of current module (i.e. *.fth)
		- added == symbol as an alias to CONSTANT but == may later on become compile time constants only
130113	- Enhanced the PINS? word to determine if a pin is pulled up or down by some sort of resistor or load

BUT, no MYWORDS to be found! Gets nothing but "???". I did a QWORDS and ctrl-F-ed my way through it ... NADA!!!!

MY WORDS and MY QWORDS

typo in the doc

[Brian Riley]

EXTEND.fth (130216) states

CHANGELOG:
130216	- Added MYWORDS which lists new words to start of current module (i.e. *.fth)
		- added == symbol as an alias to CONSTANT but == may later on become compile time constants only
130113	- Enhanced the PINS? word to determine if a pin is pulled up or down by some sort of resistor or load

BUT, no MYWORDS to be found! Gets nothing but "???". I did a QWORDS and ctrl-F-ed my way through it ... NADA!!!!

[D.P]

So far this is only a basic setup and there are other functions to add for sure but I didn't want to unduly complicate it more than necessary at the present. I will implement some more streamline methods after I have weighed up some ways of handling this. As for wTXSTR you could remove the SEND operation at the end of it so that you could just concatenate strings until you were ready to send. In fact I have just modified this so that the SEND is moved to the wEMIT word. As for adding control characters to the TX string I would really just switch the EMIT output to wEMIT and use normal print strings and characters rather than directly creating string.
TERM $0C EMIT ." HELLO" 9 EMIT ." THERE" CR CON

This is my first attempt learning and using FORTH. It has been/is a real challenge/effort having only procedural language experience/bias. Funny the people I help at the maker space that have 0 experience are not afraid/intimidated to type into the Tachyon "window" and start building words, running tasks, doing things. I show them the equivalent arduino sketch and the glaze appears again.

I'm building my TCP/IP dictionary for the gadgets I command, and now I see why.

: tw  wTXSTR SEND $0A wTX SEND ;

" Thanks Peter" tw

[Peter Jakacki]

RE Spinneret, how do we embed control characters into strings with wTXSTR?

Also these two words are needed to set the destination IP and PORT when in "client" mode?

pub dPORT ( dstport -- )         sDPORT WIZ2! ; \ set the destination port 
pub dIP   ( dstip -- )           sDIP WIZ4! ; \  set the destination ip

So far this is only a basic setup and there are other functions to add for sure but I didn't want to unduly complicate it more than necessary at the present. I will implement some more streamline methods after I have weighed up some ways of handling this. As for wTXSTR you could remove the SEND operation at the end of it so that you could just concatenate strings until you were ready to send. In fact I have just modified this so that the SEND is moved to the wEMIT word. As for adding control characters to the TX string I would really just switch the EMIT output to wEMIT and use normal print strings and characters rather than directly creating string.
TERM $0C EMIT ." HELLO" 9 EMIT ." THERE" CR CON

[D.P]

RE Spinneret, how do we embed control characters into strings with wTXSTR?

Also these two words are needed to set the destination IP and PORT when in "client" mode?

pub dPORT ( dstport -- )         sDPORT WIZ2! ; \ set the destination port 
pub dIP   ( dstip -- )           sDIP WIZ4! ; \  set the destination ip

[D.P]

I can't seem to connect to the spinneret after using either of the last two kernels, latest being 21_130216,1200. I've tried with 115_000 and 230_400 baud, standard rates I use with success (yes I did remember to modify the baudrate and clock settings in the default tachyon code). Minicom seems to connect but no IO? The spinneret is powered with +5v and using a parallax prop plug. TACHYON is constantly restarting and sending it's banner correcty to minicom?

I usually do all my TACHYON work with PBOE or a PPDB.




Propeller .:.:--TACHYON--:.:. Forth V21130216.1200
Cold start - no user code - setting defaults
----------------------------------------------------------------


UPDATE: Got it to connect once, don't know how, but can't repeat, no - consistency?

UPDATE2: OSX 10.8.2 damage, everything works peachy under my Win7 VM on this machine, drat.

UPDATE3: My OSX setup works correctly with the PBOE and PPDB, something about the prop plug, even though programs download correctly, fast, minicom doesn't work correctly. TeraTerm pass through from the VM to the physical port on the Mac is not usable to "build" the extensions.

UPDATE4: My trusty 1 gen MacBook Pro with the matte screen was truely worth replacing the HD with a SSD.
Everything works perfectly here in 10.6.8.

_Really neat stuff here Peter.

This word is helping me debug my stuff

: SS CR 
." MODE  : " sMODE WIZ@ . CR
." CMD   : " sCMD WIZ@ . CR
." INTS  : " sINTS WIZ@ . CR
." STAT  : " sSTAT WIZ@ . CR
." PORT  : " sPORT WIZ@ . CR
." DHAR  : " sDHAR WIZ@ . CR
." DIP   : " sDIP WIZ@ . CR
." DPORT : " sDPORT WIZ@ . CR
." SSIZE : " sSSIZE WIZ@ . CR
." PRO   : " sPRO WIZ@ . CR 
." TXFREE  : " TXFREE@ WIZ@ . CR
." TXREAD  : " TXREAD WIZ@ . CR
." TXWRITE : " TXWRITE WIZ@ . CR
." RXSIZE@ : " RXSIZE@ WIZ@ . CR
." RXREAD  : " RXREAD WIZ@ . CR ;

[KC_Rob]

I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?

The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.

Great! Now I have something worthwhile to do with that Spinneret I purchased during a sale not long ago (I didn't need it but couldn't resist the temptation). I too am astounded at how easy all this looks. Scary? Perhaps. Certainly impressive!

Forth support on the Propeller, in particular TACHYON, really stands out in my view. Anyone wanting to learn Forth or do work with Forth in an embedded environment would be remiss in overlooking the Propeller. Please keep up the fantastic work, Peter!

[D.P]

I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?

The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.

Having coded large "socket" based applications in everything from Ada to C it's scarry to see how simple the layout for sockets can be in Forth/Tachyon.

Thanks for removing so much accidental complexity, the WIZ820io w5200 based module is not put away just moved to make room for the spinneret. The socket code is straight forward, I was referring to how to modify the driver, I'm not ready for this in Tachyon/Forth yet.

[mindrobots]

Time to dust off my Spinneret!! This should be fun to play with!!

[Peter Jakacki]

The W5200 is significantly different to the W5100 register layout which is not un-expected of course. Time to put away the 5200 module and breakout my spinneret, this forth is a little above my comfort level to mess with until I have more experience, nice work Peter.

I've tried to keep it fairly simple even down to the IP notation as well so a lot of things should be self-explanatory (I hope). It's so easy just to type in a socket, protocol, port, and tell it to open and to listen. Actually it's too easy, maybe I better obfuscate it and grow the code 10 fold?

The Spinneret is just handy to use at the moment but I have the W5200 ready to go so don't go packing it away.

[D.P]

The W5200 is significantly different to the W5100 register layout which is not un-expected of course. Time to put away the 5200 module and breakout my spinneret, this forth is a little above my comfort level to mess with until I have more experience, nice work Peter.

[Peter Jakacki]

I've been doing bits and pieces on the Spinneret and playing with Telnet sessions. Now you can Telnet into the Forth console and interactively write programs over the internet. When I get some time later on today I will tidy up the code a little and lock it in then allow anyone who likes to Telnet in to my Spinneret running Tachyon. The WIZnet code and driver runs out of the same cog as the Tachyon console and consumes less than 1K of code at present. Next step after tidying the Telnet is to add FTP.


BTW, here's a quick session:

peter@peter-XPS-L702X-Mint14 ~ $ telnet 192.168.0.80
Trying 192.168.0.80...
Connected to 192.168.0.80.
Escape character is '^]'.
.VER
.VER 
  Propeller .:.:--TACHYON--:.:. Forth V21130216.1200
 ok
MY QWORDS
MY QWORDS 
S LW WDUMP TELNET TERM wKEY (wKEY) wEMIT wTXSTR wTX PPPoE MACRAW IPRAW UDP TCP 
CLOSED PORT SOCK_ARP2 SOCK_ARP1 SOCK_ARP SOCK_LAST_ACK SOCK_TIME_WAIT SOCK_CLOSING SOCK_FIN_WAIT 
SOCK_SYNRECV SOCK_SYNSENT SOCK_PPOE SOCK_MACRAW SOCK_IPRAW SOCK_UDP SOCK_CLOSE_WAIT SOCK_ESTABLISHED 
SOCK_LISTEN SOCK_INIT SOCK_CLOSED =CON =DISCON =RECV =TIMEOUT =SENDOK RECV SENDKEEP SENDMAC SEND 
CLOSE DISCON CONNECT LISTEN OPEN RXREAD RXSIZE@ TXWRITE TXREAD TXFREE@ sPRO sSSIZE sDPORT 
sDIP sDHAR sPORT sSTAT sINTS sCMD sMODE SOCKET @SOCKET UPORT UIP TXSIZ RXSIZ RETRYS 
RETRYTIME INTMASK INTS@ SRCIP SHAR SUBNET GATEWAY wMODE WIZ2@ WIZ2! WIZ4! !WIZIO WIZ@ WIZ! 
=WRD =WWR WSEL WRST WCK WCE WDI WDO 
 ok

  ok

[fidolo]

Spot on. I don't think pairing the Propeller up with ARM chips, much less ARM modules/SBCs, is really the best way to extend the Propeller's capabilities (vice versa, on the other hand,... perhaps). It might be fun or interesting to do, but I'm less certain that there is much practical application and far less certain that it helps market the Propeller chip itself.

I concur. I recently learned a good bit about the Propeller chip, because I have long been familiar with the ways of Forth, and Tachyon made the Propeller chip approachable to me (the same would probably have happened if by accident I had stumbled upon PropForth first). This chip is in a class by itself (until it becomes outclassed by its big brother P2). This hardware architecture can break all kinds of sound barriers in situations where fast execution and multitasking environment rank high in the priority chain.

I would start to explore experimental ways of networking several propellers using Tachyon as a development strategy because of its superb ability to get things debugged, particulalrly flexible and open-ended things such as networking protocols. This is bound to lead to the discovery of good protocols (robustness, high speed, extensibility, etc..). When it does, these protocols may become worthy of porting to other hardware platforms using other software tools and methodologies, not because they were created in a propeller-specific Forth dialect, but because they have practical merit, so everyone will benefit. This could for instance benefit both the propeller and the RPi platforms, because the pairing between them would provide bridging between wide scope protocols such as TCP and UDP (over IP) and narrow scope protocols such as what I am dreaming aloud about, first propeller-to-propeller using Tachyon for its development advantages, and later on, if something of real value comes of it, more options and possibilities for everyone, within every development paradigm.

May they multiply and prosper, all of them!

[Loopy Byteloose]

Ah ha... Tachyon is back to shaking up the Propeller Forth world. I am looking forward to Forth on the Propeller 2.

In the meantime, I am rather mired in ArrayForth, a sub-set of ColorForth for the GA144 these days. It is all very weird, one has to use the right colors to program. I prefer mono-chrome Forth, but this is all from the workshop of Chuck Moore himself. So I try to learn it anyway.

[Peter Jakacki]

What a nice treat for the long winter rainy nights in the PNW (pacific north west for non-locals), got a Prop BOE with a wiz5200 module all wired up and ready, thx Peter.

Well then, if you or anyone else would like to collaborate on the project then you are quite welcome to. Just go to https://docs.google.com/document/d/1...HCPmPn-0/edit# and apply for permission to edit.

I've just added IP notation to the kernel so that I can just enter addresses like 192.168.0.50 using a simple & prefix like this &192.168.0.50 so that the number is forced to decimal bytes with each dot packing the decimal digits up into an IP address correctly.

[D.P]

What a nice treat for the long winter rainy nights in the PNW (pacific north west for non-locals), got a Prop BOE with a wiz5200 module all wired up and ready, thx Peter.

[Peter Jakacki]

Tachyon is great, it supports (you) serial, spi, i2c, bluetooth etc, but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.

http://shop.wiznettechnology.com/Sub...id=48&pid=1161

This module is well tested with a couple of prop 1 driver sets here's one:
http://obex.parallax.com/objects/869/

Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.

Just for your interest I started playing with the W5100 on the Spinneret with the aim of using the W5200 but I'm writing the code totally clean in that I'm not referring to any existing code. Sometimes it helps to follow existing code but it can also lead you down a cramped path so I am just having fun interactively exploring the WIZnet registers and functions at present to see what I can do and get away with as well.

In typical Tachyon fashion I have a Google document and corresponding webpage document that can be viewed by anyone if you like to follow along. The document is both the source code and the documentation. This at least for the present gives you the low-level primitives to start working with while the functions are built up to what I need at least.

[KC_Rob]

I don't know if the potential market is big enough to excite Parallax, but the RasPi is hot right now so I hope it's been considered. I don't know how the RapPi will fare in the long run. Some of the promises aren't quite there yet - e.g. Scratch doesn't run all that smoothly quite yet. And many people may move on to other low cost platforms if price is what attracted them.

Raspberry Pi certainly is hot right now (http://www.cnn.com/2012/12/21/tech/i...ton/index.html). You get so much for so little. I wouldn't be surprised if it is a strong, even dominant, player in the educational space for some time. Whether or not Parallax can piggyback on that success profitably is another question.

[KeithE]

e

The Prop can be paired with a PC or a tablet just as easily as it could be paired with a RPi. If P1 was all we had then as one of the many solutions we could link to the RPi, but we are really looking forward to and preparing for P2. The fact that Aduino is being paired with the RPi is not really a concern, I mean we're not thinking of using ATMegas either, are we? Really though, all the RPi projects are centered around the RPi, not Arduino or Prop etc which become nothing more than glorified peripheral chips extending the RPi's capabilities..

I just think that it's one possible way for Parallax to get some exposure. The RasPi is cheap and can go into places where you probably wouldn't put a laptop or tablet. There's some synergy in the educational market - I think that Parallax has some excellent educational materials. I don't know if the potential market is big enough to excite Parallax, but the RasPi is hot right now so I hope it's been considered. I don't know how the RapPi will fare in the long run. Some of the promises aren't quite there yet - e.g. Scratch doesn't run all that smoothly quite yet. And many people may move on to other low cost platforms if price is what attracted them.

[Peter Jakacki]

e

I see where you guys are coming from, but just keep in mind that the Arduino is being paired with the Raspberry Pi. I believe that the Raspian distribution includes the development tools, or they are just an apt-get away. There's already a shield called Alamode that mates with the Pi. I hope that Parallax at least discusses this internally, and takes a close look at the market. There's no shame in extending the Pi's capabilities.

The Prop can be paired with a PC or a tablet just as easily as it could be paired with a RPi. If P1 was all we had then as one of the many solutions we could link to the RPi, but we are really looking forward to and preparing for P2. The fact that Aduino is being paired with the RPi is not really a concern, I mean we're not thinking of using ATMegas either, are we? Really though, all the RPi projects are centered around the RPi, not Arduino or Prop etc which become nothing more than glorified peripheral chips extending the RPi's capabilities..

[KeithE]

Spot on. I don't think pairing the Propeller up with ARM chips, much less ARM modules/SBCs, is really the best way to extend the Propeller's capabilities (vice versa, on the other hand,... perhaps). It might be fun or interesting to do, but I'm less certain that there is much practical application and far less certain that it helps market the Propeller chip itself.

I see where you guys are coming from, but just keep in mind that the Arduino is being paired with the Raspberry Pi. I believe that the Raspian distribution includes the development tools, or they are just an apt-get away. There's already a shield called Alamode that mates with the Pi. I hope that Parallax at least discusses this internally, and takes a close look at the market. There's no shame in extending the Pi's capabilities.

[Peter Jakacki]

Hmmmmm, though a lot slower, FMFS, would apply to the EEPROM as well.

Yes Captain EEPROM, that's a LOT slower but FS for EEPROM is a lot simpler too as file sizes are small also but when compared to SPI Flash at the same price point the SPI Flash is at least 50 times faster with 50 times the memory. I will look at allowing various memories to be use with the FMFS however so it can be scaled according to the hardware resources and all P1 systems have EEPROM too. FMFS file access methods are designed to treat the file as virtual memory with none of that sequential access baggage from the tape drive and floppy era thank you.

[Brian Riley]

Hmmmmm, though a lot slower, FMFS, would apply to the EEPROM as well.

[Peter Jakacki]

FTP!!!!!!! OK, Peter, that brings up the matter of getting a file system for the SD !!!!!

Yes, but you do realize that if it's FTP then the memory can stay embedded and so it can be any file system that suits? It doesn't have to be FAT16 or the mangled FAT32 neither of which are really suitable for incremental read/write filing with SD or Flash memory. It helps if an embedded SDFS allocates a large or specified contiguous chunk that doesn't need to reallocate as it grows and also if changing the actual file size would not require writing the same location over and over. I have found it far better that a marker stamp is appended to the end of the file when it's updated which is scanned for and read back into RAM only on mounting as this saves the poor directory sector from premature and certain wear. Even with wear leveling there are costs involved.

What shall I call this embedded file system? Since the SDFS term is used already to refer to a deduplicating file system for virtual environments then perhaps I could call this new file system FMFS for Flash Memory File System as that covers our little SPI Flash chips as well as SD.

The FMFS would still be structured in such a way that it would be compatible with FAT if the media is safely ejected. At that time or even on a reset the directory and file allocation table information can be updated etc. This suits the way I use Flash memory at least.

[KC_Rob]

I think modules like the RPi are great for desktop or bench systems but when we are trying to design a specific product or even just to add more networking capabilities to the Prop itself then it's better to go down the more difficult road and help the Prop "develop" those abilities too. If everyone took the "easy" road and used embedded PCs then we would not be having this discussion on the Propeller forum as there would be no such thing.

Spot on. I don't think pairing the Propeller up with ARM chips, much less ARM modules/SBCs, is really the best way to extend the Propeller's capabilities (vice versa, on the other hand,... perhaps). It might be fun or interesting to do, but I'm less certain that there is much practical application and far less certain that it helps market the Propeller chip itself.

[Brian Riley]

I want to implement serial over TCP and also FTP capabilities to the Prop so let's see what this little baby can do then.

FTP!!!!!!! OK, Peter, that brings up the matter of getting a file system for the SD !!!!!

[Peter Jakacki]

Let me know if there is anything I can do to help. I can test and do more just need a starting point, always the most difficult part.

@Braino The RPi is great but I am trying to reduce accidental complexity with less parts / software so I'll be patient and try to help Peter Tachyon support the module in question.

I think modules like the RPi are great for desktop or bench systems but when we are trying to design a specific product or even just to add more networking capabilities to the Prop itself then it's better to go down the more difficult road and help the Prop "develop" those abilities too. If everyone took the "easy" road and used embedded PCs then we would not be having this discussion on the Propeller forum as there would be no such thing. I do agree however with supplementing the Prop with additional hardware (or vice-versa) when necessary but keeping the complexity down so that I would perhaps use an ARM chip itself with the Prop rather than a whole ARM module.

To make it easier for anyone who wants to be a part of (or just follow along) the Tachyon networking project based initially on the WIZnet W5200 I will start up a Google docs project page with some initial documentation and primitives to access the chip and registers. From there we can add capabilities to the Prop. The W5200 seems to be a sensible solution for the Prop because of the hardwired TCP/IP design of the chip which minimizes scarce Prop resources and also the I/O efficient SPI interface. I want to implement serial over TCP and also FTP capabilities to the Prop so let's see what this little baby can do then.

[D.P]

It just so happens that I have a WIZ820io 5200 based module sitting on the bench waiting to be bombarded by a Tachyon stream so that it will be ready 3 month ago! Unfortunately the Tachyon stream may be a bit delayed so that it only ends up being ready in February!

Let me know if there is anything I can do to help. I can test and do more just need a starting point, always the most difficult part.

@Braino The RPi is great but I am trying to reduce accidental complexity with less parts / software so I'll be patient and try to help Peter Tachyon support the module in question.

[Peter Jakacki]

Tachyon is great, it supports (you) serial, spi, i2c, bluetooth etc, but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.

http://shop.wiznettechnology.com/Sub...id=48&pid=1161

This module is well tested with a couple of prop 1 driver sets here's one:
http://obex.parallax.com/objects/869/

Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.

It just so happens that I have a WIZ820io 5200 based module sitting on the bench waiting to be bombarded by a Tachyon stream so that it will be ready 3 month ago! Unfortunately the Tachyon stream may be a bit delayed so that it only ends up being ready in February!

[prof_braino]

but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.

An alternative to consider is Raspberry Pi. For about the same cost (overall) it provides Ethernet, and pretty much a whole workstation for free. It only costs two I/O lines on the prop. The wiznet stuff has its uses, but RPi might give more bang for the buck, and be a much more powerful general solution.

[D.P]

Tachyon is great, it supports (you) serial, spi, i2c, bluetooth etc, but one thing I would like to see is TCP/IP. An approach would be a module such as the one based on the wiznet 5200 here to off load the IP stack "duties" onto hardware.

http://shop.wiznettechnology.com/Sub...id=48&pid=1161

This module is well tested with a couple of prop 1 driver sets here's one:
http://obex.parallax.com/objects/869/

Both drivers have a spi pasm module and a higher level (socket) spin module. I would be willing to knock around the spin module into FORTH but need assistance integrating/frameworking the pasm driver into Tachyon. I have a Prop1 BOE with the module connected and have been using both driver sets with success. There will be an ethernet quickstart shield based on the w5200 as was announced on this list in another thread.

[fidolo]

Spent some good time studying the Tachyon source code to try to understand its architecture, and wound up learning the basic facts about the propeller chip architecture in the first place. I'm impressed with both.

I find Tachyon 2.1 to be very useable already. I'm now experimenting with fast D/A conversion right out of a pair of propeller pins with just a couple of resistors and a capacitor. It seems possible to output well over 30 k samples per second with 10-bit resolution using the video generator hardware, which seems capable of running a lot faster than the counter could in the duty cycle mode. The idea is to run two D/A channels with 5 bits resolution each (in a highly chopped duty cycle mode), with a 32:1 resistor ratio so one channel will represent the lowest 5 bits and the other the highest 5 bits. If I get it to work well I will share the Tachyon code.

I am grateful to Peter for sharing his Tachyon creation and even its source code, in the open source spirit, which was also a part of the Forth tradition since its early days.

[max72]

Thanks,
I tried Senaterm too. Terminal IDE fixed the new line issue with blueterm, but I cannot paste data.
With the others, including Senaterm I have yet to find the right setup to handle also the copy and paste with line delay.
In the last few days I had not the possibility to try again, but at the moment I have not found yet the perfect Tachyon companion.
Massimo

[mr23]

I fit SENA BTerm onto an HTC Wildfire (very small internal memory) w/o a SD card, along with a bunch of other apps on it (daughter's old phone).


I've had no trouble using it with a chinese BT/Serial-to-Prop (once I switched to FullDuplexSerial4Port (thanks Tracy)).

[max72]

Thanks, on the telephone I have handy there is not room for the Terminal IDE. I'll tried with hacker's keyboard but no luck. I'll test with a more decent android pad soon.
Thanks,
Massimo

[Peter Jakacki]

I received the BT modules!!
I was able to connect to Tachyon from an Android device, but I have problems finding a nice BT terminal for the phone.
Blueterm for instance is not sending the correct end of line.
I also cannot find a tool with the possibility to set the mandatory line delay.
Any suggestion?
Thanks in advance,
Massimo

Blueterm is the right one but you will find that the return problem has to do with the keyboard. Load "Terminal IDE" keyboard as this seems to be the best for this kind of stuff. I modified Tachyon the other week to accept a DEL key as well as the BKSP key because I couldn't find an Android keyboard that would actually send a $08 instead of a $7F or escape sequence.

[max72]

I received the BT modules!!
I was able to connect to Tachyon from an Android device, but I have problems finding a nice BT terminal for the phone.
Blueterm for instance is not sending the correct end of line.
I also cannot find a tool with the possibility to set the mandatory line delay.
Any suggestion?
Thanks in advance,
Massimo

[max72]

My first take with Tachyon:

http://forums.parallax.com/showthrea...94#post1157894

Nothing fancy, but I really like the interactive approach and the possibility to remotely program the propeller.
Ordered a couple of BT modules too.. :-)

Massimo

[max72]

I saw you updated the docs too.
Thanks.
Massimo

[Peter Jakacki]

I occasionally use the PINS? word to tell me about the state of the port pins. Because I have so many different hardware configurations I can't always keep track of the I/O unless I have a schematic in front of me. To assist a little in this regard I have added an extra function to PINS? to also tell me if there is some kind of load on the pin and whether its a pullup or pulldown load. So if for instance a pin is connected to an NPN (via a resistor) then this will show up as a D or pullDown whereas pullup resistors display as a U for pullUp. X indicates a floating pin.

In this hardware P5 is connected to an NPN and P8 has a pulldown with pullups on P16..31 except for P26 which has a pulldown for reset control of a Silabs CPU..So an analysis of what PINS? reports and a comparison with the schematic indicates that this word is very useful.

PINS? 
+----------u----------+
P00 <-- *D    1 --> P31
P01 <-- *D    1 <-- P30
P02 <-- *D   U1 --> P29
P03 <-- *D   U1 --> P28
P04 <-- *D   U1 --> P27
P05 <-- *D   D* --> P26
P06 <-- *X   U1 --> P25
P07 <-- *X   U1 --> P24
P08 <-- 1U   U1 --> P23
P09 <-- *X   U1 --> P22
P10 <-- *X   U1 --> P21
P11 <-- *X   U1 --> P20
P12 <-- *X   U1 --> P19
P13 <-- *X   U1 --> P18
P14 <-- *X   U1 --> P17
P15 <-- *X   U1 --> P16
+---------------------+ ok

[Peter Jakacki]

I mentioned that I would make the project page for the Steering Wheel Inteface to Infrared remote control available. So here it is.
Just to make this project more visible I will post a separate thread as well.

[fidolo]

(Tachyon V2.1-130110 kernel-5MHZ.binary) compiled for a 5MHz crystal and defaulted to 230400 baud into the Dropbox account. When you have the kernel running then set Minicom to a 10ms line delay (^A T D) and copy and paste the EXTEND.fth file, either from the Dropbox or the online document. Of course you can compile the kernel from the source as well, it's very easy and it's only a single file

Some of the Forth words are unfamiliar but not so much if you are familiar with the Propeller chip. There are other words which I would probably change now but they're okay and so they've stuck.

If you have any suggestions for improving Tachyon or the intro page then please let me know.

Thanks Peter, I was just wondering about how to install your latest build, and you just answered my question before I even asked it!

I may have suggestions at some point, but I will not attempt to contribute to your effort until I have a decent familiarity with the extraordinary Propeller-Tachyon combination, which will take a while. I remember when it was estimated that there were about 50,000 Forth progammers in the world, roughly in the days of the FORTH-83 standard. Not being a software engineer by trade, Forth has nevertheless been essential to my professional career, which required me to build a lot of fast experimental hardware, to which Forth is so well adapted.

Since these days, I have been feeling a bit nostalgic, worried about Forth seemingly being progressively eclipsed, quite unfairly if one considers its unique ability to get the best out of hardware. Now I wonder whether Forth on the propeller chip may reverse the trend by inspiring robotic enthusiasts to get the most out of the propeller chip without going all the way down to the tedium exclusive assembly programming, and without any formal training in software engineering, thanks to the inner simplicity and the interactiveness of Forth?

[Peter Jakacki]

Peter, I would suggest just using +* with * being the wildcard. And the additional default rule would be if there is no wildcard, a * will be added before and after, which gives you the intended behaviour.
of course much better :-)

Yes but if I'm searching for U* words where the star is also what I'm looking for then I am stuck. Forth words can use any mix of characters so we need to be able to find them. A double combination of the star should be suitable for practically all cases, we don't want to get too crazy (too late).

[MJB]

If I was looking for anything that started with + then it would be entered this way:
WORDS +**
Where star star (seems unique enough) is the wildcard but also forces a search only for words that begin with + in which case you would find +!

Peter, I would suggest just using +* with * being the wildcard. And the additional default rule would be if there is no wildcard, a * will be added before and after, which gives you the intended behaviour.

Now that would be even better wouldn't it?

of course much better :-)

[Peter Jakacki]

PETER, you have probably had enough suggestions and requests from me to last two lifetimes, but I have been meaning to tender this request for a while ... modify WORDS and QWORDS to take a simple search string

" S" SEARCH or " IN" QSEARCH searches for left justified match of cmds to string. SEARCH ---> WORDS QSEARCH ---> QWORDS'

This will help the apprentices/rookies and will definitely help us journeymen.

I probably need both hands full of fingers to count the number of times in the last 5 weeks I have sent you some code only to have it returned with an "oh by the way, you can use this neat word in place of these 5!" like, for example "+!" .

QWORDS is helpful but a simple filter will go a long way to making Tachyon easier to learn.

Oh, by the way I have been wanting to put a filter into place but I just never got around to it
Rather than passing a string which would mean you would always have to do it or else it might pick up garbage from the stack, I would rather have WORD look for another word or string to describe further actions. This is fine for interactive terminal use whereas the string passing method is better for words which are meant to be called from other words.

So I would have WORDS operate this way if I wanted to find all the words with a + symbol for instance:
WORDS +
In this case wildcards are assumed without having to specify, this makes it easier to get down to business.

If I was looking for anything that started with + then it would be entered this way:
WORDS +**
Where star star (seems unique enough) is the wildcard but also forces a search only for words that begin with + in which case you would find +!

Now this brings me back to my original intention of storing help comments for each word which would be stored if EEPROM > 32K or SD or SPI Flash were available, this is what would happen.

WORDS +!

CFA CODE ATRS NAME DESC
6BD3 0061 ...$ +! ( long addr -- ) add long to long at hub addr
6BC6 005D ...$ W+! ( word addr -- ) add word to word at hub addr
6BB1 0059 ...$ C+! ( byte addr -- ) add byte to byte at hub addr

Now that would be even better wouldn't it?

[Brian Riley]

If you have any suggestions for improving Tachyon or the intro page then please let me know.

PETER, you have probably had enough suggestions and requests from me to last two lifetimes, but I have been meaning to tender this request for a while ... modify WORDS and QWORDS to take a simple search string

" S" SEARCH or " IN" QSEARCH searches for left justified match of cmds to string. SEARCH ---> WORDS QSEARCH ---> QWORDS'

This will help the apprentices/rookies and will definitely help us journeymen.

I probably need both hands full of fingers to count the number of times in the last 5 weeks I have sent you some code only to have it returned with an "oh by the way, you can use this neat word in place of these 5!" like, for example "+!" .

QWORDS is helpful but a simple filter will go a long way to making Tachyon easier to learn.

[Peter Jakacki]

Fired Tachyon V2 on the quickstart propeller board earlier this week. What a delight! Worked as soon as realizing that the binary image is loaded on EEPROM at 56kb, but the board talks at 230kb when booted after that. Runs great on minicom under linux. The introduction webpage by Peter Jakacki, the author of Tachyon, reveals enough to study the source code and its comments and play with a few unfamiliar Forth words as well as the propeller-specific Tachyon words to start making things happen. The performance is so good, I believe it will encourage folks who have never tried Forth to get on with it, because it will open many new possibilities in both functionality and execution speed, including immediate debugging, as only Forth can.

Thanks Fidolo, and welcome to the Propeller forums. You might find those binaries have passed their "best before" date and the memory map has changed enough that the old binary dump methods don't work for now. In the meantime I have downloaded the binary image of the current kernel (Tachyon V2.1-130110 kernel-5MHZ.binary) compiled for a 5MHz crystal and defaulted to 230400 baud into the Dropbox account. When you have the kernel running then set Minicom to a 10ms line delay (^A T D) and copy and paste the EXTEND.fth file, either from the Dropbox or the online document. Of course you can compile the kernel from the source as well, it's very easy and it's only a single file

Some of the Forth words are unfamiliar but not so much if you are familiar with the Propeller chip. There are other words which I would probably change now but they're okay and so they've stuck.

If you have any suggestions for improving Tachyon or the intro page then please let me know.

[max72]

At last I started coding with Tachyon.
I'm playing with the cheap stepper motors, and the interactive environment is great.
I'm using the wifly modules, and I ordered the BT ones too, remote programming is a nice option. I'm really having fun, I only need some time to adapt to the different approach and be a little more fluent in the language.
Thanks for the effort.
Massimo

[fidolo]

Fired Tachyon V2 on the quickstart propeller board earlier this week. What a delight! Worked as soon as realizing that the binary image is loaded on EEPROM at 56kb, but the board talks at 230kb when booted after that. Runs great on minicom under linux. The introduction webpage by Peter Jakacki, the author of Tachyon, reveals enough to study the source code and its comments and play with a few unfamiliar Forth words as well as the propeller-specific Tachyon words to start making things happen. The performance is so good, I believe it will encourage folks who have never tried Forth to get on with it, because it will open many new possibilities in both functionality and execution speed, including immediate debugging, as only Forth can.

[Peter Jakacki]

I've refined the IR transmission a little by reducing the 32-bit code down to a family code byte plus the IR code byte. So the digits 1 to 9 are simply values 1 to 9 and so on. Except for different family codes this seems to work with all the remotes I have lying around so this may just become a useful object on it's own.

IR remote transmission format (this is the way I look at it):

1. PREAMBLE = 20 times the synch pulse duration
2. 4.2ms gap
3. "SYNCH" PULSE
4. FAMILY CODE BYTE (lsb first)
5. FAMILY CODE BYTE INVERTED
6. IR CODE BYTE
7. IR CODE BYTE INVERTED

#P24    CONSTANT =irled
BYTE family        \ IR family code byte
$81 family C!      \ Set the default family code

pub IRLED ( units -- )
    A =irled APIN #38 KHZ            \ Generate a 38kHz carrier
    #460 * us
    MUTE                        \ mute or stop the carrier
    ;
pub IRTX8 ( byte -- )
       8 FOR 
       DUP 1 AND IF #1530 ELSE #480 THEN us        \ "high" period - a 1 is 3 times the length of a 0 high 
       1 IRLED                    \ the "low" pulse  
       2/
       NEXT
     DROP
    ;
\ Transmit the IR code byte as code + inverted 
\ First transmit the preamble then the family code + invert and then the IR code + invert
pub IRTX ( code  -- )
    #20 IRLED                    \ HEADER PREAMBLE
    #4200 us    
     1 IRLED                    \ "start" bit
    family C@ DUP IRTX8 INVERT IRTX8
    DUP IRTX8 INVERT IRTX8
    ;

Now I'm going to mangle the way the steering wheel buttons operate so that it does more than it does at present and it will sense sequences and duration for extra control.

[Peter Jakacki]

This is a neat little project I started today for my wife's car. I just installed a new double DIN 6.5" touchscreen stereo in my car and I also had a brand new single DIN unit for my wife's car but the new unit didn't support the steering wheel interface (SWI). I thought, this is a job for the Prop and Tachyon! (with the same sort of emphasis as "Batman and Robin"). A few hours later I'm just about ready to install it in the car although I have tested it out on the bench. Here's a sneak peek at part of the code, I will put up a project page in the next day or so and link it from the Intro page.

{       *** STEERING WHEEL INTERFACE ***
Measure the resistance of the steering wheel interface
Resistance is a maximum of 6K8 and open if no switches are pressed
RC time constant method is used to detect the resistance but to help there is
a 100K resistor added  in parallel. 
The resistance is referenced to ground and discharges the capacitor as this method offers good noise immunity.

PORT ------220R------|-------|-----> to SWI resistors
                    104C
                     |------------>
                    _|_
}


#12        CONSTANT =scale 
#P8 |<     CONSTANT =swi

\ The maximum value read after conversion is 325 for the 100K resistor which is converted to zero
\ 10K reads around 15
pub SWI ( -- val )
     =swi OUTSET        \ charge the capacitor
     #100 us        \ for long enough (prototype is using a series 220R resistor)
     =swi INPUTS        \ now float the line
     CNT@ =swi WAITPNE    \ and wait for it to go low
     CNT@ SWAP -        \ calculate the time constant        
    =scale SHR        \ justify
    DUP #32 > IF DROP 0 THEN
    ;

\ IR Code 
\ LOW (carrier)    12.5ms 
\ HI (no carrier)    4.5ms
\  pulse low then 32 bits msb to lsb

#P24    CONSTANT =irled
pri IRLED ( units -- )
    A =irled APIN #38 KHZ        \ Generate a 38kHz carrier
    #500 * us
    MUTE                    \ mute or stop the carrier
    ;
pub IRTX ( code -- )
    0 REV                \ flip msbs into lsbs for right shifts
    #25 IRLED        \ 25 units of carrie
    #4500 us    
     1 IRLED
       BL FOR 
       DUP 1 AND 2* 1+ #500 * us        \ "high" period 
       1 IRLED        \ the "low" pulse  
       2/
       NEXT
     DROP
    ;

\ Test it out
$817EF00F IRTX

pub PWR    $817EF00F IRTX ;

[mindrobots]

Isn't that a nifty feature!!!

Brian, thanks for visually demonstrating how clever Peter is!!

[Brian Riley]

CHANGELOG

version long 21_130107,1550

130107
Added , word to compile longs (complements | and || which compile bytes and words)

Peter added the LONG to this for me. I thought that I would repay the favor by running these scripts and copying the console. It should be self-explanatory. I know the visuals one after another like this really brought it home for me ... ENJOY

\ ---- LONG ----------------

TABLE XY  ok
  ok
 1 , 2 , 3  , 4 ,  ok
  ok
XY 20 DUMP
2D44: 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00    ................
2D54: B5 02 74 20 B8 24 03 03 00 00 00 00 00 00 00 00    ..t .$..........
 ok


\ -------- WORD -------------

TABLE  XX  ok
  ok
 1 || 2 || 3 || 4 ||  ok
  ok
XX 20 DUMP
2D58: 01 00 02 00 03 00 04 00 B6 03 74 20 B8 24 03 03    ..........t .$..
2D68: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
 ok

\ --------- BYTE --------------

TABLE XZ  ok
  ok
 1 | 2 | 3 | 4 |  ok
  ok
XZ 20 DUMP
2D64: 01 02 03 04 B5 03 74 20 B8 24 03 03 00 00 00 00    ......t .$......
2D74: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
 ok

[Peter Jakacki]

Seems like I've been away for ages from any active development work on the Tachyon kernel. Seeing it's a new year I've fixed up the Intro page and brought it up to date as well as the various files and links. I hadn't realized that the links were still pointing to V2.0 rather than V2.1 which is my current kernel since November so make sure you grab this version. I will also update the binaries and make sure that I snapshot a copy that can always be used with the intro page examples.

I will finish off judging the much delayed challenge and proceed to kick off the 4/4 challenge for 2013 as well which I hope I will have better organized this time

[Peter Jakacki]

Peter - could you check into a minor issue. I think that if you have a line with just a backslash and no trailing whitespace, Tachyon may not terminate the comment with the end of line. This had me confused for a while, and it might save someone some time. I didn't look into how comments are handled (are they just another word?), so maybe this is not a surprise.

Also I was curious what you think about DOES> - do you have plans to implement it, or do you find that you don't make use of it in embedded programming?

Cosmetics, cosmetics..... Yes, I should do something about the backslash as TF doesn't use a line input buffer, just a word buffer so it's just as happy to have a backslash and CR as a terminator as it is just to have a space.

I haven't ruled out implementing DOES> as there have been a few times I could have used it effectively, so maybe sometime in the next few weeks after I've finished wrangled with a few things that didn't quite get done last month!

[KeithE]

Peter - could you check into a minor issue. I think that if you have a line with just a backslash and no trailing whitespace, Tachyon may not terminate the comment with the end of line. This had me confused for a while, and it might save someone some time. I didn't look into how comments are handled (are they just another word?), so maybe this is not a surprise.

Also I was curious what you think about DOES> - do you have plans to implement it, or do you find that you don't make use of it in embedded programming?

[Peter Jakacki]

Hello:

Can some one tell me the fundamental difference between version V2 and the original?

Regards,
Rich

I've lost track of that but when I started to change the way the kernel operated I wanted to break that off into a different version. I don't see the sense in zero point zero versions so I started with the first version which is of course V1. So V2 is just the platform for testing new enhancements while leaving V1 stable but V2 has proved stable from the start however.
So to sum up the enhancements:

• Loop branch parameters are stacked in cog RAM to allow for minimal looping overhead
• Faster dictionary searches
• Trimmed VM kernel and modularized special I/O instructions for SPI and SD etc.
• Extended direct call to VM opcodes using XOP to access top 256 longs.
• Removed possibility of absolute calls (was unused) and instead expanded the vector table handling.
• Updated serial receive to preprocess special control characters and sequences including fast-load filtering
• Optimized the number preprocessing for compilation speed
• Optimized the memory map etc

So don't even bother with V1 as all the extensions and examples are coded for V2 anyway.

If you're not picky about what a language "should be" and like to get interactive with your hardware and get up-and-running as quick as possible as well as having fast compiled code then I can definitely recommend Tachyon.

[richaj45]

Hello:

Can some one tell me the fundamental difference between version V2 and the original?

Regards,
Rich

[Brian Riley]

The neat new 8x8 RGB LED Matrices offer a lot of fun and when several are combined ca produce spectacular results.

I transcribed one of Simply Tronics for the BS2 from PBASIC to TF, added a few things, the made it more Forth-like.

The concept is redirection of Console Output which means all the nice formatting words Peter created are available, as is EMIT to send unprintable values.

[Brian Riley]

Brian your DropBox link is subscription only? It says "The invitation has already been used by ......."

Thanks for the RotaryEncoder words.

It is the same file as in msg# 541 above. Meanwhile I gotta ge t Drop Box figured out!

[D.P]

Brian your DropBox link is subscription only? It says "The invitation has already been used by ......."

Thanks for the RotaryEncoder words.

[Brian Riley]

I originally wrote this routine for PUMPTIMER, my entry in the Thanksgiving Challenge. I spent an hour this afternoon, isolating the routine and its few dependent variables, and included some code snippets of usage so it can just be included and used with little or no additional edits ... enjoy!

[Brian Riley]

Nice, Brian!
I should take the code I did for my one digit clock entry for the RTC on the PPDB and see if we can share the high level code with the different low level code.

You will notice up top where I aliased the low level i/o:

				
:	RTC!	( byte -- )			SI2C! ;	
:	RTC!?	( byte -- flag )		SI2C!? ;
:	RTC@	( flag -- byte flag )	SI2C@  ;

When it became apparent that the 1307 was 'slow' the sum of the edits were three "S"s one in front of each I2C i/o primitive.

[mindrobots]

Nice, Brian!

I should take the code I did for my one digit clock entry for the RTC on the PPDB and see if we can share the high level code with the different low level code.

[Brian Riley]

I have preliminary completion of a set of words comprising a Toolkit for the DalSemi/Maxim DS1307 Real Time Clock. Although it is a 5V chip it has been running fine for several days on 5V with a pair of 1K resistors in the lines to SDA and SCL.

You may notice that even though I wrote BCD>INT and INT>BCD I for t he most part leave the RTC data in BCD and simply use .BYTE to do display data. The two instances in the enclosed code that I do BCD conversions are to get accurate values to index into a string array for labels for month and day of week.

I also included the DS1307 Data Sheet it can also be found in my shared DropBox

[D.P]

Yes, I want to do it right which is why I might even just do some simple web pages in the meantime with the aim of adding shopping carts and all that that entails.

Let me know if you want to see contao / isotope sometime, I can give you a quick tour (front end / backend ) when your ready to do it right. In the meantime I think there are a few on this forum looking for puppys with blueteeth!

[Peter Jakacki]

Yes those modules you have are tempting but elusive until your store is online which brings up my favorite Content Management System (CMS) with integrated, seemless ecommerce package: contao/isotope all php based and open source, really nice once setup. Much different that Jumla et al with magento.

Yes, I want to do it right which is why I might even just do some simple web pages in the meantime with the aim of adding shopping carts and all that that entails.

[D.P]

I posted some info back in in this thread where I have used those serial Bluetooth modules from ebay except I made my own backplane to suit the enhanced Prop plug compatible connection that I use.

Yes those modules you have are tempting but elusive until your store is online which brings up my favorite Content Management System (CMS) with integrated, seemless ecommerce package: contao/isotope all php based and open source, really nice once setup. Much different that Jumla et al with magento.

[KeithE]

I posted some info back in in this thread where I have used those serial Bluetooth modules from ebay except I made my own backplane to suit the enhanced Prop plug compatible connection that I use.

Thanks for the pointer Peter. That looks interesting. I'll be keeping my eyes open for any availability announcements. I saw those on Ebay too, so it's nice to know that they actually work.

[Peter Jakacki]

Bluetooth would be even nicer I agree, but this was free ;-) Is there any particular Bluetooth adaptor that you recommend based on your experience?

Would the Seeed Bluetooth Shield be worth buying? It's at Radio Shack and I have a long holiday coming up.

I posted some info back in in this thread where I have used those serial Bluetooth modules from ebay except I made my own backplane to suit the enhanced Prop plug compatible connection that I use.

[KeithE]

Yes, I use the Nexus 7 as well as other devices but over Bluetooth to talk to my Forth systems. I even have text editors etc so I edit, copy, and paste into Blueterm and I am able to load in new firmware easily. I even have clients using this method as I have my running systems constantly send out operating and diagnostic information over the serial port, all they have to do is connect somewhere within range and all the information just appears automatically. In these cases I normally have a simple single character command they can use to effect changes or even escape back to the Forth console for more advanced stuff. Surprisingly Bluetooth works very effectively in an open area so that I have no problems at all communicating to many units scattered over the factory floor while I find a nice comfortable place to sit. If there appears to be a problem somewhere I normally just type in a little one-liner that captures that problem and reports back to me. One more of many reasons to use Forth in embedded control systems.

Bluetooth would be even nicer I agree, but this was free ;-) Is there any particular Bluetooth adaptor that you recommend based on your experience?

Would the Seeed Bluetooth Shield be worth buying? It's at Radio Shack and I have a long holiday coming up.

[Peter Jakacki]

I asked about this earlier, so thought it only fair to post some results. You can use a Galaxy Nexus 7 as a serial terminal for communicating with Tachyon Forth. I tried Slick USB 2 Serial Terminal and that didn't work, but USB Serial Monitor Lite works o.k. It's not a sophisticated program, so I'll search for some alternatives. All I used was a USB OTG cable with the micro connector which plugs into the Nexus, and then the USB cable with the mini connector to plug into the Parallax Prop Plug. The Nexus doesn't appear to supply power, so you can't just plug into a QuickStart board without a separate power source.

Anyways this is a very portable solution, and I think that it beats looking at composite video and having to plug in a keyboard. Sorry for the shakey photo.

Yes, I use the Nexus 7 as well as other devices but over Bluetooth to talk to my Forth systems. I even have text editors etc so I edit, copy, and paste into Blueterm and I am able to load in new firmware easily. I even have clients using this method as I have my running systems constantly send out operating and diagnostic information over the serial port, all they have to do is connect somewhere within range and all the information just appears automatically. In these cases I normally have a simple single character command they can use to effect changes or even escape back to the Forth console for more advanced stuff. Surprisingly Bluetooth works very effectively in an open area so that I have no problems at all communicating to many units scattered over the factory floor while I find a nice comfortable place to sit. If there appears to be a problem somewhere I normally just type in a little one-liner that captures that problem and reports back to me. One more of many reasons to use Forth in embedded control systems.

[KeithE]

I asked about this earlier, so thought it only fair to post some results. You can use a Galaxy Nexus 7 as a serial terminal for communicating with Tachyon Forth. I tried Slick USB 2 Serial Terminal and that didn't work, but USB Serial Monitor Lite works o.k. It's not a sophisticated program, so I'll search for some alternatives. All I used was a USB OTG cable with the micro connector which plugs into the Nexus, and then the USB cable with the mini connector to plug into the Parallax Prop Plug. The Nexus doesn't appear to supply power, so you can't just plug into a QuickStart board without a separate power source.

Anyways this is a very portable solution, and I think that it beats looking at composite video and having to plug in a keyboard. Sorry for the shakey photo.

[KeithE]

Peter, D.P., or Dave,

Since you mention machineforth I was curious if any of you have tried programming something like the Greenarrays (or predecessors), b16 (influenced by Chuck) or other similar processors. I wonder how the size of these cores compares to a COG? Maybe something to do with your DE0/DE2 boards once the Prop2 silicon arrives. I tried b16 a while back, but it was too much of a jump for me and I found it very frustrating.

-Keith

[D.P]

I'm not trying to force ANS Forth onto Tachyon. I understand that Tachyon is a machine Forth and not a standard Forth. It just helps to avoid confusion to use the same definition when using an ANS Forth word. If you want the word to act differently it might be wise to use a different name to avoid confusion.

A machine forth is correct and for myself a solution to physical engineering problems require software and hardware, not some generic portable ANS software tool but targeted to actual hardware. C, C++ users forget about libc and all the rest of the library systems that must be physically tied to the hardware in order to make them appear "portable". Tachyon is not about Alt-Lang it's Alt-Project in my world.

[D.P]

When something is really logical but it's not done that way because of a standard or tradition then I buck the system when I am free to do so. I never intended WITHIN to be nonstandard but when you look at what the standard says, that it has an inclusive limit at one end but not at the other then it doesn't make a lot of sense, who am I to judge but maybe the ANS committee were smoking some tobacco that smelt funny.

As for renaming it well that's the annoying part because it's the right name for that function if you want it to flow in a statement like this:
"0" "9" WITHIN IF

Otherwise I could use less readable but logically correct symbols like this:
"0" "9" =><= IF

But if I make it ANS then it doesn't look right either as you lose the sense of it:
"0" ":" WITHIN IF

So, do you see my dilemma?

Yes I see, and please keep bucking so us mere mortals can work on our problems and not work on the tools i.e. accidental complexity.

[Peter Jakacki]

When something is really logical but it's not done that way because of a standard or tradition then I buck the system when I am free to do so. I never intended WITHIN to be nonstandard but when you look at what the standard says, that it has an inclusive limit at one end but not at the other then it doesn't make a lot of sense, who am I to judge but maybe the ANS committee were smoking some tobacco that smelt funny.

As for renaming it well that's the annoying part because it's the right name for that function if you want it to flow in a statement like this:
"0" "9" WITHIN IF

Otherwise I could use less readable but logically correct symbols like this:
"0" "9" =><= IF

But if I make it ANS then it doesn't look right either as you lose the sense of it:
"0" ":" WITHIN IF

So, do you see my dilemma?

[KeithE]

Thanks Peter. I'm just pointing out things like this since they might cause some confusion. I don't know the history well enough to make a strong recommendation.

[Dave Hein]

I'm not trying to force ANS Forth onto Tachyon. I understand that Tachyon is a machine Forth and not a standard Forth. It just helps to avoid confusion to use the same definition when using an ANS Forth word. If you want the word to act differently it might be wise to use a different name to avoid confusion.

[Peter Jakacki]

The ANS version of WITHIN is true if n >= low and n < high. There is a non-standard COMUS Forth word, which is BETWEEN that is true if n >= low and n <= high. It can be implemented with ": BETWEEN 1+ WITHIN ;" It appears that Tachyon's implemention is consistent with BETWEEN.

The ANS version is the problem as WITHIN is either within those inclusive limits or not and BETWEEN is between the limits themselves. When Forth was not tied to the vastly unpopular ANS standard it remained popular. I don't have a big problem changing BETWEEN to suit if that really helps though. But there are plenty of other things that are never going to be ANS in Tachyon anyway.

[Peter Jakacki]

Peter - after playing around some more and found out what was going on most recently. My terminal program "CoolTerm" was sending CR/LF for the Enter key, and this was interrupting the operation of WORDS/QWORDS. When I turned this off it works. It explains why I got different results in different terminal programs due to the different default settings.

Normally the LF is discard on line inputs but still accept as a KEY character. Perhaps I could just modify QWORDS to ignore LFs.

[Dave Hein]

The ANS version of WITHIN is true if n >= low and n < high. There is a non-standard COMUS Forth word, which is BETWEEN that is true if n >= low and n <= high. It can be implemented with ": BETWEEN 1+ WITHIN ;" It appears that Tachyon's implemention is consistent with BETWEEN.

[KeithE]

Peter - is this a bug or dialect issue? According to Forth Application Techniques the definition for WITHIN is:

WITHIN ( n nlow nhigh - t ) Returns true is nlow <= n < nigh

' ( n lo hi -- flg ) true if n is within range of low and high inclusive
WITHIN	byte	INC,OVER,MINUS,PUSHR
	byte	MINUS,RPOP,XCALL,xULT
WT1	byte	ZEQ,ZEQ,EXIT

Win32Forth:

System Editor is:    Win32Forth IDE

: ISASCII ( n - )
    #32 #128 WITHIN IF ." VALID CHARACTER" THEN ;  ok
#31 ISASCII  ok
#32 ISASCII VALID CHARACTER ok
#127 ISASCII VALID CHARACTER ok
#128 ISASCII  ok

Tachyon:

: ISASCII ( n - ) 
    #32 #128 WITHIN IF ." VALID CHARACTER" THEN ;  ok
#31 ISASCII  ok
#32 ISASCII VALID CHARACTER ok
#127 ISASCII VALID CHARACTER ok
#128 ISASCII VALID CHARACTER ok

PS - I guess that I could have chosen a better name for the word, and it should probably be looking for < 127 not < 128, but the main question is about the actual implementation of WITHIN.

[KeithE]

Peter - after playing around some more and found out what was going on most recently. My terminal program "CoolTerm" was sending CR/LF for the Enter key, and this was interrupting the operation of WORDS/QWORDS. When I turned this off it works. It explains why I got different results in different terminal programs due to the different default settings.

[KeithE]

Just had a thought looking at your last post that maybe the terminal emulator is trying to software handshake or something because the WORDS and QWORDS terminated immediately which means it has detected user (or ab'user) interruption. Make sure the terminal settings are no hardware or software handshake, no character delay, and 10ms line delay.

As for CASE it's one of those words I was playing with that are unfinished but I had an application the other day that could use a good case statement so this little word may be reactivated and revamped.

Peter - I think that you're correct about some sort of corruption during the upload of EXTEND.fth. I've had problems when putting in a zero character delay too. It looks like some others have had this problem as well. Maybe I should install Linux and give minicom a try just to see how much better it works. I just tried various pacing delays and terminal emulators, and was able to get an upload where WORDS works.

In the future would it be easy to add some sort of CRC check of the EEPROM contents? And then you would publish the golden CRC? I'm not sure how well this would work if people make changes to the base build - e.g. the baud rate. Maybe it could just be done when serial uploading is occurring? Or just to a portion of EEPROM?

[Peter Jakacki]

Just had a thought looking at your last post that maybe the terminal emulator is trying to software handshake or something because the WORDS and QWORDS terminated immediately which means it has detected user (or ab'user) interruption. Make sure the terminal settings are no hardware or software handshake, no character delay, and 10ms line delay.

As for CASE it's one of those words I was playing with that are unfinished but I had an application the other day that could use a good case statement so this little word may be reactivated and revamped.

[KeithE]

Peter - one more question. I noticed that the code for CASE is commented out. Was that intentional?

[KeithE]

Peter - I finally got a chance to try this release out, and the dropbox version looks o.k. as far as the ^D command. I did notice that the behavior of both WORDS and QWORDS changed. Here's what I see:

  Propeller .:.:--TACHYON--:.:. Forth V21121214.1800

NAMES:  $63E3...7464 for 4225 (22955 bytes added) with 23159 bytes free
CODE:   $0000...26CF for 5710 (3791 bytes added) with 22833 bytes free
CALLS:  0668 vectors free
.
MODULES LOADED: 
1800: EXTEND.fth          Primary extensions to TACHYON kernel - 121214.1900 

----------------------------------------------------------------
WORDS 
NFA  PFA  EXT ATRS NAME 
----------------------- 
63E4 26C9 YB1 ...: COLD. ok
QWORDS 
COLD 
 ok

I was curious what 8051 tools you use. We used Keil at work and have shipped many 100's of millions embedded 8051 cores. (I can't say a billion for certain ;-) You would be surprised where they end up. I think that those tools are a bit pricey for home use though - we chose Keil because it supported the FS2/MIPs debugger that we used. If people follow your advice it's amazing to think about how many of these 8051s could be out there.

[Cluso99]

Don't you sleep Peter (prev post at 3:40am less 1hr since Qld is backward with no daylight saving time)? Oops, I was up till 4am

[Peter Jakacki]

Thanks for looking into and fixing this so quickly Peter! BTW - I just looked on Dropbox and don't see the update there either.

You might be right about the dropbox thing, I've got a funny feeling that since I updated my Linux system that my Dropbox needs to be reinstalled. Sorry about that, I will fix that up right now.

[KeithE]

Thanks for looking into and fixing this so quickly Peter! BTW - I just looked on Dropbox and don't see the update there either.

[Peter Jakacki]

Where are the corrections ??? I did not see any new kernel so I used 11/14 and I grabbed EXTEND 12/14. IN that configuration ^D is still broken!

Maybe you need to refresh the page or directory, it certainly is there. Either way here are the files and I had to change the name of EXTEND.fth to EXTEND.fth.txt just so the forum uploader would see it???

[Brian Riley]

I fixed the bug with DEBUG, funny that. The problem lay in a simple word which is used to point to the stacks in the cog and it had been moved to interpreted bytecode to free up a couple of longs. In fact there were two bugs with it, one in the definition and the other in the vector table entry. All fixed.

Where are the corrections ??? I did not see any new kernel so I used 11/14 and I grabbed EXTEND 12/14. IN that configuration ^D is still broken!

[Bill Henning]

Nice work Peter!

Quite some time ago on this forum I started a thread about using small and cheap micros in place of more expensive and limited peripheral chips such as MCP3208s etc. For around one or two dollars or so you can have a better 12-bit ADC chip with lots of features and even program in your own acquisition code to filter and average etc if you like. Normally I interface via the I2C lines and there is no reason why the PPC can't also drive some LEDs and monitor your serial receive line for special control sequences etc. Most of these chips have ADC, DAC, PWM, UART, SPI, I2C plus they are fast and have a very good precision oscillator.

At that time I also released some Spin code that could program the PPC with an embedded binary file compiled from whatever 8051 software tools you so desired. C8051s are very fast at 25 or 50 MIPS yet are simple to write code for even in assembler. Now I have released working Flash programming code in Tachyon Forth which takes up less than 900 bytes of code including the Intel Hex loader utility. So you can design boards with these chips instead of the limited and "why are they so much more expensive" dumb peripheral chips. The con with this chip is that except for a couple of DIP packs most of the series are only available in SMD (mostly QFN but not all).

The reason I wrote this code in Tachyon Forth is because I designed my new QVGA TFT driver using a $1.60 chip that enables me to talk to the display via a hybrid I2C that can shift into high speed 2-wire SPI mode. The chip also takes care of power-up reset as well as block operations such as clearing the screen and fills etc. Well, it can even do everything anyway if it has to but there are some things I like to leave for the Propeller to handle. This is the block diagram for this particular one that is in an easy to solder by hand 24 pin QSOP pack. BTW, it may even handle the touch screen too.

Attachment 97832

The link to the code is at the bottom of the introduction page (see my sig) or also here for your convenience.

I also had to get this display working because it's one of the prizes in the Forth of the Forth competition for which I will announce the winners this weekend.

[Peter Jakacki]

Quite some time ago on this forum I started a thread about using small and cheap micros in place of more expensive and limited peripheral chips such as MCP3208s etc. For around one or two dollars or so you can have a better 12-bit ADC chip with lots of features and even program in your own acquisition code to filter and average etc if you like. Normally I interface via the I2C lines and there is no reason why the PPC can't also drive some LEDs and monitor your serial receive line for special control sequences etc. Most of these chips have ADC, DAC, PWM, UART, SPI, I2C plus they are fast and have a very good precision oscillator.

At that time I also released some Spin code that could program the PPC with an embedded binary file compiled from whatever 8051 software tools you so desired. C8051s are very fast at 25 or 50 MIPS yet are simple to write code for even in assembler. Now I have released working Flash programming code in Tachyon Forth which takes up less than 900 bytes of code including the Intel Hex loader utility. So you can design boards with these chips instead of the limited and "why are they so much more expensive" dumb peripheral chips. The con with this chip is that except for a couple of DIP packs most of the series are only available in SMD (mostly QFN but not all).

The reason I wrote this code in Tachyon Forth is because I designed my new QVGA TFT driver using a $1.60 chip that enables me to talk to the display via a hybrid I2C that can shift into high speed 2-wire SPI mode. The chip also takes care of power-up reset as well as block operations such as clearing the screen and fills etc. Well, it can even do everything anyway if it has to but there are some things I like to leave for the Propeller to handle. This is the block diagram for this particular one that is in an easy to solder by hand 24 pin QSOP pack. BTW, it may even handle the touch screen too.



The link to the code is at the bottom of the introduction page (see my sig) or also here for your convenience.

I also had to get this display working because it's one of the prizes in the Forth of the Forth competition for which I will announce the winners this weekend.

[Peter Jakacki]

I fixed the bug with DEBUG, funny that. The problem lay in a simple word which is used to point to the stacks in the cog and it had been moved to interpreted bytecode to free up a couple of longs. In fact there were two bugs with it, one in the definition and the other in the vector table entry. All fixed.

DATA STACK 
01A6: 000001A6 00001234 
01A8: FFFFF9FF 00000000 00000000 00000000 
01AC: 00000000 00000000 00000000 00000000 
01B0: 00000000 00000000 
RETURN STACK 
01B2: 0000167A 00001487 
01B4: 000013E8 00000A93 00000A77 00000A10 
01B8: 000009A6 000009A6 0000099E 00000996 
01BC: 00000000 00000000 00000000 00000000 
01C0: 00000000 00000000 00000000 00000000 
LOOP STACK 
01C4: 00000000 00000000 00000000 00000000 
01C8: 00000000 00000000 00000000 00000000 
REGISTERS
0068: 00 00 CC 01 00 00 00 00 00 00 00 00 00 00 00 00    ................
0078: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0088: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0098: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00A8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00B8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00C8: 00 00 00 00 00 00 00 00 34 12 00 00 00 00 00 00    ........4.......
00D8: 04 00 00 00 00 00 00 00 90 7C 00 02 00 00 00 00    .........|......
00E8: 00 00 00 00 65 6A 64 6A 64 6A 00 00 40 18 40 18    ....ejdjdj..@.@.
00F8: 40 18 5A A5 01 00 00 00 20 04 10 10 04 0D 00 00    @.Z..... .......
0108: 00 01 31 34 00 00 00 00 00 00 00 00 00 00 00 00    ..14............
0118: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0128: 00 00 00 00 00 00 00 00 00 00 00 00 00 24 00 00    .............$..
0138: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0148: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 31 31    .............211
0158: 32 31 31 39 43 00 00 00 00 00 00 00 00 00 00 00    2119C...........

COMPILATION AREA
1840: 73 12 34 03 03 03 00 00 00 00 00 00 00 00 00 00    s.4.............
1850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
1860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
1870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

[Loopy Byteloose]

@Iamretired
For starters, you can just use Minicom as a computer terminal in your existing computer. If you need to hook up an independent VGA and keyboard right away, you will have less Cogs to use.

I use a Toshiba NB250 notebook and either a Prop Demo Board or Prop Proto Board ( I have about 4 boards running Forth at this point).

I am sure Peter will explain what a VGA and keyboard require in detail.

[Peter Jakacki]

Peter - I was wondering if the ^D Debug dump "Dumps the stacks and registers and compilation area." is working in the latest version. I can't seem to make sense of the data stack dump. It the information encoded? I like a lot of the ideas that you have in here.

Well I just tried this and it seems to be a bug for sure, I just haven't used this feature for a while, I guess it shows. I will fix up the bug and post back here when I'm done.

DATA STACK 
5685: 5C7C0003 A0BF3394 08BF3799 
5688: 5C7C0084 A0BF37F2 5C7C000F A0BFE9A6 
568C: 5C7C000B 6CBFE99C 5C7C00F8 68BFE9A6 
5690: 5C7C0092 
RETURN STACK 
000C: 5C7C00F8 EC7F4CF8 A0BF37A6 5CFF0374 
0010: 5C7C00F8 A0BF37A7 5C7C000F A0BF37A8 
0014: 5C7C000F A0BF37A9 5C7C000F A0BF37A7 
0018: A0BF4FA6 A0BF4D9B 5C7C00F8 A0BF37A8 
001C: A0BF51A7 5C7C0018 
LOOP STACK 
001E: A0BF4FA6 5C7C000B 
0020: 80BF4FA6 5C7C000B 84BF4FA6 5C7C000B 
0024: 80FF4C01 5C7C00F8 
REGISTERS
0068: 00 00 26 00 00 00 00 00 00 00 00 00 00 00 00 00    ..&.............
0078: 8D CE 13 43 00 00 00 00 8A 20 00 00 00 A0 00 00    ...C..... ......
0088: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0098: 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00    ................
00A8: 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00    ................
00B8: 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00    ................
00C8: 24 20 01 00 00 00 00 00 0D 00 00 00 00 00 00 00    $ ..............
00D8: 02 00 00 00 00 00 00 00 90 7C 00 02 FD 26 00 00    .........|...&..
00E8: 00 00 00 00 65 6A 77 5E 86 5C 91 5C 7B 35 7A 39    ....ejw^.\.\{5z9
00F8: 7A 39 5A A5 00 00 D3 00 20 04 10 10 04 0D 00 00    z9Z..... .......
0108: 0A 01 24 44 00 00 00 00 00 00 00 00 00 00 00 00    ..$D............
0118: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0128: 00 00 00 00 00 30 30 30 31 30 00 00 00 23 00 00    .....00010...#..
0138: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0148: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 31 31    .............211
0158: 31 30 34 36 34 00 00 00 00 00 00 00 00 00 00 00    10464...........

COMPILATION AREA
397A: 03 03 03 03 00 00 00 00 00 00 00 00 00 00 00 00    ................
398A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
399A: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
39AA: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

[KeithE]

Peter - I was wondering if the ^D Debug dump "Dumps the stacks and registers and compilation area." is working in the latest version. I can't seem to make sense of the data stack dump. It the information encoded? I like a lot of the ideas that you have in here.

[D.P]

The VGA driver was easy to interface and I just ignored the Spin routines although they were using up memory. All that is really needed is to access the memory directly from Forth. The TV driver is similar and I will just have to test it out. As for the Wiznet driver I suspect that a lot of routines are written in Spin with the low-level stuff in a PASM cog. What's needed here is just the PASM for the cog and replacing the Spin commands etc with Forth ones. Do you have a link to "the wiznet 5200 driver"?

Here's the link to the repository,

http://code.google.com/p/propeller-w...r-w5200-driver

This link TWC has found a buffer overflow in the driver but I've been using it without error so far.

http://forums.parallax.com/showthrea...Gotcha-amp-Fix

[Peter Jakacki]

Or how about any object with tachyon, like the wiznet 5200 driver?

The VGA driver was easy to interface and I just ignored the Spin routines although they were using up memory. All that is really needed is to access the memory directly from Forth. The TV driver is similar and I will just have to test it out. As for the Wiznet driver I suspect that a lot of routines are written in Spin with the low-level stuff in a PASM cog. What's needed here is just the PASM for the cog and replacing the Spin commands etc with Forth ones. Do you have a link to "the wiznet 5200 driver"?

[D.P]

Hi John, are you trying to run a TV object with Tachyon? Tachyon doesn't "need" objects but a user might need the capability of an object, if you know what I mean. All the objects in the obex were written for interfacing to other Spin programs so they might need a little tweaking as no Spin independent API has been implemented for these objects. So, are you wondering how to integrate a TV object with Tachyon then?

Or how about any object with tachyon, like the wiznet 5200 driver?

[Peter Jakacki]

I have run the Propeller Tool on my Dell XP PC. I downloaded the TV demo onto the Prop Demo Board and ran it. I find it difficult when there are several objects that are needed to run an application like Tachyon. Years ago I learned how to write simple FORTH routines on a DOS based PC.
Thank you,
John

Hi John, are you trying to run a TV object with Tachyon? Tachyon doesn't "need" objects but a user might need the capability of an object, if you know what I mean. All the objects in the obex were written for interfacing to other Spin programs so they might need a little tweaking as no Spin independent API has been implemented for these objects. So, are you wondering how to integrate a TV object with Tachyon then?

[Iamretired]

I have run the Propeller Tool on my Dell XP PC. I downloaded the TV demo onto the Prop Demo Board and ran it. I find it difficult when there are several objects that are needed to run an application like Tachyon. Years ago I learned how to write simple FORTH routines on a DOS based PC.
Thank you,
John

[D.P]

I have a Prop Demo Board, a PS/2 keyboard, and a VGA monitor. Is there a set of instructions for setting up and using Trachyon with this configuration. Please note: I am a raw beginner.
John

How raw? Have you programmed the demo board with any spin code with the propeller tool and made the "lights" blink yet?

What OS are you using for development work: OSX, Linux, Windows.

dp

[Iamretired]

I have a Prop Demo Board, a PS/2 keyboard, and a VGA monitor. Is there a set of instructions for setting up and using Trachyon with this configuration. Please note: I am a raw beginner.
John

[Peter Jakacki]

Peter - no reason, just going through the introduction. I looked at FONT5X7.fth, but it didn't look like an exact match. I'm thinking that I might start going through the manual for the Propeller Education Kit and just try translating the examples into forth. It's been a while since I played with the Propeller and with forth so I'm very rusty.

Maybe in a year someone in this area could take Tachyon to Forth day at SVFIG. If you keep having your contests there could be some interesting demos to show.

It's the same font but it's called FONT5X7 in Forth rather than just FONT, that's all. Come to think of it there are some characters that were never finished off in that font, mainly the lower case ones as these were just copied from the upper case and only a few were changed at the time.

[KeithE]

I need to go back through the intro page and bring it up to date as a lot of things changed in a very short period of time. Initially I had the VGA and fonts loaded by default but now you need to explicitly load these in yourself. Is there something in particular you need it for? It can be found in the Dropbox files as FONT5X7.fth.

Peter - no reason, just going through the introduction. I looked at FONT5X7.fth, but it didn't look like an exact match. I'm thinking that I might start going through the manual for the Propeller Education Kit and just try translating the examples into forth. It's been a while since I played with the Propeller and with forth so I'm very rusty.

Maybe in a year someone in this area could take Tachyon to Forth day at SVFIG. If you keep having your contests there could be some interesting demos to show.

[Peter Jakacki]

I have a question about one of the examples in the "Introduction to TACHYON Forth" document. In the section "Play Time" is FONT just the address of where the font is in ROM? This word doesn't seem to be defined in the core or EXTEND.fth.

I need to go back through the intro page and bring it up to date as a lot of things changed in a very short period of time. Initially I had the VGA and fonts loaded by default but now you need to explicitly load these in yourself. Is there something in particular you need it for? It can be found in the Dropbox files as FONT5X7.fth.

[KeithE]

I have a question about one of the examples in the "Introduction to TACHYON Forth" document. In the section "Play Time" is FONT just the address of where the font is in ROM? This word doesn't seem to be defined in the core or EXTEND.fth.

[KeithE]

If you don't like TeraTerm, there are other terminal programs for Window. Minicom is what I am using and I think Peter is too. Then there is PuTTY. All are free.

I am not sure if the 'separate cut & paste' will go away as I think I have a similar situation in Minicom. I have to use the mouse and the menu of the terminal to paste, the CNTL-V doesn't work for me in Ubuntu. Not exactly sure that TeraTerm is doing with delays and tabs and all.

Thanks - it's more for convenience than taste. I have an old minimalistic OS X laptop that I plan to use for some of this over a winter shutdown, so I wanted to make sure something would work there. I tried zterm and it worked out o.k. My main desktop has more memory etcetera, so I can run VMWare on it quite nicely.

[Dave Hein]

Well as soon as we get a few people helping with the P2 documentation then I can take a break. It's grueling man.
As much as I'm itching to fire up Tachyon on the P2 FPGA I've just been too bogged down with all these other things. Now I have the job of judging the entries for the Forth of the Forth because I need to have that done in the next day or so. Then I've got my new QVGA display board that I will have to test and write some firmware for the interface chip as well. Then....not P2....but Tachyon will get some more attention as I have some real need at present for FAT32. All this is interleaved with work projects but Tachyon P2 will be up and running soon.

Peter, I don't know how far along you are on the FAT32 implementation, but I've done some work recently on this for pfth. I'm using code from FSRW to provide the SPI driver plus the Spin mount routine. This handles the messy initialization of the SD card before I start up the Forth cog. The Spin mount routine saves the useful volume information in a data struct that can be access by the Forth routines. It saves things like the cluster size, file system type and the first sector number for the root directory. I haven't gotten very far with this yet, but I wrote a couple of words named file-list and file-type that can list the files in the root directory and type the contents of a file to the console. This code is in the latest update to pfth.

[Loopy Byteloose]

If you don't like TeraTerm, there are other terminal programs for Window. Minicom is what I am using and I think Peter is too. Then there is PuTTY. All are free.

I am not sure if the 'separate cut & paste' will go away as I think I have a similar situation in Minicom. I have to use the mouse and the menu of the terminal to paste, the CNTL-V doesn't work for me in Ubuntu. Not exactly sure that TeraTerm is doing with delays and tabs and all.

[KeithE]

Thanks for the tips guys. I was able to load EXTEND.fth and use QWORDS with Tera Term. My main problem was the WORDS that's built into the Tachyon V2.1.spin file. It's not that I really need that to work, but it makes me worry that something fundamental may have gone wrong. I'll give some of the suggestions for other tools a try this week since I'm not crazy about running Tera Term.

Regards,
Keith

[MJB]

I recently had same problem.

Did you notice, that Tera-Term has a separate delay setting for Cut&Paste in the SETUP\Additional Settings\Cut&Paste tab?

I couldn't take it anymore and had to give Tachyon a spin.

Thanks,
Keith

[Peter Jakacki]

I will as soon as I see TachyonFatFiles.fth file posted Speaking of which I wonder just what you are up to with your DE115, P2 image and Tachyon.

I'll let this thread know about the char delay.

EDIT

Just retested my setup and I do infact still need the 1ms char delay.

Well as soon as we get a few people helping with the P2 documentation then I can take a break. It's grueling man.
As much as I'm itching to fire up Tachyon on the P2 FPGA I've just been too bogged down with all these other things. Now I have the job of judging the entries for the Forth of the Forth because I need to have that done in the next day or so. Then I've got my new QVGA display board that I will have to test and write some firmware for the interface chip as well. Then....not P2....but Tachyon will get some more attention as I have some real need at present for FAT32. All this is interleaved with work projects but Tachyon P2 will be up and running soon.

[D.P]

I will as soon as I see TachyonFatFiles.fth file posted Speaking of which I wonder just what you are up to with your DE115, P2 image and Tachyon.

I'll let this thread know about the char delay.

EDIT

Just retested my setup and I do infact still need the 1ms char delay.

[Peter Jakacki]

I use minicom natively on OSX. ZTerm is another option.

And launch it like this using an alias

alias mini='minicom -D /dev/tty.usbserial-0000103D -b 230400' # the last argument being the baud rate. To paste the forth extensions in this terminal at this baud rate you must have a 10ms new line text delay and a 1 ms character text delay. Use (CTRL-a z ) to bring up the options in the terminal.

And you will find your unique device serial port in /dev/tty.usb*

Your problem is your terminal, I'm running this version of Tachyon on multiple devices under multiple OSs, even Windows7 on parallels on my Macbook Pro 10.6.8 using TeraTerm Pro.

I find that I only need the 10ms line delay and no delay at all for characters. Have you tried that? It downloads very fast.

[D.P]

I couldn't take it anymore and had to give Tachyon a spin. I've tried forth a few times and at one point played with some simple machine forth
.
.
.

I'll have to go through this thread and look for tips. e.g. what's a good OS X terminal emulator to use?
.
.
.
Keith

I use minicom natively on OSX. ZTerm is another option.

And launch it like this using an alias

alias mini='minicom -D /dev/tty.usbserial-0000103D -b 230400' # the last argument being the baud rate. To paste the forth extensions in this terminal at this baud rate you must have a 10ms new line text delay and a 1 ms character text delay. Use (CTRL-a z ) to bring up the options in the terminal.

And you will find your unique device serial port in /dev/tty.usb*

Your problem is your terminal, I'm running this version of Tachyon on multiple devices under multiple OSs, even Windows7 on parallels on my Macbook Pro 10.6.8 using TeraTerm Pro.

[Peter Jakacki]

I couldn't take it anymore and had to give Tachyon a spin. I've tried forth a few times and at one point played with some simple machine forth on an FPGA board when playing with computer chess development, but I never really got any good at it.

I was wondering if WORDS is expected to work for the release Tachyon V2.1.spin that's on dropbox. The only things that I changed are the clock rate (from 10 to 5 MHz) and the baud rate.

Thanks,
Keith

Hi Keith, I've neglected Tachyon lately, about time I went over and gave it a bit of a pat then. It's very unusual that your version didn't work so I'll check the dropbox files etc and get to you on this thread. I just use minicom in Linux but Putty should be good too.

BTW, I remembered that I have a WORDS in the precompiled kernel and then I have another one with some enhancements in EXTEND.fth. I'll check them both.

[KeithE]

I couldn't take it anymore and had to give Tachyon a spin. I've tried forth a few times and at one point played with some simple machine forth on an FPGA board when playing with computer chess development, but I never really got any good at it.

I was wondering if WORDS is expected to work for the release Tachyon V2.1.spin that's on dropbox. The only things that I changed are the clock rate (from 10 to 5 MHz) and the baud rate.

Here's an example of what I see:

  Propeller .:.:--TACHYON--:.:. Forth V21121114.1330
 Cold start - no user code - setting defaults
----------------------------------------------------------------
WORDS
6A65: 80 0E 03 DUP
F9FF: C1 D9 08
FA04: CB B4 9A
0000: C4 7E 24 ZbnI
0000: C4 7E 24 ZbnI
0000: C4 7E 24 ZbnI

It keeps printing out the last line over and over. I tried this on both a demo board and quickstart board and saw the same behavior.

I'll have to go through this thread and look for tips. e.g. what's a good OS X terminal emulator to use? Is there a way to connect from an iPad or Nexus 7 tablet? After watching the Ben Heck show where he makes a portable basic computer, it's tempting to buy a large LCD (Alphasmart size) from Ebay and make a little portable forth machine for random lab work.

Right now I'm using Windows XP under VMware on a OS X machine. I'm using Tera Term since I wasn't sure how to transfer files from Hyperterminal if we need to add delays after every line. I found that I needed to convert the line endings before Tera Term can successfully transfer the file EXTEND.fth. One I loaded that I was able to use QWORDS. There were some beeps during download that make me wonder if it was successful. Is there any way to check the integrity of the image?

Thanks,
Keith

[MJB]

Hi Peter,
is my assumtion correct, that SPIN and Tachyon can coexist if some rules are followed?
Like:
- place SPIN code in Tachyon.spin file before the dictionary.
- don't stop the SPIN COG
- from START start your own spin code instead of terminating the COG
- load the serial PASM code into COG7 instead
- for communication between TACHYON and SPIN additional hub 'registers' could be defined
- SPIN code can not easily use the terminal connection since this is used by Tachyon. (haven't checkt the details of communication yet)

[mindrobots]

OK, so Tachyon's more like an Elephant that can't handle its booze. It never forgets unless you take it out and get it (re)loaded!

I can see your point and now I won't forget it, so let's forget we had this discussion!

Thanks!

[Peter Jakacki]

I'm feeling a bit silly about this question but after playing with Tachyon for a good part of the day and reading this thread and looking at the code, I'm thinking it's a bit like my wife! (It's an endearing quality, I assure you!)

Does Tachyon ever FORGET? I can't find a way to FORGET my definitions (remove them from the dictionary in some way) without doing REBOOT. Am I missing something?

I didn't forget to forget, I just didn't forget. Got it?

Because of the way I create vector table entries with each new code entry I just haven't bothered to implement a word that is in my opinion unnecessary. If the code I have loaded is only sitting in RAM then I just hit a ^C or some other reset it so that I can reload again, it only takes a couple of seconds. Alternatively since Tachyon generates very compact code I just load new code over the top of the old.

In the event that I have done a BACKUP then that's different and at present I just load all the modules back in again. Even though this process only takes a few seconds I am looking at ways to lock the modules so that I only need to load the latest module. But once again I don't feel a pressing need to implement a FORGET which proved useful when you had to load from slow floppies and memory was limited as well.

[prof_braino]

I'm feeling a bit silly about this question but after playing with Tachyon for a good part of the day and reading this thread and looking at the code, I'm thinking it's a bit like my wife! (It's an endearing quality, I assure you!)

Does Tachyon ever FORGET? I can't find a way to FORGET my definitions (remove them from the dictionary in some way) without doing REBOOT. Am I missing something?

Let me guess - Is your wife Karen, the same Karen that was Plankton's wife on Sponge Bob?

http://spongebob.wikia.com/wiki/Karen

[mindrobots]

I'm feeling a bit silly about this question but after playing with Tachyon for a good part of the day and reading this thread and looking at the code, I'm thinking it's a bit like my wife! (It's an endearing quality, I assure you!)

Does Tachyon ever FORGET? I can't find a way to FORGET my definitions (remove them from the dictionary in some way) without doing REBOOT. Am I missing something?

[MJB]

some very interresting links
Some interresting links

A Beginner's Guide to Forth (HTML)

Old, text-only version
List of on-line Forth tutorials, with links, other stuff

---

Links to various Forth-related sites

---

The ANS Forth Standard Document

draft v. 6, in HTML format ...in *.zip format

---

Forth system and example programs

[Dave Hein]

I've been working on a smaller kernel for pfth that implements about 50 basic words so it will fit in a cog. It implements an additional 100 ANS Forth words by loading an external Forth program. In theory, the ANS word program can be loaded on any Forth kernel with some modifications. I'll post it in the pfth thread in the next few days.

For me the only way to really learn Forth is to implement a Forth interpreter. I've learned quite a bit by just trying to implement basic ANS words in Forth, such as does>, literal and ['].

[Peter Jakacki]

ANS Forth compliance is not an either or thing. You can be standard's compliant and be fast. In the case of Tachyon, it could just continue to support the current word set plus any ANS core words that it's missing. I'm not saying that Tachyon needs to do this, but I am suggesting that it's possible.

I've looked at ANS many times before and even when it was do'able I still didn't choose to follow it. Now because of the way I have had to structure Tachyon in that it had to be custom carved for a good fit both for the Propeller and the Spin tool, I find there are a lot of redundancies in trying to implement ANS. For starters, I've got 4 stacks, not two, I've got a 12 word deep parameter stack, not 1200, plus I don't have a stack pointer. I could continue with a whole list of things but suffice to say I don't intend to cripple it just to make it standard because it would be useless for me. I wrote Tachyon because I had to and it has met the needs I have for my systems. On P2 I may do something different and maybe even more standard but I can't afford to do the same with the way P1 works.

Now, I am quite happy for you to develop ANS Forth and you have all my source and documentation at your fingertips if you want to avail yourself of any features and we're all Prophead buddies anyway. What I'd like to see though is ANS Forth out on the track to see how it performs. Maybe then I will sit up and take notice.

[Dave Hein]

ANS Forth compliance is not an either or thing. You can be standard's compliant and be fast. In the case of Tachyon, it could just continue to support the current word set plus any ANS core words that it's missing. I'm not saying that Tachyon needs to do this, but I am suggesting that it's possible.

[MJB]

Functions that require locals will not be impacted greatly by this speed reduction as there are other overheads anyway. In the case of the RECT word it spends a lot of time plotting and sending via SPI so using locals makes no discernible difference. So NICE *and* just as FAST.

ok - in this case LOCALS will not be the bottleneck - and in many other cases it does not matter as well.

I notice what seems to be a contradiction here......?

- sorry maybe I was unclear - I was referring to the other threads about ANS compliant Forth's on the Prop.
I think we are in agreement on this topic. better fast, focused on the job and easily adaptable - then necessarily compliant to some standard, that originated from different requirements.

Kernel optimization

when I find time, maybe I do the statistics as an exercise ...

[Peter Jakacki]

then it is not so much of whatever standard, but very intuitive and useful - especially for migrants from other languages
For time critical code putting the LOCALS in HUB will cost some cycles - so the user can then decide NICE or FAST

Functions that require locals will not be impacted greatly by this speed reduction as there are other overheads anyway. In the case of the RECT word it spends a lot of time plotting and sending via SPI so using locals makes no discernible difference. So NICE *and* just as FAST.

I am learning FORTH to program the PROP not for the language itself. So I don't need the ANS-Forth as discussed. My Prop-programs will never be ported to another controller - besides Prop2

btw.
Thinking about kernel optimization <snip>

I notice what seems to be a contradiction here......?

My optimizations are mostly intuitive and I especially target those words that are involved in loops and the loop words themselves. The other thing is that the Prop is very effective at being used for a lot of I/O bit-bashing rather than having specialized peripherals that might not do exactly what you want, hence it's flexibility. This however requires that Forth prove itself fast and efficient in this regard otherwise you end up programming in a mangled form of PASM to supplement Forth or not being able to do it at all. There is no practical gain in following a standard if it proves ineffective in operation and especially is this true in regards to embedded control in conjunction with the Propeller. The standard might be very effective when implemented in 90% of processors but a different standard might be required for the Propeller. If someone wants to be really standard, then don't use a very non-standard Propeller chip.

[Dave Hein]

I've found that one of the biggest time wasters with programming in Forth is trying to keep track of where things are in the stack. I have to scribble notes on paper to list the state of the stack as I progress through a word. Then I have to add a rot, over and sometimes a dup if I need to keep the original value. Occasionally I use pick or roll if the value I need is deeper than 3 entries in the stack. pick is also nice if you need to do an indexed selection from the stack. It's the only way I could figure out how to implement a "jump on zero" word without having an existing conditional jump word.

Most other languages do all this book keeping for you, so you don't have to worry about the stack. I think using local variables in Forth, whether they are on the stack or in registers, is a great improvement.

[MJB]

The "registers" that ITEMS use are in hub RAM and accessed with the REG word as opposed to the COGREG word. The LOCAL variables have been implemented in hub RAM stack which is pushed and popped automatically using CMOVE and new <CMOVE instructions. So I've tested out the nesting to a few levels deep without any problems, I can make the locals stack as deep as I like if I need to.

arghh - of course you're right - my memory mixed TAKE4 with ITEMS - TAKE4 saves the 4 topmost stack items to COG registers, and ITEMS saves n stack items to HUB 'registers'.
should verify before posting ...

You may have noticed that I don't bother with PICK and ROLL instructions as I hate having to mangle the stack in this way, plus it's a headache.

as a Forth newbie I couldn't agree more - even without those keeping track of stack is still the hardest part for me.

There are however the 3RD and 4TH words to directly copy those stack items but any further than 4 levels I try to avoid. The sooner I can implement the stack notation method for local variables, the better. Having them implicitly leave a value rather than having to use @ or anything is just sensible I think and leaving the output parameters as normal stack operations is just practical.

then it is not so much of whatever standard, but very intuitive and useful - especially for migrants from other languages
For time critical code putting the LOCALS in HUB will cost some cycles - so the user can then decide NICE or FAST

I am learning FORTH to program the PROP not for the language itself. So I don't need the ANS-Forth as discussed. My Prop-programs will never be ported to another controller - besides Prop2

btw.
Thinking about kernel optimization I was wondering how to get usage statistics for the byte codes to know which ones to put in first 256 longs, which in second 256 and which in HUB.
Because lexical analysis would not really resemble the dynamic usage patterns.

' Fetch the next byte code instruction in hub RAM pointed to by the instruction pointer IP
'
doNEXT                  rdbyte  X,IP    'read byte code instruction
                        add     IP,#1   'advance IP to next byte token
                        jmp     X       'execute the code

  jmp     X

could jump to high COG space
for the COG-Kernel byte codes a separate HUB array of about 500 longs would hold the counters
kind of

kernelCtr X + C++

in PASM

and for the XCalls increment the high word in the XCALLS vectors (as long as those are not used yet) - and because of only 16bit this is only for short time measurements.
Longer sample times would require longs to store the counters.

xycall                  call    #SETUPIP        ' read offset in table
                        shl     X,#2    ' offset into longs in hub RAM
                        add     X,ACC
                        mov     ACC,#0  ' Always clear ACC to zero ready for reuse
                        rdword  IP,X
                        jmp     #doNEXT

Then a simple DUMP would reveal the usage statistics.

Of course this would slow down the code - so would only be implemented for performance optimization and not for production.

This optimization might not be the most important right now - just wanted to share my thought.

[Peter Jakacki]

my understanding of the was, that you need to exactly know, what you do,
since it uses the registers and those are not managed automatically. So using a function which used ITEMS inside another one which does the same could result in disaster.


with the LOCAL / RELEASE proposal you would need an additional LOCAL-Stack if those words using LOCAL / RELEASE should be nested - right?
If there is a deep nesting this stack could quickly become quite deep.
So the benefit of the COG register based ITEMS approach would suffer.
As with data stack size this probably stongly depends on the usage 'habbits'.

but: the idea using a modified stack comment word is great - and shows the benefits of FORTH, the extensibility of the language - WOW - Try to do this in C ;-) ...

The "registers" that ITEMS use are in hub RAM and accessed with the REG word as opposed to the COGREG word. The LOCAL variables have been implemented in hub RAM stack which is pushed and popped automatically using CMOVE and new <CMOVE instructions. So I've tested out the nesting to a few levels deep without any problems, I can make the locals stack as deep as I like if I need to.

You may have noticed that I don't bother with PICK and ROLL instructions as I hate having to mangle the stack in this way, plus it's a headache. There are however the 3RD and 4TH words to directly copy those stack items but any further than 4 levels I try to avoid. The sooner I can implement the stack notation method for local variables, the better. Having them implicitly leave a value rather than having to use @ or anything is just sensible I think and leaving the output parameters as normal stack operations is just practical.

I can't see a lot of these features being "standard" in any way but then neither is the Prop chip (what! no interrupts!, only 512 longs!!! useless chip I'd say). We nonetheless have fun and get stuff working at the same time.

[MJB]

my understanding of the

ITEMS word

was, that you need to exactly know, what you do,
since it uses the registers and those are not managed automatically. So using a function which used ITEMS inside another one which does the same could result in disaster.

Previously I had used an ITEMS word which simply grabbed the stack parameters and copied them into my general-purpose "register" area, but that was a bit limited. So this has been superseded with the LOCAL and RELEASE word.

with the LOCAL / RELEASE proposal you would need an additional LOCAL-Stack if those words using LOCAL / RELEASE should be nested - right?
If there is a deep nesting this stack could quickly become quite deep.
So the benefit of the COG register based ITEMS approach would suffer.
As with data stack size this probably stongly depends on the usage 'habbits'.

but: the idea using a modified stack comment word is great - and shows the benefits of FORTH, the extensibility of the language - WOW - Try to do this in C ;-) ...

[Peter Jakacki]

Peter, the local variable feature looks good. One of the most frustrating things when programming with Forth is keeping track of the location of things on the stack. pick and roll are useful for accessing values if you know where they are, but local variables make it a lot easier.

So this may not be the final form, I've just fixed a couple of bugs in the code as well. I am looking at using the stack comment to automatically grab the parameters without having to explicitly say 4 LOCAL and 4 RELEASE for instance. So a modified stack comment could be LOCAL( x1 x2 xsize ysize -- ) which would grab the input parameters as local variables (essentially read-only). The exit would be flagged during compile to compile the release code before exit. Perhaps to cover an unstructured exit I could simply call the new word from a wrapper which worries about the LOCAL and RELEASE mechanisms.

[Dave Hein]

Peter, the local variable feature looks good. One of the most frustrating things when programming with Forth is keeping track of the location of things on the stack. pick and roll are useful for accessing values if you know where they are, but local variables make it a lot easier.

[MJB]

Peter: TACHYON 2.1

xLOADMOD            jmp    #_LOADMOD

' 16 longs (or more) are reserved for a selectable module as a helper for specialized functions such as SPI etc.

DAT
        org $01D8    ' fixed address - high-level code can always assume it is here
xRUNMOD
_RUNMOD        res 16

you changed the starting address, but not the size ... I wondered what would be after ... but I assume it is just RUNMOD space. So it should be 24 now ??
Of course makes no big problem here. Just for consistency.
... I do a compare, whenever you post a new version ;-.)
so now my Sigma-Delta Module will fit more easily.
MJB

[Peter Jakacki]

There is a neat little local variable function that I have added which is useful for reading stack parameters. At present they just have simple names such as X1 X2 X3 X4 corresponding to their position on the stack before they were pushed into a local variables area. Previous local variables are moved aside and restored automatically if the function uses the corresponding RELEASE word.

Previously I had used an ITEMS word which simply grabbed the stack parameters and copied them into my general-purpose "register" area, but that was a bit limited. So this has been superseded with the LOCAL and RELEASE word.

Here's how I use it when I draw a rectangle:

\ Draw a rectangle at x1 y1 
pub RECT ( x1 y1 width height -- )
        ( X4 X3 X2    X1 )
    4 LOCAL
    X4 X3 X2 HLINE
    X4 X2 + X3 X1 VLINE
    X4 X3 X1 VLINE
    X4 X3 X1 + X2 HLINE
    4 RELEASE
    ;

Here's how I will eventually use it when I draw a rectangle:

\ Draw a rectangle at x1 y1 
pub RECT ( x1 y1 width height -- )
    4 LOCAL
    x1 y1 width HLINE
    x1 width + y1 height VLINE
    x1 y1 height VLINE
    x1 y1 height + width HLINE
    4 RELEASE
    ;

I only want to use these locals as read only and do all the writing onto the stack so this is only for input parameters at present (where it's really needed).

[D.P]

Did you initialize the SD card first? Use either !SD which returns a parameter or SD which lists the card.

SD 
Card inserted 
MFG:    02
OEM:    TM
PROD:   SD01G
REV:    32
S/N:    1BD7AA9B
DATE:   2007/8
CRC:    33

TACC    500ns
NSAC    0

DOH, yes that would help quite a bit. My card says

0004_C700: 50 4F 50 43 4F 52 4E 20 57 41 56 20 10 59 2A 81   POPCORN WAV .Y*.
0004_C710: 6B 41 6B 41 00 00 A3 50 67 41 02 00 9A 79 31 00   kAkA...PgA...y1.

5.0600 200 XDUMP
0005_0700: 52 49 46 46 92 79 31 00 57 41 56 45 66 6D 74 20   RIFF.y1.WAVEfmt 
0005_0710: 10 00 00 00 01 00 01 00 11 2B 00 00 22 56 00 00   .........+.."V..

So the address is $5.0600, thanks for all the help. Tachyon is moving fast.

[Peter Jakacki]

Did you initialize the SD card first? Use either !SD which returns a parameter or SD which lists the card.

SD 
Card inserted 
MFG:    02
OEM:    TM
PROD:   SD01G
REV:    32
S/N:    1BD7AA9B
DATE:   2007/8
CRC:    33

TACC    500ns
NSAC    0

[D.P]

Ahhh, that's a little trick as I either just write a little scan function or even XDUMP until I see the RIFF header. True. There is my FAT FS code I'm playing with but I need to polish it a bit more yet (when I get a "round tuit").

Try this on a 2GB card as the only file (first off):

4.0000 1.0000 XDUMP
0004_C300: 41 50 00 4F 00 50 00 43 00 4F 00 0F 00 6E 52 00 AP.O.P.C.O...nR.
0004_C310: 4E 00 2E 00 77 00 61 00 76 00 00 00 00 00 FF FF N...w.a.v.......
0004_C320: 50 4F 50 43 4F 52 4E 20 57 41 56 20 00 00 8B 00 POPCORN WAV ....
0004_C330: 68 41 68 41 00 00 41 BB 67 41 03 00 9A 79 31 00 hAhA..A.gA...y1.
0004_C340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

5.8200 200 XDUMP
0005_8300: 52 49 46 46 92 79 31 00 57 41 56 45 66 6D 74 20 RIFF.y1.WAVEfmt
0005_8310: 10 00 00 00 01 00 01 00 11 2B 00 00 22 56 00 00 .........+.."V..
0005_8320: 02 00 10 00 4C 49 53 54 28 00 00 00 49 4E 46 4F ....LIST(...INFO
0005_8330: 49 4E 41 4D 08 00 00 00 50 6F 70 63 6F 72 6E 00 INAM....Popcorn.
0005_8340: 49 41 52 54 0C 00 00 00 48 6F 74 20 42 75 74 74 IART....Hot Butt
0005_8350: 65 72 00 00 64 61 74 61 3E 79 31 00 32 00 58 00 er..data>y1.2.X.
0005_8360: 4D 00 53 00 4F 00 50 00 53 00 4E 00 53 00 4F 00 M.S.O.P.S.N.S.O.
0005_8370: 50 00 53 00 4E 00 52 00 50 00 50 00 51 00 52 00 P.S.N.R.P.P.Q.R.

Remember that XDUMP will skip blank sectors/blocks.
Disregard the block address of 5_8300, it should be even at 5_8200 (I obviously have added a bug into XDUMP)
$5.8200 #6332 #11,050 #P20 PLAY

I have some rubbish problematic 2GB EBAY cards which do not always want to read the next block in time but all my other cards, even the old ones, are fine.


EDIT: I've fixed the XDUMP bug by simply aligning the SD buffer. Try the code sample in the latter half of the source code document, it's only 76 bytes long. Here it is:

Well I did try XDUMP to locate the file before I submitted the last question. It seems all I get on my PNY 2gig disk is a repeating pattern being dumped by XDUMP. I have used SD-MMC_FATEngine.spin on this card/PBOE to make sure the file is readable and I can open and dump it this way as well, I'm just not familiar enough with this driver to find a raw virtual address for the file in question.

EDIT
I was able to dump the SD card using: (sudo dd if=/dev/disk1 of=~/Desktop/output.raw) and able to edit the file with OxED editor but unable to get the correct address I guess. I'm gonna wait for FAT FS to appear. No worries, I'll keep moving forward on other things.

50 4F 50 43 4F 52 4E 2E 77 61 76 POPCORN.wav

[Loopy Byteloose]

Propeller.wikispaces.com is updating its listing and there is section for Forth on the Propeller. You might want to post an entry for Tachyon Forth.

forums.parallax.com/showthread.php?143700-propeller.wikispaces.com-(fixed-and-open-for-business!)

[Peter Jakacki]

{
WAVE PLAYER
11.025kHz 16-bit signed
Reads and plays directly from the SD card using multiple block read mode
Assumes file is non-fragmented (fairly normal for SD cards)
External file system must locate the virtual address and size and pass this to PLAY
RUNMOD is actually the instruction for SPIO (input and output) when the SPIO module is loaded

Notes: Also seems to work fine at 22.050kHz sample rates
}


Peter I'm not sure how to locate the Popcorn.wav file's virtual address on the SD card with ?

Ahhh, that's a little trick as I either just write a little scan function or even XDUMP until I see the RIFF header. True. There is my FAT FS code I'm playing with but I need to polish it a bit more yet (when I get a "round tuit").

Try this on a 2GB card as the only file (first off):

4.0000 1.0000 XDUMP
0004_C300: 41 50 00 4F 00 50 00 43 00 4F 00 0F 00 6E 52 00 AP.O.P.C.O...nR.
0004_C310: 4E 00 2E 00 77 00 61 00 76 00 00 00 00 00 FF FF N...w.a.v.......
0004_C320: 50 4F 50 43 4F 52 4E 20 57 41 56 20 00 00 8B 00 POPCORN WAV ....
0004_C330: 68 41 68 41 00 00 41 BB 67 41 03 00 9A 79 31 00 hAhA..A.gA...y1.
0004_C340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

5.8200 200 XDUMP
0005_8300: 52 49 46 46 92 79 31 00 57 41 56 45 66 6D 74 20 RIFF.y1.WAVEfmt
0005_8310: 10 00 00 00 01 00 01 00 11 2B 00 00 22 56 00 00 .........+.."V..
0005_8320: 02 00 10 00 4C 49 53 54 28 00 00 00 49 4E 46 4F ....LIST(...INFO
0005_8330: 49 4E 41 4D 08 00 00 00 50 6F 70 63 6F 72 6E 00 INAM....Popcorn.
0005_8340: 49 41 52 54 0C 00 00 00 48 6F 74 20 42 75 74 74 IART....Hot Butt
0005_8350: 65 72 00 00 64 61 74 61 3E 79 31 00 32 00 58 00 er..data>y1.2.X.
0005_8360: 4D 00 53 00 4F 00 50 00 53 00 4E 00 53 00 4F 00 M.S.O.P.S.N.S.O.
0005_8370: 50 00 53 00 4E 00 52 00 50 00 50 00 51 00 52 00 P.S.N.R.P.P.Q.R.

Remember that XDUMP will skip blank sectors/blocks.
Disregard the block address of 5_8300, it should be even at 5_8200 (I obviously have added a bug into XDUMP)
$5.8200 #6332 #11,050 #P20 PLAY

I have some rubbish problematic 2GB EBAY cards which do not always want to read the next block in time but all my other cards, even the old ones, are fine.


EDIT: I've fixed the XDUMP bug by simply aligning the SD buffer. Try the code sample in the latter half of the source code document, it's only 76 bytes long. Here it is:

: GetSample ( -- sample )       
      -1 RUNMOD $FF AND -1 RUNMOD $80 + 8 SHL OR
      ;
: WhenReady
      BEGIN -1 RUNMOD -1 <> UNTIL 
      ;
: PLAY ( addr blocks rate pin -- )
      A DUTY APIN                              \ audio dac using counter A in duty mode to pin
      ROT #18 CMD DROP                         \ Issue a multiple block read command with addr
      [SPIO]                                   \ Switch to raw SPI mode
      WhenReady                                \ when SD card is ready
      CLKFREQ SWAP / DELTA                     \ set sample period from rate
      FOR                                      \ for multiple blocks - read samples and update dac counter
        #256 FOR                               \ 256 samples per 512 byte sector 
          GetSample                            \ Get a 16-bit biased sample from the SD card  
          #16 SHL WAITCNT FRQA COG!            \ left justify, synch, then update dac counter 
      NEXT                                   \ next sample
      GetSample DROP                         \ drop the CRC (treat as a sample)
        WhenReady                              \ wait for SD card ready
      NEXT                                     \ next block
      0 #12 CMD DROP                           \ STOP multiple block read
      ;

[D.P]

{
WAVE PLAYER
11.025kHz 16-bit signed
Reads and plays directly from the SD card using multiple block read mode
Assumes file is non-fragmented (fairly normal for SD cards)
External file system must locate the virtual address and size and pass this to PLAY
RUNMOD is actually the instruction for SPIO (input and output) when the SPIO module is loaded

Notes: Also seems to work fine at 22.050kHz sample rates
}


Peter I'm not sure how to locate the Popcorn.wav file's virtual address on the SD card with ?

[Sapieha]

Hi Peter.

Why in v2.1 read.me file You have that version info ?
Latest version: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120814.1230

NA@ was replaced sometime ago with U@ which works a little differently internally in that it uses a CMOVE to a long aligned variable so it's actually faster. The dropbox files have now been updated plus just so we are on the same page I have been using V2.1 of the kernel as this extended the opcodes available with an XOP instruction. The ESPIO module that I use with the display is also part of this kernel and I am working on a suped-up version of this SPI that can run as fast as possible.

[D.P]

Thanks for updating the dropbox and setting me straight version wise. Found one of the new displays your working with for $21.00 US, 10 shipping but still very reasonable for my prototyping.

[Peter Jakacki]

NA@ was replaced sometime ago with U@ which works a little differently internally in that it uses a CMOVE to a long aligned variable so it's actually faster. The dropbox files have now been updated plus just so we are on the same page I have been using V2.1 of the kernel as this extended the opcodes available with an XOP instruction. The ESPIO module that I use with the display is also part of this kernel and I am working on a suped-up version of this SPI that can run as fast as possible.

[D.P]

In the lastest SDCARD.fth the commented pri NA@ word is causing .CARD to not compile obviously. More important is I can't get the wave player to run on my PBOE and can't get the SD card to work any longer using the lastest dropbox files after resolving the feature in the SDCARD.fth file? I've check my card and PBOE with a simple spin program just to make sure the HW is _still working correctly.

\ pri NA@ ( addr -- long )  0 SWAP 4 0 DO C@++ I 2* 2* 2* SHL ROT + SWAP LOOP DROP ;

CREATE tval	
	#00 | #10 | #12 | #13 | 
  	#15 | #20 | #25 | #30 |
	#35 | #40 | #45 | #50 | 
 	#55 | #60 | #70 | #80 |



\ Card information
pub .CARD
\	  CR ." BYTES:  " SDSIZE? .
	  \    0123456789ABCDEF012345
	  CR ." MFG:    " cid C@ .BYTE
	  CR ." OEM:    " cid 1+ 2 TYPE
	  CR ." PROD:   " cid 3 + 5 TYPE
	  CR ." REV:    " cid 8 + C@ .BYTE
	  CR ." S/N:    " cid 9 + NA@ .LONG
	  CR ." DATE:   " cid #13 + C@
	  8 SHL cid #14 + C@ OR
	  DUP 4 SHR #2000 + #10 .NUM
	  ." /" $0F AND #10 .NUM
	  CR ." CRC:    " cid #15 + C@ 2/ .BYTE
	  CR
	  CR ." TACC    " #119 #112 CSD@
	  DUP 3 SHR tval + C@ #10 .NUM
	  3 AND  1- 0 DO ." 0" LOOP ." ns"
	  CR ." NSAC    " #111 #104 CSD@ .

[Peter Jakacki]

I look forward to hearing about your other success with Tachyon but realize the importance of project completion. I admire what seems to be your unstated philosophy of not letting the accidental complexity of the problem (tools, languages, methods...) get in the way of solving the inherent complexity of the issue at hand.

Thanks for this snippet and everything else you have so generously shared.

Thanks for the feedback. Although there seems to be some real interest in Forth being generated and that's a good thing, I've also been hearing a lot of critique about what Forth should be or shouldn't be. This goes against what Forth is and it mightn't please some but for those who love standards the good news is that there are so many to choose from!

Because Tachyon does the things the way it does it gets the job done rather than look pretty in a glossy. Because of it's "short" stack there are some standard words that don't make sense or can't be implemented. Because of it's multiple stacks it's also non-standard. Because Tachyon is written for the Propeller it is the way it is and it is not meant to be ported to another processor. BTW, the short stack has never been a problem in all my applications and it is very robust because it can underflow and overflow without crashing the chip. Error reporting is all very good and well on a PC but you wouldn't want one of your flight-control processors being so helpful and also automatically rebooting when it's a non-fatal soft error would you? That would be fatal.

What the wave player snippet demonstrates is why speed is important (not just bit-bashing) but also the way you go about things too which is what Forth is about, allowing you to explore and test interactively. So this code is a quick hack but it works well whereas any other wave player on the Prop requires PASM, a dedicated cog, and buffer ram to playback the samples. Stripping away all the complexities also reveals that the complexities of a program are mostly from the programmer or more precisely, their way of working out a solution. When I was a very young child my brother and I took my sister's walking doll and hid under the bed while we pulled it apart to see what made it work. Well, we didn't figure that out then but us "boys" will want to pull things apart to see how they work. So it's much easier to do so when all the complexities are stripped away. However, my sister still remembers what we did to her prized doll to this day!

[D.P]

Here's some updated code of the wave player that I've placed onto a webpages version of the Google docs. This version doesn't seem to have any artefacts at 11.025kHz plus I've included a wave file (POPCORN) that you can just copy it onto your SD card (I used 2GB ones) and give it a go. My audio dac is a normal RC network of 220R from the pin to a 0.1uF cap to ground.

So you can play wave files without dedicating 1K for buffers or other variables. It runs in a single non-dedicated cog and the only memory it basically takes up is 88 bytes for the code. You require the standard SDCARD.fth module loaded of course.

I look forward to hearing about your other success with Tachyon but realize the importance of project completion. I admire what seems to be your unstated philosophy of not letting the accidental complexity of the problem (tools, languages, methods...) get in the way of solving the inherent complexity of the issue at hand.

Thanks for this snippet and everything else you have so generously shared.

[Peter Jakacki]

Here's some updated code of the wave player that I've placed onto a webpages version of the Google docs. This version doesn't seem to have any artefacts at 11.025kHz plus I've included a wave file (POPCORN) that you can just copy it onto your SD card (I used 2GB ones) and give it a go. My audio dac is a normal RC network of 220R from the pin to a 0.1uF cap to ground.

So you can play wave files without dedicating 1K for buffers or other variables. It runs in a single non-dedicated cog and the only memory it basically takes up is 88 bytes for the code. You require the standard SDCARD.fth module loaded of course.

[Peter Jakacki]

I haven't been able to share my Tachyon applications because they are commercial but suffice to say that Tachyon is working extremely well in this regard. But I haven't any time to discuss what the language should or should not be as I am too busy busting bits n bytes with Tachyon to create new applications.

What I can do for the brave hearted is give you this tiny bit of code that is a one word 16-bit signed wave player. It only uses the one cog for reading the SD card and playing at the same time. There are no special words or kernel enhancements, just Tachyon as it is. because it runs straight from SD card you don't even need buffers. I've tested this to 22.050kHz and given the rough bit of code that it is it runs extremely well.

TACHYON

{
WAVE PLAYER 
11.025kHz 16-bit signed
Reads and plays directly from the SD card using multiple block read mode
Assumes file is non-fragmented (fairly normal for SD cards)
External file system must locate the virtual address and size and pass this to PLAY
RUNMOD is actually the instruction for SPIO (input and output) when the SPIO module is loaded

Notes: Also seems to work fine at 22.050kHz sample rates
}


LONG rate

: PLAY ( addr blocks rate pin -- )
    A DUTY APIN            \ audio dac
    CLKFREQ SWAP / rate !
    SWAP #18 CMD 0=            \ Issue a multiple block read command
      IF RES@ #datatkn =        \ when ready
        IF [SPIO] 8 SDCNT        \ ensure the bit count is 8 for byte transfers 
          FOR
          rate @ DELTA        \ reset play period ( slight delay because of reading end of block crc etc)
          $100 FOR -1 RUNMOD $FF AND -1 RUNMOD $80 + 8 SHL OR #16 SHL WAITCNT FRQA COG! NEXT
          -1 RUNMOD -1 RUNMOD 2DROP
          BEGIN -1 RUNMOD $FF AND $FF <> UNTIL    \ wait for SD card
          NEXT
        THEN
     THEN
    0 #12 CMD DROP
    ;

END

\ Demo - play a file located at $18.0000 for 3000 blocks @ 11.025kHz on P20
!SD
$18.0000 #3000 #11,025 #P20 PLAY

EDIT: If you are only running at 11.025kHz you can move the line "rate @ DELTA" to just before the "FOR" instruction and it will be very smooth playing.

[Peter Jakacki]

how much memory per thread do you estimate, and where will the context be saved? sal did software multitasking early on in propforth, but removed it as toocostly. now we are talking about adding it again, in preparation for prop2 and other experiments. we are talking about the PAUSE round robin from traditional forth, is this wha t you are doing using EXIT?

Multi-tasking uses a cog per task which is how you really want it so there is no need for any scheduling since they are all running concurrently, not sequentially. However the interrupts are very low overhead and allow a task (cog) to be interrupted in a timely fashion normally just to do something short and sweet.

Here are the two code fragments:

            '''
EXIT                 mov    R0,interrupts wc,wz
     if_nc_and_nz    jmp    #INTERRUPT    'service interrupts before restoring IP from return stack
                     call    #RPOPX
                     mov    IP,X
                     jmp    #doNEXT        


INTERRUPT            mov    R1,#@intvecs+s-4    ' point to interrupt vectors in hub ram (low address)
scanirqs             shr    R0,#1 wc,wz    ' test next irq bit (with a safety fence)
                     add    R1,#2    ' point to next word vector
    if_nc_and_nz     jmp    #scanirqs
                     or    interrupts,msb    ' set inhibit
                     rdword    IP,R1    ' read in external vector
                     jmp    #doNEXT    ' and execute  (no need to save IP as it's not yet restored)
    

[prof_braino]

All this talk about multi-threading in another thread (hey, this is multi-threading!) reminded me to add my interrupt processing to the VM. Virtual interrupts are checked whenever an EXIT instruction is executed but before the instruction pointer is restored (just like a conventional return from subroutine). Up to 31 interrupt sources may be used each with an associated vector in hub RAM. I am still playing with this although it works as is but I am thinking of adding cog context switching where I can push and pop the cog's stacks etc to hub RAM and back. You can also trigger the interrupt from PASM so that another cog such as a CAN or USB bus device can initiate high-level functions.

how much memory per thread do you estimate, and where will the context be saved? sal did software multitasking early on in propforth, but removed it as toocostly. now we are talking about adding it again, in preparation for prop2 and other experiments. we are talking about the PAUSE round robin from traditional forth, is this wha t you are doing using EXIT?

[Peter Jakacki]

All this talk about multi-threading in another thread (hey, this is multi-threading!) reminded me to add my interrupt processing to the VM. Virtual interrupts are checked whenever an EXIT instruction is executed but before the instruction pointer is restored (just like a conventional return from subroutine). Up to 31 interrupt sources may be used each with an associated vector in hub RAM. I am still playing with this although it works as is but I am thinking of adding cog context switching where I can push and pop the cog's stacks etc to hub RAM and back. You can also trigger the interrupt from PASM so that another cog such as a CAN or USB bus device can initiate high-level functions.

[Peter Jakacki]

I rebuilt my TF load from COLD and applied your latest "1wire.fth" and then my extensions, "1WIREBBR.fth" on top of that sans my patches for 1W@. All OK nothing broken ... thank you!

Thanks Brian, I thought it was still a WIP until you said it all worked! I've changed the write routines to force the bus high to power any devices that rely on parasitic power. Your routines have also been incorporated in 1-Wire.fth with a few little changes.

Here's a test of a 18B20 temperature chip (warmed, cooled, then placed next to my i7 laptop's vent):
SHOWTEMPS
+036.81'C ************************************
+036.62'C ************************************
+036.06'C ************************************
+035.68'C ***********************************
+034.62'C **********************************
+034.68'C **********************************
+034.25'C **********************************
+033.31'C *********************************
+032.87'C ********************************
+032.50'C ********************************
+032.81'C ********************************
+033.12'C *********************************
+033.25'C *********************************
+033.31'C *********************************
+033.43'C *********************************
+033.50'C *********************************
+033.68'C *********************************
+033.68'C *********************************
+033.62'C *********************************
+032.87'C ********************************
+031.62'C *******************************
+031.00'C *******************************
+028.12'C ****************************
+026.62'C **************************
+026.31'C **************************
+025.81'C *************************
+024.43'C ************************
+024.18'C ************************
+022.37'C **********************
+021.68'C *********************
+021.81'C *********************
+022.18'C **********************
+022.50'C **********************
+023.18'C ***********************
+023.93'C ***********************
+024.62'C ************************
+025.18'C *************************
+025.62'C *************************
+026.06'C **************************
+026.68'C **************************
+027.93'C ***************************
+029.00'C *****************************
+029.81'C *****************************
+030.50'C ******************************
+029.18'C *****************************
+028.31'C ****************************
+029.56'C *****************************
+031.68'C *******************************
+033.43'C *********************************
+034.81'C **********************************
+036.18'C ************************************
+037.50'C *************************************

<snip>
+054.62'C ************************************************** ****
+054.68'C ************************************************** **** ok

[Brian Riley]

Just starting to play with 1-Wire stuff again and I noticed quite a few mistakes in my code. First off I noticed that the 1W@ was assembling the byte back-to-front in that it was left shifting the bits in, didn't you notice! I was also driving the line high with an OUTSET instruction rather than letting it float using INPUTS.

This is a READROM from an 18B20 which matches the family code:
READROM 28 AE 68 24 03 00 00 E4
So I will play with it a bit more today and see how it goes.

I rebuilt my TF load from COLD and applied your latest "1wire.fth" and then my extensions, "1WIREBBR.fth" on top of that sans my patches for 1W@. All OK nothing broken ... thank you!

[Peter Jakacki]

Just starting to play with 1-Wire stuff again and I noticed quite a few mistakes in my code. First off I noticed that the 1W@ was assembling the byte back-to-front in that it was left shifting the bits in, didn't you notice! I was also driving the line high with an OUTSET instruction rather than letting it float using INPUTS.

This is a READROM from an 18B20 which matches the family code:
READROM 28 AE 68 24 03 00 00 E4
So I will play with it a bit more today and see how it goes.

[Peter Jakacki]

Well I still can't figure out what is causing and how its doing it the read-1wire-byte, "1W@" to receive the bits in proper order in proper order but write them out in reverse. Needless to say nothing in 1 Wire works quite right with this function compromised(Sorry Peter!).

In the meantime I wrote a not so quick and oh-so-dirty kluge that brute force puts the bits in the proper order. It is called FIX1W@ ... please don't laugh too hard ... remember it breaks nothing and allow one-wire to move forward while Peter tries to find time to solve the bug.

The bug patch call is a I sIngle word call as the last line in 1W@.

The file I attached is Peter's original code with FIX1W@ and the patched 1W@ and appended to the end is my 1-W extensions.

Hi Brian, I'm looking into it today so hang tight, I just never got around to doing anything more with this code at the time.

[Brian Riley]

Well I still can't figure out what is causing and how its doing it the read-1wire-byte, "1W@" to receive the bits in proper order in proper order but write them out in reverse. Needless to say nothing in 1 Wire works quite right with this function compromised(Sorry Peter!).

In the meantime I wrote a not so quick and oh-so-dirty kluge that brute force puts the bits in the proper order. It is called FIX1W@ ... please don't laugh too hard ... remember it breaks nothing and allow one-wire to move forward while Peter tries to find time to solve the bug.

The bug patch call is a I sIngle word call as the last line in 1W@.

The file I attached is Peter's original code with FIX1W@ and the patched 1W@ and appended to the end is my 1-W extensions.

[Brian Riley]

First, let's READ the ROM ID and the SCRATCHPAD that has NOT been commanded to measure TEMP

RD1ROM 00010100 11011100 00111011 10110010 11000000 00000000 00000000 10110111
 ok
RD1SCR 00001010 10100000 11010010 01100010 11111110 11111111 00110000 00001000 00111000
 ok

1st byte of ROMID should be $28 but it's $14. Enter the bits of that byte in reverse order and "." it. What do we get ... $28 !!!

1st 2 bytes of an idle SCRATCHPAD are supposed to be $50 and $05 ... same drill, again ... type them in in reverse bit order and dump the stack ... we get $05 and $50

%00101000 . 28 ok
%01010000 %00000101 .S
STACK: 00005D97 00005D0A 00000050 00000005  ok

Simply READ and compute the temperature ... what!! That cannot be!

T2 +062.87 degrees C
 ok

Go right back and READ the TEMP and binary dump SCRATCHPAD. Enter the LSB and then the MSB as before in reverse bit order, execute the second half of GETTEMP, joining the LSB and MSB in one long on stack, then call PRINTTEMP to finish the job ... 23 degrees C is nominally accepted as "room temp."

T3 11101110 10000000 11010010 01100010 11111110 11111111 10010000 00001000 11110110
 ok
%01110111 %00000001  ok
8 SHL + .S
STACK: 00000005 00000005 00000050 00000177  ok

PRINTTEMP +023.43 degrees C
 ok

I think it is pretty conclusive that "1W@" is the culprit and it needs to write the bits in reverse order!

[Brian Riley]

Left to my own devices sooner or later I latch onto a clue. It was unfortunate that the 'clue' was $14 that should have been $28 ... you can get there two ways, a lost/dropped bit ORRRRR reversed order in the byte ... to make a long story short, "1W@" is reading the bits right but placing the bits into the byte in the reverse order. I got this by displaying binary and looking for hard coded numbers in ROM ID and the SCRATCHPAD.

Here's my additions to the toolbox that let me read temps and IDs etc

TACHYON

: 1WIREbbr.fth        ." 1-wire interface BBR additions 121019:1530 " 

\ -------------------------------------------------------------------

: READROM	( -- )	$33 1W!	;	\ command to read ROM ID
: SKIPROM   ( -- )	$CC 1W! ;	\ when only one device online responds without MATCHROM
: MATCHROM   ( -- )	$55 1W! ;	\ command to match an ID to a specific device
: CONVERTT	( -- )	$44 1W! ;	\ commands all Temp sensors to start measurement (750 ms)
: READSCR	( -- )	$BE 1W!;	\ dumps 9 bytes (8 plus CRC) of device scratchpad

: GETBYTES	( bytecnt -- )	 FOR 1W@ $0802 .NUM SPACE NEXT CR ;

: RD1ROM	( -- ) 1WRESET DROP READROM 8 GETBYTES ;
: RD1SCR	( -- ) 1WRESET DROP SKIPROM READSCR 9 GETBYTES ;


: GETTEMP	 ( -- temp )			
					READSCR	
					1W@ 1W@  8 SHL +
					;
					
: PRINTTEMP	  ( temp -- )
		
					DUP $0F AND SWAP 4 SHR	\ put whole degrees in one long and fraction in another 
					$830A .NUM				\ print whole number
					"." EMIT				\ print decimal point
					#100 * #16 /			\ turn binary bits to 100ths
					$020A .NUM				\ print decimal
					."  degrees C  " CR
					;
					

: T2	( -- )		\ reads annd displays a single DS18B20 alone on a 1-W buss
		1WRESET DROP SKIPROM CONVERTT 750 ms
		1WRESET DROP SKIPROM GETTEMP  PRINTTEMP
		;

: T3	( -- )		\ reads annd displays a single DS18B20  SCRATCHPAD alone on a 1-W buss
		1WRESET DROP SKIPROM CONVERTT 750 ms
		1WRESET DROP SKIPROM RD1SCR
		;

END

[Peter Jakacki]

shouldn't endofkernel go directly after marker to give the right amount of free kernel COG size?

7C58(01D6) 24 00 00 00 | Xptr            long @XCALLS+s                          ' used by XCALL
7C5C(01D7) 00 00 00 00 | marker          long 0[4]
7C6C(01DB)             |                 org tos
7C6C(01A8)             | sdat            res 1
7C6C(01A9)             |                 org REG0
7C6C(01CE)             | sck             res 1
7C6C(01CF)             | mosi            res 1
7C6C(01D0)             | miso            res 1
7C6C(01D1)             | pixshift
7C6C(01D1)             | scnt            res 1
7C6C(01D2)             | pixeladr                res 1
7C6C(01D3)             | endofkernel             res 0   ' just a marker to indentify the end of the kernel in the listing (BST)
7C6C(01D3)             |                 res 0

endofkernel is a leftover and unused symbol from an earlier version but the important address if it was used is it's address in hub RAM (7C6C), not the address in cog RAM. So moving the symbol would not change this address anyway.

[Peter Jakacki]

Hi Peter,
playing with unmodified TY I get this:

Propeller .:.:--TACHYON--:.:. Forth V20121013.1530
1780: EXTEND.fth          Primary extensions to TACHYON kernel - 121012.2300


  ok


1 2 3 4 5 6 7 8 9 10 11 12 13 14 . . . . . . . . . . . . . . . 14131211109870000000 ok
  ok


1  ok
2  ok
3  ok
4  ok
5  ok
6  ok
7  ok
8  ok
9  ok
10  ok
11  ok
12  ok
13  ok
14  ok


DATA STACK
01A8: 000001A8 00000014 00000013 00000012
01AC: 00000011 00000010 00000009 00000000
01B0: 00000000 00000000 00000000 00000000
RETURN STACK

Terminal interaction uses the stack too so this always has to be taken into account. If a Forth is to be judged on the depth of it's stack then Tachyon probably is on the bottom of that stack! Like the philosophy of RISC where decisions are made to remove the complexity and run lean and mean so too there is a philosopy behind Tachyon vs conventional Forths which drive the decisions made. First off, the Prop is not real good with addressing stacks and there is not a lot of room in cog RAM to spare and hub RAM is too slow. Plus there has always been the problem with Forth with addressing items more then 3 or 4 levels deep. The decision therefore is to use cog RAM but for the individual VM instructions to run unimpeded by any stack somersaults the stack items need to be in a fixed place. So keep them fixed and move all the contents around when it comes to pushing and popping. But this is costly in terms of processor cycles etc so once again design the kernel in such a way that stack usage could be minimized etc.

So this brings us to your test which as mentioned earlier is flawed because you assume it's deeper than it is and you don't take into account stack usage just for handling terminal interaction and printing etc. Also the DEBUG word is high level so it must use the stack also although it's use is minimized. My very early Tachyon had the debugger in PASM and it could list everything perfectly without using the stack etc. But alas there is no way to have the machine level debugger and a Tachyon VM plus stacks etc resident in 496 longs.

The test for the stack handling should therefore be made from within a definition (or on a single line) and stack usage should be minimized. The data stack is only 12 longs deep so this is my simple version:
: N CR .BYTE ; ok
ok
: T 12 23 34 45 56 67 78 89 90 91 82 73
N N N N N N N N N N N N ; ok
T
73
82
91
90
89
78
67
56
45
00
00
00 ok

Notice that it seems to go 9 levels deep before it "loses" the first 3 items. That's because up to 3 items were pushed on top of the stack losing the first 3 items that were there and then subsequent popping results in zeros filling those voids. The zeros are popped into the most bottom level of the stack mainly for error checking but serve no other useful purpose.

How useful is a shallow stack? Well when combined with useful VM instructions which also use other stacks and fixed cog registers the results are very good. I've written working turn-key applications in Tachyon that testify to the workability of the approach taken to an embedded Forth that works in harmony with the Prop's unique architecture.

Would I love more cog RAM? You betcha! But that ain't ever going to happen, however P2 will have a lot of enhancements that Tachyon will exploit to the max, but that's next year.

[MJB]

Hi Peter,
playing with unmodified TY I get this:

Propeller .:.:--TACHYON--:.:. Forth V20121013.1530
1780: EXTEND.fth          Primary extensions to TACHYON kernel - 121012.2300


  ok


1 2 3 4 5 6 7 8 9 10 11 12 13 14 . . . . . . . . . . . . . . . 14131211109870000000 ok
  ok


1  ok
2  ok
3  ok
4  ok
5  ok
6  ok
7  ok
8  ok
9  ok
10  ok
11  ok
12  ok
13  ok
14  ok


DATA STACK
01A8: 000001A8 00000014 00000013 00000012
01AC: 00000011 00000010 00000009 00000000
01B0: 00000000 00000000 00000000 00000000
RETURN STACK

[MJB]

shouldn't endofkernel go directly after marker to give the right amount of free kernel COG size?

7C58(01D6) 24 00 00 00 | Xptr            long @XCALLS+s                          ' used by XCALL
7C5C(01D7) 00 00 00 00 | marker          long 0[4]
7C6C(01DB)             |                 org tos
7C6C(01A8)             | sdat            res 1
7C6C(01A9)             |                 org REG0
7C6C(01CE)             | sck             res 1
7C6C(01CF)             | mosi            res 1
7C6C(01D0)             | miso            res 1
7C6C(01D1)             | pixshift
7C6C(01D1)             | scnt            res 1
7C6C(01D2)             | pixeladr                res 1
7C6C(01D3)             | endofkernel             res 0   ' just a marker to indentify the end of the kernel in the listing (BST)
7C6C(01D3)             |                 res 0

[Brian Riley]

PETER,

MEANWHILE, ON ANOTHER TANGENT ... I was working with your One-Wire code today. I took your suggestion and made "1WRESET DROP READROM" into a WORD "RD1ROM" I used it to read device IDs on a bunch of DS18B20s. Your READROM word or one of its support words is dropping a bit. Every one of my DS18B20s showed a device code of $14 instead of $28.

RD1ROM 14 AB BD B2 C0 00 00 D0  ok
  ok
RD1ROM 14 DC 3B B2 C0 00 00 B7  ok

I have attached a copy of your 1 wire file with almost a dozen words appended to the end that should prove useful. Look at GETTEMP and see if you can figure why the two "1W@" always read all "F"s in my routine but gets realistic reads in your READROM.

T1
STACK: 00000000 00000000 0000000F 00000FFF +095.93 degrees C

Now to rummage through my backups and find my working spin code for 1--w ... failing that I may have to rummage in my [gasp!] Arduino stuff!

[Peter Jakacki]

I reconstructed the exact same TF build on one of my new Propeller Platform Through Hole boards, which is uses the non-integral USB Prop Plug. After setting "AUTORUN MAINLOOP3 BACKUP" I simply removed the Prop Plug and hit the Reset button. MAINLOOP3 came up and ran perfectly.

AT this point the TxD and RxD were hanging empty, 'floating at TTL level.' As I said in my initial message on this matter I have some vague recollection of this problem. After further ruminations I am convinced its not TF's fault. The problem seems to lie in boards with built in USB.

Hi Brian, did you try commenting out that line in the serial Rx routine? However I suspect that the problem is with the way the USB chip is connected and that it also controls the reset line. A lot of these USB chips draw their power from the USB bus and so when it's unplugged the chip isn't directly powered. However the Txd line from the Prop is normally high and this feeds through the USB chip's substrate back into it's power and has a tendency to kick it into life after which it resets the Prop and so on ad infinitum. The simple solution for this is to simply have a current limit resistor from the Prop's Tx pin into the USB chip so that it can never draw enough power to kick in. There are variations on these solutions but that's a simple one. Try a value of 10K.

[Brian Riley]

I reconstructed the exact same TF build on one of my new Propeller Platform Through Hole boards, which is uses the non-integral USB Prop Plug. After setting "AUTORUN MAINLOOP3 BACKUP" I simply removed the Prop Plug and hit the Reset button. MAINLOOP3 came up and ran perfectly.

AT this point the TxD and RxD were hanging empty, 'floating at TTL level.' As I said in my initial message on this matter I have some vague recollection of this problem. After further ruminations I am convinced its not TF's fault. The problem seems to lie in boards with built in USB.

[Peter Jakacki]

I have some code that works perfectly when tethered to the Mac by the USB, but appears to never get started untethered.

The Setup

Tachyon Forth 121013 - latest EXTEND and SDCARD
my JMSERVO2.fth

Prop BOE mounted on a BOEBOT

The errant code - a short script to see how the maneuvers actually look on the ground.
This code was copy pasted in and followed by

AUTORUN MAINLOOP3 BACKUP

The bot was set on a stand to keep the wheels off he desk. It was powered up with no power to the servos. It appeared to run oK. There is an LED commanded on in the background task "SERVOS."

Repeated with power to servos. They ran, they appeared to follow the script and did loop and repeat.

Shut bot down.. disconnected wall power, plugged in 6v battery pack and removed USB cable.

Put bot on floor, powered up BOE and servos ====> nada, zilch, NOTHING ... no LED from "ON SERVOS," no servos running

Pickup bot, plug in USB and "back in business!"

I have a vague recollection of this problem elsewhere ... what am I missing ?????????

: MAINLOOP3
    SVZRO            \ start with all servos disabled
    #8 seconds  
    ON SERVOS
    #2 seconds

    BEGIN
        STRAIGHT 5 seconds
        BACK 4 seconds
        ROTLFT 500 ms
        ROTRT  500 ms
        ROTLFT 2 seconds
        STRAIGHT 4 seconds
        ROTLFT 2 seconds
        STRAIGHT 4 seconds
        CRVLFT 2 seconds
    KEY? AND UNTIL                     \ HIT CR  to break loop
    OFF SERVOS
    ;

Just an idea but your loop terminates with any key which is not a real good idea for a turn-key app. Test for <esc> or something instead as the receive pin may be being pulled low by the disconnected USB and that's sending nulls through the port. This could also trigger a break condition which will reboot the Prop but my serial driver also checks for a floating input by pulsing the receive line high for a microsecond then checking to see if it's stayed high (floating input) or still low (driven). If you can't do anything about the break condition because of your hardware then better disable it by commenting out the second line:
RxLoop call #receive
if_nc jmp #abreak ' discard if framing error (no stop bits)

I may add a little extra checking on the serial driver to see if I can automatically disable the break detect in these circumstances.

[Brian Riley]

I have some code that works perfectly when tethered to the Mac by the USB, but appears to never get started untethered.

The Setup

Tachyon Forth 121013 - latest EXTEND and SDCARD
my JMSERVO2.fth

Prop BOE mounted on a BOEBOT

The errant code - a short script to see how the maneuvers actually look on the ground.
This code was copy pasted in and followed by

AUTORUN MAINLOOP3 BACKUP

The bot was set on a stand to keep the wheels off he desk. It was powered up with no power to the servos. It appeared to run oK. There is an LED commanded on in the background task "SERVOS."

Repeated with power to servos. They ran, they appeared to follow the script and did loop and repeat.

Shut bot down.. disconnected wall power, plugged in 6v battery pack and removed USB cable.

Put bot on floor, powered up BOE and servos ====> nada, zilch, NOTHING ... no LED from "ON SERVOS," no servos running

Pickup bot, plug in USB and "back in business!"

I have a vague recollection of this problem elsewhere ... what am I missing ?????????

: MAINLOOP3
	SVZRO			\ start with all servos disabled
	#8 seconds  
	ON SERVOS
	#2 seconds

	BEGIN
		STRAIGHT 5 seconds
		BACK 4 seconds
		ROTLFT 500 ms
		ROTRT  500 ms
		ROTLFT 2 seconds
		STRAIGHT 4 seconds
		ROTLFT 2 seconds
		STRAIGHT 4 seconds
		CRVLFT 2 seconds
	KEY? AND UNTIL					 \ HIT CR  to break loop
	OFF SERVOS
	;

[Peter Jakacki]

One major difference between PF and TF has been that TF permits looped structures from the command line and PF does not!

Also, from the beginning, could not parse input in the form "-123" , but that can be gotten around by typing "123 NEGATE"

Regarding the negative number input I did finally get a round tuit a little while back. It only took a couple of minutes to add the extra checking along with all the other prefix and suffix stuff that I do. BTW, the latest kernel will process anything that starts with # or $ or % and ends in a digit as a number rather than search the dictionary. This speeds up compilation but you might get caught as my L6470.fth source had some #cs1 and #cs2 constants etc which were being interpreted as 1 and 2 rather than the defined constant! Of course I just renamed these constants.

[Peter Jakacki]

While reading in 'Starting Forth' (thanks Peter, for the link)
I was typing some examples into Tachyon.


this:

-10 0 DO I . -1 +LOOP

did not work.

<snip>

A nice example of the extensability of a Forth system.
Especially if all the source is available ... Thanks Peter ...

The TERMINAL definition is a bit long at present and I will get around to factoring the functions out so for one thing it will make it very easy to patch a specialized parser into a precompiled kernel. Talking about getting "a round tuit" there are little things like you came across with negative numbers in a loop for instance that I would get around to it eventually. Funny thing is I can't ever recall using negative indices in a loop before but I'm sure it would come in useful. I think I normally keep it positive and simply subtract the index from an offset.

Thanks for the code, I will get "a round tuit" later

[Brian Riley]

One major difference between PF and TF has been that TF permits looped structures from the command line and PF does not!

Also, from the beginning, could not parse input in the form "-123" , but that can be gotten around by typing "123 NEGATE"

[Peter Jakacki]

It looks like you are calling the loop words from the command line with out encapsulating them in a definition.
I don't know it this matters, but I don't think the branching functions are supposed to work from the command line, they are only supposed to be used within a word definition.

I think it was something about the way they use the return stack, you could get things out of whack if you did the wrong word in between.

Since I detest having Forth work differently from the command line I have made Tachyon compile before execute on the command line. So anything that you can do from within a definition you can do on the command line without any special words plus the timing is identical.

It also compiles word by word so once you've typed that word in and entered a space etc you can't go back. So if you make a mistake after that you need to discard the line with an <esc> key. Sometimes that's a nuisance but tolerable. I may make that part of it selectable in the future though.

[prof_braino]

-10 0 DO I . -1 +LOOP

did not work.

It looks like you are calling the loop words from the command line with out encapsulating them in a definition.
I don't know it this matters, but I don't think the branching functions are supposed to work from the command line, they are only supposed to be used within a word definition.

I think it was something about the way they use the return stack, you could get things out of whack if you did the wrong word in between.

[MJB]

While reading in 'Starting Forth' (thanks Peter, for the link)
I was typing some examples into Tachyon.


this:

-10 0 DO I . -1 +LOOP

did not work.


So I started digging ... to find out why.
And ... added the functionality to the kernel.
Takes 3 longs in COG - If one wants to sacrifice this ...
I am still very new to Prop and Forth ... so I hope I did
not break s.th. else.


A first version of my parser to handle a legacy
command syntax is also working (http://forums.parallax.com/showthrea...83#post1128483)
- and integrated to the TACHYON Terminal code.
Quite a challenge - and fun.

with the definition

 : SUP ( U I -- )
    ." !SUP " SWAP .DEC BL EMIT .DEC ;

the input string:

 !SUP1000;250

is properly converted to

 1000 250 SUP

pushed back on front of the rxbuffer and
Forth takes care of the rest and evaluates it.


A nice example of the extensability of a Forth system.
Especially if all the source is available ... Thanks Peter ...

[Peter Jakacki]

Hi Peter,
with last version long 20121013,1530
on Spin-Tool 1,2,6
I get Error: Address is out of range at line: 1688
in Terminal at:
un00 byte XCALL,xSPACE,REG,wordbuf,XCALL,xPSTR ' Spit out offending word
byte _WORD,$02,14,(EMIT),_ELSE,@un04-@un03

EMIT is highlighted ...

previous versions run wonderfully ...
while new to FORTH I learn a lot reading your souce code ... thanks a lot for sharing
MJB Markus from Germany

That's a strange one. The _EMIT word is named (EMIT) in the compiled dictionary only yet BST is quite happy to compile _EMIT in it's place even though I obviously have made a mistake in typing (EMIT).

1652(0049) 6D          |          byte        _WORD,$02,14,(EMIT),_ELSE,@un04-@un03     
1653(0049) 02          |                                                                
1654(004A) 0E          |                                                                
1655(004A) F0          |                                                                
1656(004A) C2          |                                                                
1657(004A) 09          |                                                                

vs the correct version

1652(0049) 6D          |          byte        _WORD,$02,14,_EMIT,_ELSE,@un04-@un03
1653(0049) 02          | 
1654(004A) 0E          | 
1655(004A) F0          | 
1656(004A) C2          | 
1657(004A) 09          |

So just correct that by typing _EMIT instead while I ponder over this mystery.

[Peter Jakacki]

PETER,

How does one 'cancel' an AUTORUN?


If I type "AUTORUN FOO" on the next and subsequent REBOOT, hardware reset, power-on reset TF will search for and execute FOO. If I then type "AUTORUN BAR" FOO is out and now AUTORUN looks for BAR.... what do I type to stop AUTORUN altogether?

Just AUTORUN CANCEL
In fact you can use any word that does not exist as this will always return with a null. To cancel it from code just access it's variable directly:
autorun W~

[Brian Riley]

PETER,

How does one 'cancel' an AUTORUN?


If I type "AUTORUN FOO" on the next and subsequent REBOOT, hardware reset, power-on reset TF will search for and execute FOO. If I then type "AUTORUN BAR" FOO is out and now AUTORUN looks for BAR.... what do I type to stop AUTORUN altogether?

[MJB]

Hi Peter,
with last version long 20121013,1530
on Spin-Tool 1,2,6
I get Error: Address is out of range at line: 1688
in Terminal at:
un00 byte XCALL,xSPACE,REG,wordbuf,XCALL,xPSTR ' Spit out offending word
byte _WORD,$02,14,(EMIT),_ELSE,@un04-@un03

EMIT is highlighted ...

previous versions run wonderfully ...
while new to FORTH I learn a lot reading your souce code ... thanks a lot for sharing
MJB Markus from Germany

[Peter Jakacki]

Another tweak of the dictionary search routines has made compilation speeds even faster.
Testing at 230,400 baud and 6ms line delay.

EXTEND.fth = 11.6 seconds
SDCARD.fth = 4.9 seconds
L6470.fth = 5.35 seconds

I'm thinking about how best to access the dictionary in SD as although 1K could be paged in every 5ms (without optimization) you wouldn't want to do that for every word that's searched. So I was thinking perhaps that when I read it in and find a match that I then add it to my dictionary cache in RAM. This cache could be flushed at the end of a source code load and it wouldn't matter if the whole dictionary was held in SD. This would free up around 4 to 8K of RAM and simply rely on the SD buffers. BTW, EEPROM is way too slow. The SD search method would only be implemented if the SDCARD.fth extensions have been loaded and the option selected otherwise everything will just run as it does now.

[Brian Riley]

I really appreciated finding this page. The 'one' item that no one seems to have is a PDF version of Starting Forth by Leo Brodie, and yet it is very worthwhile.

Since one can't download it, you either have to buy an out of print copy or read it on-line. Fortunately, Forth, Inc. has it in the original format.

http://www.forth.com/starting-forth/sf1/sf1.html

I find out that while so much of Forth has been generously shared with the public domain, this one book has become rather protected. If you can find it used, the second edition published 1987 by Prentice Hall is supposed to be the best.

... and thanks to Peter's link to an SF in PDF, my Forth Resources Directory now has filled this hole in its catalog.

[Loopy Byteloose]

There's a pdf of the online version of Starting Forth here.
I have just found an old copy in reasonable condition which I have ordered just for nostalgia (loved that book). I used to have about 3 copies but you know how people are when they say "just want to borrow it for a day or two...bring it right back..."

Thanks, I don't have to pay for wifi in Starbucks to read it on my notebook.

AbeBooks.com has several copies available of both first and second editions, along with several other Forth classics. Prices range from under $5 to over $100USD.

Reading Starting Forth really makes moving on to Brodie's other later book Thinking Forth, much easier.

[Peter Jakacki]

There's a pdf of the online version of Starting Forth here.
I have just found an old copy in reasonable condition which I have ordered just for nostalgia (loved that book). I used to have about 3 copies but you know how people are when they say "just want to borrow it for a day or two...bring it right back..."

[Loopy Byteloose]

Funny you should mention this. I just today added that article to my "Fort Resources" directory http://www.wulfden.org/downloads/Forth_Resources/

I really appreciated finding this page. The 'one' item that no one seems to have is a PDF version of Starting Forth by Leo Brodie, and yet it is very worthwhile.

Since one can't download it, you either have to buy an out of print copy or read it on-line. Fortunately, Forth, Inc. has it in the original format.

http://www.forth.com/starting-forth/sf1/sf1.html

I find out that while so much of Forth has been generously shared with the public domain, this one book has become rather protected. If you can find it used, the second edition published 1987 by Prentice Hall is supposed to be the best.

[Peter Jakacki]

The memory map has been optimized again and this time the image for the Tachyon VM and HS-Serial are located at the end of hub memory so that they can be used for buffers. The SD card buffers will be moved to overlay the 2K VM image which will also include dictionary buffers.

To speed up compilation I have added a number preprocessor so that prefixed numbers are processed immediately rather than searching the dictionary first. The dictionary search has also been optimized as well as the dictionary headers with the most common kernel words being searching first for an earlier match. I've been able to reduce my line delay to 12ms even on SDCARD.fth which used to need 60ms or more.

So the kernel dictionary is searched first unless it's a prefixed number (#$%) and then the extended dictionary is searched while allowing for an alternate search method so that SDCARD.fth can be expanded to buffer the extended dictionary into SD memory and page it in and out rapidly as needed. The SD card routines use the 2K Tachyon image as a buffer area.

Since bytecode is referenced via the vector table it can be relocated very easily which will allow modules to be moved around or in and out of memory. This also means that kernel bytecode words can also be redefined by changing it's vector to point to the new definition. I will be making more use of these features as I expand Tachyon's functionality.

Loading EXTEND.fth takes 18.6 seconds (11.7 seconds with 6ms line delay @3M baud)
End of source code, 0978 lines processed and 0000 errors found
Load time = 18,607ms

NAMES: $6488...7446 for 4030 (23176 bytes added) with 23648 bytes free
CODE: $0000...250B for 5453 (3595 bytes added) with 23285 bytes free
CALLS: 0688 vectors free

and loading SDCARD.fth only takes 8 seconds now (6 seconds with 8ms line delay @3M baud)
End of source code, 0423 lines processed and 0000 errors found
Load time = 8,094ms

NAMES: $61AB...7446 for 4763 (20973 bytes added) with 22915 bytes free
CODE: $0000...2D69 for 6862 (2142 bytes added) with 21143 bytes free
CALLS: 0609 vectors free


RMAP
0000: 47 4F 45 4E 35 47 62 43 4A 45 59 44 66 29 .. ..
0400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
0800: 09 05 23 0F 2E 59 65 5D 4A 4B 50 7D 92 7C 7F 81
0C00: 76 5C 61 5E 3B 5B 5B 59 56 5A 52 4E 57 60 63 5E
1000: 75 6D 68 41 65 7E 79 74 63 7E 68 50 5B 66 5C 56
1400: 65 54 6C 65 72 77 60 79 79 77 39 .. 4D 62 50 3A
1800: 52 5F 61 5B 42 42 50 58 45 5B 5B 4E 68 69 66 73
1C00: 6A 4C 65 48 60 45 58 57 59 76 62 53 71 5C 6E 71
2000: 70 66 71 6B 6A 6E 73 6E 81 5A 6C 5D 5D 66 5D 5B
2400: 6B 63 47 15 47 3B 2A 7E 88 36 77 7E 5A 1E 29 27
2800: 3D 6B 77 72 79 76 76 80 78 72 5A 56 59 59 6A 84
2C00: 87 6F 67 66 51 34 .. .. .. .. .. .. .. .. .. ..
3000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
3C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
4C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
5C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
6000: .. 2A 6C 5D 64 6A 5F 58 68 5F 62 60 62 63 60 6B
6400: 71 6A 65 5D 5F 5E 5A 55 60 60 5D 63 5B 57 57 56
6800: 54 5A 53 58 51 4F 50 48 55 3E 3D 4E 42 32 3A 38
6C00: 35 41 4B 4B 4B 53 48 46 59 5D 58 65 52 53 55 52
7000: 48 50 55 51 52 52 57 58 5A 63 74 73 64 5B 5C 5B
7400: 5D 7B 65 71 5A 69 64 65 6A 74 6C 6E 61 70 82 91
7800: 7C 6C 71 74 6A 72 8E A1 8D 8A 72 0E .. .. 08 54
7C00: 4F 55 76 6A 6F 85 76 30 92 3E .. .. .. .. .. .. ok

[Peter Jakacki]

I'm in the process of tidying up and optimizing the memory map for Tachyon so I can work with the bulk of the dictionary in EEPROM or SD memory. So the bytecode kernel itself and the images and the vector table (kernel and user) requires 8K. Since accessing the dictionary in EEPROM will be slow I am looking at employing another task to page in sections and scan them but we'll see how that goes. Other than that there is nothing really new yet but these changes will enable more functionality to be incorporated while also freeing up more RAM for user applications. I almost forgot to mention that the HS-SerialRxL driver is now integrated in the Tachyon source.
Latest binary - bare kernel, 230400 baud, 5MHz

0 8000 MAP 
0000: 34 34 68 65 7A 7A A7 A6 11 87 6B 68 5C 6A 66 63 
0400: 6C 7B 6F 5C 6F 6E 8B 82 7E 68 7A 72 73 6F 9D 9A 
0800: 8F 77 5A .. .. 01 3D 5D 68 57 4B 50 4E 87 91 7B 
0C00: 8E 77 72 61 57 59 3B 63 5A 5B 55 53 54 4F 62 53 
1000: 67 64 76 6A 60 4D 68 7B 80 62 71 81 5A 51 63 69 
1400: 4E 5A 5E 5D 6C 62 6D 75 74 7F 75 4A 0D 0C 20 0F 
1800: 43 54 5C 41 58 4C 69 4D 5E 54 33 .. .. .. .. .. 
1C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
2000: ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## 
2400: ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## 
2800: ## ## ## ## ## ## ## ## E7 66 5B 60 5B 5C 55 5F 
2C00: 62 5F 62 5B 58 54 57 54 5C 52 56 52 4D 4E 4C 56 
3000: 38 35 35 3A 37 3C 42 3D 45 4B 4A 49 4D 51 50 51 
3400: 53 54 58 49 4D 56 4D 54 55 50 56 59 5A 70 73 74 
3800: 5B 54 5F 5F 63 5D 62 61 63 5E .. 4D 66 50 3A 52 
3C00: 5F 61 69 42 3F 54 58 45 5B 5B 4E 68 69 64 72 6A 
4000: 4D 66 48 5F 44 5A 56 55 77 66 4E 71 61 69 74 6E 
4400: 63 6F 70 68 6F 6C 6F 7D 5C 6F 5C 5E 66 5B 5B 6B 
4800: 63 4E 0C 2E .. .. .. .. .. .. .. .. .. .. .. .. 
4C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
5000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
5400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
5800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
5C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
6000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
6400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
6800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
6C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..  ok

[nglordi]

I required SDCARD.fth for the FPU64 words since my application included both the FPU64 and an SD card. In a previous post on this thread (#334), I included generic SPI words and applied them to accessing flash memory.

NickL

[mindrobots]

I'm a step away from earning my apprenticeship but Brian's suggestion makes sense to me. A layer of SPI words on top of which any device/application specific words for a particular SPI peripheral can be built.

[Brian Riley]

Peter et al.
I was going over Nick's FPU 64 code this afternoon and a thought occurred to me. The FPU64 uses SPI for I/O, thus necessitating loading SDCARD.fth before loading FPU64. So when reading or writing to the FPU64 you are mostly using Forth word whose names derive from "SD" which is only logical if you are familiar with Tachyon history. In my rarely very humble opinion would not it be easier on future apprentices of TF if SPI words were collected together, given SPI derived names and put into their own file? Do it now while it is still a manageable task.

Does this make any sense? thanks for listening ...

[Brian Riley]

The shared DropBox folder, "Tachyon Forth Apps," has had quite a bit of traffic. I set it up so that any "member" can also invite members. The problem is I only have a very few regular email addresses to use to issue "invitations" for a few of the regular posters and lurkers. So, if you wish to subscribe to the shared folder, send me an email to <brianbr@wulfden.org>. In order to accept the sharing status you need to have a DropBox account. The initial account is free with 2 GB. DropBox has all sorts of ways to earn extra space for no cost. I have almost doubled my free space already. Personally I am quite satisfied.with the DropBox service. I have it running on my iMac, an old MacBook Pro, my iPhone, iPad, a WinXP box and also on my iMac, Parallels passes the Mac DropBox through to a WinXP VM transparently.

If you are not interested in joining feel free to lurk and browse simply by clicking on the link to that folder in my sig.

While on the subject of Tachyon Forth Apps. Nick Lordi wrote up a great toolkit for the Micromega uM-FPU64 64-bit Floating Point Coprocessor. The 32 bit version of this is found in abundance, even right here at Parallax, but the 64 bit not so much. Solarbotics out in Western Canada has the chip for $25 plus shipping. The link to it is here

I created a separate folder for the FPU64 code and added the documentation from Micromega ... enjoy

[Brian Riley]

I found a bug in my jmservo8 code that would blow the stack. It has been fixed. Along the way I created a second piece of code titled jmservo2 . Where the original code would flexably handle 1-8 servos this is hard coded for two, though one or two more could be easily added.

I also created a shared DropBox folder for Tachyon Forth Apps and JMSERVO and NIc Lordi's 64 bit FPU code are the first entries.

... enjoy!

[Peter Jakacki]

Tachyon is just on 3 months old and there is still so much to do yet. I have finally just gotten around to tidying up a couple of things and expanding the vector table to allow for larger programs. In Tachyon all definitions need to have (it's automatic) the absolute address recorded in the vector table (XCALLS) and one of 4 instructions along with an 8-bit index is normally compiled and accesses code via the table. Later on when P2 comes out the vector table can be "widened" to accommodate longer addresses without impacting the compactness of the compiled code.

The dictionary still needs to be moved out of RAM and the 2K kernel image will be reused for the serial buffers and paging the dictionary from EEPROM/SPI/SD into RAM. I just need to figure out how to convince the Spin tool that I want the dictionary compiled right at the very end.


The startup screen after which I type INFO then 0 8000 MAP:

  Propeller .:.:--TACHYON--:.:. Forth V20121003.2240

NAMES:  $2066...39A7 for 6465 (2434 bytes added) with 0222 bytes free
CODE:   $0000...67CE for 20109 (2282 bytes added) with 6194 bytes free
CALLS:  0434 vectors free

MODULES LOADED: 
5EE4: LABELLER.fth        P1121 V1.5 121003.1100 
5735: L6470.fth           L6470 MicroStepper V1.2 121003.1140
4ED7: SDCARD.fth          SD CARD Toolkit - 120908.0400 
40C0: EXTEND.fth          Primary extensions to TACHYON kernel - 121003.1130 
----------------------------------------------------------------
INFO 
  Propeller .:.:--TACHYON--:.:. Forth V20121003.2240

Clock frequency = 80,000,000
MODULES LOADED: 
5EE4: LABELLER.fth        P1121 Labeller  V1.5 121003.1100 
5735: L6470.fth           L6470 MicroStepper V1.2 121003.1140
4ED7: SDCARD.fth          SD CARD Toolkit - 120908.0400 
40C0: EXTEND.fth          Primary extensions to TACHYON kernel - 121003.1130 

Tasks 
0000: IDLE                            0000 01 00 00 00 00 00 
0001: CONSOLE                         0000 00 00 00 00 00 00 
0003: IDLE                            0000 01 00 00 00 00 00 
0004: IDLE                            0000 01 00 00 00 00 00 
0005: IDLE                            0000 01 00 00 00 00 00 
0006: IDLE                            0000 01 00 00 00 00 00 
0007: TIMERTASK                       47F8 01 00 00 00 00 00 
Status 
NAMES:  $2066...39A7 for 6465 (2434 bytes added) with 0222 bytes free
CODE:   $0000...67CE for 20109 (2282 bytes added) with 6194 bytes free
CALLS:  0434 vectors free

I2C BUS SCAN 
Fast Device at 00A0  B4 C4 04 6E 25 10 00 44 

I/O Port states 
+----------u----------+
P00 <-- 1     1 --> P31
P01 <-- 1     1 <-- P30
P02 <-- 1     1 --> P29
P03 <-- 1     * <-- P28
P04 <-- *     * --> P27
P05 <-- *     * --> P26
P06 <-- *     * --> P25
P07 <-- *     * --> P24
P08 <-- *     * --> P23
P09 <-- *     1 --> P22
P10 <-- *     1 --> P21
P11 <-- *     1 --> P20
P12 <-- *     * --> P19
P13 <-- *     * --> P18
P14 <-- 1     * --> P17
P15 <-- *     * --> P16
+---------------------+
Special function registers 
01F0: PAR  = $0000_1600   00_0000_0000_0000_0001_0110_0000_0000
01F1: CNT  = $634B_198D   10_0011_0100_1011_0001_1001_1000_1101
01F2: INA  = $E070_400F   10_0000_0111_0000_0100_0000_0000_1111
01F3: INB  = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F4: OUTA = $4000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F5: OUTB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F6: DIRA = $5000_0000   01_0000_0000_0000_0000_0000_0000_0000
01F7: DIRB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F8: CTRA = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01F9: CTRB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FA: FRQA = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FB: FRQB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FC: PHSA = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FD: PHSB = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FE: VCFG = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000
01FF: VSCL = $0000_0000   00_0000_0000_0000_0000_0000_0000_0000 ok
0 8000 MAP 
0000: 28 .. .. .. .. .. 2C 7C 66 69 65 66 5E 6C 6A 7B 
0400: 6D 5E 72 76 89 7C 78 6D 7A 6E 74 7A 9C 9C 8E 66 
0800: 46 .. .. 05 0F 07 31 26 44 64 66 51 48 56 56 8B 
0C00: 92 78 8B 7A 71 58 63 49 43 5E 5E 53 60 4E 55 52 
1000: 5F 56 66 6D 6E 64 60 4E 70 77 82 61 73 83 51 54 
1400: 60 6B 49 63 5B 5C 6F 62 77 74 76 7C 7C 4F 4E 4B 
1800: 6C 58 3E 53 5D 56 59 5A 52 64 6F 6A 66 73 72 77 
1C00: 34 .. .. .. .. .. .. .. .. .. .. .. .. .. DF ## 
2000: ## B6 50 4F 50 50 52 61 61 62 57 58 4B 55 6B 6A 
2400: 68 61 68 69 71 70 6E 6D 6B 72 68 67 57 65 62 61 
2800: 60 63 63 60 6D 73 67 65 5C 63 5B 5B 55 5F 5F 5F 
2C00: 63 5A 59 57 56 54 5A 53 59 51 50 4C 4C 54 3D 35 
3000: 34 3A 36 3B 40 3E 44 4C 4A 49 4B 54 51 4F 52 53 
3400: 56 4E 49 53 50 53 51 52 56 59 5A 69 75 72 62 5C 
3800: 59 61 61 5D 65 59 65 80 13 .. .. .. .. .. .. .. 
3C00: .. .. .. .. .. .. .. .. 5A 5B 57 67 60 7E 90 73 
4000: 3C 3F .. 4D 66 50 3A 52 5F 61 69 42 3F 54 58 45 
4400: 5B 5B 4E 68 69 64 72 6A 4D 66 48 5F 44 5A 56 55 
4800: 77 6C 4E 71 61 69 74 6E 63 6F 70 68 6F 72 70 81 
4C00: 59 74 5E 5B 66 61 57 71 5F 5A 05 51 0C .. .. .. 
5000: .. .. .. .. 0F 11 09 14 64 7B 77 7A 74 70 7B 7F 
5400: 77 5C 57 5A 52 67 81 8E 72 64 6A 53 4F 3D 3A 4C 
5800: 90 71 4D 8A 88 3A 20 22 22 48 77 84 99 71 60 63 
5C00: 66 5E 60 63 66 5F 56 43 8B 64 4F 80 3C 03 40 4F 
6000: 4C 2C 38 60 6B 83 60 59 55 53 6D 6A 6A 68 3D 3B 
6400: 51 59 5A 64 63 66 64 61 6B 5E 64 59 52 60 5B 1D 
6800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
6C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7000: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7400: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7800: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 
7C00: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..  ok

[Brian Riley]

So, watching this thread, I started wondering if C could be compiled to Tachyon bytecode.So, I Googled "compile C to stack machine" and the first result was My history with Forth & stack machines which is an absolutely fascinating article. After reading it, I can somewhat wrap my head around Forth, but I also understand that some people can't, so I won't feel bad if I never do, completely.

Funny you should mention this. I just today added that article to my "Fort Resources" directory http://www.wulfden.org/downloads/Forth_Resources/

[Circuitsoft]

So, watching this thread, I started wondering if C could be compiled to Tachyon bytecode.So, I Googled "compile C to stack machine" and the first result was My history with Forth & stack machines which is an absolutely fascinating article. After reading it, I can somewhat wrap my head around Forth, but I also understand that some people can't, so I won't feel bad if I never do, completely.

[Peter Jakacki]

#241 Thanks Brian, Tachyon is moving faster than I can keep up with it seems.

Oh, and I thought it had slowed to a pedestrian pace in recent weeks! I've been very busy with hardware and application software with very little time for improving the kernel lately. Big things are happening with Tachyon in the next couple of weeks though (unless other big things happen in the meantime!).

[D.P]

Peter set a good example in Msg #241 of this thread. I copy pasted it to an editor and corrected it for the changes that have occurred over the last few weeks.

#241 Thanks Brian, Tachyon is moving faster than I can keep up with it seems.

[Brian Riley]

While the source for V2 and Extend.fth do have some inline documentation an example of inter-task communications would be fantastic.

Peter set a good example in Msg #241 of this thread. I copy pasted it to an editor and corrected it for the changes that have occurred over the last few weeks.

"Okay so I have made an addition to allow other Tachyon cogs to receive a command, a bit like hitting a key. It's really very simple, we just insert ATN? which returns with a non-zero byte command which is inserted by another cog. You can interpret the command anyway you want, just like a key. The command is read from the cog's "tasks" vector which won't cause it to run wild as it will simply clear a byte command in the idle loop without trying to execute it.

Here's what my BLINKY looks like:

#13 MASK    CONSTANT .RDY
: BLINKY    BEGIN .RDY OUTSET 50d ms .RDY OUTCLR 50d ms ATN? UNTIL ;
' BLINKY	CONSTANT UBLINKY

UBLINKY 4 RUN

Now when I type:

1 4 ATN!

Where 1 is a "command" for cog 4 the loop will terminate and I can get control of it once again in the idle loop. This is also a neat way to pass commands to the cog if it is setup to process them like this:

#13 MASK    CONSTANT .RDY
: BLINKY    50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY	CONSTANT UBLINKY

UBLINKY 4 RUN

So BLINKY will start off with a fast blink, but now type:

#200 4 ATN!

will cause it to slow blink. NOTE from BBR ... even with BLINKY reconfigured to set the blink rate sending "1" to ATN? still terminates the loop and hands control back over to the TF VM IDLE loop. "

[Humanoido]

Is there a version of Tachyon Forth that can qualify as Tiny Forth for the Propeller?

[D.P]

I wanted to share some info from Peter via pm:

"BTW, use the ATN! command rather than the RUN for passing commands to tasks. I noticed that the task that stopped may not have been stopped because you probably said 1 4 RUN rather than 1 4 ATN!. The ATN? looks in another location for the command while the RUN vector really only takes effect when the task is in IDLE.

pub ATN? \ alias for newer command ATN@
pub ATN@ ( -- cmd )
COGID TASK 4 + DUP W@
0 ROT W! \ Clear the command (ack)
;


( To talk to tasks in other cogs )
\ Use this in place of "cmd n RUN"
pub ATN! ( cmd cog -- )
TASK 4 + W!
;

Cheers,
Peter
"

While the source for V2 and Extend.fth do have some inline documentation an example of inter-task communications would be fantastic.

[Brian Riley]

I wanted to share some info from Peter via pm:

"BTW, use the ATN! command rather than the RUN for passing commands to tasks. I noticed that the task that stopped may not have been stopped because you probably said 1 4 RUN rather than 1 4 ATN!. The ATN? looks in another location for the command while the RUN vector really only takes effect when the task is in IDLE.

pub ATN? \ alias for newer command ATN@
pub ATN@ ( -- cmd )
COGID TASK 4 + DUP W@
0 ROT W! \ Clear the command (ack)
;


( To talk to tasks in other cogs )
\ Use this in place of "cmd n RUN"
pub ATN! ( cmd cog -- )
TASK 4 + W!
;

Cheers,
Peter
"

[nglordi]

I have found that TACHYON and the Micomega uM-FPU64 64-bit Floating Point Coprocessor work well together. A minimal code for using the FPU64 in a TACHYON environment is shown below. Note that 3 words are included which allow access to a serial lcd connected to the coprocessor serial port. This chip includes support for a 1-Wire bus, servo controller, parallel lcds, GPS input with NMEA sentence parsing, etc..

{  TACHYON V2.0   um-FPU64 Access      Nicholas G. Lordi  9/2012 

   See uM-FPU64 Datasheet and Instruction Set for details.  }


'' SPI Words  - require loading SDCard.fth 

'' Pin Assignments - scs is not needed, since the FPU cs pin is wired to ground
#21  MASK CONSTANT .miso
#22  MASK CONSTANT .sclk
#23  MASK CONSTANT .mosi

#4   MASK CONSTANT .busy   \ monitor FPU busy signal (lo - busy   hi - not busy)

  

: SPI  ( -- ) \  Initialize spi engine (2.8 MHz).
    #8 3 COGREG!
    .miso 2 COGREG!
    .mosi 1 COGREG!
    .sclk  0 COGREG!
    .mosi OUTCLR
    .sclk  OUTCLR   ;

: FPU>B   ( -- b ) \ Leaves 1 byte on stack.  
    SD@ ;

: B>FPU   ( b -- ) \ Sends 1 byte to  FPU64. 
    SD! ; 

: W>FPU  ( w -- ) \ Sends 1 word to FPU64.
    DUP #8 SHR SD! SD!  ;

: L>FPU  ( l -- ) \ Sends 1 long to device.  
    DUP #24 SHR SD! DUP #16 SHR SD! DUP #8 SHR SD! SD! ;

: FPU>W  ( -- w ) \ Leaves 1 word on stack. 
   SD2@  ;

: FPU>L  ( -- l ) \  Leaves 1 long on stack.  
   SD@  #8 SHL SD@ OR  #8 SHL SD@ OR #8 SHL SD@ OR ;
 



'' Utilities

WVARIABLE REGA   \ stores reg A  number
WVARIABLE REGX   \ stores reg X  number

: FPU  ( -- b )  \ Initialize SPI engine and resets the fpu chip. Leaves $BC on stack if fpu is in sync.
    SPI  10 0 DO $FF SD! LOOP  $00 SD! 10 ms $F0 SD!  SD@ ;


'' Some Useful Subroutines

: SETREGA  ( n1 -- )  \ Assigns register A as register #n1.
    DUP REGA W! $01 SD! SD!  ;

: SETREGX  ( n1 -- )  \ Assigns register X as register #n1.
    DUP REGX W! $02 SD! SD!  ;

: I>FP ( l -- ) \ Stores long in fpu reg A and converts it to floating point.
    $91 SD! L>FPU  $60 SD!  ;

: FP>I ( -- l ) \ Leaves integer form of floating point value in fpu reg A on stack. Value unchanged in reg A.
    $08 SD! #0 SD! $62 SD! $95 SD! 1 ms FPU>L $10 SD! REGA W@ SD!   ;

: SCALEUP  ( n1 -- )  \ Multiplies fp value in reg A by n1.
    $08 SD! #0 SD! I>FP $2D SD! $06 SD!  ;

: SCALEDN  ( n1 -- )   \ Divides fp value in reg A by n1.
    $08 SD! #0 SD! I>FP $2F SD! $06 SD!  ;

: LCD  ( -- ) \ Initializes serial lcd (4x20) attached to the seroil port at 19200 baud.
    $CE SD! $00 SD!  #7 SD!  ;

: >LCD ( b -- )  \ Sends control code b to lcd.
    $CE SD! $01 SD! SD! $0 SD! ;

: FP>LCD  ( n1 -- )  \ Converts value in reg A to a string of length n1 (max 10) to the lcd. 
    $1F SD! #0 SD! $E4 SD! #0 SD! SD! $CE SD! #3 SD! #13 >LCD ;
 

END

NickL

[Brian Riley]

Yes I got the gcc warning, that's the beauty of the -Wall arg. Parallels? I highly recommend BST since your on OSX, it handles tachyon source and binarys perfectly so far.

For some reason, I have never been able to fathom, the BST IDE stopped working for me under Lion and Mtn Lion. The BST executables work fine for SpinSIDE (Simple IDE). Parallels is so thoroughly integrated into OSX that its no bother at all.

[D.P]

@mindrobots and @DP .. muchas gracias

1.61 GB of Xcode 4.5 later plus another 115 MB for 'command line tools' and I had hex2bin turned into an executable under Mountain Lion ... did either of you guys get a compiler warning about 'signedness.'

I could not figure how to make SpinSIDE do a .binary. So I brought up Parallels/WinXP and PropTool 1.3.2, and burned the EEPROM and it ran.

Yes I got the gcc warning, that's the beauty of the -Wall arg. Parallels? I highly recommend BST since your on OSX, it handles tachyon source and binarys perfectly so far.

[Brian Riley]

@mindrobots and @DP .. muchas gracias

1.61 GB of Xcode 4.5 later plus another 115 MB for 'command line tools' and I had hex2bin turned into an executable under Mountain Lion ... did either of you guys get a compiler warning about 'signedness.'

I could not figure how to make SpinSIDE do a .binary. So I brought up Parallels/WinXP and PropTool 1.3.2, and burned the EEPROM and it ran.

[Brian Riley]

FOUND ANOTHER ODDITY

I was setting up a situation to try out BACKUP and RESTORE. I added my own small file LOOKUP.fth after EXTEND.fth did a BACKUP and a REBOOT and MODULES stopped reporting EXTEND, but it IS there!

End of source code, 0027 lines processed and 0000 errors found
Load time = 2,502ms

CODE   @$4B02  - bytes added = 0189 and 13566 bytes free
NAMES  @$2648  - bytes added = 0151 and 2568 bytes free
YCALLS @ 0163 entries free
Runtime since last reset = 306,496ms
 ok
MODULES
LOOKUP.fth              120922.1300 - extension to examine LOOKUP/VECTORS
EXTEND.fth              Primary extensions to TACHYON kernel - 120923.2300
 ok
BACKUP  ok
REBOOT

  Propeller .:.:--TACHYON--:.:. Forth V20120919.1215

CODE   @$4B02  - bytes used in this load = 0189
NAMES  @$2648  - bytes used in this load = 0151
YCALLS @ 0163 entries free
----------------------------------------------------------------
MODULES
LOOKUP.fth              /
 ok
MODULES
LOOKUP.fth              \
 ok
QWORDS
LU DEFLT FTH ETH DTH CTH BTH ATH 9TH 8TH 7TH 6TH 5TH 4TH 3RD 2ND 1ST 0TH SPCHAR
LOOKUP.fth COLD EXTEND exttimers INFO STATS END .RUNTIME BINARYDUMP FIXCKSUM IDUMP cksum CONBAUD
RESTORE ?BACKUP BACKUP kernel 64K? EVERIFY EFILL EECOPY eebuf ELOAD ESAVEB ESAVE EDUMP ENDRD
EE@ EE! EERD @EE I2CBUS SI2C@ SI2C! SI2C!? I2C@ I2C! I2C!? I2CSTOP I2CSTART I2CPINS
EEPROM SDA SCL sda scl % PWM! PWMFREQ RUNPWM PWMCOG pwmfreq pwmtbl pwmchans pwmpins
RUNTIMERS TIMERTASK ALARM TIMEOUT? TIMEOUT TIMER timercnt timers runtime MUTE HZ KHZ MHZ DAC!
FRQ BPIN APIN PLLDIV PLL DUTY CTRMODE NCO B A CTR@ CTR! CTR ctr PINS? .PIN SPRS REG$
.LAP .NUM (SEP) B>L B>W W>L W>B L>W >B >W CON SERIN SEROUT SERBAUD MAP MODULES QWORDS
@. C~~ C~ W~~ W~ ~~ ~ C-- C++ W-- W++ -- ++ <= => >| |< seconds second MOD
LONGFILL LBIT! MASKS PININP PINCLR PINSET TYPE SPACES ALIGNL TASKS TASK? ENQ@ ATN! ENQ! ATN@
ATN? RUN COGINIT @CNT @MISO @MOSI @SCK COGREG@ COGREG! CLKFREQ U@ .INDEX ... Published
IMMEDIATE ok ]~ [~ LEMIT EXTEND.fth RESET 0EXIT EXIT NOP 3DROP 2DROP DROP ?DUP DUP OVER 3RD
4TH SWAP ROT NIP 1+ 1- + - * U/MOD UM* NEGATE INVERT AND ANDN OR XOR SHR SHL 2/ 2*
REV MASK 0= = > C@ W@ @ C+! C! C@++ W+! W! +! ! CMOVE BIT! SET CLR IC! (PUSH4)
(PUSH3) (PUSH2) (PUSH1) (VAR) FALSE OFF 0 1 2 3 4 5 6 7 8 ON TRUE -1 BL IN@ P@ OUT!
P! CLOCK OUTSET OUTCLR OUTPUTS INPUTS WAITLOW SHROUT SHRINP LOADMOD RUNMOD SFR@ SPR@
COG@ COGREG COG! PASM STACKS LSTACK CALL JUMP (XCALL) (YCALL) (WCALL) (ELSE) (IF) (UNTIL)
(AGAIN) ADO DO LOOP +LOOP FOR NEXT <BEGIN AGAIN> UNTIL> POPMARK >R R> >L L> (EMIT) (REG)
REG DELTA WAITCNT WAITPEQ WAITPNE CMPSTR I XCALLS REBOOT STOP COGID PAR CNT INA INB
OUTA OUTB DIRA DIRB CTRA CTRB FRQA FRQB PHSA PHSB VCFG VSCL SPR SPR! [SPIO] [SPIOD]
[SDRD] [SDWR] [PWM] [PWM!] [PLOT] !SP 2+ 2- SET? / 2DUP MIN MAX 0<> <> 0> 0< < U<
WITHIN ?EXIT BOUNDS LEAVE J K IX ERASE FILL ms us CNT@ NEWCNT LAPCNT OUT IN INPUT PIN!
PIN@ KEY? KEY HEX DECIMAL BINARY .S DUMP COGDUMP .STACKS DEBUG EMIT CLS SPACE BELL CR
SPINNER .HEX .BYTE .WORD .LONG . >DIGIT NUMBER SCRUB GETWORD FINDSTR NFA>CFA EXECUTE V2 VER
.VER TACHYON @PAD HOLD >CHAR #> <# # #S (STR) .STR STRLEN U. .DEC DISCARD colors pixels
REG flags base digits delim word autorun keypoll tasks unum uemit ukey names here codes
errors baudcnt prompt find create lines ALLOT ALLOCATED HERE AUTO! MARK UNMARK >PFA NFA' '

KEYPOLL \ '' ( { } IFNDEF " ." AUTORUN IF ELSE THEN ENDIF BEGIN UNTIL AGAIN WHILE REPEAT
; [COMPILE] GRAB LITERAL : pub pri CREATEWORD CREATE CVARIABLE WVARIABLE VARIABLE BYTE
WORD LONG TABLE CONSTANT C, | || TASK IDLE LOOKUP VECTORS +XCALL +YCALL ITEM ITEM@ ITEMS
NFA>CFA WORDS =PIXELS STATS FREE COLD
 ok

[mindrobots]

Brian,

GCC is part of XCode (sort of) but you still need to go into XCode | Preferences and install "Command Line Tools". Then you can GCC to your heart's content!

[D.P]

How did you get this to compile. I am running 10.8.2 and it couldn't find GCC. I though that got installed along with the XCode package.

My system is:
Darwin dp.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

GCC is located at:
dp:Hex2bin-1.0.9 dp$ whereis gcc
/usr/bin/gcc

This is all I had to do

gcc -O2 -Wall -o hex2bin hex2bin.c

[Brian Riley]

hex2bin v1.0.9, Copyright (C) 2012 Jacques Pelletier
checksum extensions Copyright (C) 2004 Rockwell Automation
improved P.G. 2007, modified Danny Schneider,2012

How did you get this to compile. I am running 10.8.2 and it couldn't find GCC. I though that got installed along with the XCode package.

[D.P]

The IDUMP on it's own will not work if you want a valid image for a Prop binary. Have a look at BINARYDUMP which fixes up the header and checksum (first 16 bytes of memory) before it dumps from the EEPROM. You don't need to set any parameters for this word as it caclulates what's needed.

Works perfect with BST, thanks.

[Peter Jakacki]

I tried as many ways, programs etc that I could think of to output $0000 $8000 IDUMP to a binary including hex2bin (mac osx) None of them were recognized as a valid image by BST like your .binary was.

Here's the best of them:

hex2bin v1.0.9, Copyright (C) 2012 Jacques Pelletier
checksum extensions Copyright (C) 2004 Rockwell Automation
improved P.G. 2007, modified Danny Schneider,2012

Lowest address = 00000000
Highest address = 00007FFF
Pad Byte = FF
8-bit Checksum = 15
-rw-r--r-- 1 dp staff 32768 Sep 24 15:33 Tachyon.binary

The IDUMP on it's own will not work if you want a valid image for a Prop binary. Have a look at BINARYDUMP which fixes up the header and checksum (first 16 bytes of memory) before it dumps from the EEPROM. You don't need to set any parameters for this word as it caclulates what's needed.

[D.P]

I will have to try using SImpleIDE a little more but where does it know how to load an Intel hex file? The reason I have an Intel hex dump is that conversion utilities are very common for this format and so I run HEX2BIN and rename the file with a .binary extension for the Spin tool to recognize.

BTW - the first 2 hex characters after the : happen to be the byte code for the line, it's the next 4 hex digits that represent the address.

I tried as many ways, programs etc that I could think of to output $0000 $8000 IDUMP to a binary including hex2bin (mac osx) None of them were recognized as a valid image by BST like your .binary was.

Here's the best of them:

hex2bin v1.0.9, Copyright (C) 2012 Jacques Pelletier
checksum extensions Copyright (C) 2004 Rockwell Automation
improved P.G. 2007, modified Danny Schneider,2012

Lowest address = 00000000
Highest address = 00007FFF
Pad Byte = FF
8-bit Checksum = 15
-rw-r--r-- 1 dp staff 32768 Sep 24 15:33 Tachyon.binary

[Peter Jakacki]

I looked up "IDUMP ( src cnt -- )" . In the absence of any further guidance I typed "0 $8000 IDUMP" copy pasted the dump into a text editor and named it BINARYTEST.HEX. Opened the HEX file in SimpleIDE put the focus on the HEX and told it to BURN EEPROM, its started and then aborted, complaining "load file bigger than 32K"

What did I do wrong and/or fail to do?

OBTW - The HEX file seems to start address at $10000 maybe explaining SimpleIDE's mistaken complaint of "over 32K"

OBTW-2 - I did a manual initiated BACKUP after adding one of my personal files after EXTEND. The EEPROM would not boot. I had to go back to SimpleIDE and start over.

I will have to try using SImpleIDE a little more but where does it know how to load an Intel hex file? The reason I have an Intel hex dump is that conversion utilities are very common for this format and so I run HEX2BIN and rename the file with a .binary extension for the Spin tool to recognize.

BTW - the first 2 hex characters after the : happen to be the byte code for the line, it's the next 4 hex digits that represent the address.

[Brian Riley]

For anyone who would like to try out Tachyon preloaded with the extensions and SDCARD tools you can now download it via the Dropbox link in the binaries folder. The binary is preset for 57600 baud with a 5MHz crystal but the baudrate is easy to change once you startup. To change to 230400 baud for instance just type:
#230400 CONBAUD
The # symbol is just to make sure that the baudrate is accepted as a decimal number (230400d will work too). The baudrate will be locked into EEPROM as the default baudrate on the next reboot.
I tested this binary out on my original Prop demo board.

I looked up "IDUMP ( src cnt -- )" . In the absence of any further guidance I typed "0 $8000 IDUMP" copy pasted the dump into a text editor and named it BINARYTEST.HEX. Opened the HEX file in SimpleIDE put the focus on the HEX and told it to BURN EEPROM, its started and then aborted, complaining "load file bigger than 32K"

What did I do wrong and/or fail to do?

OBTW - The HEX file seems to start address at $10000 maybe explaining SimpleIDE's mistaken complaint of "over 32K"

OBTW-2 - I did a manual initiated BACKUP after adding one of my personal files after EXTEND. The EEPROM would not boot. I had to go back to SimpleIDE and start over.

[D.P]

Works great here, PBOE, BST, Mac OS 10.6, MiniTerm 234000. Nice way to distribute Tachyon.

[Peter Jakacki]

For anyone who would like to try out Tachyon preloaded with the extensions and SDCARD tools you can now download it via the Dropbox link in the binaries folder. The binary is preset for 57600 baud with a 5MHz crystal but the baudrate is easy to change once you startup. To change to 230400 baud for instance just type:
#230400 CONBAUD
The # symbol is just to make sure that the baudrate is accepted as a decimal number (230400d will work too). The baudrate will be locked into EEPROM as the default baudrate on the next reboot.
I tested this binary out on my original Prop demo board.

INFO 
  Propeller .:.:--TACHYON--:.:. Forth V20120919.1215

Clock frequency = 80,000,000
MODULES LOADED 
SDCARD.fth              SD CARD Toolkit - 120908.0400 
EXTEND.fth              Primary extensions to TACHYON kernel - 120923.2300 

Tasks 
0000: Tachyon Slave   0000 01 00 00 00 00 00 
0001: Tachyon Console 0000 00 00 00 00 00 00 
0003: Tachyon Slave   0000 01 00 00 00 00 00 
0004: Tachyon Slave   0000 01 00 00 00 00 00 
0005: Tachyon Slave   0000 01 00 00 00 00 00 
0006: Tachyon Slave   0000 01 00 00 00 00 00 
0007: Tachyon Slave   4348 01 00 00 00 00 00 
Status 
CODE   @$52AC  - bytes added = 2151 and 11604 bytes free
NAMES  @$240C  - bytes added = 0739 and 1980 bytes free
YCALLS @ 0103 entries free
Runtime since last reset = 1,085,775ms 

I2C BUS SCAN 
Fast Device at 00A0  B4 C4 04 6F 46 10 00 00 

I/O Port states 
+----------u----------+
P00 <-- *     1 --> P31
P01 <-- *     1 <-- P30
P02 <-- *     1 --> P29
P03 <-- *     * <-- P28
P04 <-- *     1 --> P27
P05 <-- *     1 --> P26
P06 <-- *     1 --> P25
P07 <-- 1     1 --> P24
P08 <-- *     * --> P23
P09 <-- *     * --> P22
P10 <-- *     * --> P21
P11 <-- *     * --> P20
P12 <-- *     * --> P19
P13 <-- *     * --> P18
P14 <-- *     * --> P17
P15 <-- *     * --> P16
+---------------------+
Special function registers 
01F0: PAR  = $0000_16C0   %0000_0000_0000_0000_0001_0110_1100_0000
01F1: CNT  = $43A6_CD25   %0100_0011_1010_0110_1100_1101_0010_0101
01F2: INA  = $EF00_0080   %1110_1111_0000_0000_0000_0000_1000_0000
01F3: INB  = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F4: OUTA = $4000_0000   %0100_0000_0000_0000_0000_0000_0000_0000
01F5: OUTB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F6: DIRA = $5000_0000   %0101_0000_0000_0000_0000_0000_0000_0000
01F7: DIRB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F8: CTRA = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01F9: CTRB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FA: FRQA = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FB: FRQB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FC: PHSA = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FD: PHSB = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FE: VCFG = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000
01FF: VSCL = $0000_0000   %0000_0000_0000_0000_0000_0000_0000_0000 ok
QWORDS 
SPINNERET PPUSB BOE BOECARD? CE1200 CE0972 P1145 P1107 P1144 LR XLOAD XSAVE SDPOLL SD 
XDUMP SDWR SDRD PROCESS_TOKEN SDRDBLK (SDRD) (SDWR) .CARD tval NA@ CID@ CSD@ BEXT XSHR 
XSHR1 !SD ?TIMEOUT !TIMEOUT GETCID GETCSD SDDAT! SDERR? STAT@ ACMD CMD MARKER? RES@ !SDIO 
SDBUSY &sdto SDCLK SLOWCLK SD4@ SD2@ SD! SD@ SPIO CARD? SDSEL SDPINS SCK MOSI MISO SDCS 
SDMASKS SDCNT #datatkne #datatkn1 #datatkn extbuf csd cid card? crc ucard timeout sdtimer oc 
sdrd sdwr sdflg sdsize sdpins SDBUF BLKSIZ SDCARD.fth COLD EXTEND exttimers INFO STATS END 
.RUNTIME BINARYDUMP IDUMP FIXCKSUM cksum CONBAUD RESTORE ?BACKUP BACKUP kernel 64K? EVERIFY 
EFILL EECOPY eebuf ELOAD ESAVEB ESAVE EDUMP ENDRD EE@ EE! EERD @EE I2CBUS SI2C@ SI2C! 
SI2C!? I2C@ I2C! I2C!? I2CSTOP I2CSTART I2CPINS EEPROM SDA SCL sda scl % PWM! PWMFREQ 
RUNPWM PWMCOG pwmfreq pwmtbl pwmchans pwmpins RUNTIMERS TIMERTASK ALARM TIMEOUT? TIMEOUT TIM 
timercnt timers runtime MUTE HZ KHZ MHZ DAC! FRQ BPIN APIN PLLDIV PLL DUTY CTRMODE NCO B A 
CTR@ CTR! CTR ctr PINS? .PIN SPRS REG$ .LAP .NUM (SEP) B>L B>W W>L W>B L>W >B >W CON 
SERIN SEROUT SERBAUD MAP MODULES QWORDS @. C~~ C~ W~~ W~ ~~ ~ C-- C++ W-- W++ -- ++ 
<= => >| |< seconds second MOD LONGFILL LBIT! MASKS PININP PINCLR PINSET TYPE SPACES 
ALIGNL TASKS TASK? ENQ@ ATN! ENQ! ATN@ ATN? RUN COGINIT @CNT @MISO @MOSI @SCK COGREG@ 
COGREG! CLKFREQ U@ .INDEX ... Published IMMEDIATE ok ]~ [~ LEMIT EXTEND.fth RESET 0EXIT EXIT 
NOP 3DROP 2DROP DROP ?DUP DUP OVER 3RD 4TH SWAP ROT NIP 1+ 1- + - * U/MOD UM* 
NEGATE INVERT AND ANDN OR XOR ROL ROR SHR SHL 2/ 2* REV MASK 0= = > C@ W@ @ C+! C! 
C@++ W+! W! +! ! CMOVE BIT! SET CLR IC! (PUSH4) (PUSH3) (PUSH2) (PUSH1) (VAR) FALSE OFF 
0 1 2 3 4 5 6 7 8 ON TRUE -1 BL IN@ P@ OUT! P! CLOCK OUTSET OUTCLR OUTPUTS 
INPUTS WAITLOW SHROUT SHRINP LOADMOD RUNMOD SFR@ SPR@ COG@ COGREG COG! PASM STACKS LSTACK 
CALL JUMP (XCALL) (YCALL) (WCALL) (ELSE) (IF) (UNTIL) (AGAIN) ADO DO LOOP +LOOP FOR NEXT 
<BEGIN AGAIN> UNTIL> POPMARK >R R> >L L> (EMIT) (REG) REG DELTA WAITCNT WAITPEQ WAITPNE 
CMPSTR I XCALLS REBOOT STOP COGID PAR CNT INA INB OUTA OUTB DIRA DIRB CTRA CTRB FRQA 
FRQB PHSA PHSB VCFG VSCL SPR SPR! [SPIO] [SPIOD] [SDRD] [SDWR] [PWM] [PWM!] [PLOT] !SP 
2+ 2- SET? / 2DUP MIN MAX 0<> <> 0> 0< < U< WITHIN ?EXIT BOUNDS LEAVE J K IX 
ERASE FILL ms us CNT@ NEWCNT LAPCNT OUT IN INPUT PIN! PIN@ KEY? KEY HEX DECIMAL BINARY 
.S DUMP COGDUMP .STACKS DEBUG EMIT CLS SPACE BELL CR SPINNER .HEX .BYTE .WORD .LONG . 
>DIGIT NUMBER SCRUB GETWORD FINDSTR NFA>CFA EXECUTE V2 VER .VER TACHYON @PAD HOLD >CHAR #> 
<# # #S (STR) .STR STRLEN U. .DEC DISCARD colors pixels REG flags base digits delim 
word autorun keypoll tasks unum uemit ukey names here codes errors baudcnt prompt find 
create lines ALLOT ALLOCATED HERE AUTO! MARK UNMARK >PFA NFA' ' KEYPOLL \ '' ( { } 
IFNDEF " ." AUTORUN IF ELSE THEN ENDIF BEGIN UNTIL AGAIN WHILE REPEAT ; [COMPILE] GRAB 
LITERAL : pub pri CREATEWORD CREATE CVARIABLE WVARIABLE VARIABLE BYTE WORD LONG TABLE 
CONSTANT C, | || TASK IDLE LOOKUP VECTORS +XCALL +YCALL ITEM ITEM@ ITEMS NFA>CFA WORDS 
=PIXELS STATS FREE COLD 
 ok

[MJB]

Unfortunately many command syntaxes do not have any general-purpose means of parsing in that they do not have clearly defined delimiters for one. At least if the command was written as "!CMD;100;349" then that would be far easier to set Forth to have the ";" delimiter as well as <CR>. I assume they at least include a <CR> at the end too? You can scrub out approach 2 as the preprocessing it does is fairly simple and has to do it in real-time between characters.

Approach 1 with writing a simple parser will work though as you don't have to do all the processing, it may be that the command like !CMD is fixed size or always delimited by a digit etc. So you could parse this to the point of plucking out commands and parameters and pass this through the normal word interpreter. Which reminds me, I must see about including an equivalent INTERPRET command which can take a string and process it as if it were terminal input.

If you would like to maintain normal operation of Forth from the terminal command line then integrating approach 1 with approach 3 will work also. The only downside is that there will be a small delay before control is passed to your parser as the dictionary is searched first and then an attempt is made to convert it to a number.

Hi Peter,
after a closer look into Tachyon2 I am thinking of:
1. hooking into MAIN CONSOLE TERMINAL at notfound
2. transforming the content of wordbuffer into regular forthsyntax and
3. with a new word unreadbuf push the result of the transformation back on the front of the readbuffer. Since the transformation does not grow the string this will be ok for the short commands < 64 bytes each.
4. return control to normal processing of the console input.

'' The read and write index is stored as two bytes preceding the buffer, read this as a word (faster)'' BKEY ( buffer -- ch ) ' byte size buffer is preceded with a read index, go and read the next character
'' assume the buffer is 256 bytes long
' READBUF ( buffer -- ch )
READBUF
byte DUP,DEC,DEC,DUP,WFETCH ' point to read index ( buffer writeptr writeindex )
byte SWAP,DEC,DEC,WFETCH,SWAP ' ( buffer readindex writeindex )

to me - Forth-beginner - it looks like two words are fetched and not two bytes as a word. so readindex writeindex are both treated as a word even while the buffer is only 256 bytes long

I must see about including an equivalent INTERPRET command which can take a string and process it as if it were terminal input.

yes would love that - like LISPs EVAL function.
thanks Markus

[prof_braino]

Is there a possebility to connect TACHYON to the ViewPort envoirment?
So you can combine the exelent capability of TACHYON with the gui of ViewPort

propforth was working towards an interface for Hanno's tools to work with forth. the effort was overcome by other project priorities, but there werrre no technical reasons why it wouldn't work.
it might even be easier with tachyon, as there are so many folks looking at it.

[Brian Riley]

Pete
I prepared the following code so that I could better understand LOOKUP/VECTORS words. I created a test construct word LU that is passed a number and in this case selects from 16 words for values input from 0 to 15 and a 17th for all else

TACHYON

: SPCHAR ( char -- ) SPACE EMIT ;
: 0TH  "0"  SPCHAR ; 
: 1ST   "1"  SPCHAR ; 
: 2ND   "2"  SPCHAR ; 
: 3RD   "3"  SPCHAR ; 
: 4TH   "4"  SPCHAR ; 
: 5TH   "5"  SPCHAR ; 
: 6TH   "6"  SPCHAR ; 
: 7TH   "7"  SPCHAR ; 
: 8TH   "8"  SPCHAR ; 
: 9TH   "9"  SPCHAR ; 
: ATH   "A"  SPCHAR ; 
: BTH   "B"  SPCHAR ; 
: CTH   "C"  SPCHAR ; 
: DTH   "D"  SPCHAR ; 
: ETH   "E"  SPCHAR ; 
: FTH   "F"  SPCHAR ;
: DEFLT  ."  DEFLT " ;

: LU ( input -- ) 		\ <limit> LOOKUP <default action> <list word 0> ... <list word limit-1>
		#16 LOOKUP  DEFLT	\ '16' number of list words start count after DEFLT, count from 0
		0TH 1ST 2ND 3RD 	\ DEFLT is selected if input is GT or EQ to limit
		4TH 5TH 6TH 7TH 
		8TH 9TH ATH BTH 
		CTH DTH ETH FTH
	;
END

Here is the results a few passes through the test construct LU ... enjoy

0 LU  0 ok
1 LU  1 ok
5 LU  5 ok
8 LU  8 ok
9 LU  9 ok

#10 LU  A ok
#12 LU  C ok
#14 LU  E ok
#15 LU  F ok

#16 LU  DEFLT ok
#17 LU  DEFLT ok
#18 LU  DEFLT ok
#102 LU  DEFLT ok

[Peter Jakacki]

Is there a possebility to connect TACHYON to the ViewPort envoirment?
So you can combine the exelent capability of TACHYON with the gui of ViewPort

I've never looked into it before as I usually just write a couple of debugging words to display the information that I need displayed and examining and changing variables from the terminal is intrinsic to Forth itself. I think Sal even wrote a logic analyzer for PropForth so this kind of thing is possible without having to resort to external debuggers. But in saying all that I do agree that Viewport is a very powerful tool for those who program in Spin.

[Powersoft]

Is there a possebility to connect TACHYON to the ViewPort envoirment?
So you can combine the exelent capability of TACHYON with the gui of ViewPort

[Peter Jakacki]

Peter,

The DS18B20 is the most popular of the 18xx series. It offers 12 bit resolution by default, selectable down to 10 and 8 bits. Do you have any of them? If not I can send you a couple.

Yes, it is the DS18B20+ that I have a few of. I had a look at the flowchart for the SEARCH ROM command but it's so unstructured that I decided I just need to implement this command in my own fashion. In fact I just found the 1-wire PASM code in the OBEX so I will follow that as a guide instead.

[Brian Riley]

Peter,

The DS18B20 is the most popular of the 18xx series. It offers 12 bit resolution by default, selectable down to 10 and 8 bits. Do you have any of them? If not I can send you a couple.

[Peter Jakacki]

I've had a request to interface 1-wire devices, specifically the DS1820+ temperature sensor and the DS2450+ 12-bit ADC so I got some chips in and having a play with it now. So I can read a single device fine just using Tachyon bytecode as I can manage 1us pulses without PASM. Now I am implementing the SEARCH ROM command which is probably the most complicated command. This is a work-in-progress but you can have a play with it while I continue to expand the functionality. Perhaps you can test it out yourself and report any problems or just make suggestions.
https://docs.google.com/document/pub...avdwmCv_z7Ftg0

[Peter Jakacki]

Peter

Is there a chance for getting an example of PWM in TACHYON?

Jan Kromhout
Hellevoetsluis-NL

Hi Jan, how did you go with using the 8 channel PWM module?

I've been using it myself with my H-bridge modules and motors and I have just updated the kernel to include a faster table update module, not that I had any problems with it, I just wanted to make it better. Originally PWM! which sets the duty cycle for the channel was just scanning through a 256 byte table clearing and setting masks which took >5ms but then I did another version which cut that in half. Not happy with that I then created a PWM! PASM module which like the other specialized modules just gets loaded as needed and are useful in repetitive tasks. So the load time is around 20us and setting the table takes around 200us.

[Peter Jakacki]

There's hardly a day that goes by that there isn't a significant addition etc so I really recommend that you update to the latest kernel. Just a very quick summary then:
The ' (tick) word now operates within definitions correctly so that there is no need to create a constant beforehand.
VER @ will return the version and build in one handy long like this: 20120917
I'm also experimenting with the source code loader, line numbers etc.

I'm being summoned now so in the meantime here's a little bit of code for a PCF8563 I2C RTC chip. Other RTC chips will follow but will probably be integrated into the one RTC module so they can use common routines.

TACHYON
[~
: PCF8563.fth ;

: @RTC ( reg --  )
    I2CSTART $A2 I2C! I2C!
    ;
    

TABLE rtc #16 ALLOT
TABLE rtcmasks
    $FF | $FF | $7F | $7F |
    $3F | $3F | $07 | $1F |
    
    $FF | $7F | $3F | $3F |
    $07 | $03 | $03 | $FF |
    
: RDRTC ( -- )
    0 @RTC
    I2CSTART $A3 I2C! 
    0 #16 ADO 0 I2C@ I rtcmasks + C@ AND I rtc + C! LOOP 1 I2C@ DROP
    I2CSTOP
    ; 
: WRRTC
    0 @RTC rtc #16 ADO I C@ I2C! LOOP I2CSTOP
    ;
    
: RTC!    rtc + C! ;
: RTC@ rtc + C@ ;

    
: .TIME
    RDRTC
    4 RTC@ .BYTE ." :" 3 RTC@ .BYTE ." :"  2 RTC@ .BYTE
    ;
: .DATE \ print date as DD/MM/YY
    RDRTC
    5 RTC@ .BYTE ." /" 7 RTC@ .BYTE ." /" 8 RTC@ .BYTE
    ;

: BCD>DEC
    DUP 0F AND SWAP 4 SHR #10 * +
    ;
    
: TIME@ ( -- dectime ) \ Time is represented in decimal form i.e. #123055 = 12:30 PM & 55 seconds)
    RDRTC
    4 RTC@ BCD>DEC #10000 *
    3 RTC@ BCD>DEC #100 * +
    2 RTC@ BCD>DEC +
    ;
: DATE@ ( -- decdate ) \ date is represented in decimal form as YYMMDD
    RDRTC
    8 RTC@ BCD>DEC #10000 *
    7 RTC@ BCD>DEC #100 * +
    5 RTC@ BCD>DEC +
    ;
: DEC>BCD
    #10 U/MOD 4 SHL +
    ;
    
: TIME! ( dectime -- ) \ Store the time from a decimal form ( #123055 = 12:30:55 PM)
    RDRTC
    #100 U/MOD SWAP DEC>BCD 2 RTC!
    #100 U/MOD SWAP DEC>BCD 3 RTC!
    DEC>BCD 4 RTC!
    WRRTC
    ;
: DATE! ( decdate -- ) \ Store the date from a decimal form ( #120917 = 17th Sept, 2012)
    RDRTC
    #100 U/MOD SWAP DEC>BCD 5 RTC!
    #100 U/MOD SWAP DEC>BCD 7 RTC!
    DEC>BCD 8 RTC!
    WRRTC
    ;

        
]~
    
END

[Peter Jakacki]

Where do I find V2 to download?

How did you go? The files are all linked in the Intro pages and are also in the Dropbox folder. See my sig.

[Powersoft]

Where do I find V2 to download?

[D.P]

Good news for multi-taskers! The task functions have been expanded and so you should use the new kernel and extensions. Support includes finding the next free Tachyon cog available for a task.

TASKS
0001: Tachyon Console 0000 00 00 00 00 00 00
0003: Tachyon Slave 0000 01 00 00 00 00 00
0004: Tachyon Slave 0000 01 00 00 00 00 00
0005: Tachyon Slave 0000 01 00 00 00 00 00
0006: Tachyon Slave 3A73 01 00 00 00 00 00
0007: Tachyon Slave 3AD4 01 00 00 00 00 00 ok

.
.
.
.

This is so very helpful for interactive development and has made the return to FORTH fun, thanks Peter. Current DropBox V2 file and Extend.fth running well on PBOE.

[nglordi]

Peter:

I think that having a Tachyon OBEX is a good idea. It certainly would be useful to have the C3 spi words file listed in the Dropbox folder.
I will change my approach to adding comments to forth words and adopt your suggestion.

I have a question concerning EXECUTE and how it is used. In PropForth, one can do the following: ' <word> execute. I haven't been able to do this in Tachyon. I am interested in defining deferred words - in this example <word> is deferred and can be replaced with other words, depending on circumstances.

NickL

[Peter Jakacki]

The Parallax C3 represents an interesting board for a Tachyon installation. The C3 includes 5 spi devices: flash memory, 2 32K sram chips, a 2 channel adc, and the sd card, all of which are multiplexed through a 4 bit counter. Two pins are used to control the chip select. The Tachyon code for selecting spi devices on the C3 is shown below.
<snip>
The attached file 'C3SPI.fth" includes the basic spi words and basic commands needed to access the flash & sram memory as well as the
adc. The second file, 'SDCARD_MOD.fth, is a modified version of SDCARD.fth for the C3. It uses the spi words defined in C3SPI. These words work with Tachyon V1.1. I have not tried Tachyon V2 at this time.

NickL

Thanks Nick, do you want me to put these files in the Dropbox folder and perhaps link to them? It's starting to look like I need to create my own organized Tachyon OBEX! (BTW, the ! at the end of OBEX might mean what it means or it might also mean "store to OBEX" )

Just a little comment about comments too. If you place your stack comment after the name then it looks a little bit more familiar to those not familiar with Forth plus very soon my compiler will take that stack comment plus any other comment after it and place that automatically in a help section in EEPROM or SD etc. So instead of:
\ ( b -- ) Write 1 byte to memory at paddr, incrementing the page address.
pub WRITE

You could write:
pub WRITE ( b -- ) \ Write 1 byte to memory at paddr, incrementing the page address.

The stack comment and description are ignored at present but may be used later for help files and possibly local variable declarations too so therefore stack comments can be a bit more verbose for parameter names in anticipation of that feature and being able to reference the stack by symbol name.

[nglordi]

The Parallax C3 represents an interesting board for a Tachyon installation. The C3 includes 5 spi devices: flash memory, 2 32K sram chips, a 2 channel adc, and the sd card, all of which are multiplexed through a 4 bit counter. Two pins are used to control the chip select. The Tachyon code for selecting spi devices on the C3 is shown below.

#8   MASK  CONSTANT .spck
#25  MASK  CONSTANT .spcs

BYTE chan

\ ( n1 -- ) Select channel: n1 is 1 - Sram bank 0     2 - Sram bank 1   3 - Flash  4 - A/D   5 - SD Card
: SPSET  chan C!  ;

\ ( on/off -- ) Selects\Deselects C3 spi channels
: SPSEL
    .spcs OUTCLR  .spcs OUTSET     
    IF .spck OUTCLR
       chan C@ 0 DO .spck OUTSET .spck OUTCLR LOOP 
    THEN ;

The attached file 'C3SPI.fth" includes the basic spi words and basic commands needed to access the flash & sram memory as well as the
adc. The second file, 'SDCARD_MOD.fth, is a modified version of SDCARD.fth for the C3. It uses the spi words defined in C3SPI. These words work with Tachyon V1.1. I have not tried Tachyon V2 at this time.

NickL

[Peter Jakacki]

[QUOTE=Powersoft;1126826]

You made a mistake when you went to read the device because you used $92 to address it but it needs to have the R/W bit set so that it should be $93. There is no need to continually initialize the device every time you read plus my example left the device pointing to register 0 so that you could always just read the temperature without having to set the pointer.

With regards to the config register it looks like my code lost the (percentage 01) just before the 100000 It was okay in the text document but must have had some hungry keys eating up a couple of characters but anything was possible because I was very tired for a change!

BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)



Please find my working version.

: TMP75 ( ch -- dev )
2* $90 +
;

\ Initialize the configuration register
: !TEMP ( ch -- )
$0E $0F I2CPINS
I2CSTART TMP75 DUP I2C! \ Address device
1 I2C! \ address configuration register
$60 I2C! \ Set 12-bit resolution + defaults
I2CSTART I2C! \ Readdress to set default register as temperature
0 I2C!
I2CSTOP
;

\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch )
I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode)
0 I2C@ 0 I2C@ \ Fetch two bytes from device,
\ First byte is temperatuur
\ Second byte is fraction
I2CSTOP
4 SHR \ Remove last 4 bits second byte
$271 * \ Each bit = 0.0625 degree C
SWAP \ print fancy format
. ." ." . ." C" CR \ Print temperatuur as xx.yyyy C
;

So it looks like my code did work then (expect for the obvious dropped characters in the configuration).

If you want to make it more general-purpose and in line with the proven Forth philosophy of factoring functions then you would leave TEMP@ simply as a word that fetches the raw temperature data and leaves it on the stack. So it's far better for debugging and reading to factor out the I2CPINS function and the conversion and printing into your own application specific word such as ShowTemp or anything like that. Also noticed that you used $271 instead of a far more readable #625 or 625d which directly corresponds with the comment. So if you factor into general and specific words you will have a far easier time testing and especially later on when you have to read your own code you may actually save some hair!.

[Peter Jakacki]

<snip>
Unfortunately compatibility requires me to support the old syntax:
!CMD100;349<cr/lf>

Options:
1: write a parser (I read in a Forth book, 'try to use Forth's parser instead writing your own ...)

2: so I thought since you use HS-SerialRxL to do some preprocessing on the input stream I could extend this approach to convert
!CMD100;349 to 100 349 CMD and feed it to Tachyon to do the work

3: or modify the Tachyon parser by intercepting the 'word not defined' error, then checking for the pattern !CMDxxx:yyy or even !CMDxxxxx;yyyyy;zzzzz;qqqqq then do the transformation and feed the new tokens into the input strean for further processing.

which approach would you advise me to go?

Unfortunately many command syntaxes do not have any general-purpose means of parsing in that they do not have clearly defined delimiters for one. At least if the command was written as "!CMD;100;349" then that would be far easier to set Forth to have the ";" delimiter as well as <CR>. I assume they at least include a <CR> at the end too? You can scrub out approach 2 as the preprocessing it does is fairly simple and has to do it in real-time between characters.

Approach 1 with writing a simple parser will work though as you don't have to do all the processing, it may be that the command like !CMD is fixed size or always delimited by a digit etc. So you could parse this to the point of plucking out commands and parameters and pass this through the normal word interpreter. Which reminds me, I must see about including an equivalent INTERPRET command which can take a string and process it as if it were terminal input.

If you would like to maintain normal operation of Forth from the terminal command line then integrating approach 1 with approach 3 will work also. The only downside is that there will be a small delay before control is passed to your parser as the dictionary is searched first and then an attempt is made to convert it to a number.

[MJB]

I am not sure if this is the right thread - but since the question is directly to Peter ...

while in the hot bathtub my mind was circling around Tachyon ...
and now I need to ask ...

I want to use a prop-board as a front end for a legacy test system.
Following Tachyon and this thread quite some time it seems to fullfill my needs for handling of interactive commands and downloadable test scripts.

commands are simple and would look s.th. like this in Tachyon:
100 349 CMD
12 46 DMD ... 0 to 4 16Bit Integer arguments + 3 Char Command

so quite simple to do in Forth.
Unfortunately compatibility requires me to support the old syntax:
!CMD100;349<cr/lf>

Options:
1: write a parser (I read in a Forth book, 'try to use Forth's parser instead writing your own ...)

2: so I thought since you use HS-SerialRxL to do some preprocessing on the input stream I could extend this approach to convert
!CMD100;349 to 100 349 CMD and feed it to Tachyon to do the work

3: or modify the Tachyon parser by intercepting the 'word not defined' error, then checking for the pattern !CMDxxx:yyy or even !CMDxxxxx;yyyyy;zzzzz;qqqqq then do the transformation and feed the new tokens into the input strean for further processing.

which approach would you advise me to go?

I am quite new to prop and forth, but can read and understand extend.fth already mostly. And I am heavily working through TachyonV2 and Prop ASM.
TachonV1 was running on my PropBoE, V2 I try tomorrow.

Kind regards MJB Markus from Germany

[Powersoft]

[QUOTE=Peter Jakacki;1126805]You made a mistake when you went to read the device because you used $92 to address it but it needs to have the R/W bit set so that it should be $93. There is no need to continually initialize the device every time you read plus my example left the device pointing to register 0 so that you could always just read the temperature without having to set the pointer.

With regards to the config register it looks like my code lost the (percentage 01) just before the 100000 It was okay in the text document but must have had some hungry keys eating up a couple of characters but anything was possible because I was very tired for a change!

BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)

It is'nt working.
<snip>
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C@ \ READ FIRST BYTE
$01 I2C@ \ READ LAST BYTE
I2CSTOP \ STOP TRANSMISSION
;

Please find my working version.

: TMP75 ( ch -- dev )
2* $90 +
;

\ Initialize the configuration register
: !TEMP ( ch -- )
$0E $0F I2CPINS
I2CSTART TMP75 DUP I2C! \ Address device
1 I2C! \ address configuration register
$60 I2C! \ Set 12-bit resolution + defaults
I2CSTART I2C! \ Readdress to set default register as temperature
0 I2C!
I2CSTOP
;

\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch )
I2CSTART TMP75 1+ I2C! \ Form I2C address & address chip (blind mode)
0 I2C@ 0 I2C@ \ Fetch two bytes from device,
\ First byte is temperatuur
\ Second byte is fraction
I2CSTOP
4 SHR \ Remove last 4 bits second byte
$271 * \ Each bit = 0.0625 degree C
SWAP \ print fancy format
. ." ." . ." C" CR \ Print temperatuur as xx.yyyy C
;

[Peter Jakacki]

You made a mistake when you went to read the device because you used $92 to address it but it needs to have the R/W bit set so that it should be $93. There is no need to continually initialize the device every time you read plus my example left the device pointing to register 0 so that you could always just read the temperature without having to set the pointer.

With regards to the config register it looks like my code lost the (percentage 01) just before the 100000 It was okay in the text document but must have had some hungry keys eating up a couple of characters but anything was possible because I was very tired for a change!

BTW, did you try my code at all? Also Tachyon uses common prefix and suffixes for numbers so binary is either (percent)0100 or 0100b (argghhh, forum code keeps eating the percent symbol)

[QUOTE=Powersoft;1126802]It is'nt working.
<snip>
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C@ \ READ FIRST BYTE
$01 I2C@ \ READ LAST BYTE
I2CSTOP \ STOP TRANSMISSION
;

[Powersoft]

This code looks like it should work but I don't have a chip to try it on.

{ Access TMP75 temperature chip
These routines allow for multiple TMP75 devices to share the bus.

Usage:
1 !TEMP            \ Initialise device #1 (address $92)
1 TEMP@ CELCIUS        \ Read temperature from device #1 and convert to Celcius

}

\ 
: TMP75 ( ch -- dev )
    2* $90 +
    ;
    
\ Initialize the configuration register
: !TEMP ( ch -- )
    I2CSTART TMP75 DUP I2C!        \ Address device
    1 I2C!                \ address configuration register
    100000 I2C!            \ Set 12-bit resolution + defaults
    I2CSTART I2C!            \ Readdress to set default register as temperature
    0 I2C!
    I2CSTOP
    ;
    
: CELCIUS ( temp12 -- celcius )
    1+ 4 SHR DUP $80 AND IF $FFFF.FF00 OR THEN
    ;
\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch -- temp12 )
    I2CSTART TMP75 1+ I2C!        \ Form I2C address & address chip (blind mode)
    0 I2C@ 0 I2C@ 8 SHL OR        \ Fetch two bytes from device and combine into one word 
    I2CSTOP
    ;
    

It is'nt working.

This is the code I tried but also no response

: TMP75_INIT
$0E $0F I2CPINS \ SET THE I2C PINS FOR THE ASC+ BOARD
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$01 I2C! \ REGISTER
$60 I2C! \ CONFIGURE
I2CSTOP \ STOP TRANSMISSION
;

: TMP75@
TMP75_INIT
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C! \ SET POINTER REGISTER TMP75 TO 0
I2CSTOP \ STOP TRANSMISSION
500 ms \ 0.5 SEC DELAY
I2CSTART \ BEGIN TRANSMISSION
$92 I2C! \ ADDRESS DEVICE
$00 I2C@ \ READ FIRST BYTE
$01 I2C@ \ READ LAST BYTE
I2CSTOP \ STOP TRANSMISSION
;

Tis looks a little bit strange for me in the code you wrote

100000 I2C! \ Set 12-bit resolution + defaults

I think this should @60 or B01100000

I tried also the slow version no results.
It is working on the arduino, but not on the ASC+ board.

[Peter Jakacki]

Good news for multi-taskers! The task functions have been expanded and so you should use the new kernel and extensions. Support includes finding the next free Tachyon cog available for a task.

TASKS
0001: Tachyon Console 0000 00 00 00 00 00 00
0003: Tachyon Slave 0000 01 00 00 00 00 00
0004: Tachyon Slave 0000 01 00 00 00 00 00
0005: Tachyon Slave 0000 01 00 00 00 00 00
0006: Tachyon Slave 3A73 01 00 00 00 00 00
0007: Tachyon Slave 3AD4 01 00 00 00 00 00 ok


The EXTEND.fth has the new multichannel PWM task included as well as a background timer task.
The PWM has up to 8 channels per task with 8-bit resolution at up to 5kHz. It's also possible to run some PWM channels at a multiple of the base frequency with less resolution. If you want more channels you can run another instance as another task. If there is interest I will also include a 32-channel version I have which just means that you can pick whichever pins you want for PWM.

USAGE:
( implement 8 PWM channels on P0..P7 )
\ setup area for PWM values
TABLE pwm #256 ALLOT
\ Set the frequecy
#1000 PWMFREQ
\ Start up PWM using from P0 for 8 channels (will find the next free cog to use)
0 8 pwm RUNPWM
\ Set PWM channel 0 for 50%
$80 0 PWM!
\ Set PWM channel 7 for 25%
#25 % 7 PWM!

Many applications need some kind of background polling and timing which is what the timer task does. You can launch this in a cog and it will maintain an elapsed time in milliseconds which won't wrap-around for over 49 days plus maintain the number of countdown timers you specify. When these timers countdown to zero they automatically stop and if you have set a timeout vector for that timer then it will execute that automatically.

USAGE:
( Create 8 countdown timers and assign a BLINKY function to timer 0 )
\ Allocate space for 8 timers at 8 bytes each
TABLE mytimers #64 ALLOT
\ pass parameters to start timer task
mytimers 8 RUNTIMERS
\ demo LED flasher which takes 5 seconds before it starts flashing every 100ms
: BLINKY
#16 PIN@ 0= #16 PIN! \ toggle pin 16
0 TIMER 6 + W@ 0 TIMER ! \ reload timer using stored value in timer memory
;
\ Setup the timeout vector for TIMER 0
' BLINKY 0 TIMER 4 + W!
\ Write a reload value to timer's memory
#100 0 TIMER 6 + W!
\ Setup timer 0 to timeout in 5 seconds
#5,000 0 TIMER !

The timer functions will be expanded upon to include virtual RTC support which will also automatically detect an I2C RTC if present and hopefully figure out what device it is to correctly interface to it. RTC API is non-device specific and includes fetching and storing date and time strings and longs.

V2 source code page link will now be included in the links section of the Intro page.

[Peter Jakacki]

This code looks like it should work but I don't have a chip to try it on.

{ Access TMP75 temperature chip
These routines allow for multiple TMP75 devices to share the bus.

Usage:
1 !TEMP            \ Initialise device #1 (address $92)
1 TEMP@ CELCIUS        \ Read temperature from device #1 and convert to Celcius

}

\ 
: TMP75 ( ch -- dev )
    2* $90 +
    ;
    
\ Initialize the configuration register
: !TEMP ( ch -- )
    I2CSTART TMP75 DUP I2C!        \ Address device
    1 I2C!                \ address configuration register
    100000 I2C!            \ Set 12-bit resolution + defaults
    I2CSTART I2C!            \ Readdress to set default register as temperature
    0 I2C!
    I2CSTOP
    ;
    
: CELCIUS ( temp12 -- celcius )
    1+ 4 SHR DUP $80 AND IF $FFFF.FF00 OR THEN
    ;
\ Read the temperature data from the chip - assumes temperature register is selected (via !TEMP)
: TEMP@ ( ch -- temp12 )
    I2CSTART TMP75 1+ I2C!        \ Form I2C address & address chip (blind mode)
    0 I2C@ 0 I2C@ 8 SHL OR        \ Fetch two bytes from device and combine into one word 
    I2CSTOP
    ;
    

[Peter Jakacki]

Yes, but only if it's been connected that way, so A0 = pin 7 on the chip is tied high for sure. Just having a look at it now so I will get back shortly with the code.

[Powersoft]

SCRUB THIS - IT'S NOT QUITE RIGHT - I NEED TO READ THE DATASHEET MORE CLOSELY

The base 8-bit address of the TMP75 is $90 but there are three address pins that can allow 8 devices with addresses from $90..$9E so the $92 in the example is not the normal default address. Check your connections.
Basically you need to write to the device to set it's pointer register which if set to 2 then addresses Tlow followed by Thigh. So after the set pointer operation you need to start again in read mode to read these registers. Like this:
I2CSTART $90 I2C! 2 I2C!
I2CSTART $91 I2C! 0 I2C@ 1 I2C@ I2CSTOP

Combine that code into a more general-purpose word that can address one of several devices:

: TEMP@ ( ch -- temp )
    I2CSTART 2* $90 +        \ Form I2C address  
    DUP I2C!            \ Address chip (blind mode)
    2 I2C!                \ and write 2 as the next byte to set register pointer to 2
    I2CSTART 1+ I2C!        \ Now use I2C address but set R/W to 1 (1+)  
    0 I2C@ 1 I2C@ 8 SHL OR        \ Fetch two bytes from device and combine into one word
    I2CSTOP
    ;

BTW, The code 0 I2C@ means fetch a byte and send a low for the acknowledge (keep reading more) while 1 I2C@ will fetch a byte but not acknowledge this as this is the last byte to read.

As you see the address is really $92


I2CBUS
Fast Device at 0000 FF FF FF FF FF FF FF FF
Slow Device at 0070 80 80 80 80 80 80 80 80
Fast Device at 0092 1C F0 FF FF FF FF FF FF
Fast Device at 00A0 FF FF FF FF FF FF FF FF ok

[Peter Jakacki]

Thanks Peter ... now I am left with one question on this matter ... should there now be a choice for me <BEGIN ... UNTIL> versus BEGIN ... UNTIL ? If so what do I consider in selecting one or the other? ... OOOORRRRR just use <BEGIN ... UNTIL> and forget about the latter.

If you are not sure just use the regular BEGIN..UNTIL since you can force an exit from this without consequences. The <BEGIN..UNTIL> should only be used if it's a clean loop, that is, it is structured in having only one entry and one exit. So don't bother with these special words then.

[Peter Jakacki]

Qustion about the I2C

I have now a working 7-segment display version.
What I am try to do is use the TMP75 thermomether to read.
When I look to the original Arduino code it looks like

while (1)
{
Wire.RequestFrom($92,2) / request 2 bytes from register TMP75
t_H=Wire.receive() \ Get register-0
t_L=Wire.receive() \ Get register-1
.........
}


How can't this be translate into the I2C routines of TACHYON

SCRUB THIS - IT'S NOT QUITE RIGHT - I NEED TO READ THE DATASHEET MORE CLOSELY

The base 8-bit address of the TMP75 is $90 but there are three address pins that can allow 8 devices with addresses from $90..$9E so the $92 in the example is not the normal default address. Check your connections.
Basically you need to write to the device to set it's pointer register which if set to 2 then addresses Tlow followed by Thigh. So after the set pointer operation you need to start again in read mode to read these registers. Like this:
I2CSTART $90 I2C! 2 I2C!
I2CSTART $91 I2C! 0 I2C@ 1 I2C@ I2CSTOP

Combine that code into a more general-purpose word that can address one of several devices:

: TEMP@ ( ch -- temp )
    I2CSTART 2* $90 +        \ Form I2C address  
    DUP I2C!            \ Address chip (blind mode)
    2 I2C!                \ and write 2 as the next byte to set register pointer to 2
    I2CSTART 1+ I2C!        \ Now use I2C address but set R/W to 1 (1+)  
    0 I2C@ 1 I2C@ 8 SHL OR        \ Fetch two bytes from device and combine into one word
    I2CSTOP
    ;

BTW, The code 0 I2C@ means fetch a byte and send a low for the acknowledge (keep reading more) while 1 I2C@ will fetch a byte but not acknowledge this as this is the last byte to read.

[Brian Riley]

So functionally these are the same but stacked branches can be faster and also easier especially when coding bytecode in DAT structures in the Spin tool. The <BEGIN and UNTIL> are the actual bytecodes whereas BEGIN UNTIL etc are compiler control words that decide what needs to be compiled. So actually the stacked branch instructions simplfy the compiler too.

Thanks Peter ... now I am left with one question on this matter ... should there now be a choice for me <BEGIN ... UNTIL> versus BEGIN ... UNTIL ? If so what do I consider in selecting one or the other? ... OOOORRRRR just use <BEGIN ... UNTIL> and forget about the latter.

[Powersoft]

Qustion about the I2C

I have now a working 7-segment display version.
What I am try to do is use the TMP75 thermomether to read.
When I look to the original Arduino code it looks like

while (1)
{
Wire.RequestFrom($92,2) / request 2 bytes from register TMP75
t_H=Wire.receive() \ Get register-0
t_L=Wire.receive() \ Get register-1
.........
}


How can't this be translate into the I2C routines of TACHYON

[Peter Jakacki]

OK Peter,
Please explain to those of us amongst the vast unwashed, the finer points of what the difference between <BEGIN ... UNTIL> and BEGIN ... UNTIL ...... inquiring minds want to know! ;-]

Internally in the Spin tool compiled kernel they are handy as I do not need to specify a branch address. Externally they are a little more useful in fast and tight loops as they minimise the overhead of looping. They are an extension of DO...LOOP & FOR..NEXT in that these were made as stacked branches using markers that are setup when the loop begins as they loop faster. The stacked branch also does not have a range limit whereas the displacement in the standard bytecode is limit to -255.

The traditional approach for BEGIN....UNTIL is for BEGIN to leave a marker at compile time (but no code) which UNTIL checks and compiles a conditional branch along with a branch address. where we look at this code example from PWM.fth both ways.

\ code snippet with conventional BEGIN UNTIL
    BEGIN
      CLOCK OVER DELTA
      CLOCK DUP DELTA
      KEY? AND            \ keep doing this until we hit a key
    UNTIL
        
\ compiles as 
addr    CLOCK OVER DELTA
addr+3    CLOCK DUP DELTA
addr+6    KEY? AND
addr+9    (UNTIL),11            \ Conditional branch instruction plus displacement backwards to "addr" (IP-11)


\ code snippet using stacked BEGIN UNTIL
    <BEGIN
      CLOCK OVER DELTA
      CLOCK DUP DELTA
      KEY? AND            \ keep doing this until we hit a key
    UNTIL>    

\ compiles as
addr    <BEGIN                \ Compiles the <BEGIN opcode which actually pushes the IP onto the marker stack
addr+1    CLOCK OVER DELTA
addr+4    CLOCK DUP DELTA
addr+7    KEY? AND
addr+10    UNTIL>                \ UNTIL> pops from the top of the marker stack into the IP (equivalent to JUMP TO MARK ADDRESS)

So functionally these are the same but stacked branches can be faster and also easier especially when coding bytecode in DAT structures in the Spin tool. The <BEGIN and UNTIL> are the actual bytecodes whereas BEGIN UNTIL etc are compiler control words that decide what needs to be compiled. So actually the stacked branch instructions simplfy the compiler too.

[Brian Riley]

OK Peter,
Please explain to those of us amongst the vast unwashed, the finer points of what the difference between <BEGIN ... UNTIL> and BEGIN ... UNTIL ...... inquiring minds want to know! ;-]

[Peter Jakacki]

Played a little more with multichannel PWM and came up with this one for starters. It can run 8 channels of 8-bit PWM at 183Hz. I will do another version where I will tweak the kernel a little so I should be able to do 1KHz comfortably.

EDIT: Go to this page for the 1kHz version (at the bottom of the page)

BYTE pwmpins,pwmcnt
TABLE pwm #256 ALLOT

: PWMCOG 
    pwmpins C@ pwmcnt C@ MASKS OUTCLR
    #1700 DELTA
    <BEGIN 
      pwm $100 
      ADO 
        I C@ pwmpins C@ SHL P!
        WAITCNT
      LOOP
    AGAIN>
    ;
    
: PWM! ( duty8 ch -- )
    MASK
    pwm 3RD            \ set duty cycle high    
    ADO
      DUP I SET  
      LOOP
    $100 3RD - ROT pwm + SWAP
    ADO
      DUP I CLR
      LOOP
    DROP
    ;

' PWMCOG CONSTANT #pwmcog

: RUNPWM ( pwmpins pwmcnt -- )
    pwmcnt C! pwmpins C!
    #pwmcog 4 RUN
    ;

: % ( %duty -- duty8 )
    8 SHL #100 /
    ;
    
\ Usage: 
0 8 RUNPWM    \ Starts up COG 4 to use pins 0 to 7
$80 0 PWM!    \ Set PWM channel 0 for 50%
#25 % 7 PWM!    \ Set PWM channel 7 for 25%

[Peter Jakacki]

Peter

Is there a chance for getting an example of PWM in TACHYON?

Jan Kromhout
Hellevoetsluis-NL

Here's a bit of quick code to play with. It runs at about 833Hz and for testing purposes it will exit on a key press. You can have this run inside another cog and have it read a hub variable each time to change it's duty cycle.
I will continue to look at improvements and multichannel operation etc.

: PWM ( duty pin -- )
    SWAP #100 MIN
    #1000 * #100005 OVER - ROT    \ Scale to lower frequency ( duty off pin ) 
    <BEGIN
      DUP PINSET
      3RD DELTA
      DUP PINCLR
      OVER DELTA
      KEY? AND
    UNTIL>    
    3DROP
    ;

[Peter Jakacki]

Peter

Is there a chance for getting an example of PWM in TACHYON?

Jan Kromhout
Hellevoetsluis-NL

I'm having a look at it right now. You know that there is a really easy neat method for getting 50 to 100% PWM by using 2 counters with only an initial setting and no maintenance software? Anyhow, I will play with some variations of PWM.

[Powersoft]

Peter

Is there a chance for getting an example of PWM in TACHYON?

Jan Kromhout
Hellevoetsluis-NL

[Peter Jakacki]

I am having problems getting VECTORS to work. Specifically, what are the definitions of index, range, and limit with respect to VECTORS?

Also what does LOOKUP do?

NickL

Hi NIck, funny thing is someone just asked me that question in an email. I will try to insert some explanatory notes in the source document for some of these special words. Basically VECTORS or it's alias LOOKUP just does a simple indexed lookup in a jump table but with a range check and default execution vector. Here is my explanation from the email.

In regard to CASE did you see how VECTORS (or LOOKUP) is being used in CHARLCD.fth?


pub LCDCTRLS ( ctrl -- ) '' Look up and execute the code that corresponds to the ctrl character
$10 LOOKUP LCDchar { Default vector if equal or above limit of $10 }

NOP LCDHOME LCDchar LCDINIT
LCDchar LCDchar LCDchar BEEP
LCDchar LCDchar LCDLF LCDchar
LCDCLS LCDCR LCDchar LCDchar
;

So all that LOOKUP basically does is execute one of the words in the list depending upon the index so that 0 execute NOP and 1 executes LCDHOME etc. But to help the application along you need some range checking otherwise a large index could execute garbage outside the table which is why we have:

$10 LOOKUP LCDchar

So $10 is the ceiling and if anything reaches the ceiling (BTW, including $10) then it won't index into the table but execute a default word which is LCDchar.

[nglordi]

I am having problems getting VECTORS to work. Specifically, what are the definitions of index, range, and limit with respect to VECTORS?

Also what does LOOKUP do?

NickL

[Peter Jakacki]

I was able to build V2 with the lastest HS-SerialRxL, Extend and SDCard extensions sucessfully and they work correctly on the Prop BOE. I thought my last message stated PBOE was at issue, I will be more specific next time I report any problems or self induced errors.

I saw it was a PBOE but I wasn't sure which files they were, whether they were the Dropbox (stable) or Google files (bleeding edge). It can be a juggle.

[D.P]

Alright, V2 has been stitched up again with a few changes externally. Something to note is that I wanted to fix the ' (tick) word up so that it returned the actual "parameter field address" or bytecode address rather than anything to do with the header. So tick does not require a >PFA to convert it, I know that's a pain but it'll pass. If you want the name field address or NFA just use NFA' and from there NFA>CFA which points to the CFA although it's not really a CFA the same as conventional Forths.

[/FONT]

I was able to build V2 with the lastest HS-SerialRxL, Extend and SDCard extensions sucessfully and they work correctly on the Prop BOE. I thought my last message stated PBOE was at issue, I will be more specific next time I report any problems or self induced errors.

[Peter Jakacki]

Yes, I have come across that and I am now working on it. Since BACKUP is doing a full 32K backup it looks like there is one small area in the Spin initialization code for the serial object that I just need to fix.

[Brian Riley]

I was able to build v1.1 on a Propeller Platform USB with SD just fine. Shifting down to 115200 baud from 230400 I was able to build 2.0 on a PropBOE and Propeller Platform Through hole with add-on uSD. The only glitch I see is after I manually initiate a BACKUP for the SD words on V2/PropBOE subsequent invocations of BACKUP can produce a non functioning boot image.

[Peter Jakacki]

Alright, V2 has been stitched up again with a few changes externally. Something to note is that I wanted to fix the ' (tick) word up so that it returned the actual "parameter field address" or bytecode address rather than anything to do with the header. So tick does not require a >PFA to convert it, I know that's a pain but it'll pass. If you want the name field address or NFA just use NFA' and from there NFA>CFA which points to the CFA although it's not really a CFA the same as conventional Forths.

Everything else should work the same it's just that the dictionary got a count byte added to it to help speed up searching and jumping to the next entry. Originally I was going to run the dictionary totally out of EEPROM and it didn't make any sense to try and jump to the next name as this just slows down an uncomplicated sequential read. Now however the dictionary includes the count byte in the compare string function so it can lead to an earlier reject and skip on to the next. In the precompiled source code it was too much of a pain to have to calculate the length of each entry and manually insert it so I just inserted a dummy byte before each name in the dictionary and have a startup routine scan the dictionary and fill in the count for me (I'm lazy).

Since the dictionary builds down and scans forward there is no need for a link field as it is very easy to get to the next name either by using the count byte + fixed offset or scanning forward to the attribute byte with it's 8th bit set.

BACKUP just does a simple byte for byte backup of the 32K of RAM to EEPROM now as there is no overwriting of cog images etc since I gave the serial buffer it's own 1K RAM (I'm generous).
EDIT: Use the latest version of HS-SerialRxL from the Dropbox folder
I'm not worried about using a bit more RAM at present as the time will come when I get serious about reclaiming memory. In the meantime it's about functionality. I've tested EXTEND.fth and SDCARD.fth and they are all working well so V2 is fine to use 'as is' while I progress onto the next stage of having the user dictionary running from EEPROM or far more preferably SD or SPI memory where it will page into RAM. Have a look at these two 4K loads:
8000 6000 1000 NEWCNT XLOAD .LAP 5,192us ok
8000 6000 1000 NEWCNT ELOAD .LAP 202,755us ok
Big difference, the SD memory reads in a 4K chunk in 5ms vs the 202ms with the EEPROM and the SD code is not even fully optimized yet.


Here's the current hex map of the 32K of RAM (each "byte" = 64 bytes averaged) EDIT: used average instead of OR'ed
0 8000 MAP
0000: 1E 00 00 00 00 00 43 77 6C 66 6B 67 74 6A 6D 7C
0400: 6F 5C 72 7F 91 7C 76 6F 7E 76 76 71 A1 9E 93 7A
0800: 5C 00 00 01 11 0A 1A 05 2D 62 62 5A 47 50 54 89
0C00: 8D 7D 87 4F 4B 3C 54 5E 57 53 58 4D 4D 5C 52 65
1000: 65 71 68 59 57 71 75 77 7A 7A 5F 4E 64 61 55 66
1400: 60 57 53 53 4E 5C 68 64 78 6C 76 60 3E 50 43 18
1800: 19 26 2D 28 1C 20 2F 3B 1F 30 33 3D 48 FF FF FF
1C00: FF FF FF FF FF FF FF FF FF FF FF FF FF F2 53 4A
2000: 49 56 74 6B 6D 68 68 74 67 66 62 5D 60 37 32 39
2400: 37 36 40 3F 42 49 4B 4B 46 50 50 50 52 54 53 50
2800: 48 53 52 53 52 51 56 59 5B 6E 6E 6F 5B 57 5D 64
2C00: 5A 64 5C 5E 29 06 0B 08 12 11 0E 07 0D 10 10 80
3000: 4B 2C 32 31 38 3A 3B 3D 3E 3C 3B 3A 3A 3D 3D 43
3400: 69 7F 6F 6D 78 8B A9 69 04 00 00 00 00 00 00 00
3800: 3A 29 56 3D 58 44 47 67 7F 63 67 7C 79 67 55 63
3C00: 55 5E 4D 6F 5F 75 7C 62 63 6D 4F 6B 61 66 66 71
4000: 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4C00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5C00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6C00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7C00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok

[Peter Jakacki]

Using the current V2, Extend.fth, SDCard.fth in the dropbox on the PBOE (with the correct SD pins now $17181619 SDPINS) everything compiles and I2CBUS works correctly. However I can't get the SD card to work now with a constant "SD Card Error" no matter which version of Extend and SDCard extensions I try with V2. Everything works correctly with V1.1 FYI

Alas, V2 is splayed open on the operating table with it's gizzards out and stitching it back together bit by bit. However the Dropbox version should be fine as it won't get updated until I'm happy with the changes. If you are using a BOE configuration then bear in mind that I have coded in a separate card detect routine to suit it however the earlier version had a small bug. Since all the commands and primitives are available it is very easy to find out what is going wrong if you are adventurous enough. It is a lot of fun just interacting with the card and the SD commands to see how they respond and what happens if....
So if this is a bug report then could you please let me know the configuration as well, thanks.

[D.P]

Since V2 at this present moment seems quite stable I am releasing it into the Dropbox folder along with the HS-SerialRxL object. The Google document is available for those who have the link but it is not always stable as this is the main document I use for development. The HS-SerialRxL object includes a symbol decoder and filter so that it automatically detects a source code load via the [~ symbols which I believe would be unique enough to not encounter normally. Once it detects this symbol it will switch on filtering which removes redundant whitespace, strips out all forms of comments (except the double tick versions '' ). The tilde symbol is checked by the object and then it looks at the last character received before this and processes this as a command (or none). Since the symbol is passed through the object I also have these defined in EXTEND.fth as a little bit more than just a dummy definition. They also turn "echo" on or off thus removing most of the echoed characters during load. Eventually the output will be clean expect for line numbers and error messages etc.

I've also reduced my standard baud rate to 921600 which is the maximum that TeraTerm can handle plus it's also a standard baud rate that the Bluetooth modules can handle too. The line delay on my Minicom is set to 25ms which is a compromise between compilation speeds and receive buffer size which is set to 1K.
Currently V2 just has these enhancements along with the faster stacked branch operations. Once I have tested the next lot of enhancements I will update the Dropbox files. At present the .fth files are compatible and I will try to keep them that way, at least until V2 progresses to V2.1.

Using the current V2, Extend.fth, SDCard.fth in the dropbox on the PBOE (with the correct SD pins now $17181619 SDPINS) everything compiles and I2CBUS works correctly. However I can't get the SD card to work now with a constant "SD Card Error" no matter which version of Extend and SDCard extensions I try with V2. Everything works correctly with V1.1 FYI

[Powersoft]

I modified I2CBUS immediately after my previous post to just do a slow scan and pick everything up. All the faster devices will work at the slower speed as it is really only the device's internal noise filter that's different on the newer devices.

However I have just redone I2CBUS (maybe that should be called I2CSCAN) so that it detects the speed of devices and reports. I could get fancy and try to tell you what the device is etc but that can get a little complicated too as I have an RTC chip that responds as if it is a second EEPROM. Here's the output from I2CBUS:
I2CBUS
Slow Device at 0070 00 00 00 00 00 00 00 00
Fast Device at 00A0 00 F3 34 00 00 FC 34 00 ok

Thanks for this quick service!

[Peter Jakacki]

Should be fine when there is a slow version for testing the I2CBUS
I have no knowledge about this, but can you detect with a slower version a fast version?

I modified I2CBUS immediately after my previous post to just do a slow scan and pick everything up. All the faster devices will work at the slower speed as it is really only the device's internal noise filter that's different on the newer devices.

However I have just redone I2CBUS (maybe that should be called I2CSCAN) so that it detects the speed of devices and reports. I could get fancy and try to tell you what the device is etc but that can get a little complicated too as I have an RTC chip that responds as if it is a second EEPROM. Here's the output from I2CBUS:
I2CBUS
Slow Device at 0070 00 00 00 00 00 00 00 00
Fast Device at 00A0 00 F3 34 00 00 FC 34 00 ok

[Powersoft]

Yes, the I2C now runs at 400kHz which is why my SAA1064 driver accesses the slower I2C! method SI2C!. Perhaps I can get I2CBUS to scan at the slower speed as well as the higher speed. The SAA1064 is quite old when I2C was only ever 100kHz speed whereas many devices these days run at 400kHz.

Should be fine when there is a slow version for testing the I2CBUS
I have no knowledge about this, but can you detect with a slower version a fast version?

[Peter Jakacki]

I2C question

Some week ago I tested the I2C connection with the 7-seg shield from gravitech, this in combination withe ASC+ propeller board.
On this shield is a SAA1064 chip with address $70. The connections worked well, I could send data to this 7-seg display
Yesterday I tried it again with no results.
On the shield are tree I2C devices
I2CBUS was not able to detect the device at address $70.
Tested on a bare arduino board and all was working well.
Is there something changed in the mean time?

Yes, the I2C now runs at 400kHz which is why my SAA1064 driver accesses the slower I2C! method SI2C!. Perhaps I can get I2CBUS to scan at the slower speed as well as the higher speed. The SAA1064 is quite old when I2C was only ever 100kHz speed whereas many devices these days run at 400kHz.

[Powersoft]

I2C question

Some week ago I tested the I2C connection with the 7-seg shield from gravitech, this in combination withe ASC+ propeller board.
On this shield is a SAA1064 chip with address $70. The connections worked well, I could send data to this 7-seg display
Yesterday I tried it again with no results.
On the shield are tree I2C devices
I2CBUS was not able to detect the device at address $70.
Tested on a bare arduino board and all was working well.
Is there something changed in the mean time?

[Peter Jakacki]

Since V2 at this present moment seems quite stable I am releasing it into the Dropbox folder along with the HS-SerialRxL object. The Google document is available for those who have the link but it is not always stable as this is the main document I use for development. The HS-SerialRxL object includes a symbol decoder and filter so that it automatically detects a source code load via the [~ symbols which I believe would be unique enough to not encounter normally. Once it detects this symbol it will switch on filtering which removes redundant whitespace, strips out all forms of comments (except the double tick versions '' ). The tilde symbol is checked by the object and then it looks at the last character received before this and processes this as a command (or none). Since the symbol is passed through the object I also have these defined in EXTEND.fth as a little bit more than just a dummy definition. They also turn "echo" on or off thus removing most of the echoed characters during load. Eventually the output will be clean expect for line numbers and error messages etc.

I've also reduced my standard baud rate to 921600 which is the maximum that TeraTerm can handle plus it's also a standard baud rate that the Bluetooth modules can handle too. The line delay on my Minicom is set to 25ms which is a compromise between compilation speeds and receive buffer size which is set to 1K.
Currently V2 just has these enhancements along with the faster stacked branch operations. Once I have tested the next lot of enhancements I will update the Dropbox files. At present the .fth files are compatible and I will try to keep them that way, at least until V2 progresses to V2.1.

[Brian Riley]

Well, a long evening coding, a long morning testing, and a long afternoon commenting and the servo code inspired by JonnyMac's Servo8 in Spin is done for Tachyon Forth. As requested I tried to comment every line. I did 90% of the work on a PropBOE, Spin Compiles on a recent vintage iMac using 0.8.1 of SimpleIDE subrunning BST and ZTerm for console and TextMate for TF edits.

[nglordi]

I have been experimenting with the TACHYON spi words, which I have generalized, extended and applied to accessing serial flash memory. The code shown below was based on my PropForth SPI application.

 { TACHYON SPI Driver for  Flash Memory   }


''  SPI Words based on Peter Jackabi's spi sd &  mcp3208 wordsets.

'' Pin Masks - adjust to suit.
#27  MASK  CONSTANT .sclk
#26  MASK  CONSTANT .miso
#25  MASK  CONSTANT .mosi
#24  MASK  CONSTANT .spcs

 
\ ( -- )  Initialize spi engine (2.8 MHz).
: SPI
    #8 3 COGREG!
    .miso 2 COGREG!
    .mosi 1 COGREG!
    .sclk  0 COGREG!
    .spcs  OUTSET
    .mosi OUTCLR
    .sclk  OUTCLR   ;

\ ( n1 -- )  n1 is the number of bits to be transmitted.   
: SPCNT  3 COGREG!  ;   

\ (on/off -- )  Selects/Deselects spi memory.
: SPSET  0= .spcs OUT  ;

\ ( -- )  Executes kernel spi engine.
: SPIO  [SPIO] RUNMOD ;

\ ( -- b ) Leaves 1 byte on stack.
: SP@  -1 SPIO $FF AND  ;

\ ( b -- ) Sends 1 byte to device.
: SP!  #24 SHL SPIO DROP ;

\ ( w -- ) Sends 1 word to device.
: SP2!
    DUP #8 SHR SP! SP!  ;

\ ( a -- )  Sends 3 byte address to device.    
: SP3!
    DUP 10 SHR SP! DUP 8 SHR SP! SP! ;

\ ( l -- ) Sends 1 long to device.
: SP4!
    #32 SPCNT SPIO DROP #8 SPCNT ;  

\ ( -- w ) Leaves 1 word on stack.
: SP2@
   SP@  #8 SHL SP@ OR  ;
   
\ ( -- a ) Leaves 3 bytes on stack.
: SP3@
   #24 SPCNT -1 SPIO  8 SPCNT $FFFFFF AND ; 

\ ( -- l) Leaves 1 long on stack.
: SP4@
   #32  SPCNT -1 SPIO  8 SPCNT $FFFFFFFF AND   ;
   
'' SPI Flash Memory Access Wordset

'' Define page and sector sizes in bytes. Adjust to suit specific memory.
'' Values given are for the ST M2516 (Digilent PModSF).
'' Values for the Numonyx Omneo P5Q PCM (Digilent PModSF2) are 64 & 128k and the
'' winbond W25X16 are 256 and 4k.
#256   CONSTANT page
#65536 CONSTANT sector

'' Define input and output buffers as page sizes.
TABLE inbuf  page ALLOT
TABLE outbuf page ALLOT

'' Define the active page address.
LONG paddr


\ ( n1 n2  -- ) Set page n1 (0 - 255) address in sector n2 (0-31).
: PGAD
    page * SWAP sector * + paddr !  ;

\ ( -- ) Clear input buffer.    
: INBUF
    inbuf page 0 FILL  ;

\ ( -- ) Clear output buffer.
: OUTBUF
    outbuf page 0 FILL ;
    
\ ( -- id ) Leaves memory id on stack. Pmod-SF: $202015  Pmod-SF2: $20DA18  
: RDID
    ON SPSET  $9F SP!  SP3@   OFF SPSET  ;

\ ( -- )  Write Enable instruction.
: WREN
    ON SPSET  $06 SP! OFF SPSET  ;
                      
\ ( -- )  Write Disable instruction.
: WRDI
    ON SPSET  $04 SP!  OFF SPSET  ;

\ ( -- b ) Read status register. Leaves byte b on stack   
: RDSR
    ON SPSET  $05 SP!  SP@  OFF SPSET  ;

\ ( b -- ) Write byte b to status register.
: WRSR
    WREN  ON SPSET $01 SP!  SP! OFF SPSET  ;

\ ( n1 -- ) Erase sector n1 (0 - 31). Sets all bits in sector to 1. 
: SE
    WREN  ON SPSET $D8 SP!   sector * SP3! OFF SPSET  ;

\ ( -- ) Bulk (chip)  erase. Sets all bits to 1.
: BE
    WREN  ON SPSET  $C7 SP!  OFF SPSET  ;
    
\ ( n1 - ) Increment page address where n1 is 1, 2, or 4.
: PADDR+
    paddr @ + paddr !  ;


'' The following commands implement th ememory  read instructions.
\ ( -- )  Set READ command.
: RD
    $03 SP! paddr @ SP3!  ;

\ ( -- b ) Read 1 byte from memory at paddr, incrementing the page address.
: READ
     ON SPSET RD  SP@  OFF SPSET 1 PADDR+ ;

\ ( -- w ) Read 1 word from memory at paddr.     
: WREAD
    ON SPSET RD SP2@ OFF SPSET 2 PADDR+ ;
    
\ ( -- l ) Read 1 long from mempry at paddr.
: LREAD
    ON SPSET RD SP4@  OFF SPSET 4 PADDR+ ;

'' The following instructions implement the memory write instructions.
'' For the PModSF2, the following definition of PP should be used so that
'' pages may be written over without erasure, as required with flash memories.
{ : PP $22 SP! paddr @ SP3! ; }

\ ( -- ) Set Page Programming command.
: PP
    $02 SP! paddr @ SP3!  ;

\ ( b -- ) Write 1 byte to memory at paddr, incrementing the page address.
: WRITE
    WREN ON SPSET PP SP! OFF SPSET 1 PADDR+ ;

\ ( w -- ) Write 1 word to memory at paddr.
: WWRITE
    WREN ON SPSET PP SP2! OFF SPSET  2 PADDR+  ;

\ ( l -- ) Write 1 long to memory at paddr.                                                   
: LWRITE
    WREN ON SPSET  PP SP4! OFF SPSET  4 PADDR+  ;

My next step is to revise the PropForth C3 SPI Application for TACHYON.

NickL

[D.P]

I just added the BOE parameters that were handed to me but I double checked the schematic and entered the pin numbers individually using the SDCS SDK MOSI MISO words and had a look at the long it generated and it was different from what was supplied. So the definition has been corrected.
Before it was: $19171816 SDPINS
but after entering:
#25 SDCS
#23 SCK
#24 MOSI
#22 MISO
ok
I read the result as
sdpins @ .LONG 17181619 ok

So the correct long is: $17181619 SDPINS

Thanks Peter, PEBKAC on my part, appreciate all that you have done!

[Brian Riley]

the new numbers work for the BOE. Tried SanDisk and Kingston 2GB uSD cards.

Returning to an earlier post of mine, the BOE SD slot has CS pulled up, thus defeating "KEYPOLL SDPOLL" ... It all works just each time a card is inserted or removed an SD command needs to be done to force TF to take note of SD card change of status.

Peter, does this code handle SDHC cards? I have seen some good prices lately.

[Peter Jakacki]

Okay, thanks for the effort. I'll just be patient and wait until the SD tool kit is further along in Tachyon.

I just added the BOE parameters that were handed to me but I double checked the schematic and entered the pin numbers individually using the SDCS SDK MOSI MISO words and had a look at the long it generated and it was different from what was supplied. So the definition has been corrected.
Before it was: $19171816 SDPINS
but after entering:
#25 SDCS
#23 SCK
#24 MOSI
#22 MISO
ok
I read the result as
sdpins @ .LONG 17181619 ok

So the correct long is: $17181619 SDPINS

[D.P]

NOPE! It won't work on any of my uSD cards. I also checked Mike Green's PropBOE Basic source code for pin numbers as well as loaded the code and verified the card worked.

Okay, thanks for the effort. I'll just be patient and wait until the SD tool kit is further along in Tachyon.

[Brian Riley]

Brian do you have SDCard.fth running with the PBOE? If so please share if possible.

EDIT: Now that I found version : SDCARD.fth ." SD CARD Toolkit - 120908.0400 is does have the PBOE word and I got the bitmask correct but I still get a "SD Card Error" when attempting to use the SD word?

NOPE! It won't work on any of my uSD cards. I also checked Mike Green's PropBOE Basic source code for pin numbers as well as loaded the code and verified the card worked.

[D.P]

JonnyMac has contributed an enormous amount of code to the Parallax community. One of my favorites is "jm_servo8-ez.spin" ... it is what its name implies ... simple and easy background servo pulse driver all in spin. The counters/timers of the prop are hidden behind the WAITCNT commands. Its a quick, easy and CLEAN way to get servos up and running on a prop.

I started my usual way by transcribing from spin to TF ... I got a clean load in two tries under kernal rev120905.0000.. I sat back and looked at what I had and GAWD! ... it sure was ugly and I couldn't get the background task to kickoff. After some patient help from Peter I have it going and documented and available for public consumption.

I compiled the code under kernel 120905.0000 with and EXTEND.fth newer than 120904. I ran it on a PropBOE with a couple of GWS servos I had hanging around. Any problems let me know.

Thanks, Jon!

Attachment 95383

Brian do you have SDCard.fth running with the PBOE? If so please share if possible.

EDIT: Now that I found version : SDCARD.fth ." SD CARD Toolkit - 120908.0400 is does have the PBOE word and I got the bitmask correct but I still get a "SD Card Error" when attempting to use the SD word?

[JonnyMac]

Thanks, Jon!

My pleasure -- and thanks for the kind words. I am still in the struggling stages with Forth, and as this is the Halloween season and I'm very busy writing code for my customers, not sure how I'll fair. The key for me -- as I often tell my customers -- is to create a real project. It's neat to see a translation of the code, though I dare say I don't know how you got from point a to point b....

[Brian Riley]

JonnyMac has contributed an enormous amount of code to the Parallax community. One of my favorites is "jm_servo8-ez.spin" ... it is what its name implies ... simple and easy background servo pulse driver all in spin. The counters/timers of the prop are hidden behind the WAITCNT commands. Its a quick, easy and CLEAN way to get servos up and running on a prop.

I started my usual way by transcribing from spin to TF ... I got a clean load in two tries under kernal rev120905.0000.. I sat back and looked at what I had and GAWD! ... it sure was ugly and I couldn't get the background task to kickoff. After some patient help from Peter I have it going and documented and available for public consumption.

I compiled the code under kernel 120905.0000 with and EXTEND.fth newer than 120904. I ran it on a PropBOE with a couple of GWS servos I had hanging around. Any problems let me know.

Thanks, Jon!

Attachment 95383

[D.P]

Trying to get version 1.1 working with the SD card on the Prop BOE I have added this to SDCard.fth:

: PBOE '' Prop BOE
$19171816 SDPINS
{
#25 SDCS '' SD Card chip select
#23 SCK '' SD Card clock
#24 MOSI '' SD data in from Prop
#22 MISO '' SD data out to Prop
)

Based on this from the Prop BOE docs

P22 MicroSD card DO (data out)
P23 MicroSD card CLK (clock)
P24 MicroSD card DI (data in)
P25 MicroSD card /CS (active-low chip select)

Just not sure if this is correct.

[Peter Jakacki]

Peter,

What's the story on "=IF" and/or "EQIF" ... it looks like its there but it isn't. The other day you mentioned LOOKUP and LOOKDOWN as CASE substitutes . Do they exist?

I would like to take a whack at V2. Please send the link to my regular email address ... TNX

Since we have to work with the Spin tool we also need to avoid reserved names such as LOOKUP so internally it's known as VECTORS. However I don't have a LOOKDOWN yet although it's probably no problem and still checking out a few different scenarios to see how I can make a really useful (and efficient) CASE structure. Will send you the link shortly. The EQIF was removed as there are only so many bits in a long and so many longs in a cog and we are always a "bit" short.

[Brian Riley]

Peter,

What's the story on "=IF" and/or "EQIF" ... it looks like its there but it isn't. The other day you mentioned LOOKUP and LOOKDOWN as CASE substitutes . Do they exist?

I would like to take a whack at V2. Please send the link to my regular email address ... TNX

[Peter Jakacki]

I've made a decision to hold Tachyon V2 until I have done a bit more testing and tweaking so as to avoid all the "this doesn't work" when I am still testing and deciding what to do. The kernel is running very well and I made some decisions in optimizing it. For starters besides the new stacked looping used in DO...LOOP +LOOP FOR..NEXT I have also implemented stacked conditional looping with <BEGIN...AGAIN> or UNTIL> and added a POPMARK word so that a forced exit can adjust the MARKER (branch marker) stack. The reason I did not replace the conventional conditional looping was that it does have uses and there may be some user code that may not take into account the MARKER stack and break it.

So I've had to squeeze a bit more into the cog kernel where there was absolutely no room before so now the bits are more compressed :o I managed to find some operations or parts thereof that could be moved to the hub kernel (bytecode) and removed some redundant registers etc. The 16-bit calls (vs 8-bit indexed) have not been used yet as everything so far including my applications have not exhausted the call vector table but I will be pushing it so that these limits are tested. This also means the expansion of the dictionary and word help functions into EEPROM or other non-volatile storage such as SPI FLASH or SD.

I'm also thinking of implementing a fast serial download feature a bit like PropForth in that a Tachyon cog just processes the input stream and strips out all the redundant spaces and comments etc (about 50%) and buffers this in available RAM which the main Tachyon cog can then process at it's speed which most of the time is fast. This would remove any need for line delays as there is no handshaking although I wish that all terminal emulators supported XON/XOFF properly. So the TACHYON word that I use at the start of a source code file will trigger the fast load automatically. BTW, the TACHYON word is just there to make sure that you don't try to load it on another Forth system and also to reset error counters etc.

There's also context switching support for changing the REG base for any Tachyon cog so that it can have it's own local variables etc. If anyone wants a copy to play with V2 in the meantime and perhaps report bugs (without expecting anything) then please PM me for a link.

[Peter Jakacki]

Well I have been playing with Tachyon V2 and looping is like it's slid on rails, I'm getting figures of 400ns loop overhead compared to 800ns (average due to hub access jitter) in V1. As a side bonus I no longer need special words to compile loops, you know DO compiles a (DO) bytecode normally and leaves stuff on the stack for LOOP to work with and compile a (LOOP),<branch>. Yep, no longer need those special word and the loop code is more compact, cleaner, and twice as fast. The same will go for BEGIN..WHILE..REPEAT structures etc.

@Jan: Wait your turn! I'm busy with V2!
I will try to get around to it soon.

[Powersoft]

I will try to fit it in today in my schedule of forum browsing, posting, and scratching myself (but mostly real work)
Do you need this multichannel as it would make sense and what frequency?

Two channels will be fine, because the most motor controller shields for the arduino (I use the ASC board) can handle 2 motors.

I think a frequency of about 500 HZ will be fine (adjustable?), and the range of manupulation the pwm may be 0..255


Cheers,

Jan Kromhout
Hellevoetsluis-NL

[Peter Jakacki]

Maybe add a third stack and explore all that matrix and stack frames stuff they talked about?

http://www.ece.cmu.edu/~koopman/forth/rochester_90b.pdf

Actually that would make it a fourth Forth stack I already have the DATA, RETURN, and LOOP stacks. Already I'm looking at putting the loop branch address onto a BRANCH stack so that then would make it five stacks! Well, whatever works as long as it doesn't make it complicated from the coding perspective, just simpler. I've started coding a new version of Tachyon that has almost zero overhead when looping in DO..LOOPs etc. I also want to extend that to repeat branches as well but I will test out the looping shortly.

BTW, Tachyon also uses 4 or 5 cog registers (COGREG) for parameters in certain functions such as SPI, SD etc where there is a lot of repetition and this helps keep the data stack small and tidy.

Tachyon V2 stacks:
DATA for pertinent data parameters (not using it for junk)
RETURN only for return addresses (and the occasional fudge)
LOOP where index and limits for looping are placed
+
BRANCH for branch addresses for looping and repeat structures
LOCAL for local variables

EDIT: I think Tachyon is now 2 months old a couple of days ago, time for it to evolve!

[prof_braino]

Maybe add a third stack and explore all that matrix and stack frames stuff they talked about?

http://www.ece.cmu.edu/~koopman/forth/rochester_90b.pdf

[Peter Jakacki]

For many people familiar with Forth they know that things are done a certain way and Tachyon doesn't always do it the same. Even in little things such as DO.. LOOP it's conventional wisdom to push loop parameters onto the return stack (I cringe) and remove those after the loop exits. Also LOOP has a branch address compiled after it so that it can branch back to the start of the loop. The other problem is that the stack index is not easily accessible outside of the loop but has to be passed explicitly which is more junk on the data stack.

IDEA:
So in Tachyon we have a separate loop stack used for DO..LOOP and FOR..NEXT parameters which do not mess with the return stack and allow easy direct access to parameters. But there is still the branch address used by LOOP and NEXT which seems both inefficient and can slow down a fast loop. So I got to thinking what if we include the branch address as part of the loop parameters that get pushed onto the loop stack when we first enter the loop with DO, ADO, or FOR so that there are 3 not 2 parameters (as in DO)? This way when a branch has to be taken it can read it directly from the loop stack in cog RAM and snap back to the start of the loop in an instant without the slow hub access required to read the branch normally. The same would go for repeating structures such as BEGIN UNTIL as well.

Just thought I'd share this one with you as I'm always looking at ways of making Tachyon and Forth better, both from a programming perspective and from a run-time efficiency perspective.

[Peter Jakacki]

Peterbdo you have a pwm example in tachyon?

I will try to fit it in today in my schedule of forum browsing, posting, and scratching myself (but mostly real work)
Do you need this multichannel as it would make sense and what frequency?

[Peter Jakacki]

Thanks. The version I was using had the phrase ' #31 I - " missing in two critical places.

NickL

You know, it's quite possible that you had a snapshot of a page that I was editing because that only existed for the brief moment it took to check and fix. I try to avoid that however for this very reason and I either make small changes in a text editor before pasting or encapsulate my test code in curlys in the online document to avoid transients. So it you do get an error during loading then go back and just refresh your webpage copy.

[Peter Jakacki]

Wow, I go on vacation for a week and 4 new pages of Tachyon "news" are posted. You are right Peter Tachyons never stop moving. Look forward to catching up with everything.

I do have some I2C RTC code as well with standardized interface so you can read and write stamps or strings without regard to the chip but I want to connect to a Spinneret I've got here and interface to that chip too. There's a 1-wire page and some other ones that are alluded to in the Intro page that will go up as soon as I finish scratching myself.

[D.P]

Wow, I go on vacation for a week and 4 new pages of Tachyon "news" are posted. You are right Peter Tachyons never stop moving. Look forward to catching up with everything.

[nglordi]

Thanks. The version I was using had the phrase ' #31 I - " missing in two critical places.

NickL

[Powersoft]

when i understand you right is 8 bit enough. It wil used for a motor controller

Peterbdo you have a pwm example in tachyon?

[User Name]

I've just tweaked the I2C routines to run at 400kHz with a cycle time of 36us for reading and writing. <snip> What I'm wondering is does anyone have a need to run faster than this? Is anyone using 1MHz I2C?

400 kHz is a pretty decent speed even for a PASM implementation. For Forth, it's very impressive. Personally, if I needed anything faster, I'd use SPI. It seems a lot more robust for high speed use.

[Peter Jakacki]

Peter:

There appears to be a bug in PINS? (current version of EXTEND) which is not present in earlier versions.
Results for pins 16-31 mirror those for pins 0-15.

NickL

Not sure what is happening there as I just did a quick check and got:

PINS? 
i----------u----------i
P00 <-- 1     1 --> P31
P01 <-- 1     1 <-- P30
P02 <-- 1     1 --> P29
P03 <-- 1     0 <-- P28
P04 <-- 1     1 --> P27
P05 <-- 1     0 --> P26
P06 <-- 1     1 --> P25
P07 <-- 1     1 --> P24
P08 <-- 1     0 --> P23
P09 <-- 1     0 --> P22
P10 <-- 1     0 --> P21
P11 <-- 1     0 --> P20
P12 <-- 0     0 --> P19
P13 <-- 0     0 --> P18
P14 <-- 0     0 --> P17
P15 <-- 1     0 --> P16
i---------------------i ok

So that doesn't look mirrored at all. If you downloaded from the webpage version just make sure that you refresh it beforehand as you may have a stale copy. Just in case...

'' List out each of the Prop's I/O pins & their direction)
pub PINS?
    CR ." i----------u----------i"
    P@ DIRA COG@    ( port dir )
    #16 0 
      DO
      CR ." P" I $20A .NUM DUP I MASK AND 
        IF ."  -->" ELSE ."  <--" THEN 
      SPACE OVER I MASK AND 0<> 1 AND .
      5 SPACES OVER #31 I - MASK AND 0<> 1 AND . 
      DUP #31 I - MASK AND
        IF ."  <-- P" ELSE ."  --> P" THEN
    #31 I - $20A .NUM
      LOOP
    CR ." i---------------------i"
    2DROP
    ;

[nglordi]

Peter:

There appears to be a bug in PINS? (current version of EXTEND) which is not present in earlier versions.
Results for pins 16-31 mirror those for pins 0-15.

NickL

[Peter Jakacki]

I've just tweaked the I2C routines to run at 400kHz with a cycle time of 36us for reading and writing. I know that there are PASM routines that run in their own cog or Spin routines that run very slow but this is just bytecode running from the main Tachyon cog.

Here's a shot of the timing when performing a write and a read ($55 I2C! I2C@):


What I'm wondering is does anyone have a need to run faster than this? Is anyone using 1MHz I2C?

[Peter Jakacki]

try to download the saa1064 source, get some problems with the words byte and long.
They are not seen by the compiler.
I load the latest version of the bin and extension file.

A tachyon is never still, you haven't been keeping up with the thread! I mentioned way back...... a day ago.... that I wanted to allow variables to be entered the same way we do in Spin using comma separated lists. So you will have to compile the new kernel as there are other changes too.

EDIT: I should mention too that you can just declare these in the normal way using VARIABLE & CVARIABLE but without a comma separated list

[Powersoft]

there's been a few extra project pages added to the intro links section.
new - project page links

• ps/2 keyboard interfacing - (wip) testing the ps/2 keyboard and what you can do too.
• characer lcd interfacing a full featured lcd driver - software contrast and brightness, big digits etc
• graphic lcds both the 128x64 and come other types
• serial devices interfaces to common serial lcds and devices
• vga expanding a bit more on the driver - a how-to
• sound fun both with bit-bashing, the counters, and then some wav stuff
• mma7660fc accelerometer i2c this demonstrates have we can easily interface to a common i2c accelerometer
• sd card interfacing get right down to the metal with this. See what's "inside" a card etc
• l6470 microstepper full code for this 3a rms/winding 128-step chip (it's tiny)
• h-bridge motor control
• mc3208 8-channel 12-bit adc
• silabs c2 programming in-circuit programming of silabs c8051f microcontrollers from the prop
• saa1064 4-digit led display this chip interfaces via i2c so you can have up to 4 chips without extra i/o

try to download the saa1064 source, get some problems with the words byte and long.
They are not seen by the compiler.
I load the latest version of the bin and extension file.

[Peter Jakacki]

If you are stuck with a pullup on the CS line then just modify CARD? by specifying the input for the #CD. Here is the before and after:

'' Detect SD card presence - the CS line must not have a pullup on it (redundant and undesirable).
pub CARD?        ( -- flg ; Is SD card present? )
        ON SDCS                        '' Force CS line low
        .SDCS INPUTS                '' Float CS
        .SDCS IN                        '' Is it still low or has it been pulled up (by the card's pullup)
        OFF SDCS
       ;

'' Secondary brute force method 

'' Detect SD card presence - use card detect switch and dedicated I/O
pub CARD?        ( -- flg ; Is SD card present? )
        #CD IN 0=
        ;

BTW, that SDCARD code is the "old stuff" before I added the redirection ability.

[Brian Riley]

With regard to the issue of a pull-up on the Chip Select for the SD card. For the SDPOLL word to work autonomously there must not be a pull-up.

"A Tale of Two Platform Modules"

The first, a Prop Platform USB board, pins 0 to 3 used, an SM 4 position 10K resistor pack pulling up all 4 lines, and worst of all the pull-up traces are mostly hidden by the socket! Maybe one of you guys with really young eyes and stead y hands could do it but the quarter inch of exposed traces (did I mention 'tiny') is nothing I want to tackle.

So, I left CS pulled up. the "SD" command showed me my card data, but when I pulled it out, nothing happened. I typed "SD" and, correctly, I got "Card Error." I put the card back in, again, nothing ... again, typed "SD"and it displayed my card info.

The second, Prop Plat Through Hole with a 'hacked'' microSD Platform Module (essentially cut the microSD out of a PP-USB), PP-TH has exact same Tachyon kernal and EXTEND and SDCARD. The board booted u p, typed SD and got card info. I then pulled the micro SD card got "Card Error", then re-inserted card and got card info.



The hack suffered from the same placement and tiny traces as the PP-USB, soooooo ... got out my hot air rework station and removed the SM resistor pack and then using 3 10K 1/8th watt resistors used a spare set of holes to put pull-ups back onto CLK, DO, and DI.

In the end with or without the pull-up on CS the Tachyon SD code works fine at its main job ... however, if you can have the CS pull-up removed you get some convenient benefits.

[Peter Jakacki]

There's been a few extra project pages added to the Intro links section.
NEW - Project page links

• PS/2 Keyboard interfacing - (WIP) Testing the PS/2 keyboard and what you can do too.
• Characer LCD interfacing A full featured LCD driver - software contrast and brightness, big digits etc
• Graphic LCDs Both the 128x64 and come other types
• Serial devices Interfaces to common serial LCDs and devices
• VGA Expanding a bit more on the driver - a how-to
• Sound Fun both with bit-bashing, the counters, and then some WAV stuff
• MMA7660FC ACCELEROMETER I2C This demonstrates have we can easily interface to a common I2C accelerometer
• SD card interfacing Get right down to the metal with this. See what's "inside" a card etc
• L6470 Microstepper Full code for this 3A RMS/winding 128-step chip (it's tiny)
• H-bridge motor control
• MC3208 8-channel 12-bit ADC
• SILABS C2 Programming In-circuit programming of Silabs C8051F microcontrollers from the Prop
• SAA1064 4-digit LED display This chip interfaces via I2C so you can have up to 4 chips without extra I/O

[Peter Jakacki]

Here's a quick little update that I may expand upon as I was converting some Spin code and thought, hey wait, I can leave this part as it is, I'll just tweak the compiler to process it. When you enter variables in spin you can have them separated by commas so that's what I did also. The only other change was using LONG,WORD,BYTE always in uppercase as I like to leave lowercase to denote variables and constants etc rather than code which in in uppercase or CamelCase at least.
In Spin or Tachyon variables are entered like this:
LONG faddr,flen,flen2,cold
WORD c2cmd,c2dat
BYTE chip,c2code

The reason I changed it was because.....
Before I get going on the full SD software I've been sidetracked by some software I wrote a couple of years ago to program a SILABS C8051F in-circuit using just the SDA line plus a dedicated C2CK/RST line. As some of you may know I use support micros in many of my designs rather than a dumb and more expensive chip. So rather than an MCP3208 for 12-bit ADC I use a SILABS micro that has everything including a faster ADC, voltage reference, temp sensor, a 25MIPS core, 0.5% internal oscillator and various bus interfaces including I2C. They cost a little bit more than many other "8-bit" micros but they are worth it and better and cheaper than a dumb chip. If you are interested I will be starting a project page for this family as well which will be linked at the bottom of the Intro page as usual. Writing code for the 8051 is trivial and plenty of tools are available although I will have precompiled modules available as well so it's easy peasy (super simple).

[Peter Jakacki]

Hi Brian,
The P11xx numbers are actual PCB model numbers so that I could just enter the appropriate name You can remove these from your copy of the source code but they are useful to me. So you would just name yours as PLATFORM or something unique enough to identify it with the board and pinout. The curly comments are just the alternative way of defining the pins as you have guessed whereas the SDPINS version is more efficient.

Even though I could probably do some more work on testing other cards I can do that later on and as for now it would be good to introduce the other layers, first virtual memory, then FAT16 (yuck), then FAT32 (yuck). However it's really good to work with files as virtual memory as you can directly access any part of the file that you want so I will probably demonstrate some applications using this as well. Certainly a text editor and at least a character based text display would be a good app to demonstrate this plus it is a big step towards being totally self-hosted.

NOTE: This thread has now passed the 10,000 views mark a couple of hours ago!

[Brian Riley]

PETER HERE'S THE SD SETUP FOR PROPELLER PLATFORM USB AND ANY OTHER PROP PLAT USING THE "MICRO SD PLATFORM MODULE"

: P1146		'' PP-USB/uSD-PM
	#26 MASK OUTCLR	'' P1146 PPC reset 
	$01020003 SDPINS
{	
	#03 SDCS	'' SD CS - Card chip select
	#01 SCK		'' SD CLK - Card clock
	#02 MOSI	'' SD DI - data in from Prop
	#00 MISO	'' SD DO - data out to Prop
}
	;

I couldn't, for the life of me, figure the scheme for naming the "P11xx" so I picked next in sequence.

[Peter Jakacki]

SDCARD.fth has just been upgraded to allow SD pins to be defined or changed on the fly. You can specify an individual pin change only or even all 4 pins as a long. I've got boards with 2 or more SD card slots so this is convenient for me. Here's the output from my test board with a 4GB microSD and an 8GB SD:

PINS? 
i----------u----------i
P00 <-- 0     1 --> P31
P01 <-- 0     1 <-- P30
P02 <-- 0     1 <-- P29
P03 <-- 0     0 <-- P28
P04 <-- 0     1 --> P27
P05 <-- 0     0 <-- P26
P06 <-- 0     1 <-- P25
P07 <-- 0     1 <-- P24
P08 <-- 0     1 --> P23
P09 <-- 0     1 --> P22
P10 <-- 0     1 --> P21
P11 <-- 0     1 --> P20
P12 <-- 0     1 <-- P19
P13 <-- 0     1 --> P18
P14 <-- 0     1 --> P17
P15 <-- 0     1 --> P16
i---------------------i ok
P1145 SD 
Card inserted 
MFG:    89
OEM:    
PROD:   NCard
REV:    10
S/N:    B3710000
DATE:   2010/11
CRC:    24

TACC    100ns
NSAC    0
 ok
P1107 SD 
Card inserted 
MFG:    03
OEM:    SD
PROD:   SU04G
REV:    80
S/N:    F0E5620A
DATE:   2010/10
CRC:    3C

[Brian Riley]

OK!!! SANDISK uSD works

KEYPOLL SDPOLL  ok
  ok

Card inserted
MFG:    03
OEM:    SD
PROD:   SU02G
REV:    80
S/N:    B55F1C21
DATE:   2012/5
CRC:    27

TACC    150ns
NSAC    0
Card Error
Card inserted
MFG:    03
OEM:    SD
PROD:   SU02G
REV:    80
S/N:    B55F1C21
DATE:   2012/5
CRC:    27

TACC    150ns
NSAC    0

[Peter Jakacki]

More on SanDisk 2 GB microSD .. I got out one of my PropBOE boards loaded with Mike Green's PropBOEBasic and the SanDisk was read and written to by Mike's routines.

I've updated the Google and Dropbox files so have a look at it now. I've tested this out on at least 1/2 dozen different cards or more from 1GB to 8GB in various brands etc. It's also setup to do the automatic polling so it will report the card's stats as soon as you insert it. That's probably all I will do for tonight (here) but I know I have more testing to do as I have some Eye-Fi cards here that didn't respond although I haven't really looked into it yet. The initialization is fairly basic and I will do some more checks

[Peter Jakacki]

I'm just playing with this right at the moment and I have isolated the "bad" cards and I am now getting them to read. Looks like it's an initialization thing so I will continue to check them out and post an update soon.

[Brian Riley]

More on SanDisk 2 GB microSD .. I got out one of my PropBOE boards loaded with Mike Green's PropBOEBasic and the SanDisk was read and written to by Mike's routines.

[prof_braino]

Is it possible to implement the case structure in TACHYON?

Sorry to butt in to a question addressed to Peter-

CASE is always possible, but tends to be very cumbersome and expensive from a forth dictionary perspective. Usually it is implemented on PC environments where there is tons of memory that needs to be wasted.

Tachyon is very fast and small. CASE doesn't feel like Tachyon.

Could you describe what you want to do? Usually there is a nice way to accomplish what case does, but faster using less memory, etc.

[Peter Jakacki]

Peter,

I have tried Kingston 2 GB micro SD cards and they work fine. I bought 10 SanDisk 2 GB micro SD cards and the first two I have tried generate "Card error" .... suggestions for further investigation ???

Definitely, but I'm still scratching myself

[Peter Jakacki]

Peter,

I was playing with the ANSI VT100 words.
There is some strange thing in the source.
The definition of pri CUR is not finished.
I marked with an arrow
Please can you take a look?
<snip>
pri CUR ( cmd n -- ) "[" ESC SWAP <=
pri .PAR SWAP #10 .NUM EMIT ;
pub XY ( x y -- ) ";" SWAP CUR "H" .PAR ;
<snip>

This is deliberate as CUR's final act is to call .PAR but that's silly to call it when you can "fall-through" into it which is possible in Tachyon Forth. Normally this is not possible in any Forth that I know of as each word normally has a header and even if it didn't it would still have a CFA. TF keeps the headers completely separate and there is no real CFA as such, as it's all interpreted as Tachyon bytecode instructions which are executed by the Tachyon VM cog. The header does not even point to the code but it does have the one or two bytecodes necessary that represent the call or the instructions for the word. The address is actually in the XCALL vector table which is indexed with a single byte. In this case the header for CUR looks like this:

CUR HEADER:
1FB3: 43 55 52 82 BD 24
CUR CODE:  
 ' CUR >PFA 10 DUMP 
37A0: 73 5B BD 1A 15 15 73 0A C0 DA C0 41 06 73 3B 15    s[....s....A.s;.
       "["   ESC   SWAP
 ok
' .PAR >PFA 10 DUMP 
37A5: 15 73 0A C0 DA C0 41 06 73 3B 15 BD 24 73 48 BD    .s....A.s;..$sH.
     SWAP #10   .NUM   EMIT  EXIT

[Brian Riley]

Peter,

I have tried Kingston 2 GB micro SD cards and they work fine. I bought 10 SanDisk 2 GB micro SD cards and the first two I have tried generate "Card error" .... suggestions for further investigation ???

[Brian Riley]

Peter,

I was playing with the ANSI VT100 words.
There is some strange thing in the source.
The definition of pri CUR is not finished.
I marked with an arrow

TACHYON FORTH permits you to leave out the ";" and 'run on' into the next definition. IN this case the word definition CUR is finished by .PAR

[Powersoft]

Peter,

I was playing with the ANSI VT100 words.
There is some strange thing in the source.
The definition of pri CUR is not finished.
I marked with an arrow
Please can you take a look?

TACHYON

\ **** ANSI VT100 terminal support

pri ESC ( ch -- ) $1B EMIT EMIT ;
pri ESCB ( ch -- ) "[" ESC EMIT ;
pri ESCH ( ch -- ) "#" ESC EMIT ;
pri CUR ( cmd n -- ) "[" ESC SWAP <=
pri .PAR SWAP #10 .NUM EMIT ;
pub XY ( x y -- ) ";" SWAP CUR "H" .PAR ;
pub HOME "H" ESCB ;
pub ERSCN "2" ESCB "J" EMIT ;
pub ERLINE "2" ESCB "K" EMIT ;
pub CLS HOME ERSCN ;
pub CURSOR ( on/off -- ) "?" ESCB ." 25" IF "h" ELSE "l" THEN EMIT ;

[Peter Jakacki]

I discovered my error with the cut/paste procedure. In Tera Term, Serial port setup, it has a Transmit delay section, I put the 60ms in msec/char, where it should of been 60ms in msec/line. Now that I got that corrected, the cut/paste session goes a lot quicker.

Since I am using the QuickStart board, I was playing around with the code below. After you get the code running, the LED is flashing, I type in STOPCOG4, which stops the LED. Then I STARTBLINK4, and the LED starts up again, the problem is, when I STOPCOG4, and then STARTBLINK4, again, nothing happens. It is if STARTBLINK4 is no longer functioning, so I have to do a ' BLINKY >PFA 4 RUN to get it going again. I thought that once you created a new WORD, it is valid until you reboot or do a COLD? Is there something that I missed?

Ray

#16 MASK    CONSTANT .RDY
: BLINKY    50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY >PFA  4 RUN
: STOPCOG4 1 4 RUN ;
: STARTBLINK4 ' BLINKY >PFA 4 RUN ;

Because Tachyon compiles word by word it isn't possible (at present anyway) to do certain things the way that they are normally done in conventional Forth which has it's own limitations. The tick word is immediate and as of yet I have not put in any compensations so that if you try to put it in a definition it will of course execute immediately as you would expect it to but the address is on the stack but not compiled as it needs to be. That's why in my examples I create a constant first and then use it like this from your example:

' BLINKY >PFA CONSTANT UBLINK
: START  UBLINK 4 RUN ;

[Rsadeika]

I discovered my error with the cut/paste procedure. In Tera Term, Serial port setup, it has a Transmit delay section, I put the 60ms in msec/char, where it should of been 60ms in msec/line. Now that I got that corrected, the cut/paste session goes a lot quicker.

Since I am using the QuickStart board, I was playing around with the code below. After you get the code running, the LED is flashing, I type in STOPCOG4, which stops the LED. Then I STARTBLINK4, and the LED starts up again, the problem is, when I STOPCOG4, and then STARTBLINK4, again, nothing happens. It is if STARTBLINK4 is no longer functioning, so I have to do a ' BLINKY >PFA 4 RUN to get it going again. I thought that once you created a new WORD, it is valid until you reboot or do a COLD? Is there something that I missed?

Ray

#16 MASK    CONSTANT .RDY
: BLINKY    50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY >PFA  4 RUN
: STOPCOG4 1 4 RUN ;
: STARTBLINK4 ' BLINKY >PFA 4 RUN ;

[Peter Jakacki]

Yes, I started having a look at it and just seeing if I could convince the counters to work together without dedicating a cog for this. Well you can and Tracy Allen did some work on using 2 counters with an external XOR gate or 3 counters otherwise you need to dedicate a cog to it so that's what I will do. So as soon as I get a few minutes when I'm not on the forum or documenting what I've done, reviewing and testing changes and requests, scratching myself etc I will check it out and try it on some of my 8A H-bridge modules just to make sure

Ditto with the CASE structure although I have my own ideas on that. Did you check out the simpler indexed LOOKUP structure?

[Powersoft]

Peter,

Is it possible to implement the case structure in TACHYON?

[Powersoft]

when i understand you right is 8 bit enough. It wil used for a motor controller

Peter,

Plese can you take a look at my question about PWM with TACHYON

Thanks

[Peter Jakacki]

The Dropbox files are not the bleeding edge files as you need to look at the Google docs versions for that. But when I'm happy with a version I then update it. In this case I think it just didn't get updated perhaps but I've done that now.

[Peter Jakacki]

Brian:

.Thanks. The EECOPY word, as you suggested, will prove very useful in working with Tachyon.

I have been trying out the sdcard word set. Executing SD with all my cards only results in a card error message, apparently due
to a timeout error. Have you eXperienced any problems with this word set?

NickL.

Hi Nick, there are some cards that aren't working but I've been stretched here and there but I fully intend to sort out what's going on. Having all the primitives required at your fingertips make it very easy to test as you can just issue CMDs and ACMDs etc on the fly and look at the results. Once I do that then I will introduce the virtual memory and file system layers on top of that.

[nglordi]

Brian:

.Thanks. The EECOPY word, as you suggested, will prove very useful in working with Tachyon.

I have been trying out the sdcard word set. Executing SD with all my cards only results in a card error message, apparently due
to a timeout error. Have you eXperienced any problems with this word set?

NickL.

[Brian Riley]

Brian:

Where is EECOPY located? It doesn't appear in the QWORD list.

NickL

Its in recent (last three days) copied of EXTEND.fth

[nglordi]

Brian:

Where is EECOPY located? It doesn't appear in the QWORD list.

NickL

[Brian Riley]

FWIW - here's my numbers for essentially the same file - 37+ SECONDS - it may even have been faster than Peter ... but i had set it to 133ms and had not put it back to 65 ms.

END
End of source code, there were 0 errors found
CODE   @$3D4F  - bytes used in this load = 1512
NAMES  @$1D3A  - bytes used in this load = 751
YCALLS @ 140 entries free
 ok
''
A ... EEPROM ... 19200d BAUD  ok
  ok
CR .LAP CR
37,610,922us
 ok
?BACKUP  ok

[Peter Jakacki]

I just did a test run of loading in EXTEND.fth, I have a fairly fast PC, and I was very surprised that it took some fifteen minutes (approx) to cut and paste it into Tera Term, sure glad he has BACKUP. At the end of the cut and paste, it showed that there was one error ( I had a 60ms delay), I failed to write the error down, so now I am not sure at what point that will show up. There must be a better way, or at least a faster way.

I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?

Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?

Ray

There is a faster way! That was supposed to be a 60ms line delay, that is it only waits after each end of line. I timed the load and it took 36 seconds and this is the output:

End of source code, there were 0 errors found 
CODE   @$3627  - bytes used in this load = 1511
NAMES  @$2021  - bytes used in this load = 751
YCALLS @ 243 entries free 
 ok
'' 
A ... EEPROM ... 9600d BAUD  ok
.LAP 36,113,223us ok
?BACKUP  ok

It might be a good idea for me to include the time to load in the STATS report as I did manually in this example.

If you have a look back at some of the other posts you will see your questions answered. Essentially we don't have any direct control over a cog in any language, we can stop it or we can reload it, that's all. Also the only reason we normally would want to stop the cog itself it is because we are testing so it is just as easy to reboot (<ctrl> C or break etc). The other way is to place something in your software that can look at a hub command and decide what to do. Have a look at post #241.

EDIT: Looks like Brian answered this a bit already

[prof_braino]

Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?

Here is caskaz's quickstart demo in propforth, this should be similar

http://propforth.googlecode.com/file...20611-1540.txt

I thought somebody already ported this, but I can't find the link right now

[Brian Riley]

I just did a test run of loading in EXTEND.fth, I have a fairly fast PC, and I was very surprised that it took some fifteen minutes (approx) to cut and paste it into Tera Term, sure glad he has BACKUP. At the end of the cut and paste, it showed that there was one error ( I had a 60ms delay), I failed to write the error down, so now I am not sure at what point that will show up. There must be a better way, or at least a faster way.

I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?

Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?

Ray

Likely you didn't have an actually error during the copy/paste. I am running a 2.5 GHz quad core I5 iMac with ZTerm and 80 Msec line wait and about one in 10 copy/paste actions hiccup.15 minutes is all wrong. Are you sure you didn't set a character wait too?

The answers to your multi-Task questions are in Message #241 of this thread.

[Rsadeika]

I just did a test run of loading in EXTEND.fth, I have a fairly fast PC, and I was very surprised that it took some fifteen minutes (approx) to cut and paste it into Tera Term, sure glad he has BACKUP. At the end of the cut and paste, it showed that there was one error ( I had a 60ms delay), I failed to write the error down, so now I am not sure at what point that will show up. There must be a better way, or at least a faster way.

I went ahead and ran the MULTITASKING example, now it ran successfully. The obvious question is, how do you stop the event(s), is this where REBOOT or COLD comes in?

Since I am using a QuickStart board for this, I wonder if the next test should be, being able to use the touch buttons to light up the LEDs, anybody have any ideas as to how that would be done?

Ray

[Brian Riley]

With the addition of the EECOPY command Tachyon has some interesting abilities to store and reload alternate configurations.

Its not a simple matter of copying the 32K of RAM to EEPROM ... Peter's masterful use/reuse of RAM means, unfortunately that key items in setup have come and gone by the time the terminal console is handed to the user!

BUT WAIT! Don't despair! Peter has another trick, BACKUP. Didn't you ever wonder why bACKUP has so much to it ... it does because it has to assemble the pieces to look like they came in s neat package from the compiler.

The following examples are based on an improved version of the Propeller Platform Through-Hole board I am working on. It has two AT24C1024B EEPROMs yielding 256 KBytes addressed $0 to $3FFFF. The first 32K, as usual belongs to the current boot image.

So load up you favorite kernal spinfile, apply your extensions and custom tools. Several lBACKUPs later you are ready to rock and roll ... BUT WAIT!!! Let's buy some insurance ... type in ...

$0 $38000 $8000 EECOPY

Copy, starting at $0 the 32K boot image and store it in the top of the EEPROM array. Now to work creating. Sooner or later you need to put it all on the line and BACKUP merging development code with new code ... test it out, does it work? YES, save it

$0 $30000 $8000 EECOPY

... or NO, it doesn't, time to start over, recover the original development configuration ...

$38000 $0 $8000  EECOPY REBOOT

It beats the heck out of multiply redoing 2-5 lengthy Copy/Pastes.

[mindrobots]

Just chasing the latest bright shiny thing......whenever PropForth 5.3 comes out, we'll flock to it.

[prof_braino]

Just so y'all know, I getting totally jealous that the Tachyon thread is only a month old and already has 269 posts.

Good work guys!

[mindrobots]

Hey Tony, ...

Not sure who Tony is, but that's ok! I'm cool with the development environment and changes. Hopefully, the core words won't change too dramatically.

Tachyon itself hosts the glossary as you could type HELP BAUDRATE for instance and it will show the word, it's stack comments and any other information that has been entered. A bit like this:
HELP BAUDRATE
2046: 8A YCALL 08 : BAUDRATE ( baud -- ) '' sets the baudrate of the console which is locked into EEPROM, requires reboot)

If you type HELP without parameters it will list every word. I may include a search parameter to help narrow down words of interest.

What happens is when the source is compiled and a new word is created it will also take the stack comments and any other comments on that line and store this in the EEPROM dictionary information area. This area may simply be the top area of a 32K EEPROM which is normally an uninitialized data are such as display buffers or else if more than 32K is available it will use the top area of that device. Precompiled words and primary extensions will be searched as they are now in RAM and user words stored in EEPROM which frees up a lot of wasted RAM otherwise. The precompiled kernel words won't have any help information when it's freshly compiled but EXTEND.fth will include the additional information for these so that they can be compiled into EEPROM.

By all means you don't need to desist from maintaining a glossary however as I might even include the descriptions in the help comments.
How does that sound?

The documenting dictionary sounds very impressive. So my choice soon will be to continue updating my spreadsheet from your source or just type in HELP <word> ?

Wow, that's going to be a tough choice!!

It's looking real good. Hopefully, I'll get a chance to play more this afternoon!

[Peter Jakacki]

If you are working with a fresh precompiled kernel that you have just F11d then you need to load in EXTEND.fth which has all the extras built on the kernel like RUN which is where the ??? came after in your attempt meaning it did not know what RUN is. You might need to set your line delay from the terminal to around 60ms or so as there is no handshaking while a large source code file is pasted in.

[Rsadeika]

In the MULTI-TASKING example, ' BLINKY >PFA 4 RUN, is the " ' " used for comment, or is it a word? When I tried to run the example as is, I get ??? on that line of code, and there is no LED that is blinking. My assumption with that example is the I could have an LED blinking while I would still be in the interactive mode.

Ray

[Rsadeika]

Yes, the new download now compiles, and it was a SETQ error.

Ray

[Powersoft]

But which lines are you using? Are you saying that you have it hooked-up already to work with the Spin code? If so then it's simply:
#27 |< CONSTANT #mcp '' Select mcp3208 chip ( This is the chip select or AdcCS )
#25 |< CONSTANT #sck '' SCK mask ( This is the clock or AdcCL )
#26 |< CONSTANT #mosi '' MOSI
#26 |< CONSTANT #miso '' MISO data

This pins work fine, thanks

[Peter Jakacki]

I just downloaded your latest Tachyon1v1-VGA.spin, tried to load it to RAM, I get "ERROR - Address is out of range". Not sure what is causing this to happen.

Ray

I've just checked the Google doc version and it's fine in both BST and Spin tool. Just in case I have updated the Dropbox version as well. There was a small typo that I picked up earlier on which may have produced this error, in fact it was an XCALL,SETQ rather than the XCALL,xSETQ that was defined in the dictionary.

[Peter Jakacki]

But which lines are you using? Are you saying that you have it hooked-up already to work with the Spin code? If so then it's simply:
#27 |< CONSTANT #mcp '' Select mcp3208 chip ( This is the chip select or AdcCS )
#25 |< CONSTANT #sck '' SCK mask ( This is the clock or AdcCL )
#26 |< CONSTANT #mosi '' MOSI
#26 |< CONSTANT #miso '' MISO data

[Rsadeika]

I just downloaded your latest Tachyon1v1-VGA.spin, tried to load it to RAM, I get "ERROR - Address is out of range". Not sure what is causing this to happen.

Ray

[Powersoft]

Either change the pins in the source code or enter these pins before loading the code.

spin |< CONSTANT #mcp '' Select mcp3208 chip
cpin |< CONSTANT #sck '' SCK mask
dpin |< CONSTANT #mosi '' MOSI
dpin |< CONSTANT #miso '' MISO data

Now that's not totally correct because you just gave me symbols and not actual pins so you do the substitution then. The code will float the MOSI pin after sending the command so you can use the same pin for data out and data in.

I see this in the Spin Source
AdcDT=26
AdcCL=25
AdcCS=27

[Powersoft]

what resolution are we talking about? I will look at a simple 8-bit example first off.

when i understand you right is 8 bit enough. It wil used for a motor controller

[Peter Jakacki]

Peter thanks for this.
But what I want is a PWM signal of about 10kHz.
Do you have an example of that?

Thanks in advance.

What resolution are we talking about? I will look at a simple 8-bit example first off.

[Peter Jakacki]

Peter in MCP3208.fth you are using 4 pins.

I have these:

'' dpin = pin connected to both DIN and DOUT on MCP3208

'' cpin = pin connected to CLK on MCP3208

'' spin = pin connected to CS on MCP3208

How can we convert these pins into your program?

Cheers.

Jan

Either change the pins in the source code or enter these pins before loading the code.

spin |< CONSTANT #mcp '' Select mcp3208 chip
cpin |< CONSTANT #sck '' SCK mask
dpin |< CONSTANT #mosi '' MOSI
dpin |< CONSTANT #miso '' MISO data

Now that's not totally correct because you just gave me symbols and not actual pins so you do the substitution then. The code will float the MOSI pin after sending the command so you can use the same pin for data out and data in.

[Powersoft]

Peter in MCP3208.fth you are using 4 pins.

I have these:

'' dpin = pin connected to both DIN and DOUT on MCP3208

'' cpin = pin connected to CLK on MCP3208

'' spin = pin connected to CS on MCP3208

How can we convert these pins into your program?

Cheers.

Jan

[Powersoft]

Peter thanks for this.
But what I want is a PWM signal of about 10kHz.
Do you have an example of that?

Thanks in advance.

[Brian Riley]

Ah, probably not, but functionality comes first and so multiply just multiplies Seriously though there are some features that I need to go back over because you may notice that you can't even enter a signed number at present, it's a fairly minor thing but it will be addressed shortly. I was more concerned with the overall functionality and usability of Tachyon which is why I have been testing it a lot in real applications which BTW none have needed signed arithmetic.

Save for entering a negative number which can be worked around it sure looks like it handles signed numbers.

0 8 .S - .S 9 * .S . CR
STACK: 00000000 00000000 00000000 00000008
STACK: 00000000 00000000 00000000 FFFFFFF8
STACK: 00000000 00000000 00000000 FFFFFFB8 -48
 ok
8  NEGATE .S
STACK: 00000000 00000000 00000000 FFFFFFF8  ok

[Christof Eb.]

Hi Peter,
it is me "rough crowd" again. I have got the impression, that the basic functions are already there now. So tachyon could be useful for some guys like me. But such very basic things like * should be stable before. This leads me to the question, whether you might want to release a kernal, that is supposed to stay?
Christof

[Peter Jakacki]

I'm slowly going through the Tachyon code to learn the words. Since I have a terrible memory and lots of debris from other languages in my head, I'm creating a Tachyon vocabulary cheat sheet out on Google Docs to help me learn the new words (and keep them straight). I'm far from done but I have enough to start sharing. Hopefully, the basic vocabulary is relatively stable at this point.

There are a bunch of very clever quick words in there when you start digging around!

If anyone wants to contribute by filling in the blanks, I'll be more than happy to grant you edit access (I can probably figure that out), just send me a PM with your Google details let me know.

Hey Tony, just be aware that this can change from day to day (sorry) but that's the nature of development. Anyway coming up fairly soon the dictionary will support EEPROM dictionaries which includes stack comments and additional information. So that means that Tachyon itself hosts the glossary as you could type HELP BAUDRATE for instance and it will show the word, it's stack comments and any other information that has been entered. A bit like this:
HELP BAUDRATE
2046: 8A YCALL 08 : BAUDRATE ( baud -- ) '' sets the baudrate of the console which is locked into EEPROM, requires reboot)

If you type HELP without parameters it will list every word. I may include a search parameter to help narrow down words of interest.

What happens is when the source is compiled and a new word is created it will also take the stack comments and any other comments on that line and store this in the EEPROM dictionary information area. This area may simply be the top area of a 32K EEPROM which is normally an uninitialized data are such as display buffers or else if more than 32K is available it will use the top area of that device. Precompiled words and primary extensions will be searched as they are now in RAM and user words stored in EEPROM which frees up a lot of wasted RAM otherwise. The precompiled kernel words won't have any help information when it's freshly compiled but EXTEND.fth will include the additional information for these so that they can be compiled into EEPROM.

By all means you don't need to desist from maintaining a glossary however as I might even include the descriptions in the help comments.
How does that sound?

[Peter Jakacki]

Another question: * is unsigned. Is this intended to remain unsigned?
Christof

Ah, probably not, but functionality comes first and so multiply just multiplies Seriously though there are some features that I need to go back over because you may notice that you can't even enter a signed number at present, it's a fairly minor thing but it will be addressed shortly. I was more concerned with the overall functionality and usability of Tachyon which is why I have been testing it a lot in real applications which BTW none have needed signed arithmetic.

[Christof Eb.]

Another question: * is unsigned. Is this intended to remain unsigned?
Christof

[Christof Eb.]

Great idea, this list of words!
As it is now possible to use multible cogs, I think it is necessary to have hub vars for communication. Is this possible?
Christof

[mindrobots]

I'm slowly going through the Tachyon code to learn the words. Since I have a terrible memory and lots of debris from other languages in my head, I'm creating a Tachyon vocabulary cheat sheet out on Google Docs to help me learn the new words (and keep them straight). I'm far from done but I have enough to start sharing. Hopefully, the basic vocabulary is relatively stable at this point.

There are a bunch of very clever quick words in there when you start digging around!

If anyone wants to contribute by filling in the blanks, I'll be more than happy to grant you edit access (I can probably figure that out), just send me a PM with your Google details let me know.

[prof_braino]

In "traditional" forth, the . is a diagnostic word that pops the top element off the stack and displays it on the output line. I think there's an ANSI description for the recommended implementation.

Another diagnostic word is .s which display the contents of the stack.

Propforth did the "traditional" . but not .s, instead opting for st? as Sal thought that did more of what he wanted. Just another design decision.

There's a lot of cases where we DON'T want the extra space after the number, but propforth decided leave that to the user.

We can implement either alternative in either flavor as an extension.

By the way, the Tachyon doc is really cool!

[mindrobots]

I like the explicit output without any extra padding. Adding the padding, CR and other formatting is easier than trying to remove it from generated output.

[Peter Jakacki]

That's really funny Jon, I never thought that by not including an automatic and not always desirable space in the number print function that it would produce puzzling results

Tachyon is Forth but I'm not trying to make it compatible to any standard although I'm not trying to make it incompatible either. It's just that I've had many times in programs where the space is fine say on the terminal screen but if I try to use it when it's redirected to an LCD for instance that I find the space messes things up. Excise the problem space I say and decide when it's needed or not.

Just be aware that there are many dialects of Forths just as there are many dialects of other languages but especially when it comes to embedded systems vs resource rich PCs. While trying to keep it compatible enough there is room for improvement or changes are necessary simply because it's a Propeller.

In the way of tutorials I'm quite happy to include specialized material in my Intro section if it's requested. I use Forth especially when I have a lot of mechatronics as I can interact with the devices and sometimes find I can do things that might not have been thought of or thought possible.

[mindrobots]

Interesting results - implementation differences.

From PropForth:

MASTERProp0 Cog6 ok
 3 2 . . cr
2 3 
MASTERProp0 Cog6 ok

From Tachyon:

   ok
3 2 . . CR 23
 ok

 ok
3 2 . SPACE . CR 2 3
 ok

Tachyon output is exactly as you specify it. PropForth output adds a CR here and a space there........

Which is more useful??? Hmmmmm.........

A Tale of Two Forths

"It was the best of times, it was the worst of times........"

[JonnyMac]

Thanks, Brian. I will scratch that web-based tutorial off my list.

[Brian Riley]

No, Jon, this is correct ... to get what you expected you would have needed to type

3 2 . SPACE . <CR>

[JonnyMac]

Peter,

I'm trying to give myself a bit of time each day to "play" with Forth, hoping at some point that I'll have that "Aha!" moment and I'll understand why those that love it so much do.

While working through a simple demo this morning I entered this:

2 3 . . <CR>

The expected output was

3 2 OK

but was actually

32 OK

Is this something that should be addressed? Sorry if this is a ridiculous request -- still WAY down the learning curve and am dependent on web-based tutorials.

[Peter Jakacki]

Okay so I have made an addition to allow other Tachyon cogs to receive a command, a bit like hitting a key. It's really very simple, we just insert ATN? which returns with a non-zero byte command which is inserted by another cog. You can interpret the command anyway you want, just like a key. The command is read from the cog's "tasks" vector which won't cause it to run wild as it will simply clear a byte command in the idle loop without trying to execute it.

Here's what my blinky looks like:

#13 MASK    CONSTANT .RDY
: BLINKY    BEGIN .RDY OUTSET 50d ms .RDY OUTCLR 50d ms ATN? UNTIL ;
' BLINKY >PFA  4 RUN

Now when I type:
1 4 RUN
where 1 is a "command" for cog 4 the loop will terminate and I can get control of it once again in the idle loop. This is also a neat way to pass commands to the cog if it is setup to process them like this:

#13 MASK    CONSTANT .RDY
: BLINKY    50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
' BLINKY >PFA  4 RUN

So blinky will start off with a fast blink, but now:
#200 4 RUN
will cause it to slow blink

[Peter Jakacki]

Whoooops, what's in a name??? Okay, I fixed the name of the files and removed 1V0 so there is no confusion. I will put that flag in shortly, maybe even use the vector location with a single-byte command rather than an address.

[Brian Riley]

OK, when you put it that way. Most tasks will come in execute and exit back and the VM Idle Loop resumes. If you have and endless loop its still good to have control, so instead of "BEGIN.. AGAIN" You code "BEGIN.. ?hubflag UNTIL"so the loop can be forced out without a system reset.

Question: you said you made a change for multi-tasking several hours ago "Tachyon1v0-VGA.spin" was altered 4 hours ago and "Tachyon1v1-VGA.spin" 20+ hours ago. Did you mean to alter v1.0 or v1.1 ????

[Peter Jakacki]

Since it's not possible to interrupt a cog then the only way to break into anything is if the user code polls for something. So I guess your code may have poll a variable then. I don't know if there's a better way. I will see if I can include something as a VM instruction that simplifies this. But remember this really only applies when you are testing out code and wish to stop it without resetting. Every other time we want to stop any kind of code we have to reset it anyway.

[Brian Riley]

However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop

Before I was running a "BEGIN..AGAIN" loop with no exit and stopping it was simple matter of "<cogid> STOP" With a foreground processes you test a "KEY?" to break a loop. Is there a way to send a cog a character? Or do we do it the old fashioned way cog abort flag in hub ram?

[Peter Jakacki]

Peter,

Do you have experiance to communicate with a mcp3004/3008 or mcp3208

Thanks in advance.

Jan

I've started up an MCP3208 code document and I will hook-up a chip later as I have used these in old projects. You are welcome to follow my progress but be quick about it as it won't take long at all. Although this is the default ADC solution for many as it's easy I don't really use these chips anymore as I use cheaper solutions based on single-chip processors with embedded ADCs and I2C etc.

EDIT: The solution should have taken 5-10 minutes once I hooked up the pcb except I forgot that this board had a deliberate and hidden short between the Din and Dout of the chip and I was wondering why I kept reading back 0's until I decided to float the MOSI from the Prop after the first 8 bits. Anyway it's working now, there's both a fast and slow method. I checked it on my old pill counter sensor pcbs which use 1" photodiodes connected to opamps and into the MCP3208. It's all working well.

[Peter Jakacki]

To answer this and your other question:
It's easy enough to use cog 0 but why bother as we already have 5 cogs running a Tachyon VM and I might want another one for an object from the OBEX (maybe). Each cog has an "run" vector but unless all cogs are runnning Tachyon (possible) they won't all be needed. At startup cogs 4 to 7 are loaded with the VM but told to execute an IDLE loop which just waits for it's run vector to come alive. Once it's off and running there is not much in the way of control that we have with these little cogs but that's the way the Prop is. You can stop them but you can't restart them unless you do another coginit which I can do but it's only necessary when you are mucking around testing and it's easier just to reset the Prop (^C or <break>).

The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?

So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?
<snip>
[/CODE]

However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop

[Peter Jakacki]

Peter,

Another thing I dont get fix is to output a PWM signal on a specific pin.
Do you have an example in TACHYON

Thanks in advance,

Jan

Do you want PWM or duty mode DAC?
If it's a duty mode DAC then that's real easy, you can even do that in interactive mode as you have direct access to the counter registers. Just type this in:
#11 APIN
DUTY

To get a square wave (50%) type:
$8000.0000 FRQ

To get 25% type:
$4000.0000 FRQ

To make that into a convenient word say as an 8-bit DAC:
pub DAC! ( level -- )
#24 SHL FRQ DUTY
;
The pin can be specified once as shown above or changed on the fly. By default the A counter is accessed but you only have to type in "B" to change it like this:
B #12 APIN
$40 DAC!
Which will set pin 12 to use counter B with a 25% duty cycle.


Now if it's PWM (fixed frequency) you need then normally we dedicate a cog to looking after that (plus other things). That's not so hard either but this duty mode is simple and normally what you would use if you had an RC network to filter it to a voltage.

[Brian Riley]

There is a problem in the multi-tasking. Once you excercise a COG, say " ' BLINKY >PFA 5 RUN " and it runs for a while, and then you decide its usefulness is over and you issue a " 5 STOP" ...

THAT"s IT for COG 5 ... you can issue this, " ' BLINKY >PFA 5 RUN " until the cows come home and it isn't going to blink, because it never gets back to that SPIN initialization in COG 0 where the Tachyon VM idle loop is called for COG 5 "cognew(@RESET, @IDLE)"

Now maybe I have made the mistake of loading my expectations on to your project, but it seems to me that being able to start a cog with a task and then stop it and run yet another task and maybe go back to the first task or on to a third or fourth one is what we've come to expect from Prop based systems.

[Brian Riley]

It's not quite two months since I started the Tachyon project and for the last couple of weeks I have been porting applications across to Tachyon and tweaking the kernel that little bit more etc. I have now released V1.1 which also introduces multi-tasking using cogs 4 to 7. There's also a KEYPOLL background function that can be used from the primary terminal task that's useful for checking for status updates such as SD card insertion/removals etc without resorting to using another cog.

The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?

So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?

... and the answer is 4..7 only, a request for 0 or 3 executes but nothing

  Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200


TACHYON

  Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200
ok
: TASK1  ( -- )
         BEGIN
                 0 MASK OUTSET
                 #500 ms
                 0 MASK OUTCLR
                 #500 ms
         AGAIN
         ;  ok
: BLINKY   200d FOR 0 MASK OUTSET 100d ms 0 MASK OUTCLR 100d ms NEXT ; ok 
END
End of source code, there were 0 errors found
CODE   @$3E9D  - bytes used in this load = 39
NAMES  @$1DCB  - bytes used in this load = 17
YCALLS @ 180 entries free
 ok
NOVGA  ok
  ok
' BLINKY >PFA 3 RUN  ok
.
' BLINKY >PFA 7 RUN  ok
7 STOP  ok
' BLINKY >PFA 0 RUN  ok

[Powersoft]

Peter,

Another thing I dont get fix is to output a PWM signal on a specific pin.
Do you have an example in TACHYON

Thanks in advance,

Jan

[Powersoft]

Peter,

Do you have experiance to communicate with a mcp3004/3008 or mcp3208

Thanks in advance.

Jan

[Peter Jakacki]

It's not quite two months since I started the Tachyon project and for the last couple of weeks I have been porting applications across to Tachyon and tweaking the kernel that little bit more etc. I have now released V1.1 which also introduces multi-tasking using cogs 4 to 7. There's also a KEYPOLL background function that can be used from the primary terminal task that's useful for checking for status updates such as SD card insertion/removals etc without resorting to using another cog.

The SD card "toolkit" has been up and running but I am still doing some more tests with various cards before I add on the full virtual memory and file system extensions. At the moment it's very useful for investigating SD cards and you can even backup the hub ram directly into the SD card as if it were just a very large SPI memory chip (and unless you want to use it in a PC, who cares). It's possible to do bitmap screen updates at around 20 fps with this method which just uses a PASM kernel routine for bit-bashing SPI. I might look at the counter approach later on once functionality is fully established (so 60fps would be possible!). BTW, I favor non-fragmentation of files as it simplfies file access and makes them far more efficient. Sometimes I even create one big non-fragmented file which may hold lots of smaller files. Certainly many of my logging files preallocate a large chunk as non-fragmented so that it becomes a simple virtual memory and avoids all those traditional and cumbersome file access methods. The virtual memory address is the handle and the virtual memory access words hide the caching and flushing etc.

Now there's also a lot of peripheral chip interfacing that I'm doing but let me know if there are any special requests as I will be testing and releasing this source daily.

[Peter Jakacki]

Seeing that a version of my L6470.fth has just been posted in the PropForth thread I thought I would post my Tachyon version of the original L6470.fth file. This is not totally optimized yet for Tachyon but the code takes 1.8K. These files are also available through the link section of the Tachyon Intro page. One of the aims with Tachyon was to avoid any cryptic PASM code when programming in Forth and so Tachyon had to be fast but it is also supported with a sensible set of instructions in it's VM.

L6470 Microstepper code for dual motors - L6470 1V1.txt

[Peter Jakacki]

Brian,

Since I don't use the card detect switch I never noticed it It just so happens that last night I came across this and renamed the card detect switch to .CD although I may improve my convention for naming pins as it can get confused with the standard Forth dot word for print.

My detect routines assume you have not used the seemingly obligatory pull-up resistor on the chip select line then you can use this routine to detect whether a card is present or not

: CD?    ( -- flg ; Is SD card present? )
    ON SDCS            '' Force CS line low
    .SDCS INPUTS        '' Float CS
    .SDCS IN        '' Is it still low or has it been pulled up (by the card's pullup)
    OFF SDCS
    ;

Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?

So as you can see the card detect switch is not being used as I rely on the documented CS pull-up that is present on SD cards internally. If you have a pull-up to the CS line on your board then disconnect it.

After power up, this line is input with 50Kohm(+/-20Kohm) pull-up (can be used for card detection or SPI mode
selection). The pull-up may be disconnected by the user, during regular data transfer, with
SET_CLR_CARD_DETECT (ACMD42) command.

Here's a schematic of the SD hookup that is used in the code (although I have many others I test as well).

[mindrobots]

Another Tachyon script ... Ping))).

I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.

Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.

One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.

Brian,

I took the liberty of porting your wonderful PING.fth for Tachyon to PropForth and posted it to the PropForth 5.0 thread here. I don't want it to feel left out since everyone is playing with the new kid. (Sibling rivalries and all that! )

I'm going to do the PIR next, when I get more play time if there are no objections.

Thanks for the words!

[Brian Riley]

Peter,

I the new code for the SD card, in the top of the file you have a iomask constant for "Card Detect" called ".CARD"

TACHYON

: SDCARD.fth	." SD CARD Access and file system layer - 120821.2100 " ;

#23 MASK	CONSTANT .CARD	'' Card detect - active low
#24 MASK	CONSTANT .SDCS	'' SD Card chip select
#25 MASK	CONSTANT .SDCK	'' SD Card clock

Then down around line 179 you have a word defined ".CARD" ... Is this a problem?

CREATE tval	
	#00 | #10 | #12 | #13 | #15 | #20 | #25 | #30 |
	#35 | #40 | #45 | #50 | #55 | #60 | #70 | #80 |

'' Card information
: .CARD
''	  CR ." BYTES:  " SDSIZE? .
	  ''    0123456789ABCDEF012345
	  CR ." MFG:    " cid C@ .BYTE
	  CR ." OEM:    " cid 1+ 2 TYPE

Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?

[Brian Riley]

Yet another Tachyon Forth script ==> Parallax PIR Sensor module

Like my script for the Ping, my PIR code is a transcription of Josh Donelson's SPIN code to Tachyon Forth.


**** The code in PIR.ZIP is good under kernel 120815.0930 ****


**** The code in PIR2.ZIP is good under kernel 120820.1445 ****


Enjoy!!

[prof_braino]

I have started playing with SimpleIDE and have also been using this for editing Forth source code files (.fth) as well. It got me thinking that it would be nice if SimpleIDE had a terminal built-in especially if it supported common ANSI controls and allowed source code to be downloaded along with XON/XOFF handshaking. So I will try to find out about this but in the meantime some of you may have noticed that various snippets of code look a little Spin-like. ....

Don't know if you're open to this, but it got me thinking....

I hear Go language compiler also compiles C code. The Go language terminal utility example Sal wrote uses the host PC's OS functions, so it gives tab completion, command history, command line editing, stuff like that for free. And it provides the channel interfaces, so the PC app can talk directly to the prop over a fast channel, if you chose to expand in this direction...

[Peter Jakacki]

I have started playing with SimpleIDE and have also been using this for editing Forth source code files (.fth) as well. It got me thinking that it would be nice if SimpleIDE had a terminal built-in especially if it supported common ANSI controls and allowed source code to be downloaded along with XON/XOFF handshaking. So I will try to find out about this but in the meantime some of you may have noticed that various snippets of code look a little Spin-like. You know, instead of the colon they start with pub or pri plus instead of a long line of code it is spread over multiple lines. Well, I'm trying to make this more readable for Spin users and it is just as readable to Forth users yet it does not compromise the simplicity of the Forth compilation process. There are probably other changes I will make as they seem practical and conducive to learning to program in Tachyon Forth (and have others understand it).

So where I can and as long as it doesn't compromise Tachyon itself I have been renaming or creating aliases of functions so that they are more familiar to Spin (and C) users but of course taking into account the RPN stack notation. Here's a snippet of LCD code that uses ++ and ~ and pub etc, even LOOKUP in a slightly different form:

pub LCDHOME
    ypos C~        '' clear y line position 
    xpos C~        '' clear x character position
    2 LCDCMD        '' Raw home command for LCD 
    1 ms        '' Just give the LCD time to execute it
    ;

pub LCDCLS        '' Clear the LCD screen
    1 LCDCMD        '' Raw LCD command to clear it's screen
    1 ms        '' The only command that you really need to wait for
    LCDHOME    
    ;
pub LCDCR        '' Carriage return
    xpos C~ XYCUR    '' Return to X position zero and update LCD's cursor
    ;
pub LCDLF        '' Line feed
    ypos C++
    ypos C@ #lines =>    '' Wrap-around to the top of the display?  
      IF ypos C~ THEN
    XYCUR        '' Update the LCD's internal cursor
    ;
pub LCDCHAR ( char -- )    '' Treat character as data
    LCDDAT
    xpos C++        '' increment character position
    xpos C@ chars =>    '' and wrap to next line if necessary
      IF 
      xpos C~
      LCDLF 
      THEN
    ;
pub LCDchar ( char -- )
    0 REG C@ LCDCHAR    '' Restore character and pass as a character to the LCD
    ;
pub LCDCtrls ( ctrl -- )    '' Look up and execute the code that corresponds to the ctrl character
    $10 LOOKUP LCDchar    { Default vector if above limit of $10 }
    LCDchar LCDHOME LCDchar LCDchar 
    LCDchar LCDchar LCDchar BEEP 
    LCDchar LCDchar LCDLF LCDchar 
    LCDCLS LCDCR LCDchar LCDchar 
    ;
pub LCDEMIT ( char -- )    '' Process the ASCII character either as a control or as a printable character
    DUP BL <        '' Less than a BLANK ($20) is a control character
      IF DUP 0 REG C! LCDCtrls 
      ELSE LCDCHAR    '' else it is display data
      THEN
    ;

[Brian Riley]

Another Tachyon script ... Ping))).

I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.

Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.

One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.

[prof_braino]

yes its perfectly fine and a valid choice, just noting that it is different in one of the many ways it can be different. Propforth tends to have many, very long scripts, and the delay was getting bothersome. We figured the chance to have an overrun meant we would get false bugs, so we made a different choice. Tachyon is attracting more of the advanced users and so this should not be an issue. Anything that works really well is fine in my book.

It is really cool how far you've come in such a short time. Clearly you don't waste as much time watching TV as some of us.

[Peter Jakacki]

Tachyon does the interpreter's compilation in-line, it does not send it over to another cog so is susceptible to overrun on the input.
This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.

But Tachyon does not go through long long development cycles before release, it is a work in progress and the primary focus was to get it up and running as fast as possible and build up from there. So I use the expression "bear in mind" a bit but it's a reminder that any deficiencies Tachyon has now is simply because of it's being incomplete although it is "complete at any particular stage" in that it functions well and it's no slouch at 7 weeks. Compile speed is not really that important in the whole scheme of things so it has a lower priority at present as other things are far more important. IIRC PropForth had problems with line delays being required for a long time before that was finally fixed up and now it works really well. Being able to squeeze as much as I do out of one cog without having to resort to special PASM operations simply means that Tachyon will not fail to impress when it opens up to full throttle.

Also, the compilation in-line is very deliberate and can and will perform a lot faster than all that multiple buffering that goes on with serial buffers, terminal input buffers etc. The main offender at present is not having a dependable method of handshaking as some terminals support XON/XOFF and some don't. Putting in a longer line delay means it takes 5 seconds instead of 1 or 2 to compile a file, hardly anything to lose sleep over. In the end runtime speed is far more important which Tachyon cannot be faulted for, especially in the area of I/O and common operations which is where an MCU needs to perform. If that's a temporary tradeoff then I'm certainly happy with that

[prof_braino]

Tachyon does the interpreter's compilation in-line, it does not send it over to another cog so is susceptible to overrun on the input.
This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.

[Tor]

Been following the thread. Seems like I should be able to run this thing on a QuickStart, with or without my VGA+ board. That combo is such a nice little "mini"computer which just might be the thing for playing around with Forth.

In the past when I've looked into Forth and Forth-like languages I always found it interesting, but I always ran into a wall when I wanted to try Forth for the stuff I normally do in some high-level language on the computer.. writing emulators and data processors. Forths in general won't seem to let me work that way, with programs taking input from files, letting me edit source in my editor and so on. But with a QS I can as well do the interactive thing, as there's no operating system or filesystem there anyway.. so I'll have a go at it this weekend.

-Tor

[JonnyMac]

Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.

I went through the same thing until I found the line delay setting in TeraTerm.

[Oldbitcollector (Jeff)]

Hi Jeff, I'm shocked, absolutely shocked (Casa Blanca I think) that the extended features didn't backup to EEPROM. Normally after loading in a fresh kernel the idea is to download EXTEND.fth and if there were no errors in download (usually due to coming in too fast without handshaking) then it will do an automatic backup. So just make sure that you have enough line delay on your terminal settings (30 to 50ms) and that there were no errors. However the VGA DEMO does not do an automatic backup because it's a demo but you can tell it to at any time by typing BACKUP. The VGA demo is overlapping into ROM until I free up some more memory so you will see some garbage at the bottom of the screen when it's not blanked. Is that what you mean by "glitched".

I'm going to try the EEPROM thing again on the Quickstart, with and without my plug-in-board. I'm wondering if something there is getting in thew way. (Like USB power enable jumper maybe?) -I'll report back..

(Darn it! I took another chip!)


Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.
Jeff

[prof_braino]

Read post #195.

Wow. 195 posts. If there were one post detailing each word in the dictionary, the thread would be done already.

[Brian Riley]

IN the VGADEMO.fth, the last lines of the file are

\ CORRECT THE 5X7 FONT FOR USE WITH VGA
FONT $1D + C@ $0F = IF FONT $60 7 * ADO I C@ #27 REV I C! LOOP THEN
\ back it up into EEPROM - don't use paging NOTE: this becomes redundant once the font table is fixed
FONT DUP $60 7 * ESAVEB
END

what is "ESAVEB" ??? It gets a "???" and I have looked all over without finding a clue!

[JonnyMac]

Thanks. I was probably being a bit too literal; I saw an RX object declared, but no TX object.

Update: Up and running between work tasks.

[Rsadeika]

Read post #195.

Ray

[JonnyMac]

Am I missing something, or is a VGA display required to run Tachyon? Is there not a version that is serial only so I can play with it on a QuickStart of EFX-TEK board? Forgive me if this is a stupid question, I still feel a bit out of the clubhouse on this whole Forth thing, but I'm very interested.

[User Name]

...In the beginning Forth was the fastest way to get software up and running on a new CPU...

Yup. EasyWriter, the first word processor for the original IBM PC was written in Forth. I remember it fondly.

[prof_braino]

This project is still fairly young. Maybe its not too late for this request....

Could Peter (and the group) attempt to sketch out the high level functional requirements, the required functions, the code specific code that implements each and the tests that prove the code? Just a sketch. It doesn't have to be complete at least not right off the bat. But if Peter could make a start, and post it on his google docs, other folks could at least poke at it and maybe fill in some stuff... Hopefully, if would grow as more folks read the drafts, and scratch their heads and fill in more details they figure out. Kind of an organic, untended review process?

This is kind of a big request, and unusual I know. BUT this requirements-function-code-test trace is found on most successful projects I've encountered. I think could be a value add for maintainability and training, and well worth the effort.

Also, I'm working on designing something like this for another project, and I need more data on what works well and what to avoid. You guys are working well together, I want to capture what you do well and try to make a sequence of behavior that others can emulate on more projects. This project is BIG enough to include multiple folks, yet small enough for this experiment to be manageable.

Any takers? Too nuts? Thanks for your consideration.

[Peter Jakacki]

Yes, I'd go with that definition especially considering the amount of work I've put into the different aspects of this projects and made it the most open project that I know of. It's so open that if you are at the right place in an online document you can see me making changes. Is there any tiny aspect of the project that I haven't laid out on the table? Perhaps I should rename the project to "Pearls" if you get my drift

[RickInTexas]

Keep up the great work, Peter.

I'm going to try you're direct PS/2 USB keyboard with my Kensington "Keyboard for Life" that came with one of those ugly USB/PS/2 adapters. Interesting App note.

[RickInTexas]

Hi mindrobots,
sorry my English is not good enough, what exactly means "rough crowd"?
I only wanted to give some hints regarding this question of Peter....
Christof

"rough crowd" just means unduly critical, hard to please.

[Peter Jakacki]

I took the time to play with TACHYON the first time the other night.. I can definitely see the attraction here.

I compiled my own source using my VGAplus/Quickstart combo. The VGA demo was a little glitchy, but still very cool, and for some reason I couldn't get the extended features to stick when the unit is powered down. Are these written to EEPROM, or do they need to be reloaded at each power up?

Ether way, are there any Forth applications which were designed which would run on this setup?

Great job Peter. I'm not completely a Forth convert, but I'm definitely planning some more time with this.
(Yes, I swear, I CAN just eat ONE.)

Jeff

Hi Jeff, I'm shocked, absolutely shocked (Casa Blanca I think) that the extended features didn't backup to EEPROM. Normally after loading in a fresh kernel the idea is to download EXTEND.fth and if there were no errors in download (usually due to coming in too fast without handshaking) then it will do an automatic backup. So just make sure that you have enough line delay on your terminal settings (30 to 50ms) and that there were no errors. However the VGA DEMO does not do an automatic backup because it's a demo but you can tell it to at any time by typing BACKUP. The VGA demo is overlapping into ROM until I free up some more memory so you will see some garbage at the bottom of the screen when it's not blanked. Is that what you mean by "glitched".

[Brian Riley]

An update to the Tachyon EMIC2 code ... more comments ... enhanced Demo ... enjoy

[Oldbitcollector (Jeff)]

I took the time to play with TACHYON the first time the other night.. I can definitely see the attraction here.

I compiled my own source using my VGAplus/Quickstart combo. The VGA demo was a little glitchy, but still very cool, and for some reason I couldn't get the extended features to stick when the unit is powered down. Are these written to EEPROM, or do they need to be reloaded at each power up?

Ether way, are there any Forth applications which were designed which would run on this setup?

Great job Peter. I'm not completely a Forth convert, but I'm definitely planning some more time with this.
(Yes, I swear, I CAN just eat ONE.)

Jeff

[Peter Jakacki]

Yes, it looks good and it works! Win-win. If anyone wants to know how to interface a device using TACHYON then just ask as I will consider these for future project pages.

BTW, ANYONE at all, even die-hard C coders (no fun) should consider loading TACHYON onto any new prototype because it's the mother of all debuggers, and friendly too (if you have bothered to learn some of the etiquette involved to talk nicely that is). In fact this is where OpenFirmware (and funnily enough Java (C programmers version of Forth) at the same place years later ) was used to test out new Sun Sparc prototypes. In the beginning Forth was the fastest way to get software up and running on a new CPU where the old compilers were useless and because it is was such a great debugging tool in that you could write complete programs and test suites in it that it was incorporated into Sun workstation ROMs and evolved into OpenFirmware.


PS/2 interfacing project document
Introduction to Tachyon Forth

[mindrobots]

Peter, I really like the "ProjectDoc" format. Everything in one place, clear schematics, nicely formatted code, theory as a bonus!! These should be a great addition.

[Peter Jakacki]

I've decided to make some project pages available which have both code and documentation, schematics etc. There are stacks of devices that I have already interfaced to but here's one for starters that I just started working on yesterday. It's still a WIP but this gives you an idea. I will place the links at the bottom of the Intro page.

Other pages that I will put up shortly are:
Character LCD interfacing
Graphic LCD interface
Serial interfacing
VGA (of course)
I2C Accelerometer
I2C devices in general
Parallax GPS
Sound generation
etc

[D.P]

Peter and I exchanged some back channel emails and he gave me some code to get me started writing code to interface to an Emic2 Text-To-Speech module.

Easier said than done. But after a couple of hours hitting myself on the forehead, it all came together ... the devil indeed is in the details.

Enjoy ....

Great to see some Tachyon .fth that drive Parallax "sensors". While the code is very straight forward for the adapt forth'r I think it would be great for you to fully explain everything in your code so the neophyte can follow along. Assume nothing. Again thanks for contributing your efforts.

[Brian Riley]

Peter and I exchanged some back channel emails and he gave me some code to get me started writing code to interface to an Emic2 Text-To-Speech module.

Easier said than done. But after a couple of hours hitting myself on the forehead, it all came together ... the devil indeed is in the details.

Enjoy ....

[Rsadeika]

For you convenience these are the lines to comment out in the source (182 & 196 in my source):

I kind of thought that those two lines would be it, but I wanted to make sure. Thanks Peter.

Ray

[Peter Jakacki]

I just checked your latest source and binaries folder, it seems that you are only going to support Tachyon1v0-VGA, meaning includes VGA? I noticed that when I run that particular version with my QuickStart board, it lights up LED16, and LED17, which is becoming very annoying. So, I guess if you could offer up exactly what lines of code I would have to comment out to fix it so it is strictly a serial terminal experience?

I tried Tera Term, the program has changed from what I remember it being about four or five years ago. The program is more "real" terminal screen oriented, which I like, and the fact that you can paste to the screen in an effective manner is also a plus. A thumbs up on that program.

I just gave the "Forth Primer" a cursory look, and I noticed it gives a good preliminary introduction which is good. But, where do I find a good explanation for something like the words BACKUP and AUTORUN? Or are these two words just pertaining specifically to your dictionary?

As I spend more time with Tachyon, I find it is becoming more familiar, and therefore less "Yoda" like, as one forum member described it. Very good job Peter, I can hardly wait to see what all this looks like when it finally "grows up", hopefully we can see a fast growth rate LOL.

Ray

There's a readme.txt in the dropbox folder which addresses the VGA plus even at present you can type NOVGA to kill the VGA cog. BACKUP and other special functions are covered quite a bit in the Introduction page so make sure you have a read of it especially with a system running.

The latest binaries start up at 57600 baud and after you have loaded EXTEND.fth you can change this with BAUDRATE which becomes effective after the next reboot (hit ^C or ALT-B to send a break from TeraTerm).

For you convenience these are the lines to comment out in the source (182 & 196 in my source):

OBJ

coms     : "HS-SerialRx"    ' Mega-baud serial receive driver
vga      : "VGA_512x384_Bitmap"

''=======[ PUBlic Spin Methods ]===============================================
PUB Start
{{{
 - Tachyon starts up in cog 1
 - Serial receive starts up in cog 2
 - vga starts up in cog 3
start returns and cog 0 ends - this Spin cog now terminates and is free for reuse as are cogs 4..7
}}

long[@bit_ticks] := clkfreq/long[@baudrate]    ' Force VM transmit routine to correct baud
cognew(@RESET, @MAIN)            ' Tachyon starts up in cog 1
word[@rxbufptr] := coms.start(rxd, long[@baudrate])     ' Serial receive in cog 2
vga.start(16, @Colors, Pixels, @vgasync)    ' VGA in cog 3

[Rsadeika]

I just checked your latest source and binaries folder, it seems that you are only going to support Tachyon1v0-VGA, meaning includes VGA? I noticed that when I run that particular version with my QuickStart board, it lights up LED16, and LED17, which is becoming very annoying. So, I guess if you could offer up exactly what lines of code I would have to comment out to fix it so it is strictly a serial terminal experience?

I tried Tera Term, the program has changed from what I remember it being about four or five years ago. The program is more "real" terminal screen oriented, which I like, and the fact that you can paste to the screen in an effective manner is also a plus. A thumbs up on that program.

I just gave the "Forth Primer" a cursory look, and I noticed it gives a good preliminary introduction which is good. But, where do I find a good explanation for something like the words BACKUP and AUTORUN? Or are these two words just pertaining specifically to your dictionary?

As I spend more time with Tachyon, I find it is becoming more familiar, and therefore less "Yoda" like, as one forum member described it. Very good job Peter, I can hardly wait to see what all this looks like when it finally "grows up", hopefully we can see a fast growth rate LOL.

Ray

[Peter Jakacki]

I have moved most of the old binaries from Dropbox into a sub-folder called "old". Now there are only two, why? Because the kernel has been updated to handle baudrate as a variable so now the standard binaries are set for 57600 baud and either a 5MHz or 10MHz crystal with VGA (and for now a 6MHz binary). When you extend the kernel with EXTEND.fth you can change the baudrate from there as well as turn off the VGA.

@Brian: Thanks Brian, trouble is I am far too aware of all the "little things" that need to be checked and things I have not implemented yet. I've been bogged down a little with using Tachyon in some applications so I'm itching to get the keyboard and SD stuff up and running now. I think that lockup you mentioned may have been to do with the output redirection word VGA which used to have a bug. The normal demo doesn't use this though.

[Brian Riley]

VGA Report - Kernal 120814.1200, Extensions - 120814.1330, VGADEMO - 120814.1200

Seems to be a great improvement. Very stable so far. Multiple passes at DEMO interspersed with VGA/CON sequences ... CLRSCNs ... HOMEs ... etc ... such sequences, in the past, absolutely would have caused a hard lockup requiring a hardware reset.

Time for a modest bow (as befits a 6 week old!), Peter.

[mindrobots]

Sorry, Christof, no offense.

I was just joking with Peter. Tachyon has been around for less than 6 weeks and there have been a number of comments as to its completeness and usability. He had made a reference to his 6 week old baby in an earlier posting.

It may not be production ready but it is impressive the features it has, the speed at which it has been created and the potential it has.

You were complimentary, correct in your statements and said you'd be back to check it out.

[jazzed]

Thanks Steve, I normally try to keep a low profile but occasionally I stick my head up to get it smacked about

I'm trying out SimpleIDE on LinuxMint 13 with Cinnamon desktop, it looks good so far, I have just got to get it to compile properly! BST has been good to me, I like to be able to see the listing to make sure the compiler is doing what I want it to and to help debug any problems. It's unfortunate that Brad never made the source for BST open.

Sorry Peter. I suppose I'm too outspoken right or wrong, and can't seem to avoid getting lumps either way.

LinuxMint13 is one of my test platforms. The last Debian package works there. I'll post an update soon.

[Christof Eb.]

Hi mindrobots,
sorry my English is not good enough, what exactly means "rough crowd"?
I only wanted to give some hints regarding this question of Peter....
Christof

[mindrobots]

Peter,

Rough crowd on a 6 week old baby!

[Christof Eb.]

....What I find more amazing than Forth on the Propeller though is why more people have not taken the time to discover it's huge potential for us Prop heads. I'm only talking about one lousy hour here, not months. (Stop kicking the tires, jump in and take it for a drive)

Hi Peter,

well, I did take some time. I am very impressed by your Forth and I did want a fast FORTH.
But -sorry- at that moment it was a system, that cannot work with multiple cogs, a system that is changing very fast, a system that is rather different to standards and has got only it's commented source as docu. Frankly speaking this system is still not so very useful at this very moment, sorry again. I think Forth is a little bit different to BASIC or C, because when you use Forth, you want to understand, what Forth does.

I have now seen, that you have started a webpage with some explanations and there is backup and cold now written as UPPERCASE. So this looks very promising for the future and I am sure, that I will be back again... Good luck with this nice work!
Christof

[Rsadeika]

I tried another scratch build using SimpleIDE, and it worked. The first time I did this, I made a very bad assumption, without looking at the code, I took for granted that _clkmode = pll16x, and _xinfreq = 5_000_000, plus baud = 57_000. A very bad mistake on my part, now with those values set correctly, for my board anyway, using SimpleIDE to run Tachyon works like a charm.

I had some more time to play with Tachyon, and I think I am starting to like the experience. I also did a WORDS, and it printed out a bunch of words, I am assuming that is the dictionary, in its present state? Some of the words are somewhat self explanatory, but some, for example CLS, did not do what I expected. I expected the screen to be cleared, that did not happen.

The other thing that I am having trouble understanding is BACKUP. Does this mean that when you create a bunch of words that equal a small program, and do BACKUP, all of the words and small program gets saved, so when you REBOOT, or do new start all of the stuff is there, and does not have to be retyped?

Thanks Peter, this is starting to look good.

Ray

[Peter Jakacki]

SimpleIDE and Tachyon - WIN/WIN in my book

I've been watching the debates and troubles with SimpleIDE and Spin in general and particular in building Tachyon (and PropForth) so it was time to take some time and see what this was all about.
<snip>
Thank you, Peter!
Thank you, Steve (jazzed)!

Thanks Steve, I normally try to keep a low profile but occasionally I stick my head up to get it smacked about

I'm trying out SimpleIDE on LinuxMint 13 with Cinnamon desktop, it looks good so far, I have just got to get it to compile properly! BST has been good to me, I like to be able to see the listing to make sure the compiler is doing what I want it to and to help debug any problems. It's unfortunate that Brad never made the source for BST open.

[Peter Jakacki]

I mentioned, in a post, that my objective was to have SimpleIDE for Spin compile the source code and burn the EEPROM. For whatever reason it compiled and loaded but Tachyon was not working. The same thing happened when I used the Propeller tool to compile the source code. The problem was solved when I just downloaded the Tachyon binary and had the Propeller tool burn the EEPROM. A side note, I am not sure if a lot of the beginners know how to load a bin file from within the Propeller tool, I sure don't.


I sort of described it already.


I am still playing around with it, so will hold back on my thoughts about that. I must say it is a barebones setup, so it may be a struggle to really get a good feel for it. I would mention that I did not find a write up about your version of the "dictionary" of words, maybe a brief description of the "words" may be in order. Keep in mind the people that will be trying this have no idea as to what Forth is, or what the existing "words" do.

Since I have a DNA-RTC board, at some point I will want to be able to use everything on the board, RTC, Flash ram, and whatever "shield" becomes available(RPi). I also have some Xbee modules laying around, hopefully Tachyon would be able to handle that. And so I travel into the new(old) frontier ...

Ray

Barebones???????? Ah well, there's no pleasing some people then so I am not sure what it is that you are after. If the source code compiled then there is no problem. If there is a problem then it is to do with the crystal settings and/or the baud rate which is right there in the CON section around line 143 which every Spin programmer is familiar with:

CON
_clkmode    = xtal1 + pll8x        ' <---------------- change to suit
_xinfreq    = 10_000_000            ' <---------------- change to suit your crystal

baud        = 3_000_000          ' tested to 3_000_000 baud, probably okay for 4M as well

Try the Intro page and just bear with it and follow along and try the few things mentioned. There are reference links to Forth at the bottom of the page which covers Forth in general. The rest of the information is to be found in the online source documents which attempts to combine source and documentation. I did attempt to start a glossary of Forth words but alas, there are only 24 hours in a day and I already use 25 of them.

BTW, those peripherals you mentioned are trivial and very easily interfaced to directly from Tachyon without the need for any special PASM drivers. I use many different types of RTCs and Winbond Serial Flash etc. XBEE is only serial basically.

[mindrobots]

SimpleIDE and Tachyon - WIN/WIN in my book

I've been watching the debates and troubles with SimpleIDE and Spin in general and particular in building Tachyon (and PropForth) so it was time to take some time and see what this was all about.

1) I loaded the latest (0.8.1) SimpleIDE on a Windows laptop
2) start SimpleIDE up and switch to SPIN compiler mode
3) close Hello.c (it opens up untitled.something)
4) cut/paste Tachyon SPIN source from the web page into the untitled doc
5) update _clkmode to pll16x and _xinfreq to 5_000_000 to match my QuickStart and changed bauc to 115_200 to match SimpleIDE terminal speed
6) hit the "gear" in SimpleIDE to make the current file the project (when I hit the "Gear", I was pleased that SimpleIDE found an object Tachyon.SPIN used in the c:\propgcc\spin folder)
7) I created a new document and cut/paste Peter's HS-SerialRx.spin code into it and saved it
8) Hit the blue button in SimpleIDE and it compile the spin code, loaded my QuickStart and the terminal window popped up talking to Tachyon.
9) typed in WORDS and saw that Peter has been a busy, busy boy creating Forth!!

That seemed pretty simple and a well spent 15 minutes or so to try out two useful tools.

...and I can now do the same thing on my Mac and on My Linux machines without any concerns (except maybe for some terminal issues).

Thank you, Peter!
Thank you, Steve (jazzed)!

[mindrobots]

I would mention that I did not find a write up about your version of the "dictionary" of words, maybe a brief description of the "words" may be in order. Keep in mind the people that will be trying this have no idea as to what Forth is, or what the existing "words" do.

Ray

I think we can cut Peter a little slack here. Right now, I'd rather have his time spent developing rather than documenting a still changing dictionary. His sources are rather well documented as far as finding the words defined so far.

SOME of the people trying this have no idea what forth is, others have been using forth and are excited to see what Peter is doing and are looking at his code to see how it works and what he's done "under the hood" and how he has implemented standard/common words.

[Rsadeika]

I did a bit of a walk through video with compiling the source from the online pages but do you think there were some tricks to compiling even just the binary?

I mentioned, in a post, that my objective was to have SimpleIDE for Spin compile the source code and burn the EEPROM. For whatever reason it compiled and loaded but Tachyon was not working. The same thing happened when I used the Propeller tool to compile the source code. The problem was solved when I just downloaded the Tachyon binary and had the Propeller tool burn the EEPROM. A side note, I am not sure if a lot of the beginners know how to load a bin file from within the Propeller tool, I sure don't.

What happened that it wasn't so smooth?

I sort of described it already.

Now do you like it.....??? (Remember this will eventually be a complete stand-alone as well as a lean target kernel)

I am still playing around with it, so will hold back on my thoughts about that. I must say it is a barebones setup, so it may be a struggle to really get a good feel for it. I would mention that I did not find a write up about your version of the "dictionary" of words, maybe a brief description of the "words" may be in order. Keep in mind the people that will be trying this have no idea as to what Forth is, or what the existing "words" do.

Since I have a DNA-RTC board, at some point I will want to be able to use everything on the board, RTC, Flash ram, and whatever "shield" becomes available(RPi). I also have some Xbee modules laying around, hopefully Tachyon would be able to handle that. And so I travel into the new(old) frontier ...

Ray

[Peter Jakacki]

I've cleaned up the VGA DEMO.fth source and improved the speed as well. Interesting effect if you have loaded EXTEND.fth and VGA DEMO.fth and after running DEMO try this:

DECIMAL 19 APIN 2249 HZ

then try different RGB pins such as
21 APIN
then try
1 MHZ
etc
Just a little interactive fun.

EDIT: Oh, and this slow moving mesh using counters A & B
DEMO ok
ok
DECIMAL ok
23 APIN 4390 HZ ok
B 23 APIN 3,999,985 HZ ok

[Peter Jakacki]

Yes, now that I am going over the VGA code I have already made some improvements since possibly you have loaded this. Once that is done I will update the dropbox files and binaries as well. So I guess I should rename it VGA DEMO.fth as that is what it really is. So that also means that I will have a separate source for the VGA BITMAP driver which can be relied upon for applications. I will see if I can set it so you don't have to tell it to set the COGREG for plotting unless you want to change it for other devices such as LCDs.

[Brian Riley]

VGA REPORT

New EXTEND.fth and VGA.fth work fine. The 'bleeding edge' code is on the Intro links, not in the dropbox folders.

THANK YOU for putting dates in the .fth files!

The command "6 3 COGREG!" has to be run for VGA to work, so for now If you do not run DEMO the various VGA commands do not work.

VGA is stilll a little shakey. I think some commands are still waltzing into forbidden territory and quietly getting lost. That said it is still good and DEMO is impressive.

[Peter Jakacki]

There's been quite a few more features as I go through my testing and improvements which concentrates on porting applications across to TACHYON and then looking at what I need to do to make the kernel better etc. As I am still testing my CASE .... OTHER features I did however introduce a VECTORS word which very simply takes an index and executes the nth+1 word following the VECTORS. There is also a default vector if the index is over the limit. Here's how it looks:

: LCDCtrls
    $10 VECTORS LCDchar        \ Default vector if above $10
    LCDchar LCDHOME LCDchar LCDchar 
    LCDchar LCDchar LCDchar BEEP 
    LCDchar LCDchar LCDLF LCDchar 
    LCDCLS LCDCR LCDchar LCDchar 
    ;
: LCDEMIT 
    DUP BL < IF DUP 0 REG C! LCDCtrls ELSE LCDData THEN
    ;

There's also all the ++ -- ~ ~~ operators that we like in Spin although they are just there for convenience really. Under the hood the TACHYON compiler now handles double the number of vectors via XCALLs and YCALLs which internally are used to point to bytecode using just a single byte index to keep it compact. All the common or looped operations are as lean and mean as possible and the I/O operations are many times faster than Spin.

You can glean a lot of information too just from studying the Forth sources (vs the Spin tool compiled kernel) such as EXTEND.fth etc.

Thanks for the feedback everyone.

[Peter Jakacki]

So, I finally got Tachyon working. For some of the beginners, you want to download the binary, and have it auto downloaded to the EEPROM, it took me awhile but I figured it out. Now, do I like it ...

Ray

I did a bit of a walk through video with compiling the source from the online pages but do you think there were some tricks to compiling even just the binary? What happened that it wasn't so smooth? Now do you like it.....??? (Remember this will eventually be a complete stand-alone as well as a lean target kernel)

[Peter Jakacki]

VGA PROBLEMS

Scenario #1 - Demo Board, fresh load 120810.1730, fresh load of EXTEND.fth 120810.2150, fresh load of VGA.fth (No date but most recent)

Observations

1 - while VGA.fth was loading. Screen turned blue then two bands of white appeared ... the bottom fixed, the top grew pixel by pixel while the code was loading,

Attachment 94861
<snip>

Hi Brian, welcome to the bleeding edge, it's a fun ride but it gets a little bumpy! I had said that I would get around to it but unfortunately that didn't happen until now. The main problem is that I need more memory, especially as I am developing and I haven't yet squeezed the kernel up. So at the present now that I have expanded both the kernel and extensions without any optimizations I end up with free space from about $3700. Obviously the VGA.fth DEMO sets the pixel buffer at $3000 and what is happening is that this directly overwrites the code. So I've changed the calculation for the pixel buffer and made it relative to the current free space. There's also been a change in the kernel since in that the PLOT primitive used to be locked to 64 bytes per line as a shift constant of 6 but now that setting is programmable and is set via 3 COGREG! (I will come up with a better name). So I have updated the DEMO with these two small changes and it works fine on the latest kernel although of course there will be junk at the top and bottom of the screen which can be blanked by setting this tiles to the same foreground and background color.

The junk at the bottom of the screen is actually the ROM has the VGA driver reads pixels from memory sequentially and the pixel buffer overlaps ROM. The kernel has been growing as I have been adding more and more functions yet it is still very lean and faster and smaller than Spin code. So as I mentioned, the kernel will be compacted through reuse and keeping the user part of the dictionary in EEPROM etc and then there will be more memory again for the VGA display.

[Rsadeika]

So, I finally got Tachyon working. For some of the beginners, you want to download the binary, and have it auto downloaded to the EEPROM, it took me awhile but I figured it out. Now, do I like it ...

Ray

[D.P]

I spoke with Sal about Tachyon at yesterday's meeting, we are winding down development as we near release. He has some free time, so he said he can give comments if you are interested. In the few minutes we looked at it, he got a better understanding than I got in the last several weeks.

He's most interested in the design decisions you made in Tachyon that are different from propforth, and how they pan out. Sal had examined Cliffe Biffle's propellerforth and decided to do many things different, as Sal's goals were different from Cliffe's. Tachyon has made some choices more similar to propellerforth, and it will be interested to compare the benefits and drawbacks of each method. Currently the assumption is that both tools are designed for different purposes and this accounts for differences. For us it would be best to determine if we ought to do something "a better way" now before we get much further in the release. Review is a good way to find the reasoning behind the choices.

His first comment was"Well, this is going to be fast as all get out for the bit-banging stuff!".

Are you interested in getting more comments and questions? I think he said he'd send some by email if you want.

Hi Prof, are you gonna gives us the skinny on the Sunday Call with Sal, (in the propforth thread) it's been required reading for me ever since it started. I want both versions: Full blown Forth, PropForth, and peddle to the metal Tachyon.

[Brian Riley]

VGA PROBLEMS

Scenario #1 - Demo Board, fresh load 120810.1730, fresh load of EXTEND.fth 120810.2150, fresh load of VGA.fth (No date but most recent)

Observations

1 - while VGA.fth was loading. Screen turned blue then two bands of white appeared ... the bottom fixed, the top grew pixel by pixel while the code was loading,



2 - when done I typed "DEMO" and it reset.

...
: VGA    ' VEMIT >PFA uemit W! ;  ok
  ok
  ok
END
End of source code, there were 0 errors found
CODE   @$3174  - bytes used in this load = 846
NAMES  @$1A31  - bytes used in this load = 174
XCALLS @ 30 entries free (not including YCALLS) ok
  ok
DEMO


 Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120810.1730
----------------------------------------------------------------
  ok

* * * * * * * * * * * * * *

Scenario #2 - All the same except Prop Board was a PPDB

Observations - same as above

* * * * * * * * * * * * * * *

Scenario #3 - same as #1 and #2 except board was a Propeller platform, with Wulfden VGA-A/V board

Observations - same as #1 and #2

[Peter Jakacki]

I made a point of not looking at any other code too closely, or even much at all. I wasn't too sure how it would all pan out, I just basically jumped in feet first and got the VM running and built on that. Along the way I changed things both from a runtime point of view and also from a Spin tool compile point of view. The Spin tool is one of our many constraints besides the Prop's architecture and I didn't want to fight it too much, just work along with it.

So okay, go shoot, but please be gentle, I might cry like a 6 week old baby

[prof_braino]

I spoke with Sal about Tachyon at yesterday's meeting, we are winding down development as we near release. He has some free time, so he said he can give comments if you are interested. In the few minutes we looked at it, he got a better understanding than I got in the last several weeks.

He's most interested in the design decisions you made in Tachyon that are different from propforth, and how they pan out. Sal had examined Cliffe Biffle's propellerforth and decided to do many things different, as Sal's goals were different from Cliffe's. Tachyon has made some choices more similar to propellerforth, and it will be interested to compare the benefits and drawbacks of each method. Currently the assumption is that both tools are designed for different purposes and this accounts for differences. For us it would be best to determine if we ought to do something "a better way" now before we get much further in the release. Review is a good way to find the reasoning behind the choices.

His first comment was"Well, this is going to be fast as all get out for the bit-banging stuff!".

Are you interested in getting more comments and questions? I think he said he'd send some by email if you want.

[Peter Jakacki]

Yes, just as the serial and VGA object have been included but with Forth controls. I don't envisage any problems in running Forth from multiple cogs and I may look into it in the next few days.

[nglordi]

Since Tachyon is still a baby it hasn't yet developed the ability to run in multiple cogs. It's easy enough to have it launch into several cogs at startup, I just have have to make sure that all the controls are in place to have them idling until I pass control to them. Perhaps Tachyon will develop this ability after the next feeding and burping

OK, since the forth kernel resides in cog 1, the cog words and registers only apply to cog 1. This means a that cogdump, for example, only dumps data from cog 1.

If I wanted to add words which would control servos, I could include an existing spin/pasm servo object in the Tachyon spin program as well as the required global variables.
The necessary servo control words could then be written in forth.

NickL

[Peter Jakacki]

Hi.
I think TACHYON is very interesting.
Sorry, but I don't use TACHYON, because many basic word is UPPERCASE letter.
I cannot continue to read statement using UPPERCASE letter.
So I cannot write codes on TACHYON.
Maybe English is foreign langauge for me.

You don't have to use Tachyon at all, that's up to you. If it really is for the reason you stated then perhaps it's better that you don't, Tachyon will still be what it is. Perhaps because of the influence of C and other languages we seem to have "lost" the use of uppercase, why is that? I have previously mentioned why I use uppercase and this immediately allows me to see a word like "WASH" vs "wash" and know that one is an action while the other is a variable. Should we also document in lower case without bold headings and color etc? I'm glad we don't.

BTW, Tachyon is not just interesting, it is very fast, especially compared to PropForth. Languages are not a matter of loyalty or tradition, they are a matter of necessity.

[caskaz]

Hi.
I think TACHYON is very interesting.
Sorry, but I don't use TACHYON, because many basic word is UPPERCASE letter.
English(alphabet) is foreign langauge for me.
I cannot continue to read statement using all UPPERCASE letter.
So I cannot write codes on TACHYON.

[Peter Jakacki]

Peter:

I have finally been able to spend time with TACHYON. I very much like the features you have built in this forth version. However, I
have some questions relating to cog usage.

For example, suppose I wished to run two different versions of the UFO counter example in two different cogs. How would I do this?
PropForth has the cogx word which allows one to specify cogs and assign them to specific words. While you have a STOP cog word,
I can find no equivalent START cog word in the dictionary.

NickL

Since Tachyon is still a baby it hasn't yet developed the ability to run in multiple cogs. It's easy enough to have it launch into several cogs at startup, I just have have to make sure that all the controls are in place to have them idling until I pass control to them. Perhaps Tachyon will develop this ability after the next feeding and burping

[nglordi]

Peter:

I have finally been able to spend time with TACHYON. I very much like the features you have built in this forth version. However, I
have some questions relating to cog usage.

For example, suppose I wished to run two different versions of the UFO counter example in two different cogs. How would I do this?
PropForth has the cogx word which allows one to specify cogs and assign them to specific words. While you have a STOP cog word,
I can find no equivalent START cog word in the dictionary.

NickL

[Brian Riley]

I understand PC Forth compatibility, but PropForth and Tachyon are both on the Propeller. Do they have a similar dialect given the same architecture?

Yes ... and No ... There are hard core Forth manipulatives that are the same ... DROP, DUP, ROT, IF, AND, OR and so on. But then something simple like a pause, PropForth says "100 delms" to wait 100 msecs where as Tachyon says "100 ms" ... a small issue, but in my rarely very humble opinion point to Tachyon, in this case I think more readable. Then there are the Propellor uniquenesses, different names. Both sets of names pretty much obvious, but different approaches.

Sal and the Prof have delivered to us a vast package that I think most any noob can follow the tutorials and get running and learn from ... a Rolls Royce if you will. Peter on the other hand has given us a lean fast Jaguar with a seat almost right on top of the engine. Its a little short on features compared to PF but it has a strong foundation on which to build.

[Rsadeika]

I admit it, I use and like SimpleIDE. So, what does that have to do with anything, especially this thread? I went past the "tire kicking" stage, and decided to give TACHYON a run. I used SimpleIDE to compile, and burn the EEPROM, which occurred without any problems. The big problem is, it is not behaving very well with the serial terminal, even when set to the required 57600 BAUD. I used PST, and I get nothing, it takes a key press, but nothing happens which includes the typing of a few gibberish characters, and expecting an error message. When I run PropForth with identical conditions, it works. I also have a personal serial terminal program, which works with PropForth, but all I get with TACHYON is a screen that has '??????' symbols.

If I can make a suggestion, if you could setup TACHYON in such a way that it would run on SimpleIDE, using the built in Console window, it could simplify the interaction with TACHYON, maybe more people would be willing to take it for a test run. Or maybe I am having a big problem with trying to get your program to work, and it is my own personal problem. Just a suggestion.

Ray

[Martin_H]

If this was a PC Forth then there should be a very high degree of compatibility as there are also the ANSI standards. But since this is the Propeller we are talking about then there are aspects of the Prop that Forth needs to take into account just as Spin does also. I have my own philosophy which influences Tachyon too as does the Propeller.

I understand PC Forth compatibility, but PropForth and Tachyon are both on the Propeller. Do they have a similar dialect given the same architecture?

[Peter Jakacki]

That's all I do...which reminds me, I need to go and double check the VGA side of things again. If you do happen to leave the VGA active then it doesn't really matter for the moment unless you need access to P16..23. So it might be a good idea if I can make the VGA switchable.

[Brian Riley]

To produce a VGA-less Tachyon binary, it appears that I need to comment out the VGA object and remove the call to vga.start() ... is that all???

[Peter Jakacki]

If this was a PC Forth then there should be a very high degree of compatibility as there are also the ANSI standards. But since this is the Propeller we are talking about then there are aspects of the Prop that Forth needs to take into account just as Spin does also. I have my own philosophy which influences Tachyon too as does the Propeller. My initial reasons and goals for Tachyon was not to sacrifice any low-level speed in trying to introduce more advanced features. Forth is advantageous for direct low-level access which is also why the I/O words are tweaked to suit the Prop and implementing bit-bashed interfaces. The other requirement I had was to be able to compile a complete kernel in seconds with one simple keystroke with any further enhancements being loaded in the normal Forth fashion by means of the kernel itself. PropForth although being rather slow for my use is really neat though with it's advanced features and serial channels for multiprocessing.

What I find more amazing than Forth on the Propeller though is why more people have not taken the time to discover it's huge potential for us Prop heads. I'm only talking about one lousy hour here, not months. (Stop kicking the tires, jump in and take it for a drive)

[Martin_H]

How compatible are the PropForth and Tachyon Forth dialects? Last fall I spent time learning gforth and PropForth and while they are similar, a porting effort is required due to dialect differences.

Forth seems interesting, but I haven't really done anything major with it yet. Unfortunately I know Algol family languages too well and it is easier for me to work with Spin than to think Forth. The self hosting remote programmability is pretty neat, especially when coupled with a wireless link.

[Peter Jakacki]

Peter,

I've been reading your posts on the development of TACHYON with great interest and just want to commend you on a tremendous and remarkable effort - please continue :-)

Alas, I don't get a lot of "play" time and haven't for quite a long time now but I try to keep up with what's happing in and around this most clever silicon chip. I have alse been experimenting with Sal's PropForth to a limited degree and this too is remarkable - well done Sal.

In any case, just thought I'd throw these comments into the mix because it seems to me that many folk (like me) seem to have a large hurdle getting Forth to do anything so to follow on like a few earlier posts - here's a A$0.02 sample:

My own interpretation of Forth is that it is neither an OS or a language per se but a functional development environment with which the user/programmer develops their own vocabulary to address the specific needs of the project at hand. Having said this it seems most important to understand what the issue being addressed is and therefore what "words" are chosen to perform the required task-at-hand. I feel this is why many folk shy away because most programming disciplines are based on a more "formal" set of language specific semantics. Forth doesn't really have any but can if this is how the programmer designed their system - the system being the implementation of the project.

In addition to your code in post 152, specifically the set up of the counters and so forth, an earlier version of PropForth included a set of definitions, using the counters like you have, to define easy access for use with the COG counters (these can still be defined just as they were but are not in the current version I have loaded).

These words were "setHza" and "setHzb" and as their names imply:

16 5 setHza
20 15 setHzb

would set pin 16 pulsing at 5 Hertz and pin 20 at 15 Hertz concurrently using both counters in a single COG. Rather cool I must say :-)

Anyway, in response to Rsadeika's post # 153: here is a sample that I came up with - hopefully fairly self explanatory - apologies if not. I was thinking maybe a new Subject called "Forth Code Snippets" may be appropriate so feel free to move this post elsewhere.

The following is for a Parallax RPM (Rapid Prototype Module) using PropForth - it's a bit different to the usual demo board - in particular, the included LED's - 10 of them are inverted WRT their signalling so for the following, the "on" and "off" definitions need to be swapped.

: on dup pinout pinlo ;          \ ( n -- ) Set pin to output and enable
: off dup pinhi pinin ;          \ ( n -- ) Disable pin and set to input

: delay 500 delms ;              \ ( -- ) Delay for 500 milliseconds

: flash dup on delay off delay ;     \ ( pin -- ) Pulse PIN once with 500 ms duration

: flashes 0 do dup flash loop drop ; \ ( pin iterations -- ) Pulse PIN for number of ITERATIONS

: sweepup 16 10 0 do dup i + flash loop drop ; \ ( -- ) Pulse pins from pin 16 through 16 + 9

: sweepdn 25 10 0 do dup i - flash loop drop ; \ ( -- ) Opposite of sweepup

: sweepupdn sweepup sweepdn ;                  \ ( -- ) Guess what this does

Usage:
Any word as above - provide the indicated parameter(s).

Example: 16 5 flashes
Will flash pin 16 5 times with a 500 ms cycle time

Finally for this the PropForth "saveforth" words would write the above back to EEPROM so they survive reset/power cycles.

Peter, apologies for not providing this in TACHYON but ... :-)

Kind regards,

Thanks for your comments.

Looking at the way PropForth is coded and how it would be done in Tachyon one of the immediate things many might notice is that I use a lot of UPPERCASE words. I like to reserve UPPERCASE for action words and lowercase for variables and subroutines of functions etc. The other thing is that if I can choose a word that's short and sweet and understandable then I do so. For instance you have a word just for delay whereas I would just code in "500d ms" right where I need it although I do understand why you might direct it to one word but then that could benefit with a variable. Also you have words "on" and "off" just for setting and clearing an I/O pin. Rather a waste of a good general-purpose modifier so I already have ON and OFF as constants passed to action words. So I would perhaps say things like "ON I OUT" or "OFF I OUT" to turn an output on or off or anything else. That is also why I have words such as OUTSET and OUTCLR in that we should be able to see that they SET or CLR the OUTPUTS. If they are OUTPUTS then it also makes sense to make sure that the DIR register is set which is what they do automatically (after writing to the OUT register).

Also do loops could very well be simplified like this:
: SWEEPUP ... 16 8 ADO I FLASH LOOP ;
This is a much better way to code as it avoids unnecessary clutter and is also more efficient. I made up ADO for the sake of a better word at present rather than continually writing BOUNDS DO which converts "from for" into a "to from" form. Notice that the index is the value rather than added to the value, much simpler and clearer.

BTW, my counter words are expanded upon in EXTEND.fth and rather than typing in a rather awkward word such as "decimal 1000 setHzA" as you would in PropForth I type in "1000d KHZ" which is readily understood and the selection of A and B are latched with "A" or "B" anywhere before the action wordas is the output pin (APIN). Unless some thought is given as to how others might read it rather than just getting it functional then Forth (not the programmer) will be criticized for it's readability as a "write-only" language.

EDIT: If you try the toggle pin exercise I described earlier in PropForth rather than Tachyon you will find that it runs very slow compared even to Spin so it's probably best to show Tachyon code on this thread.

[he1957]

Peter,

I've been reading your posts on the development of TACHYON with great interest and just want to commend you on a tremendous and remarkable effort - please continue :-)

Alas, I don't get a lot of "play" time and haven't for quite a long time now but I try to keep up with what's happing in and around this most clever silicon chip. I have alse been experimenting with Sal's PropForth to a limited degree and this too is remarkable - well done Sal.

In any case, just thought I'd throw these comments into the mix because it seems to me that many folk (like me) seem to have a large hurdle getting Forth to do anything so to follow on like a few earlier posts - here's a A$0.02 sample:

My own interpretation of Forth is that it is neither an OS or a language per se but a functional development environment with which the user/programmer develops their own vocabulary to address the specific needs of the project at hand. Having said this it seems most important to understand what the issue being addressed is and therefore what "words" are chosen to perform the required task-at-hand. I feel this is why many folk shy away because most programming disciplines are based on a more "formal" set of language specific semantics. Forth doesn't really have any but can if this is how the programmer designed their system - the system being the implementation of the project.

In addition to your code in post 152, specifically the set up of the counters and so forth, an earlier version of PropForth included a set of definitions, using the counters like you have, to define easy access for use with the COG counters (these can still be defined just as they were but are not in the current version I have loaded).

These words were "setHza" and "setHzb" and as their names imply:

16 5 setHza
20 15 setHzb

would set pin 16 pulsing at 5 Hertz and pin 20 at 15 Hertz concurrently using both counters in a single COG. Rather cool I must say :-)

Anyway, in response to Rsadeika's post # 153: here is a sample that I came up with - hopefully fairly self explanatory - apologies if not. I was thinking maybe a new Subject called "Forth Code Snippets" may be appropriate so feel free to move this post elsewhere.

The following is for a Parallax RPM (Rapid Prototype Module) using PropForth - it's a bit different to the usual demo board - in particular, the included LED's - 10 of them are inverted WRT their signalling so for the following, the "on" and "off" definitions need to be swapped.

: on dup pinout pinlo ;          \ ( n -- ) Set pin to output and enable
: off dup pinhi pinin ;          \ ( n -- ) Disable pin and set to input

: delay 500 delms ;              \ ( -- ) Delay for 500 milliseconds

: flash dup on delay off delay ;     \ ( pin -- ) Pulse PIN once with 500 ms duration

: flashes 0 do dup flash loop drop ; \ ( pin iterations -- ) Pulse PIN for number of ITERATIONS

: sweepup 16 10 0 do dup i + flash loop drop ; \ ( -- ) Pulse pins from pin 16 through 16 + 9

: sweepdn 25 10 0 do dup i - flash loop drop ; \ ( -- ) Opposite of sweepup

: sweepupdn sweepup sweepdn ;                  \ ( -- ) Guess what this does

Usage:
Any word as above - provide the indicated parameter(s).

Example: 16 5 flashes
Will flash pin 16 5 times with a 500 ms cycle time

Finally for this the PropForth "saveforth" words would write the above back to EEPROM so they survive reset/power cycles.

Peter, apologies for not providing this in TACHYON but ... :-)

Kind regards,

[Peter Jakacki]

I am using PropForth, but the question pertains to both Forth's. How do you write some code in Forth, compile, download and watch the LED blink? Can something like that be done, or are you locked into the interactive mode? If you are locked into the interactive mode, then it seems like you would have to have a Forth run like an OS.

Ray

Well you can't blink the LED from the "command line" in PropForth because looping is involved. However since Tachyon compiles each word as it arrives then executes the built-up code once the line is entered we can "cheat" and have loops while still in interactive mode. Normally you would have to create a word (new definition) and then invoke the word by it's name. Now to blinking leds, did you read that section in my Intro page? You should get a pretty good idea about how it works. I'm not sure why you think Forth is locked in interactive mode though??? Haven't there been scores of examples here and there? So don't just check the Intro page, go and read it and better still load Tachyon into a board and follow along.

[Rsadeika]

Yes, of course we could write some code in Spin, compile, download and find out.

I am using PropForth, but the question pertains to both Forth's. How do you write some code in Forth, compile, download and watch the LED blink? Can something like that be done, or are you locked into the interactive mode? If you are locked into the interactive mode, then it seems like you would have to have a Forth run like an OS.

Ray

[Peter Jakacki]

Being able to interact with the hardware is always rewarding and you can investigate, discover and understand more about the hardware. Take for instance the counters, what happens if we do this....or that. Yes, of course we could write some code in Spin, compile, download and find out. But that's slow. Here's how we do it in Tachyon Forth:

: CTR ( -- addr )        CTRA #29 REG C@ + ;          
: CTR! ( val -- )    CTR COG! ;
: CTR@ ( -- val )    CTR COG@ ;          
: A            0 #29 REG C! ;
: B            1 #29 REG C! ; 


: CTRMODE ( n -- )    #26 SHL CTR@ $1F #26 SHL ANDN OR CTR! ;
: PLLDIV ( n -- )    #23 SHL CTR@ 7 #23 SHL ANDN OR CTR! ;
: APIN    ( pin -- )    DUP MASK OUTPUTS CTR@ $1F ANDN OR CTR! ;
: BPIN ( pin -- )    DUP MASK OUTPUTS 9 SHL CTR@ $1F 9 SHL ANDN OR CTR! ;
: FRQ    ( n -- )    FRQA #29 REG C@ + COG! ;

: NCO            4 CTRMODE ;
: DUTY            6 CTRMODE ;

{ Some sample code here that you can type in interactively. 


A 4 CTRMODE #100,000 FRQ #19 APIN
B 4 CTRMODE #100,100 FRQ #19 APIN
BEGIN #90,000 #20,000 ADO I FRQ LOOP KEY? AND UNTIL


\ to turn them off
OFF A CTR!
OFF B CTR!
}

I connected a piezo transducer (or connect to your audio amp) onto pin 19, typed in the code I have in curlys and I had to run outside to check for aliens. Then my wife came rushing in all alarmed! (she thought I was being abducted)

[Brian Riley]

The larger I2C bus EEPROMs are accessed with a 16-bit address so they are limited to 64K bytes of addressing. The simple trick to get around this is to access the other 64KB on another device address as if it were separate. Using the 8-bit format to represent addresses we end up with:
$A0 = 1st 64KB (write)
$A1 = 1st 64KB (read)
$A2 = 2nd 64KB (write)
$A3 = 2nd 64KB (read)

This is what I2CBUS reports on my 2 AT24C1024B's hardware addressed as 00 and 01 . What you show above must cover, device 00.

 Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120810.1730
----------------------------------------------------------------
I2CBUS
Device at 00A0  FF FF FF FF FF FF FF FF
Device at 00A2  00 00 00 00 00 00 00 00
Device at 00A4  FF FF FF FF FF FF FF FF
Device at 00A6  FF FF FF FF FF FF FF FF  ok
  ok

[Peter Jakacki]

OK, the serial stuff compiles clean now.

I understand about COLD and BACKUP now.

Question - I am using a new board I am working on with 256 KB of EEPROM (2 AT24C1024B's). Is Tachyon taking any notice of and/or making use of the 'extra' storage space beyond 32KB?

Question - when I do an I2CBUS it reports the 2 AT24C1024B's as 4 devices, why?

Question - Has something changed in VGA? I tried the VGA and CON commands yesterday and they worked fine redirecting console output to my VGA monitor. Today I issued a VGA command and it all locks up forcing me to do a manual hardware reset. Also, the DEMO is all screwy and seems too be prematurely ending in a RESET.

The larger I2C bus EEPROMs are accessed with a 16-bit address so they are limited to 64K bytes of addressing. The simple trick to get around this is to access the other 64KB on another device address as if it were separate. Using the 8-bit format to represent addresses we end up with:
$A0 = 1st 64KB (write)
$A1 = 1st 64KB (read)
$A2 = 2nd 64KB (write)
$A3 = 2nd 64KB (read)

Of course they could make an I2C bus device accept a 24-bit address and then they wouldn't need two device addresses but then user code would have to be modified to handle it.
BTW, when I say 16-bit address this is not the same as a device address, it is rather the 2 bytes that get sent after a device address (write) that are required to set the EEPROMs internal address counter. Thereafter the address counter will increment automatically when you read bytes back.

Sequence to read bytes from location $1000 (if you can follow):
'
I2CSTART [$A0] [eeprom acks] [$10] [eeprom acks] [$00] [eeprom acks] ....... I2CSTART [$A1] [eeprom acks] [read byte] [we ACK] [read byte] [we ACK] [read byte] [no ACK] I2CSTOP

I haven't been testing VGA lately so I will take a quick look at that tomorrow (3:00AM here)

[Brian Riley]

I noticed the problem with the serial driver and then promptly forgot. It just had to do with some curly problem, you know, the { } in the wrong places. Nothing much, I'll fix it up in a jiffy.

Now I think I explained what happened when you type COLD in that it clears everything back to factory settings.......in RAM....not EEPROM. Just type COLD, don't reset, but load in your EXTEND.fth and it works fine. I've tested this over and over.

OK, the serial stuff compiles clean now.

I understand about COLD and BACKUP now.

Question - I am using a new board I am working on with 256 KB of EEPROM (2 AT24C1024B's). Is Tachyon taking any notice of and/or making use of the 'extra' storage space beyond 32KB?

Question - when I do an I2CBUS it reports the 2 AT24C1024B's as 4 devices, why?

Question - Has something changed in VGA? I tried the VGA and CON commands yesterday and they worked fine redirecting console output to my VGA monitor. Today I issued a VGA command and it all locks up forcing me to do a manual hardware reset. Also, the DEMO is all screwy and seems too be prematurely ending in a RESET.

[mindrobots]

Excellent! Fixed the problem!

I don't mind untidy and hard coded for now.

Thanks!

[Peter Jakacki]

Look at line 1071 in the source or there abouts and just patch this line for now from 80MHz to your 96Mhz :
bit_ticks long (80_000_000 / baud ) ' set baud rate

I will tidy up some of these things properly as they were just hard-coded initially to minimize any unnecessary debugging.

[mindrobots]

Peter,

I finally am getting a chance to start playing with your wonderful creation.

Currently 2 test target boards: One of pedward's PropKEY USB boards (6.00MHz xtal) and a standard Quickstart (5.00MHz xtal).
I'm currently using CoolTerm on a Mac Mini w/ OS X 10.7.4 - terminal speed is 230400 (fastest it can go).

When I change the _xinfreq to 5_000_000 and the pll to pll16x (80MHz clock) for the Quickstart, everything works fine (zippy software!)
When I change the _xinfreq to 6_000_000 and the pll to pll16x (96MHz clock) for the PropKEY, I get garbage characters output over the terminal and can't match speeds.
baud = 230400 in both cases.

I haven't dug into it but is there something in the character output routines that would tie it to a 80MHz clock?

Other than that, I'm having fun with Tachyon on the Quickstart!

Thanks for the great work on Tachyon!!

[Peter Jakacki]

I noticed the problem with the serial driver and then promptly forgot. It just had to do with some curly problem, you know, the { } in the wrong places. Nothing much, I'll fix it up in a jiffy.

Now I think I explained what happened when you type COLD in that it clears everything back to factory settings.......in RAM....not EEPROM. Just type COLD, don't reset, but load in your EXTEND.fth and it works fine. I've tested this over and over.

[Brian Riley]

I just put up 120810.1730 and Prop Tool 1.3.2 reports "no PUBs found" for the highSpeed Serial RX module I had same problem with 120810.0015. In each case I had to go back to an Aug 5th version to get it to compile.

I am still unable to clear out EXTEND.fth using COLD and REBOOT. COLD works and it issues the COLDstart message and indeed all of EXTEND.fth is gone, BUT I then do a REBOOT and it is all back.

It seems to me that to make this action permanent that you would need to do a BACKUP after you issue the COLD, but you cannot because COLD just got rid of BACKUP! Catch-22 anyone??!!??!!

[Peter Jakacki]

Peter,

I have worked now for a couple of days whith this forth.
I have some experiance withe the standard Forth words!
A lot of words ar unknow for me, there is a sort of list of words?

Thanks in advance.

Jan

The source code page is helpful if you look through it as most of the main words are highlighted in some fashion with brief descriptions. I'm not really trying to write a "standard" Forth both because the Propeller is not a standard MCU (hey, we are all "unorthodox" in this department in not going with what's popular) and also because many Forths are based on PC standards and that is definitely not where I want to go. Forth's greatest strength is in embedded systems IMO so I tune my Forth depending upon the MCU and usage.

Some of these words I am using now are also evolving as I am already writing applications with Tachyon and looking at how it could be better, then going back into the kernel and making the changes.

However, I will look to see if there is something I can do. I appreciate the feedback, keep it coming.

[Powersoft]

Peter,

I have worked now for a couple of days whith this forth.
I have some experiance withe the standard Forth words!
A lot of words ar unknow for me, there is a sort of list of words?

Thanks in advance.

Jan

[Peter Jakacki]

Hi.

For anyone interested to have FORTH programmings PDF.s

Thanks Sapieha. Brian Riley suggested that one too and I have the link for it at the bottom of my Intro page.

@Jan: I've found where the problem is and I am just fixing it now. Looks like I wasn't clearing out my XCALL table so while I'm at that I will start testing the YCALL facility which uses the high word of the long as well. The Spin tool is recalcitrant when it comes to things like this where I couldn't use a word, it wanted a long, so in ways Tachyon is structured the way it is because of the limitations of the primary development environment.

[Sapieha]

Hi.

For anyone interested to have FORTH programmings PDF.s

[Sapieha]

Hi.

Good Forth pdf.

http://ficl.sourceforge.net/pdf/Forth_Primer.pdf

[Brian Riley]

Peter commented that a hard copy of Leo brodie's "Starting Forth" was hard to come by. Search on Amazon, used, but in decent shape, copies are still available.

[Brian Riley]

I loaded the 120810 version from Spin source then applied EXTEND.fth with no errors and it did BACKUP.

I wanted to cleanup and start over so I did a COLD . I did WORDS and QWORDS and the EXTEND.fth words were gone.

I did a REBOOT and it came up without t he cold start message and QWORDS et al. were still there. How do I clean out and start over without using Prop Tool to wipe the lower 32K of EEPROM space???

[Powersoft]

Peter,

Found only problems when using extend.fth from link.
When I used it from the link on the start of the forum and copy the text into my texteditor (ultra edit) and save
it, it runs without any problem!!!

Jan

[Powersoft]

Peter,

I downloaded via the link the latest 57600 Baud version and the extended.fth
After loading the binary the Forth is running.
But loading the latest version of extend.fth is not posible. Get a lot of What? errors

The versions before where able to load.
Do you have an idee why now not?

Jan

[Powersoft]

There is now one single link on the Intro page to the binaries folder, so it's a matter of picking the one you want.

Peter,

This works perfect!

[Peter Jakacki]

There is now one single link on the Intro page to the binaries folder, so it's a matter of picking the one you want.

[Peter Jakacki]

Yes, I was getting around to updating the binaries but I have been making a few modifications since. Check back very soon, I may update the Intro page to indicate the current version of the binary although the file name will remain the same.

Why so slow?

[Powersoft]

I've been sidetracked from getting the SD system going but that won't take long when I get around to it. In the meantime I have updated a few little things including EXTEND.fth with a few goodies. CONSTANT is now supported so instead of typing in the constant into a definition as before the more efficient form is: "1234_5678 CONSTANT bignum"

An interesting thing I found as I was thinking about doing some error checking when a definition is completed with ; is that as Tachyon Forth does not have any special headers or code field addresses at the start of the definition's code it is possible to fall-through from one definition into the next if there is not an EXIT in between. The compiled kernel bytecode is written this way also but how do we make that happen from the terminal? I tried this and it works. Just for curiosity this is what happens when we start a new definition without completing the one prior.

: HELLO ." HELLO " 
: THERE ." THERE " ;  ok
HELLO HELLO THERE ok

EDIT: I just looked at how the code displayed on another computer and it was atrocious so I changed the font.

I'm updating my ANSI.fth file with this technique as well which I need to link to the Intro page.

Peter,

The version in Dropbox contains not the CONSTANT structure!
Is it also posible to make a version with VGA and a speed of 57600 Baud?

Cheers,

Jan

[Peter Jakacki]

I've been sidetracked from getting the SD system going but that won't take long when I get around to it. In the meantime I have updated a few little things including EXTEND.fth with a few goodies. CONSTANT is now supported so instead of typing in the constant into a definition as before the more efficient form is: "1234_5678 CONSTANT bignum"

An interesting thing I found as I was thinking about doing some error checking when a definition is completed with ; is that as Tachyon Forth does not have any special headers or code field addresses at the start of the definition's code it is possible to fall-through from one definition into the next if there is not an EXIT in between. The compiled kernel bytecode is written this way also but how do we make that happen from the terminal? I tried this and it works. Just for curiosity this is what happens when we start a new definition without completing the one prior.

: HELLO ." HELLO " 
: THERE ." THERE " ;  ok
HELLO HELLO THERE ok

EDIT: I just looked at how the code displayed on another computer and it was atrocious so I changed the font.

I'm updating my ANSI.fth file with this technique as well which I need to link to the Intro page.

[Peter Jakacki]

Just a tip but although it is common Forth practice to set the number base and then hope that all numbers are in that base we like to avoid that irritating problem that you have also discovered. You can force numbers to binary, decimal, or hex using a prefix or a suffix. Why both? Because we can. In Spin we are used to saying $70 which means interpret 70 as a hex number whereas 70 in Spin always means decimal. As you know, in Forth and some other languages (including assemblers) you can set a default radix or base but you can always override this. I try to use common forms although I do detest the 0x format personally. Have a look at the Introduction page and there is a section on number formats. Here's a quick summary:
Hex numbers: $70 70h
Decimal: #112 112d
Binary: %01110000 01110000b
ASCII: "p"
Plus control characters can be represented with a caret such as: ^C

[Powersoft]

Peter,

Is there going sommething wrong in the new version.
Yesterday I tested my I2C device with I2CBUS, and it gives the right addresses ($70,$92 and $A0)
With the new version (binary and extended.fth) it is not working.

I cant test it with the old version because I have over written it and have no backup.

Please can you take a look?

Jan

Found the problem, the Forth whas in hex mode and I used the decimal pin numbers!

[Powersoft]

Hi Jan, that's vey straightforward and this code here should work fine. I have just modified EXTEND.fth a tiny bit so you will need to use the new version. In the old version IC2! returned with an ack flag but most of the time we don't need it so I just made I2C! the ack flag but if I do need to find out I have I2C!? which is actually the old version.

Now as I mentioned earlier in another post that I2C addresses are sometimes referred to in 7-bit right justified format so if your $70 is in that format then make sure you type it in the 8-bit format as $E0. Which device is it by the way?

\ Init the I2C
\ BeginTransmission($70) \ assuming the 7-bit address is in normal byte format not right justified
    BEGIN I2CST $70 I2C!? 0= UNTIL    \ Wait for an ack from device (otherwise just use I2CST $70 I2C!)
\ Send_I2C($00)
\ Send_I2C($47)
    $00 I2C! $47 I2C!
\ EndTransmission
    I2CSP


\ BeginTransmission($70)
    I2CST $70 I2C!        \ this time we are going in blind

\ Send_I2C($01)
\ Send_I2C($3B)
    $01 I2C! $3B I2C!
\ EndTransmission
    I2CSP

Be aware that as I develop Tachyon that I may change some names and the way they operate as I see ways to improve the operation and readability of the code. So I2CST may just be called I2CSTART and I2CSP will be called I2CSTOP although I will still keep the old names too.

Peter,

Is there going sommething wrong in the new version.
Yesterday I tested my I2C device with I2CBUS, and it gives the right addresses ($70,$92 and $A0)
With the new version (binary and extended.fth) it is not working.

I cant test it with the old version because I have over written it and have no backup.

Please can you take a look?

Jan

[Powersoft]

Hi Peter,

Thanks again for the help.
As answer on your question, this I2C device is a 7-Segment display on the Gravitech shield for the Arduino.
When I use the command I2CBUS then I see the address of $70,$92 and $A0
So I will use these addresses!

There is also a Thermometer, and a EEP on the the board.
Nice board to do some experiments with the I2C bus!!

Last question about the I2C.
Is it also posible to read more bytes in on go?
Supose I wont to read the registers of the DS1307 in one go?

Thanks

Jan

[Peter Jakacki]

Peter,

Do you have time to look at this question?
Thanks allot

Jan

Hi Jan, that's vey straightforward and this code here should work fine. I have just modified EXTEND.fth a tiny bit so you will need to use the new version. In the old version IC2! returned with an ack flag but most of the time we don't need it so I just made I2C! the ack flag but if I do need to find out I have I2C!? which is actually the old version.

Now as I mentioned earlier in another post that I2C addresses are sometimes referred to in 7-bit right justified format so if your $70 is in that format then make sure you type it in the 8-bit format as $E0. Which device is it by the way?

\ Init the I2C
\ BeginTransmission($70) \ assuming the 7-bit address is in normal byte format not right justified
    BEGIN I2CST $70 I2C!? 0= UNTIL    \ Wait for an ack from device (otherwise just use I2CST $70 I2C!)
\ Send_I2C($00)
\ Send_I2C($47)
    $00 I2C! $47 I2C!
\ EndTransmission
    I2CSP


\ BeginTransmission($70)
    I2CST $70 I2C!        \ this time we are going in blind

\ Send_I2C($01)
\ Send_I2C($3B)
    $01 I2C! $3B I2C!
\ EndTransmission
    I2CSP

Be aware that as I develop Tachyon that I may change some names and the way they operate as I see ways to improve the operation and readability of the code. So I2CST may just be called I2CSTART and I2CSP will be called I2CSTOP although I will still keep the old names too.

[Powersoft]

Thanks again.

I have some trouble with the I2C commands name.
Please can you help me with this small example.

My device address is $70

In plain text my problem is:

Init the I2C

BeginTransmission($70)
Send_I2C($00)
Send_I2C($47)
EndTransmission

BeginTransmission($70)
Send_I2C($01)
Send_I2C($3B)
EndTransmission

Thanks for the help.
Cheers,
Jan

Peter,

Do you have time to look at this question?
Thanks allot

Jan

[Peter Jakacki]

Peter,

I found sommething strange.

Why can't I create a variable like "CREATE DUMMY 99 ,"?
But when I use "CREATE DUMMY 99 C," seems to work, but when I recall DUMMY I het a data stack dump

What I wont is to create an lookup table like

CREATE DISPLAY $3F C, $06 C, $6D C, ............

Not all Forths operate the same way when you start delving under the hood such as creating new structures. I don't really want to make it work exactly the same as there are far better ways of doing it. However I have modified CREATE to compile the bytecode for a variable by default without assigning any memory and without aligning to longs although I could make that optional. I also needed to modify C, because due to the nature of Tachyon when it compiles on the fly this means that the literals you enter before a C, are already compiled as literals. What was needed was to execute any interactive code up to that point so that C, could use the result.
I have also added CVARIABLE, WVARIABLE, and VARIABLE which not only allocate memory but also align the storage area to their respective boundaries. Now I might add CONSTANTs as well even though I have been getting around it simply with a normal colon definition but certainly a long constant would execute a little faster.

There's probably other stuff I've done but I forget now.... so I'll mention it later if I remember and it's pertinent.

[Peter Jakacki]

Okay, I needed to get around to checking this.....be back soon

[Powersoft]

Peter,

I found sommething strange.

Why can't I create a variable like "CREATE DUMMY 99 ,"?
But when I use "CREATE DUMMY 99 C," seems to work, but when I recall DUMMY I het a data stack dump

What I wont is to create an lookup table like

CREATE DISPLAY $3F C, $06 C, $6D C, ............

Please can you help me with this?

Cheers,

Jan

[Powersoft]

Thanks again.

I have some trouble with the I2C commands name.
Please can you help me with this small example.

My device address is $70

In plain text my problem is:

Init the I2C

BeginTransmission($70)
Send_I2C($00)
Send_I2C($47)
EndTransmission

BeginTransmission($70)
Send_I2C($01)
Send_I2C($3B)
EndTransmission

Thanks for the help.
Cheers,
Jan

[Peter Jakacki]

If we had tons of memory to spare we would make base a long but it's not. Try base C! instead.
Remember that HEX will not take effect until after the line has been executed but it is temporarily compiled first so this may not have the desired effect. You can also type $A0 2 B. which accepts A0 as hex regardless of base and also formats the number print for binary (2 B.)

[Powersoft]

Hello,

I found sommething to think about.
When I try to print a binairy like

HEX 00A0 2 base ! .

the system seems to hang.
Or do I sommething wrong?

Cheers,

Jan Kromhout
Hellevoetsluis-NL

[Powersoft]

Thanks for the changes!
It is working great now.
I have added at top of the ASC board a Gravitech 7-SEG shield, wich included three I2C divices.
With the command 14 15 I2CPINS and I2CBUS is can see now all tree addresses.

Now I will try to get acces to all the devices.

Cheers,

Jan

[Peter Jakacki]

Yes, but you might be better off leaving the existing code in place for the EEPROM and just adding the first part of the I2C code. Also you could rename the functions to SCL2 SDA2 SDA2? and I2CST2 I2CSP2 I2C2@ I2C2! or something like that, it's up to you. That way you can still access the EEPROM and any other device you might put on the EEPROM lines. However if the EEPROM is the only thing on P28,29 then it doesn't matter if you just load the definitions with the same name (except the change to the port numbers).
I might look at updating the code to allow redirection to other pins.


EDIT: I have just updated EXTEND.fth to allow for redirection. The word I2CPINS takes two parameters for the pin numbers and EEPROM is the word that sets up the Prop's I2C lines. BACKUP will always invoke EEPROM to set up the correct lines but otherwise you can change the pins and all the other words will follow.

[Powersoft]

Peter,

I whas I think to quick with my latest replay.
Are these the addresses of the I2C?

: SCL 28d MASK ;
: SDA 29d MASK ;
: SDA? 29d INPUT ;

And are these for my case:

: SCL 14d MASK;
: SDA 15d MASK ;
: SDA? 15d MASK ;


Cheer.

Jan Kromhout
Hellevoetsluis-NL

[Powersoft]

Hello Peter,

I wont to use the TACHYON with the ASC board to use my Arduino shields.
On the ASC shield the I2C connection is don by P14 and P15.
Is it posible to redirect the I2C routines of TACHYON to these pins?

Cheers,

Jan Kromhout
Hellevoetsluis-NL

[Peter Jakacki]

Minicom may allow you to select a baud rate regardless of the capabilities of the serial port. For instance I can select 3.5M baud and 4M baud in Minicom yet the FT232R chip "only" goes up to 3M baud. So check your serial port or use an FT232R or similar. I've always been a TeraTerm fan but even though it's open source now it's strictly a Windows program. After TeraTerm I'm not impressed with any other terminal program. But I rediscovered Minicom which I had dismissed so many times before, however it handled the rfcomm channels for Bluetooth and since then I have gotten to really like it, it certainly performs.

[D.P]

Good point Brian. Back to Zterm. I tried every "valid" baud rate between 230_400 and 3_000_000 on Minicom 2.6.1. -> PropBOE. No joy except at 230_400. OSX 10.6.8 first generation Macbook Pro.

[Brian Riley]

Hey Peter, nice additons to the doc. I'm currently running minicom 2.6.1 on Mac OSX (I'm a sucker for nice laptops, meh on OSX) and can only attach at 230_400 fyi BUT my question is the ^ keys don't seem to work as documented. I'm wondering if you have done any special configs to your minicom setup? Also looking forward to SD@ SD! and the filesystem, very cool.

IF Minicom only gives you 230,400 you might as well use Zterm. The Control keys work there just fine.

[Brian Riley]

I wired up a second AT24C1024B to my PPDB and Tachyon 120806.00 read it as i suspected it would, as 4 64K devices ..see thread http://forums.parallax.com/showthrea...16#post1116016

[D.P]

The Introduction page has been updated with a section on BACKUP and AUTORUN as well as a link to a YouTube video showing the whole compile from on-line source, to loading in Forth source and demonstrating an AUTORUN with an SPI 128x64 Graphic LCD and I2C bus LEDs.

Hey Peter, nice additons to the doc. I'm currently running minicom 2.6.1 on Mac OSX (I'm a sucker for nice laptops, meh on OSX) and can only attach at 230_400 fyi BUT my question is the ^ keys don't seem to work as documented. I'm wondering if you have done any special configs to your minicom setup? Also looking forward to SD@ SD! and the filesystem, very cool.

[Powersoft]

Hi Peter,

Thanks for the reply. After setting the line delay to 30 ms I could load the file.
Can now start to play with it!!

Cheers,

Jan

[Peter Jakacki]

Hi Jan,
Make sure you have set a line delay of around 30ms. Can you copy&paste from your terminal to here so I can see what's happened?

[Powersoft]

Hello,

I download a TACHYON version (binary).
As terminal I use Tera Term.
All is working well.
But now I try to load the extended.fth file with the command "send file"
But I get on;y errors.
Is there another way to download these file?

Thanks for any help.
Cheers,

Jan Kromhout
Hellevoetsluis-NL

[Peter Jakacki]

The Introduction page has been updated with a section on BACKUP and AUTORUN as well as a link to a YouTube video showing the whole compile from on-line source, to loading in Forth source and demonstrating an AUTORUN with an SPI 128x64 Graphic LCD and I2C bus LEDs.

[msrobots]

Jupp,

that tick-thing is stupid too, but easy to handle ... just mark and copy existing one in the doc and paste, that works.

Yes i do use IE and all of that windows-stuff. From SQL 2008R2 to Visual-Studio, AD with all the goodies like system-policys and roaming-desktop, one-click install, you name it. Doing this for years in differnt environments from small to big.

The only thing I really skip there is MS-Exchange. This beast is not for me. I use LumiSoft-mailserver wherever needed.

Outside of the geeky groups - in opposite to alot of belives - windows IS quite common in ALL companys I ever worked for. In Germany alike as in California. Sorry but I tryed and failed... I never again will run a serious Database on MySQL,never,never again. Not after having the quality of tools in MS-SQL or Oracle. If I do need Unix-things, well there is SUN. Partitioning like in MainFrames and very scalable. But to expensive for me. Still running two old ones in Germany but they are allmost out of work now and will be replaced by w2008 too.

Since I entirely work over RemoteDesktops form Home I do have just the absolute minimum of things installed on my local machines, so it boils down to the PropTool, PropGCC and CodeSourcery for ARMs. Somewhere Office 2010. No local files if possible.

When I spill my beer over the Walmart-Laptop - well **** happens - I get another one for $200-300 upgrade windows, log into my network and DONE. Back to work, nothing missing.

I do have a debian-linux for testing compability with MONO - yet in the last 14 years none of my customers asked for. See above. All are using Windows on there Desktops. Most of them on the server side also. But this are companys and they just buy what they need, including licences.

At Home things might be different and more people are using linux, MySQL, etc, not willing to spend money for SQL2008 Enterprise or such. Sure. But they don't need a DB like that then anyways, or?

(hiding behind ice-block to avoid upcoming heat)


Enjoy!

Mike

[Peter Jakacki]

WHAT! Why are you using IE? That is totally weird, I have been trying with all kinds of browser but I never use IE so I jumped on a Windows 7 machine, went to the forum, click on my thread, then on the link to the Tachyon Intro and it wants me to sign in which I never have to do on any other browser. What's going on? So I switch to a guest account on the same machine....and it works fine...good, I was worried there. But try Chrome or Firefox at least, they are only a click away. I get the same problem with Chrome if I try to zoom out but it also gives me a warning that the zoom mode is not supported in Google Docs for editing.

BTW, the tick symbol above the TAB key is not always the right one for the Spin compiler. I have edited the source in Firefox and it puts in a tick that is wrong. If I ask Tachyon what it is seeing it reports instead of the ASCII character for $27 the tick from Firefox using Google Docs is the sequence E2 80 98.

+BTW, I'm working on my SD access routines at present which just allows access to the SD as if it were a huge virtual memory using SD@ and SD! words etc after which I will build a FAT16/32 layer on top of that. I will probably allow for several 512 byte sectors to be cached to RAM a bit like the original disk blocks that Forth used to use. Since I have control over how files are created and written I always enforce a non-fragmented file write as this allows direct access to the file as virtual random access memory. Just open the file which returns with it's handle and "memory" address.

[msrobots]

@Peter,

yes - sadly. But I am specially interested in that VGA-Display since I found out that using VGA and graphics.spin does not leave you enough room to do much in spin. Especially if I try to use KYEs Fat-Engine too.

So I haven't had anything to USE that little (expensive) Demo-Board. But I think Tachyon may be a nice fit there. I just need to find it....

I started putting autodoc comments into your code. I used the 'paint' thing to color them like you colored the curly brackets so they are quite invisible. Doing that I stumbled about those two lines (hr?) above the yellow block (internal cog routines). Copying the source into Proptool results in two lines of minus-signs in the prop-source. I was not able to put comment char (') in front of them. Somehow I can not really position the cursor in Google-Docs. If i write something it appears about 10 characters left of the cursor. Maybe Google-docs do not like IE and wants CHROME or so. Copy and Paste works but typing is a PITA and writes usually somewhere else in the line not where the cursor is.

Enjoy!

Mike

[Peter Jakacki]

@Peter,
So Tachyon is not running yet here but will soon do so. Until then I read your source...
Mike

WHAT! Why aren't you running it on any board yet? I have a variety of boards, many without VGA and I just load it on and it goes. The only side effect of having VGA enabled is that P16..23 will be set to output VGA data. If that's a problem then just disable VGA either in the Spin "start" statement or stop the cog. In fact I will upload a few different binaries just so they don't have to be compiled. Just check the bottom of the intro page for the links.

[D.P]

Should have read your post completely!

Looks like some misplaced comments. Attached are the three files I am currently using to compile and EXTEND the kernel. Make sure you set the baud rate and PLL to your needs in the Tachyon spin file.

[D.P]

@Powersoft

You need to have the HS-SerialRx.spin file in the same directory as the Tachyon1v0-VGA.spin file, or in the library path for the compiler you are using: BST (linux, mac) or PropTool on windows.
Introduction and link to all the files at the bottom of this page courtesy of Peter.
https://docs.google.com/document/pub...5m6XWmkJX0XSl8

[Powersoft]

Hello,

Today I try to load the TACHYON byte forth.
When I try to compile the "HS-SerialRx" I get the error no PUB routines found.
Please can you take a look?
I download the latest files.


Thanks in advance,

Jan Kromhout
Hellevoetsluis-NL

[D.P]

Just trying to keep up with you all: Forth V1.0 rev120806.0000, you moved "free" to "FREE", "IICBUS" to "I2CBUS"..... Everything works for me as expected, COLD, AUTORUN, BACKUP. Nice to have Extend.fth and IIC.fth in one file now.

[msrobots]

@Peter,

thank you. I do know that looking at the ByteCodes is less easy than looking at FORTH but for me it is more easy to look at the PASM behind then. So working my way up from PASM to ByteCode I try to grook the whole thing. By now I really like the code. Seems to me that this kernel should be quite fast.

I usually build my stuff on a PPDB (and this is full now) then move over to ProtoBoards and wire it together. So I am still looking for that DemoBoard thing I got myself a while ago... this has also VGA... and it is here, somewhere ... if the dogs don't found it inbetween. Two days ago they found my wallet... they had FUN. An my money and cards where everywhere around in the house...

So Tachyon is not running yet here but will soon do so. Until then I read your source...

and ENJOY! it

Mike

[Peter Jakacki]

Sorry about the last terse message.
Okay just a little confused. I understand and have been using IIC.fth and others. Performing a RESET maintains my "user code" if I have done a BACKUP. Power off and on removes my "user code" and I get: Cold start - no user code - setting defaults. Got it. _My problem was trying to AUTORUN a word that used EMIT and I didn't get any output so I thought (mistake) it was the kernel. PEBKAC! Can / will we be able to disable "cold start" after power failure to enable AUTORUN the "system". NOCOLD

I setup a complicated AUTORUN routine and ran BACKUP and then powered off completely. Plugging it back in it ran through all it's hoops just like a charm. Now coming back to that PEBKAC..........
Hint! When you load your code in from a cold start and before you have done anything else just make sure that the definition you want as an AUTORUN will work on it's own. So type it in, put on a strong face and press <enter>......What happened? Did it do everything as it should? If you are still having problems then please just post the code so you can have another eye glance over it.

[Peter Jakacki]

{ HS-SerialRx - High speed Serial Receive }

While cog space isn't an issue right now I'd still like to mention things I'd have done differently (have to make up for the 2 insns inserted on my behalf).

DAT variables can be accessed the same way as VARs (if nothing else it's easier to read IMO).
<snip>

Thanks for the help Kuroneko, I know the code looks like a bit of a hack but it was just to get some terminal input at the time so I could get Tachyon communicating! I appreciate too the explanations because I just play with Spin and PASM and I do forget and get confused at times because I work with other architectures. Writing Tachyon is helping me to get back up-to-speed with PASM though.

[Peter Jakacki]

@Peter,

yes I am one of those programmers trained to think the other way. The whole concept of a DataStack still confuses me. So definition of PRTHEX for example. I think I do understand how it works and why. So far so good.PRTBYTE..WORD..LONG ok also. Then I hit DUMP.
<snip>

PRTHEX or .HEX as it is referred to in the dictionary is probably one of the first definitions I coded in bytecode to help me debug in the early stages. It's job is very simple as part of the "hex print" family it didn't have to worry about number bases. Passing parameters on a stack is normally hidden from a programmer and many languages will use a frame stack internally or something similar. Forth doesn't try to hide how things work unless you want it to but even then you can always dig right into the very inner workings of it easily. But take care when viewing the document as it's also an experiment in progress! I noticed on the first line of PRTHEX that I said "_BYTE,$0F" which is equivalent to saying "MOV tos,#$0F" but pushing the stack before hand which is why the original name is also used on the next line. Here I say "PUSH1,$30" which is equivalent to "MOV tos,#$30" etc. I haven;t decided yet as to which way is the most sensible.

Remember too that part of the problem here was also representing bytecode clearly in the Spin tool and working with it's syntax. If this had been a macro-assembler I could have made the code far more readable because you see that the branches get messy with their "_IF,@PRTCH-@PH1" calculations. I tried to balance the readability (and "writability") with runtime operation which is one of the reasons I dropped the /2 after each bytecode by limiting the calls to the first 256 longs without any compromises in reality. The other thing that made it a lot more readable/writable is making the jumps and calls relative so that the +$10 can be omitted and having an XCALL method made it both more readable and efficient at the same time as XCALL,xEMIT would otherwise be written as "RCALL,@PRTBYTE-@EMIT" assuming that EMIT was in range of a single 8-bit relative address.

' .HEX ( n -- ) print nibble n as a hex character
PRTHEX  ' ( n -- ) print n (0..$0F) as a hex character
     byte    _BYTE,$0F,_AND
     byte    PUSH1,$30,PLUS
     byte    DUP,PUSH1,$39,GT,_IF,@PRTCH-@PH1
PH1    byte    _7,PLUS                      'Adjust for A..F
PRTCH    byte    XCALL,xEMIT,EXIT

 ' .BYTE ( n -- ) print n as 2 hex characters
PRTBYTE     byte    DUP,_4,_SHR
     byte    XCALL,xPRTHEX,XCALL,xPRTHEX,EXIT

BTW, from the Tachyon terminal this definition could be defined this way:

: .HEX  ( n -- )  $0F AND $30 + DUP "9" > IF 7 + THEN EMIT ;
: .BYTE ( n -- ) DUP 4 SHR .HEX .HEX ;

In PASM (no stack, assumes "tos" is the register):

PRTHEX                
          and  tos,#$0F
          add  tos,#$30
          cmp tos,#39 wc
If_c      add  tos,#7
          call  #emit
prthex_ret

[kuroneko]

{ HS-SerialRx - High speed Serial Receive }

While cog space isn't an issue right now I'd still like to mention things I'd have done differently (have to make up for the 2 insns inserted on my behalf).

DAT variables can be accessed the same way as VARs (if nothing else it's easier to read IMO).

 long[@rxpin] := |<rxdpin
 long[@bitticks] := (clkfreq / baudrate)

PASM:

mov     Y0,rxbuf
sub     Y0,#4
mov     X0,#0
wrlong  X0,Y0

With rxbuf being @HSSerialRx+4 this effectively clears long[@HSSerialRx]. That said, rxwr is initialised to @HSSerialRx+3 which means we can get away with:

wrlong  par, rxwr         ' wrlong ignores rxwr[1..0] which means we write to @HSSerialRx

Image padding to fixed size (65 longs or 256+4 bytes). This disables itself in case the image is big enough on its own.

breakcnt                long    40

padding                 long    -1[(65 - $)&($ < 65)]

rxcnt                   res     1

[msrobots]

@Peter,

yes I am one of those programmers trained to think the other way. The whole concept of a DataStack still confuses me. So definition of PRTHEX for example. I think I do understand how it works and why. So far so good.PRTBYTE..WORD..LONG ok also. Then I hit DUMP.

OK. Now I need a piece of paper and a pen. Writing my own stack while jumping between definitions in code. This is a interesting concept of language, and certainly a very good match for the prop. But mindbending. Somehow it is like a functional language like "F" or so. But it isn't.

Having your PASM helps me out alot. There I feel home.

Anyways I did as you said in the PM and have write-acces to your document. Will start tomorrow... still browsing around in your doc. Having pictures is very nice.


Enjoy!


Mike

[D.P]

Sorry about the last terse message.
Okay just a little confused. I understand and have been using IIC.fth and others. Performing a RESET maintains my "user code" if I have done a BACKUP. Power off and on removes my "user code" and I get: Cold start - no user code - setting defaults. Got it. _My problem was trying to AUTORUN a word that used EMIT and I didn't get any output so I thought (mistake) it was the kernel. PEBKAC! Can / will we be able to disable "cold start" after power failure to enable AUTORUN the "system". NOCOLD

[Peter Jakacki]

@Peter

Now I've got the uemit word in: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120804.0140 but now it seems BACKUP is not working nor is COLD sensing a hard restart as before?

I've been using a PROPBOE for testing.

I'm not sure what you mean by BACKUP is not working. Are you use the I2C.fth document from the link and are you able to EDUMP? If you ever want to reset to factory values and wipe out all your downloaded extensions then you have to do a COLD but this doesn't actually change the EEPROM so you then have to download I2C.fth and perform a new BACKUP. Perhaps I could build IC2.fth into the kernel but I am trying to do more with these Forth source extensions rather then "hard-coding" it into the kernel.

[D.P]

@Peter

Now I've got the uemit word in: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120804.0140 but now it seems BACKUP is not working nor is COLD sensing a hard restart as before?

I've been using a PROPBOE for testing.

[Peter Jakacki]

@Peter,

yes, I would love to do that. As you can see the differences are small and it will not disturb your progress.

Still need to wrap my head around FORTH. But reading your source helps a lot Since in FORTH everything seems backwards for me understanding the Language by understanding its implementation in PASM seems to be logical to me, somehow...

PM me how to do that, and I gladly accept your offer.

I am currently building up my own (Silver?) Standard Library of those objects I really need often.(Serial,I2C,SD,TV,VGA). Documenting them and, well add some generic I/O methods. This is preatty rewarding in it self. As you said "What Phil has done looks very professional".

Enjoy!

Mike

English is an example of an SVO language in that we have a subject, then the verb and then the object. However in other languages it is common to have the verb last such as in SOV languages. Isn't Forth more like an SOV language then in that you supply the information first (subject, object) then feed it into the verb. Take for example if I had a command in something like a standard CLI:
DUMP $1000,$400
Well you could see that DUMP is straining at the bit to find out what it's got to dump and that information can only be in the form that it is prepared for, it's syntax. However in the back-to-front (or is it front-to-back from a reverse perspective) you can do what you like before you tell it what to do:
0 REG $100 DUMP
Eminently far more sensible in my opinion and far more flexible even in this very simple example. Hang on, in many programming languages to get a delay you have to say something like delayms(100) which is not how we talk either yet many programmers have had it instilled into them to think that way. In Forth I just say 100 ms and that's it.

[msrobots]

@Peter,

yes, I would love to do that. As you can see the differences are small and it will not disturb your progress.

Still need to wrap my head around FORTH. But reading your source helps a lot Since in FORTH everything seems backwards for me understanding the Language by understanding its implementation in PASM seems to be logical to me, somehow...

PM me how to do that, and I gladly accept your offer.

I am currently building up my own (Silver?) Standard Library of those objects I really need often.(Serial,I2C,SD,TV,VGA). Documenting them and, well add some generic I/O methods. This is preatty rewarding in it self. As you said "What Phil has done looks very professional".

Enjoy!

Mike

[Peter Jakacki]

Well there seems to be a great flurry of activity lately in the area of improving the documentation in various ways. In regards to base64 "junk" even if I had a heap of stuff down the bottom of the Google document I can hide it by graying it out and/or reducing the font size. Let's get into it and try it out. What do I need to do?

[Phil Pilgrim (PhiPi)]

Peter,

I've thought about adding an image capability to the autodocumenter. Do you think it would clutter things too much to have a bunch of base64-encoded stuff in comments at the end of the source file to accommodate such a facility? I do want it to be completely self-contained, without referencing external files or urls.

BTW, if you don't want to be dragged into this discussion, just say so, and I'll understand.

-Phil

[Peter Jakacki]

@Peter,

yes I stumbled over transmit already, nice. And - yes - this is a huge amount of work you are doing there. But at least you have ONE guy interessted in this - ME.

The style of commenting differs not much from what you are doing and you can keep your source where it is. But like Phil said anybody can (re)create the html-doc out of your source easy.

@Phil - I takes Parallax 2 Years to NOD?

Enjoy!

Mike

Hi MIke, I've had some sleep so I'm feeling a little better now What Phil has done looks very professional and I'm surprised that Parallax haven't nodded yet because it doesn't really change anything for them, it can only make it better. The Google Docs however allow me to paste in images and tables and drawings etc which you can't normally do in source code. If it hampered my productivity I think I would know plus it would show. But it is very streamlined to copy&paste back into the Spin tool and hit F11. If I time it I guess it might take as long as 2,000,000us which if I were the Prop that would be a long time to wait around.

How about this: If I give you the keys to the car and grant you permission to edit the main document could you insert the extra formatting required without crunching the gears? Then you should be able to do a copy&paste or whatever into Guru Phil's confabulator.

[Peter Jakacki]

Can't seem to find word "uemit" in the line.

: CON 0 uemit W! ;

near the end of EXTEND.FTH

running kernel: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120803.1845

Did not find the "uemit" word in any of the posted files.

_Really like the BACKUP and AUTORUN words.

And just for fun the how about this link: http://www.inventio.co.uk/forthvsc.htm I've got my flame suit on so go ahead. I really like the part about if you don't understand the problem you shouldn't be writing software.

I think the problem might be the version so just make sure you get the latest because I do update it constantly. Just look at the links at the bottom of the Introduction web page. Bear in mind that I try not to change things too much but if it needs to it needs to. Things are starting to settle down a bit more now though.

The problem with the article from the link you gave to "Forth vs C" is it is too busy defending and comparing. The target audience have already been assimilated and any further resistance is futile for they C the world via their library implants. There is only one way of doing it and that's the library way and you had better fit in with it.

Forth is Forth, not C, and a good Forth is so much better than a bad Forth and some although well written can be bad simply because they do not address the needs of the application and platform, they seem to have been written more like an assignment in a CS class or are PC centric. So I can definitely tell you that this Forth is tailored both for the Propeller and for the many applications that you and I typically use it for.

[msrobots]

@Peter,

yes I stumbled over transmit already, nice. And - yes - this is a huge amount of work you are doing there. But at least you have ONE guy interessted in this - ME.

The style of commenting differs not much from what you are doing and you can keep your source where it is. But like Phil said anybody can (re)create the html-doc out of your source easy.

@Phil - I takes Parallax 2 Years to NOD?

Enjoy!

Mike

[D.P]

Can't seem to find word "uemit" in the line.

: CON 0 uemit W! ;

near the end of EXTEND.FTH

running kernel: Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120803.1845

Did not find the "uemit" word in any of the posted files.

_Really like the BACKUP and AUTORUN words.

And just for fun the how about this link: http://www.inventio.co.uk/forthvsc.htm I've got my flame suit on so go ahead. I really like the part about if you don't understand the problem you shouldn't be writing software.

[Brian Riley]

I started a new thread concerning EEPROMs there is some mention of the newest Tachyon with EEPROM support.

The thread is at http://forums.parallax.com/showthrea...ur-EEPROM-Slot

[Phil Pilgrim (PhiPi)]

Peter,

The idea behind the autodoc facility is that you don't have to create and store a separate HTML file, but convert the source on demand every time you need to view it in doc form. To make things even easier, I've created a "DOC" button that resides on the Prop Tool's toolbar. When clicked with an autodoc-ready Spin file showing, the file is converted on the spot to an HTML document which opens in the user's default browser. If the Spin file that's showing is not autodoc-ready, the user is prompted to see if he wants the program to add an autodoc template, which he can then simply fill in with the needed information.

I haven't posted this version publicly yet, since I'm waiting for an official nod from Parallax. There's a good chance that the templating facility will be extended to include optional retabbing and case-conformance to the Gold Standard spec, although the latter is one feature that I probably wouldn't use myself.

-Phil

[Peter Jakacki]

The tiny bit of code in the kernel labeled "transmit' is all you need but if you call it from Spin which is many times slower it will slow down the throughput and also take up a whole cog. Having it built into the Tachyon kernel means it's a lot more efficient to just send data out rather than trying to buffer it and this leaves the serial cog totally free to just concentrate on receiving data.

I've updated the links at the bottom of the Introduction page if you are looking for the VGA object.

I also had a look at the formatted source code and while it's very neat and kudos to Phil there is one big drawback for me and that is it's not editable on-line. At present if I make a modification to a document then everybody else has access to the very latest without having to upload or anything. However I don't mind adding the formatting if it makes it easy to convert but besides doing all this fancy (but not complicated or aggressive) formatting on Google Docs I have been far too busy concentrating on developing Tachyon itself in-between real work etc. It's only been about a month since I first announced I was going to do it and now I have it so it's very solid that I can easily use it in real products and the speed it runs at is fantastic. I would have loved this stuff if someone else did it but now that I've done it, it seems to be a bit of a flop as I can almost hear the yawns of disinterest from the forum. Perhaps if I burnt out a Prop or came up with a transistor to use with the Prop I would have had more interest. Of course that doesn't stop me from doing what I'm doing but a little helpful "user" feedback might prove beneficial for all, after all it's not a small amount of work to do this plus publish it in this format.

[msrobots]

@Peter,

I know you like GoogleDoc, but I am a man on a mission - for Phil's Spin Documenter.


Since I ponder for a while now with getting into FORTH, I read this thread with interest. Looked at your GoogleDoc, found it to complicated and agressive for my use. Finally downloaded your code of post #70 and dove into it.

I still do not know much about FORTH but I do like your PASM-Source. WELL DONE!

So to better browse your source and understand it, I decided to 'rework' the way you are commenting your source according to the rules Phil posted in this Thread.

Fairly simple. I needed to repace/change some titles. Add some curly brackets and some dots. And DONE.
Then I took the spin fie and submitted it to Phils Spin Documenter. Saved the resuting file as Tachyon1v0-VGA_Doc.html. Impressive. Did the same with the rest of the spin files and added a README_Doc.html as a header. Here the complete Tachyon1v0-VGA-Autodoc.

Funny thing is - once you adapted the way of commenting you can at any time recreate a new HTML-file out of your Tachyon1v0-VGA.spin source. Just upoad it to Phil's Spin Code Documenter and save the resulting file as Tachyon1v0-VGA_Doc.html. That easy.

I did not wrote any of that documentation shown in the link. YOU DID. I just changed the way you are commenting a bit...

So PLEASE - open a beer - look at both sources - compare the comments - smile.

You can download from that web-page or take the attachment ... both are the same.

The whole shebang is just html - So it works on any webserver and even without webserver on your local harddrive. Just download the zip-file. (in windows7 right-click after saving, select properties and select 'unblock' if there)
Then unzip in folder of the same name as the zip - and voila there you go.
Start _README_Doc.html inside the folder.

BTW. I did not found VGA_512x384_Bitmap.spin in your zip. can you post it or give me a link ?

Ahh. And is there a HS-SerialTx.spin you can point me to also? I do like the simplicity of HS-SerialRx.spin

Enjoy!

Mike

[Peter Jakacki]

For those who liked the simplicity of BS2 commands I am slowly building up equivalents of them. Here's a very useful one which I happened to have an immediate need for with a serial LCD where it pays to keep it simple. The BS2 SEROUT command transmits asynchronous data from any pin at any baud rate (within limits) and so it is with Tachyon Forth. I've tested this code for use up to 220K baud. Here's the code fragment for it and some typical uses.

: SEROUT ( data baud pin -- )
    MASK DUP OUTSET ROT    ( baud mask data )
    $100 OR 2*        ( baud mask data )
    ROT #10 SWAP #80,000,000 SWAP / WAITCNT ( mask data )
    FOR SHROUT 0 WAITCNT NEXT
    2DROP
    ;

\ Demo code

: >LCD   ( char -- )  #9600 3 SEROUT  ;   \ transmit serial data to the LCD on P3
: CLD           $0C >LCD ;   \ clear LCD
: SETBIG     2 >LCD ; \ big digit mode
: ENDBIG        3 >LCD ;
: TYPELCD  ( str -- )  BEGIN C@++ ?DUP WHILE >LCD REPEAT DROP ;

CLD SETBIG " 123" TYPELCD ENDBIG " DEMO" TYPELCD ;

WAITCNT is a little different than what it is in Spin or PASM in that if you supply a non-zero value then it will save that value as the delta and calculate the target. You can get it to synchronize easily by simply saying 0 WAITCNT which uses the saved target and delta.

EDIT: With a slight modification to the kernel where WAITCNT does not need any parameters passed to it anymore and the word DELTA is used instead to set it up I can achieve over 400K baud speeds.

[Peter Jakacki]

Hi Brian, I'm removing most of the links in the actual source code document and the thread as I want to put this in a central place and preferably on a standard web page that everybody can access easily. So use the links at the bottom of the Introduction page as these will always be up-to-date. In fact the binary and source code text files are sitting on my Dropbox account and all I have to do is copy my current files to that folder. No links to change and instantly updated. Now that I have a session save and autorun up and running I can really get into expanding the kernel. Next will be SD memory access then PS/2 style keyboard after which I will look at running multiple VMs concurrently and perhaps at least one that just looks after "background" processes and timed tasks.

[Brian Riley]

Peter,
The code in Tachyon120801.zip is 120731 not 120801.0950

[Peter Jakacki]

Finally I have gotten around to implementing the session backup feature where all user code and settings are backed up to EEPROM (it only needs a standard 32K). Just download the latest binary and include the IIC.fth source file (from the intro page) which when added you can tell it to do a BACKUP. There's also an AUTORUN feature so that your code can run automatically on startup.

On top of this I have created an "Introduction to Tachyon Forth" webpage (which automatically republishes from a Google Document) which will gradually be expanded to include all kinds of stuff including tutorials and projects.
The links for the current binary and other documents etc will also be located at the end of this page.

[Peter Jakacki]

I think a lot of people have had a look at the on-line document but except for one grumpy comment at the start I haven't had too much feedback. I noticed that if I view it on another computer that I'm not signed into then it may appear slightly different to what I'm seeing. At the very least it always seems to show a paginated view with gaps between pages. On my Android phone and tablets it may have a different font but it's still readable.

I'm at the stage where I am documenting more and tidying things up before I move onto to the next big stage leading up to a full-blown stand-alone system capable of editing and developing with a part graphics and part text display. But I like the idea of using Bluetooth and that's the other way that this can be developed too, on a tablet which is both small, portable, and cordless. However, I am not locking it into any one method, I'd rather keep it very flexible.

The latest binary and sources are in a WHAT'S NEW section near the start of the document to make that more central to access and I'd like to keep as much of the documentation together with the source as the copy&paste into the Spin tool doesn't phase it one bit.

Any feedback is welcome (hopefully positive)

[Peter Jakacki]

The latest binary image and source files have been zipped and updated on the top post and here --> TACHYON.zip. The EEPROM routines include bytecode that runs the I2C bus at 125kHz so that a full 32kB of EEPROM can be saved in 5.4 seconds and loaded in 4.3 seconds while not relying on anything but the Tachyon cog. In fact except for the high-speed serial cog and of course the VGA cog I am restricting myself to the one cog at present just to maximize what I can do with it first. For SPI and SD functions I can clock data at 2.8MHz which unfortunately was a tad fast for I2C and I didn't want to bog down the PASM code with programmable delays as I may end up using the counter to clock data at much higher speeds, especially when I fully implement my SD file system.
Anyway, there are a lot of little things that have been tidied up and improved with runtime compilation etc and I have had to move the VGA pixel buffer up a couple of K just so I can develop and test. Later on the dictionary will be fully optimized to run out of the 2K Tachyon image in hub plus the rest in EEPROM.

[Peter Jakacki]

Thanks for the feedback Brian, I will have to setup some help information but possibly on another document that's linked to from the source. I have a 25ms line delay which is pretty close to what you have. I have yet to figure out why Minicom doesn't understand software handshaking even though it has a setting for it. Once I sort that out then Tachyon will simply XON/XOFF at the application level to say "hit me" when it's ready for more and certainly at 3M baud that doesn't take long at all to fill the bill. I'm working on my EEPROM routines at present (working) and making it possible to backup the current session but there are a few tweaks I still need to make.

[Brian Riley]

FWIW, Mac people trying Tachyon using Zterm, 230_400 baud works just fine.

To optimize copy/paste transfers, you want to setup Settings --> Text Pacing , which controls copy/paste as well as File Send

- uncheck "wait for echo"

- set "delay between characters" to zero (0) 60ths of a second

- set "delay between lines" to two (2) 60ths of a second
( I tried 0 & 1 for line delay and it wasn't enough)

- save configuration Dial --> Save Setup

[Brian Riley]

Works like a charm .. TNX! Now does anyone know of Minicom or equivalent that will run under Apples shell at 3Mbit?

Big thanks to Peter for the great work and to Kuroneko-san for the quick and accurate fix.

[Peter Jakacki]

Yes, it is. Try this:
..............<snip\>..........

Thanks friend, I've been concentrating that much on Tachyon itself that the little sidekick HS-SerialRx didn't get much attention as it was more of a quick hack. I tried out your mods and can confirm that they work just fine.

[kuroneko]

Is it a BST thing? Any hope for a Prop Tool compatible?

Yes, it is. Try this:

  result := @HSSerialRx+4       ' Use cog image for serial buffer (skip 4 for control)
  cognew(@HSSerialRx, @HSSerialRx)

DAT                     org     0

HSSerialRx              add     rxwr, par
                        add     rxbuf, par
                        
                        mov     Y0,rxbuf
...
rxpin                   long    0                  ' mask of rx pin
rxwr                    long    3                  ' byte address of rxwr in hub
rxbuf                   long    4                  ' pointer to rxbuf in hub memory

bitticks                long    0

[Brian Riley]

PETER,


I downloade the latest and finally h ad a chance to play with it. I loaded the 57600 binary... Since ZTerm on th Mac goes to 230400, I tried to recompile for that using Prop Tool, which kept barfing in the serial object to a reference to rbuf pprefixed with "@@@". I know I have seen a thread on this but cannot seem to find it. Is it a BST thing? Any hope for a Prop Tool compatible?

TNX

[Peter Jakacki]

With that pathway in mind, you could always develop using TWO Prop 1's ? - if your total 'equivalent' COG use is <=8, it would morph into a Prop 2 quite easily.

Prop II will have hardware to support communicating between cogs and other Props so anything I do with the current Prop will be a poor man's version although capable enough for present. My main focus now is getting Tachyon fully functional and robust for industrial applications.

[jmg]

Although it is possible to add extra chips to do more wonderful things with the video I'd rather concentrate on getting the most out of the Prop itself and also so that when Prop II pops up I'm ready to port and play!

With that pathway in mind, you could always develop using TWO Prop 1's ? - if your total 'equivalent' COG use is <=8, it would morph into a Prop 2 quite easily.

[Peter Jakacki]

I like the graphics. Are you going to include a source editor in your package?

I get tested the HC06 blue tooth module yesterday, I was able to use the terminal from two houses away.

Certainly that is my intention to add a source code editor since I can have VGA. So there will be support for keyboard, mouse, and SD card as well as audio etc. I want to make this as standalone as possible although most of my projects won't need all of these things. Since the 512x384 bitmap takes up a bit of memory, well most of it, I might have to allow for an enhanced text and graphics mode. For the moment even with the 512x384 bitmap I can simply let code overflow into where the lower video memory is and move the "start of video" pointer up accordingly. This means that junk from the ROM would be displayed at the bottom of the screen but I can blank this by setting the tiles for these to the same foreground and background colors.

Although it is possible to add extra chips to do more wonderful things with the video I'd rather concentrate on getting the most out of the Prop itself and also so that when Prop II pops up I'm ready to port and play!

At present I am working on making the user code persistent and autostarting with the backup to EEPROM.

[prof_braino]

I like the graphics. Are you going to include a source editor in your package?

I get tested the HC06 blue tooth module yesterday, I was able to use the terminal from two houses away.

[D.P]

I was struggling with the previous version "white space" damage I think using the Prop BOE and BST but since rev1220727. 1800 all is well.

Also trying to use "download" with google docs inserts a bunch of garbage into the source (MAC OSX, FireFox 13) so I for one appreciate the zips. Probably just pebkac.

Appreciate all of your work, look forward to trying your bluetooth module.

[Christof Eb.]

Thanks for the explanation, Peter and keep on with this!
I will next try your forth for a little experiment. The interactive way and the speed should be just optimal for such things.
I want to compare a transistor amplifiier with a valve amplifier. I want to give them short burst signals like beep-pause-beep-pause... as input. This shall be done with the demoboard. Should be quite simple with your forth, but I am no forth guru at all....
Due to the difference of the output impedance I assume, that a difference of the loudspeaker input signal at the end of the beeps could be visible with an oscilloscope.
Thanks for sharing Christof

[Peter Jakacki]

Yes, the DECIMAL is compiled but not executed until you hit enter however the numbers are converted before that happens. The best way is to either set the base beforehand as you have done or else explicitly force the number to a decimal either as #22 or 22d so that there is no confusion. i just checked and the OUTA and DIRA registers are being set correctly although I have VGA hooked up to these pins so I haven't connected an LED.

_22d MASK OUTSET ok
_1F4 COG@ . ok
40400000 _ ok
_1F6 COG@ . ok
40400000 _ ok

New youtube video showing some more graphics and scrolling as well as a little bit with the serial terminal speed

[Christof Eb.]

Hi, Peter,
as the cog outputs are "ored", this is not a problem of the hardware.
I had already tried rev120727.1800.
_22d MASK OUTSET ok works
_DECIMAL 22 MASK OUTSET ok does not work.

_DECIMAL ok
_22 MASK OUTSET ok does work

Christof

[Peter Jakacki]

Ah, I have pins 16..23 setup for VGA, that would explain why you can't set the output. As for the 22 not appearing on the stack the problem could be with the earlier version's whitespace "feature" in that it would compile but not execute a line if it had a trailing whitespace. Try it without a space after it and just hit <enter> or else download the latest binary at the top post as I have just updated it before. I tried it just now:

 Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120727.1800 
_ ok
_.S ok

STACK: 00000000 00000000 00000000 A55AA55A _ ok
_22d ok
.S ok

STACK: 00000000 00000000 A55AA55A 00000016 _

Here's a new video that shows a bit more detail that you should find interesting

[Christof Eb.]

Hi Peter,
great if this will be a full self hosting system!


_DECIMAL 22 MASK OUTSET ok
does not switch on the LED.

I downloaded the new version, but I still cannot see a 22d on the stack. Only after a DUP there are two entrys 16hex. See the terminal protocol below.
Perhaps you want to have a look at it, although I don't want to break your actual work.

Christof




Propeller .:.:--TACHYON--:.:. Forth V1.0 rev120727.1800
_22d ok

DATA STACK
01CE: 000001CE A55AA55A
01D0: 00000000 00000000 00000000 00000000
01D4: 00000000 00000000 00000000 00000000
01D8: 00000000 00000000
RETURN STACK
01DA: 00001007 00000CBB
01DC: 00000C60 00000ABC 00000AA2 00000A44
01E0: 000009DF 000009DF 000009D7 00000000
01E4: 00000000 00000000 00000000 00000000
LOOP STACK
01E8: 00000000 00000000 00000000 00000000
01EC: 00000000 00000000 00000000 00000000
REGISTERS
093C: 00 00 F0 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
094C: 00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00 ............$...
095C: 00 20 00 00 16 00 00 00 00 00 00 00 02 00 00 00 . ..............
096C: BC 09 00 00 00 00 E0 14 00 00 A4 01 A6 01 20 0D .............. .
097C: 01 10 10 32 64 00 00 00 00 00 00 00 00 00 00 00 ...2d...........
098C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
099C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
09AC: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

COMPILATION AREA
01A4: 81 16 7C 5C 76 07 FF 5C 06 96 7F E8 0E 01 7C 5C ..|\v..\......|\
01B4: 76 07 FF 5C 0E 97 7F E8 AD 5F FF 5C 0E 01 7C 5C v..\....._.\..|\
01C4: 76 07 FF 5C 76 07 FF 5C 76 07 FF 5C 0E 01 7C 5C v..\v..\v..\..|\
01D4: 0E 9D 7F EC CE 97 BF A0 33 01 7C 5C CF 97 BF A0 ........3.|\....
DUP ok
_
DATA STACK
01CE: 000001CE 00000016
01D0: 00000016 A55AA55A 00000000 00000000
01D4: 00000000 00000000 00000000 00000000
01D8: 00000000 00000000

[Peter Jakacki]

Wicked Fast, Peter!

I like the loop compiling from the input stream - very useful for testing/playing!

Thanks Rick, that's what always used to annoy me with every Forth I've ever played with (including my own) in that you had to create a definition to run a quick command just because it contained looping and/or branching etc. So compiling word by word has advantages and when it is executed on an <enter> it runs at the same speed and the exact same way it would when it's built into a definition. The VGA stuff I'm doing is really just to provide a test environment for Tachyon at present but it looks like it would be good to continue with this stuff and turn it into a development system on a chip rather than having to rely on PCs or other platforms. When Prop II comes along I will be in a good position to port this stuff over fairly easily I think.

BTW, when I did some testing and tweaking of my serial receive driver the other day I found out why it wouldn't work above 3M baud. It turns outs that Minicom is quite happy to issue the 3.5 and 4M baud commands to the Linux drivers but the FTDI chip just reverts to a slow speed instead. From the timing it looks like I could go faster again if only the PC could keep up !

[Peter Jakacki]

Hi Christof,
Thanks, I'm trying to keep it simple, both in terms of the kernel source and one step compilation plus in terms of just using it. Yes, I will be implementing full SD and keyboard drivers etc, either in Forth itself perhaps running in another cog or a stripped down version from the OBEX. The default number base is hex so that may be the problem then? I will update the binary to the latest version too. You can always force the number to decimal either as #23 or 23d and the same goes for forcing hex or binary as well as ASCII and control characters as in "#" and ^D.

Yes, the stack "seems" a little small but stack abuse is rife in a lot of Forth code and should really be reined in. In fact the return stack gets misused by many programs because they have no way of manipulating data easily on the data stack and when the return stack is not restored properly, then whamo, crash ..... not good. So you see I have the loop stack just for loops or even for temporary values and they can even be addressed easily too using the I,IX, and J type words etc. The other thing that helps is the use of the fixed register area which is used internally and also to handle four or more parameters. Eventually I will have local variables created from the stack comment ( -- ) and saved in these registers. Manipulating and juggling values on the data-stack is fine when there are only 2 or 3 values but over that it becomes annoying. Anyway my original plan was to try and keep it small and tidy on the stack but allow for a mechanism which could automatically come into action when the stack overflowed and start saving these values to hub memory but only when necessary which is obviously required to make the system robust (but slower during these exceptions).

[mindrobots]

Wicked Fast, Peter!

I like the loop compiling from the input stream - very useful for testing/playing!

[Christof Eb.]

Hi Peter,
I am very impressed by your direction implemeting forth. I like the byte code which is directly the adress. Simple and fast whow!
I have played just a little bit with tachyon. I can switch on a LED at port P7: 7 MASK OUTSET. I have not been able to do this with the LED on Port P23 of the demoboard: "23 MASK OUTSET".
I cannot see a number with two digits (22) on the stack using ^d. But if I use "." I can print it.

What is your idea of the system, when will it be complete for you? Will it be a self- hosted system with SD-card and keyboard support?
I understand that the stack in cog-ram is a key to a very fast implementation but I am a little bit frightend what ca be done with such a short stack?

Christof

[Peter Jakacki]

The current version appears to be working well although I still have to build in a SAVE feature for backing-up downloaded user code for full auto-restore and run. But that will come soon. For now I have uploaded to youtube a short video where I load in some Forth code into a Prop board running Tachyon and show how well this bytecode handles bitmapped VGA without resorting to a GPU cog.

For reference this is the code I downloaded:

 
: START   CNT@ $10 @REG ! ;
: LAP       CNT@ $10 @REG @ - #80,000 / ;

\ **************************** VGA FUNCTIONS ********************

: CLRSCN        pixels W@ $6000 ERASE ;

: COLORS    colors W@ W! colors W@ DUP 2+ #382 CMOVE ;

$FF04 COLORS
{                                   
: PLOT ( x y -- ) 
    6 SHL OVER 3 SHR +  
    SWAP 7 AND MASK SWAP pixels W@ + SET 
    ;
}

: HLINE  ( x y length -- ) 
    ROT SWAP ADO I OVER PLOT LOOP DROP 
    ;
    
: VLINE  ( x y length -- ) 
    ADO DUP I PLOT LOOP DROP 
    ;

: ITEM    2* 2* @REG ;

: ITEMS  ( items -- ) 0 DO I ITEM ! LOOP ;

: RECT ( x1 y1 xlen ylen -- ) 
    4 ITEMS 
    3 ITEM @ 2 ITEM @ 1 ITEM @ HLINE 
    3 ITEM @ 1 ITEM @ + 2 ITEM @ 0 ITEM @ VLINE 
    3 ITEM @ 2 ITEM @ 0 ITEM @ VLINE 
    3 ITEM @ 2 ITEM @ 0 ITEM @ + 1 ITEM @ HLINE 
    ;

: BOXES
    CLRSCN 
    #200 0 DO I I 50 50 RECT 4 +LOOP 
    $C0 $C0 $30 FOR 2DUP $80 $40 RECT SWAP 4 + SWAP 4 - NEXT 2DROP 
;


: SLANTS  180 0 DO 100 0 DO I J + I PLOT LOOP 4 +LOOP ;

\ : RSLANTS  180 0 DO 100 0 DO I 180 J - + 100 I - PLOT LOOP 4  +LOOP ;



: X   8 @REG ;
: Y #10 @REG ;
: VCR    0 X W! ;
: VLF    #34 Y W+! ;
: HOME        VCR 0 Y W! ;
HOME
: CHAR ( ch -- ) 
       DUP 2/ 7 SHL $8000 + 
       ( ch addr ) 
       20 0 DO DUP @ 3RD 1 AND IF 2/ THEN 
       10 0 DO DUP 1 AND IF X W@ I + Y W@ J + PLOT THEN 2/ 2/ LOOP 
       DROP 4 +  
       LOOP 2DROP #18 X W+! X W@ #500 > IF VCR VLF THEN ;

: CTRL
    DUP $0D = IF VCR DROP EXIT THEN
    DUP $0A = IF VLF DROP EXIT THEN
    DUP $0C = IF HOME CLRSCN DROP EXIT THEN
    DUP $01 = IF HOME DROP EXIT THEN
    DUP $1B = IF DROP R> DROP EXIT THEN
    CHAR
    ;
: VEMIT  DUP 20 < IF CTRL ELSE CHAR THEN ;


: DEMO
    CLRSCN HOME
    BEGIN KEY VEMIT AGAIN
    ;

[jmg]

Thanks.

STL doesn't look like it's using a stack from the programmers perspective at least, interally it may but with a lot of these compilers the syntax is very rigid.

I did find some more info that mentions stack here,

http://claymore.engineer.gvsu.edu/~j...ers/plc_il.pdf

An important concept in this programming language is the stack. (Note: if you use a calculator
with RPN you are already familiar with this.)

and I think they mean the brackets are an inferred/hidden stack, not quite the explicit stack of forth.

[Peter Jakacki]

If you were to take an example from here, for all Boolean variables (aka pins)
http://www.automation-course.com/branching-in-il/
which links from
http://en.wikipedia.org/wiki/Instruction_list

shown below, and coded that in TACHYON, what would the result look like ?
It seems the braces in the Instruction List carry an implied stack ?

The thing with Forth is that you can tailor the way it compiles to suit your style or application. In this case I have added or modified a couple of words which would eventually be part of the kernel anyway. Following this I set the number base to octal to allow the port numbering system to be used where the last digit I assume is from 0..7, so it's octal. So if I interpreted the instructions correctly they could look like this example where I have spread the statement over a few lines and named it as well.

STL doesn't look like it's using a stack from the programmers perspective at least, interally it may but with a lot of these compilers the syntax is very rigid.

\ Let's define a couple of general-purpose extensions 
: IN  ( bit -- ) MASK P@ AND 0<> ;
: OUT    ( state pin -- )  px ;

\ change number base to octal to enhance readability of port numbering
8 BASE C!  

\ Now code the example
: PLC_DEMO
  0.1 IN 0.2 IN OR
  0.5 IN 0.6 IN OR
  AND
  2.0 IN AND 2.5 IN AND 
  2.3 OUT
;

[jmg]

If you were to take an example from here, for all Boolean variables (aka pins)
http://www.automation-course.com/branching-in-il/
which links from
http://en.wikipedia.org/wiki/Instruction_list

shown below, and coded that in TACHYON, what would the result look like ?
It seems the braces in the Instruction List carry an implied stack ?

; Instruction list coded
   AND(
       OR  I0.1
       OR  I0.2
      )
   AND(
       OR I0.5
       OR I0.6
       )
   AND I2.0
   AND I2.5
   = Q2.3

; Algebraic coded this is 
 Q2.3 =  I2.0 AND I2.5 AND (I0.1 OR  I0.2) AND (I0.5 OR I0.6)

This link  http://users.isr.ist.utl.pt/~pjcro/courses/api0809/docs/API_I_C3_IL.pdf
has a slightly different style, and I think this is also equivalent to the above 

   AND(
       LD  I0.1
       OR  I0.2
      )
   AND(
       LD I0.5
       OR I0.6
       )
   AND I2.0
   AND I2.5
   ST  Q2.3

[Peter Jakacki]

I have updated the top post to include a demo board binary and Forth source test samples in the zip attachment. So now it's easy just to load in a standard binary (set for 57.6K baud) and hookup a VGA monitor.

Here's that attachment anyway:TACHYON.zip

[Peter Jakacki]

The current appoach on TrimSpin is to write a Spin interpreter that implements all of the instructions, but runs about twice as fast. However, because this doesn't fit in a cog, the interpreter is trimmed down to only the bytecodes that are used by a particular program. This is done by profiling the bytecodes in an existing binary file, and generating an interpreter that matches it.

I'm not sure which applications would use it other than those that need to run just a little bit faster.

Peter, the 88 msec time is very impressive.

I think you are on the right track with having your own Spin interpreter and trimming the way you do. I assume that what can't fit in the cog but is needed is then implemented at a higher-level?


As I develop and test Tachyon further I keep optimizing the kernel. I just improved the erase and fill operations simply by creating a helper word with two PASM instructions so that I can now fill or erase the 24kB of memory in 34ms.

: CLS        pixels W@ $6000 ERASE ;

In the kernel I also had code for some fast single bytecode constants using mov X,#n and jmp #PUSHX instructions but now I have reduced this to one instruction per "entry" so that constants 0...8 take but 10 instructions total.

As of this moment the runtime compiler seems to be working fine although there are a lot of little things that need to be tidied up. Here is a little test code that I use to list the words in the dictionary. BTW, I have a whitespace after each line except the last to prevent execution of the line of code which normally is executed on a <CR>. I will tidy up little things like this in the process of testing and developing.

: NFA>CFA  BEGIN C@++ $7F > UNTIL ;
: WORDS      
    names W@ 
    BEGIN 
    CR DUP .W 3A EMIT BL EMIT 
    DUP NFA>CFA 1- DUP 3 ADO I C@ .B BL EMIT LOOP 
    3 + 
    SWAP .STR BL EMIT 
    DUP C@ 0= 
    UNTIL 
    DROP CR 
    ;

\ we will now execute WORDS
_WORDS ok

13C2: 8A C1 53 WORDS 
13CA: 8A C1 52 NFA>CFA 
13D4: 80 00 06 RESET 
13DC: 80 01 06 ?EXIT 
13E4: 80 04 06 0EXIT 
13EC: 80 06 06 EXIT 
13F3: 80 07 06 NOP 
13F9: 80 08 06 3DROP 
1401: 80 09 06 2DROP 
1409: 80 0A 06 DROP 
1410: 80 0C 06 ?DUP 
1417: 80 0D 06 DUP 
141D: 80 0F 06 2DUP 
1424: 80 11 06 OVER 
142B: 80 13 06 3RD 
1431: 80 15 06 4TH 
1437: 80 19 06 SWAP 
143E: 80 1C 06 ROT 
1444: 80 17 06 NIP 
144A: 80 25 06 1+ 
144F: 80 27 06 1- 
1454: 80 21 06 + 
1458: 80 23 06 - 
145C: 80 2E 06 * 
1460: 80 2B 06 / 
1464: 80 29 06 U/MOD 
146C: 80 30 06 UM* 
1472: 80 32 06 NEGATE 
147B: 80 36 06 INVERT 
1484: 80 39 06 AND 
148A: 80 3B 06 OR 
148F: 80 3D 06 XOR 
1495: 80 3F 06 SHR 
149B: 80 41 06 SHL 
14A1: 80 43 06 2/ 
14A6: 80 45 06 2* 
14AB: 80 47 06 REV 
14B1: 80 49 06 MASK 
14B8: 80 4D 06 0= 
14BD: 80 51 06 = 
14C1: 80 55 06 > 
14C5: 80 5A 06 C@ 
14CA: 80 5C 06 W@ 
14CF: 80 5E 06 @ 
14D3: 80 60 06 C+! 
14D9: 80 62 06 C! 
14DE: 80 64 06 C@++ 
14E5: 80 68 06 W+! 
14EB: 80 6A 06 W! 
14F0: 80 6C 06 +! 
14F5: 80 6E 06 ! 
14F9: 80 70 06 CMOVE 
1501: 80 71 06 SET 
1507: 80 73 06 CLR 
150D: 80 75 06 BIT? 
1514: 80 7A 06 C++ 
151A: 80 7E 06 IC! 
1520: 80 80 06 PUSH4 
1528: 80 81 06 PUSH3 
1530: 80 82 06 PUSH2 
1538: 80 83 06 PUSH1 
1540: 80 86 06 LVAR 
1547: 80 8B 06 BVAR 
154E: 80 95 06 FALSE 
1556: 80 95 06 OFF 
155C: 80 95 06 0 
1560: 80 94 06 1 
1564: 80 93 06 2 
1568: 80 92 06 3 
156C: 80 91 06 4 
1570: 80 90 06 5 
1574: 80 8F 06 6 
1578: 80 8E 06 7 
157C: 80 8D 06 8 
1580: 80 97 06 0FF 
1586: 80 99 06 ON 
158B: 80 99 06 TRUE 
1592: 80 99 06 -1 
1597: 80 9B 06 BL 
159C: 80 BC 06 LSTACK 
15A5: 80 F3 06 EMIT 
15AC: 80 9D 06 P@ 
15B1: 80 9F 06 P! 
15B6: 80 A1 06 OUTSET 
15BF: 80 A3 06 OUTCLR 
15C8: 80 A4 06 OUTPUTS 
15D2: 80 A6 06 INPUTS 
15DB: 80 A8 06 PX 
15E0: 80 AB 06 CLKBIT 
15E9: 80 AD 06 CLKBITS 
15F3: 80 B6 06 REBOOT 
15FC: 80 AE 06 COG@ 
1603: 80 B2 06 COG! 
160A: 80 B8 06 HUBOP 
1612: 80 BA 06 STACKS 
161B: 80 BC 06 LSTACK 
1624: 80 BE 06 CALL 
162B: 80 C1 06 (XCALL) 
1635: 80 C6 06 (RCALL) 
163F: 80 C8 06 (WCALL) 
1649: 80 CA 06 (CMPJEQ) 
1654: 80 CE 06 (ELSE) 
165D: 80 D0 06 (IF) 
1664: 80 D2 06 (UNTIL) 
166E: 80 D4 06 (AGAIN) 
1678: 80 D6 06 (ADO) 
1680: 80 D9 06 (DO) 
1687: 80 DA 06 (LOOP) 
1690: 80 DC 06 (+LOOP) 
169A: 80 E4 06 (FOR) 
16A2: 80 E6 06 (NEXT) 
16AB: 80 E8 06 >R 
16B0: 80 EB 06 R> 
16B5: 80 ED 06 >L 
16BA: 80 EF 06 L> 
16BF: 80 F1 06 I 
16C3: 80 FF 06 BKEY 
16CA: 80 F3 06 EMIT 
16D1: 80 F6 06 (REG) 
16D9: 80 F8 06 @REG 
16E0: 80 FA 06 WAIT 
16E7: 80 FD 06 (PTRSTR) 
16F2: 80 FE 06 (CMPSTR) 
16FD: 82 C1 19 STOP 
1704: 82 C1 1A COGID 
170C: 82 C1 02 0<> 
1712: 82 C1 01 <> 
1717: 82 C1 05 0> 
171C: 82 C1 04 0< 
1721: 82 C1 03 < 
1725: 82 C1 06 U< 
172A: 82 C1 07 WITHIN 
1733: 82 C1 0A LEAVE 
173B: 82 C1 0B J 
173F: 82 C1 0C K 
1743: 82 C1 0D IX 
1748: 82 C1 2F ERASE 
1750: 82 C1 2E FILL 
1757: 82 C1 08 ms 
175C: 82 C1 09 CNT@ 
1763: 82 C1 23 KEY 
1769: A2 C1 0F \ 
176D: 82 C1 22 HEX 
1773: 82 C1 21 DECIMAL 
177D: 82 C1 20 BINARY 
1786: 82 F6 00 REG 
178C: 82 F6 3D BASE 
1793: 82 F6 2C DIGITS 
179C: 82 F6 36 HERE 
17A3: 82 F6 3A DELIM 
17AB: 82 C1 14 .S 
17B0: 82 C1 17 DUMP 
17B7: 82 C1 18 COGDUMP 
17C1: 82 C1 15 .STACKS 
17CB: 82 C1 16 DEBUG 
17D3: 82 C1 1B CLS 
17D9: 82 C1 1C SPACE 
17E1: 82 C1 1D BELL 
17E8: 82 C1 1E CR 
17ED: 82 C1 10 .H 
17F2: 82 C1 11 .B 
17F7: 82 C1 12 .W 
17FC: 82 C1 13 .L 
1801: 82 C1 3E . 
1805: 82 C1 31 >DIGIT 
180E: 82 C1 32 NUMBER 
1817: 82 C1 29 GETWORD 
1821: 82 C1 2B FINDSTR 
182B: 82 20 C1 ' 
182F: 82 C1 2D *VER 
1836: 82 C1 34 @PAD 
183D: 82 C1 35 +PAD 
1844: 82 C1 36 >CHAR 
184C: 82 C1 37 #> 
1851: 82 C1 38 <# 
1856: 82 C1 39 # 
185A: 82 C1 3A #S 
185F: 82 C1 3B .STR 
1866: 82 C1 3C STRLEN 
186F: 82 C1 3D U. 
1874: 82 F6 1C colors 
187D: 82 F6 20 pixels 
1886: 82 F6 32 names 
188E: 82 F6 36 here 
1895: 82 F6 38 codes 
189D: A2 C1 42 FOR 
18A3: A2 C1 43 NEXT 
18AA: A2 C1 44 DO 
18AF: A2 C1 45 ADO 
18B5: A2 C1 46 LOOP 
18BC: A2 C1 47 +LOOP 
18C4: A2 C1 48 IF 
18C9: A2 C1 49 ELSE 
18D0: A2 C1 4A THEN 
18D7: A2 C1 4B BEGIN 
18DF: A2 C1 4C UNTIL 
18E7: A2 C1 4D AGAIN 
18EF: A2 C1 4E : 
18F3: A2 C1 4F ; 
18F7: A2 C1 50 CREATE 
1900: 82 C1 51 AddXcode

[Dave Hein]

AS I understand it, TrimSpin is a subset of spin. What kind of applications do you use it for?
Can you do everything spin can do using your subset?

The current appoach on TrimSpin is to write a Spin interpreter that implements all of the instructions, but runs about twice as fast. However, because this doesn't fit in a cog, the interpreter is trimmed down to only the bytecodes that are used by a particular program. This is done by profiling the bytecodes in an existing binary file, and generating an interpreter that matches it.

I'm not sure which applications would use it other than those that need to run just a little bit faster.

Peter, the 88 msec time is very impressive.

[Phil Pilgrim (PhiPi)]

If Tachyon is capable of handling the full repertoire of Spin commands -- either natively or with a combination of native words -- I wonder if it might be a better target virtual machine for the Spin compiler than the current p-code interpreter.

-Phil

[Peter Jakacki]

If I replace "byte[i++] += 1" with "byte[i++]++" in Spin I get 294 msec. I get 132 msec in TrimSpin.

Well, if it comes down to optimizations then if I replace "1 I C+!" with "I C++" then I get 88ms in Tachyon

[prof_braino]

If I replace "byte[i++] += 1" with "byte[i++]++" in Spin I get 294 msec. I get 132 msec in TrimSpin.

AS I understand it, TrimSpin is a subset of spin. What kind of applications do you use it for?

For example, forth is often used for cases where we want drivers maybe eventually in assembler, but don't want to write the whole program in assembler. And/or we want to develop and test interactively.

Can you do everything spin can do using your subset? This is a cool idea.

[Dave Hein]

If I replace "byte[i++] += 1" with "byte[i++]++" in Spin I get 294 msec. I get 132 msec in TrimSpin.

[Peter Jakacki]

Here's a simple benchmark for Spin vs Tachyon in terms of raw HUB memory access. I increment each byte of the 24K of bitmap memory which of course involves a hub read and a hub write as well as looping. So both fragments of code are limited by the hub access time and shouldn't really perform any differently as hub access is like wading through molasses. However the Spin loop takes 368ms to execute vs the 137ms it takes Tachyon to do the same. I will look at some other routines later and compare the differences.

' Spin: Increment 24kB of video memory byte by byte - takes 368ms with 50 bytes of code

  repeat
    i := Pixels
    x := CNT
    repeat $6000
      byte[i++] += 1
    y := CNT
    x := (y-x)/80000
    coms.tx($0D)
    coms.tx($0A)
    coms.dec(x)

' Tachyon: Increment 24kB of video memory byte by byte - takes 137ms with 32 bytes of code

100 0 DO CNT@ $8000 $2000 DO 1 I C+! LOOP CNT@ SWAP - 80,000 / CR U. LOOP

[Peter Jakacki]

Progess report....

The VGA_512x384_Bitmap object has now been incorporated into the source as there is sufficient memory available despite the fact that this object requires 24KB just for the bitmap. Being able to include objects such as these was one of the requirements of Tachyon which is also why it had to have a very small footprint despite the need for speed. Access to the object at present is via the color and pixel pointers but at a later stage I will write a Graphics demo object in Forth to showcase Tachyon.

I mentioned in the thread that Tachyon does not follow the traditional method of handling text input which normally would accumulate into a text input buffer (TIB) and after an <enter> would be processed word by word in an interpretive fashion. One of the drawbacks of this is that branch and loop stuctures which are meant to be compiled cannot be entered in an interpretive fashion and you just end up with the "compile only" warning. What I've been able to do is to skip the TIB and just parse words as they are encountered in the input stream and compile these immediately into the current code compilation location. When an <enter> is encountered the bytecodes are then executed which means that it is now possible to type in interactively such statements as:
20 1 DO CR I 0 DO 2A EMIT LOOP LOOP<enter>
without having to resort to creating a special word, invoking it, and then forgetting it (deleting). The interactve statements also behave exactly like they would inside a definition and at the same speed. Of course words such as IF and THEN etc are tagged as immediate words and are not compiled but instead execute immediately and control the compilation.

My next step which I am presently on is allowing new definitions to be created to which end I am testing the dictionary and vector table handlers. This stage of the testing will probably be completed in the next 24 hours.

Has anyone tried loading Tachyon onto a board yet? Please let me know if you had any problems. The same goes for viewing the on-line Google document source. BTW, I am using one of my Pixie boards at the moment so I can play with the VGA graphics especially when the Tachyon kernel is developed enough (soon) that I can just communicate to it via Bluetooth or ZigBee and interactively develop my applications.

[Peter Jakacki]

3M baud is crazy fast. Didn't somebody say 9600 should be fast enough for anybody?

I didn't check, are you doing any error checking? Sal said something about a limit at which point it starts to get unstable, have you noticed anything like that?

At 3M baud the terminal screen updates blindingly fast and unless it's a long listing all it does is blink a new screen into existence! Since a cog is devoted to receive only it is not handicapped with trying to maintain buffering and timing and timing for the transmitter as well. To do this in Spin would require three cogs: one for Spin, one for Receive, one for Transmit. However in Tachyon I can transmit straight from Tachyon's cog and leave the other cog to handle the receive. I can probably go faster yet still but 3M works reliably.

BTW, I have updated the top post with a zipped attachment of the latest files which I will keep up-to-date with the latest "release" version whereas the on-line document will always be the live and bleeding edge.

[prof_braino]

3M baud is crazy fast. Didn't somebody say 9600 should be fast enough for anybody?

I didn't check, are you doing any error checking? Sal said something about a limit at which point it starts to get unstable, have you noticed anything like that?

[Peter Jakacki]

Here's an update, I've had a busy week but still managed to get a lot more going. The current version runs at a default of 3M baud (I use Minicom on Linux) and includes break detection to reboot the Prop. The word and number parser are working well as are the formated print functions. Numbers encountered in the terminal text input in Forth are normally converted in the current number base (decimal,hex,binary etc) but I also allow a very flexible format for these numbers as I like to use them this way.
Number prefixes include: $ for hex, % for binary, # for decimal while suffixes can be h for hex, d for decimal, and b for binary. As long as it begins or ends in a digit or an valid symbol you can use any other symbol mixed between the digits for instance:
#12:45 is decimal for 1245
%1100_0101 is binary for $C5
5_000_000d or #5,000,000 is what it looks like etc

BTW, a hex dump listing of the full 64K of memory takes 4 seconds including interpreting the text "CNT@ 0 $10000 DUMP CNT@ SWAP - #80,000 / DECIMAL ." which means at 56 characters/line and 4,096 lines that equates to 17.43us average time per character which also includes the 4us or so to send the character! I know that Spin would never ever keep up with that!

Next step now is to implement compilation mode with it's associated dictionary handlers, Hopefully I will have that done this weekend.

[Peter Jakacki]

Do you wonder what the memory map looks like for Tachyon? I made a quick one up in Tachyon's on-line document but here is what it looks like:

Out of this almost 4K bytes there is another 800 bytes or so that I could reclaim again so that really brings the memory footprint closer to 3kB. Since Tachyon bytecode is so efficient this might only go up another few k when I add in the rest of the high-level functions.

[Peter Jakacki]

Hello:

So how is your coding doing 2M baud?
Why is it so much faster than the standard Full Duplex 4 port object?
Is the serial driver full duplex?
When do you think the whole of the Tachyon code will be posted?

Thanks in advance for your patience with all these questions.

cheers,
rich

There's nothing really difficult in getting the Prop to handle a couple of mega-baud but to get it to do it full-duplex or worse still, four full-duplex channels from the one cog is a huge ask. I dedicate a cog just to handle the receive and buffering side while the Tachyon VM cog will bit-bash the transmit side directly as it's faster to do it that way. So effectively you have Full-duplex without the timing problems that would normally arise from getting a cog to jumpret here and there and introducing jitter both in receive and transmit as is the case with most implementations. I've looked at the timing for a lot of these implementations and while they are fine at low speed they are way out, asymetrical, and jittery at high speeds.

The code I have on Google Docs is "live" all the time and will always be the most current version as it is the one I work off, if I make a change and someone has the document open then their document will reflect that change immediately. However to keep a few grumblers happy I have zipped up and attached the current version.

I am still a few more days away or so from having a fully functional system running, at present I need to finish off the whole text interpreting thing with it's number processing and compilation modes and then I will look at integrating SD and VGA etc.

TACHYON.zip

EDIT: Now tested and working at 3M baud!

[richaj45]

Hello:

So how is your coding doing 2M baud?
Why is it so much faster than the standard Full Duplex 4 port object?
Is the serial driver full duplex?
When do you think the whole of the Tachyon code will be posted?

Thanks in advance for your patience with all these questions.

cheers,
rich

[Peter Jakacki]

Well I'm starting to get somewhere with this beyond the VM part of it that is. I am staring off simple again after scrubbing out some ugly code I imported and tried to use from another Forth project. Now I have a simple text interpreter running that executes immediately on each word for the moment. The idea is that even in interpretive mode text will be compiled into a temporary location word by word (as it is entered) and then that complied code executed on an CR. The dictionary is running out of RAM at present but I will be copying this over the 2K image of the Tachyon's VM kernel that lies unused after boot rather than worrying about accessing it in EEPROM. Once the dictionary is copied over the VM image there is still about 29K of RAM left at present. The structure of the dictionary is settling down now as I have this running nicely with non-counted string names terminated by an attribute byte and 2 bytecodes so this structure is very compact and easy to scan plus there are no link fields.

I have also tested the serial transmit and receive to at least 2M baud at present and I will do some further tests at higher speeds later on. I'm also overlaying the serial receive cog's image as well with the receive buffer so there is no wasted memory.

So far...so good.

[Peter Jakacki]

Even with automagic converters you still have to have it formatted correctly plus there are some things that you don't want it to do automagically anyway. Well that's my argument against it No but the Google document is manually formatted just like any word processor and if you are formatting as you are entering text (vs pasting an existing text file) then you make it stand out just as you would like etc. My suggestion is to give it a try, it can't hurt and you can play with it to see how well it works plus the source code is always intact.

[prof_braino]

I think I want to try this for propforth. So how do you get the context highlighting for forth? In the PSPad text editor, we can set up the set of forth control words, and it automagically does the context highlights. Do we have to set up up something to define the set of forth words, or do you have to do the color for every word as you type it in?

[Peter Jakacki]

Hi prof, this is a Google cloud document so all the normal editing tools are there online when you are signed in and you have permission to edit. For some reason some may not be able to access this document although I had no problems on many different systems as guest and only one person has complained so far that their browser didn't render it properly..grumble grumble. I've tried accessing this on several completely clean systems with different browsers etc and it all seems to work fine. What I like about this type of formatted document is that it is a very good way to document as you go and it makes important parts of the source "pop out" while subduing others. Images are a bonus too. I've probably gone a little wild with some of the colors on this document but I am experimenting at present to see what does work. It's actually faster to edit in this document normally and when it comes time to compile it takes less than 3 seconds to "select all - copy& paste into BST and F10.

The other advantage is that this is a live document, what you see is what I see and what I am changing.

[prof_braino]

That looks pretty cool. How do you do the formatting? Is there a link to how-to instructions?

[Humanoido]

Peter, congrats on this spectacular project! You mentioned CogForth and how you reworked it to create Tachyon Forth. I'm interested in a copy of the original CogForth, in any condition, for its great historical value.

[Peter Jakacki]

Yes, the fancy formatting makes it a lot easier to read, even for me. It's certainly a lot clearer to see where the flow goes and I can insert images etc without upsetting the text itself. So you can just copy and paste or download as text to compile.

Another great feature is that this "source" is live, you may even see things change before your eyes as I am formatting it or making code changes !!! Maybe this way should be the way we format source for the gold standard?

Fancy formatted source code in Google Docs

[msrobots]

@Peter.

now I need to start thinking backwards.This is nice. Even I might understand FORTH now - Will study your pasm ...

Thank you

Mike

[Peter Jakacki]

I'm not really ready yet to release the source for this but in a way I am doing so. I've been experimenting with formatting the source code in Google Docs (<-- click here) and just copying and pasting the formatted text into BST to make sure that it runs. Well, guess what?, it does!. So this is more an exercise into posting code in fancy format as a shared document just to see how it will work. This is also a good opportunity for those who want to get their hands on to the source for Tachyon just to play with until I manage to get the text interpreter all sorted out. BTW, I copied the higher-level source from an old Forth I wrote for the ARM chip several years ago and although it worked there it is ugly and I am in the process of re-doing it all. So just a little while longer but in the meantime have a good look.

The Google Docs format makes it easy to view and even download in various formats. Of course if you want to try out the code then just select all and copy&paste into your Spin IDE. The settings are so that anyone with the link can view and comment and if anyone wants to be able to edit this document as part of a collaborative effort then please just email me. There's also the chat box you can use when you have the document opened.

[Peter Jakacki]

Phil,
Although Postscript may be based on Forth it is also very non-Forth'ish because of it's huge complexity. I understand the Postscript requirements but how useful would that really be in the simpler embedded Forth model with lots of "small" words? But I will see if this can be implemented without too much fuss, especially since I am looking at being able to create local variables straight from the stack description which is normally only a comment such as: ( pin channel -- flg ) ..... and referring directly to pin and channel etc. However EXIT or it's cousin will then have to clean-up the stack and place whatever results there are onto the stack.

[Phil Pilgrim (PhiPi)]

Peter,

My suggestion arises from comparative experience programming in both Forth and Postscript. The latter has mark and cleartomark words that make stack maintenance a breeze compared to Forth. One simple example of their utility can be seen when a subroutine needs to abort, returning the stack to a known state upon exit. Depending upon how much stuff got pushed on before the fault condition was encountered, this could be a real chore without a way simply to wipe out the garbage down to a known point in the stack.

-Phil

[Peter Jakacki]

This bytecode is proving to be very compact as I have tediously coded in the high-level words that are needed to handle the text input, parsing, interpreting/compiling and number conversion etc. How compact? The bytecode for all this with the bells and whistles is under 1k.

Some changes:
1) Added a jump table for kernel bytecodes as I originally planned. This simplifies calling them from the Spin compiler and allows these functions to be anywhere.
The table allows for up to 256 vectors which so that a call looks like:..... BCALL,xPARSE ..... where PARSE is referred to by the byte label xPARSE. Now I don't have to do a relative call with all that awkward setup for the Spin tool as in:...... RCALL,@L1-@PARSE .....where I also have to create a label such as L1 that follows everytime. The DATA section has it's advantages as I just set the ORG to 0 before the table so that each entry has consecutive values from 0 up to the maximum reference of 255.

2) Added a local register bank which is great for storing temporary values and settings etc. This makes the kernel bytecode a lot easier too as it doesn't have to create special variables for number bases and interpreter flags etc. The registers used by the kernel are referred to in the CON section where they are created with a simple:

' REGISTER byte OFFSETS - 64 bytes
        #32,NTIB,IN,NUMFLG,FLAGS,BASE

While the reference in the Spin tool to the register is in the form:

COMMENT byte  REG,NTIB,CFETCH,REG,IN,CSTORE,EXIT

and compiled:

091E(002A) DF          | COMMENT byte  REG,NTIB,CFETCH,REG,IN,CSTORE,EXIT   ' ignore the rest of the text line
091F(002A) 20          | 
0920(002B) 62          | 
0921(002B) DF          | 
0922(002B) 21          | 
0923(002B) 6A          | 
0924(002C) 05          |

3) Enhanced number processing so that sensible prefixes and suffixes can be used:

Prefixs:
    -    negative number
    $    hex number ($0F00)
    %    binary number 
    '    ASCII character ('H') used in the form..... '*' EMIT
    ^    ASCII control character (^G) used in the form..... KEY? ^C = IF .....
 Suffixes:
    h    hex number (0F00h)
    d    decimal number (1000d)
    b    binary number (11000101b)

 Others:
     .    decimal point - decimal place stored in DPL
    _  standard Spin digit separator (ignored)

4) 5) 6) lots more stuff

I will probably allow direct addressing of stack items so that .... 3 STACK ... will return the address of the third stack item which can be manipulated just like any other variable.

@Phil:
I have tinkered before with shadow stacks that hold information about the stack items, a bit like a type identifier. But although I understand what you are saying and ways to implement it I'm not sure how useful this would be, at least to a Forth programmer. You see, although the stack can be a nuisance especially when it is misused and layers deep, part of coding any Forth is the art of factoring things into small, clear, and manageable chunks of code. My Tachyon Forth is being driven by need, by actual embedded control use so I tweak it to optimize what I really need. But could you please give me an example of where your suggestions would really excel? Thanks.

[Phil Pilgrim (PhiPi)]

Peter,

I like your stack philosophy. There's no reason to have a huge stack, except for deep recursion. One annoyance of Forth, of course, is stack maintenance. It would be handy to add two more kernel instructions, pushmark and poptomark. These allows one to punctuate the stack in such a way that post-operative cleanup requires only a poptomark without having to know how much garbage remains. The "mark" deosn't really have to exist in the stack itself, but can be tracked either via a rotating bitmask that's synchronous with the stack, or a separate mark stack whose top element keeps track of the relative position of the next mark (i.e. increments on a push, decrements on a pop, and gets popped off when it goes negative).

-Phil

[Dave Hein]

Can you publish a complete list of the Tachyon bytecodes? It seems that Spin could be compiled to Tachyon bytecodes with about the same code size, but faster speed. Most of the Spin bytecodes are used to support various addressing modes, but this takes up a lot of space in the Spin interpreter. It may be more efficient to use a simpler VM, and do some operations with multiple bytecodes. This way the interpreter could be streamlined to a smaller set of intructions, and could run faster. It's sort of a RISC approach. Maybe a common streamlined bytecode VM could be developed that could be used by Spin, C, Forth and any other high level languages.

[Peter Jakacki]

Peter,

Do you think your interpreter could be applied to Spin to improve the speed? One approach would be to compile Spin to your bytecodes. Another approach may be to use your instruction-decoding technique to decode the existing Spin bytescodes.

Also, maybe it would be possible to compile C to your bytecodes. Can you describe your VM in more detail? It appears to be stack-based, but also includes an accumulator. Are there any other registers in the VM?

Dave

I just had a look at the Spin bytecodes and it ain't fun, there's no way you could code all that and still cram it into just the cog. Tachyon Forth bytecode operations are fairly simple, just like PASM, but they are very flexible and implement a simple virtual stack based processor. The reference to an accumulator is really nominal as this is just a location to shift and accumulate literal values. The so named "accumulator" is cleared for next use after every push onto the datastack. There are other temporary registers also named for convenience such as R,X,Y,Z,R0..R3 as well as the IP which is equivalent to the PC in a real processor. The "X" register is used a lot for passing a value without upsetting the tos (top of stack) value as you can see in the GETBYTE and ACCBYTE routines. Creating virtual registers is not a problem though.

Stack manipulation can be very easy and transparent on some processors but the Prop isn't one of them, there are no auto increment/decrement indexed instructions. I push and pop my stacks by physically moving values which sounds kind of brute force'ish but I worked out that this is still far more efficient as the PASM routines can access all stack items (not just tos) directly without any extra overhead so rotating and swapping etc is very fast and compact. The push and pop operations only take a tiny bit longer than a conventional stack implemented with a pointer anyway. Upon detecting non-zero values "falling" off the bottom of the stack I jump to an error processing routine but who cares if zero values "fall off" as I also pump zero values back into the bottom of the stack when it's popped.

As for compiling from C to these bytecodes there shouldn't be any problem at all as it would only be the PASM code that fits in the VM cog that would be required to run them. It's a bit like compiling from C to Java bytecodes and using the JVM but a lot simpler of course and without all the overhead that would normally be involved. At present the Tachyon bytecodes are not fixed in value as the VM is in a state of flux but even so I don't think that there would be any requirement for portable bytecode normally. The symbol address of the bytecode function is the same as the bytecode which is why I can just reference them directly with the "byte" directive in a DAT section.

Hope that sort of answers your questions and when i release some source soon you will be able to have a good look yourself to see if Tachyon bytecode is suitable for your task.

[Dave Hein]

Peter,

Do you think your interpreter could be applied to Spin to improve the speed? One approach would be to compile Spin to your bytecodes. Another approach may be to use your instruction-decoding technique to decode the existing Spin bytescodes.

Also, maybe it would be possible to compile C to your bytecodes. Can you describe your VM in more detail? It appears to be stack-based, but also includes an accumulator. Are there any other registers in the VM?

Dave

[mindrobots]

Excellent work Peter! This is exciting!

I'm doing a rain dance on this side of the world because we need the rain.....I'll add some "remote location" rain dancing for purely selfish reasons!

[Peter Jakacki]

Just a progress report now as I streamline the code. I have decided to revert back to using all 256 byte-code values for direct long access to the first 256 longs in the cog as this also simplifies the precompiled byte-code in that I don't need to specify a "/2" after each word. Plus not all byte-code values are used though as I try to cram the code for each into 2 longs if possible rather than just wasting code by jumping to the actual code. Some code primitives are 6 longs long but are still in the first 256 longs of the cog because it's a balance between wasting byte-code values and wasting cog memory (extra jmps). Having some byte-codes that use external tables for vectoring to more byte-code is too awkward to maintain and at this point seems redundant so it's been removed. The byte-code interpreter is reduced to:

doNEXT
                        rdbyte  token,IP                'read byte code instruction
                        add     IP,#1                   'advance IP to next byte token
                        jmp     token

The SPI primitives now include a flexible transmit routine which clocks data out at 2.85MHz (without doing anything fancy that is) so this handles a lot of SPI and I2C style protocols very efficiently. To slow it down just requires accessing the CLKBIT primitive at your leisure.

I have also found that it is far more efficient to store my inline literals and constants in big endian form to facilitate shifting and accumulating. So there is only one routine that reads in bytes to form these numbers and depending upon the entry point is what decides how many bytes are read. Constants are also coded as a standard definition with an exit (return from call) as there is not much advantage in having a special operation just for this. So the structure of say a 24-bit constant is [PUSH3] [$A5] [$00] [$C1] [EXIT] where PUSH3 is the byte-code for reading in 3 bytes and pushing the result onto the data stack after which the definition EXITs. Too easy.

This is the simple PASM code that effects pushing 1 to 4 inline bytes onto the datastack.

PUSH4                   call    #ACCBYTE                ' read the next byte @IP++ and shift accumulate
PUSH3                   call    #ACCBYTE
PUSH2                   call    #ACCBYTE
PUSH1                   call    #ACCBYTE
                        call    #_PUSHACC               ' Push the accumulator onto the stack then zero it
                        jmp     #doNEXT

' This code here is located in the second half of the cog RAM to leave the first half free for byte-code access.

ACCBYTE                 call    #GETBYTE
                        shl     ACC,#8
                        or      ACC,X
ACCBYTE_ret             ret

GETBYTE                 rdbyte  X,IP
                        add     IP,#1
GETBYTE_ret             ret

And this is how a separate constant is coded (similar to inline literals without the EXIT):

06DD(0023) 74          | MYCON   byte  PUSH4,$A5,$00,$FC,$01,EXIT
06DE(0023) A5          | 
06DF(0023) 00          | 
06E0(0024) FC          | 
06E1(0024) 01          | 
06E2(0024) 03          |

Because all values are non-aligned there is no wasted space aligning them to word or long boundaries. Also relative addressing gets around any offsets and allows for relocating code easily.

So my test routine which prints a start-up message, sends out 32-bits via SPI, and does a hex dump of hub RAM looks like this in byte-code listing form (courtesy BST):

06F8(002A) 77          | TXSPI   byte  PUSH1,32,CLKBITS,EXIT                  ' Send the 32-bits
06F9(002A) 20          | 
06FA(002A) 8D          | 
06FB(002A) 03          | 
06FC(002B) 74          | MYCON   byte  PUSH4,$A5,$00,$FC,$01,EXIT
06FD(002B) A5          | 
06FE(002B) 00          | 
06FF(002B) FC          | 
0700(002C) 01          | 
0701(002C) 03          | 
0702(002C)             | DEMO
0702(002C) B9          |         byte  PRTSTR,$0D,$0A,"TACHYON Forth V1.0 ",0
0703(002C) 0D          | 
0704(002D) 0A          | 
0705(002D) 54          | 
0706(002D) 41          | 
0707(002D) 43          | 
0708(002E) 48          | 
0709(002E) 59          | 
070A(002E) 4F          | 
070B(002E) 4E          | 
070C(002F) 20          | 
070D(002F) 46          | 
070E(002F) 6F          | 
070F(002F) 72          | 
0710(0030) 74          | 
0711(0030) 68          | 
0712(0030) 20          | 
0713(0030) 56          | 
0714(0031) 31          | 
0715(0031) 2E          | 
0716(0031) 30          | 
0717(0031) 20          | 
0718(0032) 00          | 
0719(0032) 77          |         byte  PUSH1,15,MASK,_8,MASK
071A(0032) 0F          | 
071B(0032) 4F          | 
071C(0033) 35          | 
071D(0033) 4F          | 
071E(0033) 96          |         byte  RCALL,@DO7-@MYCON
071F(0033) 24          | 
0720(0034) 09          | DO7     byte  DUP,RCALL,@DO8-@PRTLONG
0721(0034) 96          | 
0722(0034) 53          | 
0723(0034) 77          | DO8     byte  PUSH1,32,_REV
0724(0035) 20          | 
0725(0035) 4D          | 
0726(0035) 96          |         byte  RCALL,@DO5-@TXSPI
0727(0035) 30          | 
0728(0036) 2B          | DO5     byte  _0,PUSH2,$02,00,RCALL,@DO9-@DUMP
0729(0036) 76          | 
072A(0036) 02          | 
072B(0036) 00          | 
072C(0037) 96          | 
072D(0037) 55          | 
072E(0037) A0          | DO9     byte  _AGAIN,@DO6-@DEMO
072F(0037) 2E          | 
0730(0038)             | DO6

Please note too that Forth is only coded this way in the Spin compiler to form the kernel after which the Forth itself would handle normal text input for compiling which would look like this:

: TXSPI       32 CLKBITS ;
: MYCON       $A500FC01 ;       \ Could also be coded as: $A500FC01 CONSTANT MYCON
: DEMO
        begin
          cr ." TACHYON Forth V1.0 "            \
          15 MASK 8 MASK MYCON                  \ Assemble clockmask outmask and data for SPI
          DUP PRTLONG                           \ Let's see what is going to be sent
          32 REV                                \ Make it MSB first
          TXSPI                                 \ Off it goes
          0 $200 DUMP                            \ Hex dump of first 512 bytes of RAM
        again ;                                 \ Continue forever

So I'll try not to bore you any further with any details suffice to say that there are a lot of very neat things going on and planned. With the dictionary (names of functions and pointers etc) in external memory such as EEPROM and SD there will be a lot of program code that will be able to be squeezed into just a few k of RAM, count the bytes that are used in the demo! Some code will be available very soon now. (Hey Cluso, I hear it's going to rain all week )

[Cluso99]

Nice job Peter. May it rain a little more so you don't need to garden until finished

[Peter Jakacki]

Alright, after a few delays away from the project here and there due do the dear wife and her holiday projects I have reached a milestone with TACHYON. I am now able to run precompiled byte code successfully and have run some tests on various byte code routines. Afterwards I wrote an SPI output routine that manipulated the SPI bits individually and this ran at a speed of 82kHz with a clock high time of 1us. I compared this to the equivalent Spin routine which ran at 26.88kHz with a clock high time of 7.8us. Great, that's 3 times faster already for this kind of code. Next step was to code a simple primitive (6 PASM instructions) that clocked a single bit at a time and place that within a DO..LOOP to keep the code flexible and ran the tests. This time it ran at 625kHz with a clock high time of 50ns so that the CLKBIT primitive and the looping amounted to 1.6us per bit and 11 bytes for the SPI routine, that's pretty good I think. So the average execution speed of most byte codes is around 1us which is mainly limited by the RDBYTE access times.

I have a little tidying up to do (if I am not seconded to the garden project in the meantime) and I will build in the dictionary and high-level words that form the text interpreter (vs the byte code interpreter) so that I can work with this interactively in a terminal. At this stage I may release the source for the alpha which should be in the next week of so.

Another change I made was to the serial I/O and include the serial transmit code into the Forth cog and leave the serial receive to a dedicated cog. The transmit code is very small and doesn't have to worry about multi-tasking with any receive code etc. This way the receive timing can be very precise and run at 1,382,400 baud for the maximum speed of my Bluetooth modules. Also since the transmit speed is very high there is no need to buffer or waste time writing to hub RAM as each character completes transmission in 7.23us.

[prof_braino]

.. PropForth ... runs too slow at the Forth level ... PASM. ... lot easier and faster to recompile a new kernel with other objects.
... hook-up a monitor, keyboard and SD card and run the whole system stand-alone .
... patch in a Spin file, recompile the kernel and have it up and running just as quick.
... running larger programs ... 4M byte serial Flash chips or SD

I'm looking forward to your experimenting along these lines, your perspective and results will be interesting. We do have a way to "lock" the forth prompt so only the user level application words are available, and to eliminate the development extensions from the final application to save space, but we haven't worked on trimming down the kernel further, there is a lot of unexplored custom kernel development.

In the meantime, maybe look at the JupiterACE code from v3.6; this runs on the Prop Demo Board and is a stand alone forth with VGA and keyboard, 80 column text in hires, 40 column text in low res. This might be towards what you are looking for, it will be brought up to 5.0 kernel when the test automation is complete. You might be able to build on this, but Sal's version is still a couple weeks out. The JupiteACE was actually my goal for joining the project. V3.6 was the teaser, v5.3 may be the final result. Running VGA takes most of the resources of a prop chip, which lead us to the idea of just adding more props, which lead us to MCS and Go-channels. So the propforth development has been getting "bigger", if you find ways to get it "smaller" again, that will be really helpful.

Sal plans to simplify the process for optimizing in assembler, he will add new words that start and end the assembly process, and the assembler code can be compiled right into the dictionary. This could help in creating tachyon, but it may not ready until 5.4.

We looked at linking in arbitrary SPIN files, but that seemed to require the SPIN be written to support a "standard" interface, and we couldn't find anything to use as the standard; (every spin program seems to be too different) so we stopped that investigation. Maybe you can provide some insight or example of a specific spin file you want linked in, we can use that as a starting point for a "standard".

Sal's model supports adding more hub and cog memory in the form of more units of prop + SD, rather than adding more dedicated memory parts etc. For Sal's purposes, its easier and cheaper to just grab a couple more props out of the bin. In the case of the JupiteACE, it allows the full resource of oa prop to run the VGA, and permits a a full prop or more to be available to an application. But we have kept in the 32K memory mind set, it will be interesting to see what we gain will large external memory configurations.

I have a pile of HIVE boards (hive-project.de) that accept 1 meg x 8 bit SRAM. I was thinking of circuit bending these toward a propforth rig, but that is way down the road. In fact, you might want to check out the "m" language Ingo is working on over there. It appears to be a version of forth for the Hive hardware, and works with the hive OS running on the other chips (which might get you the "link in spin programs" function you seek). I don't know the details, but a bunch of it seems similar to your goals. Google translate does a fair job with the German, and Ingo and the Borg drones can do English.

[Peter Jakacki]

While I really like PropForth and the work that's been put into it the problem is that it runs too slow at the Forth level since very little is actually coded in directly executed PASM. I don't know if my Forth will measure up to the work that Sal and Prof Braino have put into theirs but it definitely will suit my needs. Plus it should be a lot easier and faster to recompile a new kernel with other objects. I'm a simple guy and I like to keep things simple. If I can't knock this TACHYON Forth over in a week or two then it's probably too complicated for me

One of my aims is to also have enough resources left over that I can hook-up a monitor, keyboard and SD card and run the whole system stand-alone if I have to. But mainly I find that I interface to a great variety of chips but I need more speed and I would like to stay within the normal Forth environment when doing that. Forth was after all designed to get at the bare metal in a transparent and interactive manner having first been employed on radio telescopes in the 70's. At the very most if necessary having to patch in a Spin file, recompile the kernel and have it up and running just as quick. Well, at least, that's my aim. Having efficient byte code means I can pack a large application program in and still have memory left over for video etc.

I hadn't looked at localroger's Windmill before but that's the basic idea I had before for running larger programs in that I would use those small 4M byte serial Flash chips I have on some boards or else SD but it's still a lot more cumbersome than running from hub RAM. Running interpreted code from serial memory is an old idea, I remember the TSS400 for one. It's interesting to see that he is thinking of a scheme to encode PASM. But what has happened to Windmill since? Has he charged at it a bit too quixotically?

[Cluso99]

Nice work Peter. I don't have time to analyse what you've done and I have never looked at Forth.

As Prof says, another version is great, and ideas can be shared, making each version better than before. Good ideas will find their way into other code too.

Prof & Sal: I am sure the test automation suite will be great once things settle. Hopefully it should even find its way into normal code too.

[prof_braino]

WOW. You rock! A new forth on the prop. Next thing you know Cliffe Biffle will release his source. Are there now more versions of forth than C for the prop? We make catch up to basic yet!

I look forward to (attempting) assimilating all your best ideas! Especially those that yield more run time speed without assembler. You got some neat stuff going on. Can you borrow from localroger's work?

When your design starts to get stable, consider using the test automation so the workstation runs a regression test suite after every development change is "done". Sal says there is no reason the automation would not work with any language, I would like to find evidence one way or the other. I'd like to help set it up.

@richaj45: The biggest advantage is getting the perspective of a different approach. Sal's way is deemed the best by Sal to do what Sal wants to do, and does not necessarily lend itself to what Peter wants to do or the way Peter wants to do it. "Right tool for the right job". Its almost guaranteed that Peter will find a better way to do what Peter wants to do, since he does not have the same constraints. Often, we will find a new perspective in the way one does something that improves the other. This effect might not be limited to forth kernel development . I heard of some guy Darwin that made some notes about exploiting niches, but he has not posted anything in the OBEX.

[Peter Jakacki]

If you want to separate between $00-BF and $C0-$FF shouldn't the test/jmp pair be a cmp/jmp (less than)? Currently anything above $3F produces !Z. Or are your tokens inverted somewhere? Do I need more coffee?

We all need more coffee and we don't need an excuse. The code was all mish-mashed by some major upheavals when I posted this about 3:30AM in the morning (or at night from my pont of view) and I spotted it this morning and changed it to if_z instead but still wrong Oh look! time for a coffee! The original just tested the msb so the reason for "test" instead of "cmp". Anyway I thought I would leave the post without corrections as it serves it's purpose and I will find out if anyone is analyzing it (which you did 30 minutes later).

I had changed the point at which byte tokens are either used as a direct 9-bit address into the cog's PASM code or as an index into a jump table to byte code. Somehow it looked right when I did it. Sometimes I aim for "close enough is good enough" as I know I will come back and if it's still there in that I haven't changed it all again then I will make it right (or just crumple it up and toss it into the trash).

[kuroneko]

doNEXT                  rdbyte  token,IP                'read byte code instruction
                        add     IP,#1                   'advance IP to next byte token
                        shl     token,#1                'expand to 9-bits - all byte codes point to code on double-long boundary
                        test    token,#$180 wz          'tokens $C0..$FF are calls to kernel byte code via kbctbl
               if_nz    jmp     token                   'directly execute PASM byte codes without further ado

If you want to separate between $00-BF and $C0-$FF shouldn't the test/jmp pair be a cmp/jmp (less than^A)? Currently anything above $3F produces !Z. Or are your tokens inverted somewhere? Do I need more coffee?

^A or greater equal depending on when you do the jump

[richaj45]

Hello:

I am curious as to what the advantage of developing another Forth when PropForth looks very complete?

That is besides the need to learn by doing, which i understand completely.

cheers,
rich

[mindrobots]

Peter, Excellent!!

Tachyon is a perfect name for it since Forth is often considered a hypothetical language that may or may not exist.

I look forward to taking this out for a cruise!

[ericball]

Hi Peter,

Sounds cool. Did you read localroger's Windmill blogs? It's a Forth-like bytecode interpreter designed to run out of SPI EEPROM. I'd recommend checking out http://forums.parallax.com/entry.php...de-Interpreter where he talks about mapping bytecodes to PASM instructions.

[Peter Jakacki]

INTRODUCTION: Click here to go to the "INTRODUCTION to TACHYON web page" with examples and links to the source code files and binaries etc
VIDEOS: Enhanced bitmap graphics demo + serial

Original post:

---

I've been hooked onto Forth again after a long break away. Thanks to Sal's PropForth and recently the Bluetooth modules I have rediscovered the advantages and fun of programming and testing in a Forth environment. Now I mentioned I have been away from Forth for awhile and that's got to do with the Propeller chip since I like using it but Forth does not lend itself to this architecture very easily. Several years ago (time flies) I had a look at writing a Forth call CogForth for the Prop but I just felt it was too much hard work, which it was, not just because of the architecture but also because of the limitations of the tools (Spin tool etc). Even so the Forth would have been slow for what I need and there were memory limitations.

However, spurred on by the efforts of Sal Sanci and Prop Braino I have taken another look at my old CogForth since I needed amongst other things more runtime speed without having to resort to assembler. So over the last couple of days CogForth has been completely revamped and I think I'm on a winner with this implementation. It is both fast and very small thanks to the byte codes for each Forth VM operation. Like a tachyon, it is fast and very small (as a hypothetical particle anyway) with emphasis on fast I/O operations and maximizing the Propeller's memory. What would some byte code look like? Have a look at this function which prints a hex character:

0534(001C)             | PRTHEX  ' ( n -- ) print n (0..$0F) as a hex character
0534(001C) 2D          |         byte  CLIT/2,$30,PLUS/2
0535(001C) 30          | 
0536(001C) 0C          | 
0537(001C) 05          |         byte  DUP/2,CLIT/2,$39,GT/2,_IF/2,3
0538(001D) 2D          | 
0539(001D) 39          | 
053A(001D) 20          | 
053B(001D) 3E          | 
053C(001E) 03          | 
053D(001E) 2D          |         byte  CLIT/2,12,PLUS/2                      'Adjust for A..F
053E(001E) 0C          | 
053F(001E) 0C          | 
0540(001F) 49          | PRTCH   byte  EMIT/2,EXIT/2
0541(001F) 00          |

EDIT: Byte codes mush be shifted one bit right to compress 9-bits, the lsb is always zero as all byte code functions are on double-long boundaries.

So you see this function takes 14 bytes and compare this to Spin which also uses byte codes:

88                        char+=$30
Addr : 05B0:          38 30  : Constant 1 Bytes - 30 - $00000030 48
Addr : 05B2:          66 4C  : Variable Operation Local Offset - 1 Assign WordMathop +
89                        if char > $39
Addr : 05B4:             64  : Variable Operation Local Offset - 1 Read
Addr : 05B5:          38 39  : Constant 1 Bytes - 39 - $00000039 57
Addr : 05B7:             FA  : Math Op >     
Addr : 05B8: JZ Label0002
Addr : 05B8:          0A 04  : jz Address = 05BE 4
90                          char+=12
Addr : 05BA:          38 0C  : Constant 1 Bytes - 0C - $0000000C 12
Addr : 05BC:          66 4C  : Variable Operation Local Offset - 1 Assign WordMathop +
Addr : 05BE: Label0002
Addr : 05BE: Label0003
91                        coms.tx(char)
Addr : 05BE:             01  : Drop Anchor   
Addr : 05BF:             64  : Variable Operation Local Offset - 1 Read
Addr : 05C0:       06 03 0B  : Call Obj.Sub 3 11
Addr : 05C3:             32  : Return

The dictionary of Forth words which is very useful for development and debugging purposes is not really necessary for run-time operation and if stripped from hub RAM would free up a lot of space. So what I did is to load the dictionary as a separate file and hold that in some available space in EEPROM or even SD memory. Now this would make it rather slow to search the dictionary when it is compiling source code so I have optimized this so that it only has to spend a fraction of the time it normally would to find a word in the dictionary by linking all words together with the same first character and using a table to point to the first (last) instance of that word. So searching the dictionary is reduced to looking at only those entries that match the first character. The worst case results in only part of the dictionary being searched rather than the whole.

The runtime speed is mainly because many of the primitives are written in assembly and stacks are implemented that are more suited for the Prop's architecture permitting direct addressing, just like a register. So many of the primitives get the job done with very very few instructions and even the runtime interpreter is lean and mean. A byte code is read from hub RAM and shifted up to 9-bits which the Prop jumps to in COG memory, so it's very direct. The runtime interpreter looks like this:

doNEXT                  rdbyte  token,IP                'read byte code instruction
                        add     IP,#1                   'advance IP to next byte token
                        shl     token,#1                'expand to 9-bits - all byte codes point to code on double-long boundary
                        cmp    token,#$180 wc          'tokens $C0..$FF are calls to kernel byte code via kbctbl
               if_c     jmp     token                   'directly execute PASM byte codes without further ado

EDIT: Fixed a bug when testing for PASM for extended byte code functions.

There's a test for byte codes from $C0..$FF which doesn't really impact the speedy operation of the assembly primitves which are indexed by codes $00..$BF. The reason I reserve some codes is that there is no way you could use all the 256 codes for assembly primitives so I used some to form a very compact way of accessing up to 64 more words (functions) which instead of being assembly code are instead interpreted byte codes. All byte code functions other than these special 64 are referenced with 2 or 3 bytes one of which is the byte code and the other 1 or 2 bytes are a relative address poining back to the word function. The one byte CALL gets straight into 1 of 64 higher-level functions which are themselves comprised of byte codes which eventually execute assembly code via the first 192 byte codes $00..$BF.

Anyway, I'm developing and testing and the beta will be ready very soon but I thought I would present some details of the workings of this Forth implementation as I am also looking for feedback. Perhaps also someone could suggest an easier way around the Spin/BST compiler limitations especially with DAT sections and references which the compiler insists must be on long boundaries. Anyway, I want the references to be absolute in hub RAM rather than as if it were PASM running in a COG. Also, I am making it far easier to interface to various chips by having low-level code for serial operations and making all the byte code operations fast, especially serial operations. I'm even thinking of making it as easy to use as the Basic Stamp. For instance, there's something in being able to send and receive serial data on any pin at any time (without starting up a cog). So too all those pin high and pin low and clocking operations etc. I want to be able to hook-up an I2C or SPI'ish chip and bit-bash to it at least in the 100kHz range if not more (without resorting to PASM in a COG).

This is my header file and some code snippets for the moment.


TACHYON

A very fast and very small Forth byte code interpreter for the Propeller chip.
2012 Peter Jakacki

Features:
- Low level words are written in PASM and accessed by the
Forth run-time interpreter as single byte codes.
Byte codes are read from hub RAM and executed in PASM
Byte codes $00..$BF are PASM primitives expaned to 9-bits to directly address COG code
Byte codes $C0..$FF are calls to kernel byte code defs via table in hub RAM

- Support for LMM operations
- Interpreted byte code definitions are referenced either as:
- 1 byte - codes $C0..$FF index their definitions via a table - used as part of compiled kernel
- 2 bytes - RCALL opcode + relative byte (always referenced backwards) (extra 4 bits in opcode = -4096 range)
There are 16 entires in the COG for the RCALL byte code + extra address bits
- 3 bytes - WCALL byte code + 16-bit relative address
- All literals and strings are byte aligned
- Fast I/O bit-bashing support
- Flexible SPI PASM code support words in kernel
Constuct fast serial drivers with minimal code


- Holds Forth headers in EEPROM or SD storage
Searches the dictionary using rapid index key searching by first character
No hub RAM is used by headers
Even 32K EEPROMs can be used if the area is in RAM is normally rewritten (i.e. video memory)
Option to hold additional information per defintion such as stack usage and description

- Kernel compiled in standard manner via Spin tools so other Spin objects can be combined

- Three stacks in COG RAM: Data, Return, and Loop
Access loop indices outside of definitions
Avoids manipulation and corruption of return stack
Static stack arrays for direct addressing of stack items
Intrinsically safe stack overflow and underflow

Some early unoptimized observations:
- Empty loops can execute in 500ns to 825ns (absolute worst case)
Two to one stack operations ( + * AND etc) inc opcode fetch take 900ns to 1.087us (absolute worse case)

  
' Fetch the next byte code instruction pointed to by the instruction pointer IP in hub RAM
'
doNEXT                  rdbyte  token,IP                'read byte code instruction
                        add     IP,#1                   'advance IP to next byte token
                        shl     token,#1                'expand to 9-bits - all byte codes point to code on double-long boundary
                        cmp    token,#$180 wc          'tokens $C0..$FF are calls to kernel byte code via kbctbl
               if_c     jmp     token                   'directly execute PASM byte codes without further ado
                                                        ' byte codes $C0..$FF point to further byte code definitions
                            ' which are larger fragments of byte code in hub RAM
                        call    #SAVEIP                 'save current IP in prep for a call
                        add     X,kbcptr                'kbcptr points to the kernel byte code table (less $180)
                        rdword  IP,X                    'read 16-bit address from hub kbc table into IP
                        jmp     #doNEXT                 'Execute the code
  
  
' Example of PASM code entries for Byte Code indexing on double-long boundaries
'   
DROP2                   call    #POPX
                        jmp     #DROP
DUP                     mov     X,tos                   ' Read directly from the top of the data stack
                        jmp     #PUSHX                  ' Push X onto the data stack and doNEXT              '
OVER                    mov     X,tos+1                 'read second data item and push
                        jmp     #PUSHX
NIP                     mov     tos+1,tos               'replace second item with top and drop
                        jmp     #DROP

LIT0                    mov     X,#0
                        jmp     #PUSHX
LIT1                    mov     X,#1
                        jmp     #PUSHX

'****************** BOOLEAN ******************
_AND                    movi    _POPEX,#1000_001    ' AND ( n1 n2 -- n3 )
                        jmp     #POPEX                  'discard top of stack and execute modified PASM
_OR                     movi    _POPEX,#1010_001
                        jmp     #POPEX
_XOR                    movi    _POPEX,#1011_001
                        jmp     #POPEX

'***************** MEMORY *******************
CFETCH                  rdbyte  tos,tos        ' read byte pointed to by tos into tos
                        jmp     #doNEXT    
CPLUSST                 rdbyte  X,tos           ' read in byte from adress
                        add     tos+1,X         ' add second item to contents of address 
CSTORE                  wrbyte  tos+1,tos       ' write the second item using address on the tos
                        jmp     #DROP2


' Example of interpreted byte codes in hub RAM
' References to other byte code defintions is relative which is also necessary because of the Spin compiler's limitations with DAT sections
'
0530(001B) 06          | _BOUNDS byte  OVER/2,PLUS/2,SWAP/2,EXIT/2
0531(001B) 0C          | 
0532(001B) 08          | 
0533(001B) 00          | 
0534(001C)             | PRTHEX  ' ( n -- ) print n (0..$0F) as a hex character
0534(001C) 2D          |         byte  CLIT/2,$30,PLUS/2
0535(001C) 30          | 
0536(001C) 0C          | 
0537(001C) 05          |         byte  DUP/2,CLIT/2,$39,GT/2,_IF/2,3
0538(001D) 2D          | 
0539(001D) 39          | 
053A(001D) 20          | 
053B(001D) 3E          | 
053C(001E) 03          | 
053D(001E) 2D          |         byte  CLIT/2,12,PLUS/2                      'Adjust for A..F
053E(001E) 0C          | 
053F(001E) 0C          | 
0540(001F) 49          | PRTCH   byte  EMIT/2,EXIT/2
0541(001F) 00          | 
0542(001F)             | PRTBYTE
0542(001F) 05          |         byte  DUP/2,CLIT/2,4,_SHR/2
0543(001F) 2D          | 
0544(0020) 04          | 
0545(0020) 1A          | 
0546(0020) 3B          |         byte  RCALL/2,20 '-->PRTHEX                  'Due to limitations of Spin tool & BST this needs to be calculated by hand
0547(0020) 14          | 
0548(0021) 3B          |         byte  RCALL/2,22
0549(0021) 16          | 
054A(0021) 00          |         byte  EXIT/2

EDIT: Fixed byte code references which are encoded as 8-bits using cogaddress/2