When we have nothing else to do we will find something to complain about, and while I'm not impressed with the ongoing issues with the forum implementation I'd rather get on with what I'm doing and the ongoing really slomo development of the BREAKOUT video game. I've been hoping that some might dip their big toe into these waters and contribute, even just a little but otherwise I'm using this as an example in developing Tachyon apps.
So now I've added simple ball physics with a bounce method which basically translates the ball movement control digit (7 is up and left, 3 is down and right etc) into a corresponding bounce direction so that a ball that hits the left wall when it's control digit was 7 will return a new direction of 9 for instance. Very simple and easy to follow, even interact with the game routines and single step etc. Ball physics will be enhanced bit by bit so that anyone who wants to can follow along.
Could you write a forum in Forth and solve all of our problems?
hehe, lol, yeah, but then it wouldn't be a forum, it would be a forthum
Funnily enough, I had already given it some passing thought simply to scope out how I would implement it and what would be required etc. Imagine though a whole bank of Propellers serving up the forum and if you didn't like the way it worked you could specify your own "script", w00t!
Then I think of the 800+ man-hours that have been spent on just porting the forums, that's a lot of Forth-seconds there that if devoted to writing code would certainly result in it being worthy of consideration, it might even max out a Prop or two! Would be even better to run the forum on P2, woot woot!
So super cool, I have loaded the EASYFILE FAT32 filesystem, the WIZnet W5500 driver and EASYNET servers, as well as the VGA drivers and the BREAKOUT game. What's super cool? It all fits in an unexpanded Prop, serves up web pages and FTP files from a FAT32 SD card, and Telnet into Forth all while playing a game of breakout on the VGA monitor. Still have 4 cogs free.
Next thing to do is to add sound effects wave files. If you telnet into it at tachyonforth.com port 10001 you can check the score with "score C@ ." for instance. Of course once you telnet in you can pretty much do anything that you could do over a serial console.
Because the Propeller is multicore there is no induced lag in the game or networking.
EDIT: there was still room to squeeze in the Game of Life which I can run serially over Telnet while of course Breakout is playing on the VGA monitor.
Here's a little VGA screen dump word that reads the screen memory and translates the characters as well as formatting a frame for it over serial. So while the game is running I can Telnet into it and type SPY to spy on the game with a live action moving update and this is what I get:
: LOOK
2 SPACES "_" 32 EMITS
@VGA 960 ADO
CR PRINT" |" I 64 ADO
I C@ I 1+ C@ 2 >> 1 AND OR
DUP BL < IF DROP "=" THEN
DUP $FB = IF DROP "*" THEN
DUP $7E > IF DROP "-" THEN
EMIT
2 +LOOP PRINT" | "
64 +LOOP
CR PRINT" |" "_" 32 EMITS "|" EMIT
;
: SPY CLS $0C EMIT BEGIN HOME LOOK KEY $0D = UNTIL ;
I'm pretty sure I crashed your server. Sorry.
Also, every time I ran TEXTBOX on your server, it stopped responding to everything but "bye" and ^C.
I have a Quickstart board with a W5200 board. I should probably be more considerate and crash my own server instead of yours in the future.
I'm pretty sure I crashed your server. Sorry.
Also, every time I ran TEXTBOX on your server, it stopped responding to everything but "bye" and ^C.
I have a Quickstart board with a W5200 board. I should probably be more considerate and crash my own server instead of yours in the future.
Don't worry, that's why it's online, to play with, and crash and burn etc
The textbox function does not return to the console but selects VGA as it's output device. Simply typing CON will return it back. It did kinda crash but I just did a reload by typing "LOADROM BREAKOUT.ROM" which loaded 64k of the EEPROM from file and it was all good again.
I'm pretty sure I crashed your server. Sorry.
Also, every time I ran TEXTBOX on your server, it stopped responding to everything but "bye" and ^C.
I have a Quickstart board with a W5200 board. I should probably be more considerate and crash my own server instead of yours in the future.
Don't worry, that's why it's online, to play with, and crash and burn etc
The textbox function does not return to the console but selects VGA as it's output device. Simply typing CON will return it back. It did kinda crash but I just did a reload by typing "LOADROM BREAKOUT.ROM" which loaded 64k of the EEPROM from file and it was all good again.
Do you want a binary for the QS and W5200?
OK, thanks. I was trying to write stuff on the VGA and then look at it with LOOK.
I think I crashed it again. I would love a binary to run on my own system.
I decided to make some changes and couldn't seem to get it right since it was 3 in the morning and I needed some sleep. I will fire it back up later on and leave it alone while I run my tests on another board. I will also make a binary for the QS seeing that can have a W5200.
in an other thread was the question of how fast to transfer samples of 12 bytes.
So I was curious what sustainable transfer rate I could get with TACHYON
without using a RUNMOD (which can of course be much faster).
{ high speed serial in TACHYON
Streaming speed test
MJB 2015-07-17
Assumption:
Transfer 3 longs from memory as fast as possible
We just set the transfer baudrate and write out,
then set it back to have the terminal again.
}
LONG cnt1
LONG cnt2
cnt1 ~
cnt2 ~
pub SPEEDTEST
80000000 3000000 / 3 MBit/s
5 COGREG!
10 FOR
CNT@
DUP (EMIT)
DUP 8 SHR (EMIT)
DUP 8 SHR (EMIT)
8 SHR (EMIT)
cnt1 @
DUP (EMIT)
DUP 8 SHR (EMIT)
DUP 8 SHR (EMIT)
8 SHR (EMIT)
cnt1 @
DUP (EMIT)
DUP 8 SHR (EMIT)
DUP 8 SHR (EMIT)
8 SHR (EMIT)
cnt1 ++
NEXT
694 5 COGREG! set back to 115200 BAUD
;
LAP SPEEDTEST LAP .LAP
{
LAP SPEEDTEST LAP .LAP 1.600ms ok for 10 times 12 bytes each
1600 120 / . 13 ok
10000 16 / . 625 ok
gives 6.25kHz ( not yet 14.4 kHz) transfer rate of 12 bytes ...
}
{ or as a runmod would be easily much faster
}
- hope the code tags still work
this means at a raw UART speed of 3MBit/s
I get an actual sustainable transfer rate of only 600kBit/s (which is not bad ;-)
just in high level interpreted TACHYON Forth.
It is also easy to write a little few lines PASM module to be loaded,
that can then go much faster.
Probably Peter knows a few tricks to get even my simple Tachyon code faster ...
:arrowl:
in an other thread was the question of how fast to transfer samples of 12 bytes.
So I was curious what sustainable transfer rate I could get with TACHYON
without using a RUNMOD (which can of course be much faster).
{ high speed serial in TACHYON
Streaming speed test
MJB 2015-07-17
Assumption:
Transfer 3 longs from memory as fast as possible
We just set the transfer baudrate and write out,
then set it back to have the terminal again.
}
LONG cnt1
LONG cnt2
cnt1 ~
cnt2 ~
pub SPEEDTEST
80000000 3000000 / 3 MBit/s
5 COGREG!
10 FOR
CNT@
DUP (EMIT)
DUP 8 SHR (EMIT)
DUP 8 SHR (EMIT)
8 SHR (EMIT)
cnt1 @
DUP (EMIT)
DUP 8 SHR (EMIT)
DUP 8 SHR (EMIT)
8 SHR (EMIT)
cnt1 @
DUP (EMIT)
DUP 8 SHR (EMIT)
DUP 8 SHR (EMIT)
8 SHR (EMIT)
cnt1 ++
NEXT
694 5 COGREG! set back to 115200 BAUD
;
LAP SPEEDTEST LAP .LAP
{
LAP SPEEDTEST LAP .LAP 1.600ms ok for 10 times 12 bytes each
1600 120 / . 13 ok
10000 16 / . 625 ok
gives 6.25kHz ( not yet 14.4 kHz) transfer rate of 12 bytes ...
}
{ or as a runmod would be easily much faster
}
- hope the code tags still work
this means at a raw UART speed of 3MBit/s
I get an actual sustainable transfer rate of only 600kBit/s (which is not bad ;-)
just in high level interpreted TACHYON Forth.
It is also easy to write a little few lines PASM module to be loaded,
that can then go much faster.
Probably Peter knows a few tricks to get even my simple Tachyon code faster ...
:arrowl:
found some improvement
LONG cnt0
LONG cnt1
LONG cnt2
cnt0 ~
cnt1 ~
cnt2 ~
pub SPEEDTEST
921600 CONBAUD
3000000 CONBAUD
115200 CONBAUD
80000000 3000000 / 3 MBit/s
5 COGREG@
5 COGREG!
10 FOR
CNT@ cnt0 !
cnt0
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@ (EMIT)
cnt1
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@ (EMIT)
cnt1 @
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@ (EMIT)
cnt1 ++
NEXT
694 5 COGREG! set back to 115200 BAUD
;
LAP SPEEDTEST LAP .LAP
{
LAP SPEEDTEST LAP .LAP 931.600us ok for 10 times 12 bytes each
1000000 931 / . 1074 = 10.74kHz @ 12 bytes / sample
1074 12 * 8 * . 103104 -> 1.03 MBit/s transfer rate at baudrate 3 MBaud
}
without extra PASM - just interpreted TACHYON Forth code
}
Here's one too, I just transfer a block of 1k bytes which takes 6.148ms at 4Mbps. This is about the fastest rate I can transfer at asynchronously but synchronized transmissions can run at much higher rates. The code is simply setting the tx bit-time directly in COGREG 5 and then dumping the 1k block at BUFFERS directly to (EMIT) rather than EMIT which is a higher-level revectorable word that normally defaults to (EMIT). The transfer rate is around 1.3Mbps at 4M baud.
BTW, the transmit routine is not buffered, it is bit-bashed directly from the running cog so it is actually better to run faster rather than slower.
: TXBLK ( baud -- )
CLKFREQ SWAP / 5 COGREG!
BUFFERS $400 LAP ADO I C@ (EMIT) LOOP LAP
50 ms
CLKFREQ 115,200 / 5 COGREG!
.LAP
;
4,000,000 TXBLK 6.148ms ok
1024,000,000 6148 / . 166558 ok
166558 8 * $400A .NUM 1,332,464 ok
4,000,000 TXBLK 6.148ms ok
1024,000,000 6148 / . 166558 ok
166558 8 * $400A .NUM 1,332,464 ok
4,000,000 TXBLK 6.148ms ok
1024,000,000 6148 / . 166558 ok
166558 8 * $400A .NUM 1,332,464 okeh Peter -
just raising raw baud rate to beat me I'd consider cheating ;-)
at 4MBaud raw my code gives even a slight improvement over yours ;-)
LAP SPEEDTEST LAP DUP .LAP 701.600us ok for 10 times 12 bytes each
the enrolled
C@++ (EMIT)
is just a tiny bit faster than the loop even on small block size
so to meet the 14.4 kHz @ 12 bytes / sample requested in the other thread looks like some PASM is needed.
But good to know the limits.
Also, this is only the sending side here. Would the standard receiver just do the 4MBaud ?
Fancy a simple VGA digital clock? How about this one which uses the "big digit" mode for a nice and simple and very easy to read display.
BYTE dtfl,pm
LONG clk
pub (CLOCK)
--- service every 500ms
runtime @ clk @ 500 + > 0EXIT runtime @ clk ! dtfl C++
--- read time and seperate the hours mins seconds
TIME@ 100 U/MOD 100 U/MOD
--- adjust the 24 hour time back to 12 hour and display 00 hours as 12
DUP 12 > DUP pm C! IF 12 - THEN DUP 0= IF DROP 12 THEN
--- display time in big digits
VGA yel HUE BIG
2 4 XY 2 PRINTDEC
16 4 XY 2 PRINTDEC
VGA
--- print seconds
28 10 XY 2 PRINTDEC
--- print AM or PM
28 4 XY pm C@ IF ." PM" ELSE ." AM" THEN
--- plot flashing colon
14 6 XY dtfl C@ 1 AND PLOT 14 8 XY dtfl C@ 1 AND PLOT
--- date as DAY date, month year
red HUE 9 13 XY .DAY SPACE DATE@ 100 U/MOD SWAP 2 PRINTDEC
--- month and year
." , " 100 U/MOD SWAP .MONTH SPACE 2000 + 4 PRINTDEC
--- draw a frame around it
blu HUE 0 0 XY 31 15 BOX
CON
;
pub CLOCK ' (CLOCK) keypoll W! runtime @ clk ! ;
Thanks Ray, I have made some improvements to it since and added temperature and humidity readouts to it as well and will probably add some other information too yet. Since I have Ethernet running on it too I could probably update it remotely as well as reading weather reports. Then I could run the wave audio to a speaker and have it announce local weather warnings too as well as logging the information. With the RS485 on-board it's easy to link into other systems on premises as well as supply power on 4-core.
Thanks Ray, I have made some improvements to it since and added temperature and humidity readouts to it as well and will probably add some other information too yet. Since I have Ethernet running on it too I could probably update it remotely as well as reading weather reports. Then I could run the wave audio to a speaker and have it announce local weather warnings too as well as logging the information. With the RS485 on-board it's easy to link into other systems on premises as well as supply power on 4-core.
WOW Peter, this has certainly progressed!
Makes a very nice tool/block base for your products.
Well it really isn't progress technically, just application of what I already have. The VGA driver and clock etc occupy one tiny little corner of the Prop sitting on top of the Tachyon kernel and extensions and the SD filesystem and network servers. I might add some of my RS485 networking to the extensions as standard though. I also need to have another look at extracting weather information from websites if I want to add that feature. All this on a single unexpanded Prop with cogs to spare, now that's the "beauty" of it.
Yes, I am in awe of your Tachyon. While I don't understand forth, the snippets of what I have seen are easy enough to use. And yes, all on a prop with spare cogs. It's speed is amazing for a higher level language!
Since my Tachyon on Spinneret is broken I can only show how I would parse the file.
Which URL do you want to get what data from?
The versions I am doing now are not compiled for any target in particular, they just rely on a simple config that can be applied after loading a binary. I will test that this is so on an actual Spinneret although I might have to massage the older W5100 features a little to fit in with the W5200 and W5500. So the idea is that you specify the pins used by the SD card and WIZnet etc and even specify the type of I2C RTC by name. For instance if I use MCP79410 I just type that in and the RTC routines work automatically but I can just as easily say DS3231 or whatever common ones are predefined. The Seiko RTC used on the Spinneret is a bit of a weird one though, it's not really I2C so I might end up still doing a special binary just for the Spinneret I think
That VGA digital clock works well except I wanted to fill the screen a bit more so I added 7x9 and 6x8 big fonts to the VGA driver as well as the 5x7. So with a little positioning I can fit the time right across the width of the screen.
If anyone wants to try it out then here is the binary for it (Updated 150729). The clock runs in it's own cog so you can play with Tachyon all you like while it's running. If you happen to have a DHT22 humidity/temperature sensor then hook it up to a pin and specify the pin used with:
<mypin> ' dhtpin 1+ !
If you want to keep the setting then type BACKUP. All that this does is change a runtime constant and to disable it use -1 as a pin value.
I use I2C RTCs such as the DS3231 or MCP79410 although PCF8583 and the like should work too. You may have to type in MCP79410 if you are using that chip but normally there is no need to type DS3231 etc to set other RTCs.
TACHYON [~
FORGET BIGCLOCK.fth
pub BIGCLOCK.fth ." BIG DIGIT VGA CLOCK with temperature and humidity 150727-1000 " ;
--- VGA app for big clock ---
BYTE dtfl,pm
pub (CLOCK)
--- read time and seperate the hours mins seconds
time @ 100 U/MOD 100 U/MOD
--- adjust the 24 hour time back to 12 hour and display 00 hours as 12
DUP 12 > DUP pm C! IF 12 - THEN DUP 0= IF DROP 12 THEN
--- display time in big digits 7X9
VGA yel HUE 7X9
--- most sig hours digit will only ever be 1 or blank so adjust left one pixel
-1 3 XY
DUP 10 < IF SPACE ELSE ." 1" THEN
--- least sig hours digit can butt up against the blank or 1 a little closer
col -- 10 MOD PRINT
--- now there is room for a flashing colon
dtfl C@ 1 AND col @ DUP 5 XY OVER PLOT 9 XY PLOT
col ++
--- minutes color --- red minutes every 5 mins (marker)
DUP 5 MOD 0= IF red HUE THEN
--- minutes
3 row C! 2 PRINTDEC
VGA cyn HUE
--- print seconds
28 12 XY 2 PRINTDEC
--- print AM or PM
28 2 XY pm C@ IF ." PM" ELSE ." AM" THEN
--- date as DAY date, month year
time 4 + @ 100 U/MOD ( dm yymm )
wht HUE 9 1 XY .DAY
--- print month
SPACE 100 U/MOD SWAP .ASMONTH ( dm yy )
--- print dayofmonth
SPACE SWAP 2 PRINTDEC ." ,"
--- print year
SPACE 2000 + .DEC
;
--- print format for humidity and temperatue with trend arros
pri .HT ( val var x y -- )
XY 2DUP AVG > IF red HUE 4 ELSE @ 2/ 2/ SWAP OVER < IF blu HUE 5 ELSE BL THEN THEN VCHAR
grn HUE 0 1 VGA .DP
;
--- DHT22 temperature and humidity sensor - to change: ' dhtpin 1+ ! BACKUP
--- to disable: -1 ' dhtpin 1+ ! BACKUP
-1 == dhtpin
--- averages
LONG avgc,avgh
pub (WEATHER)
--- read temperature and humidity from DHT22 sensor else dummy if -1 specified
dhtpin 1+ IF dhtpin DHT ELSE 500 250 THEN
avgc 2 13 .HT ." 'C "
avgh 22 13 .HT ." %rh "
;
--- display timing
LONG clk
8 LONGS dstk
$7F00 == dregs
pub BIGCLOCK
--- setup stack and registers for new task
7 COGREG@ dregs $80 CMOVE
dregs 7 COGREG! dstk SP! !SP
--- setup VGA
!VGA blu HUE 0 0 XY 31 15 BOX
runtime @ clk !
BEGIN
!SP
--- service every 500ms
runtime @ clk @ 500 + U>
IF
runtime @ clk !
dtfl C++
(CLOCK) (WEATHER)
THEN
AGAIN
;
--- Setup a keypoll to read the time and date into global variables to avoid I2C bus conflicts
pub ?RTC TIME@ time ! DATE@ time 4 + ! ;
---
pub MAIN ' ?RTC +POLL httime ~ ' BIGCLOCK 3 RUN ;
]~
END
?BACKUP
AUTORUN MAIN
Peter or others,
Where is the best info on how Tachyon works?
I will have some time on my flight home so thought I would do a little reading on both forth and tachyon.
I have run Tachyon binary a while ago but I didn't do much with it. So much work has been done on Tachyon that it deserves a closer look!
Comments
So now I've added simple ball physics with a bounce method which basically translates the ball movement control digit (7 is up and left, 3 is down and right etc) into a corresponding bounce direction so that a ball that hits the left wall when it's control digit was 7 will return a new direction of 9 for instance. Very simple and easy to follow, even interact with the game routines and single step etc. Ball physics will be enhanced bit by bit so that anyone who wants to can follow along.
The game code size is only around 1.2k
This is the read-only source code document link btw.
Could you write a forum in Forth and solve all of our problems?
hehe, lol, yeah, but then it wouldn't be a forum, it would be a forthum
Funnily enough, I had already given it some passing thought simply to scope out how I would implement it and what would be required etc. Imagine though a whole bank of Propellers serving up the forum and if you didn't like the way it worked you could specify your own "script", w00t!
Then I think of the 800+ man-hours that have been spent on just porting the forums, that's a lot of Forth-seconds there that if devoted to writing code would certainly result in it being worthy of consideration, it might even max out a Prop or two! Would be even better to run the forum on P2, woot woot!
Next thing to do is to add sound effects wave files. If you telnet into it at tachyonforth.com port 10001 you can check the score with "score C@ ." for instance. Of course once you telnet in you can pretty much do anything that you could do over a serial console.
Because the Propeller is multicore there is no induced lag in the game or networking.
EDIT: there was still room to squeeze in the Game of Life which I can run serially over Telnet while of course Breakout is playing on the VGA monitor.
________________________________
|3 balls TACHYON BREAKOUT 037/128|
| |
| |
|================================|
|==================== ======= ===|
|================= * |
|== ==== ====== |
| |
| |
| |
| |
| |
| |
| |
| -- |
|________________________________|
Hit enter to exit.
Also, every time I ran TEXTBOX on your server, it stopped responding to everything but "bye" and ^C.
I have a Quickstart board with a W5200 board. I should probably be more considerate and crash my own server instead of yours in the future.
Also, every time I ran TEXTBOX on your server, it stopped responding to everything but "bye" and ^C.
I have a Quickstart board with a W5200 board. I should probably be more considerate and crash my own server instead of yours in the future.
Don't worry, that's why it's online, to play with, and crash and burn etc
The textbox function does not return to the console but selects VGA as it's output device. Simply typing CON will return it back. It did kinda crash but I just did a reload by typing "LOADROM BREAKOUT.ROM" which loaded 64k of the EEPROM from file and it was all good again.
Do you want a binary for the QS and W5200?
Also, every time I ran TEXTBOX on your server, it stopped responding to everything but "bye" and ^C.
I have a Quickstart board with a W5200 board. I should probably be more considerate and crash my own server instead of yours in the future.
Don't worry, that's why it's online, to play with, and crash and burn etc
The textbox function does not return to the console but selects VGA as it's output device. Simply typing CON will return it back. It did kinda crash but I just did a reload by typing "LOADROM BREAKOUT.ROM" which loaded 64k of the EEPROM from file and it was all good again.
Do you want a binary for the QS and W5200?
OK, thanks. I was trying to write stuff on the VGA and then look at it with LOOK.
I think I crashed it again. I would love a binary to run on my own system.
in an other thread was the question of how fast to transfer samples of 12 bytes.
So I was curious what sustainable transfer rate I could get with TACHYON
without using a RUNMOD (which can of course be much faster).
{ high speed serial in TACHYON Streaming speed test MJB 2015-07-17 Assumption: Transfer 3 longs from memory as fast as possible We just set the transfer baudrate and write out, then set it back to have the terminal again. } LONG cnt1 LONG cnt2 cnt1 ~ cnt2 ~ pub SPEEDTEST 80000000 3000000 / 3 MBit/s 5 COGREG! 10 FOR CNT@ DUP (EMIT) DUP 8 SHR (EMIT) DUP 8 SHR (EMIT) 8 SHR (EMIT) cnt1 @ DUP (EMIT) DUP 8 SHR (EMIT) DUP 8 SHR (EMIT) 8 SHR (EMIT) cnt1 @ DUP (EMIT) DUP 8 SHR (EMIT) DUP 8 SHR (EMIT) 8 SHR (EMIT) cnt1 ++ NEXT 694 5 COGREG! set back to 115200 BAUD ; LAP SPEEDTEST LAP .LAP { LAP SPEEDTEST LAP .LAP 1.600ms ok for 10 times 12 bytes each 1600 120 / . 13 ok 10000 16 / . 625 ok gives 6.25kHz ( not yet 14.4 kHz) transfer rate of 12 bytes ... } { or as a runmod would be easily much faster }- hope the code tags still workthis means at a raw UART speed of 3MBit/s
I get an actual sustainable transfer rate of only 600kBit/s (which is not bad ;-)
just in high level interpreted TACHYON Forth.
It is also easy to write a little few lines PASM module to be loaded,
that can then go much faster.
Probably Peter knows a few tricks to get even my simple Tachyon code faster ...
:arrowl:
in an other thread was the question of how fast to transfer samples of 12 bytes.
So I was curious what sustainable transfer rate I could get with TACHYON
without using a RUNMOD (which can of course be much faster).
{ high speed serial in TACHYON Streaming speed test MJB 2015-07-17 Assumption: Transfer 3 longs from memory as fast as possible We just set the transfer baudrate and write out, then set it back to have the terminal again. } LONG cnt1 LONG cnt2 cnt1 ~ cnt2 ~ pub SPEEDTEST 80000000 3000000 / 3 MBit/s 5 COGREG! 10 FOR CNT@ DUP (EMIT) DUP 8 SHR (EMIT) DUP 8 SHR (EMIT) 8 SHR (EMIT) cnt1 @ DUP (EMIT) DUP 8 SHR (EMIT) DUP 8 SHR (EMIT) 8 SHR (EMIT) cnt1 @ DUP (EMIT) DUP 8 SHR (EMIT) DUP 8 SHR (EMIT) 8 SHR (EMIT) cnt1 ++ NEXT 694 5 COGREG! set back to 115200 BAUD ; LAP SPEEDTEST LAP .LAP { LAP SPEEDTEST LAP .LAP 1.600ms ok for 10 times 12 bytes each 1600 120 / . 13 ok 10000 16 / . 625 ok gives 6.25kHz ( not yet 14.4 kHz) transfer rate of 12 bytes ... } { or as a runmod would be easily much faster }- hope the code tags still workthis means at a raw UART speed of 3MBit/s
I get an actual sustainable transfer rate of only 600kBit/s (which is not bad ;-)
just in high level interpreted TACHYON Forth.
It is also easy to write a little few lines PASM module to be loaded,
that can then go much faster.
Probably Peter knows a few tricks to get even my simple Tachyon code faster ...
:arrowl:
found some improvement
LONG cnt0 LONG cnt1 LONG cnt2 cnt0 ~ cnt1 ~ cnt2 ~ pub SPEEDTEST 921600 CONBAUD 3000000 CONBAUD 115200 CONBAUD 80000000 3000000 / 3 MBit/s 5 COGREG@ 5 COGREG! 10 FOR CNT@ cnt0 ! cnt0 C@++ (EMIT) C@++ (EMIT) C@++ (EMIT) C@ (EMIT) cnt1 C@++ (EMIT) C@++ (EMIT) C@++ (EMIT) C@ (EMIT) cnt1 @ C@++ (EMIT) C@++ (EMIT) C@++ (EMIT) C@ (EMIT) cnt1 ++ NEXT 694 5 COGREG! set back to 115200 BAUD ; LAP SPEEDTEST LAP .LAP { LAP SPEEDTEST LAP .LAP 931.600us ok for 10 times 12 bytes each 1000000 931 / . 1074 = 10.74kHz @ 12 bytes / sample 1074 12 * 8 * . 103104 -> 1.03 MBit/s transfer rate at baudrate 3 MBaud }[code]
3 LONGS data
pub SPEEDTEST
921600 CONBAUD
3000000 CONBAUD
115200 CONBAUD
80000000 3000000 / 3 MBit/s
5 COGREG@
5 COGREG!
10 FOR
data
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@++ (EMIT)
C@ (EMIT)
NEXT
694 5 COGREG! set back to 115200 BAUD
;
LAP SPEEDTEST LAP .LAP
{
LAP SPEEDTEST LAP .LAP 798.000us ok for 10 times 12 bytes each
1000000 800 / . 1250 = 12.5 kHz @ 12 bytes / sample
1000000 800 / . 1250 ok
1250 12 * 8 * . 120000 = 1.2 MBit/s streaming capacity
without extra PASM - just interpreted TACHYON Forth code
}
1000000 800 / . 1250 = 12.5 kHz @ 12 bytes / sample
1000000 800 / . 1250 ok
1250 12 * 8 * . 120000 = 1.2 MBit/s streaming capacity
without extra PASM - just interpreted TACHYON Forth code
}
Here's one too, I just transfer a block of 1k bytes which takes 6.148ms at 4Mbps. This is about the fastest rate I can transfer at asynchronously but synchronized transmissions can run at much higher rates. The code is simply setting the tx bit-time directly in COGREG 5 and then dumping the 1k block at BUFFERS directly to (EMIT) rather than EMIT which is a higher-level revectorable word that normally defaults to (EMIT). The transfer rate is around 1.3Mbps at 4M baud.
BTW, the transmit routine is not buffered, it is bit-bashed directly from the running cog so it is actually better to run faster rather than slower.
4,000,000 TXBLK 6.148ms ok
1024,000,000 6148 / . 166558 ok
166558 8 * $400A .NUM 1,332,464 okeh Peter -
just raising raw baud rate to beat me I'd consider cheating ;-)
at 4MBaud raw my code gives even a slight improvement over yours ;-)
LAP SPEEDTEST LAP DUP .LAP 701.600us ok for 10 times 12 bytes each
10000000 7016 / . 1425 = 12.5 kHz @ 12 bytes / sample
1425 12 * 8 * . 136800 = 1.368 MBit/s streaming capacity
the enrolled
C@++ (EMIT)
is just a tiny bit faster than the loop even on small block size
so to meet the 14.4 kHz @ 12 bytes / sample requested in the other thread looks like some PASM is needed.
But good to know the limits.
Also, this is only the sending side here. Would the standard receiver just do the 4MBaud ?
BYTE dtfl,pm LONG clk pub (CLOCK) --- service every 500ms runtime @ clk @ 500 + > 0EXIT runtime @ clk ! dtfl C++ --- read time and seperate the hours mins seconds TIME@ 100 U/MOD 100 U/MOD --- adjust the 24 hour time back to 12 hour and display 00 hours as 12 DUP 12 > DUP pm C! IF 12 - THEN DUP 0= IF DROP 12 THEN --- display time in big digits VGA yel HUE BIG 2 4 XY 2 PRINTDEC 16 4 XY 2 PRINTDEC VGA --- print seconds 28 10 XY 2 PRINTDEC --- print AM or PM 28 4 XY pm C@ IF ." PM" ELSE ." AM" THEN --- plot flashing colon 14 6 XY dtfl C@ 1 AND PLOT 14 8 XY dtfl C@ 1 AND PLOT --- date as DAY date, month year red HUE 9 13 XY .DAY SPACE DATE@ 100 U/MOD SWAP 2 PRINTDEC --- month and year ." , " 100 U/MOD SWAP .MONTH SPACE 2000 + 4 PRINTDEC --- draw a frame around it blu HUE 0 0 XY 31 15 BOX CON ; pub CLOCK ' (CLOCK) keypoll W! runtime @ clk ! ;WOW Peter, this has certainly progressed!
Makes a very nice tool/block base for your products.
Hi Peter,
I wrote a very simple and very fast stream parser for extracting data from web sites last year.
Shared it with you on GoogleDocs.
Markus
Hi Peter,
I wrote a very simple and very fast stream parser for extracting data from web sites last year.
Shared it with you on GoogleDocs.
Markus
Good, are you volunteering to do a demo to display the weather information on a VGA monitor, or even a terminal screen?
Hi Peter,
I wrote a very simple and very fast stream parser for extracting data from web sites last year.
Shared it with you on GoogleDocs.
Markus
Good, are you volunteering to do a demo to display the weather information on a VGA monitor, or even a terminal screen?
Since the networking on my Tachyon on Spinneret is broken I can only show how I would parse the file.
Which URL do you want to get what data from?
Since my Tachyon on Spinneret is broken I can only show how I would parse the file.
Which URL do you want to get what data from?
The versions I am doing now are not compiled for any target in particular, they just rely on a simple config that can be applied after loading a binary. I will test that this is so on an actual Spinneret although I might have to massage the older W5100 features a little to fit in with the W5200 and W5500. So the idea is that you specify the pins used by the SD card and WIZnet etc and even specify the type of I2C RTC by name. For instance if I use MCP79410 I just type that in and the RTC routines work automatically but I can just as easily say DS3231 or whatever common ones are predefined. The Seiko RTC used on the Spinneret is a bit of a weird one though, it's not really I2C so I might end up still doing a special binary just for the Spinneret I think
If anyone wants to try it out then here is the binary for it (Updated 150729). The clock runs in it's own cog so you can play with Tachyon all you like while it's running. If you happen to have a DHT22 humidity/temperature sensor then hook it up to a pin and specify the pin used with:
<mypin> ' dhtpin 1+ !
If you want to keep the setting then type BACKUP. All that this does is change a runtime constant and to disable it use -1 as a pin value.
I use I2C RTCs such as the DS3231 or MCP79410 although PCF8583 and the like should work too. You may have to type in MCP79410 if you are using that chip but normally there is no need to type DS3231 etc to set other RTCs.
I want to filter some data (length 10-20)
thanks MJB
I want to filter some data (length 10-20)
thanks MJB
I believe that the best person for this task is a resourceful German who has access to the data to be sorted
If you give it a shot and post what you've got then maybe we can come up with a more refined an elegant solution.
Where is the best info on how Tachyon works?
I will have some time on my flight home so thought I would do a little reading on both forth and tachyon.
I have run Tachyon binary a while ago but I didn't do much with it. So much work has been done on Tachyon that it deserves a closer look!