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

Tachyon V4 "DAWN" - exploring new worlds

1212224262730

Comments

  • Erna - while I could play with the SD card software and tweak it a bit more and test out various brands I just haven't had any need especially seeing that some are trying to use rather old cards anyway. For a few dollars just buy a new one and I've always found Sandisk work to spec unlike some. I even have some rebranded cards that output junk on the data lines before they are initialized etc. Do you think it is a real problem to use a good card vs an old card which although we may get it to work have been shown to have long latencies vs the new cards.

    BTW, NEON uses the same code too, but I felt it needed a major version since the dictionary structure will be quite different, but ordered. Even the dictionary is the same in the Prop source kernel but it gets restructured and moved on a cold start.
  • ErNaErNa Posts: 1,738
    Hello Peter, I'm very close to do real work with Tachyon. My main fear is to use a system, that changes behavior in an unpredictable manner. So if SD cards are not according standard, I'm eager not to use them. It would be bad, very bad, to save a dollar and buy a problem. But as sd cards are improved over the years, compatibility is a issue. If Tachyon works with a certified card, this should not change without notice. If a given card creates problems, this is out of your scope. Freeing up memory for the P1 is a good idea, because such a solution will give extra space to the P2. This will be good, very good, to all sides, to the left and to the right.
  • Yes, my whole point about using Sandisk cards is that they just work and are predictable but it is certainly not a major issue to test other common cards. I'm fairly certain that any hiccups recently are fairly easy to fix.... once I figure out why some brands misbehave that is. I am using Sandisk Ultra at present since they are faster and are the most common and affordable and the microSD all come with a standard adapter too. There doesn't seem to be anything available under 16GB though and I'm paying around $12 AUD for 16GB, about the same price as a steak lunch at the local.

  • Cluso99Cluso99 Posts: 18,066
    Agreed SanDisk cards always seem to work. 8GB microSD seem no longer available (at least Officeworks in Oz) as 16GB is now the smallest, and double the price!

    BTW I am not seeing any problems with the other brand microSD cards that I have since I moved to Kye's driver which includes the extra clocks to ensure DO release.
  • Cluso99 wrote: »
    Agreed SanDisk cards always seem to work. 8GB microSD seem no longer available (at least Officeworks in Oz) as 16GB is now the smallest, and double the price!

    BTW I am not seeing any problems with the other brand microSD cards that I have since I moved to Kye's driver which includes the extra clocks to ensure DO release.

    Yes, I do have extra clocks for this too but obviously there's more to it and when I hook it up again to the LA I will track it down this time :)

  • MJBMJB Posts: 1,235

    EASYFILE.fth

    --- Open or create a file
    pub FMAKE$ ( name -- flg )
    --- create default 1MB file if it doesn't exist
    FOPEN$ NOT IF 64 MB FILE$ FCREATE$ FOPEN$ THEN
    ;


    scan logic confuses me.
    scan = 0 means NO scan
    scan <> 0 means use slower scan method --- right??

    pri APPEND.BLK ( -- relblk )
    FSECT@ FSIZE@ 9 >> OVER+ SWAP ( max min )
    BEGIN
    --- Find new mid point ( max min mid )
    2DUP - 2/ OVER+
    --- flag scan method ( max min )
    scan C~~ SECTOR --- set scan<>0 to activate scan
    2DUP - 1 >
    WHILE
    --- if true then too high ( max min flg )
    sdbuf C@ eof C@ =
    IF 2DUP - 2/ OVER+ ROT DROP SWAP
    ELSE 2DUP - 2/ OVER+ NIP
    THEN
    REPEAT
    --- shouldn't we RESET scan = 0 to DEactivate scan as normal state? or is scan=$FF considered normal mode??
    NIP FSECT@ -
    ;


    pri RDSECT ( dst -- crcflg )
    --- card has been prep'd for read - proceed and read a block of data
    --- MOSI high
    2 COG@ OUTSET
    scan C@ NOT --- why the NOT ?? logic reversed??
    IF --- use slower scan method
    [SDRD] ( dst eof -- firstPos charcnt ) scanch C@ RUNMOD scancnt W+!
    scanpos W@ 0= IF scanpos W! ELSE DROP THEN
    ELSE --- use raw & fast method (no scan)
    [SDRDF] BLKSIZ RUNMOD
    THEN
    scan C~~
    --- switch back to standard SPI mode (for commands etc)
    [SDIO] 0-1 SDIO8 SDIO8 $FFFF AND DUP 0= IF 31 MASK OR THEN
    ;
  • Hi there,
    trying to build the latest v4r5. Hardware is iot5500.
    1 baudrate 115200
    2 downloading kernel - ok
    3 line delay for always 50 ms
    4 downloading EXTEND.FTH
    4.1 (maybe) endless reset loop. Remembered Mike Green's Post on p 23 and Peter's answer
    5 downloading EASYFILE.FTH
    5.1 minicom line delay 50 ms pasting manually - minicom/iot5500 hang

    Peter could you collect a working v4r5 set of files for the iot5500 and make it accessible in your dropbox?

    Thanks in advance,
    proplem
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-08-29 15:12
    @proplem - I'm using those files right now. In minicom I use 5ms line delay to load EXTEND and EASYFILE and then COMPACT. After which I COMPACT, BACKUP and then proceed to load in EASYNET which has the first line set to "FL EASYNET.FTH" to load to EASYFILE.fth first (hit an escape after this). This should automatically FLOAD but there's a small bug there but you can then FLOAD EASYNET.FTH easily. If you don't let it fast load into a file first (just type \ and a space before you transfer the file) you will find that you may have to set the line delay to 50ms or so since the dictionary is in slow EEPROM.

    Here though are the files and I will do a fresh load myself from these just to make sure.


    BTW, if "lsio" which tests and reports the state of the I/O pins is causing a reset then you can also tap some ^A characters after reset to force the high level BOOT routine to abort early and not run these tests. It would be good to find out what's on that pin though that's causing it to reset.
  • Hi Peter,
    tachyon v4r5 build for iot5500 is now fine. Also the resetting is explained. In my Linux setup the reset via rs232 isn't working so after loading the kernel I have to reset manually which I do via a switch connected to another pin which normally isn't used. By setting this pin via "lsio" the reset is initiated. Ok. That's also clear now.

    Thank you for the quick premium support!

    Best regards,
    proplem
  • MJBMJB Posts: 1,235
    edited 2017-08-31 17:18
    Hi @Peter
    I am experimenting with unnamed words ;-)
    like the unnamed Lambda's we have in LISP.

    but it is not completely right yet
    
    ..  OFF ANYCASE  ok
     .  8 words myAlarms
     .  BYTE alarmcnt
    ..  alarmcnt C~  ok
    ..
    ..  pre :A
    ..       HERE
    ..       myAlarms alarmcnt C@ 2* + W!
    ..       alarmcnt C++
    ..       7 flags SET ;
    ..
    ..  :A ." Alarm0"  ;
    ..  :A ." Alarm1"  ;
    ..  :A ." Alarm2"  ;
    ..  :A ." Alarm3"  ;
    ..  myAlarms 10 DUMP
    0000.7960:   B8 47 C4 47  D0 47 DC 47  00 00 00 00  00 00 00 00    .G.G.G.G........ ok
    ..  myAlarms W@ CALL Alarm0 ok
    ..  myAlarms FROM 2 BY 4 FOR I W@ CALL CR NEXT Alarm0
    Alarm1
    Alarm2
    Alarm3
     ok
    ..
    ..  OFF ANYCASE  ok
     .  8 words myAlarms
     .  BYTE alarmcnt
    ..  alarmcnt C~  ok
    ..
    ..  pre :A
    ..       HERE
    ..       myAlarms alarmcnt C@ 2* + W!
    ..       alarmcnt C++
    ..       7 flags SET ;
    ..
    ..  :A ." Alarm0"   Alarm0 ok
    ..  ." Alarm0second"  ;
    ..  :A ." Alarm1"  ;
    ..  :A ." Alarm2"  ;
    ..  :A ." Alarm3"  ;
    ..
    ..  CR myAlarms FROM 2 BY 4 FOR I W@ CALL CR NEXT
    Alarm0second
    Alarm1
    Alarm2
    Alarm3
     ok
    ..
    
    
    when I only have onliners after :A than it looks OK,
    but not for multi lines.
    I think this has to do with the evaluation at <CR>
    also I am not sure if I forget to clean some flags and leave some garbage.
  • MJBMJB Posts: 1,235
    Hi Peter,
    I wanted to use 1Wire on V4.5 but obvoiusly a lot has changed.
    Do you already have a working port of 1Wire to V4.5,
    to be used in the demonstrator?
    then it saves me some time.
    Otherwise I will do it.

    thanks
    MJB

  • MJBMJB Posts: 1,235
    MJB wrote: »
    Hi Peter,
    I wanted to use 1Wire on V4.5 but obvoiusly a lot has changed.
    Do you already have a working port of 1Wire to V4.5,
    to be used in the demonstrator?
    then it saves me some time.
    Otherwise I will do it.

    thanks
    MJB
    found it - will be testing it
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-09-07 02:59
    HVAC MODBUS interface

    The trouble with Forth is that it is too interactive, I find myself exploring so many different ideas. The other week the ducted HVAC started playing up but the MYAIR touch panel display gave no indication that there was any problem, nor does it ever show "problems". Right I said, this is no good, so I crawled up into the roof over the ducting and located the control modules. After some investigation I decided to connect a cable to a protocol converter box that converted the DIII-net bus from the Daikin compressor to the MYAIR system and I ran this cable back down into the workshop. That's when I found out that the interface to the MYAIR system was RS485 and connecting it to a Prop board I could see that it seemed to be the default 9600 baud.

    This is where it was a simple matter to write a couple of one-liners and capture the traffic into a buffer, it looked like this (slightly formated)
    01 03 00 31 00 01 D5 C5    01 03 02 08 00 BF 84
    01 03 00 00 00 01 84 0A    01 03 02 00 00 B8 44
    01 03 00 01 00 01 D5 CA    01 03 02 00 03 F8 45
    

    This looked a lot like MODBUS protocol with CRC-16 so I wrote a few more one-liners and started decoding the information that was being read by the MYAIR system. Knowing the setpoint I was able to track down the packet and register for this one and then by changing the modes I was able to track down most of the other packets. After fancying this up I tried sending stuff on the bus by synchronizing between polling from the master. This way I could read other registers that weren't being polled plus I could also set them which means that I could now control the HVAC compressor.

    I will probably develop this into some sort of fully-blown commercial product with the zone monitoring and control as well with Ethernet and Bluetooth but in the meantime here is the code I am using. The code size is less than 1kB, in fact it's only 810 bytes. To control it from a terminal I could type a few commands in one line such as " ON AIRCON HEAT 25 SETPOINT 2 FAN"

    BTW, the problem was that the filters needed a good cleaning, something that my wife looked after while I did the fun stuff ;)
    TACHYON V4
    
    pub HVAC.fth		PRINT" Some utilities for accessing the DAIKIN HVAC CB via MODBUS 170907-0000" ;
    
    @org W@	== @rest	--- remember data org for FORGET
    
    --- RS485 pins
    #P1		== *TR0
    #P0		== *TE0
    
    
    --- read a modbus word (big endian)
    pri MW@ ( addr -- llhh )	C@++ 8<< SWAP C@ + ;
    
    TIMER mbtmr		--- MODBUS activity timer
    
    --- Synchronize MODBUS receive
    pri MBSYNC ( ms -- )
    	--- retrigger timer with specified delay
    	DUP mbtmr TIMEOUT
    	BEGIN
    	  --- retrigger anytime we detect activity
    	  BEGIN *TR0 PIN@ 0= WHILE DUP mbtmr TIMEOUT REPEAT
    	  --- until it times out
    	  mbtmr TIMEOUT?
    	UNTIL
    	DROP
    	;
    
    20 bytes mbcap		--- MODBUS task capture buffer
    
    12 longs mbstk		--- loop stack for MODBUS task
    
    200 bytes mbregs	--- maintain up to 200 holding registers
    
    --- read a register from the mbregs array
    pub MB@ ( reg -- word )		2* mbregs + W@ ;
    
    byte txreq		--- request for transmission flag to MODBUS task
    
    --- background MODBUS receive task
    pub MBTASK
    	mbstk LP!
    	mbregs 200 ERASE
    	9600 SERBAUD
    	BEGIN
    	  --- allow at least 20ms gap to synch to command packet from master
    	  20 MBSYNC mbcap FROM 8 FOR *TR0 SERIN I C! NEXT
    	  --- just read the register address and assemble index into mbregs array
    	  mbcap 2+ MW@ 2* mbregs + ( addr )
    	  --- standard MODBUS synch between packets of >5ms
    	  5 MBSYNC mbcap FROM 7 FOR *TR0 SERIN I C! NEXT
    	  --- just read result for register requested and save in mbregs
    	  mbcap 3 + MW@ SWAP W!
    	  --- now let foreground task send a packet if requested
    	  txreq C@ IF txreq C~ 20 ms THEN
    	AGAIN
    	;
    
    word crc16
    
    --- Init send
    pri !SEND			-1 crc16 W! 9600 SERBAUD ;
    
    --- accumulate the CRC-16
    pri CRC	( n -- )	crc16 W@ XOR 8 FOR DUP 2/ SWAP 1 AND IF $A001 XOR THEN NEXT crc16 W! ;
    
    --- send a byte over the MODBUS lines - maintain CRC
    pri SEND ( ch -- )	DUP CRC *TR0 HIGH *TE0 HIGH *TR0 SEROUT ;
    
    --- Send a 16-bit word as hh ll
    pri SEND16 ( word -- )	W>B SEND SEND ;
    
    --- Send the CRC ( ll hh ) and release RS485
    pri SENDCRC		crc16 W@ W>B SWAP SEND SEND *TR0 FLOAT *TE0 LOW ;
    
    --- Wait for inactivity before transmitting packet ( multiple masters )
    pri TXWAIT			!SEND txreq C~~ BEGIN txreq C@ 0= UNTIL 7 ms ;
    
    8 bytes response		--- response packet
    
    --- MODBUS command and single register response
    pub MBCMD ( cmd -- response )
    	TXWAIT 1 SEND SEND SEND16 1 SEND16 SENDCRC
    	response FROM 7 FOR *TR0 SERIN I C! NEXT response 3 + MW@
    	;
    
    --- request holding register
    pub HOLD@ ( reg -- val )	3 MBCMD	;
    
    --- request input register
    pub INP@ ( reg -- val )		2 MBCMD ;
    
    --- preset holding register
    pub PRESET ( val reg -- )	TXWAIT 1 SEND 6 SEND SEND16 SEND16 SENDCRC ;
    
    --- some common HVAC operations
    pub SETPOINT ( temp -- )	10 * 4 PRESET ;
    pub FAN ( speed -- )		2 PRESET ;
    pub HEAT			1 1 PRESET ;
    pub COOL			4 1 PRESET ;
    pub FANONLY			3 1 PRESET ;
    pub AIRCON ( on/off -- )	1 AND 0 PRESET ;
    
    --- print A/C version
    pub .ACVER			50 HOLD@ . ;
    
    --- dump modifiers to request MODBUS registers rather than memory (default)
    pub HOLDING	DUMP: HOLD@ HOLD@ HOLD@ ;
    pub INPUTS	DUMP: INP@ INP@ INP@ ;
    
    --- print compressor block data
    pub .CB
    	CR PRINT" HVAC" 14 XTAB 0 MB@ IF PRINT" ON" ELSE PRINT" OFF" THEN
    	CR PRINT" FAN SPEED"  14 XTAB 2 MB@ 1- 3 AND 4* " LOW MED HIGH????" + 4 CTYPE
    	CR PRINT" SETPOINT" 14 XTAB 4 MB@ 0 1 .DP
    	CR PRINT" RETURN" 14 XTAB 5 MB@ 0 1 .DP
    	CR PRINT" AMBIENT" 14 XTAB 22 MB@ 0 1 .DP
    	CR PRINT" MODE" 14 XTAB 1 MB@ 1- 3 AND 4* " HEAT????FAN COOL" + 4 CTYPE
    	CR PRINT" ERROR CODE" 14 XTAB 11 MB@ .
    	CR 10 MB@ 0= IF PRINT" NO " ELSE red PEN THEN PRINT" ALARM" PLAIN
    	;
    
    --- display A/C in terminal - any key terminates
    pub HVAC
    	' MBTASK 7 RUN
    	BEGIN 9 HOLD@ CLS
    	  PRINT" HVAC DISPLAY  " SPINNER
    	  CR PRINT" RUN HOURS" 14 XTAB .
    	  .CB CR 200 ms KEY
    	UNTIL
    	;
    { HVAC display
    HVAC DISPLAY  \
    RUN HOURS      8248
    HVAC           ON
    FAN SPEED      LOW
    SETPOINT       24.0
    RETURN         27.7
    AMBIENT        24.8
    MODE           HEAT
    ERROR CODE     0
    NO ALARM
    }
    
    END
    

  • proplemproplem Posts: 233
    edited 2017-09-07 20:25
    HVAC MODBUS interface

    The trouble with Forth is that it is too interactive, ...
    END
    Master Yoda - again the Forth was with you! Really "cool" :-)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-09-07 22:32
    proplem wrote: »
    HVAC MODBUS interface

    The trouble with Forth is that it is too interactive, ...
    END
    Master Yoda - again the Forth was with you! Really "cool" :-)

    Did I mention it is a lot of fun!? Stay tuned for when I interface to the zone control motors which are plugged in on little RJ11s and I might replace the wireless sensors with my own based on ESP8266s instead. The trouble with the wireless sensors I reason is that they need to be mounted up higher in summer and lower in winter or the sensible thing could be that each just has an extra temperature sensor element, so I plan to do the sensible thing with my own circuit plus I won't need a dedicated wireless base station either.

    The existing unit has a tablet like touch panel and allows control from phone apps too although this spends way too much time searching for the system and then promptly forgets where it found it ( no IP address). I plan to use a standard tablet on WiFi running off the charger but with a 3D Bezel to cover and mount it.

    The existing zone control designates a "master" zone but that is plain dumb because after the master zone reaches setpoint the airflow is reduced etc and the other zones suffer. This just needs a good algorithm for ensuring that all zones reach their setpoint and then the compressor can be instructed to take it easy.

    Maybe this is a good project for Hackaday, or Nuts and Volts.....

    Now my wife is confused because I can put the unit into modes that the existing panel doesn't know how to report (auto fan speed, auto cool/heat/dry etc).
  • ErNaErNa Posts: 1,738
    edited 2017-09-11 12:46
    Gateway needed
    Hello Peter, I'm sure it is a simple task, but not to me. I'm in need for a IoT5500 based gateway to just route an information, incoming via http or udp to a serial pin and sending serial information back. Can you assist ;-) by creating a solution?
  • ErNa wrote: »
    Gateway needed
    Hello Peter, I'm sure it is a simple task, but not to me. I'm in need for a IoT5500 based gateway to just route an information, incoming via http or udp to a serial pin and sending serial information back. Can you assist ;-) by creating a solution?
    What about Telnet? That just connects up as the console so you can just as easily send commands etc.

  • ErNaErNa Posts: 1,738
    The task is as follows: A propeller based system is connected to the terminal program via a serial communication. Now I need a gateway: a IoT5500 is serially connected to com, and to the internet. Via the terminal program I can establish an internet connection and communicate with a remote system, another IoT5500. This will output everything I type on the terminal keyboard to a serial pin (not necessarily the tachyon console) and on the other hand, all serial input to the remote system will be transmitted to the local IoT and will be seen at the terminal. This way I can run the propeller based system remotely.
    After a testphase, the local terminal /IoT will be replaced by another IP-device to create machine2machine communication.
    Just now, I do not need more or less than I decribed ;-).
  • MJBMJB Posts: 1,235
    ErNa wrote: »
    The task is as follows: A propeller based system is connected to the terminal program via a serial communication. Now I need a gateway: a IoT5500 is serially connected to com, and to the internet. Via the terminal program I can establish an internet connection and communicate with a remote system, another IoT5500. This will output everything I type on the terminal keyboard to a serial pin (not necessarily the tachyon console) and on the other hand, all serial input to the remote system will be transmitted to the local IoT and will be seen at the terminal. This way I can run the propeller based system remotely.
    After a testphase, the local terminal /IoT will be replaced by another IP-device to create machine2machine communication.
    Just now, I do not need more or less than I decribed ;-).
    as Peter said,
    use the Telnet-Server on the remote site, which gives you access to the terminal.
    From there you can redirect to another serial port if you like,
    and just use prints to the console, which gets sent back by Telnet.

    On the local site open a socket to the Telnet port on the remote site.
    Then you can use stream redirect to send and receive from it.


  • MJBMJB Posts: 1,235

    Hi Peter,
    I wanted to play with a tiny DS3231 module on a PropBoE.
    Unfortunately the I2C bus is not accessible on pin headers.

    So I put it on another 2 pins.
    Interactive play is a bit difficult, because I can not statically change the I2C bus
    since it is used while parsing input. But I could handle it.

    I put the complete session here, with the interresting parts highlighted/bold.
    There is some strange behaviour with timing (seconds) and with LAP.
    LAP probably can not time longer than a full 32-bit wrap around.
    So not 60 seconds ...


    but just 60 seconds also waits only around 6 seconds ...


    .. REBOOT

    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400
    Loading cog 3 E50A F32
    *** MODULES ***
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400
    1B40: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 170814-1100

    AUTORUN BOOT
    FREQ = 80.0MHz
    *** INITS ***
    *** ROMS ***
    E01C: VGA32x15 848
    E37C: HSUART 392
    E514: F32 1900
    *** I2C ***
    $42 I/O PORT
    $A0 EEPROM
    I/O = 31:UHUU 27:DDUD 23:~UUU 19:~~~~ 15:DU~~ 11:~~UU 7:~D~~ 3:~~~U
    INTERCOM: &00.00.00.00 @2,000,000

    CODE:$3818 = 13848 bytes
    NAME:$5940 = 6848 bytes
    DATA:$770C = 252 bytes
    FREE: = 8488 bytes
    Data Stack (0)
    Mon, 01 Jan 2001 00:00:00 AEST

    .. okYON V4 ( V4.5 EASYFILE ) Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 ok

    End of source code, 0000 errors found Load time = 1821309344 cycles at 80MHz = 22.766sec
    Code bytes used = 4294

    CODE:$48DE = 18142 bytes
    NAME:$5090 = 9072 bytes
    DATA:$7AD2 = 1218 bytes
    FREE: = 1970 bytes
    Data Stack (0)

    ok
    ..
    .. ' MOUNT +INIT ok
    ..
    ..
    .. ?BACKUP BACKUP ok
    ..
    .. ---
    .. SD1656 SDPINS ok
    .. &25.22.24.23 SDPINS ok
    .. MOUNT
    Mounted 504B.6474-7006.730C MSDOS5.0 NO NAME FAT32 15,927MB (32,768/cluster) ok
    .. dir
    NO NAME
    ROM0004 .ROM .....a 0000.4040 32k m2014/06/23 11:37 c2017/08/16 16:33.420 a2017/08/16
    NEWFILE .TXT .....a 0000.5040 1M m2001/01/01 00:20 c2001/01/01 00:20.280 a1980/00/00
    ABC .TXT .....a 0000.5840 1M m2001/01/01 01:52 c2001/01/01 01:51.280 a1980/00/00 ok
    ..
    ..
    .. END

    End of source code, 0000 errors found Load time = 0 cycles at 80MHz = 0.000us
    Code bytes used = 4294

    CODE:$48DE = 18142 bytes
    NAME:$5090 = 9072 bytes
    DATA:$7AD2 = 1218 bytes
    FREE: = 1970 bytes
    Data Stack (0)

    ok
    .. okYON V4 ( V4.5 ) Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400 ok

    End of source code, 0000 errors found Load time = 593916880 cycles at 80MHz = 7.423sec
    Code bytes used = 422

    CODE:$4A84 = 18564 bytes
    NAME:$5006 = 9210 bytes
    DATA:$7AF4 = 1252 bytes
    FREE: = 1410 bytes
    Data Stack (0)

    ok
    ..
    .. ---
    .. pub TACHYON TACHYON ~H ;
    .. pub END END ~H ;
    ..
    73F2 *end* ok
    .. END

    End of source code, 0000 errors found Load time = 0 cycles at 80MHz = 0.000us
    Code bytes used = 430

    CODE:$4A8C = 18572 bytes
    NAME:$6FFE = 1026 bytes
    DATA:$7AF4 = 1252 bytes
    FREE: = 9586 bytes
    Data Stack (0)

    ok
    .. BACKUP BACKUP ok
    .. *SCL .S Data Stack (1)
    $0000.001C - 28
    ok
    .. *SDA ok
    .. . 29 ok
    .. ' *SDA 10 DUMP
    0000.258C: 1D 80 3F 00 9C 00 14 00 20 80 AA 00 02 7F 99 00 ..?..... ....... ok
    .. $1D . 29 ok
    .. ' *SDA C@ . 29 ok
    .. lsi2c *** I2C ***
    $42 I/O PORT
    $A0 EEPROM ok
    .. lsio 31:UHUU 27:DDHL 23:LUUU 19:~~~~ 15:DU~~ 11:~~UL 7:~DHH 3:~D~U ok
    .. pub RTCI2C ( SDA SCL -- ) ' *SCL C! ' *SDA C! ;
    .. pub I2CORG 28 ' *SCL C! 29 ' *SDA C! ;
    ..
    .. pub MYRTC 9 8 RTCI2C ;
    .. MYRTC lsi2c I2CORG *** I2C ***
    $D0 RTC ok
    ..
    .. MYRTC .TEMP I2CORG 26.50'C ok
    .. MYRTC .TEMP I2CORG 30.75'C ok
    .. .DT Mon, 01 Jan 2001 00:30:05 AEST
    ok
    .. MYRTC .DT I2CORG Mon, 01 Jan 2001 00:30:34 AEST
    ok
    .. MYRTC 154400 TIME! 170914 DATE! I2CORG ok
    .. .DATE 2017/09/14 ok
    .. .TIME 15:44:11 ok
    .. .DT Mon, 14 Sep 2017 15:45:42 AEST
    ok
    .. MYRTC THU DAY I2CORG ok
    .. .DT Thu, 14 Sep 2017 15:46:48 AEST
    ok
    .. BACKUP BACKUP ok
    ..

    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400
    Loading cog 3 E50A F32
    Mounted 504B.6474-7006.730C MSDOS5.0 NO NAME FAT32 15,927MB (32,768/cluster)
    *** MODULES ***
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400

    3818: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System Layer V1.2 170807-1600
    1B40: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 170814-1100
    AUTORUN ´
    FREQ = 80.0MHz
    *** INITS ***
    INIT#0 3D9C
    *** ROMS ***
    E01C: VGA32x15 848
    E37C: HSUART 392
    E514: F32 1900
    *** I2C ***
    $42 I/O PORT
    $A0 EEPROM
    I/O = 31:UHUU 27:DDHH 23:LUUU 19:~~~~ 15:DU~~ 11:~~UU 7:~D~~ 3:~D~U
    INTERCOM: &00.00.00.00 @2,000,000

    CODE:$4AB0 = 18608 bytes
    NAME:$6FD6 = 1066 bytes
    DATA:$7AF4 = 1252 bytes
    FREE: = 9510 bytes
    Data Stack (0)
    Sun, 31 Dec 2165 23:46:25 AEST

    ..
    .. MYRTC DS3231 !RTC I2CORG ok
    .. .DT Thu, 14 Sep 2017 15:48:43 AEST
    ok
    .. .DT Thu, 14 Sep 2017 15:48:43 AEST
    ok
    .. .DT Thu, 14 Sep 2017 15:48:43 AEST

    ok
    ..
    .. MYRTC DS3231 !RTC I2CORG ok
    .. .DT Thu, 14 Sep 2017 15:49:39 AEST
    ok
    .. @time . 30412 ok
    .. timers 20 DUMP
    0000.2A8A: 60 77 C5 00 01 00 80 38 3F 00 52 00 4C 00 C3 00 `w.....8?.R.L... ok
    .. timers 50 DUMP
    0000.2A8A: 60 77 C5 00 01 00 80 38 3F 00 52 00 4C 00 C3 00 `w.....8?.R.L...
    0000.2A9A: 14 00 08 80 5D 00 B1 00 B6 F6 B1 00 A2 00 02 7F ....]...........
    0000.2AAA: 4A 00 3F 00 B6 F6 B1 00 4C 00 08 80 5D 00 BB 00 J.?.....L...]... ok
    .. .TIMERS ticks = 1/1,000 runtime = 736,413
    7760: ´ 000,000ms =0000.0000 L76B8
    76B8: ´ 000,000ms =0000.0000 L0001 ALARM=´ ok
    .. .TIMERS ticks = 1/1,000 runtime = 754,544
    7760: ´ 000,000ms =0000.0000 L76B8
    76B8: ´ 000,000ms =0000.0000 L0001 ALARM=´ ok
    .. .TIMERS ticks = 1/1,000 runtime = 775,212
    7760: ´ 000,000ms =0000.0000 L76B8
    76B8: ´ 000,000ms =0000.0000 L0001 ALARM=´ ok
    .. .TIMERS .TIMERS ticks = 1/1,000 runtime = 790,832
    7760: ´ 000,000ms =0000.0000 L76B8
    76B8: ´ 000,000ms =0000.0000 L0001 ALARM=´ ticks = 1/1,000 runtime = 790,852
    7760: ´ 000,000ms =0000.0000 L76B8
    76B8: ´ 000,000ms =0000.0000 L0001 ALARM=´ ok
    .. @time . 30412 ok
    .. @time . 30412 ok
    .. @time @ . 57966632 ok
    .. @time @ . 57975170 ok
    .. @time @ . 57978716 ok
    .. @time @ . 57979593 ok
    .. @time @ . 57980379 ok
    ..
    .. @time @ . 57981292 ok
    .. @time @ . 57985401 ok
    ..
    .. @time @ . @time @ . 5799390557993907 ok
    .. .DT Thu, 14 Sep 2017 16:06:57 AEST
    ok
    .. @time @ . 58029161 ok
    .. .DT Thu, 14 Sep 2017 16:07:13 AEST
    ok
    .. .DT 60 seconds .DT Thu, 14 Sep 2017 16:07:35 AEST
    Thu, 14 Sep 2017 16:07:41 AEST

    ok
    .. .DT 60 seconds .DT Thu, 14 Sep 2017 16:08:37 AEST
    Thu, 14 Sep 2017 16:08:43 AEST
    ok
    .. .DT 120 seconds .DT Thu, 14 Sep 2017 16:09:14 AEST
    Thu, 14 Sep 2017 16:09:27 AEST
    ok
    .. 'X' EMIT 60 seconds 'X' EMIT XX ok
    .. LAP 'X' EMIT 60 seconds 'X' EMIT X ??? LAP .LAP XX505052160 cycles at 80MHz = 6.313sec ok
    .. LAP 'X' EMIT 60 seconds 'X' EMIT LAP .LAP XX505052160 cycles at 80MHz = 6.313sec ok
    .. LAP 1 second LAP .LAP 80000640 cycles at 80MHz = 1.000sec ok
    .. LAP 2 seconds LAP .LAP 160000688 cycles at 80MHz = 2.000sec ok
    .. LAP 60 seconds LAP .LAP 505033600 cycles at 80MHz = 6.312sec ok
    .. LAP 30 seconds LAP .LAP 0 cycles at 80MHz = 0.000us ok
    ..
    ..
    .. LAP 30 seconds LAP .LAP 0 cycles at 80MHz = 0.000us ok
    .. LAP 10 seconds LAP .LAP 800000800 cycles at 80MHz = 10.000sec ok
    .. .DT Thu, 14 Sep 2017 16:17:46 AEST
    ok
    .. MYRTC .DT I2CORG Thu, 14 Sep 2017 16:18:44 AEST
    ok
    ..
    .. MYRTC DS3231 !RTC I2CORG ok
    .. .DT Thu, 14 Sep 2017 16:19:24 AEST
    ok
    ..
    .. MYRTC 162300 TIME! 170914 DATE! I2CORG ok
    .. .DT Thu, 14 Sep 2017 16:23:03 AEST
    ok
    .. .DT 6 seconds .DT Thu, 14 Sep 2017 16:24:00 AEST
    Thu, 14 Sep 2017 16:24:06 AEST
    ok
    .. .DT 60 seconds .DT Thu, 14 Sep 2017 16:24:25 AEST
    Thu, 14 Sep 2017 16:24:32 AEST
    ok
    ..

    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400
    Loading cog 3 E50A F32
    Mounted 504B.6474-7006.730C MSDOS5.0 NO NAME FAT32 15,927MB (32,768/cluster)
    *** MODULES ***
    Propeller .:.:--TACHYON--:.:. Forth V4.5 DAWN 450170727.1400

    3818: EASYFILE.fth SDHC card + FAT32 Virtual Memory Access File System Layer V1.2 170807-1600
    1B40: EXTEND.fth Primary extensions to TACHYON V4.5 kernel - 170814-1100
    AUTORUN ´
    FREQ = 80.0MHz
    *** INITS ***
    INIT#0 3D9C
    *** ROMS ***
    E01C: VGA32x15 848
    E37C: HSUART 392
    E514: F32 1900
    *** I2C ***
    $42 I/O PORT
    $A0 EEPROM
    I/O = 31:UHUU 27:DDHH 23:LUUU 19:~~~~ 15:DU~~ 11:~~UU 7:~D~~ 3:~~~U
    INTERCOM: &00.00.00.00 @2,000,000

    CODE:$4AB0 = 18608 bytes
    NAME:$6FD6 = 1066 bytes
    DATA:$7AF4 = 1252 bytes
    FREE: = 9510 bytes
    Data Stack (0)
    Sun, 31 Dec 2165 23:46:25 AEST


    .. [0n ???
    ..
    ..
    ..
    .. .DT Sun, 31 Dec 2165 23:46:25 AEST
    ok
    ..
    .. MYRTC DS3231 !RTC I2CORG ok
    .. .DT Thu, 14 Sep 2017 16:53:17 AEST
    ok
    ..
    .. .DT Thu, 14 Sep 2017 16:54:07 AEST
    ok
    .. .DT Thu, 14 Sep 2017 16:54:35 AEST
    ok
    ..

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-09-15 02:38
    @MJB -

    I've now changed seconds to actually count off 1000 ms intervals instead but I've never worried about more than a few seconds normally. This means that there is a slight error of around 2us each second but that shouldn't be a worry. I've also updated the time zone as a 4 character string (sorry 5 character summer time zones).

    LAP is used to time code so it's range doesn't have to be huge but I have a "0 MAX" in ELAPSED which turns those negative counter values to zero. I've patched the code to use unsigned 32-bit values so you can LAP right up to the limits of the 32-bit counter. The print routines include scaling so I've patched it to print 64-bit integers too. But I found it necessary to move .LAP over to EXTEND so I could also use the high-level runtime counter for 32-bit milliseconds rather than the CNT.

    Of course, none of this is totally necessary, but there's no problem extending it to do this.


    BTW, have you noticed the Prop's demise on the forum? There are lots and lots of discussion about all sorts of stuff (cars, planets, satellites, cyber attacks etc) but who is actually using the Prop for anything anymore other than "a play"?
  • MJBMJB Posts: 1,235
    Of course, none of this is totally necessary, but there's no problem extending it to do this.

    BTW, have you noticed the Prop's demise on the forum? There are lots and lots of discussion about all sorts of stuff (cars, planets, satellites, cyber attacks etc) but who is actually using the Prop for anything anymore other than "a play"?
    The 'younger' people I meet, the few interrested in engineering at all, know the RPi and the Arduino.
    Not a single had ever heard of the Propeller.
    And when I demo Tachyon then they are really impressed - not that they would really understand ;-) ...

    If I search EBAY:
    36,096 results for Arduino
    12,629 results for Raspberry Pi
    5 results for Parallax Propeller - usually it is ZERO

    If you are not visible noone will buy :-(

    Whenever s.o. searches for Arduino or RPi the Propeller needs to pop up either as an alternative or addon/extension. ...

  • @MJB -


    BTW, have you noticed the Prop's demise on the forum? There are lots and lots of discussion about all sorts of stuff (cars, planets, satellites, cyber attacks etc) but who is actually using the Prop for anything anymore other than "a play"?

    I go live with SAP 9.2 PL07 on the 25th of this month, after that I'm back in Tachyon dev for my projects. Somebody has to make an automatic duck feeder ;)

    dp

  • Cluso99Cluso99 Posts: 18,066
    @MJB - ...
    BTW, have you noticed the Prop's demise on the forum? There are lots and lots of discussion about all sorts of stuff (cars, planets, satellites, cyber attacks etc) but who is actually using the Prop for anything anymore other than "a play"?

    Yes. One would have to seriously consider if there is a P2 market any more ???
  • ErNaErNa Posts: 1,738
    That's a nice idea, a multi purpose duck feeder... could easily pass the turing test. While I know it is a fault, not to use Tachyon, I myself are still a bloody beginner. Will change. We just created a board with three propellers, one IoT5500 compatible (6MHz, W5500) and now software has to be brought to that board. So Propeller and Tachyon will feed a lot..
  • BTW, have you noticed the Prop's demise on the forum? There are lots and lots of discussion about all sorts of stuff (cars, planets, satellites, cyber attacks etc) but who is actually using the Prop for anything anymore other than "a play"?
    I've been disappointed in the lack of forum activity as well but I think Parallax has been doing quite well with BlocklyProp with their educational customers. I recently purchased a Coyote-1 guitar pedal that uses a Propeller. It's a very old product but I think the software architecture is interesting and I'm looking forward to playing with it.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-09-21 06:34
    New UART ROM for V4.5

    I've added a new UART ROM to V4.5. Unlike HSUART which is built for high speed half-duplex communications such as RS485 although it works quite well with any command/response full-duplex, the newer UART ROM was originally based upon full-duplex serial but along the way it got heavily modified. I've tested this to over 1M baud by feeding tx into rx but 480,600 baud should work reliably with any other UART device. The rx and tx buffers and respective sizes can be defined at run-time. The buffers can be larger than 256 bytes.
    ROMS are binary images held in upper EEPROM and able to be loaded into cogs at runtime by name.
    Here is some quick demo code to run this:
    {
    Demonstrates TACHYON FULL-DUPLEX UART ROM
    running in a cog.
    }
    --- define buffers
    128 bytes rxbuf1
    64 bytes txbuf1
    --- define buffer indices in this order
    word rxwr1
    word rxrd1
    word txwr1
    word txrd1
    
    --- Define parameter table for UART cog
    TABLE uart1
    ---	rx  tx  mode
    	1 | 1 | 0 ||
    ---	baudrate ticks
    	CLKFREQ 460,800 / ,
    ---	rxbuf, rxsiz
    	rxbuf1 || 128 ||
    ---	txbuf, txsiz
    	txbuf1 || 64 ||
    ---	ptr to buffer word indices (rxwr,rxrd,txwr,txrd)
    	rxwr1 ||
    
    --- Load a cog with the UART ROM using "uart1" parameter table
    uart1 4 " UART    " LOADCOG
    
    --- define a simple emit routine
    pub EMIT1		txwr1 C@ txbuf1 + C! txwr1 W++ ;
    --- and then define a com port that uses it.
    pub COM1		' EMIT1 uemit W! ;
    

    running it:
    ..  rxbuf1 $20 DUMP 
    0000.770C:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
    0000.771C:   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................ ok
    ..  COM1 .VER CON  ok
    ..  txbuf1 $20 dump 
    0000.778C:   20 20 50 72  6F 70 65 6C  6C 65 72 20  2E 3A 2E 3A      Propeller .:.:
    0000.779C:   2D 2D 54 41  43 48 59 4F  4E 2D 2D 3A  2E 3A 2E 20    --TACHYON--:.:.  ok
    ..  rxbuf1 $20 dump 
    0000.770C:   20 20 50 72  6F 70 65 6C  6C 65 72 20  2E 3A 2E 3A      Propeller .:.:
    0000.771C:   2D 2D 54 41  43 48 59 4F  4E 2D 2D 3A  2E 3A 2E 20    --TACHYON--:.:.  ok
    ..  
    

    I'm also planning to make this handle two channels and if possible any mix of rx/tx as I would like it to handle 4 serial receive inputs but we'll see how it goes. I know it would be possible to do 4 channels in one cog but I like the timing more precise at higher baudrates.

    The timing looks very good in test at 115,200 baud, one stop bit.
    MSO1104Z_DS1ZD180800127_2017-09-21_16.30.43.png
  • Really neat Peter, soon I can re-factor my code and move all the system sideband coms out of the HSUART console channel and use the console for it's purpose, monitor and hack on the working "robot".

  • MJBMJB Posts: 1,235
    pub EMIT1		txwr1 C@ txbuf1 + C! txwr1 W++ ;
    

    I would expect


    pub EMIT1 txwr1 W@ txbuf1 + C! txwr1 W++ ;

    here of course with txbuf1 being only 64 bytes long it does not matter.
    But better save 'cut&paste' programmers from surprises.
  • @MJB - true and true but as was mentioned it is "quick demo code" almost synonymous with "quick and dirty code" :)
    Have a look at UARTCOG.FTH in the V4.5 folder for a more complete version of this code. It's possible to do away with the table structure and just use a handful of words to set parameters too. There's some sample code there for that purpose too that gives you an idea how to go about it..
Sign In or Register to comment.