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

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

194959799100109

Comments

  • Hi there, I have tried to build the binary for the IoT5500. I executed all steps manually (copy&paste) according to Peters explanation to be sure when the problem occurs.

    All the first steps seem to finish successfully but the last step - copy/pasting EASYNET.FTH - fails. Here the last output lines:
    BUILD:  FIRMWARE BUILD DATE 160804:180000   BOOTS:  0   runtime 0               
    BOOT:   EXTEND.boot ok                                                          
      ok                                                                            
      ok                                                                            
    .MODULES                                                                        
    MODULES LOADED:                                                                 
    3823: EASYFILE.fth        SD card  + FAT32 Virtual Memory Access File System La 
    3761: +P8.fth             P1432 +P8 HARDWARE DEFINITIONS 141118.0000            
    17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 160809-1840    
     ok                                                                             
    LAP COMPACT LAP .LAP  erasing eeprom sectors.. compacting..\                    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730            
    PCB:    P1432 +P8 (1432)                                                        
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)                                       
    NAMES:  $71B0...74D0 for 800 bytes (4,294,961,321)                              
    CODE:   $0930...4D39 for 17,417 bytes (+5,398)                                  
    RAM:    9,335 bytes free                                                        
    BUILD:  FIRMWARE BUILD DATE 160804:180000   BOOTS:  0   runtime 0               
    BOOT:   15.412secs ok                                                           
    LAP BACKUP LAP .LAP 1.244secs ok                                                
    TACHYON   Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160804.1730          
     ok                                                                             
    1126  W5500.fth not foun error in ?CTRLS at REAK  *error*                       
    ----------------------------------------------------------------
    

    Also remarkable: the short BACKUP time of 1.244 secs I'm not sure with - is it realistic?

    I'm not yet so far to investigate and solve this problem myself - it's some levels to high.
  • D.PD.P Posts: 790
    edited 2016-08-20 04:59
    I haven't tried to build the bleeding edge but is seems you have an easynet.fth file that does not inclued the wiznet 5500 driver stuff. Check the file for references to W5500, does something need to be set? i.e. CREATE 5500. I have not looked at or used the new combined version of the easynet.fth file but have used the new combined version of easyfile.fth with no problems.

    Check the source Luke (proplem)
  • I just did a IoT5500 build with a 20ms line delay in minicom without any problems. I'll try to do it again with a video. I did post a series of screenshots in a "build" folder in the Tachyon Dropbox which is where I will save the video too once it is ready.
  • proplemproplem Posts: 233
    edited 2016-08-20 19:08
    I think a video is not necessary. Have mixed git with dropbox. Investigating asap ...
  • MJBMJB Posts: 1,235
    edited 2016-08-21 13:09
    proplem wrote: »
    I think a video is not necessary. Have mixed git with dropbox. Investigating asap ...

    I don't think mixing git with dropbox is a good idea.

    Thanks Peter - video is here:
    https://dropbox.com/sh/yzrczasnorqp5i9/AAD8aP6CS3QTSVGYF1cTlyDJa/more/build?dl=0&preview=BUILD.mp4
  • MJB wrote: »
    proplem wrote: »
    I think a video is not necessary. Have mixed git with dropbox. Investigating asap ...

    I don't think mixing git with dropbox is a good idea.

    Thanks Peter - video is here:
    https://dropbox.com/sh/yzrczasnorqp5i9/AAD8aP6CS3QTSVGYF1cTlyDJa/more/build?dl=0&preview=BUILD.mp4
    I agree, I use GIT personally so all my projects have a "release" of Tachyon and all the associated files that build together.

    What is on GIT right now is one capture of Tachyon that all builds together. You cannot grab the GIT stuff then download new stuff from DropBox and expect any goodness from that adventure.

    Tachyon moves so fast it became difficult for me to figure out again when to grab a build/release.


  • D.P wrote: »
    MJB wrote: »
    I don't think mixing git with dropbox is a good idea.
    I agree, I use GIT personally so all my projects have a "release" of Tachyon and all the associated files that build together.

    What is on GIT right now is one capture of Tachyon that all builds together. You cannot grab the GIT stuff then download new stuff from DropBox and expect any goodness from that adventure.

    Tachyon moves so fast it became difficult for me to figure out again when to grab a build/release.

    Oh yes. If someone accesses the dropbox folder his/her result is of random character. We can't put all the additional work to organize the cooperation on Peters shoulders. He is the super developer who is driving this project but there is need for helping hands. Peter should support the community so they can support him with organizational work.

    From my point of view Peter should continue his work via dropbox.

    The dropbox version should be copied identically to github and should be kept in sync even manually or via the tool
    D.P mentioned some posts before.

    The next (repetitive) step would be the creation of a `stable version' branch. This would have regression tests and builds for the supported hardwares.

    @D.P: you made the first steps with github. How do you think about continuing?
  • I just did a IoT5500 build with a 20ms line delay in minicom without any problems. I'll try to do it again with a video. I did post a series of screenshots in a "build" folder in the Tachyon Dropbox which is where I will save the video too once it is ready.
    Hi Peter, thank you for the screenshots. I recently downloaded all FTH files I need to build an iot5500 and executed every single step according to your screenshots and I wasn't able get a functional build. The last step (EASYNET) fails always.
    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    P1432 +P8 (1432)
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $71B0...74DC for 812 bytes (4,294,961,314)
    CODE:   $0930...4D8D for 17,501 bytes (+5,406)
    RAM:    9,251 bytes free
    BUILD:  FIRMWARE BUILD DATE 160804:180208   BOOTS:  0   runtime 44,054
    BOOT:   
    MODULES LOADED: 
    386F: EASYFILE.fth        SD card  + FAT32 Virtual Memory Access File System La 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 160809-1840
    37AD: +P8.fth             P1432 +P8 HARDWARE DEFINITIONS 141118.0000 
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    ----------------------------------------------------------------
    TACHYON   Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230          
     ok                                                                             
    1131  W5500.fth not foun error in ?CTRLS at BUG BREAK *error*                   
    ----------------------------------------------------------------
    

    I tried it several times. No way, you are finding me in a completely frustrated mood.
    I compared every screenshot to yours - I found only one difference in RAM size (yours: 9247 mine: 9251) after COMPACTing which might occur because we (unfortunately) used different files. I was not fast enough to grab the same sources that you used.

    As a last idea what could have gone wrong: is there a need for any special file (in particular version) on the sdcard to create a successful build?
  • re Dropbox sources

    Everytime I update the sources I always do a complete build and if something doesn't work I fix it. A case in point was a few weeks ago when I noticed that the keyboard didn't respond properly after running EASYNET. Turned out to be that a change to "lastkey" which is used to check for control keys was causing a problem with the old method still being used by EASYNET and that was fixed and tested.

    It is possible that I am in the middle of such an update when you use the source and although I try not to save the file until it is tested, it still happens. But this should be a rare occurrence and simply solved by trying again later. You may have noticed however that I have a snapshots folder where I have been zipping up the source files that have been built and tested, so you can always resort to downloading and using one of these. However for the bleeding edge stuff just use the stuff I use with the caveats I have already mentioned.
  • D.PD.P Posts: 790
    edited 2016-08-22 07:45
    If I start a task that uses a "new" i2c bus let's say P0 and P1 then I need to:
    #P0 #P1 I2CPINS 
    

    from within the task correct? I have slightly modified I2c routines that use "factory" I2C I2CSTART and STOP. The routines are in the same module as the task. The need for the I2C modifications are sensor non-sense. Everything works grand if I just leave the sensor on the EEPROM I2C bus (28,29) but I want to isolate this "high speed" sensor on it's own bus to avoid hammering the bus with RTC EEPROM writes, RTC queries...

    Problem is I can't seem to get the sensor running on a different bus within a task?

    @proplem, being a GIT librarian for Tachyon is a large commitment to make sure it all works, passes a regression test and a release is set. I have a full time job, it's called SAP and she is demanding for 65 users OMG. I spoil myself with Tachyon time when I can but I am willing to help out.

    Also @Peter the DS3232M provides a 5PPM +- accuracy, 8 pin and has 238 bytes of battery backed SRAM. Just what I need instead of the DS1302. The DS3231 is a 2PPM +- chip but so much bigger for a tiny layout we are working on.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-22 10:47
    @D.P. I see that there is a bug that was introduced during an optimization quite some time ago in regards to the I2C pins with the constant "SCL SDA + == I2C". Obviously the constant won't change just because you change the pins so I will update the routine. However this still does not give you cog independent pins as the pin constants are global. I will look into it a bit more to see if I can come up with something that will work the way you want.

    Re the DS3232M - it seems to have an identical register map so it is totally compatible with RAM to boot. Sounds like a good choice.

    btw - do you really need to isolate this chip onto another bus?
  • D.PD.P Posts: 790
    edited 2016-08-22 17:27
    Oh good, it's a bug hunt then. Okay I think I need another bus because I am reading this sensor at 12 HZ and my main system is reading and writing to EEPROM, RTC and RTC EEPROM on the DS3231.

    I've noticed ?I2CSTART polls for the i2cflg so it will not conflict on the bus. But I see in EXTEND that not all of the routines use this form of ?I2CSTART so my task using it makes no difference right?

    I can see myself clobbering the bus with my sensor reads while the big loop is clobbering as well, hence my guess for the need of a second i2c bus or my own semaphores, yuk. Hey I can write my own start and stop routines and put them in the PSI.TASK module? I was just cheating a little using the factory ones.

    Gonna mount up that DS3232M and give it a whirl

    Thanks for the pointers.

    EDIT: wait a minute I reviewed the extend source again and factory I2C start and stop do set and clear the i2cflg so all my task needs to do is use ?I2CSTART, I'll report back later.

    EDIT2: I will have to check i2cflg though before I use any of my calls to EEPROM or RTC-EEPROM though, check back later
  • D.PD.P Posts: 790
    edited 2016-08-23 04:13
    @D.P. I see that there is a bug that was introduced during an optimization quite some time ago in regards to the I2C pins with the constant "SCL SDA + == I2C". Obviously the constant won't change just because you change the pins so I will update the routine. However this still does not give you cog independent pins as the pin constants are global. I will look into it a bit more to see if I can come up with something that will work the way you want.

    Re the DS3232M - it seems to have an identical register map so it is totally compatible with RAM to boot. Sounds like a good choice.

    btw - do you really need to isolate this chip onto another bus?

    Well I was just about to tear up some source and protect it with i2cflg but I noticed you have redone the I2CSTART routine already with ?I2C in EXTEND.fth

    Time to give it a whirl.

    EDIT: Thanks Peter! The new EXTEND.FTH works fantastically, I've got three TASKS all hammering at the standard I2C Bus without any errors!
    Also the build is so simple since the early days of Tachyon, hat tip.



  • Quick question- How does one use SPLAT? do you just load it like EXTEND?

    Sorry if its a previously answered question.
  • D.PD.P Posts: 790
    edited 2016-08-24 17:43
    Hi Shawn, yes all *.fth files are loaded the same way extend.fth was loaded. There are advanced methods to load from the SDCard but that will come. Search the forum for the SPLAT entry Peter made, I can't find it right now.
    Update:
    HERE it is
  • MJBMJB Posts: 1,235
    Shawn Lowe wrote: »
    Quick question- How does one use SPLAT? do you just load it like EXTEND?

    Sorry if its a previously answered question.

    there is a SPLAT binary that you can load with SpinTool or BST in the binaries subfolder in Peter's dropbox
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-25 01:58
    One of the additions to the JUNO kernel was the LMM opcode but up till now I hadn't really used it. Now I am releasing some cog memory that was being used by low priority code that needed to be executed at the PASM level. So I've been making use of LMM in the kernel but normally a function is just bytecode until it encounters the LMM opcode which is aligned just before a long. What is interesting is that this can become a mix of bytecode and LMM rather than just one or the other. This is what it looks like:
    0A63(000D)             | _COGINIT
    0A63(000D) 1D          |         byte  SWAP,_16,_SHL,_OR,SWAP,_2,_SHL,_OR
    0A64(000E) 75          |
    0A65(000E) 3B          |
    0A66(000E) 35          |
    0A67(000E) 1D          |
    0A68(000F) 78          |
    0A69(000F) 3B          |
    0A6A(000F) 35          |
    0A6B(000F) 04          |         byte  LMM
    0A6C(0010) 02 42 FF 0C |                         coginit tos wr
    0A70(0011) 0A 00 7C 5C |                         jmp     #EXIT
    
    and also
    0A74(0012) 00          |         byte  0
    0A75(0012) 7A          | _CLK    byte  _3,PLUS,_4,CFETCH
    0A76(0012) 25          |
    0A77(0012) 77          |
    0A78(0013) 5C          |
    0A79(0013) 71          |         byte  _BYTE,7,_ANDN,_OR
    0A7A(0013) 07          |
    0A7B(0013) 33          |
    0A7C(0014) 35          |
    0A7D(0014) 77          | _CLKSET byte  _4,CSTORE,LMM
    0A7E(0014) 64          |
    0A7F(0014) 04          |
    0A80(0015) 00 32 7F 0C |                         clkset  X
    0A84(0016) 0A 00 7C 5C |                         jmp     #EXIT
    

    It is also possible to jump in and out of LMM in the middle of bytecode too. A trick I have if I need to drop a stack item is rather than using it then dropping it with a call in LMM is that I simply do a DROP In bytecode which leaves the old stack item in the X register which LMM can use without having to waste memory by calling POPX which is what DROP calls anyway.
  • Hi tachyonista,
    We are approaching 100 pages. How about a worldwide toast on Tachyon, his father and all users if we reach page 100?
    Let's have a drink together then.
    Cheers, proplem
  • D.PD.P Posts: 790
    edited 2016-08-26 05:28
    @Peter
    FYI The DS3232M with 238 bytes of sram instead of EEPROM works just fine with Extend's DS3231 RTC code. Used the same code as RDRTC and WRRTC to read and write the SRAM that starts at address $14. Tiny little chip with +- 5PPM accuracy but not cheap at 6.37 qty 1.

    EDIT:
    Also that dang All-Sensors DLVR-L30D I2C-ish psi gauge sensor was clobbering the EEPROM and RTC i2c bus after all! It would go weird when it failed a sensor read. It has been put on it's own bus before I smashed it with a hammer to "fix" it. Now the new design is ready for a 3 board sample run.

  • Here is a problem I've been wrestling with for a day now.

    First the build:
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    P5555 +P8 Only (5555)
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $562D...74DC for 7,855 bytes (+890)
    CODE:   $0930...4B76 for 16,966 bytes (+4,193)
    RAM:    2,743 bytes free
    BUILD:  FIRMWARE BUILD DATE 160827:081549   BOOTS:  7   runtime 39
    BOOT:   EXTEND.boot
    MODULES LOADED: 
    3B15: GARDENCONTROL.fth   Garden Control P8 160826 0800 V0.92          
    387D: DLVR-L30D.fth       DLVR-L30D PSI Sensor v1.2 160823.1330
    381D: P8Only.fth          P8 Only HARDWARE DEFINITIONS 160823.1800 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 160823-0800
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    

    If I paste in this code to compile
    IF
    
    
    
    
    
    
    THEN
    

    I get this
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    P5555 +P8 Only (5555)
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $562D...74DC for 7,855 bytes (+890)
    CODE:   $0930...4B76 for 16,966 bytes (+4,193)
    RAM:    2,743 bytes free
    BUILD:  FIRMWARE BUILD DATE 160827:081549   BOOTS:  8   runtime 39
    BOOT:   EXTEND.boot
    MODULES LOADED: 
    3B15: GARDENCONTROL.fth   Garden Control P8 160826 0800 V0.92          
    387D: DLVR-L30D.fth       DLVR-L30D PSI Sensor v1.2 160823.1330
    381D: P8Only.fth          P8 Only HARDWARE DEFINITIONS 160823.1800 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 160823-0800
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    ----------------------------------------------------------------
    IF   ok
      ok
      ok
      ok
      ok
      ok
      ok
      ok
    THEN Structure mismatch!  *error*
    

    The actual code in the IF block looks like this but can comment out all the lines and get the same result, I've check the source using "set lists" in vi to show any nasty chars that may have been hidden, help.
           IF
               TRUE fdsflag !                                     --- reset the dwell flag
                FDWL C@  #60000 * flowdwell   TIMEOUT               --- set the dwell timer
                LOG? IF CR .TIME PRINT" : Reset Flow Dwell Timer Reset Pump OFF "  CR
                   PRINT" Tank Level: " gtl .  CR
               THEN
               PRINT" debug step 1 " cr
            THEN
    
  • MJBMJB Posts: 1,235
    D.P wrote: »
    Here is a problem I've been wrestling with for a day now.

    First the build:
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    P5555 +P8 Only (5555)
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $562D...74DC for 7,855 bytes (+890)
    CODE:   $0930...4B76 for 16,966 bytes (+4,193)
    RAM:    2,743 bytes free
    BUILD:  FIRMWARE BUILD DATE 160827:081549   BOOTS:  7   runtime 39
    BOOT:   EXTEND.boot
    MODULES LOADED: 
    3B15: GARDENCONTROL.fth   Garden Control P8 160826 0800 V0.92          
    387D: DLVR-L30D.fth       DLVR-L30D PSI Sensor v1.2 160823.1330
    381D: P8Only.fth          P8 Only HARDWARE DEFINITIONS 160823.1800 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 160823-0800
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    

    If I paste in this code to compile
    IF
    
    
    
    
    
    
    THEN
    

    I get this
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V3.0 JUNO 300160819.2230
    PCB:    P5555 +P8 Only (5555)
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $562D...74DC for 7,855 bytes (+890)
    CODE:   $0930...4B76 for 16,966 bytes (+4,193)
    RAM:    2,743 bytes free
    BUILD:  FIRMWARE BUILD DATE 160827:081549   BOOTS:  8   runtime 39
    BOOT:   EXTEND.boot
    MODULES LOADED: 
    3B15: GARDENCONTROL.fth   Garden Control P8 160826 0800 V0.92          
    387D: DLVR-L30D.fth       DLVR-L30D PSI Sensor v1.2 160823.1330
    381D: P8Only.fth          P8 Only HARDWARE DEFINITIONS 160823.1800 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 160823-0800
    ROMS
    0848 VGA32x15  
    0236 HSSERIAL  
    1648 SIDEMU    
    1940 QUADUART  
    0196 MONO16    
    1900 F32       
    ----------------------------------------------------------------
    IF   ok
      ok
      ok
      ok
      ok
      ok
      ok
      ok
    THEN Structure mismatch!  *error*
    

    The actual code in the IF block looks like this but can comment out all the lines and get the same result, I've check the source using "set lists" in vi to show any nasty chars that may have been hidden, help.
           IF
               TRUE fdsflag !                                     --- reset the dwell flag
                FDWL C@  #60000 * flowdwell   TIMEOUT               --- set the dwell timer
                LOG? IF CR .TIME PRINT" : Reset Flow Dwell Timer Reset Pump OFF "  CR
                   PRINT" Tank Level: " gtl .  CR
               THEN
               PRINT" debug step 1 " cr
            THEN
    

    this code is inside a word definition?
    There are subtle differences between pasting code inside a definition or for direct execution.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-28 00:09
    @D.P. While Tachyon supports interactive operation of compile-only type words it cannot really do this over multiple lines since interactive code is executed line by line. So while you may have IF THENs and DO LOOPs etc you may only do so on the same line otherwise you need to create a temporary definition.

    However if you really want to compile over multiple lines then try adding these words to Tachyon which I may also add to EXTEND as standard:
    : [ IMMEDIATE $80 flags SET ; 
    : ] IMMEDIATE $80 flags CLR ;
    

    Now enclose your multiple line interactive code in these brackets and it won't execute until it hits the closing bracket ].
    A simple test:
    1  ok
    [ IF 
    ." HELLO" 
    THEN 
    ] HELLO ok
    

    Actually I seem to remember that [ and ] stop and start compilation in some Forths so this is actually doing the reverse......hmmm
  • Okay got it thanks.

    I've been bug hunting. I've got some code that just literally blows up and I can't figure it out yet. Is there a way to invoke ^D within the code so I can see it just before she blows?

  • Just use DEBUG but normally I just write my own debug routine for the task at hand to display the relevant information. You can also add a control flag so that you can turn it on or off as needed or even add levels for more details. So you could create a byte variable _debug for instance and define your ?DEBUG routine which checks the flag or value to determine if it needs to report anything or just return.

    I've been meaning to ask you since I first asked about if you would post your garden control code but you feel the need to "clean it up" before doing so. However I feel that posting as is will be of more benefit both to yourself, myself, and others. This is because your code would be more typical of code NOT written by me, so then I get a better idea of how Tachyon is being used and how I can make improvements in this area. The other thing is that I can use the code as an example in not only in how to make optimizations but also in coding Tachyon and "thinking Forth" which really is not so much about Forth but about "thinking" itself.
  • Just use DEBUG but normally I just write my own debug routine for the task at hand to display the relevant information. You can also add a control flag so that you can turn it on or off as needed or even add levels for more details. So you could create a byte variable _debug for instance and define your ?DEBUG routine which checks the flag or value to determine if it needs to report anything or just return.

    I've been meaning to ask you since I first asked about if you would post your garden control code but you feel the need to "clean it up" before doing so. However I feel that posting as is will be of more benefit both to yourself, myself, and others. This is because your code would be more typical of code NOT written by me, so then I get a better idea of how Tachyon is being used and how I can make improvements in this area. The other thing is that I can use the code as an example in not only in how to make optimizations but also in coding Tachyon and "thinking Forth" which really is not so much about Forth but about "thinking" itself.

    I'll do it, should I zip the whole batch up, kernel, extend and all. I'm happy with what I have so far.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-28 03:37
    Just the code itself is fine as I'm most curious about this and I wish more Tachyonistas would be more forthcoming (that's a pun, I didn't even know it). Sometimes I feel like a rough brute when I "redo" the code in a totally different way but I am sitting across the table now from my wife who is marking senior biology student's drafts and she knows that all the red lining and comments are going to upset her students but in the end they become better students and continue to thank her even after they have left school and attend university.

    I'm constantly reexamining my own methods and sometimes I see the way someone else has done it and adopt some of those ideas. As you can see from all my Google docs and Dropbox files that I lay it all out there for what it is and try not to worry about what others think or even comparing it to what others do. It's like bringing a plate to a gathering and in the mix we all find something to enjoy.

    btw, I just fixed up one of my mistakes too as I noticed BACKUP was taking forever. Turns out that I compare a page (64 or 128 bytes) at a time to see if it needs to be programmed but at the end of the test it didn't issue an I2CSTOP which didn't clear the busy flag which made it take forever while each page timed out.
  • D.PD.P Posts: 790
    edited 2016-08-28 03:37
    I've made the GitHub repository public for now.

    Follow this link for fun :)

    Post anything you want, I can show you where the problem is. Not at the screen again for about an hour though.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-28 03:46
    Thanks D.P. - the code looks neat and the first thing I noticed was the explicit zeroing of declared variables which is redundant for any variables declared this way except for ORG/DS variables which allocate totally differently anyway. However if they are part of a TABLE you can have them zeroed by using BYTES instead of TABLE/ALLOT. So "TABLE runtime #22 ALLOT" becomes "22 BYTES runtime" instead. Normally I use TABLE if I am building literals directly into it at compile time such as lookup or font tables.

    See the btw in my previous post about BACKUP
  • @D.P. I can see that although you have written this neatly and well laid out that it is crying out for factoring common functions into new words. A case in point is I see a lot of duplication of exactly the same message or an ON/OFF variation of it. Now without looking too far we just make a word that says ON or OFF we can also call it something that we recognized such as .ON/OFF. Combine this with one other very common function which prints your tank level and you are starting to make your code simpler and more concise while saving much memory.

    Take this function for instance which is very similar to a number of other functions:
    pub CIRCPUMP  ( ON / OFF -- message to terminal )
        IF
           circp HIGH
           LOG? IF .TIME PRINT" : CIRC PUMP ON  " CR
             PRINT" Tank Level: " gtl . CR
           THEN
        ELSE
           circp LOW
           LOG? IF .TIME PRINT" : CIRC PUMP OFF  " CR
             PRINT" Tank Level: " gtl . CR
           THEN
        THEN
    ;
    

    Then factor out functions that are used identically in several places which also helps to keep changes in one place too.
    pub .ON/OFF	DUP IF PRINT" ON  " ELSE PRINT" OFF  " THEN ;
    pub .GTL	PRINT" Tank Level: " gtl . CR ;
    
    pub CIRCPUMP  ( ON / OFF -- message to terminal )
        DUP circp PIN!
        LOG? IF .TIME PRINT" : CIRC PUMP " .ON/OFF CR .GTL THEN
        DROP
    ;
    

    So .ON/OFF and .GTL are used in other functions plus we also remove the need for an ELSE in these functions too.
  • Time for a notepad :) At least I got the neat right.

    dp
Sign In or Register to comment.