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.
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.
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 ...
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
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
;
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!
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.
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
@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?
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:
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
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.
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
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
{ 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
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
@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.
@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.
@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.
@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.
@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.
@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
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
Comments
edit: I'll leave it to you to make the changes to your code to see how it looks, and works, and saves memory.
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
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 ...
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?
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....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 ;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!
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.
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
just see this ... looks like C ;-)
DAY? --- is it day? IF ON LIGHTS ELSE OFF LIGHTS THENassuming ON ~ TRUE interresting that you turn on lights at day - others turn on light in the night :-)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?
hum, it also seems the spurious characters begin in the FLOW and EBB sections when the dwell timers get reset?
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: 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:
Your routines are definitely corrupting the stack by dropping where they shouldn't etc.
Checking
UPDATE:
Here is what PSI@ returns
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.
{ 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 THENgonna rewrite this now and remove the testm stuff
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 thensrebuilt and running
When I restart the first occurrence of chars is here:
The ? mark, this is happening right after the ebbdwell timer is set
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
If I am not sure about the stack I put a lot of lines in my code where the number tells me where in code it is executed.
This usually reveals stack bugs quite fast
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.
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.
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
Ebb and Flow System Controller under construction
Find the P8
EDIT: moved the rx/tx data pin to P20, moving on.