Please teach me how to use WAITPEQ and WAITPNE and WAITCNT.
just load Tachyon.spin and Extend.fth into your favorite editor and use SEARCH.
I am sure you can read some PASM plus the inline documentation.
A good place to start understanding.
And internally it obviously just is using WAITPEQ and WAITPNE and WAITCNT as you know them from PASM.
\ From EXTEND (older version):
\ WAITPxx instructions also capture the CNT into COGREG0 or 1
pub WAITPNE ( mask -- \ wait until pins are not equal to mask, then capture counter onto COGREG0 )
3 COGREG! (WAITPNE)
;
pub WAITPEQ ( mask -- \ wait until pins are equal to mask, then capture counter onto COGREG1 )
3 COGREG! (WAITPEQ)
;
\ from Tachyon (older version)
' WAITPEQ Wait until input is high - REG4 = mask, REG2 = CNT
_WAITPEQ
waitpeq REG4,REG4
mov REG2,cnt ' capture count in REG2
jmp unext
' WAITPNE Wait until input is low - REG4 = mask, REG1 = CNT
_WAITPNE
waitpne REG4,REG4 ' use REG4 as the mask
mov REG1,cnt ' capture count in REG2
jmp unext
{ WAITPNE with timeout - mask in REG4
' Usage: #P4 MASK 3 COGREG! #50,000 WLOW IF <timeout out> THN
' WLOW ( timeout -- rem )
wfp test REG4,ina wz ' look for low on pin (REG4 mask)
if_nz djnz tos,#wfp ' otherwise keep checking and continue counting down
jmp unext ' either pin is low or it's timed out
}
so you can see count is captured on EQ and NE in different internal registers.
Quite handy for timing pulses & events
caskaz - As MJB said, look at the source. Since there are no conversion steps in creating the kernel you have access to all there is in basically two documents, TACHYON.SPIN and EXTEND.FTH. If you are looking for WAITCNT in the TACHYON.SPIN source you may search for "WAITCNT" in the dictionary and find its code name WAITCNTS and then search for that etc.
There are also the new help files being constructed for loading onto an SD card but are also handy for reference from your PC. Look in V4/HELP. If you open WAIT.TXT in the HELP folder you will see that DELTA is used to setup WAITCNT but often just perusing both sources gives you a good idea on how to use it.
I installed v4r5.
There are assembler source in TACHYON.SPIN.
I searched WAITPNE and WAITPNE in EXTEND.FTH.
But nothing except for alias.
[pub WAITPNE] and [pub WAITPNE] also are valid on V4r5?
There is not [pub WAITCNT] in EXTEND.FTH.
Maybe I think (cnt delta -- cnt).
I have the habbit to keep all the Tachyon files (.spin, Extend, File, NW ..) of the actual and some older versions (4.5, 4.4, 4.0, 3) open in NOTEPAD++ at the same time.
Then I do a search in all files.
So I can find hopefully all relevant instances and can easily compare new to old versions. So I see what has been changed by Peter recently.
...Propeller\Forth\Tachyon\DropBoxImages\V4r5 2017-07-08\EXTEND.FTH (1 hit)
Line 121: ALIAS (WAITPNE) WAITLO
...Propeller\Forth\Tachyon\DropBoxImages\V4r5 2017-07-08\TACHYON4r5.SPIN (8 hits)
Line 2256: waitpne X,REG1 ' wait for change on those masked bits
Line 3008: byte cn,"(WAITPNE)",hd
Line 3009: word _WAITPNE
Line 3602: waitpne ccr0,ccmask ' wait for change on those masked bits
Line 5143: waitpne rxpins,rxpins ' wait for a low = start bit
Line 6152: ' WAITPNE Wait until input is low - REG4 = mask, REG1 = CNT
Line 6153: _WAITPNE
Line 6154: waitpne REG4,REG4 ' use REG4 as the mask
and do not make the search to restrictive.
it could be pub, pri, pre, upper/lower case, part of a name, wrapped in () ...
this is how I try to make sense of Tachyon .... just read the source.
This way I even picked up a significant amount of PASM.
--- Thanks for the training Peter.
I installed v4r5.
There are assembler source in TACHYON.SPIN.
I searched WAITPNE and WAITPNE in EXTEND.FTH.
But nothing except for alias.
[pub WAITPNE] and [pub WAITPNE] also are valid on V4r5?
There is not [pub WAITCNT] in EXTEND.FTH.
Maybe I think (cnt delta -- cnt).
an example from EXTEND.fth
--- receive 8 bit serial data from pin at rate set with SERBAUD, blocks until character received
pub SERIN ( pin -- data )
MASK DUP 4 COG! --- [5.8us]
baudcnt 2+ W@ --- [4.8us] serup half-bit delay with high speed compensation
WAITHI --- [0.4us+] make sure we are not detecting the last data bit - wait for stop
WAITLO DELTA --- wait for start bit then wait haf bit time
0 --- [5.4us] setup pin mask and inital data to SHRINP 8 data
baudcnt W@ DELTA --- delay to sample 1 bit later in 1st data bit
SHRINP WAITCNT
SHRINP WAITCNT
SHRINP WAITCNT
SHRINP WAITCNT
SHRINP WAITCNT
SHRINP WAITCNT
SHRINP WAITCNT
SHRINP --- last data bit
NIP #24 >> --- right justify 8-bit data
;
Hi.
I wrote code for SHT31.
Measurement with clockstreching cannt operate by using Tachyon's I2C-WORD.
I think Tachyon's I2C-WORD have problem same as PropForth.
So, I re-defined i2c-word on PropForth.
I translated them. Not 400kHz.
Periodic Mode measurment is a little strange yet.
from the datasheet it looks like you do not need to use the clock stretching.
You can repeat the read id while you get NACK until you could read the value ...
@mjb - That's the trouble with the I2C standard, it was meant to be a bus to accommodate slower peripherals that might emulate the bus under software but some companies use the "bus" as a dedicated connection. Who would want the bus blocked for up to 15ms? Imagine if the humble I2C EEPROM did that? Thankfully EEPROMs do what you say in that they indicate they are ready when they ack their device address.
caskaz - as MJB pointed out, you don't need clock stretching with this chip, just restart after a read command and keep addressing it until you get an ack back.
No Clock Stretching
When a command without clock stretching has been
issued, the sensor responds to a read header with a not
acknowledge (NACK), if no data is present.
Clock Stretching
When a command with clock stretching has been issued,
the sensor responds to a read header with an ACK and
subsequently pulls down the SCL line. The SCL line is
pulled down until the measurement is complete. As soon
as the measurement is complete, the sensor releases
the SCL line and sends the measurement results.
Of course,I don't think clockstreching must use.
But SHT31's clockstreching cannot use on Tachyon's I2C-specification.
Many I2C-devices operate under current Tachyon.
But maybe I think some devices don't operate.
UM10204 Rev.6 I2C-Bus specification
3.1.1 SDA and SCL signals
When the bus is free, both lines are HIGH.
The output stages of devices connected to the bus must have an open-drain or open-collector to perform the wired-AND function.
caskaz - I've been using I2C ever since it replaced the 3-wire CBUS and it was originally called IIC - the Inter IC bus but later changed to I2C for trademark and IP reasons. Being familiar with how it is used and was intended to be used is helpful and specifications are quite correct when they say "to perform the wired-AND function" that you need open-drain. However most micros don't have true open-drain drivers since they use GPIO but they can simulate open-drain within reason IF they perform the wired-AND function that is. There is however no need for this arbitration if clock stretching and multi-master are not employed, the latter of which I have never seen used but was envisioned by the designers.
The use of clock stretching was not meant for the purpose that some manufacturers have (mis)used it for though, as some early I2C devices were based on slow micros and couldn't always keep up with the timing so in a clever way clock-stretching was specified. A bus implies that this is a common freeway that should not be hogged by one device but for many to use according to the rules. Polling a device until you get an acknowledgement is the proper way to use the bus but I do notice that some processors these days offer a multitude of I2C buses which doesn't make any sense really unless you dedicate the "bus" for single use.
"bus" - shortened from Latin "omnibus" = "for all"
I expect to modify setting to input-mode when SCL/SDA is High.
*SDA HIGH -> *SDA FLOAT
*SCL HIGH -> *SCL FLOAT
Maybe many i2c-devices don't occur trouble.
SHT31's clocksteching should also operate well although I think such function don't need to use.
On some Prop systems the SCL line does not have a pull-up fitted since it is normally driven from the master. I always say a pull-up on SCL isn't necessary but I almost always put one on it if I expect to interface to interface to some unknown chip other than the EEPROM although I have never had occasion to need it either. A pull-up/down in general is useful on Prop I/O because it allows the pin to be floated but still in a known state so that more than one cog can share an output.
The lines are floated at I2C STOP after an I2C transaction anyway.
pub I2C>
--- pull SDA high from low while clock high
*SDA LOW *SCL HIGH ( 1 DROP ) *SDA HIGH
--- free up I2C lines
*SDA FLOAT *SCL FLOAT
i2cflg C~ --- i2c bus free
;
btw - modification isn't impossible of course, but is it really necessary? Should we allow for multi-master and arbitration in general? Do we respond to general-call address even as a master? Most of the I2C specification is never needed in practice and seeing we have such limited resources we don't pile on unnecessary baggage unless there is some real advantage. Besides, I normally like to test this out so next time I order some chips I will get a few of these devices and test out the clock stretching mode on them although I probably would never use it in that mode due to the long delay necessary.
The terminal emulators I use support ANSI sequences which I use for some words but I decided to put in a test for ANSI capability at boot time and if there was a response to then allow ANSI. Hopefully simple terminals will only display a couple of garbage characters from the initial ANSI query and suppress everything ANSI thereafter although I encourage anyone using Tachyon to use an ANSI/VT100 capable terminal.
@Peter - you've been really eager so I gave IoT5500 a new try with v4r5. The case sensitivity thing is solved but still I have problems to change IP, SN and GW on the WIZNET 5500 chip.
I set myIP, mySN, myGW before and then I do which gives:
NETWORK STATUS:
LINK *UP*
HARDWARE: WIZnet W5500 V4
SRC IP 192.168.000.099
MASK 255.255.255.000
GATEWAY 192.168.000.001
MAC 02.FF.22.04.31.FC.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#3 00:00:55 TCP 10001 . . . . . 00 14 LISTEN
ok
.. myIP .& &192.168.1.124 ok
.. WCOLD
Setting default IP configuration ok
.. ifconfig
NETWORK STATUS:
LINK *UP*
HARDWARE: WIZnet W5500 V4
SRC IP 192.168.000.099
MASK 255.255.255.000
GATEWAY 192.168.000.001
MAC 02.FF.22.04.31.FC.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#3 00:00:55 TCP 10001 . . . . . 00 14 LISTEN
ok
..
It seems that WCOLD doesn't write to the wiznet chip ?!
PS:
The ethernet connection is up, LED is on, but there is no gateway available
@Peter - you've been really eager so I gave IoT5500 a new try with v4r5. The case sensitivity thing is solved but still I have problems to change IP, SN and GW on the WIZNET 5500 chip.
I set myIP, mySN, myGW before and then I do which gives:
NETWORK STATUS:
LINK *UP*
HARDWARE: WIZnet W5500 V4
SRC IP 192.168.000.099
MASK 255.255.255.000
GATEWAY 192.168.000.001
MAC 02.FF.22.04.31.FC.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#3 00:00:55 TCP 10001 . . . . . 00 14 LISTEN
ok
.. myIP .& &192.168.1.124 ok
.. WCOLD
Setting default IP configuration ok
.. ifconfig
NETWORK STATUS:
LINK *UP*
HARDWARE: WIZnet W5500 V4
SRC IP 192.168.000.099
MASK 255.255.255.000
GATEWAY 192.168.000.001
MAC 02.FF.22.04.31.FC.
SKT HH:MM:SS MODE PORT DEST TXRD TXWR RXRD RXWR RXSZ IR STATUS IP ADDR
#3 00:00:55 TCP 10001 . . . . . 00 14 LISTEN
ok
..
It seems that WCOLD doesn't write to the wiznet chip ?!
PS:
The ethernet connection is up, LED is on, but there is no gateway available
Thanks in advance, best regards,
proplem
could be this:
WCOLD refers to the constants defined in EASYNET.fth
if you define NEW constants, WCOLD still refers to the old ones.
So you need to change the values of the original constants with: AT .... hmmm - seems to be gone.
but it looks like you can use those to put new values into EEPROM
@proplem - smaller constants are simply symbols with only a header that embed the values into code at compile time so you can't change those ones at runtime but the constants that are great than 15 bits do have a code field that is called so it is possible to change these IP constants. However the default configuration rather than the default values themselves are meant to be overridden by the user application which determines if it needs to do that. My applications simply use SIP and GATEWAY but if you really want to you could change the constant itself. Bear in mind that structure of the constant is:
[CONL] [HIGH] [LOW] where the constant is encoded as 2 words in high low order so you need to split your new value into 2 words and write them to these fields. Otherwise just use SIP and GATEWAY.
I use Tachyon "Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170712.0020".
These data looks like correct.
What is "320 16 COG!"?
The first thing you need to do is simply search for this in TACHYON.SPIN or EXTEND.FTH where you will find:
--- The CLOCK instruction can be slowed down at 16 COG!
pub I2CFAST 0
pri ~D 16 COG! ;
pub I2C100 CLKMHZ / ~D ;
pub I2C400 CLKMHZ 12 / ~D ;
However I noticed a bug there, somehow my constant in I2C100 got deleted so switching to this mode could switch to almost any speed. Here is what I think it should be but I will also check the timing at some point.
pub I2C100 CLKMHZ 3 / ~D ;
EDIT: I typed in 48 but what was I thinking .... try a lower value etc. I notice frida has a very long delay in there of 320 which is probably way too slow.
@MJB - I've been labeling private subroutines in the form ~x since V4 allows subroutines to be added and called efficiently. It doesn't matter that there might be routines named the same since it is only the most recent definition that would be referenced anyway. An optional RECLAIM can remove all the private headers to free up some memory without having to compact the dictionary into EEPROM.
--- The CLOCK instruction can be slowed down at 16 COG!
pub I2CFAST 0
pri ~D 16 COG! ;
pub I2C100 CLKMHZ / ~D ;
pub I2C400 CLKMHZ 12 / ~D ;
@MJB - I've been labeling private subroutines in the form ~x since V4 allows subroutines to be added and called efficiently. It doesn't matter that there might be routines named the same since it is only the most recent definition that would be referenced anyway. An optional RECLAIM can remove all the private headers to free up some memory without having to compact the dictionary into EEPROM.
sure - only the most recent definition will be referenced in new code.
so rewriting to
--- The CLOCK instruction can be slowed down at 16 COG!
pub I2CFAST 0
pub I2C100 CLKMHZ / --- fall thru into next
pri ~D 16 COG! ;
pub I2C400 CLKMHZ 12 / ~D ;
so using the old fall thru technique is a bit more difficult to read but would not gain a lot - right?
but is still valid?
looks like - but RECLAIM hangs the PROP
( 0003 $35DA ok ) pub A1 ." A1"
( 0005 $35E0 ++ ) pri ~A1 ." ~A1" ;
( 0006 $35E8 ok ) A1
A1~A1
( 0007 $35E8 ok ) ~A1
~A1
( 0008 $35E8 ok ) RECLAIM
Removing ~A1
---- a fed LEDs light up and system is dead
Mjb - last word in any real code is never private but reclaim hangs if it is as in your quick test. There's a bug to fix for sure but neither should it encounter it anyway. Don't forget there is a 3 missing in I2C100 but also that I2CFAST already falls through. Calls become jumps if they are followed by a ; making it faster and also does not compile the otherwise necessary exit opcode.
Mjb - last word in any real code is never private but reclaim hangs if it is as in your quick test. There's a bug to fix for sure but neither should it encounter it anyway. Don't forget there is a 3 missing in I2C100 but also that I2CFAST already falls through. Calls become jumps if they are followed by a ; making it faster and also does not compile the otherwise necessary exit opcode.
yea - missed that I2CFAST fall through ...
your introduction of CLKMHZ gives up resolution in selecting the division factor ...
but will usually be ok.
Comments
just load Tachyon.spin and Extend.fth into your favorite editor and use SEARCH.
I am sure you can read some PASM plus the inline documentation.
A good place to start understanding.
And internally it obviously just is using WAITPEQ and WAITPNE and WAITCNT as you know them from PASM.
\ From EXTEND (older version): \ WAITPxx instructions also capture the CNT into COGREG0 or 1 pub WAITPNE ( mask -- \ wait until pins are not equal to mask, then capture counter onto COGREG0 ) 3 COGREG! (WAITPNE) ; pub WAITPEQ ( mask -- \ wait until pins are equal to mask, then capture counter onto COGREG1 ) 3 COGREG! (WAITPEQ) ; \ from Tachyon (older version) ' WAITPEQ Wait until input is high - REG4 = mask, REG2 = CNT _WAITPEQ waitpeq REG4,REG4 mov REG2,cnt ' capture count in REG2 jmp unext ' WAITPNE Wait until input is low - REG4 = mask, REG1 = CNT _WAITPNE waitpne REG4,REG4 ' use REG4 as the mask mov REG1,cnt ' capture count in REG2 jmp unext { WAITPNE with timeout - mask in REG4 ' Usage: #P4 MASK 3 COGREG! #50,000 WLOW IF <timeout out> THN ' WLOW ( timeout -- rem ) wfp test REG4,ina wz ' look for low on pin (REG4 mask) if_nz djnz tos,#wfp ' otherwise keep checking and continue counting down jmp unext ' either pin is low or it's timed out }so you can see count is captured on EQ and NE in different internal registers.Quite handy for timing pulses & events
There are also the new help files being constructed for loading onto an SD card but are also handy for reference from your PC. Look in V4/HELP. If you open WAIT.TXT in the HELP folder you will see that DELTA is used to setup WAITCNT but often just perusing both sources gives you a good idea on how to use it.
I installed v4r5.
There are assembler source in TACHYON.SPIN.
I searched WAITPNE and WAITPNE in EXTEND.FTH.
But nothing except for alias.
[pub WAITPNE] and [pub WAITPNE] also are valid on V4r5?
There is not [pub WAITCNT] in EXTEND.FTH.
Maybe I think (cnt delta -- cnt).
I have the habbit to keep all the Tachyon files (.spin, Extend, File, NW ..) of the actual and some older versions (4.5, 4.4, 4.0, 3) open in NOTEPAD++ at the same time.
Then I do a search in all files.
So I can find hopefully all relevant instances and can easily compare new to old versions. So I see what has been changed by Peter recently.
and do not make the search to restrictive.
it could be pub, pri, pre, upper/lower case, part of a name, wrapped in () ...
this is how I try to make sense of Tachyon .... just read the source.
This way I even picked up a significant amount of PASM.
--- Thanks for the training Peter.
an example from EXTEND.fth it is all there ... ;-)
Code below ocuur stack-overflow.
What is it wrong?
Sorry, solved to check HELP-folder.
I wrote code for SHT31.
Measurement with clockstreching cannt operate by using Tachyon's I2C-WORD.
I think Tachyon's I2C-WORD have problem same as PropForth.
So, I re-defined i2c-word on PropForth.
I translated them. Not 400kHz.
Periodic Mode measurment is a little strange yet.
You can repeat the read id while you get NACK until you could read the value ...
so what do you need clock stretching for?
caskaz - as MJB pointed out, you don't need clock stretching with this chip, just restart after a read command and keep addressing it until you get an ack back.
But SHT31's clockstreching cannot use on Tachyon's I2C-specification.
Many I2C-devices operate under current Tachyon.
But maybe I think some devices don't operate.
The use of clock stretching was not meant for the purpose that some manufacturers have (mis)used it for though, as some early I2C devices were based on slow micros and couldn't always keep up with the timing so in a clever way clock-stretching was specified. A bus implies that this is a common freeway that should not be hogged by one device but for many to use according to the rules. Polling a device until you get an acknowledgement is the proper way to use the bus but I do notice that some processors these days offer a multitude of I2C buses which doesn't make any sense really unless you dedicate the "bus" for single use.
"bus" - shortened from Latin "omnibus" = "for all"
I expect to modify setting to input-mode when SCL/SDA is High.
*SDA HIGH -> *SDA FLOAT
*SCL HIGH -> *SCL FLOAT
Maybe many i2c-devices don't occur trouble.
SHT31's clocksteching should also operate well although I think such function don't need to use.
Such modification is impossible?
The lines are floated at I2C STOP after an I2C transaction anyway.
btw - modification isn't impossible of course, but is it really necessary? Should we allow for multi-master and arbitration in general? Do we respond to general-call address even as a master? Most of the I2C specification is never needed in practice and seeing we have such limited resources we don't pile on unnecessary baggage unless there is some real advantage. Besides, I normally like to test this out so next time I order some chips I will get a few of these devices and test out the clock stretching mode on them although I probably would never use it in that mode due to the long delay necessary.
The terminal emulators I use support ANSI sequences which I use for some words but I decided to put in a test for ANSI capability at boot time and if there was a response to then allow ANSI. Hopefully simple terminals will only display a couple of garbage characters from the initial ANSI query and suppress everything ANSI thereafter although I encourage anyone using Tachyon to use an ANSI/VT100 capable terminal.
Here is the startup screen.
This don't operate on Tachyon's I2C-word(I2C100).
Hi caskaz
at first I was thinking about complaining because you provide so little information.
Then I had a look into the ZIP - great start.
Looks you use your own I2C routines and not the ones from Tachyon.
So where is the problem or what exactly is your question.
I don't have a nunchuk - YET - I'll see if I can get one.
looks like fun to play with.
@caskaz,
Here I have ajusted your script so that it runs with I2C100 and a white nunchuck.
( 0151 $3822 ok ) lsi2c *** I2C *** A0 EEPROM A4 EEPROM ( 0152 $3822 ok ) i2cscan 0 1 2 3 4 5 6 7 8 9 A B C D E F 00 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- -- 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- I2C devices:2 ( 0153 $3822 ok ) tt SX:64 SY:-9 AX:744 AY:444 AZ:370 c:2 z:1 SX:64 SY:-9 AX:658 AY:448 AZ:389 c:2 z:1 SX:64 SY:-9 AX:620 AY:472 AZ:465 c:2 z:1 SX:64 SY:-9 AX:619 AY:485 AZ:491 c:2 z:1 SX:64 SY:-9 AX:603 AY:467 AZ:503 c:2 z:1 SX:64 SY:-9 AX:598 AY:498 AZ:502 c:2 z:1 SX:64 SY:-9 AX:581 AY:494 AZ:518 c:2 z:0 SX:64 SY:-9 AX:549 AY:476 AZ:520 c:2 z:0 SX:64 SY:-9 AX:577 AY:481 AZ:516 c:2 z:0 SX:64 SY:-9 AX:574 AY:483 AZ:523 c:2 z:0 SX:64 SY:-9 AX:584 AY:479 AZ:515 c:2 z:0 SX:64 SY:-9 AX:581 AY:487 AZ:518 c:2 z:0 SX:64 SY:-9 AX:564 AY:508 AZ:517 c:2 z:1 SX:64 SY:-9 AX:589 AY:471 AZ:507 c:0 z:1 SX:64 SY:-9 AX:605 AY:484 AZ:509 c:0 z:1 SX:64 SY:-9 AX:599 AY:480 AZ:513 c:0 z:1 SX:64 SY:-9 AX:596 AY:482 AZ:505 c:0 z:1 SX:64 SY:-9 AX:603 AY:488 AZ:506 c:2 z:1 SX:32 SY:4 AX:586 AY:513 AZ:526 c:2 z:1 SX:16 SY:7 AX:559 AY:475 AZ:516 c:2 z:1 SX:17 SY:8 AX:565 AY:470 AZ:517 c:2 z:1 SX:17 SY:7 AX:539 AY:467 AZ:514 c:2 z:1 SX:17 SY:7 AX:544 AY:465 AZ:521 c:2 z:1 SX:16 SY:6 AX:535 AY:472 AZ:520 c:2 z:1 SX:57 SY:-9 AX:535 AY:481 AZ:525 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:52 SY:82 AX:502 AY:480 AZ:527 c:2 z:1 SX:64 SY:90 AX:426 AY:487 AZ:511 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:65 AX:427 AY:541 AZ:371 c:2 z:1 SX:55 SY:50 AX:273 AY:511 AZ:341 c:2 z:1 SX:64 SY:50 AX:392 AY:464 AZ:238 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:60 SY:10 AX:246 AY:536 AZ:295 c:2 z:1 SX:62 SY:-3 AX:105 AY:515 AZ:261 c:2 z:1 SX:64 SY:120 AX:1023 AY:1023 AZ:823 c:2 z:1 SX:64 SY:-8 AX:835 AY:546 AZ:160 c:2 z:1 SX:63 SY:-8 AX:715 AY:473 AZ:176 c:2 z:1 SX:62 SY:-8 AX:201 AY:497 AZ:311 c:2 z:1 SX:63 SY:-8 AX:313 AY:476 AZ:419 c:2 z:1 ( 0154 $3822 ok ) .s Data Stack (0) ( 0155 $3822 ok )Thanks to try nunchuk code.
I tried your code.
But these values are strange.
SX and SY should be between 100 and -100.
AX,AY,AZ:approximately 300 to 700
SX and SY is not from 100 to -100
AX/AY/AZ is sometimes 1023. AX/AY/AZ is 10bit(max1023)
BTW, your using Tachyon version?
I set myIP, mySN, myGW before and then I do which gives: It seems that WCOLD doesn't write to the wiznet chip ?!
PS:
The ethernet connection is up, LED is on, but there is no gateway available
Thanks in advance, best regards,
proplem
could be this:
WCOLD refers to the constants defined in EASYNET.fth
if you define NEW constants, WCOLD still refers to the old ones.
So you need to change the values of the original constants with: AT .... hmmm - seems to be gone.
but it looks like you can use those to put new values into EEPROM
ADD: WCOLD writes to EEPROM not to WIZNET
[CONL] [HIGH] [LOW] where the constant is encoded as 2 words in high low order so you need to split your new value into 2 words and write them to these fields. Otherwise just use SIP and GATEWAY.
I am using this version:
Yes I see there are some problems.
Now I have made it slower.
I now use this:
Will it work for you?
I use Tachyon "Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170712.0020".
These data looks like correct.
What is "320 16 COG!"?
The first thing you need to do is simply search for this in TACHYON.SPIN or EXTEND.FTH where you will find:
However I noticed a bug there, somehow my constant in I2C100 got deleted so switching to this mode could switch to almost any speed. Here is what I think it should be but I will also check the timing at some point. EDIT: I typed in 48 but what was I thinking .... try a lower value etc. I notice frida has a very long delay in there of 320 which is probably way too slow.
@MJB - I've been labeling private subroutines in the form ~x since V4 allows subroutines to be added and called efficiently. It doesn't matter that there might be routines named the same since it is only the most recent definition that would be referenced anyway. An optional RECLAIM can remove all the private headers to free up some memory without having to compact the dictionary into EEPROM.
sure - only the most recent definition will be referenced in new code.
so rewriting to so using the old fall thru technique is a bit more difficult to read but would not gain a lot - right?
but is still valid?
looks like - but RECLAIM hangs the PROP
with
yea - missed that I2CFAST fall through ...
your introduction of CLKMHZ gives up resolution in selecting the division factor ...
but will usually be ok.