Hi Peter,
this is the output at boot. You see, we have EXTEND, TOOLS, etc. loaded. Free memory: 1560, stack level 0 is correct. We removed not needed code from EXTEND to have more free memory. The sd card is detected correctly. The network is started, LINK *UP* correct, IP's etc. are ok.
What seemed strange: Socket #3 shows IP &192.168.1.101 which was an old connection. But after we reset the wiznet chip, the IP is 0.0.0.0, so that behavior looks ok.
A next try which complete power down and restart showed the same result: stack level (2) and values are unchanged.
We will now remove the INIT so we can manually start the modules and locate the stack change.
Propeller .:.:--TACHYON--:.:. Forth V5r4 NEON 540180811.0000
*** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V5r4 NEON 540180811.0000
4EE4: EASYNET WIZNET NETWORK SERVERS 180319.0000
4850: W5500 WIZNET W5500 driver 180319.1100
3766: EASYFILE SDHC card + FAT32 Virtual Memory File System V1.2 171024-0000
2FF4: TOOLS DEV TOOLS
1980: EXTEND Primary extensions to TACHYON V5 kernel - 180915-1900
AUTORUN BOOT 2F82
FREQ = 96.00MHZ
*** INITS ***
MOUNT 3DA4
ifup 51FA
*** ROMS ***
C01C: UART 468
C204: BLINKY1 28
C234: BLINKY2 32
C268: BLINKY3 32
*** I2C ***
$A0 EE/RTC
$A2 EE/RTC
INTERCOM:
CODE:$523E = 20542 bytes
NAME:$5856 = 7082 bytes
DATA:$784F = 831 bytes
FREE: = 1560 bytes
Data Stack (0)
Mon, 01 Jan 2001 00:00:01 UTC
CARD: SL32G SD03.80 #DD3D.6825 2017/3 !C0FF.80C3 1,413us
FAT: #6464.6433 NO NAME FAT32 31,910,789,120 bytes (32kB clusters)
*** Tachyon Forth EASYNET Network Servers and EASYFILE File Server ***
NETWORK STATUS:
LINK *UP*
HARDWARE: WIZnet W5500 V4
SRC IP &192.168.1.213
MASK &255.255.255.0
GATEWAY &192.168.1.1
MAC 02.FF.E2.20.64.2E.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#3 00:00:03 TCP 32797 23072 0000.0000.0000.0000.0000. 04 14 14 &192.168.1.101
* Servers running *
--------------------------------------------------------------------------------
... .S Data Stack (2)
$0000.51DA - 20954
$0000.51CE - 20942
ok
Hi Peter,
this is the output at boot. You see, we have EXTEND, TOOLS, etc. loaded. Free memory: 1560, stack level 0 is correct. We removed not needed code from EXTEND to have more free memory. The sd card is detected correctly. The network is started, LINK *UP* correct, IP's etc. are ok.
What is strange:
Propeller .:.:--TACHYON--:.:. Forth V5r4 NEON 540180811.0000
*** MODULES *** Propeller .:.:--TACHYON--:.:. Forth V5r4 NEON 540180811.0000
4EE4: EASYNET WIZNET NETWORK SERVERS 180319.0000
4850: W5500 WIZNET W5500 driver 180319.1100
3766: EASYFILE SDHC card + FAT32 Virtual Memory File System V1.2 171024-0000
2FF4: TOOLS DEV TOOLS
1980: EXTEND Primary extensions to TACHYON V5 kernel - 180915-1900
AUTORUN BOOT 2F82
FREQ = 96.00MHZ
*** INITS ***
MOUNT 3DA4
ifup 51FA
*** ROMS ***
C01C: UART 468
C204: BLINKY1 28
C234: BLINKY2 32
C268: BLINKY3 32
*** I2C ***
$A0 EE/RTC
$A2 EE/RTC
INTERCOM:
CODE:$523E = 20542 bytes
NAME:$5856 = 7082 bytes
DATA:$784F = 831 bytes
FREE: = 1560 bytes
Data Stack (0)
Mon, 01 Jan 2001 00:00:01 UTC
CARD: SL32G SD03.80 #DD3D.6825 2017/3 !C0FF.80C3 1,413us
FAT: #6464.6433 NO NAME FAT32 31,910,789,120 bytes (32kB clusters)
*** Tachyon Forth EASYNET Network Servers and EASYFILE File Server ***
NETWORK STATUS:
LINK *UP*
HARDWARE: WIZnet W5500 V4
SRC IP &192.168.1.213
MASK &255.255.255.0
GATEWAY &192.168.1.1
MAC 02.FF.E2.20.64.2E.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#3 00:00:03 TCP 32797 23072 0000.0000.0000.0000.0000. 04 14 14 &192.168.1.101
* Servers running *
--------------------------------------------------------------------------------
... .S Data Stack (2)
$0000.51DA - 20954
$0000.51CE - 20942
ok
Peter,
I found your old Neopixel driver for WS2812 but it is not updated for Neon. Where do I find the newest WS2812 RUNMOD that will work with the V5r4 kernel?
Peter,
I found your old Neopixel driver for WS2812 but it is not updated for Neon. Where do I find the newest WS2812 RUNMOD that will work with the V5r4 kernel?
unless you have really big and fast updates you can do without runmod and just bitbang it
some old code I found
: XLED ( ggrrbb -- ) L 50 us 8 REV 24 FOR DUP 1 AND IF H H L ELSE H L L THEN 2/ NEXT DROP ;
: XLED ( ggrrbb pin -- ) DUP PIN MASK SWAP L 50 us 8 REV 24 FOR H SHROUT L NEXT DROP ;
: XLED ( ggrrbb pin -- ) DUP PIN L MASK SWAP 8 REV 24 FOR H SHROUT L NEXT 2DROP ;
: XLEDS ( array cnt pin -- ) DUP PIN L MASK -ROT ADO I @ 8 REV 24 FOR H SHROUT L NEXT DROP 4 +LOOP DROP ;
: XLEDS ( array leds pin -- ) DUP PIN L MASK -ROT 3 * ADO I C@ 8 FOR H SHROUT L NEXT DROP LOOP DROP ;
--- ( 0062 $2D6E ok ) 0 1000 14 LAP XLEDS LAP .LAP
--- 4657456 cycles at 96000000Hz or 48.515ms
{ this version uses IC@ which replaces tos with byte from loop indexed memory
}
: XLEDS ( array leds pin -- ) DUP PIN L MASK -ROT 0 -ROT 3 * ADO IC@ 8 FOR H SHROUT L NEXT LOOP 2DROP 50 us ;
: XLEDS ( array leds pin -- ) DUP PIN L MASK -ROT 0 -ROT 3 * ADO IC@ 8 FOR L H SHROUT NEXT L LOOP 2DROP 50 us ;
--- ( 0041 $2D46 ok ) 0 1000 14 LAP XLEDS LAP .LAP
--- 4177824 cycles at 96000000Hz or 43.519ms
: P $7E00 + C! ;
: O $7E00 40 14 XLEDS ;
: XLEDS ( array leds pin -- )
OP <---- stack DESC
------------------------------------------------------------------------------------
DUP array leds pin pin
PIN array leds pin set fast pin
L array leds pin fast pin low
MASK array leds pinmask create mask for SHROUT ops
-ROT pinmask array leds work dummy data into the correct position
0 pinmask array leds 0
-ROT pimask 0 array leds
3 pinmask 0 array leds 3 convert leds to byte count
* pinmask 0 array bytes
ADO pinmask 0 start a loop using start address and count
IC@ pinmask data replace data with the next byte pointed to by loop index
8 pinmask data 8 for 8 times
FOR pinmask data
H pinmask data output a high
SHROUT pinmask data>> output a data bit
L pinmask data>> output a low
NEXT " " next bit
LOOP " " loop for another byte
2DROP discard parameters
50 50 delay for 50 us
us
; return
( 0084 $3002 ok ) SEE XLEDS
--- Spin near equivalent Pseudo assembly
2D0E DUP
2D10 PIN pinreg := pin mov pinreg,pin
2D12 L outa[pinreg] := 0 andn outa,pinreg
dira[pinreg] := 1 or dira,pinreg
2D14 |< pinmask := 1 << pin mov pinmask,#1
shl pinmask,pin
2D16 -ROT
2D18 $0000 (0) data := 0 mov data,#0
2D1A -ROT
2D1C $0003 (3) bytes := leds*3
2D1E *
2D20 ADO repeat i from array for bytes
2D22 IC@ data := rdbyte[i] rdbyte data,i
2D24 $0008 (8) repeat 8 mov x,#8
2D26 FOR
2D28 H outa[pinreg] := 1 or outa,pinmask
dira[pinreg] := 1 or dira,
2D2A SHROUT outa[pin] := data&1
data := data >> 1
2D2C L outa[pin] := 0
dira[pin] := 1
2D2E NEXT
2D30 LOOP
2D32 2DROP
2D34 $0032 (50) delayms(50)
2D36 GOTO us
--- RUNMOD
( 0075 $2D6E ok ) 0 1000 3 * LAP RUNMOD LAP .LAP
2400144 cycles at 96000000Hz or 25.001ms
( g r b )
{
WS2812
rdbyte X,tos+1 ' read next byte
rev X,#24 ' the msb must be transmitted first - get it into the lsb for shr ops
mov R1,#8 ' data bits
jmp #$+2 ' skip delay of last bit (in loop) as we had to read another byte from hub
TXRGBlp call #WSDLY ' gets skipped if this is a new byte
shr X,#1 wc ' get next bit
or OUTA,REG4 ' always clock tx pin high for at least 400ns
call #WSDLY ' delay
if_nc andn OUTA,REG4 ' pull line down now if it's a 0 we are transmitting
call #WSDLY ' delay again, either high or low
andn OUTA,REG4 ' always needs to go low in the last third of the cycle
djnz R1,#TXRGBlp ' so go back and get the next bit ready
RGBNEXT add tos+1,#1 ' next byte in array (and delay)
djnz tos,#WS2812 ' read the next long as long as we can (tos = count)
jmp #DROP2 ' tx line left low - discard stack parameters, all done.
WSDLY mov R2,CNT
add R2,#13
waitcnt R2,#0 ' just a delay, no need to synch
WSDLY_ret ret
}
Hi Peter, am I right that Stack level greater zero is a bad Omen?
not if you need that value later...
Mike
it is in the case, I just load tachyon an extentions. I fear, stack level 2 points to some mistakes in extend I made and that could be a reason, why I can not load assembler hex files to a new cog
Peter,
I found your old Neopixel driver for WS2812 but it is not updated for Neon. Where do I find the newest WS2812 RUNMOD that will work with the V5r4 kernel?
The driver is built into Tachyon plus there are a few helper words in EXTEND so there is no need to find them.
To set P20 as the LED driver pin:
20 RGBPIN
To output light green to a single WS2812 LED:
$2000 RGB
To output an array (use BUFFERS for demo) to 40 LEDs:
BUFFERS 40 RGBS
If by driver you actually meant the WS2812MX.FTH demo program then I have also converted that across.
LOADCOG ( name pars cog pars name -- ) Load cog with ROM if found (ex: " VGA32x15" 3 vgapars 3 " VGA32x15" LOADCOG)
Is that correct? Did you test LOADCOG after the changes (can not imagine: NO)
If you look at VGA.FTH you will see that LOADCOG gets used this way:
" VGA32x15 " 3 vgapars LOADCOG
In EXTEND there is this for LOADCOG
pub LOADCOG ( name cog par -- )
So those two agree with each other and is the correct form. Now there is also LOADCOGS but that is for loading multiple cogs with the same ROM so you need to specify two extra parameters, the step or the size of the parameter table to step over, and the number of cogs. Maybe parlen would be a better variable name in place of step.
Sorry, in my post of the change I made to the glossary, the cross out was not visible
LOADCOG ( name pars cog pars name -- ) Load cog with ROM if found (ex: " VGA32x15" 3 vgapars 3 " VGA32x15" LOADCOG)
is
LOADCOG ( name pars cog pars name -- ) Load cog with ROM if found (ex: " VGA32x15" 3 vgapars 3 " VGA32x15" LOADCOG)
(Remark to the forum software: it looks as if [c o d e] and [ s ] can not be stacked)
Open question: is it a MUST that the rom name is exactly 10 characters long, including the trailing blanks? In this case, there should be a hint in the glossary.
OK, thanks @mjb for the hint to LOADCOGS and new example
We still try to isolate the moment, when COGLOAD doesn't work any longer. We load the kernel and EXTEND in the latest version (with changes LOW@ etc). Then COGLOADing uart works, that is, we see the buffers, pointers and the behavior is like expected.
Next we generate a system with init EASYFILE and EASYNET. Then the stack level is 2! (supposed to be an error) and COGLOAD doesn't word.
We find that the +INIT word is in EXTEND, but there is no description in the glossary. We will add it the moment we gained understanding. ALSO we are searching for a -INIT, what we can't find.
The next round hopefully is a system that only inits EASYFILE to check, if the stack error comes from EASYFILE or EASYNET.
edit: just realized, that +INIT is documented in Introduction to TACHYON Forth
One more step: we removed unneeded code from extend (unused peripheral devices) to gain memory. Next we load EASYFILE. COGLOAD works. Next we load EASYNET manually and start: Stack is ok, but the chip is not found, as we forget to select the wiznet pins. So we enter the pins and start EASYSNET again and NOW the stack is in level 2 and COGLOAD doesn't work. That points to an error in EASYNET?
pub !EASYNET
!WIZ #150 ms --- Setup WIZnet chip
#5000 @RTR LW! 16 @RCR LC! --- setup retry counters
CR PRINT" *** Tachyon Forth EASYNET Network Servers and EASYFILE File Server *** " CR CR
4 ledon C! --- just setup an LED blink time
ON RDYLED --- Now init the IP addresses (stored in high 64K EEPROM)
TELNET SOCKET sCLOSE TCP sOPEN sLISTEN --- Setup TELNET but on port 10001
" ?FTP" 0 PROTOCOL --- Poll the FTP server
" ?HTTP" 1 PROTOCOL --- Poll the WEB server
" !FTP" NFA$ ?DUP IF CFA CALL THEN ;
;
There is a semicolon the last line AND another one in the last but one line. Is this intenionally?
I went through !EASYNET line for line to see, where the stack changes:
.. .S Data Stack (0) ok
... !WIZ #150 ms ok
... .S Data Stack (0) ok
... #5000 @RTR LW! 16 @RCR LC! ok
... .S Data Stack (0) ok
... CR PRINT" *** Tachyon Forth EASYNET Network Servers and EASYFILE File Server *** " CR CR
*** Tachyon Forth EASYNET Network Servers and EASYFILE File Server ***
ok
... .S Data Stack (0) ok
... 4 ledon C! ok
... .S Data Stack (0) ok
... ON RDYLED ok
... .S Data Stack (0) ok
... TELNET SOCKET sCLOSE TCP sOPEN sLISTEN ok
... .S Data Stack (0) ok
... " ?FTP" 0 PROTOCOL ok
... .S Data Stack (1)
$0000.52C4 - 21188
ok
... " ?FTP" 0 PROTOCOL ok
... .S Data Stack (2)
$0000.52C4 - 21188
$0000.52C4 - 21188
ok
... " ?HTTP" 1 PROTOCOL ok
... .S Data Stack (3)
$0000.52C4 - 21188
$0000.52C4 - 21188
$0000.52C4 - 21188
ok
... " !FTP" NFA$ ?DUP IF CFA CALL THEN ok
... .S Data Stack (3)
$0000.52C4 - 21188
$0000.52C4 - 21188
$0000.52C4 - 21188
ok
As can be seen: it happens at " ?FTP.... and " ?HTTP...
In difference to the running !EASYNET the values on the stack are equal, when !EASYNET the values on the stack differ by 12
I just see: protocol is a one liner, so I will crank it down
thanks, peter, as we celebrate the "making Germany great again by tearing down the wall on advice of a great president of us day" tomorrow, I will only be able to have this tested the day after tomorrow...
Not related to our current problems:
on a german keyboard the '"' is shift 2 and '§' is shift 3. So it's easy to enter a string and close it with a '§'
That freezes Tachyon and a hardware reset is needed.
Digging a little deeper it turns out, that some characters are not allowed a string. So if I enter a degree (°) it is reflected ?° and the system sometimes resets, or generally spoken, shows undetermined behavior. It need a hardware reset
For our purposes we have to make some changes to EASYNET.
We need a function WRESET as it was in the past, because if we power down a board and have the propplug installed, it may happen that via the propplug current is injected and Vcc doesn't go below 1.8V. When power returns, the internal reset of the WIZNET chip is not fired.
As the reset circuit is hardware, we stay with the old version to have a dummy reset and power down WORD and do a revector at runtime.
Next a problem popped up with the time out of the TCP connection.
byte _disreq --- background timer cog can only request a disconnect
pri DISREQ _isreq C~~ --- timeout sets disreg flag which is handled by main loop
initially the connection times out after 5 minutes. Independent of traffic. Is this a bug or a feature?
We would need a description, what is the intended behavior and how is it reached?
I can imagine, that the client sends a keepalive, the server resets the watchdog. Whenever the keepAlive is requested, but no more requests from the client come within 5 minutes, the server closes the connection. Is that correct?
In the past we could deactivate the timeout, but no longer. What we see is, with RECLAIM not only the WORD DISREQ but also the name of _disreq is no longer in the dictionary.
another question: in the glossary there is still the variables declaration e.g. long ( >csv> --) but it looks as if this is not correct.
another question: what does "clong" mean when defining a variable?
@"Peter Jakacki" We still see problems with loading ROMS, we made this observation:
Starting point: because of the bugs you found (PROTOCOL) we couldn't load ROMS at all. During debugging we made a minimal ASM routine to toggle a pin. After fixing PROTOCOL et al toggle could be loaded. We next saved an uart ROM which was properly found but didn't run. We saved a new copy of toggle and could start it!
Over the time we over and over created tachyon new from source and one moment we could start the uart again. We checked then to start toggle and it didn't run. A next copy of toggle ran!
We cleared the rom area and tried different configurations and now it look, as if the first and third rom can be loaded, but NOT the second! We will now test, what happens in the case of 4 ROMS...
By the way: if the ROM name MUST be 10 characters long, it should be a good idea to indeed use 10 characters to prevent a typo. Or: does the FINDROM work also with shorter search strings?
Jim, just like bread-boarding you have all the components there to plug in an test interactively. For instance all I2C communications begin with a "chip select" using the start condition "tag" word <I2C that should be followed by the device address including r/w state. So to send a command to this chip is as simple as this definition:
: MSCMD ( cmd -- ) <I2C $EC I2C! I2C! ;
Now just keep plugging in other components into your Tachyon breadboard and build up your "circuit" this way. Use the Forth.
Hi Peter
I am looking to update an ADC/DAC project that is working well with T3; it is built into an electron gun controller crate. It uses clock stretched I2C, which one of us wrote
pub XI2C@ ( ack -- data ) \ 36.6us
SDA DUP INPUTS 0 ( ack iomask dat )
8 FOR
SCL INPUTS BEGIN SCL IN UNTIL
SHRINP SCL OUTCLR
NEXT
ROT 0= IF OVER OUTCLR THEN
CLOCK NOP CLOCK SWAP INPUTS
SDA OUTCLR SCL OUTCLR
BL REV --- flip 8 msbs of long back into 8 lsbs
;
--- Write a byte to the I2C bus and return with the ack flag :
--- written by Peter J, PR added clock stretching
--- enter and exit with both SDA and SCL driven low by propeller Master
--- This routine runs at an I2C speed of 400kHz
--- 38.4us
pub XI2C!? ( data -- flg ) --- write a byte to the I2C bus and return with the ack 0=ack )
#24 REV --- put into lsb first format for SHROUT
SDA DUP OUTSET SWAP --- data masks
8 FOR
SHROUT
SCL INPUTS BEGIN SCL IN UNTIL
SCL OUTCLR
NEXT --- loop
DROP DUP INPUTS --- Float SDA
SCL INPUTS BEGIN SCL IN UNTIL
IN 0<> SCL OUTCLR SDA OUTCLR --- ack clock
;
The T5.4 I2C codes seem very different ... would the current stretching codes still work? Would changing the I2C speed get the same result?
Very concerned about breaking something that seems to work ...
Thanks!
Comments
this is the output at boot. You see, we have EXTEND, TOOLS, etc. loaded. Free memory: 1560, stack level 0 is correct. We removed not needed code from EXTEND to have more free memory. The sd card is detected correctly. The network is started, LINK *UP* correct, IP's etc. are ok.
What seemed strange: Socket #3 shows IP &192.168.1.101 which was an old connection. But after we reset the wiznet chip, the IP is 0.0.0.0, so that behavior looks ok.
A next try which complete power down and restart showed the same result: stack level (2) and values are unchanged.
We will now remove the INIT so we can manually start the modules and locate the stack change.
this is the output at boot. You see, we have EXTEND, TOOLS, etc. loaded. Free memory: 1560, stack level 0 is correct. We removed not needed code from EXTEND to have more free memory. The sd card is detected correctly. The network is started, LINK *UP* correct, IP's etc. are ok.
What is strange:
I found your old Neopixel driver for WS2812 but it is not updated for Neon. Where do I find the newest WS2812 RUNMOD that will work with the V5r4 kernel?
not if you need that value later...
Mike
unless you have really big and fast updates you can do without runmod and just bitbang it
some old code I found
: XLED ( ggrrbb -- ) L 50 us 8 REV 24 FOR DUP 1 AND IF H H L ELSE H L L THEN 2/ NEXT DROP ; : XLED ( ggrrbb pin -- ) DUP PIN MASK SWAP L 50 us 8 REV 24 FOR H SHROUT L NEXT DROP ; : XLED ( ggrrbb pin -- ) DUP PIN L MASK SWAP 8 REV 24 FOR H SHROUT L NEXT 2DROP ; : XLEDS ( array cnt pin -- ) DUP PIN L MASK -ROT ADO I @ 8 REV 24 FOR H SHROUT L NEXT DROP 4 +LOOP DROP ; : XLEDS ( array leds pin -- ) DUP PIN L MASK -ROT 3 * ADO I C@ 8 FOR H SHROUT L NEXT DROP LOOP DROP ; --- ( 0062 $2D6E ok ) 0 1000 14 LAP XLEDS LAP .LAP --- 4657456 cycles at 96000000Hz or 48.515ms { this version uses IC@ which replaces tos with byte from loop indexed memory } : XLEDS ( array leds pin -- ) DUP PIN L MASK -ROT 0 -ROT 3 * ADO IC@ 8 FOR H SHROUT L NEXT LOOP 2DROP 50 us ; : XLEDS ( array leds pin -- ) DUP PIN L MASK -ROT 0 -ROT 3 * ADO IC@ 8 FOR L H SHROUT NEXT L LOOP 2DROP 50 us ; --- ( 0041 $2D46 ok ) 0 1000 14 LAP XLEDS LAP .LAP --- 4177824 cycles at 96000000Hz or 43.519ms : P $7E00 + C! ; : O $7E00 40 14 XLEDS ; : XLEDS ( array leds pin -- ) OP <---- stack DESC ------------------------------------------------------------------------------------ DUP array leds pin pin PIN array leds pin set fast pin L array leds pin fast pin low MASK array leds pinmask create mask for SHROUT ops -ROT pinmask array leds work dummy data into the correct position 0 pinmask array leds 0 -ROT pimask 0 array leds 3 pinmask 0 array leds 3 convert leds to byte count * pinmask 0 array bytes ADO pinmask 0 start a loop using start address and count IC@ pinmask data replace data with the next byte pointed to by loop index 8 pinmask data 8 for 8 times FOR pinmask data H pinmask data output a high SHROUT pinmask data>> output a data bit L pinmask data>> output a low NEXT " " next bit LOOP " " loop for another byte 2DROP discard parameters 50 50 delay for 50 us us ; return ( 0084 $3002 ok ) SEE XLEDS --- Spin near equivalent Pseudo assembly 2D0E DUP 2D10 PIN pinreg := pin mov pinreg,pin 2D12 L outa[pinreg] := 0 andn outa,pinreg dira[pinreg] := 1 or dira,pinreg 2D14 |< pinmask := 1 << pin mov pinmask,#1 shl pinmask,pin 2D16 -ROT 2D18 $0000 (0) data := 0 mov data,#0 2D1A -ROT 2D1C $0003 (3) bytes := leds*3 2D1E * 2D20 ADO repeat i from array for bytes 2D22 IC@ data := rdbyte[i] rdbyte data,i 2D24 $0008 (8) repeat 8 mov x,#8 2D26 FOR 2D28 H outa[pinreg] := 1 or outa,pinmask dira[pinreg] := 1 or dira, 2D2A SHROUT outa[pin] := data&1 data := data >> 1 2D2C L outa[pin] := 0 dira[pin] := 1 2D2E NEXT 2D30 LOOP 2D32 2DROP 2D34 $0032 (50) delayms(50) 2D36 GOTO us --- RUNMOD ( 0075 $2D6E ok ) 0 1000 3 * LAP RUNMOD LAP .LAP 2400144 cycles at 96000000Hz or 25.001ms ( g r b ) { WS2812 rdbyte X,tos+1 ' read next byte rev X,#24 ' the msb must be transmitted first - get it into the lsb for shr ops mov R1,#8 ' data bits jmp #$+2 ' skip delay of last bit (in loop) as we had to read another byte from hub TXRGBlp call #WSDLY ' gets skipped if this is a new byte shr X,#1 wc ' get next bit or OUTA,REG4 ' always clock tx pin high for at least 400ns call #WSDLY ' delay if_nc andn OUTA,REG4 ' pull line down now if it's a 0 we are transmitting call #WSDLY ' delay again, either high or low andn OUTA,REG4 ' always needs to go low in the last third of the cycle djnz R1,#TXRGBlp ' so go back and get the next bit ready RGBNEXT add tos+1,#1 ' next byte in array (and delay) djnz tos,#WS2812 ' read the next long as long as we can (tos = count) jmp #DROP2 ' tx line left low - discard stack parameters, all done. WSDLY mov R2,CNT add R2,#13 waitcnt R2,#0 ' just a delay, no need to synch WSDLY_ret ret }The driver is built into Tachyon plus there are a few helper words in EXTEND so there is no need to find them.
To set P20 as the LED driver pin: To output light green to a single WS2812 LED: To output an array (use BUFFERS for demo) to 40 LEDs:
If by driver you actually meant the WS2812MX.FTH demo program then I have also converted that across.
a stack level less than zero should REALLY concern you ;-)
If you look at VGA.FTH you will see that LOADCOG gets used this way: In EXTEND there is this for LOADCOG So those two agree with each other and is the correct form. Now there is also LOADCOGS but that is for loading multiple cogs with the same ROM so you need to specify two extra parameters, the step or the size of the parameter table to step over, and the number of cogs. Maybe parlen would be a better variable name in place of step.
but obviously while I was writing you sneaked in before me ... :-)
looks strange - you would normally not repeat parameters on stack, you would DUP inside the word.
this is from latest EXTEND
LOADCOG ( name pars cog pars name -- ) Load cog with ROM if found (ex: " VGA32x15" 3 vgapars 3 " VGA32x15" LOADCOG)
(Remark to the forum software: it looks as if [c o d e] and [ s ] can not be stacked)
Open question: is it a MUST that the rom name is exactly 10 characters long, including the trailing blanks? In this case, there should be a hint in the glossary.
OK, thanks @mjb for the hint to LOADCOGS and new example
Next we generate a system with init EASYFILE and EASYNET. Then the stack level is 2! (supposed to be an error) and COGLOAD doesn't word.
We find that the +INIT word is in EXTEND, but there is no description in the glossary. We will add it the moment we gained understanding. ALSO we are searching for a -INIT, what we can't find.
The next round hopefully is a system that only inits EASYFILE to check, if the stack error comes from EASYFILE or EASYNET.
edit: just realized, that +INIT is documented in Introduction to TACHYON Forth
next step: !EASYNET -> Stack = 2
In difference to the running !EASYNET the values on the stack are equal, when !EASYNET the values on the stack differ by 12
I just see: protocol is a one liner, so I will crank it down
Hi Erna & @"Peter Jakacki" ,
DEFER support is needed by EasyFile so should be moved out of tools to the front before the tools section.
It is important for defining pre ( immediate) words.
on a german keyboard the '"' is shift 2 and '§' is shift 3. So it's easy to enter a string and close it with a '§'
That freezes Tachyon and a hardware reset is needed.
Digging a little deeper it turns out, that some characters are not allowed a string. So if I enter a degree (°) it is reflected ?° and the system sometimes resets, or generally spoken, shows undetermined behavior. It need a hardware reset
We need a function WRESET as it was in the past, because if we power down a board and have the propplug installed, it may happen that via the propplug current is injected and Vcc doesn't go below 1.8V. When power returns, the internal reset of the WIZNET chip is not fired.
As the reset circuit is hardware, we stay with the old version to have a dummy reset and power down WORD and do a revector at runtime.
Next a problem popped up with the time out of the TCP connection.
initially the connection times out after 5 minutes. Independent of traffic. Is this a bug or a feature?
We would need a description, what is the intended behavior and how is it reached?
I can imagine, that the client sends a keepalive, the server resets the watchdog. Whenever the keepAlive is requested, but no more requests from the client come within 5 minutes, the server closes the connection. Is that correct?
In the past we could deactivate the timeout, but no longer. What we see is, with RECLAIM not only the WORD DISREQ but also the name of _disreq is no longer in the dictionary.
another question: in the glossary there is still the variables declaration e.g. long ( >csv> --) but it looks as if this is not correct.
another question: what does "clong" mean when defining a variable?
_isreq instead of _disreq above is a typo?
clong defines a long in code space where it is saved to EEPROM with backup.
The new Tachyon (not exactly sure since which version) has separate space for code and variables.
@"Peter Jakacki" We still see problems with loading ROMS, we made this observation:
Starting point: because of the bugs you found (PROTOCOL) we couldn't load ROMS at all. During debugging we made a minimal ASM routine to toggle a pin. After fixing PROTOCOL et al toggle could be loaded. We next saved an uart ROM which was properly found but didn't run. We saved a new copy of toggle and could start it!
Over the time we over and over created tachyon new from source and one moment we could start the uart again. We checked then to start toggle and it didn't run. A next copy of toggle ran!
We cleared the rom area and tried different configurations and now it look, as if the first and third rom can be loaded, but NOT the second! We will now test, what happens in the case of 4 ROMS...
By the way: if the ROM name MUST be 10 characters long, it should be a good idea to indeed use 10 characters to prevent a typo. Or: does the FINDROM work also with shorter search strings?
Have you ported the MS5607 chip(Parallax 29124 Altimeter) to Tachyon?
Jim
Tachyon supports I2C as well as SPI
you can use those to send the commands and retrieve the measurements.
There are several I2C and SPI sensor drivers in Peter's dropbox (link in his footer) which you can take as examples.
I am looking to update an ADC/DAC project that is working well with T3; it is built into an electron gun controller crate. It uses clock stretched I2C, which one of us wrote
pub XI2C@ ( ack -- data ) \ 36.6us SDA DUP INPUTS 0 ( ack iomask dat ) 8 FOR SCL INPUTS BEGIN SCL IN UNTIL SHRINP SCL OUTCLR NEXT ROT 0= IF OVER OUTCLR THEN CLOCK NOP CLOCK SWAP INPUTS SDA OUTCLR SCL OUTCLR BL REV --- flip 8 msbs of long back into 8 lsbs ; --- Write a byte to the I2C bus and return with the ack flag : --- written by Peter J, PR added clock stretching --- enter and exit with both SDA and SCL driven low by propeller Master --- This routine runs at an I2C speed of 400kHz --- 38.4us pub XI2C!? ( data -- flg ) --- write a byte to the I2C bus and return with the ack 0=ack ) #24 REV --- put into lsb first format for SHROUT SDA DUP OUTSET SWAP --- data masks 8 FOR SHROUT SCL INPUTS BEGIN SCL IN UNTIL SCL OUTCLR NEXT --- loop DROP DUP INPUTS --- Float SDA SCL INPUTS BEGIN SCL IN UNTIL IN 0<> SCL OUTCLR SDA OUTCLR --- ack clock ;The T5.4 I2C codes seem very different ... would the current stretching codes still work? Would changing the I2C speed get the same result?Very concerned about breaking something that seems to work ...
Thanks!