Still working on the 'bit banging' for manual mux of a 3-digit display. Right now there appears to be some 'ghosting' between the digits. I guess it's a matter of figuring out timing ... ! The circuit is pretty straight forward ... 3 transistors and a 74LS47 decoder for the segments.
In case you are struggling with the concept or coding here is my take on this and the result, try it for yourself.
TACHYON [~
--- P10 -P13 as digit value to a 74LS47 and P14 - P17 as digit select via PNPs ---
FORGET LED4.fth
: LED4.fth ;
#P10 == segpin
#P14 == selpin
TIMER scantmr --- use a timer to call LED scan routine
BYTE ledn --- led digit select count
4 BYTES leds --- led digit buffer uses a byte/4-bit character
: SCANLED
$0F selpin << OUTSET --- disable all PNP digit drives which blanks display
ledn C++ --- next digit (only lsbs of counter are used)
ledn C@ 3 AND leds + C@ >N --- read next character (4 lsbs)
$0F segpin << OUTCLR --- prep segments for I/O set mask
segpin << OUTSET --- write the segments to the pin group
ledn C@ 3 AND MASK --- proceed to next digit
selpin << OUTCLR --- write active low digit select lines (PNNs?)
10 scantmr TIMEOUT --- reload LED scan timer for 10ms
;
--- LED EMIT routine shifts valid characters into a 4-digit buffer
: (LED)
DUP "0" "9" WITHIN IF >N ELSE DROP $0F THEN --- blank all alphas and symbols etc
leds @ 8 << + leds ! --- insert new digit into right of display
scantmr @ 0= --- start up the scanner if it isn't running
IF 5 scantmr TIMEOUT ' SCANLED scantmr ALARM THEN
;
--- Switch stream output to the LED display
--- Usage: LED 123 . CON
: LED ' (LED) uemit W! ;
{ Testing
LED 5678 . CON ok
leds @ .LONG 0506.0708 ok
}
{ SPY on the outputs to test the software without hardware
Usage:
LED 1234 . CON ok
SPY
1111 02
0111 01
1111 01
1110 04
1111 04
1101 03
1111 03
1011 02
1111 02
0111 01
1111 01
1110 04
<etc>
}
: SPY
segpin 8 PINS@ --- setup for change of state
BEGIN
BEGIN segpin 8 PINS@ SWAP OVER <> UNTIL --- wait for a change of state and return with latest
CR
DUP 4 >> $402 PRINTNUM --- display binary digit select pattern
DUP >N SPACE .BYTE
ESC?
UNTIL
DROP
;
~] END
Obviously I have a little bug in there according to the SPY outputs so I will leave that for you to find perhaps?
Found my bug as I committed the big no-no of P1 in setting outputs from the console cog before handing it over to the background cog. So I changed the "SCANLED ' SCANLED scantmr ALARM" initialization to "5 scantmr TIMEOUT ' SCANLED scantmr ALARM" as the first version ran SCANLED which set the pins directly from the console cog.
EDIT: I also just realized that the 74LS47 is active low outputs so the digit select must be via PNPs so I've changed it to suit.
I get tripped up by several [*] things trying to read the source code.
One of these is IFDEF / INDEF . I take it these are compiler directives. Can you refer me to a reference where I can learn more about them?
Another is curly braces. I notice that there is often a closing } without an opening { . How does that work?
there is no such thing as compiler directives ...
all words are equal - and some are a bit more equal you know ;-)
IFDEF / IFNDEF are just 'dynamic' comments.
depending on the condition they just treat everything until the next matching } as a comment.
If not everything get's executed as normal and the spurious extra } is just ignored.
If you look in the code for the definition of IFDEF you can see it.
IFDEF byte XCALL,xNFATICK,ZEQ,JUMP,02
IFNDEF byte XCALL,xNFATICK,ZEXIT
' { Block comments - allow nested {{ }} operation
CURLY byte _1,REG,11,CSTORE ' allow nesting by counting braces
CURLYlp byte XCALL,xWKEY ' keep reading each char until we have a matching closing brace
byte DUP,_BYTE,"{",EQ,_IF,04,_1,REG,11,CPLUSST ' add up opening braces
byte _BYTE,"}",EQ,_IF,04,MINUS1,REG,11,CPLUSST ' count down closing braces
byte REG,11,CFETCH,ZEQ,_UNTIL,@CURLYxt-@CURLYlp
CURLYxt byte EXIT
this is precompiled forth byte code code from the tachyon extended kernel.
But after a while you learn to read it ;-)
so you can see IFDEF / IFNDEF just continue with the { comment behaviour,
or they exit and processing the code continues.
Still working on the 'bit banging' for manual mux of a 3-digit display. Right now there appears to be some 'ghosting' between the digits. I guess it's a matter of figuring out timing ... ! The circuit is pretty straight forward ... 3 transistors and a 74LS47 decoder for the segments.
Wow, manually muxing LED digits, this is going way back to very early days blindly typing in machine code into a monitor ROM without any display. The input was a surplus keyboard (no matrix) with a homespun matrix decoder and serializer pcb made from blank photo-laminate, taped up artwork, sunlight, developer and good ol' ferric chloride.
** I remember those ferric chloride days and always wondered where a safe place to dump the residue might be!!
To get a display I bought some surplus calculator LED displays, 5 digits apiece in a 14 pin DIP IIRC and used 3 of them for a 15-digit/alpha display.
So manually writing with pen and paper the assembly code, converting it to hex machine code while calculating addresses, punching that in through the new keyboard with only a single status LED to give me an indication that the monitor was still happy or not, and hoping I didn't make any mistakes as there was no storage as such. Slow and tedious, make a mistake, start all over again.
** My first processor was the Intel 8008, but moved over to the Signetics 2650 shortly after it became available.
Eventually the display sprang to life and there was that ghosting thing. I can't really remember but I'm pretty sure I figured out very quickly that this must be because I still had the segment lines active when I switched to the next digit. Even those few microseconds (or more) were enough for the eye to pick up.
The solution was simple of course, just blank the segment lines before switching which cleaned up the display nicely. Then I added the slow horizontal scrolling to it so now I had a "terminal" and I was in business, yay!
** Where to insert the blanking was making me scratch my head. It's been many years since I've tried this in Forth! Thanks for the reminder!
To blank the output of 74LS47 without using the dedicated blank lines you can output all 1's according to the truth table where $0F -> blank
BTW, The binaries have been updated, just use the VGA-EXPLORER.binary in the dropbox.
Just pulled down the aforementioned binary, but VER indicates 24 and not the 27 I expected.
Just pulled down the aforementioned binary, but VER indicates 24 and not the 27 I expected.
Just tried it myself loading this directly from the dropbox link into the Prop tool and it works as 2.7. Use this link for the VGA-EXPLORER binary which simply adds VGA.fth to it.
[/quote]
there is no such thing as compiler directives ...
all words are equal - and some are a bit more equal you know ;-)
IFDEF / IFNDEF are just 'dynamic' comments.
depending on the condition they just treat everything until the next matching } as a comment.
If not everything get's executed as normal and the spurious extra } is just ignored.
If you look in the code for the definition of IFDEF you can see it.
IFDEF byte XCALL,xNFATICK,ZEQ,JUMP,02
IFNDEF byte XCALL,xNFATICK,ZEXIT
' { Block comments - allow nested {{ }} operation
CURLY byte _1,REG,11,CSTORE ' allow nesting by counting braces
CURLYlp byte XCALL,xWKEY ' keep reading each char until we have a matching closing brace
byte DUP,_BYTE,"{",EQ,_IF,04,_1,REG,11,CPLUSST ' add up opening braces
byte _BYTE,"}",EQ,_IF,04,MINUS1,REG,11,CPLUSST ' count down closing braces
byte REG,11,CFETCH,ZEQ,_UNTIL,@CURLYxt-@CURLYlp
CURLYxt byte EXIT
this is precompiled forth byte code code from the tachyon extended kernel.
But after a while you learn to read it ;-)
so you can see IFDEF / IFNDEF just continue with the { comment behaviour,
or they exit and processing the code continues.
and if there is an extra }
byte $20,"}", hd+xc+im, _NOP,EXIT
the definition of the } word just ignores it[/quote]
Oy! I had found that in the extended kernel but I couldn't read it.
Kinda wanted to skip SPIN code and just come back home to Forth . . . and then Tachyon was so sexy . . .
So just a little more he'p with this please. For what type of condition are IFDEF and IFNDEF looking.
And if the condition is true then IFDEF will compile the following code and else it will be treated as a comment until the next "}" . . . and the reverse for IFNDEF ??
Oy! I had found that in the extended kernel but I couldn't read it.
Kinda wanted to skip SPIN code and just come back home to Forth . . . and then Tachyon was so sexy . . .
So just a little more he'p with this please. For what type of condition are IFDEF and IFNDEF looking.
And if the condition is true then IFDEF will compile the following code and else it will be treated as a comment until the next "}" . . . and the reverse for IFNDEF ??
Do I have that right?
Not all who wander are lost . . . but some are.
There aren't any "conditions" with IFDEF/IFNDEF as the only "itions" are definitions IF <this word here> is defined then continue as normal OTHERWISE treat everything up to the closing } as a comment. Simple! Isn't it?
It's a bit like in the Spin tool we didn't have a way to do conditional compile, we had to manually enclose unwanted sections in braces { } and remove or comment the braces on the sections we wanted such as '{ but that was messy and awkward. What we really wanted was to be able to say "compile this for a Quick Start" or "compile this for a BOE" and so in Tachyon if we define BOE in any form (CREATE CONSTANT : etc) it is now defined so that when we say IFDEF BOE then Tachyon will find BOE in the dictionary and proceed as normal. If it fails to find BOE it simply treats everything as a block comment up to the closing } although there is no actual opening brace, the IFDEF/IFNDEF takes its place.
So to summarize the IFDEF/IFNDEF takes the following word and depending on whether it finds it or not (true or false) will determine how to treat the following source, as a comment or to be compiled.
An example of this is in EXTEND.fth and abbreviated for this example is the lshw word to list the hardware info. We only want some of these features in the EXPLORER version as they can tend to be a bit verbose for such a small memory. So if EXPLORER is already defined then this definition will be compiled:
What I need to do next is interface one of the ESP8266 modules and get it working with FTP.
Hi Peter, I use ESP8266 with NodeMCU/Lua to upload data from Tachyon to Thingspeak. Code I referenced above and in the other thread. https://thingspeak.com/channels/39235
This is a good start and I have some ideas how to make a TELNET from it.
FTP can only use one socket, so needs to be handled a bit different fromthe Tachyon implementation.
since you are not editing on Google-Docs any more it is a bit more difficult to meet you online ... :-(
there is no such thing as compiler directives ...
all words are equal - and some are a bit more equal you know ;-)
IFDEF / IFNDEF are just 'dynamic' comments.
depending on the condition they just treat everything until the next matching } as a comment.
If not everything get's executed as normal and the spurious extra } is just ignored.
If you look in the code for the definition of IFDEF you can see it.
IFDEF byte XCALL,xNFATICK,ZEQ,JUMP,02
IFNDEF byte XCALL,xNFATICK,ZEXIT
' { Block comments - allow nested {{ }} operation
CURLY byte _1,REG,11,CSTORE ' allow nesting by counting braces
CURLYlp byte XCALL,xWKEY ' keep reading each char until we have a matching closing brace
byte DUP,_BYTE,"{",EQ,_IF,04,_1,REG,11,CPLUSST ' add up opening braces
byte _BYTE,"}",EQ,_IF,04,MINUS1,REG,11,CPLUSST ' count down closing braces
byte REG,11,CFETCH,ZEQ,_UNTIL,@CURLYxt-@CURLYlp
CURLYxt byte EXIT
FORGET totest ok
DOUBLE totest ok
ok
: SCRLEDS
#50000 totest TIMEOUT
BEGIN
23 16
DO
I DUP PINSET
50 ms
PINCLR
LOOP
totest TIMEOUT?
UNTIL
totest TIMEOUT? .S
; ok
ok
SCRLEDS Data Stack (1)
$FFFF.FFFF - -1 ok
Works fine the first run but if I try to run it again it freezes the machine. Does that have something to do with exiting the loop properly?
FORGET totest ok
DOUBLE totest ok
ok
: SCRLEDS
#50000 totest TIMEOUT
BEGIN
23 16
DO
I DUP PINSET
50 ms
PINCLR
LOOP
totest TIMEOUT?
UNTIL
totest TIMEOUT? .S
; ok
ok
SCRLEDS Data Stack (1)
$FFFF.FFFF - -1 ok
Works fine the first run but if I try to run it again it freezes the machine. Does that have something to do with exiting the loop properly?
Originally timer variables were constructed with DOUBLE but that was quite some time ago. Use TIMER instead as that will create the correct stucture in this case two longs and a word which is used to link to other timers. The old version just dedicated room for 8 timers in one block whereas the newer version links these dynamically and transparently at runtime, as many as can be linked.
TIMER totest
: SCRLEDS 50,000 totest TIMEOUT BEGIN 23 16 DO I HIGH 50 ms I LOW LOOP totest TIMEOUT? UNTIL ;
No need to check the timeout at the end as that would be redundant, it will always be true since that is the only way it can exit via the UNTIL
The code for SCANLEDS is running smoothly but now I am experimenting with running it in it's own cog. Everything is fine until it completes and I can't figure how to get the cog to stop and return control and I/O to COG 0. I've tried a lot of different things and can't figure it out. The system just seems to stop and/or be disassociated from the terminal.
FORGET totest
TIMER totest
: SCANLEDS
#5000 totest TIMEOUT
BEGIN
#23 #16
DO
I DUP PINSET
50 ms
PINCLR
LOOP
totest TIMEOUT?
UNTIL
;
' SCANLEDS 5 RUN
I have tried a variety of things after UNTIL - like 5 STOP, 5 COGSTOP, etc. Without results. Whaddami missin'?
There is no need to stop it since cog 5 was already running an IDLE loop and RUN simply gave it a job to do. In fact never use STOP as that will stop the cog completely not even running its IDLE loop. Once it was done it returns back to the IDLE loop and since your last pin operations were all PINCLR (or LOW) there is no need to worry further unless you want the direction itself released in which case you would use.
TIMER totest
: SCANLEDS 5,000 totest TIMEOUT BEGIN 23 16 DO I HIGH 50 ms I FLOAT LOOP totest TIMEOUT? UNTIL ;
This is assuming that your LEDs are active high of course but otherwise after the UNTIL you could just say 16 8 MASKS INPUTS to release the outputs on all the affected bits.
BTW, shouldn't the range be 24 16 for 8 LEDs as the LOOP exits when it increments the index and hits or crosses the limit which in your case is 23 which would never be looped. That is why I tend to use the ADO word and instead would say "16 8 ADO" so that it will start from 16 and loop 8 times from 16 to and including 23.
and looking at the I/O pin state (I have an RC connected to P20)
lsio PORT PINS
+--------------------------------+
P00 inp L down || H inp P31
P01 inp L float || H out P30
P02 inp L float || up H inp P29
P03 inp L float || float L inp P28
P04 inp H up || up H inp P27
P05 inp L float || float L inp P26
P06 inp L float || float L inp P25
P07 inp L float || float L inp P24
P08 inp H up || float L inp P23
P09 inp L float || float L inp P22
P10 inp L float || float L inp P21
P11 inp L float || up H inp P20
P12 inp H up || float L inp P19
P13 inp L float || float L inp P18
P14 inp L float || float L inp P17
P15 inp L float || float L inp P16
+--------------------------------+ ok
Yeah, the lockup will be because that cog also tries to emit on the same serial TX pin as the main cog and after it's done it leaves the pin as a high output, unable to be overridden by the console cog thereafter nor is the new cog able to transmit either as the transmit is already high etc. Nonetheless the second cog is unable to print the number successfully as its default stack size is only 4 deep which is okay for simple loops but insufficient for conversion operations inside of number printing.
However this will work:
TIMER totest
: SCANLEDS 30 HIGH 5,000 totest TIMEOUT BEGIN 23 16 DO I HIGH 50 ms I FLOAT LOOP totest TIMEOUT? UNTIL CR PRINT" COGID- " COGID "0" + EMIT CR 30 FLOAT ;
' SCANLEDS 5 RUN 30 FLOAT 7 seconds
For some reason my sig doesn't always appear so here are the links to Tachyon and if you just want to play with it I recommend to just click on the first link with the Explorer binary ready to go at 115,200 baud.
Just been tweaking the virtual memory layers of the filesystem so that random byte reads execute a little faster when the sector is already cached. Without anything too special the random cached byte/word/long read takes 18.2us or 2ms if the sector is not cached. Since there are buffers for up to four open files this also helps to keep a sector cached.
So an indexed read of 32K takes 804ms and that doesn't use any dedicated cog for this, just a couple of short and simple RUNMOD modules that get loaded as new instructions when needed. There is no sequential RDBYTE definition but since it's only a one-liner I will add it anyway.
32K indexed read:
$8000 0 LAP DO I XC@ DROP LOOP LAP .LAP 804.342ms ok
EDIT: If you read longs instead of bytes it's much faster: $8000 0 LAP DO I X@ DROP 4 +LOOP LAP .LAP 311.184ms ok
Also the time it takes to find and open a file is:
" FIRMWARE.ROM" LAP FOPEN$ DROP LAP .LAP 2.887ms ok
Remember too that you can traverse folders and also select multiple drives if the pins for these have been defined, as normally we only need a chip select extra.
Just been tweaking the virtual memory layers of the filesystem so that random byte reads execute a little faster when the sector is already cached. Without anything too special the random cached byte/word/long read takes 18.2us or 2ms if the sector is not cached. Since there are buffers for up to four open files this also helps to keep a sector cached.
So an indexed read of 32K takes 804ms and that doesn't use any dedicated cog for this, just a couple of short and simple RUNMOD modules that get loaded as new instructions when needed. There is no sequential RDBYTE definition but since it's only a one-liner I will add it anyway.
32K indexed read:
$8000 0 LAP DO I XC@ DROP LOOP LAP .LAP 804.342ms ok
EDIT: If you read longs instead of bytes it's much faster: $8000 0 LAP DO I X@ DROP 4 +LOOP LAP .LAP 311.184ms ok
Also the time it takes to find and open a file is:
" FIRMWARE.ROM" LAP FOPEN$ DROP LAP .LAP 2.887ms ok
Remember too that you can traverse folders and also select multiple drives if the pins for these have been defined, as normally we only need a chip select extra.
The folder navigation is fairly simple but I plan to add full path names as well if necessary.
A sector write seems to take around 4ms so I guess you could interleave buffers if you need higher speeds so this would give a sustained 128kBytes/sec. Sustained read speeds of 250kBytes/sec are possible too as average sector read is around 2ms. Now, if I dedicate a cog just for SD SPI imagine the speeds I'd get then.
The folder navigation is fairly simple but I plan to add full path names as well if necessary.
A sector write seems to take around 4ms so I guess you could interleave buffers if you need higher speeds so this would give a sustained 128kBytes/sec. Sustained read speeds of 250kBytes/sec are possible too as average sector read is around 2ms.
I was thinking of a SD-card logging 'logic analyzer'
just writing all 32 pins at max speed to SD
so with above numbers this should run @ 32kHz
(or 8 bits @128kHz)
and a 4GB SD would last > 8 hours !!
Now, if I dedicate a cog just for SD SPI imagine the speeds I'd get then.
a resident RUNMOD should give most of the speedup - isn't it.
running in a small Tachyon code in a separate COG
you implemented hierarchical folder structure ???
wow - completely missed it if you mentioned it before.
just read the new source -
unbelievable how little code is required
You can do a lot in one line when you know what you are doing!
Try "ON PROMPT ON OK" which will change the prompt to indicate the PCB ID if it has been set and also the SD card's serial# and current working directory, like this:
Change the card and remount (I might make that automatic in fact) and there's the new serial number. Maybe I might include the name too.
So when you are talking fast data logging are you talking faster than 128kByte/sec? I think I might be able to increase that by dedicating a cog to SD if necessary.
You can do a lot in one line when you know what you are doing!
So when you are talking fast data logging are you talking faster than 128kByte/sec? I think I might be able to increase that by dedicating a cog to SD if necessary.
no need for faster logging right now
- my thoughts were just exploring the limits
Is there a Q&E way to see a number on the stack expressed in binary form when it exceeds $1FF.FFFF ?
That's a strange request, to check to see if a number exceeds a certain limit and if so to then express it in binary? I'm sure that isn't too hard to do but you may as well express it in binary all the time as well as decimal and hex of course with this code:
BL NFA' .S ?DUP IF 1+ C! THEN --- disable kernel's version of .S as otherwise this would take precedence
pub .S
PRINT" Data Stack (" DEPTH PRINT PRINT" )"
DEPTH IF
16 COGREG@ 8 + DEPTH 4* OVER +
BEGIN
CR "$" EMIT DUP @ DUP .LONG
PRINT" - %" DUP $1F02 PRINTNUM
PRINT" - " $0A PRINTNUM
4 - 2DUP 4 - =
UNTIL
2DROP
THEN
;
The trouble is that the binary print part of this code doesn't seem to work at the moment as I seem to have a bug in my number formatting for long numbers such as 32-bit binary numbers although 16-bit are fine. I will have to sort this out first as I have a feeling that when I butted up the end of the ascending word buffer with the end of the descending number that something has gone awry.
If a cog is running a loop and listens with ATN@ can you send UNLOOP with ATN! to exit the loop?
Generally the question is what is the form of 'cmd'.
( To talk to tasks in other cogs )
ATN! ( cmd cog -- )
Well ATN@ and ATN! is just a way of passing a byte between tasks much as KEY or EMIT would do so it's up to the software to interpret it anyway it wants to. So you can't send an UNLOOP command but that gets me to thinking that maybe that's not a bad way to talk to it either. There would have to be a SETCMD and a RUNCMD though.
The truth is I've never used any of these words as I put them there mainly at user request. If you let me know a bit more about what you want to do I may come up with a better scheme.
I'm just trying to understand the difference between the ATN words and the ENQ words. I've experimented successfully with the ENQ words - they seem to just pass a data word. With ENQ it is "dataWord" - that's pretty clear. With ATN it is "cmdWord". I don't understand the difference.
I'm just trying to understand the difference between the ATN words and the ENQ words. I've experimented successfully with the ENQ words - they seem to just pass a data word. With ENQ it is "dataWord" - that's pretty clear. With ATN it is "cmdWord". I don't understand the difference.
Is the difference just the direction of the data flow?
I'm just trying to understand the difference between the ATN words and the ENQ words. I've experimented successfully with the ENQ words - they seem to just pass a data word. With ENQ it is "dataWord" - that's pretty clear. With ATN it is "cmdWord". I don't understand the difference.
Is the difference just the direction of the data flow?
OK, I just confirmed that. I found the term "command" confusing. I guess you could send the address of a word such as UNLOOP to a cog if you needed to.
I'm just trying to understand the difference between the ATN words and the ENQ words. I've experimented successfully with the ENQ words - they seem to just pass a data word. With ENQ it is "dataWord" - that's pretty clear. With ATN it is "cmdWord". I don't understand the difference.
Is the difference just the direction of the data flow?
OK, I just confirmed that. I found the term "command" confusing. I guess you could send the address of a word such as UNLOOP to a cog if you needed to.
Just trying to find the handle on these tools.
ATN@ ( -- cmdword ) reads in this cog's command which is sent by another cog and also clears it.
So you could pass the address of an actual definition to be executed if you wanted and in your code you might have: ATN@ ?DUP IF CALL THEN
ENQ! ( enqword -- ) --- may be sent as a response to a command or sent as status
--- there is no handshake here except if the receiving cog clears it in which case you could use:
" READY" ENQ! --- send the address of the ready message (perhaps)
BEGIN COGID ENQ? 0= UNTIL --- wait until the response has been "acknowledged" (perhaps, although this is potentially blocking)
ATN! ( cmdword cog -- ) --- use this if you want to send a message or command or data to another task which of course depends upon that task using ATN@ ATN? ( cog -- cmdword ) --- check to see if the command that was sent (by any cog) has been processed yet (zero). ENQ@ ( cog -- enqword ) --- read back and clear the response from a cog, perhaps the one we sent a command to
' UNLOOP 5 ATN! --- command cog 5 to UNLOOP
( maybe wait or poll )
5 ENQ@ ?DUP IF CR ." Response from cog 5 is " PRINT$ THEN --- if cog 5 has a response then interpret that as a string (points to string in hub memory)
Since I have never really used this mechanism I will try to incorporate the words into a demo.
BTW, the terms cmdword, datword, enqword or whatever are just used as an indication that it is a word but how the application uses it is up to the application
Comments
One of these is IFDEF / INDEF . I take it these are compiler directives. Can you refer me to a reference where I can learn more about them?
Another is curly braces. I notice that there is often a closing } without an opening { . How does that work?
there is no such thing as compiler directives ...
all words are equal - and some are a bit more equal you know ;-)
IFDEF / IFNDEF are just 'dynamic' comments.
depending on the condition they just treat everything until the next matching } as a comment.
If not everything get's executed as normal and the spurious extra } is just ignored.
If you look in the code for the definition of IFDEF you can see it.
IFDEF byte XCALL,xNFATICK,ZEQ,JUMP,02 IFNDEF byte XCALL,xNFATICK,ZEXIT ' { Block comments - allow nested {{ }} operation CURLY byte _1,REG,11,CSTORE ' allow nesting by counting braces CURLYlp byte XCALL,xWKEY ' keep reading each char until we have a matching closing brace byte DUP,_BYTE,"{",EQ,_IF,04,_1,REG,11,CPLUSST ' add up opening braces byte _BYTE,"}",EQ,_IF,04,MINUS1,REG,11,CPLUSST ' count down closing braces byte REG,11,CFETCH,ZEQ,_UNTIL,@CURLYxt-@CURLYlp CURLYxt byte EXITthis is precompiled forth byte code code from the tachyon extended kernel.But after a while you learn to read it ;-)
so you can see IFDEF / IFNDEF just continue with the { comment behaviour,
or they exit and processing the code continues.
and if there is an extra } the definition of the } word just ignores it
Just pulled down the aforementioned binary, but VER indicates 24 and not the 27 I expected.
Just tried it myself loading this directly from the dropbox link into the Prop tool and it works as 2.7. Use this link for the VGA-EXPLORER binary which simply adds VGA.fth to it.
EDIT: I see you problem, maybe you did something like this rather than reading the boot message:
The actual 32-bit version number encoded as 27150720 is at location 24 which VER points to and may be used by software to check the version number.
there is no such thing as compiler directives ...
all words are equal - and some are a bit more equal you know ;-)
IFDEF / IFNDEF are just 'dynamic' comments.
depending on the condition they just treat everything until the next matching } as a comment.
If not everything get's executed as normal and the spurious extra } is just ignored.
If you look in the code for the definition of IFDEF you can see it.
IFDEF byte XCALL,xNFATICK,ZEQ,JUMP,02 IFNDEF byte XCALL,xNFATICK,ZEXIT ' { Block comments - allow nested {{ }} operation CURLY byte _1,REG,11,CSTORE ' allow nesting by counting braces CURLYlp byte XCALL,xWKEY ' keep reading each char until we have a matching closing brace byte DUP,_BYTE,"{",EQ,_IF,04,_1,REG,11,CPLUSST ' add up opening braces byte _BYTE,"}",EQ,_IF,04,MINUS1,REG,11,CPLUSST ' count down closing braces byte REG,11,CFETCH,ZEQ,_UNTIL,@CURLYxt-@CURLYlp CURLYxt byte EXITthis is precompiled forth byte code code from the tachyon extended kernel.But after a while you learn to read it ;-)
so you can see IFDEF / IFNDEF just continue with the { comment behaviour,
or they exit and processing the code continues.
and if there is an extra } the definition of the } word just ignores it[/quote]
Oy! I had found that in the extended kernel but I couldn't read it.
Kinda wanted to skip SPIN code and just come back home to Forth . . . and then Tachyon was so sexy . . .
So just a little more he'p with this please. For what type of condition are IFDEF and IFNDEF looking.
And if the condition is true then IFDEF will compile the following code and else it will be treated as a comment until the next "}" . . . and the reverse for IFNDEF ??
Do I have that right?
Not all who wander are lost . . . but some are.
There aren't any "conditions" with IFDEF/IFNDEF as the only "itions" are definitions
It's a bit like in the Spin tool we didn't have a way to do conditional compile, we had to manually enclose unwanted sections in braces { } and remove or comment the braces on the sections we wanted such as '{ but that was messy and awkward. What we really wanted was to be able to say "compile this for a Quick Start" or "compile this for a BOE" and so in Tachyon if we define BOE in any form (CREATE CONSTANT : etc) it is now defined so that when we say IFDEF BOE then Tachyon will find BOE in the dictionary and proceed as normal. If it fails to find BOE it simply treats everything as a block comment up to the closing } although there is no actual opening brace, the IFDEF/IFNDEF takes its place.
So to summarize the IFDEF/IFNDEF takes the following word and depending on whether it finds it or not (true or false) will determine how to treat the following source, as a comment or to be compiled.
An example of this is in EXTEND.fth and abbreviated for this example is the lshw word to list the hardware info. We only want some of these features in the EXPLORER version as they can tend to be a bit verbose for such a small memory. So if EXPLORER is already defined then this definition will be compiled:
If the EXPLORER word in any form is not found then the equivalent of that would be:
{ pub lshw CR lsclk CR lsio CR lsregs CR lsi2c CR CR PRINT" Hardware signature = " iosig @ .LONG "," EMIT iosig 4 + @ .LONG i2csig 4 FOR "," EMIT DUP @ .LONG 4 + NEXT DROP DECIMAL ; }That is, everything after the EXPLORER word is treat as if it were a comment.Try this:
CREATE EARTH
IFNDEF EARTH PRINT" Lost in Space" }
IFDEF EARTH PRINT" Home Sweet Home" }
Hi Peter, I use ESP8266 with NodeMCU/Lua to upload data from Tachyon to Thingspeak. Code I referenced above and in the other thread.
https://thingspeak.com/channels/39235
This is a good start and I have some ideas how to make a TELNET from it.
FTP can only use one socket, so needs to be handled a bit different fromthe Tachyon implementation.
since you are not editing on Google-Docs any more it is a bit more difficult to meet you online ... :-(
all words are equal - and some are a bit more equal you know ;-)
IFDEF / IFNDEF are just 'dynamic' comments.
depending on the condition they just treat everything until the next matching } as a comment.
If not everything get's executed as normal and the spurious extra } is just ignored.
If you look in the code for the definition of IFDEF you can see it.
IFDEF byte XCALL,xNFATICK,ZEQ,JUMP,02 IFNDEF byte XCALL,xNFATICK,ZEXIT ' { Block comments - allow nested {{ }} operation CURLY byte _1,REG,11,CSTORE ' allow nesting by counting braces CURLYlp byte XCALL,xWKEY ' keep reading each char until we have a matching closing brace byte DUP,_BYTE,"{",EQ,_IF,04,_1,REG,11,CPLUSST ' add up opening braces byte _BYTE,"}",EQ,_IF,04,MINUS1,REG,11,CPLUSST ' count down closing braces byte REG,11,CFETCH,ZEQ,_UNTIL,@CURLYxt-@CURLYlp CURLYxt byte EXIT[/quote]A real fine explanation. Thank you very much.
Originally timer variables were constructed with DOUBLE but that was quite some time ago. Use TIMER instead as that will create the correct stucture in this case two longs and a word which is used to link to other timers. The old version just dedicated room for 8 timers in one block whereas the newer version links these dynamically and transparently at runtime, as many as can be linked.
No need to check the timeout at the end as that would be redundant, it will always be true since that is the only way it can exit via the UNTIL
I have tried a variety of things after UNTIL - like 5 STOP, 5 COGSTOP, etc. Without results. Whaddami missin'?
TIMER totest
: SCANLEDS 5,000 totest TIMEOUT BEGIN 23 16 DO I HIGH 50 ms I FLOAT LOOP totest TIMEOUT? UNTIL ;
This is assuming that your LEDs are active high of course but otherwise after the UNTIL you could just say 16 8 MASKS INPUTS to release the outputs on all the affected bits.
BTW, shouldn't the range be 24 16 for 8 LEDs as the LOOP exits when it increments the index and hits or crosses the limit which in your case is 23 which would never be looped. That is why I tend to use the ADO word and instead would say "16 8 ADO" so that it will start from 16 and loop 8 times from 16 to and including 23.
Testing this however: then after 5 seconds and looking at the I/O pin state (I have an RC connected to P20)
The fact that inactive COGs are running IDLE constantly went right over my head. I think I didn't know what to make of this in the intro: Anyway I found the thing that was messing me up originally was trying to get the TASK to identify the COG with: Looks like that is not allowed because it caused a lockup with the TASK finished.
However this will work:
Propeller Hardware Explorer with VGA
Tachyon Dropbox files and binaries (latest)
Introduction to TACHYON Forth
Tachyon Forth Resource Links
Tachyon Web Server based WIZnet chips and EASYNET software
FTP: ftp://tachyonforth.com
Telnet: tachyonforth.com 10001
Watch Easynet in operation
EDIT: these links have also been added to the top post.
So an indexed read of 32K takes 804ms and that doesn't use any dedicated cog for this, just a couple of short and simple RUNMOD modules that get loaded as new instructions when needed. There is no sequential RDBYTE definition but since it's only a one-liner I will add it anyway.
32K indexed read:
$8000 0 LAP DO I XC@ DROP LOOP LAP .LAP 804.342ms ok
EDIT: If you read longs instead of bytes it's much faster: $8000 0 LAP DO I X@ DROP 4 +LOOP LAP .LAP 311.184ms ok
Also the time it takes to find and open a file is:
" FIRMWARE.ROM" LAP FOPEN$ DROP LAP .LAP 2.887ms ok
Remember too that you can traverse folders and also select multiple drives if the pins for these have been defined, as normally we only need a chip select extra.
In the meantime I'm looking at some other enhancements and will release these shortly.
wow - completely missed it if you mentioned it before.
we can open the same file twice ??
so we could do fast logging on alternating sectors ??
A sector write seems to take around 4ms so I guess you could interleave buffers if you need higher speeds so this would give a sustained 128kBytes/sec. Sustained read speeds of 250kBytes/sec are possible too as average sector read is around 2ms. Now, if I dedicate a cog just for SD SPI imagine the speeds I'd get then.
unbelievable how little code is required
I was thinking of a SD-card logging 'logic analyzer'
just writing all 32 pins at max speed to SD
so with above numbers this should run @ 32kHz
(or 8 bits @128kHz)
and a 4GB SD would last > 8 hours !! a resident RUNMOD should give most of the speedup - isn't it.
running in a small Tachyon code in a separate COG
You can do a lot in one line when you know what you are doing!
Try "ON PROMPT ON OK" which will change the prompt to indicate the PCB ID if it has been set and also the SD card's serial# and current working directory, like this:
Change the card and remount (I might make that automatic in fact) and there's the new serial number. Maybe I might include the name too.
So when you are talking fast data logging are you talking faster than 128kByte/sec? I think I might be able to increase that by dedicating a cog to SD if necessary.
no need for faster logging right now
- my thoughts were just exploring the limits
If a cog is running a loop and listens with ATN@ can you send UNLOOP with ATN! to exit the loop?
Generally the question is what is the form of 'cmd'.
( To talk to tasks in other cogs )
ATN! ( cmd cog -- )
BL NFA' .S ?DUP IF 1+ C! THEN --- disable kernel's version of .S as otherwise this would take precedence pub .S PRINT" Data Stack (" DEPTH PRINT PRINT" )" DEPTH IF 16 COGREG@ 8 + DEPTH 4* OVER + BEGIN CR "$" EMIT DUP @ DUP .LONG PRINT" - %" DUP $1F02 PRINTNUM PRINT" - " $0A PRINTNUM 4 - 2DUP 4 - = UNTIL 2DROP THEN ;The trouble is that the binary print part of this code doesn't seem to work at the moment as I seem to have a bug in my number formatting for long numbers such as 32-bit binary numbers although 16-bit are fine. I will have to sort this out first as I have a feeling that when I butted up the end of the ascending word buffer with the end of the descending number that something has gone awry.Well ATN@ and ATN! is just a way of passing a byte between tasks much as KEY or EMIT would do so it's up to the software to interpret it anyway it wants to. So you can't send an UNLOOP command but that gets me to thinking that maybe that's not a bad way to talk to it either. There would have to be a SETCMD and a RUNCMD though.
The truth is I've never used any of these words as I put them there mainly at user request. If you let me know a bit more about what you want to do I may come up with a better scheme.
OK, I just confirmed that. I found the term "command" confusing. I guess you could send the address of a word such as UNLOOP to a cog if you needed to.
Just trying to find the handle on these tools.
So you could pass the address of an actual definition to be executed if you wanted and in your code you might have:
ATN@ ?DUP IF CALL THEN
ENQ! ( enqword -- ) --- may be sent as a response to a command or sent as status
--- there is no handshake here except if the receiving cog clears it in which case you could use:
" READY" ENQ! --- send the address of the ready message (perhaps)
BEGIN COGID ENQ? 0= UNTIL --- wait until the response has been "acknowledged" (perhaps, although this is potentially blocking)
ATN! ( cmdword cog -- ) --- use this if you want to send a message or command or data to another task which of course depends upon that task using ATN@
ATN? ( cog -- cmdword ) --- check to see if the command that was sent (by any cog) has been processed yet (zero).
ENQ@ ( cog -- enqword ) --- read back and clear the response from a cog, perhaps the one we sent a command to
' UNLOOP 5 ATN! --- command cog 5 to UNLOOP
( maybe wait or poll )
5 ENQ@ ?DUP IF CR ." Response from cog 5 is " PRINT$ THEN --- if cog 5 has a response then interpret that as a string (points to string in hub memory)
Since I have never really used this mechanism I will try to incorporate the words into a demo.
BTW, the terms cmdword, datword, enqword or whatever are just used as an indication that it is a word but how the application uses it is up to the application