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 100 — Parallax Forums

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

19798100102103109

Comments

  • Cluso99 .. Is the tri-state SDA between ! @ actions or when the bus is really waiting after I2CSTOP? I was using Tim Moore's model of bus activity.
    My boards from Parallax have the pull ups on both.
    There really should be a time-out trap on the stretching code...
  • Cluso99Cluso99 Posts: 18,066
    edited 2016-09-06 14:37
    I was referring to the ROM BOOT code in the P1 that makes CLK an output, rather than driving the CLK as an Open Drain. Neither matters unless there is no pull-up on the CLK line. Even so, quite often the CLK line will be driven while talking with an I2C device.

    Provided SDA is not switching, most likely any pulses (spikes) on CLK will not cause problems. It is just bad practice.
  • D.PD.P Posts: 790
    edited 2016-09-06 21:25
    Cluso99 wrote: »
    I was referring to the ROM BOOT code in the P1 that makes CLK an output, rather than driving the CLK as an Open Drain. Neither matters unless there is no pull-up on the CLK line. Even so, quite often the CLK line will be driven while talking with an I2C device.

    Provided SDA is not switching, most likely any pulses (spikes) on CLK will not cause problems. It is just bad practice.

    Well a case in point to this I2C mash up is the DLVR-L30Dxxxx from All Sensors. I wrote a custom "write address" sequence to the chip because it requires certain SDA and SCL states to initialize. I had to move this thing to its own bus pins because it seemed to be clobbering the DS3232 on the bus. Then Peter showed me that I could use the normal Tachyon I2C read instructions for the rest. And he found a bug of course that I am still smarting about myself, "don't ack the last read".

    @PaulR Also I'll repeat if there is arduino code to look at see if they are using wire.h to talk to the chip or if they have a custom library.

  • MJBMJB Posts: 1,235
    TaTa ... we are at page 100

    congrats Peter
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-09-07 02:14
    MJB wrote: »
    TaTa ... we are at page 100

    congrats Peter

    To put this into perspective, if the Prop2 ROM code thread goes on for much longer at this rate it will catch up soon! I woke up this morning and in the space of less than 7 hours there were 42 new posts! I know how to make the SD boot code fast and lean but with 16k of boot ROM an interactive Tachyon environment could be had, even without Flash or SD. Jupiter Ace here we come.

    At almost 3,000 replies and 300,000 views and 100 pages I keep thinking whether to start up a new thread but there wouldn't be any real advantage to it plus any year soon a lot more emphasis would be placed on the P2 version. Now proplem mentioned a while back about celebrating with a drink but I couldn't put my glass down to respond :)

    How are we going with editing the intro page? What changes and additions do we need to make?

    BTW - I've left my P2 connected to the Internet with mainly FTP on port 21 but also with Telnet on port 10001 and basic web server on port 81 except that is unreachable at the moment until I change some settings.

  • D.PD.P Posts: 790
    edited 2016-09-07 03:48
    I've been delinquent on the Intro page, trying to wrap up GardenControl.fth with a FONA GSM module. Something changed between 2.4 and 3.0 ( you don't say ) that my test code I wrote in 2015 compiles on 3.0 but just doesn't run. No worries gonna get the parsing of the AT style command syntax finished in 2.4, and work on the Intro :)
    Then port to Juno.

    Praying for P2 open firmware, also I've been grep'n the P2 folder for CONNECT, hmm. I've got a BE Micro if you care to point to the latest P2 Tachyon with CONNECT so I can work with rs485. And I see the beginnings of the P2 pin mode instructions laid out in one file. If they are as easy as the timers are to use in Tachyon then they we be accessible to mere mortals such as myself.
    1+ for the ROM thread :)

    And some FONA output for the curious
     Propeller .:.:--TACHYON--:.:. Forth V24150105.2330
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V24150105.2330
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $5A14...74B6 for 6,818 bytes (+16)
    CODE:   $0924...3D32 for 13,326 bytes (+60)
    CALLS:  370 vectors free
    RAM:    7,394 bytes free
    BOOTS:  5
    BOOT:   EXTEND.boot
    POLL:   
    
    MODULES LOADED: 
    3A3B: fonatest.fth        FONA Test V0.3 dp  20151229-2200 
    1A00: EXTEND.fth          Primary extensions to TACHYON kernel - 150116-1700
    
    BOOT:   EXTEND.boot
    POLL:   
    
    ----------------------------------------------------------------
    gofona  ok
    .TASKS 
    0000: CONSOLE                         0000 00 00 00 00 00 00 
    0002: RS232.TASK                      3B48 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                       34CE 01 00 00 00 00 00  ok
    crst  ok
    
    OK
    cinf  ok
    ATI
    SIM800 R13.08
    
    OK
    cdev  ok
    AT&V
    DEFAULT PROFILE
    S0: 0
    S3: 13
    S4:G: 0
    +CGREG: 0
    +CMEE: 0
    +CSCLK: 0
    +CIUAAS: 1
    +CBUZZERRING: 0
    +DDET: 0
    +MORINSD2PCM: 1
    +IPR: 0
    +IFC: 0,0
    E: 0: 3,3
    Q: 0
    X: 4
    &C: 1
    &D: 1
    +CLTS: 0
    
    +CSCS: "IRA"
    +VTD: 1
    +CALS: 1
    +CHF: 0000,300
    +CSDT: 0
    +CSMINS: 0
    +EXUNSOL: 10: 15
    +CBST: 7,0,1
    +CRLP: 61,61,48,6
     0,0,10
    +STKPCIS: 0
    +CMGF: 1
    +CNMI: 2,1
              +CSGS: 1
    +CNETLIGHT: 1
    +SLEDS: 64,64,64,800,3000,300
    +CSDT: 0
    +CSMINS: 0
    +EXUNSOL: 0
    +SD2PCM: 1
    +IPR: 0
    +IFC: 0,0
    +ICF: 3,3
    +CMNRP: 0
    
    OK
    clal  ok
    AT+CMGL=4
    OK
    
    +CMGL: 1,1,"",150
    07914150740250F54403CEDE9BD960B59A8D0693CD00F6F6DC55769F5DF456
    +CMGL: 2,1,"",23
    07914150740250F5040B913106535957F40001,"",28
    07914150740250F5040B913106535957F4000051
    
    +CMGL: 6,1,"",29
    07914150740250F5040B913106535957F400006190402190938A0BC2F0780D0AD341F9771D
    
    OK
    

  • @D.P. Use CHAT in P2's EXTEND to chat on the ping-pong network. The P1 basically needs a cog running a serial receive as there is no easy way to get the Prop to handle high-speed serial and still timeout if nothing arrives. I will look at this tomorrow perhaps.

    Imagine that, we could have a bare P2 that boots into an interactive Forth shell.... :)
  • If I BACKUP a Tachyon system, are all in-memory arrays stored to EEPROM then reloaded at next boot?
  • @D.P. Use CHAT in P2's EXTEND to chat on the ping-pong network. The P1 basically needs a cog running a serial receive as there is no easy way to get the Prop to handle high-speed serial and still timeout if nothing arrives. I will look at this tomorrow perhaps.

    Imagine that, we could have a bare P2 that boots into an interactive Forth shell.... :)

    Yes, I use a cog to RX cmds from the FONA (TE) right now as directed by you long ago in another project. Works great but I'm always stumped as the best way to handle parsing a protocol. For instance this arrives in the RS232 buffer:
    +CMTI: "SM",7      --- +CMTI: "SM"   = new sms message indicator ,7  = index of new message
    
    One approach I've seen is Create words that provide logic and then process accordingly.
    The darn space and comma are always a challenge for me to directly parse still in Tachyon, I keep stumbling in IF THEN hell it seems, onward.
    +CMTI: 
    "SM"
    


  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-09-07 06:00
    @D.P. Have you tried setting the delimiter to a comma? See AVAR in EXTEND for an example of this. That way your message would come back as
    +CMTI: "SM" 7
    to which I would define "SM" perhaps as a constant and +CMTI: as a deferred execution word so that at the end of the line it will execute its deferred word with two parameters, the constant for "SM" and location 7.

    +CMTI: pushes a vector onto a deferred execution stack and your ATCOMS word which is automatically executed before the next line with ' ATCOMS prompt W! can read that stack and call the vector, nice and simple.

    EDIT: coming to think of it I have a substitution table for the control keys built into JUNO so I think if I extended it for all 128 codes it could simply substitute a space for a comma etc. Along with deferred execution this is another solution. Even the " codes could be replaced with a space.
  • D.PD.P Posts: 790
    edited 2016-09-09 06:47
    @D.P. Have you tried setting the delimiter to a comma? See AVAR in EXTEND for an example of this. That way your message would come back as
    +CMTI: "SM" 7
    to which I would define "SM" perhaps as a constant and +CMTI: as a deferred execution word so that at the end of the line it will execute its deferred word with two parameters, the constant for "SM" and location 7.

    +CMTI: pushes a vector onto a deferred execution stack and your ATCOMS word which is automatically executed before the next line with ' ATCOMS prompt W! can read that stack and call the vector, nice and simple.

    EDIT: coming to think of it I have a substitution table for the control keys built into JUNO so I think if I extended it for all 128 codes it could simply substitute a space for a comma etc. Along with deferred execution this is another solution. Even the " codes could be replaced with a space.

    EDIT: found the error 09/08 never mind
  • Cluso99Cluso99 Posts: 18,066
    Peter,
    Congrats on reaching 100 pages.

    Thankfully the forum software didn't croak ;)
  • Just felt the need to post something here after reading 47 new posts on the P2 ROM thread. 100 pages won't last long >HERE< at that rate :)
  • In the current posted EXTEND.fth from 4 days ago needs this line moved to 2791, above the ".TIMERS" word.
    I'm updating a copy of the Intro and found this little error generating new output.
    LONG	runtime           --- this is define in RTC at 2845, needs to be here or above 
    
    IFDEF EXPLORER
    \ List the timers and their status
    pub .TIMERS
          SPACE CLKFREQ ttint / ." ticks = 1/" 0 PRINTDEC
          ."  runtime = " runtime @ 0 PRINTDEC
     	timers W@
     	BEGIN
     	  DUP $FF >
     	WHILE
     	  CR DUP .WORD 	  ." : "
     	  DUP 1- >NAME DUP PRINT$ LEN$ #20 SWAP - SPACES
     	  DUP @ 6 PRINTDEC ." ms "
     	  ." =" DUP @ .LONG
     	  ."  L" DUP 6 + W@ .WORD
     	  SPACE DUP 4 + W@ IF ." ALARM=" DUP 4 + W@ >NAME PRINT$ THEN
     	  6 + W@ --- fetch the link to the next timer
     	REPEAT
     	DROP
     	;
    
        }
    
    
    

  • MJB wrote: »
    TaTa ... we are at page 100

    congrats Peter

    ... mentioned a while back about celebrating with a drink but I couldn't put my glass down to respond :)

    Hi Tachyonista - wow again you have been eager and reached 100 pages (i'm back from holidays). I will rise a cup of coffee on 'Tachyon P1 100 pages' at Sunday Sep. 11, 08:00 GMT this should be 17:00 in Brisbane. Meet you ...
  • Congratulations - 100 pages
    2048 x 1536 - 936K
  • If I do this from the console or within a routine, does it free the memory as well as remove the dictionary entry ?
    10 WORDS inbuff
    < use inbuff somehow >
    FORGET inbuff
    
  • If I do this from the console or within a routine, does it free the memory as well as remove the dictionary entry ?
    10 WORDS inbuff
    < use inbuff somehow >
    FORGET inbuff
    

    The memory for inbuff is allocated in code memory so when you forget inbuff it will restore code space and dictionary to what it was prior to inbuff being created.
    .STATS 
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    CE1372 WIDGET (1372)
    FREQ:   80MHZ (PLLEN OSCEN XTAL1  PLL8X )
    NAMES:  $71B0...74DC for 812 bytes (4,294,967,051)
    CODE:   $0930...4E4B for 17,691 bytes (4,294,966,635)
    RAM:    9,061 bytes free
    BUILD:  FIRMWARE BUILD DATE 160830:024812   BOOTS:  94   runtime 118,456
    BOOT:    ok
    10 WORDS inbuff  ok
    inbuff 10 ADO I I C! LOOP  ok
    inbuff 10 DUMP 
    0000_4E4C:   4C 4D 4E 4F  50 51 52 53   54 55 00 00  00 00 00 00   LMNOPQRSTU...... ok
    .STATS 
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    CE1372 WIDGET (1372)
    FREQ:   80MHZ (PLLEN OSCEN XTAL1  PLL8X )
    NAMES:  $71A6...74DC for 822 bytes (4,294,967,061)
    CODE:   $0930...4E60 for 17,712 bytes (4,294,966,656)
    RAM:    9,030 bytes free
    BUILD:  FIRMWARE BUILD DATE 160830:024812   BOOTS:  94   runtime 170,490
    BOOT:    ok
    FORGET inbuff  ok
    .STATS 
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    CE1372 WIDGET (1372)
    FREQ:   80MHZ (PLLEN OSCEN XTAL1  PLL8X )
    NAMES:  $71B0...74DC for 812 bytes (4,294,967,051)
    CODE:   $0930...4E4B for 17,691 bytes (4,294,966,635)
    RAM:    9,061 bytes free
    BUILD:  FIRMWARE BUILD DATE 160830:024812   BOOTS:  94   runtime 177,457
    BOOT:    ok
    
    

  • Absolutely genius. Thanks Peter!

    Do people routinely do this kind of allocation/deallocation in Forth code, or is it a cheat for those of us who haven't got it yet?

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-09-13 15:44
    Absolutely genius. Thanks Peter!

    Do people routinely do this kind of allocation/deallocation in Forth code, or is it a cheat for those of us who haven't got it yet?

    FORGET can be used dynamically too, have a look at the end of EXTEND and you will see the definitions SELRTC and SAVEROMS, both of which are executed as soon as they are defined after which they have served their purpose and are forgotten.

  • Neat! I hadn't thought of wiping out code on the fly ... :)
  • Are there descriptions available on how to use the ROMS available in v3? I am thinking about HSSERIAL ... Thanks!
  • Are there descriptions available on how to use the ROMS available in v3? I am thinking about HSSERIAL ... Thanks!

    The general form of loading a cog is straightforward enough, it is:
    <parameter pointer> cog <ROM name (8 characters)> LOADCOG
    So for F32 it is:
    f32cmd 3 " F32 " LOADCOG

    However I have been meaning to get around to writing some Forth code that interfaces to these ROMS although I had started to test F32. There isn't much required to get the serial to work though and I may have a look at it shortly.
  • Thanks Peter. It is an interesting mechanism. I've activated SERIN/SEROUT (Module 13) until then.
    Cheers!
  • If its not one question, its another ...

    Is it possible to launch a cog to run an independent interactive Tachyon front end, with its own serial in and out lines? I could launch a cog that keeps running SERIN and executing code based on keystrokes, but that is already built in ...
  • If its not one question, its another ...

    Is it possible to launch a cog to run an independent interactive Tachyon front end, with its own serial in and out lines? I could launch a cog that keeps running SERIN and executing code based on keystrokes, but that is already built in ...

    The Tachyon kernel is loaded up into all the spare cogs and normally are just running an IDLE loop awaiting something to RUN. So you could assign some extra stack space for a cog and point it to CONSOLE but that really needs its own task registers for word and number buffers etc, up to about 164 bytes which you can assign via the TASKREGS word. But I've never had a need for it, it's not like it's the old days of multiuser minicomputers but now it is more like none or one user and multicores :)

    Normally a RUN task is setup for for SERIN buffering although one of the serial ROM objects could probably be used, even the 4-port full-duplex one which is my intention, when I get a round tuit that is!
  • Jerry Pournelle's rule ... at least one processor per person :)
    You've described my situation ... the prop is watching a 4x4-keypad, an RF button device, the normal console, and a GPS, plus an IMU. OK, time to write parsers ...
  • Configure a timer to scan the keypad and buffer it. Use a CONSOLE cog for the GPS and comma delimiters and deferred action via "prompt" to greatly simplify the task of parsing those strings. Then consider just using keypoll via a +POLL to check the RF button and perhaps the IMU.
  • Good ideas all, but the keypad is an asynch source mounted to a handset LCD. I like the RF in a poll, but will have to revise the code (now it sits and waits then times the duration, different key down time give different actions). I saw the GPS code you posted some time back, and will probably steal some of that.
    Thanks!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-09-29 12:50
    I had a thought today about a technique that I sometimes use for handling infix operations as in parsing GPS strings and even inline assembly. Basically what I do now is when a word has conventional infix operations is that I execute the word first which then sets up a deferred function to be executed at the end of the line. So for instance take this GPS string:
    GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47
    
    the auxiliary delimiter is set to a comma so that commas effectively become spaces and any number encountered will simply be processed and pushed onto the stack but the problem is the control word or function here is GPGGA which executes before any of the numbers are stacked. What I typically do is get to change the end of line action by pointing to a new function to execute at the end of line via the "prompt" vector.

    Now I was thinking that I could have this built in all the time simply by adding an execution stack where deferred functions are executed automatically at the end of the line but also add a new building word called DEFER that is used in a definition when there is code that will not be executed immediately. With comma delimiters the GPS string would reduce to:
    GPGGA 123519 4807.038 N 01131.000 E 1 08 0.9 545.4 M 46.9 M  *47
    
    where GPGGA is executed immediately as:
    pub GPGGA IMMEDIATE
    	DECIMAL ' ?GPS unum W!
    	DEFER &GPGGA horz ! sats ! fix ! utc ! 
    	;
    
    where the code after DEFER is only executed at the end of the line. In fact the pointer to this code is pushed onto an execution stack which will automatically be called at the end of every line. Seeing though that defer is already a Forth word that is sometimes used in some Forths I will have to call it something different and then I might just implement that "DEFER" and "IS" definition while I'm at it.

    So I'm testing this out in V3.1 and I might even manage to squeeze in CREATE DOES> as well while I am playing with these building words but if you can think of any features or ideas related to this then let me know as I may incorporate them at the same time.

    btw, the GPS parsing is simply just letting Forth do it's thing with a little help. I've posted code similar to this ages ago and N S E W and M for instance grab values immediately while the remainder of the string is finally processed by the deferred GPGGA code.

Sign In or Register to comment.