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.
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.
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.
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.
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.
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?
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.
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.
@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?
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.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.
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
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:
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
@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.
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
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.
@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:
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.
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.
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.
@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.
Comments
All the first steps seem to finish successfully but the last step - copy/pasting EASYNET.FTH - fails. Here the last output lines:
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.
Check the source Luke (proplem)
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
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 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?
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.
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.
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?
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
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.
Sorry if its a previously answered question.
Update:
HERE it is
there is a SPLAT binary that you can load with SpinTool or BST in the binaries subfolder in Peter's dropbox
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.
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
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.
First the build:
If I paste in this code to compile
I get this
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 THENthis code is inside a word definition?
There are subtle differences between pasting code inside a definition or for direct execution.
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:
Now enclose your multiple line interactive code in these brackets and it won't execute until it hits the closing bracket ].
A simple test:
Actually I seem to remember that [ and ] stop and start compilation in some Forths so this is actually doing the reverse......hmmm
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?
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.
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.
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.
See the btw in my previous post about BACKUP
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.
dp