I'm thinking about how best to access the dictionary in SD as although 1K could be paged in every 5ms (without optimization) you wouldn't want to do that for every word that's searched. So I was thinking perhaps that when I read it in and find a match that I then add it to my dictionary cache in RAM. This cache could be flushed at the end of a source code load and it wouldn't matter if the whole dictionary was held in SD. This would free up around 4 to 8K of RAM and simply rely on the SD buffers. BTW, EEPROM is way too slow. The SD search method would only be implemented if the SDCARD.fth extensions have been loaded and the option selected otherwise everything will just run as it does now.
Hi Peter,
with last version long 20121013,1530
on Spin-Tool 1,2,6
I get Error: Address is out of range at line: 1688
in Terminal at:
un00 byte XCALL,xSPACE,REG,wordbuf,XCALL,xPSTR ' Spit out offending word
byte _WORD,$02,14,(EMIT),_ELSE,@un04-@un03
EMIT is highlighted ...
previous versions run wonderfully ...
while new to FORTH I learn a lot reading your souce code ... thanks a lot for sharing
MJB Markus from Germany
If I type "AUTORUN FOO" on the next and subsequent REBOOT, hardware reset, power-on reset TF will search for and execute FOO. If I then type "AUTORUN BAR" FOO is out and now AUTORUN looks for BAR.... what do I type to stop AUTORUN altogether?
If I type "AUTORUN FOO" on the next and subsequent REBOOT, hardware reset, power-on reset TF will search for and execute FOO. If I then type "AUTORUN BAR" FOO is out and now AUTORUN looks for BAR.... what do I type to stop AUTORUN altogether?
Just AUTORUN CANCEL
In fact you can use any word that does not exist as this will always return with a null. To cancel it from code just access it's variable directly:
autorun W~
Hi Peter,
with last version long 20121013,1530
on Spin-Tool 1,2,6
I get Error: Address is out of range at line: 1688
in Terminal at:
un00 byte XCALL,xSPACE,REG,wordbuf,XCALL,xPSTR ' Spit out offending word
byte _WORD,$02,14,(EMIT),_ELSE,@un04-@un03
EMIT is highlighted ...
previous versions run wonderfully ...
while new to FORTH I learn a lot reading your souce code ... thanks a lot for sharing
MJB Markus from Germany
That's a strange one. The _EMIT word is named (EMIT) in the compiled dictionary only yet BST is quite happy to compile _EMIT in it's place even though I obviously have made a mistake in typing (EMIT).
While reading in 'Starting Forth' (thanks Peter, for the link)
I was typing some examples into Tachyon.
this:
-10 0 DO I . -1 +LOOP
did not work.
So I started digging ... to find out why.
And ... added the functionality to the kernel.
Takes 3 longs in COG - If one wants to sacrifice this ...
I am still very new to Prop and Forth ... so I hope I did
not break s.th. else.
It looks like you are calling the loop words from the command line with out encapsulating them in a definition.
I don't know it this matters, but I don't think the branching functions are supposed to work from the command line, they are only supposed to be used within a word definition.
I think it was something about the way they use the return stack, you could get things out of whack if you did the wrong word in between.
It looks like you are calling the loop words from the command line with out encapsulating them in a definition.
I don't know it this matters, but I don't think the branching functions are supposed to work from the command line, they are only supposed to be used within a word definition.
I think it was something about the way they use the return stack, you could get things out of whack if you did the wrong word in between.
Since I detest having Forth work differently from the command line I have made Tachyon compile before execute on the command line. So anything that you can do from within a definition you can do on the command line without any special words plus the timing is identical.
It also compiles word by word so once you've typed that word in and entered a space etc you can't go back. So if you make a mistake after that you need to discard the line with an <esc> key. Sometimes that's a nuisance but tolerable. I may make that part of it selectable in the future though.
While reading in 'Starting Forth' (thanks Peter, for the link)
I was typing some examples into Tachyon.
this:
-10 0 DO I . -1 +LOOP
did not work.
<snip>
A nice example of the extensability of a Forth system.
Especially if all the source is available ... Thanks Peter ...
The TERMINAL definition is a bit long at present and I will get around to factoring the functions out so for one thing it will make it very easy to patch a specialized parser into a precompiled kernel. Talking about getting "a round tuit" there are little things like you came across with negative numbers in a loop for instance that I would get around to it eventually. Funny thing is I can't ever recall using negative indices in a loop before but I'm sure it would come in useful. I think I normally keep it positive and simply subtract the index from an offset.
Thanks for the code, I will get "a round tuit" later
One major difference between PF and TF has been that TF permits looped structures from the command line and PF does not!
Also, from the beginning, could not parse input in the form "-123" , but that can be gotten around by typing "123 NEGATE"
Regarding the negative number input I did finally get a round tuit a little while back. It only took a couple of minutes to add the extra checking along with all the other prefix and suffix stuff that I do. BTW, the latest kernel will process anything that starts with # or $ or % and ends in a digit as a number rather than search the dictionary. This speeds up compilation but you might get caught as my L6470.fth source had some #cs1 and #cs2 constants etc which were being interpreted as 1 and 2 rather than the defined constant! Of course I just renamed these constants.
I have some code that works perfectly when tethered to the Mac by the USB, but appears to never get started untethered.
The Setup
Tachyon Forth 121013 - latest EXTEND and SDCARD
my JMSERVO2.fth
Prop BOE mounted on a BOEBOT
The errant code - a short script to see how the maneuvers actually look on the ground.
This code was copy pasted in and followed by
AUTORUN MAINLOOP3 BACKUP
The bot was set on a stand to keep the wheels off he desk. It was powered up with no power to the servos. It appeared to run oK. There is an LED commanded on in the background task "SERVOS."
Repeated with power to servos. They ran, they appeared to follow the script and did loop and repeat.
Shut bot down.. disconnected wall power, plugged in 6v battery pack and removed USB cable.
Put bot on floor, powered up BOE and servos ====> nada, zilch, NOTHING ... no LED from "ON SERVOS," no servos running
Pickup bot, plug in USB and "back in business!"
I have a vague recollection of this problem elsewhere ... what am I missing ?????????
: MAINLOOP3
SVZRO \ start with all servos disabled
#8 seconds
ON SERVOS
#2 seconds
BEGIN
STRAIGHT 5 seconds
BACK 4 seconds
ROTLFT 500 ms
ROTRT 500 ms
ROTLFT 2 seconds
STRAIGHT 4 seconds
ROTLFT 2 seconds
STRAIGHT 4 seconds
CRVLFT 2 seconds
KEY? AND UNTIL \ HIT CR to break loop
OFF SERVOS
;
I have some code that works perfectly when tethered to the Mac by the USB, but appears to never get started untethered.
The Setup
Tachyon Forth 121013 - latest EXTEND and SDCARD
my JMSERVO2.fth
Prop BOE mounted on a BOEBOT
The errant code - a short script to see how the maneuvers actually look on the ground.
This code was copy pasted in and followed by
AUTORUN MAINLOOP3 BACKUP
The bot was set on a stand to keep the wheels off he desk. It was powered up with no power to the servos. It appeared to run oK. There is an LED commanded on in the background task "SERVOS."
Repeated with power to servos. They ran, they appeared to follow the script and did loop and repeat.
Shut bot down.. disconnected wall power, plugged in 6v battery pack and removed USB cable.
Put bot on floor, powered up BOE and servos ====> nada, zilch, NOTHING ... no LED from "ON SERVOS," no servos running
Pickup bot, plug in USB and "back in business!"
I have a vague recollection of this problem elsewhere ... what am I missing ?????????
: MAINLOOP3
SVZRO \ start with all servos disabled
#8 seconds
ON SERVOS
#2 seconds
BEGIN
STRAIGHT 5 seconds
BACK 4 seconds
ROTLFT 500 ms
ROTRT 500 ms
ROTLFT 2 seconds
STRAIGHT 4 seconds
ROTLFT 2 seconds
STRAIGHT 4 seconds
CRVLFT 2 seconds
KEY? AND UNTIL \ HIT CR to break loop
OFF SERVOS
;
Just an idea but your loop terminates with any key which is not a real good idea for a turn-key app. Test for <esc> or something instead as the receive pin may be being pulled low by the disconnected USB and that's sending nulls through the port. This could also trigger a break condition which will reboot the Prop but my serial driver also checks for a floating input by pulsing the receive line high for a microsecond then checking to see if it's stayed high (floating input) or still low (driven). If you can't do anything about the break condition because of your hardware then better disable it by commenting out the second line:
RxLoop call #receive
if_nc jmp #abreak ' discard if framing error (no stop bits)
I may add a little extra checking on the serial driver to see if I can automatically disable the break detect in these circumstances.
I reconstructed the exact same TF build on one of my new Propeller Platform Through Hole boards, which is uses the non-integral USB Prop Plug. After setting "AUTORUN MAINLOOP3 BACKUP" I simply removed the Prop Plug and hit the Reset button. MAINLOOP3 came up and ran perfectly.
AT this point the TxD and RxD were hanging empty, 'floating at TTL level.' As I said in my initial message on this matter I have some vague recollection of this problem. After further ruminations I am convinced its not TF's fault. The problem seems to lie in boards with built in USB.
I reconstructed the exact same TF build on one of my new Propeller Platform Through Hole boards, which is uses the non-integral USB Prop Plug. After setting "AUTORUN MAINLOOP3 BACKUP" I simply removed the Prop Plug and hit the Reset button. MAINLOOP3 came up and ran perfectly.
AT this point the TxD and RxD were hanging empty, 'floating at TTL level.' As I said in my initial message on this matter I have some vague recollection of this problem. After further ruminations I am convinced its not TF's fault. The problem seems to lie in boards with built in USB.
Hi Brian, did you try commenting out that line in the serial Rx routine? However I suspect that the problem is with the way the USB chip is connected and that it also controls the reset line. A lot of these USB chips draw their power from the USB bus and so when it's unplugged the chip isn't directly powered. However the Txd line from the Prop is normally high and this feeds through the USB chip's substrate back into it's power and has a tendency to kick it into life after which it resets the Prop and so on ad infinitum. The simple solution for this is to simply have a current limit resistor from the Prop's Tx pin into the USB chip so that it can never draw enough power to kick in. There are variations on these solutions but that's a simple one. Try a value of 10K.
MEANWHILE, ON ANOTHER TANGENT ... I was working with your One-Wire code today. I took your suggestion and made "1WRESET DROP READROM" into a WORD "RD1ROM" I used it to read device IDs on a bunch of DS18B20s. Your READROM word or one of its support words is dropping a bit. Every one of my DS18B20s showed a device code of $14 instead of $28.
RD1ROM 14 AB BD B2 C0 00 00 D0 ok
ok
RD1ROM 14 DC 3B B2 C0 00 00 B7 ok
I have attached a copy of your 1 wire file with almost a dozen words appended to the end that should prove useful. Look at GETTEMP and see if you can figure why the two "1W@" always read all "F"s in my routine but gets realistic reads in your READROM.
T1
STACK: 00000000 00000000 0000000F 00000FFF +095.93 degrees C
Now to rummage through my backups and find my working spin code for 1--w ... failing that I may have to rummage in my [gasp!] Arduino stuff!
shouldn't endofkernel go directly after marker to give the right amount of free kernel COG size?
7C58(01D6) 24 00 00 00 | Xptr long @XCALLS+s ' used by XCALL
7C5C(01D7) 00 00 00 00 | marker long 0[4]
7C6C(01DB) | org tos
7C6C(01A8) | sdat res 1
7C6C(01A9) | org REG0
7C6C(01CE) | sck res 1
7C6C(01CF) | mosi res 1
7C6C(01D0) | miso res 1
7C6C(01D1) | pixshift
7C6C(01D1) | scnt res 1
7C6C(01D2) | pixeladr res 1
7C6C(01D3) | endofkernel res 0 ' just a marker to indentify the end of the kernel in the listing (BST)
7C6C(01D3) | res 0
Propeller .:.:--TACHYON--:.:. Forth V20121013.1530
1780: EXTEND.fth Primary extensions to TACHYON kernel - 121012.2300
ok
1 2 3 4 5 6 7 8 9 10 11 12 13 14 . . . . . . . . . . . . . . . 14131211109870000000 ok
ok
1 ok
2 ok
3 ok
4 ok
5 ok
6 ok
7 ok
8 ok
9 ok
10 ok
11 ok
12 ok
13 ok
14 ok
DATA STACK
01A8: 000001A8 00000014 00000013 00000012
01AC: 00000011 00000010 00000009 00000000
01B0: 00000000 00000000 00000000 00000000
RETURN STACK
Propeller .:.:--TACHYON--:.:. Forth V20121013.1530
1780: EXTEND.fth Primary extensions to TACHYON kernel - 121012.2300
ok
1 2 3 4 5 6 7 8 9 10 11 12 13 14 . . . . . . . . . . . . . . . 14131211109870000000 ok
ok
1 ok
2 ok
3 ok
4 ok
5 ok
6 ok
7 ok
8 ok
9 ok
10 ok
11 ok
12 ok
13 ok
14 ok
DATA STACK
01A8: 000001A8 00000014 00000013 00000012
01AC: 00000011 00000010 00000009 00000000
01B0: 00000000 00000000 00000000 00000000
RETURN STACK
Terminal interaction uses the stack too so this always has to be taken into account. If a Forth is to be judged on the depth of it's stack then Tachyon probably is on the bottom of that stack! Like the philosophy of RISC where decisions are made to remove the complexity and run lean and mean so too there is a philosopy behind Tachyon vs conventional Forths which drive the decisions made. First off, the Prop is not real good with addressing stacks and there is not a lot of room in cog RAM to spare and hub RAM is too slow. Plus there has always been the problem with Forth with addressing items more then 3 or 4 levels deep. The decision therefore is to use cog RAM but for the individual VM instructions to run unimpeded by any stack somersaults the stack items need to be in a fixed place. So keep them fixed and move all the contents around when it comes to pushing and popping. But this is costly in terms of processor cycles etc so once again design the kernel in such a way that stack usage could be minimized etc.
So this brings us to your test which as mentioned earlier is flawed because you assume it's deeper than it is and you don't take into account stack usage just for handling terminal interaction and printing etc. Also the DEBUG word is high level so it must use the stack also although it's use is minimized. My very early Tachyon had the debugger in PASM and it could list everything perfectly without using the stack etc. But alas there is no way to have the machine level debugger and a Tachyon VM plus stacks etc resident in 496 longs.
The test for the stack handling should therefore be made from within a definition (or on a single line) and stack usage should be minimized. The data stack is only 12 longs deep so this is my simple version:
: N CR .BYTE ; ok
ok
: T 12 23 34 45 56 67 78 89 90 91 82 73
N N N N N N N N N N N N ; ok
T
73
82
91
90
89
78
67
56
45
00
00
00 ok
Notice that it seems to go 9 levels deep before it "loses" the first 3 items. That's because up to 3 items were pushed on top of the stack losing the first 3 items that were there and then subsequent popping results in zeros filling those voids. The zeros are popped into the most bottom level of the stack mainly for error checking but serve no other useful purpose.
How useful is a shallow stack? Well when combined with useful VM instructions which also use other stacks and fixed cog registers the results are very good. I've written working turn-key applications in Tachyon that testify to the workability of the approach taken to an embedded Forth that works in harmony with the Prop's unique architecture.
Would I love more cog RAM? You betcha! But that ain't ever going to happen, however P2 will have a lot of enhancements that Tachyon will exploit to the max, but that's next year.
shouldn't endofkernel go directly after marker to give the right amount of free kernel COG size?
7C58(01D6) 24 00 00 00 | Xptr long @XCALLS+s ' used by XCALL
7C5C(01D7) 00 00 00 00 | marker long 0[4]
7C6C(01DB) | org tos
7C6C(01A8) | sdat res 1
7C6C(01A9) | org REG0
7C6C(01CE) | sck res 1
7C6C(01CF) | mosi res 1
7C6C(01D0) | miso res 1
7C6C(01D1) | pixshift
7C6C(01D1) | scnt res 1
7C6C(01D2) | pixeladr res 1
7C6C(01D3) | endofkernel res 0 ' just a marker to indentify the end of the kernel in the listing (BST)
7C6C(01D3) | res 0
endofkernel is a leftover and unused symbol from an earlier version but the important address if it was used is it's address in hub RAM (7C6C), not the address in cog RAM. So moving the symbol would not change this address anyway.
Left to my own devices sooner or later I latch onto a clue. It was unfortunate that the 'clue' was $14 that should have been $28 ... you can get there two ways, a lost/dropped bit ORRRRR reversed order in the byte ... to make a long story short, "1W@" is reading the bits right but placing the bits into the byte in the reverse order. I got this by displaying binary and looking for hard coded numbers in ROM ID and the SCRATCHPAD.
Here's my additions to the toolbox that let me read temps and IDs etc
TACHYON
: 1WIREbbr.fth ." 1-wire interface BBR additions 121019:1530 "
\ -------------------------------------------------------------------
: READROM ( -- ) $33 1W! ; \ command to read ROM ID
: SKIPROM ( -- ) $CC 1W! ; \ when only one device online responds without MATCHROM
: MATCHROM ( -- ) $55 1W! ; \ command to match an ID to a specific device
: CONVERTT ( -- ) $44 1W! ; \ commands all Temp sensors to start measurement (750 ms)
: READSCR ( -- ) $BE 1W!; \ dumps 9 bytes (8 plus CRC) of device scratchpad
: GETBYTES ( bytecnt -- ) FOR 1W@ $0802 .NUM SPACE NEXT CR ;
: RD1ROM ( -- ) 1WRESET DROP READROM 8 GETBYTES ;
: RD1SCR ( -- ) 1WRESET DROP SKIPROM READSCR 9 GETBYTES ;
: GETTEMP ( -- temp )
READSCR
1W@ 1W@ 8 SHL +
;
: PRINTTEMP ( temp -- )
DUP $0F AND SWAP 4 SHR \ put whole degrees in one long and fraction in another
$830A .NUM \ print whole number
"." EMIT \ print decimal point
#100 * #16 / \ turn binary bits to 100ths
$020A .NUM \ print decimal
." degrees C " CR
;
: T2 ( -- ) \ reads annd displays a single DS18B20 alone on a 1-W buss
1WRESET DROP SKIPROM CONVERTT 750 ms
1WRESET DROP SKIPROM GETTEMP PRINTTEMP
;
: T3 ( -- ) \ reads annd displays a single DS18B20 SCRATCHPAD alone on a 1-W buss
1WRESET DROP SKIPROM CONVERTT 750 ms
1WRESET DROP SKIPROM RD1SCR
;
END
1st byte of ROMID should be $28 but it's $14. Enter the bits of that byte in reverse order and "." it. What do we get ... $28 !!!
1st 2 bytes of an idle SCRATCHPAD are supposed to be $50 and $05 ... same drill, again ... type them in in reverse bit order and dump the stack ... we get $05 and $50
%00101000 . 28 ok
%01010000 %00000101 .S
STACK: 00005D97 00005D0A 00000050 00000005 ok
Simply READ and compute the temperature ... what!! That cannot be!
T2 +062.87 degrees C
ok
Go right back and READ the TEMP and binary dump SCRATCHPAD. Enter the LSB and then the MSB as before in reverse bit order, execute the second half of GETTEMP, joining the LSB and MSB in one long on stack, then call PRINTTEMP to finish the job ... 23 degrees C is nominally accepted as "room temp."
T3 11101110 10000000 11010010 01100010 11111110 11111111 10010000 00001000 11110110
ok
%01110111 %00000001 ok
8 SHL + .S
STACK: 00000005 00000005 00000050 00000177 ok
PRINTTEMP +023.43 degrees C
ok
I think it is pretty conclusive that "1W@" is the culprit and it needs to write the bits in reverse order!
Well I still can't figure out what is causing and how its doing it the read-1wire-byte, "1W@" to receive the bits in proper order in proper order but write them out in reverse. Needless to say nothing in 1 Wire works quite right with this function compromised(Sorry Peter!).
In the meantime I wrote a not so quick and oh-so-dirty kluge that brute force puts the bits in the proper order. It is called FIX1W@ ... please don't laugh too hard ... remember it breaks nothing and allow one-wire to move forward while Peter tries to find time to solve the bug.
The bug patch call is a I sIngle word call as the last line in 1W@.
The file I attached is Peter's original code with FIX1W@ and the patched 1W@ and appended to the end is my 1-W extensions.
Well I still can't figure out what is causing and how its doing it the read-1wire-byte, "1W@" to receive the bits in proper order in proper order but write them out in reverse. Needless to say nothing in 1 Wire works quite right with this function compromised(Sorry Peter!).
In the meantime I wrote a not so quick and oh-so-dirty kluge that brute force puts the bits in the proper order. It is called FIX1W@ ... please don't laugh too hard ... remember it breaks nothing and allow one-wire to move forward while Peter tries to find time to solve the bug.
The bug patch call is a I sIngle word call as the last line in 1W@.
The file I attached is Peter's original code with FIX1W@ and the patched 1W@ and appended to the end is my 1-W extensions.
Hi Brian, I'm looking into it today so hang tight, I just never got around to doing anything more with this code at the time.
Just starting to play with 1-Wire stuff again and I noticed quite a few mistakes in my code. First off I noticed that the 1W@ was assembling the byte back-to-front in that it was left shifting the bits in, didn't you notice! I was also driving the line high with an OUTSET instruction rather than letting it float using INPUTS.
This is a READROM from an 18B20 which matches the family code:
READROM 28 AE 68 24 03 00 00 E4
So I will play with it a bit more today and see how it goes.
Just starting to play with 1-Wire stuff again and I noticed quite a few mistakes in my code. First off I noticed that the 1W@ was assembling the byte back-to-front in that it was left shifting the bits in, didn't you notice! I was also driving the line high with an OUTSET instruction rather than letting it float using INPUTS.
This is a READROM from an 18B20 which matches the family code:
READROM 28 AE 68 24 03 00 00 E4
So I will play with it a bit more today and see how it goes.
I rebuilt my TF load from COLD and applied your latest "1wire.fth" and then my extensions, "1WIREBBR.fth" on top of that sans my patches for 1W@. All OK nothing broken ... thank you!
I rebuilt my TF load from COLD and applied your latest "1wire.fth" and then my extensions, "1WIREBBR.fth" on top of that sans my patches for 1W@. All OK nothing broken ... thank you!
Thanks Brian, I thought it was still a WIP until you said it all worked! I've changed the write routines to force the bus high to power any devices that rely on parasitic power. Your routines have also been incorporated in 1-Wire.fth with a few little changes.
All this talk about multi-threading in another thread (hey, this is multi-threading!) reminded me to add my interrupt processing to the VM. Virtual interrupts are checked whenever an EXIT instruction is executed but before the instruction pointer is restored (just like a conventional return from subroutine). Up to 31 interrupt sources may be used each with an associated vector in hub RAM. I am still playing with this although it works as is but I am thinking of adding cog context switching where I can push and pop the cog's stacks etc to hub RAM and back. You can also trigger the interrupt from PASM so that another cog such as a CAN or USB bus device can initiate high-level functions.
All this talk about multi-threading in another thread (hey, this is multi-threading!) reminded me to add my interrupt processing to the VM. Virtual interrupts are checked whenever an EXIT instruction is executed but before the instruction pointer is restored (just like a conventional return from subroutine). Up to 31 interrupt sources may be used each with an associated vector in hub RAM. I am still playing with this although it works as is but I am thinking of adding cog context switching where I can push and pop the cog's stacks etc to hub RAM and back. You can also trigger the interrupt from PASM so that another cog such as a CAN or USB bus device can initiate high-level functions.
how much memory per thread do you estimate, and where will the context be saved? sal did software multitasking early on in propforth, but removed it as toocostly. now we are talking about adding it again, in preparation for prop2 and other experiments. we are talking about the PAUSE round robin from traditional forth, is this wha t you are doing using EXIT?
how much memory per thread do you estimate, and where will the context be saved? sal did software multitasking early on in propforth, but removed it as toocostly. now we are talking about adding it again, in preparation for prop2 and other experiments. we are talking about the PAUSE round robin from traditional forth, is this wha t you are doing using EXIT?
Multi-tasking uses a cog per task which is how you really want it so there is no need for any scheduling since they are all running concurrently, not sequentially. However the interrupts are very low overhead and allow a task (cog) to be interrupted in a timely fashion normally just to do something short and sweet.
Here are the two code fragments:
[FONT=courier new] '''
EXIT mov R0,interrupts wc,wz
if_nc_and_nz jmp #INTERRUPT 'service interrupts before restoring IP from return stack
call #RPOPX
mov IP,X
jmp #doNEXT
INTERRUPT mov R1,#@intvecs+s-4 ' point to interrupt vectors in hub ram (low address)
scanirqs shr R0,#1 wc,wz ' test next irq bit (with a safety fence)
add R1,#2 ' point to next word vector
if_nc_and_nz jmp #scanirqs
or interrupts,msb ' set inhibit
rdword IP,R1 ' read in external vector
jmp #doNEXT ' and execute (no need to save IP as it's not yet restored)
[/FONT]
Comments
Testing at 230,400 baud and 6ms line delay.
EXTEND.fth = 11.6 seconds
SDCARD.fth = 4.9 seconds
L6470.fth = 5.35 seconds
I'm thinking about how best to access the dictionary in SD as although 1K could be paged in every 5ms (without optimization) you wouldn't want to do that for every word that's searched. So I was thinking perhaps that when I read it in and find a match that I then add it to my dictionary cache in RAM. This cache could be flushed at the end of a source code load and it wouldn't matter if the whole dictionary was held in SD. This would free up around 4 to 8K of RAM and simply rely on the SD buffers. BTW, EEPROM is way too slow. The SD search method would only be implemented if the SDCARD.fth extensions have been loaded and the option selected otherwise everything will just run as it does now.
with last version long 20121013,1530
on Spin-Tool 1,2,6
I get Error: Address is out of range at line: 1688
in Terminal at:
un00 byte XCALL,xSPACE,REG,wordbuf,XCALL,xPSTR ' Spit out offending word
byte _WORD,$02,14,(EMIT),_ELSE,@un04-@un03
EMIT is highlighted ...
previous versions run wonderfully ...
while new to FORTH I learn a lot reading your souce code ... thanks a lot for sharing
MJB Markus from Germany
How does one 'cancel' an AUTORUN?
If I type "AUTORUN FOO" on the next and subsequent REBOOT, hardware reset, power-on reset TF will search for and execute FOO. If I then type "AUTORUN BAR" FOO is out and now AUTORUN looks for BAR.... what do I type to stop AUTORUN altogether?
In fact you can use any word that does not exist as this will always return with a null. To cancel it from code just access it's variable directly:
autorun W~
That's a strange one. The _EMIT word is named (EMIT) in the compiled dictionary only yet BST is quite happy to compile _EMIT in it's place even though I obviously have made a mistake in typing (EMIT).
So just correct that by typing _EMIT instead while I ponder over this mystery.
I was typing some examples into Tachyon.
this:
did not work.
So I started digging ... to find out why.
And ... added the functionality to the kernel.
Takes 3 longs in COG - If one wants to sacrifice this ...
I am still very new to Prop and Forth ... so I hope I did
not break s.th. else.
A first version of my parser to handle a legacy
command syntax is also working (http://forums.parallax.com/showthread.php?141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages&p=1128483#post1128483)
- and integrated to the TACHYON Terminal code.
Quite a challenge - and fun.
with the definition
: SUP ( U I -- ) ." !SUP " SWAP .DEC BL EMIT .DEC ;the input string:
is properly converted to
pushed back on front of the rxbuffer and
Forth takes care of the rest and evaluates it.
A nice example of the extensability of a Forth system.
Especially if all the source is available ... Thanks Peter ...
It looks like you are calling the loop words from the command line with out encapsulating them in a definition.
I don't know it this matters, but I don't think the branching functions are supposed to work from the command line, they are only supposed to be used within a word definition.
I think it was something about the way they use the return stack, you could get things out of whack if you did the wrong word in between.
Since I detest having Forth work differently from the command line I have made Tachyon compile before execute on the command line. So anything that you can do from within a definition you can do on the command line without any special words plus the timing is identical.
It also compiles word by word so once you've typed that word in and entered a space etc you can't go back. So if you make a mistake after that you need to discard the line with an <esc> key. Sometimes that's a nuisance but tolerable. I may make that part of it selectable in the future though.
Also, from the beginning, could not parse input in the form "-123" , but that can be gotten around by typing "123 NEGATE"
The TERMINAL definition is a bit long at present and I will get around to factoring the functions out so for one thing it will make it very easy to patch a specialized parser into a precompiled kernel. Talking about getting "a round tuit" there are little things like you came across with negative numbers in a loop for instance that I would get around to it eventually. Funny thing is I can't ever recall using negative indices in a loop before but I'm sure it would come in useful. I think I normally keep it positive and simply subtract the index from an offset.
Thanks for the code, I will get "a round tuit" later
Regarding the negative number input I did finally get a round tuit a little while back. It only took a couple of minutes to add the extra checking along with all the other prefix and suffix stuff that I do. BTW, the latest kernel will process anything that starts with # or $ or % and ends in a digit as a number rather than search the dictionary. This speeds up compilation but you might get caught as my L6470.fth source had some #cs1 and #cs2 constants etc which were being interpreted as 1 and 2 rather than the defined constant! Of course I just renamed these constants.
The Setup
Tachyon Forth 121013 - latest EXTEND and SDCARD
my JMSERVO2.fth
Prop BOE mounted on a BOEBOT
The errant code - a short script to see how the maneuvers actually look on the ground.
This code was copy pasted in and followed by
AUTORUN MAINLOOP3 BACKUP
The bot was set on a stand to keep the wheels off he desk. It was powered up with no power to the servos. It appeared to run oK. There is an LED commanded on in the background task "SERVOS."
Repeated with power to servos. They ran, they appeared to follow the script and did loop and repeat.
Shut bot down.. disconnected wall power, plugged in 6v battery pack and removed USB cable.
Put bot on floor, powered up BOE and servos ====> nada, zilch, NOTHING ... no LED from "ON SERVOS," no servos running
Pickup bot, plug in USB and "back in business!"
I have a vague recollection of this problem elsewhere ... what am I missing ?????????
RxLoop call #receive
if_nc jmp #abreak ' discard if framing error (no stop bits)
I may add a little extra checking on the serial driver to see if I can automatically disable the break detect in these circumstances.
AT this point the TxD and RxD were hanging empty, 'floating at TTL level.' As I said in my initial message on this matter I have some vague recollection of this problem. After further ruminations I am convinced its not TF's fault. The problem seems to lie in boards with built in USB.
Hi Brian, did you try commenting out that line in the serial Rx routine? However I suspect that the problem is with the way the USB chip is connected and that it also controls the reset line. A lot of these USB chips draw their power from the USB bus and so when it's unplugged the chip isn't directly powered. However the Txd line from the Prop is normally high and this feeds through the USB chip's substrate back into it's power and has a tendency to kick it into life after which it resets the Prop and so on ad infinitum. The simple solution for this is to simply have a current limit resistor from the Prop's Tx pin into the USB chip so that it can never draw enough power to kick in. There are variations on these solutions but that's a simple one. Try a value of 10K.
MEANWHILE, ON ANOTHER TANGENT ... I was working with your One-Wire code today. I took your suggestion and made "1WRESET DROP READROM" into a WORD "RD1ROM" I used it to read device IDs on a bunch of DS18B20s. Your READROM word or one of its support words is dropping a bit. Every one of my DS18B20s showed a device code of $14 instead of $28.
I have attached a copy of your 1 wire file with almost a dozen words appended to the end that should prove useful. Look at GETTEMP and see if you can figure why the two "1W@" always read all "F"s in my routine but gets realistic reads in your READROM.
Now to rummage through my backups and find my working spin code for 1--w ... failing that I may have to rummage in my [gasp!] Arduino stuff!
playing with unmodified TY I get this:
Terminal interaction uses the stack too so this always has to be taken into account. If a Forth is to be judged on the depth of it's stack then Tachyon probably is on the bottom of that stack! Like the philosophy of RISC where decisions are made to remove the complexity and run lean and mean so too there is a philosopy behind Tachyon vs conventional Forths which drive the decisions made. First off, the Prop is not real good with addressing stacks and there is not a lot of room in cog RAM to spare and hub RAM is too slow. Plus there has always been the problem with Forth with addressing items more then 3 or 4 levels deep. The decision therefore is to use cog RAM but for the individual VM instructions to run unimpeded by any stack somersaults the stack items need to be in a fixed place. So keep them fixed and move all the contents around when it comes to pushing and popping. But this is costly in terms of processor cycles etc so once again design the kernel in such a way that stack usage could be minimized etc.
So this brings us to your test which as mentioned earlier is flawed because you assume it's deeper than it is and you don't take into account stack usage just for handling terminal interaction and printing etc. Also the DEBUG word is high level so it must use the stack also although it's use is minimized. My very early Tachyon had the debugger in PASM and it could list everything perfectly without using the stack etc. But alas there is no way to have the machine level debugger and a Tachyon VM plus stacks etc resident in 496 longs.
The test for the stack handling should therefore be made from within a definition (or on a single line) and stack usage should be minimized. The data stack is only 12 longs deep so this is my simple version:
: N CR .BYTE ; ok
ok
: T 12 23 34 45 56 67 78 89 90 91 82 73
N N N N N N N N N N N N ; ok
T
73
82
91
90
89
78
67
56
45
00
00
00 ok
Notice that it seems to go 9 levels deep before it "loses" the first 3 items. That's because up to 3 items were pushed on top of the stack losing the first 3 items that were there and then subsequent popping results in zeros filling those voids. The zeros are popped into the most bottom level of the stack mainly for error checking but serve no other useful purpose.
How useful is a shallow stack? Well when combined with useful VM instructions which also use other stacks and fixed cog registers the results are very good. I've written working turn-key applications in Tachyon that testify to the workability of the approach taken to an embedded Forth that works in harmony with the Prop's unique architecture.
Would I love more cog RAM? You betcha! But that ain't ever going to happen, however P2 will have a lot of enhancements that Tachyon will exploit to the max, but that's next year.
Here's my additions to the toolbox that let me read temps and IDs etc
1st byte of ROMID should be $28 but it's $14. Enter the bits of that byte in reverse order and "." it. What do we get ... $28 !!!
1st 2 bytes of an idle SCRATCHPAD are supposed to be $50 and $05 ... same drill, again ... type them in in reverse bit order and dump the stack ... we get $05 and $50
Simply READ and compute the temperature ... what!! That cannot be!
Go right back and READ the TEMP and binary dump SCRATCHPAD. Enter the LSB and then the MSB as before in reverse bit order, execute the second half of GETTEMP, joining the LSB and MSB in one long on stack, then call PRINTTEMP to finish the job ... 23 degrees C is nominally accepted as "room temp."
I think it is pretty conclusive that "1W@" is the culprit and it needs to write the bits in reverse order!
In the meantime I wrote a not so quick and oh-so-dirty kluge that brute force puts the bits in the proper order. It is called FIX1W@ ... please don't laugh too hard ... remember it breaks nothing and allow one-wire to move forward while Peter tries to find time to solve the bug.
The bug patch call is a I sIngle word call as the last line in 1W@.
The file I attached is Peter's original code with FIX1W@ and the patched 1W@ and appended to the end is my 1-W extensions.
Hi Brian, I'm looking into it today so hang tight, I just never got around to doing anything more with this code at the time.
This is a READROM from an 18B20 which matches the family code:
READROM 28 AE 68 24 03 00 00 E4
So I will play with it a bit more today and see how it goes.
I rebuilt my TF load from COLD and applied your latest "1wire.fth" and then my extensions, "1WIREBBR.fth" on top of that sans my patches for 1W@. All OK nothing broken ... thank you!
Thanks Brian, I thought it was still a WIP until you said it all worked! I've changed the write routines to force the bus high to power any devices that rely on parasitic power. Your routines have also been incorporated in 1-Wire.fth with a few little changes.
Here's a test of a 18B20 temperature chip (warmed, cooled, then placed next to my i7 laptop's vent):
SHOWTEMPS
+036.81'C ************************************
+036.62'C ************************************
+036.06'C ************************************
+035.68'C ***********************************
+034.62'C **********************************
+034.68'C **********************************
+034.25'C **********************************
+033.31'C *********************************
+032.87'C ********************************
+032.50'C ********************************
+032.81'C ********************************
+033.12'C *********************************
+033.25'C *********************************
+033.31'C *********************************
+033.43'C *********************************
+033.50'C *********************************
+033.68'C *********************************
+033.68'C *********************************
+033.62'C *********************************
+032.87'C ********************************
+031.62'C *******************************
+031.00'C *******************************
+028.12'C ****************************
+026.62'C **************************
+026.31'C **************************
+025.81'C *************************
+024.43'C ************************
+024.18'C ************************
+022.37'C **********************
+021.68'C *********************
+021.81'C *********************
+022.18'C **********************
+022.50'C **********************
+023.18'C ***********************
+023.93'C ***********************
+024.62'C ************************
+025.18'C *************************
+025.62'C *************************
+026.06'C **************************
+026.68'C **************************
+027.93'C ***************************
+029.00'C *****************************
+029.81'C *****************************
+030.50'C ******************************
+029.18'C *****************************
+028.31'C ****************************
+029.56'C *****************************
+031.68'C *******************************
+033.43'C *********************************
+034.81'C **********************************
+036.18'C ************************************
+037.50'C *************************************
<snip>
+054.62'C ******************************************************
+054.68'C ****************************************************** ok
how much memory per thread do you estimate, and where will the context be saved? sal did software multitasking early on in propforth, but removed it as toocostly. now we are talking about adding it again, in preparation for prop2 and other experiments. we are talking about the PAUSE round robin from traditional forth, is this wha t you are doing using EXIT?
Here are the two code fragments:
[FONT=courier new] ''' EXIT mov R0,interrupts wc,wz if_nc_and_nz jmp #INTERRUPT 'service interrupts before restoring IP from return stack call #RPOPX mov IP,X jmp #doNEXT INTERRUPT mov R1,#@intvecs+s-4 ' point to interrupt vectors in hub ram (low address) scanirqs shr R0,#1 wc,wz ' test next irq bit (with a safety fence) add R1,#2 ' point to next word vector if_nc_and_nz jmp #scanirqs or interrupts,msb ' set inhibit rdword IP,R1 ' read in external vector jmp #doNEXT ' and execute (no need to save IP as it's not yet restored) [/FONT]