Shop OBEX P1 Docs P2 Docs Learn Events
Tachyon V4 "DAWN" - exploring new worlds - Page 21 — Parallax Forums

Tachyon V4 "DAWN" - exploring new worlds

1181921232430

Comments

  • I've reverted the default console prompt back to a simpler one with a programmable prompt. Any preferences?
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170712.1730MODULES LOADED: 
    1AC0: EXTEND.fth          Primary extensions to TACHYON V4.5 kernel  - 1707012-0930
    
    AUTORUN BOOT
    FREQ = 96.0MHz
    *** INITS ***
    Loading cog 3 E50A F32     
    *** ROMS ***
    0,848 VGA32x15  
    0,392 HSUART    
    1,900 F32       
    *** I2C ***
    A0 EEPROM
    INTERCOM: &00.00.00.00 @2,000,000
     CODE:$3562 =13154 bytes   NAME:$59C4 =6716 bytes   DATA:$7704 =244 bytes    =9314 bytes free    Data Stack (0)
    -------------------------------------------------------------------------------- ok
    ..  12 34 + . 46 ok
    ..  " PBJ>"  id $!  ok
    PBJ> .S  Data Stack (0) ok
    PBJ> " .. "  id $!  ok
    ..    ok
    ..  
    
  • Please teach me how to use WAITPEQ and WAITPNE and WAITCNT.
  • MJBMJB Posts: 1,235
    edited 2017-07-15 21:48
    caskaz wrote: »
    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.
  • caskazcaskaz Posts: 957
    edited 2017-07-16 13:06
    Thanks MJB.

    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).
  • MJBMJB Posts: 1,235
    caskaz wrote: »
    Tanks MJB.

    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.

  • MJBMJB Posts: 1,235
    caskaz wrote: »
    Tanks MJB.

    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
    	;
    
    
    it is all there ... ;-)
  • caskazcaskaz Posts: 957
    edited 2017-07-17 06:44
    I have question.
    Code below ocuur stack-overflow.
    What is it wrong?
    : test
    CNT@ #8000000 +
    BEGIN ." 5" #8000000 WAITCNT KEY UNTIL DROP
    ;
    

    Sorry, solved to check HELP-folder.
    : test #8000000 DELTA BEGIN ." 5" WAITCNT KEY UNTIL ;
    
  • caskazcaskaz Posts: 957
    edited 2017-07-17 07:47
    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.
  • MJBMJB Posts: 1,235
    caskaz wrote: »
    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 ...

    so what do you need clock stretching for?


  • @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.
  • caskazcaskaz Posts: 957
    edited 2017-07-18 00:27
    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.
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-07-18 00:48
    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"
  • Hi Peter.

    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?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-07-18 04:11
    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.
  • FANCY ANSI


    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.
    ANSI.png
    2094 x 1408 - 56K
  • I wrote code for Wii-nunchuc.
    This don't operate on Tachyon's I2C-word(I2C100).
  • MJBMJB Posts: 1,235
    caskaz wrote: »
    I wrote code for Wii-nunchuc.
    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.
  • MJBMJB Posts: 1,235
    edited 2017-07-19 17:48
    caskaz wrote: »
    I wrote code for Wii-nunchuc.
    This don't operate on Tachyon's I2C-word(I2C100).
    just had a little code reading ...
    I2C100 lsi2c     \ I2C100  set's the delay in COGREG 16  and then the normal I2C routines should work as usual
    
    @Peter_Jakacki : pri ~I is defined twice in EXTEND . While it works, it could confuse a casual reader ;-)
  • caskaz wrote: »
    I wrote code for Wii-nunchuc.
    This don't operate on Tachyon's I2C-word(I2C100).

    @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 )   
    
  • caskazcaskaz Posts: 957
    edited 2017-07-20 04:52
    Hi frida.
    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?
  • @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:
    &17.20.19.18 WIZPINS	( P8 )
    &192.168.0.1		== myGW
    &192.168.0.99		== myIP
    &255.255.255.0		== mySN
    .VER CR .MODULES
    
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170715.1415
    MODULES LOADED: 
    50EA: EASYNET.fth         WIZNET NETWORK SERVERS 170708.0000 
    487C: W5500.fth           WIZNET W5500 driver 170708.0000 
    
    3616: EASYFILE.fth        SDHC card + FAT32 Virtual Memory Access File System Layer V1 
    1B00: EXTEND.fth          Primary extensions to TACHYON V4.5 kernel  - 1707017-1100 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
    
    ..  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
  • MJBMJB Posts: 1,235
    edited 2017-07-20 20:46
    proplem wrote: »
    @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:
    &17.20.19.18 WIZPINS	( P8 )
    &192.168.0.1		== myGW
    &192.168.0.99		== myIP
    &255.255.255.0		== mySN
    .VER CR .MODULES
    
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170715.1415
    MODULES LOADED: 
    50EA: EASYNET.fth         WIZNET NETWORK SERVERS 170708.0000 
    487C: W5500.fth           WIZNET W5500 driver 170708.0000 
    
    3616: EASYFILE.fth        SDHC card + FAT32 Virtual Memory Access File System Layer V1 
    1B00: EXTEND.fth          Primary extensions to TACHYON V4.5 kernel  - 1707017-1100 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
    
    ..  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
    \ common registers
    
    \ Access common registers
    pub wMODE ( mask -- )		0 COMLC! ;
    pub GATEWAY ( addr -- )		DUP @gateway E! 1 COML! ;
    pub SUBNET ( mask -- )		DUP @subnet E! 5 COML! ;
    pub MAC ( high low  -- )	DUP @mac E! $0B COML! 9 LW! ;
    pub SIP ( long -- )		DUP @sip E! $0F COML! ;
    
    

    ADD: WCOLD writes to EEPROM not to WIZNET
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-07-20 22:38
    @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.
  • caskaz wrote: »
    Hi frida.
    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 am using this version:
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170709.1930
    
    MODULES LOADED: 
    1B00: EXTEND.fth          Primary extensions to TACHYON V4.5 kernel  - 170706-0930
    
    AUTORUN BOOT
    FREQ = 80.0MHz
    *** INITS ***
    NO ROMS
    *** I2C ***
    A0 EEPROM
    A4 EEPROM
    
    INTERCOM: &00.00.00.00 @2,000,000
     CODE:$35F2 =13298 bytes   NAME:$59E8 =6680 bytes   DATA:$7704 =244 bytes    =9206 bytes free    Data Stack (0)
    
    --------------------------------------------------------------------------------
    ( 0001 $35F2  ok )   
    
      Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170709.1930
    
    MODULES LOADED: 
    1B00: EXTEND.fth          Primary extensions to TACHYON V4.5 kernel  - 170706-0930
    
    AUTORUN BOOT
    FREQ = 80.0MHz
    *** INITS ***
    NO ROMS
    *** I2C ***
    A0 EEPROM
    A4 EEPROM
    
    INTERCOM: &00.00.00.00 @2,000,000
     CODE:$35F2 =13298 bytes   NAME:$59E8 =6680 bytes   DATA:$7704 =244 bytes    =9206 bytes free    Data Stack (0)
    
    --------------------------------------------------------------------------------
    ( 0001 $35F2  ok )  
    

    Yes I see there are some problems.
    Now I have made it slower.
    I now use this:
    : test_Nunchuk
    I2C100
    --- 286 16 COG! \ lowest
    320 16 COG!
    16 COG@ . CR
    

    Will it work for you?
  • Hi frida.

    I use Tachyon "Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170712.0020".
    These data looks like correct.

    What is "320 16 COG!"?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-07-21 16:14
    caskaz wrote: »
    Hi frida.

    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.


  • MJBMJB Posts: 1,235
    --- 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
    

    with
     Propeller .:.:--TACHYON--:.:. Forth V4X5 DAWN 450170705.1015
    
    MODULES LOADED:
    1B00: EXTEND.fth          Primary extensions to TACHYON V4.5 kernel  - 170706-0930
    
    AUTORUN BOOT
    FREQ = 80.0MHz
    *** INITS ***
    Loading cog 3 E506 F32
    *** ROMS ***
    0,848 VGA32x15
    0,388 HSUART
    1,900 F32
    *** I2C ***
    42 I/O EXPANDER
    A0 EEPROM
    
    INTERCOM: &00.00.00.00 @2,000,000
     CODE:$35DA =13274 bytes   NAME:$59E8 =6680 bytes   DATA:$7704 =244 bytes    =9230 bytes free    Data Stack (0)
    
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-07-21 21:27
    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.
  • MJBMJB Posts: 1,235
    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.
Sign In or Register to comment.