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

1959698100101109

Comments

  • Peter JakackiPeter Jakacki Posts: 8,935
    edited 2016-08-28 - 05:16:44
    I may even start a program like this too as you have done but as you see this duplication while you write code then use the power of Forth to make that just another word. Picking the right name and how that is used is sometimes trickier than writing the code!

    edit: I'll leave it to you to make the changes to your code to see how it looks, and works, and saves memory.
  • D.PD.P Posts: 790
    edited 2016-08-30 - 23:02:50
    I can see the factoring at work in my code, that's neat. You see why a person steeped in formal syntax struggles with FORTH. So much emphasis is put on the tools instead of creating the language of the problem domain i.e. pub .ON/OFF and pub .GTL

    Thanks this really helps what's left of my brain. I've got big plans for Tachyon. The picture below is a working all fuel jet turbine from navy surplus that is used to keep anti-freeze in generators above -40 degrees in the Arctic. I've got it working manually, soon I'll strap a P8 to it and stand back :) Gotta keep the fish and giant australian red crayfish warm some how.
    1610 x 2147 - 1M
  • MJBMJB Posts: 1,146
    edited 2016-08-28 - 08:30:11
    @Peter


    while sitting at the lake shore my mind wondered to TACHYON ...

    FORGET works only on the part of the dictionary still in RAM, not the part moved with EEWORDS COMPACT to EEPROM

    so what about RECLAIM, which removed pri headers from dictionary?? Does it leave COMPACTED pri definitions alone and untouched and only affects RAM pri's?

    Seeing LMM now and with dynamically assembled RUNMODs in mind, I was thinking if the assembler could be dynamically loaded and used and then forgotten again in a simple way.

    setting HERE to a temporary area while loading ASSEMBLER.fth and then back - should enable to keep the assemblers code out of the way. But we still need the dictionary. So all Assembler words could be made private. And after using the assembler you just RECLAIM the assemblers own dictionary elements and clean up the RAM dictionary again. The assemblers code was in a buffer area which now just can be reused. No need to do anything with. The newly assembled code is where it belongs and the corresponding dictionary entries are in RAM.
    So now even a COMPACT could be performed again.
    EDIT: Actually I think RECLAIM is not needed, just CMOVEing the newly created part of the dictionary over the part for the ASSEMBLER should do. simple, fast.

    Now this reminds me of the FASL - fast load mechanism of LISP systems. There you file in a source text file which gets 'precompiled' stored to file and can be loaded back in very rapidly.
    So if the buffer is kept at the same address the code (of ASSEMBLER in this case) can be stored to EEPROM or SD and 'paged' in very fast. Also the corresponding part of the dictionary which is relocateable could be saved to EEPROM or SD as well.
    As you measured recently loading in a substancial amount of code takes quite some time. This would give a real speedup for precompiled helper modules.
    And open the way for real dynamic creation of RUNMODs and code with inline LMM.

    Of course now with the big memory we might just leave the whole ASSEMBLER just in the production code ...

    @DP - great to see your progress ...
  • D.PD.P Posts: 790
    edited 2016-08-28 - 21:45:40
    @Peter

    It seems I get spurious characters from PRINT" in my code, I've been over it a hundred times it seems. If I turn the log off everything is peachy but with log on various characters appear and or I get ? ( interpreter trying to execute?) depending if I have commented out some log PRINT" for testing and what not. I'm really stumped ? I'll keep looking. Checking what I have. I can even get it to dump the kernel to the screen if I comment out certain PRINT" stuff but the system keeps running fine. PS after the consolidation of the code it removed my system crash so I'm wondering If I've just got too much if else then logic happening using PRINT"

    EDIT: stuff like this, see the minicom banner?
    14:59:36 EBB PUMP OFF 
    Tank Level  102
    Minicom2.6.1
    14:59:39 Running State  Ebb 
    Time Left  3 Minutes 
    
    
  • Peter JakackiPeter Jakacki Posts: 8,935
    edited 2016-08-28 - 22:15:09
    Although the loop and branch stack is normally only about four levels deep there is no restriction on IF and BEGIN but neither have I ever had a problem with stacks. I'm looking at your code now.

    BTW - I still see these massive nested conditionals all doing practically the same thing. I took NEXTSTATE as a sample and dropped it from 39 lines of code to 11 simple lines yet I am sure that in the end this might be far simpler again.
    pub NEXTSTATE   ( -- )
        LSTS C@ ebbs =				  --- toggle ebb/flow
        DUP IF flows ELSE ebbs THEN LSTS C!	
        DUP IF OFF EBBPUMP FLTD ELSE OFF FLOWPUMP EBTD THEN
        C@ LSTT C! 
        LOG? IF 
          CR .TIME PRINT" State Change to " 
            DAY? IF PRINT" day " ELSE PRINT" night " THEN
            DUP IF PRINT" flow " ELSE PRINT" ebb " THEN
    	.TLS .GBL
        THEN
        DROP
    ;
    

    The rest of the code really needs a quick word for checking if it is ebbing, so updating that code now:
    pub ebb? ( -- flg )	LSTS C@ ebbs = ;
    
    pub NEXTSTATE   ( -- )    				 
        ebb? IF OFF EBBPUMP FLTD ELSE OFF FLOWPUMP EBTD THEN C@ LSTT C! 
        ebb? IF flows ELSE ebbs THEN LSTS C!				--- toggle ebb/flow
        LOG? IF 
          CR .TIME PRINT" State Change to " 
            DAY? IF PRINT" day " ELSE PRINT" night " THEN
            ebb? IF PRINT" ebb " ELSE PRINT" flow " THEN
    	.TLS .GBL
        THEN
    ;
    
    But of course I see looking at the source that even the toggle needs to be factored out too.......etc....
  • @D.P. You may have noticed some comments I added to the last post but essentially if I have to debug I factor common functions so that each word can be clearly understood and easily tested. Anytime you notice that a function has grown to many lines then it may be time to factor it into smaller definitions even if they are not necessarily common or reused as this may help with debugging.

    Anyway I am "mangling" a version first as that also helps me analyze the source. For instance I just came across DAY? and mangled it too :)
    pub DAY?   (  -- flg )
        SETTIMES				--- update daybegin and dayend vars
        MINUTES@  daybegin W@ =>		--- start?
        MINUTES@ dayend W@ <=		--- but not end?
        daybegin W@ dayend W@   <		
        IF AND ELSE OR THEN
    ;
    
  • Well you're gonna need some pain relief after looking at that mess :)

  • D.PD.P Posts: 790
    edited 2016-08-29 - 00:35:34
    Okay following closely here. Sheesh this is not the easiest for my little brain. Appreciate the learning.

    This is the thought compression that is the hard part Peter!!!!
    pub DAY?   (  -- flg )
        SETTIMES				--- update daybegin and dayend vars
        MINUTES@  daybegin W@ =>		--- start?
        MINUTES@ dayend W@ <=		--- but not end?
        daybegin W@ dayend W@   <		
        IF AND ELSE OR THEN
    ;
    

    Gonna work on my technique more diligently !!!!

    UPDATE: My Forth looks like C, there I said it for you. This will change!
  • D.P wrote: »
    Okay following closely here. Sheesh this is not the easiest for my little brain. Appreciate the learning.

    This is the thought compression that is the hard part Peter!!!!

    Gonna work on my technique more diligently !!!!

    UPDATE: My Forth looks like C, there I said it for you. This will change!

    Well it's just that when I look at it I see the result as being either an AND or and OR of those two comparisons rather then a control flow structure of IF ELSEs. But if the control flow structure makes more sense to you to stick with it. As I said, I am mangling it to reduce it down to pure function but sometimes you just need to leave it expanded for your brain's sake too.
  • D.PD.P Posts: 790
    edited 2016-08-29 - 05:13:17
    Neat, worked through both of the examples. It's clearer working with my code and seeing the transformations. Hopefully I can see how other's use Tachyon and if they use the same techniques as you.

    Oh and it was 41 lines of code to 11, that's a lesson that will leave a mark, thanks.


    Update: Still getting some strange chars but optimizations have saved 800+ bytes so far, sheesh
  • MJBMJB Posts: 1,146
    @D.P
    just see this ... looks like C ;-)
     DAY?                   --- is it day?
                IF
                    ON LIGHTS
                ELSE
                    OFF LIGHTS
    THEN
    
    
    assuming ON ~ TRUE
    DAY? LIGHTS
    
    interresting that you turn on lights at day - others turn on light in the night :-)
  • D.PD.P Posts: 790
    edited 2016-08-29 - 15:44:45
    @MJB
    Well you can find the latest code base on GitHub, it's been constantly updated since I began with optimizations with Peter. I'm seriously thinking I've "overrun" something in the Tachyon kernel with my C-orth code styling. I am getting these random characters to the screen when I turn logging on ( output messages to screen). The system over all has been running just fine for the last 24 hrs. No extra stack items..... Peter's tutorials on optimization have been really helpful, 800+ bytes saved already. I've tried packing up all the print statements into little pub routines in one area but I still get spurious characters, funny it's the same characters unless I comment out some print statements then it will change. Got any ideas?
  • after running the system for a while it seems the timers no longer respond
    120000 ebbdwell TIMEOUT  ok
    ebbdwell TIMEOUT? . -1 ok
    120000 flowdwell TIMEOUT  ok
    flowdwell TIMEOUT? . -1 ok
    

    hum, it also seems the spurious characters begin in the FLOW and EBB sections when the dwell timers get reset?
  • Peter JakackiPeter Jakacki Posts: 8,935
    edited 2016-08-30 - 01:13:38
    I may need to add warnings for duplicate names as you have "runtime" defined whereas I was trying to check my runtime that is maintained by TIMER.task and thought I had a bug because I had been checking your "runtime".

    When I have compiled this code I find that that the spurious character is not actually in the output stream but seems to be coming in from the serial stream itself much like KEY! works. Take this message here:
    10:17:45 System Halted
    Last Fault Water too low s
    
    That "s" has been echoed from the keyboard input so that if I simply hit enter I will get an error. I'm having a closer look at the code now.

    BTW, I have put the version that I am mangling as "GARDEN-PBJ.FTH" in the /more/testing dropbox folder

    BTW - I am checking the TIMEOUT bug, these timers should all be dynamically linked but I'm not seeing it come up properly with ,TIMERS (pasted code in from EXPLORER).

    BUG? tanklevel is a byte variable yet you are writing a long to it in GetTankLevel:
    SENF C@ LSTF !
    

  • Ack on the bug! Luckily this only executes when I unplug / electrically disconnect the sensor! The other faults are for high and low water levels in the tank. GOOD EYES. I will change the name of my runtime to rntmram
  • Peter JakackiPeter Jakacki Posts: 8,935
    edited 2016-08-30 - 01:45:29
    Can you check GetTankLevel, you have PSI@ then a 0= IF but I think perhaps you mean ROT 0= IF to read the status ( --- status inches tenths )
    Your routines are definitely corrupting the stack by dropping where they shouldn't etc.
  • D.PD.P Posts: 790
    edited 2016-08-30 - 01:56:55
    Can you check GetTankLevel, you have PSI@ then a 0= IF but I think perhaps you mean ROT 0= IF to read the status ( --- status inches tenths )
    Your routines are definitely corrupting the stack by dropping where they shouldn't etc.

    Checking
    UPDATE:
    Here is what PSI@ returns
    PSI@   ok
    .S  Data Stack (3)
    $0000.0000 - 0
    $0000.0003 - 3
    $0000.0006 - 6 ok
    
    status code
    inches
    tenths

    Use the this in the sensor module
    pub PSI@ ( -- Status inches tenths )
            PSIFLT @  
            DPAVG @ 10 / DUP 10 / swap 10 MOD SWAP  ROT
    ;
    

    fixed LSTF bug and renamed runtime rntmram, testing again, I love forth.
  • D.PD.P Posts: 790
    edited 2016-08-30 - 02:11:43
    Okay there is another bug in GetTankLevel when there is a sensor fault that is consumed by the 0= and 2DROP where there is only 1 stack item left after the LSTF store!!!!!
    { Get tank level in tenths of inches, i.e. 50 is 5 inches }
    pub GetTankLevel (  -- level )
    testm @  IF             --- check for test mode, if so just return the tanklevel
      tanklevel @
    ELSE                    --- else live reading from the psi senor
        PSI@                --- PSI@ from DLVR-L30D module returns status, inches, 10ths of inches 
                            --- convert to tenths
        0=  IF
          10 * +         
          DUP tanklevel !   --- set to tanklevel long  and return copy
        ELSE
          SENF C@ LSTF C!    ---  the fault code has been consumed by the time this write is done!!!
          2DROP             --- then this drops too many stack items!!!!!!!!!!
        THEN
    THEN
    

    gonna rewrite this now and remove the testm stuff
  • D.PD.P Posts: 790
    edited 2016-08-30 - 02:19:17
    @Peter
    Here is the rewrite of GetTankLevel
    { Get tank level in tenths of inches, i.e. 50 is 5 inches }
    pub GetTankLevel (  -- level )
        PSI@                --- PSI@ from DLVR-L30D module returns status, inches, 10ths of inches 
        DUP 0=  IF          --- dup the status code from the sensor
          DROP              --- okay good reading, drop the 0 status DUP
          10 * +         
          DUP tanklevel !   --- set to tanklevel long and return copy
        ELSE
          SENF C@ LSTF C!   ---  not zero set the sensor fault code
          2DROP             ---  drop the other returned values from PSI@
        THEN
     --- THEN    --- whoops to many thens
    

    rebuilt and running
  • @Peter,

    When I restart the first occurrence of chars is here:
    Tank Level  101
    19:35:13 Reset EBB Dwell Timer Set Pump OFF 
    Tank Level  101
    ?
    
    

    The ? mark, this is happening right after the ebbdwell timer is set
  • D.PD.P Posts: 790
    edited 2016-08-30 - 02:29:19
    @Peter another stack bug!!!!! rats
    pub LSTF?  ( -- true/false )
        PSI@  #85 =  IF                        --- status is 85 fault code, sensor grounded, retry failures
            SENF LSTF C!                       --- write the water level sensor fault code
        THEN
        2DROP                                  --- drop the other return readings from PSI@
        
        WLMX C@                                --- waterlevel max ?
        gtl@ < IF WLHF LSTF C! THEN             ---  water level high fault
        
        WLMN C@                                --- waterlevel low ?
        gtl@  => IF WLLF LSTF C! THEN           ---  water level low fault
        LSTF C@ 0 > IF TRUE ELSE FALSE THEN    --- return true or false and fault code in var
    ;
    
    

    rewritten to
    { do we have any fautls }
    pub LSTF?  ( -- true/false )
        PSI@ DUP                       --- 4 things on the stack here, two status codes and inches, tenths
        #85 =  IF                        --- status is 85 fault code, sensor grounded, retry failures
            SENF LSTF C!                       --- write the water level sensor fault code
            2DROP                              --- drop the 2 other items from PSI@
        ELSE
           DROP DROP DROP                      --- drop everything 
        THEN
        
        WLMX C@                                --- waterlevel max ?
        gtl@ < IF WLHF LSTF C! THEN             ---  water level high fault
        
        WLMN C@                                --- waterlevel low ?
        gtl@  => IF WLLF LSTF C! THEN           ---  water level low fault
        LSTF C@ 0 > IF TRUE ELSE FALSE THEN    --- return true or false and fault code in var
    ;
    
    
    

    I will refactor this mess when I have a stable version
  • Check your gmail, I sent you a link to a Google doc for debug chat so we don't end up cluttering the thread
  • MJBMJB Posts: 1,146
    @D.P
    If I am not sure about the stack I put a lot of
    1 .S DROP  
    
    lines in my code where the number tells me where in code it is executed.
    This usually reveals stack bugs quite fast
  • @MJB - we had a session via a Google doc and sorted out a lot of stuff. It seems to be working better now but when D.P. gets out of bed :) he can can test a small mod to the pressure sensor software to see if that resolves another issue. There were stack issues but you can see the source yourself in the testing folder.
  • MJBMJB Posts: 1,146
    @MJB - we had a session via a Google doc and sorted out a lot of stuff. It seems to be working better now but when D.P. gets out of bed :) he can can test a small mod to the pressure sensor software to see if that resolves another issue. There were stack issues but you can see the source yourself in the testing folder.
    @Peter -- you saw my lake shore thoughts above ??
  • MJB wrote: »
    @MJB - we had a session via a Google doc and sorted out a lot of stuff. It seems to be working better now but when D.P. gets out of bed :) he can can test a small mod to the pressure sensor software to see if that resolves another issue. There were stack issues but you can see the source yourself in the testing folder.
    @Peter -- you saw my lake shore thoughts above ??

    Yes, I need to think about it too as I may add relative calls to allow binaries to be loaded so that the assembler is more like an executable that is only used when assembling. Otherwise I really need to implement this vocabulary but I would rather not to avoid complicating the run-time memory with compile-time requirements.

  • D.PD.P Posts: 790
    edited 2016-08-30 - 16:34:42
    MJB wrote: »
    @MJB - we had a session via a Google doc and sorted out a lot of stuff. It seems to be working better now but when D.P. gets out of bed :) he can can test a small mod to the pressure sensor software to see if that resolves another issue. There were stack issues but you can see the source yourself in the testing folder.
    @Peter -- you saw my lake shore thoughts above ??
    @Peter
    Don't ack the 4th byte, don't ack the 4th byte.... It you want to learn to play tennis, play with those that are much better than you. That fixed the sensor!
    Thanks guys, I've learned so much about how to debug stack bugs by sharing my C-orth.

    @MJB what projects are you working on? Do you have any bandwidth to revive the <%F replacement %> syntax in EasyNet?
    Do you finally have a P8+ Wiznet module?
    Now back to SAP, until later.

    UPDATE: DLVR sensor polling time seems to be 10ms to accumulate the most stable readings
    in the buffer.



  • MJBMJB Posts: 1,146
    @MJB - we had a session via a Google doc and sorted out a lot of stuff. It seems to be working better now but when D.P. gets out of bed :) he can can test a small mod to the pressure sensor software to see if that resolves another issue. There were stack issues but you can see the source yourself in the testing folder.
    @Peter -- you saw my lake shore thoughts above ??
    MJB wrote: »
    @MJB - we had a session via a Google doc and sorted out a lot of stuff. It seems to be working better now but when D.P. gets out of bed :) he can can test a small mod to the pressure sensor software to see if that resolves another issue. There were stack issues but you can see the source yourself in the testing folder.
    @Peter -- you saw my lake shore thoughts above ??

    Yes, I need to think about it too as I may add relative calls to allow binaries to be loaded so that the assembler is more like an executable that is only used when assembling. Otherwise I really need to implement this vocabulary but I would rather not to avoid complicating the run-time memory with compile-time requirements.

    my idea was based on avoiding the need for relative calls by using a fixed buffer address. making it a little less generic, but much simpler - and maybe faster.

    If you are interrested we can discuss my thoughts a bit more
  • Neat discussion about the assembler but I want to see Tachyon projects MJB et al :)

    Ebb and Flow System Controller under construction

    Find the P8
    2190 x 1643 - 1M
  • D.PD.P Posts: 790
    edited 2016-08-31 - 01:21:21
    Before this gets sent off for a 3 board run I will need to modify the connections to the RS485 chip. Can I use either 30 OR 31 as the combined tx/rx data pin without ill effect? This board has been routed and it would be a "shame" to have to "rip up" the routing and move it again. Just a prototype, trying to get a project completed end to end from schematic to a professional DIN rail automation control box, I'm always trying to learn/do new things. Hum and about those Tachyon Inside stickers :)
     <tx/rx data pin> <tx enable pin> <baud> <address> PPCFG
    

    EDIT: moved the rx/tx data pin to P20, moving on.
Sign In or Register to comment.