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.
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.
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.
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
--- 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?
@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.
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.
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.
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.
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)
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
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).
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?
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.
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 ;-).
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.
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
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
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"?
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. ...
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
@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 ???
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.
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.
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".
@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..
Comments
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.
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
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
;
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
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.
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
I am experimenting with unnamed words ;-)
like the unnamed Lambda's we have in LISP.
but it is not completely right yet 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.
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
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)
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 } ENDDid 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).
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?
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 ;-).
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.
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
..
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"?
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. ...
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
Yes. One would have to seriously consider if there is a P2 market any more ???
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:
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.
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.
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..