Shop OBEX P1 Docs P2 Docs Learn Events
TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++ - Page 45 — Parallax Forums

TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++

14243454748109

Comments

  • max72max72 Posts: 1,155
    edited 2014-03-25 00:49
    So we almost have an NMEA parser... :-)
    Great stuff.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-25 03:03
    max72 wrote: »
    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):
    [FONT=courier new]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
    [B]GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47[/B]  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
    
    [/FONT]
    

    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:
    [FONT=courier new]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
    }
    [/FONT]
    
  • max72max72 Posts: 1,155
    edited 2014-03-25 04:00
    Thanks!
    Great stuff...
    Massimo
  • KeithEKeithE Posts: 957
    edited 2014-03-25 15:41
    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?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-25 16:38
    KeithE wrote: »
    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.
  • artkennedyartkennedy Posts: 174
    edited 2014-03-26 17:31
    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 JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-26 18:08
    artkennedy wrote: »
    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?
    [FONT=courier new]: 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
    [/FONT]
    
  • D.PD.P Posts: 790
    edited 2014-03-26 19:57
    That's good, it looks like there is a lot of common functionality being duplicated there though. How about this?
    [FONT=courier new]: 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
    [/FONT]
    

    Page 67 of this thread causes my head to hurt in a great way.

    thanks peter
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-26 20:29
    D.P wrote: »
    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?
  • ChameleonChameleon Posts: 14
    edited 2014-03-26 22:56
    max72 wrote: »
    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.
  • artkennedyartkennedy Posts: 174
    edited 2014-03-26 23:17
    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.
  • artkennedyartkennedy Posts: 174
    edited 2014-03-26 23:19
    You can count me in :tongue: ( for the good headache brigade ).
  • D.PD.P Posts: 790
    edited 2014-03-27 00:10
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-27 00:38
    artkennedy wrote: »
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-27 00:54
    D.P wrote: »
    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.
    [FONT=courier new]
    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
        ;
    [/FONT]
    

    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.
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-03-28 09:55
    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.
  • D.PD.P Posts: 790
    edited 2014-03-28 12:02
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-28 16:38
    D.P wrote: »
    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".
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-28 18:15
    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.
  • ChameleonChameleon Posts: 14
    edited 2014-03-28 19:16
    D.P wrote: »
    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).
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2014-03-28 22:07
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-03-29 01:34
    Chameleon wrote: »
    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.
  • D.PD.P Posts: 790
    edited 2014-03-29 13:48
    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?
  • ChameleonChameleon Posts: 14
    edited 2014-03-29 16:53
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-04-03 18:13
    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:
    [FONT=courier new]pub FRUN word FOPEN$ IF FINPUT THEN ;  ok
      ok
    ' FRUN unum W!  ok
      ok
    [B]TASKS[/B]  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
    [/FONT]
    
    and so with MAP which is only ever used from the console rarely:
    [B]MAP[/B]  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>.
  • D.PD.P Posts: 790
    edited 2014-04-05 13:47
    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:
    [FONT=courier new]pub FRUN word FOPEN$ IF FINPUT THEN ;  ok
      ok
    ' FRUN unum W!  ok
      ok
    [B]TASKS[/B]  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
    [/FONT]
    
    and so with MAP which is only ever used from the console rarely:
    [B]MAP[/B]  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
  • D.PD.P Posts: 790
    edited 2014-04-08 23:58
    Looking for AD7993 A2D IC (PBOE) Tachyon words?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-04-09 00:52
    D.P wrote: »
    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.PD.P Posts: 790
    edited 2014-04-09 10:53
    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.
  • richaj45richaj45 Posts: 179
    edited 2014-04-09 18:43
    @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
Sign In or Register to comment.