I thought it might be that Tachyon is so advanced it was a 2415 version
But yes, the (YY)YYMDD_HHMMSS permits sorting and avoids the DDMMYY vs MMDDYY problems.
It's a shame the computer industry didn't push (YY)YYMMDD to become more universal
Anyway Peter, I keep checking here at the advances you are making with Tachyon. Congratulations!
You are well on the way to 200,000 views.
It's a shame the computer industry didn't push (YY)YYMMDD to become more universal
To me it looks more like a business model. Computer industry lives from solving the same problems over and over, only this allows to hire all the skilled software guys and to market, what they learned: how to fight symptoms. ;-)
A problem ones solved from the root will no longer exist and so can not be solved again.
In between projects I've started a V3 Tachyon with a few ideas I've had which also include inline LMM code although I'm not promoting that for general programming, mainly for internal use in the Prop tool compiled kernel. There's some bytecode that could be sped up by going to LMM and there is some cog kernel PASM hogging memory that could be moved out into the hub such as (EMIT), CMPSTR, and !RP etc. The EMIT opcode is a tight bit-bashed operation but if we were to limit the baud-rate to 115.2k for compatibility then it even makes sense to put this into a full-duplex serial cog instead of the high-speed receive only cog. My original rationale for bit-bashing was that is was faster to bash it out at high baud rates then it was to muck about putting it into a buffer and then extracting it again, but at slow (115.2k) baud rates it is better off buffering it.
I even have ideas to pack the dictionary names into a string list so that the "headers" are all fixed length with pointers to the string and include vocabulary masks as well. But the current method works well with the new EEWORDS hybrid dictionary so that might still be hard to beat.
Vectors are here to stay at present as that makes it possible to code the bytecode kernel relatively cleanly and directly (using all those "byte" operations) in the Spin compiler. They are also useful in reducing the length of a call operation but the vector table may be reduced from 2K down to 1K as runtime compilation allows for absolute CALL16 operations.
The end result will be that I can pack more useful opcodes into the kernel cog so that it will be more powerful and run faster overall in conjunction with selective LMM kernel hub code. Some RUNMOD modules which are internal PASM modules of up to 21 longs normally loaded into a fixed cog address to be run as a RUNMOD opcode can now free up that cog area and run as LMM if absolute speed is not an issue.
Coglets will also be implemented in this version, that is PASM objects which are loaded from hub or EEPROM into a cog via a coginit loader. These may be the PASM part of objects from the OBEX that have been adapted slightly to work with Tachyon. Coglets can be loaded by name at runtime, or anytime and include multi-port serial objects as well, just:
" SERIAL4" SERBUFS 2 LOADCOG
will load the SERIAL4 object if found in memory (including EEPROM and SD) into cog 2 with the parameter pointing to SERBUFS and run it.
This would also be a good time to introduce the MATH COG object for floating point (yuck) and transcendental functions (yay) etc.
So, now is the time to make any requests or suggestions as to what you would like to see in V3.
In between projects I've started a V3 Tachyon with a few ideas I've had which also include inline LMM code although I'm not promoting that for general programming, mainly for internal use in the Prop tool compiled kernel. There's some bytecode that could be sped up by going to LMM and there is some cog kernel PASM hogging memory that could be moved out into the hub such as (EMIT), CMPSTR, and !RP etc. The EMIT opcode is a tight bit-bashed operation but if we were to limit the baud-rate to 115.2k for compatibility then it even makes sense to put this into a full-duplex serial cog instead of the high-speed receive only cog. My original rationale for bit-bashing was that is was faster to bash it out at high baud rates then it was to muck about putting it into a buffer and then extracting it again, but at slow (115.2k) baud rates it is better off buffering it.
I even have ideas to pack the dictionary names into a string list so that the "headers" are all fixed length with pointers to the string and include vocabulary masks as well. But the current method works well with the new EEWORDS hybrid dictionary so that might still be hard to beat.
Vectors are here to stay at present as that makes it possible to code the bytecode kernel relatively cleanly and directly (using all those "byte" operations) in the Spin compiler. They are also useful in reducing the length of a call operation but the vector table may be reduced from 2K down to 1K as runtime compilation allows for absolute CALL16 operations.
The end result will be that I can pack more useful opcodes into the kernel cog so that it will be more powerful and run faster overall in conjunction with selective LMM kernel hub code. Some RUNMOD modules which are internal PASM modules of up to 21 longs normally loaded into a fixed cog address to be run as a RUNMOD opcode can now free up that cog area and run as LMM if absolute speed is not an issue.
Coglets will also be implemented in this version, that is PASM objects which are loaded from hub or EEPROM into a cog via a coginit loader. These may be the PASM part of objects from the OBEX that have been adapted slightly to work with Tachyon. Coglets can be loaded by name at runtime, or anytime and include multi-port serial objects as well, just:
" SERIAL4" SERBUFS 2 LOADCOG
will load the SERIAL4 object if found in memory (including EEPROM and SD) into cog 2 with the parameter pointing to SERBUFS and run it.
This would also be a good time to introduce the MATH COG object for floating point (yuck) and transcendental functions (yay) etc.
So, now is the time to make any requests or suggestions as to what you would like to see in V3.
well Peter, this sounds like a new leap again.
Especially the Taychyon-OBEX for COGlets on SD.
Float is not something I really needed so far.
For me, I am still struggling with the random hangs on my Spinneret dynamic webserver.
I suspect the underlying network or W5100 layers, but it is hard to trace down for me.
well Peter, this sounds like a new leap again.
Especially the Taychyon-OBEX for COGlets on SD.
Float is not something I really needed so far.
For me, I am still struggling with the random hangs on my Spinneret dynamic webserver.
I suspect the underlying network or W5100 layers, but it is hard to trace down for me.
1-Wire seems stable.
Float is something I never need, unless I'm emulating a calculator! I've always gotten by quite fine with scaling and integer mul/divs as we always know the range we are dealing with. Besides emulated float on a processor that doesn't have mul/div instructions falls far short of anything real-time.
Now about the Spinneret, I should be able to get those samples of the IoT5500 +P8 modules off to you this week so after you forward some to WIZnet in Germany for the embedded world exhibition, you will still have some for yourself, even though you are in Spain at present! Joachim is especially interesting in the Propeller version rather than just the Ethernet module.
Once you hook them up let's see if you still get random hangs then and if so it should be fairly easy to diagnose. To grok the whole packet process I used to dump a lot of the receive and transmit buffers and socket stats to find out what I was doing wrong, or needed to do different, and of course it's easy to customise special debug words for that in Tachyon.
Nice to see I'm not alone in finding the standard ways of formatting the date ridiculous. Been using yymmdd or yyyymmdd for file naming and other date related needs for many years. Makes finding things so much easier.
Also nice to see the continuous improvements for Tachyon Forth. I will be using the Explorer-5-10-MHz.binary from your “Debug and explore your hardware the easy way!” thread to bring up the hardware for my latest project. If that raises my comfort level enough I will probably use Tachyon Forth instead of Spin/PASM for the software.
Nice to see I'm not alone in finding the standard ways of formatting the date ridiculous. Been using yymmdd or yyyymmdd for file naming and other date related needs for many years. Makes finding things so much easier.
Also nice to see the continuous improvements for Tachyon Forth. I will be using the Explorer-5-10-MHz.binary from your “Debug and explore your hardware the easy way!” thread to bring up the hardware for my latest project. If that raises my comfort level enough I will probably use Tachyon Forth instead of Spin/PASM for the software.
would ge great to have some more active Tachyonistas here :-) to exchange ideas and code snippets.
would ge great to have some more active Tachyonistas here :-) to exchange ideas and code snippets.
I'll be back soon almost full time to tachyon soon, been training my junior sys admin (and everything else) in SAP, gads. In the meantime can you elaborate the "flow, actions" in this code snippet from Peter as I learn how the tachyon "compiler, parser" is working? I could really use an in depth on the word WILL. Thanks up front.
pub SCHEDULE
!SP
schedules entries 4 * ERASE --- clear all the timers - but still in EEPROM for now
DECIMAL
;
pub DONE
DEPTH IF CR ." Schedule has not been backup up due to errors "
ELSE CR ." Backing up settings" BACKUP
THEN
;
pub +SCH ( long --- )
0 #64 1 DO I @SCH @ 0= IF I OR LEAVE THEN LOOP
?DUP IF @SCH ! THEN
;
{
Y DAY[1] --- if set then interpret MMDD as week day mask
M MM[4] 1-12
D DD[5] 1-31
3322222222 2 2111 11111 110000000000
1098765432 1 0987 65432 109876543210
AAAAAAAAAA Y MMMM DDDDD TTTTTTTTTTTT
pub WILL ( time day month <action> -- ) IMMEDIATE
[NFA'] NFA>CFA >VEC XCALLS - 2/ #22 SHL --- form the action code in the high bits of the long
[COMPILE] GRAB ( vec time day month ) --- grab the time day month
?DUP IF ( time date month ) --- process a specific date
#17 SHL SWAP #12 SHL + --- form MMMM DDDDD
ELSE ( vec time day-mask ) --- handle field as a day of week mask
$200 + #12 SHL --- Set day of week bit
THEN
( vec time day ) SWAP #100 U/MOD #60 * + ( vec day minutes )
+ +
+SCH
;
{ Example of a schedule file that can be pasted in via the console - comments allowed
SCHEDULE
08.30 AM DAILY WILL OPEN
11.00 PM DAILY WILL CLOSE
06.00 PM MON WILL CLOSE
06.00 PM FRI WILL CLOSE
07.30 PM SAT WILL CLOSE
06.00 PM SUN WILL CLOSE
01.00 PM 13 OCT WILL CLOSE
01.00 PM 14 OCT WILL CLOSE
DONE
}
I'll be back soon almost full time to tachyon soon, been training my junior sys admin (and everything else) in SAP, gads. In the meantime can you elaborate the "flow, actions" in this code snippet from Peter as I learn how the tachyon "compiler, parser" is working? I could really use an in depth on the word WILL. Thanks up front.
pub SCHEDULE
!SP
schedules entries 4 * ERASE --- clear all the timers - but still in EEPROM for now
DECIMAL
;
pub DONE
DEPTH IF CR ." Schedule has not been backup up due to errors "
ELSE CR ." Backing up settings" BACKUP
THEN
;
pub +SCH ( long --- )
0 #64 1 DO I @SCH @ 0= IF I OR LEAVE THEN LOOP
?DUP IF @SCH ! THEN
;
{
Y DAY[1] --- if set then interpret MMDD as week day mask
M MM[4] 1-12
D DD[5] 1-31
3322222222 2 2111 11111 110000000000
1098765432 1 0987 65432 109876543210
AAAAAAAAAA Y MMMM DDDDD TTTTTTTTTTTT
pub WILL ( time day month <action> -- ) IMMEDIATE
[NFA'] NFA>CFA >VEC XCALLS - 2/ #22 SHL --- form the action code in the high bits of the long
[COMPILE] GRAB ( vec time day month ) --- grab the time day month
?DUP IF ( time date month ) --- process a specific date
#17 SHL SWAP #12 SHL + --- form MMMM DDDDD
ELSE ( vec time day-mask ) --- handle field as a day of week mask
$200 + #12 SHL --- Set day of week bit
THEN
( vec time day ) SWAP #100 U/MOD #60 * + ( vec day minutes )
+ +
+SCH
;
{ Example of a schedule file that can be pasted in via the console - comments allowed
SCHEDULE
08.30 AM DAILY WILL OPEN
11.00 PM DAILY WILL CLOSE
06.00 PM MON WILL CLOSE
06.00 PM FRI WILL CLOSE
07.30 PM SAT WILL CLOSE
06.00 PM SUN WILL CLOSE
01.00 PM 13 OCT WILL CLOSE
01.00 PM 14 OCT WILL CLOSE
DONE
}
WILL gets the 'function pointer' (vector) for the word following it (here OPEN or CLOSE) (this is 10 bits) and shifts it to it's place in the schedule item long, so it can be called on time.
GRAB makes sure the stuff before the WILL gets parsed now, since it is NOT yet.
The rest is just normal shifting to put the date/time stuff into the long.
Once constructed the long is activated (stored to the schedule) by +SCH
that's it
a few nice tricks you can do in Tachyon ;-)
I'll be back soon almost full time to tachyon soon, been training my junior sys admin (and everything else) in SAP, gads. In the meantime can you elaborate the "flow, actions" in this code snippet from Peter as I learn how the tachyon "compiler, parser" is working? I could really use an in depth on the word WILL. Thanks up front.
Tachyon could do with a nice CREATE DOES> to help extend the compiler but due to the bytecode and compile as you type methods it employs this renders the DOES> a little awkward. So the WILL is more of a mangled attempt to extend the compiler by sheer brute force. Prior to encountering the WILL word all the previous parameters have already been compiled in a temporary area at the end of code space. Once WILL is encountered it is not compiled but executes immediately however those parameters aren't on the stack yet as they have not yet been executed. This is where the GRAB (not the best choice of a name) comes in as it forces execution of everything that has been compiled up to that point which will result in the parameters being pushed onto the stack after which it can proceed as normal. In this compiler "mangulation" there are a few things that could do with a little attention and improvement which I hope to address in V3.
BTW, those "10 bits" are essentially 1 of 1,024 possible vectors which point to the code to execute, so this method allows packing into a long rather than trying to encode the full 16-bit absolute address and using more than one long (not as nice).
@Jon (and everyone) - when you have some time remember to throw a few suggestions into the Working with Tachyon Forth document
I've been meaning to get around to testing some SNTP protocol to fetch the current time from an NTP server but seeing how we have been parsing HTML pages it got me to thinking that all I really need is to issue a GET request to a server which will respond with the current time and date in its header response.
So to try this I just telnet to port 80 of google.com for instance and issue a incomplete GET request.
GET /
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.com.au/?gfe_rd=cr&ei=UH_EVO24O63u8wfd74GYAQ
Content-Length: 262 Date: Sun, 25 Jan 2015 05:29:52 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic,p=0.02
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com.au/?gfe_rd=cr&ei=UH_EVO24O63u8wfd74GYAQ">here</A>.
</BODY></HTML>
Connection closed by foreign host.
So there you have it, very easy to parse up to Date: and set the current time either in an on-board RTC or Tachyon's virtual RTC and perhaps check every hour and on power-up to resynch.
Couldn't be simpler and I will build this method into EASYNET to do just that. Does anyone see any problems with this approach?
GET /
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.com.au/?gfe_rd=cr&ei=UH_EVO24O63u8wfd74GYAQ
Content-Length: 262 Date: Sun, 25 Jan 2015 05:29:52 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic,p=0.02
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com.au/?gfe_rd=cr&ei=UH_EVO24O63u8wfd74GYAQ">here</A>.
</BODY></HTML>
Connection closed by foreign host.
So there you have it, very easy to parse up to Date: and set the current time either in an on-board RTC or Tachyon's virtual RTC and perhaps check every hour and on power-up to resynch.
Couldn't be simpler and I will build this method into EASYNET to do just that. Does anyone see any problems with this approach?
great
so this would give us DNS resolution as well?
and the GET to just get any webpage
that we then parse as we like.
As I am in the middle of revamping the EASYFILE module I thought I'd better give you a heads up on this one as besides improvements there has also been a shift in how I will handle the virtual memory that the file system is built on.
VIRTUAL FILE MEMORY
To date the virtual memory access words have served me well but they are limited to 4GB addressing which happens to be the smallest SD card I can now buy. When I have been accessing files whose virtual memory address is greater than 4GB I have chosen to use the sector methods instead although this has really only been for music files. The other problem with the virtual memory addressing methods is that you can just as easily write to system areas of the card as address 0 is the very first byte of the boot block on the card. So to address these concerns I am implementing new file access words which address a "file" as virtual memory so that address 0 is the first byte of the file, previously the first byte of the file was addressed with the starting address of the file in the 4GB virtual memory range. So now the address can only access the contents of the file, not beyond its last cluster as it is clipped, but that file can be anywhere on the card, even beyond the first 4GB.
The basic methods for virtual card memory are as you know XADR XC! XC@ X! etc and so the basic methods for virtual file memory are similar as FADR FC! FC@ F! etc. These words work just like the basic Forth memory operations.
FAT32 CLUSTER
Those of you who have used EASYFILE know that I essentially ignore the file allocation table and work with files as flat contiguous address space from the starting address using just the first cluster. As the card would have files created back on the PC I don't try to create files so I can get away without having to mess with the FAT or following cluster chains which is not at all conducive for flat virtual memory anyway. However there are several good reasons for needing to create files at runtime so I am in the middle of testing that except that when I create a file I do not try to use up any loose clusters but work from the end of the used area so that the new file may grow and remain contiguous which is handy for log files and copy operations etc. For other files it is advantageous to preallocate plenty of clusters at creation time.
DIRECTORIES
EASYFILE has up to this point been limited to accessing files only in the root directory but selecting another directory isn't really all that complicated, just a matter of "opening" the directory as you would a file and using its starting address/sector as the current working directory. So I've added methods for this to permit access from the shell in the same way we would on DOS or Linux systems using the "cd" command. A "cd /" will also reset to the root directory while the "cd .." will of course access the ".." entry as a directory to go back to a higher level directory. The "pwd" will work the same and I may make it an option that the path becomes the prompt as it does in PCs.
RETURN STACK
As a side note the kernel was tweaked last week due to uncovering a very strange bug in one of my applications which I found nested a lot of return addresses, more in fact than I had room for in the cog, which is normally 22 levels deep. The return stack is really only ever used for implicit calls as there is the loop stack which is handy for pushing and popping from the data stack. However the return stack size was previously 22 levels as I've never had any applications touch the bottom until recently, and it wasn't even networked, just filesystem stuff but with many layers. So this has been increased to 26 levels and thoroughly tested to see whether I needed to perhaps expand the return stack into hub RAM. Thankfully I didn't need to as the extra code to do this would have to come out of other cog resources and also impact the speed of call/return.
The code is being updated on the Google pages at present and the Dropbox files will be updated after testing.
(Changing directories)
[font=courier][color=#000080]
[B]ON PROMPT[/B] ok
Tachyon@0000.0000 / $ [B]MOUNT[/B]
Mounted F603.8024-8336.5394 MSWIN4.1 NO NAME FAT32 8,066MB (4,096/cluster) ok
Tachyon@8336.5394 / $ [B]ls[/B]
NO NAME
CE1372 .FTH CE1372 .PDF CHARLCD .JPG IOT5500 .ROM DRAGON .JPG
DRAGON1 .JPG EASYFILE.FTH EASYNET .FTH ECOLCD .PDF EXTEND .FTH
FAVICON .ICO FIRMWARE.ROM FORUM .TXT FRED .PNG FSRPCB .PNG
FSRSCH .PNG HCB4208 .JPG HELP .TXT HOME .HTM HTTP404 .HTM
IMAGE . IMAGE1 . IMAGE2 . IMAGE3 . IOT5500 .JPG
LOGON .HTM LOVE .MP3 MENU .TXT P8X32A .PDF POPCORN .WAV
P8PGM .ROM SDCARD .FTH TEMP .TXT SITE0002.LOG SITE0003.LOG
SITE0004.LOG SITE0005.LOG SITE0006.LOG SITE0007.LOG SITE0008.LOG
SYSLOG .TXT TACHYON .HTM W5200 .FTH WELCOME .FTP WELCOME .TEL
WORDS .DCT WORDS2 .DCT IOT5500 .PDF DS3231~1.FTH P8DEFS .FTH
SDWORDS .FTH W5500 .FTH IOT .SET IOT5500A.PDF MORE . ok
Tachyon@8336.5394 / $ [B]cd MORE[/B] ok
Tachyon@8336.5394 MORE $ [B]ls[/B]
NO NAME
. . .. . FORUM .TXT P1432PCB.PDF P1432SCH.PDF
P1455PCB.PDF P1455SCH.PDF PICTURES. ok
Tachyon@8336.5394 MORE $ [B]cd PICTURES[/B] ok
Tachyon@8336.5394 PICTURES $ [B]ls[/B]
NO NAME
. . .. . PC190168.JPG PC190164.JPG PC190163.JPG
PC190162.JPG PANEL .JPG PC110001.JPG P1070194.JPG PCB . ok
Tachyon@8336.5394 PICTURES $ [B]cd ..[/B] ok
Tachyon@8336.5394 MORE $ [B]ls[/B]
NO NAME
. . .. . FORUM .TXT P1432PCB.PDF P1432SCH.PDF
P1455PCB.PDF P1455SCH.PDF PICTURES. ok
Tachyon@8336.5394 MORE $ [B]cd /[/B] ok
Tachyon@8336.5394 / $ [B]ls[/B]
NO NAME
CE1372 .FTH CE1372 .PDF CHARLCD .JPG IOT5500 .ROM DRAGON .JPG
DRAGON1 .JPG EASYFILE.FTH EASYNET .FTH ECOLCD .PDF EXTEND .FTH
FAVICON .ICO FIRMWARE.ROM FORUM .TXT FRED .PNG FSRPCB .PNG
FSRSCH .PNG HCB4208 .JPG HELP .TXT HOME .HTM HTTP404 .HTM
IMAGE . IMAGE1 . IMAGE2 . IMAGE3 . IOT5500 .JPG
LOGON .HTM LOVE .MP3 MENU .TXT P8X32A .PDF POPCORN .WAV
P8PGM .ROM SDCARD .FTH TEMP .TXT SITE0002.LOG SITE0003.LOG
SITE0004.LOG SITE0005.LOG SITE0006.LOG SITE0007.LOG SITE0008.LOG
SYSLOG .TXT TACHYON .HTM W5200 .FTH WELCOME .FTP WELCOME .TEL
WORDS .DCT WORDS2 .DCT IOT5500 .PDF DS3231~1.FTH P8DEFS .FTH
SDWORDS .FTH W5500 .FTH IOT .SET IOT5500A.PDF MORE . ok
[/color][/font]
RS232.TASK has it's own taskreg "stack" of 76 bytes
?
Classic case of another cog trying to pull a pin low while another cog has it high. In this case the console cog has TXD and the alarm cog tries to use this pin too.
The only real way around is to introduce transmit buffering which is fine for these slow speeds of 115.2K and less while the high baud rates are better off just bashing it out then and there. V3 uses a full-duplex cog so any other cog can talk to the console. Q&D way around this is to have a pullup on the TXD and uncomment the second last line in the pEMIT word in the kernel. Alternatively a KEYPOLL event in the main cog could read a hub variable and emit this too.
BYTE emitter
pub ?EMITTER emitter C@ ?DUP IF EMIT emitter C~ THEN ;
' ?EMITTER keypoll W!
and an emit routine for the timer cog
pub (CONEMIT) BEGIN emitter C@ 0= UNTIL emitter C! ;
pub CONEMIT ' (CONEMIT) emit W! ;
Classic case of another cog trying to pull a pin low while another cog has it high. In this case the console cog has TXD and the alarm cog tries to use this pin too.
The only real way around is to introduce transmit buffering which is fine for these slow speeds of 115.2K and less while the high baud rates are better off just bashing it out then and there. V3 uses a full-duplex cog so any other cog can talk to the console. Q&D way around this is to have a pullup on the TXD and uncomment the second last line in the pEMIT word in the kernel. Alternatively a KEYPOLL event in the main cog could read a hub variable and emit this too.
BYTE emitter
pub ?EMITTER emitter C@ ?DUP IF EMIT emitter C~ THEN ;
' ?EMITTER keypoll W!
and an emit routine for the timer cog
pub (CONEMIT) BEGIN emitter C@ 0= UNTIL emitter C! ;
pub CONEMIT ' (CONEMIT) emit W! ;
That makes complete sense for console output but the code I was building just called a word in the ALARM action that created no console output just an action such as set a flag and I could not get any results?
The syntax is correct then, extend needs its example updated and intro as well, I'll get to that.
Will find the bug then in my other code I guess also or is this a TASKREG issue in my use case?
That makes complete sense for console output but the code I was building just called a word in the ALARM action that created no console output just an action such as set a flag and I could not get any results?
The syntax is correct then, extend needs its example updated and intro as well, I'll get to that.
Will find the bug then in my other code I guess also or is this a TASKREG issue in my use case?
Could you post your code that just "set a flag" for instance?
Oh, just looking at running your code and there might be a bug in my code somewhere perhaps.
[B].TIMERS[/B] ticks = 1/1,000
5150: hwtimer 010,000ms =0000.2710 L3310 ALARM=HWMESSAGE
3310: 000,000ms =0000.0000 L0001 ALARM= ok
[B]TIMER xy[/B] ok
[B]-1 xy TIMEOUT[/B] ok
ok
[B].TIMERS[/B] ticks = 1/1,000
517C: xy 967,295ms =FFFF.FFFF L5150
5150: hwtimer 010,000ms =0000.2710 L3310 ALARM=HWMESSAGE
3310: 000,000ms =0000.0000 L0001 ALARM= ok
Seems it does start to count down, but after a delay, as if it were a CNT wraparound or something.
I see the problem now, the console routine you used still tries to bit-bash and if it is at 115.2k baud then that part of it alone takes 1.833ms yet the alarms need to be functions that execute in less than a millisecond, which is not too hard at all but console output messes that up. So these are simple alarms and WAITCNT is used in the timer loop with the inherited problem of the Prop's WAITCNT instruction where we actually need a WAITCNT that would return immediately if the target has already been reached. Even at 230.4k it would still take more than 0.9ms and the rest of the virtual RTC and timer functions already consume 100us, so that messes the 1ms timing.
I see the problem now, the console routine you used still tries to bit-bash and if it is at 115.2k baud then that part of it alone takes 1.833ms yet the alarms need to be functions that execute in less than a millisecond, which is not too hard at all but console output messes that up. So these are simple alarms and WAITCNT is used in the timer loop with the inherited problem of the Prop's WAITCNT instruction where we actually need a WAITCNT that would return immediately if the target has already been reached. Even at 230.4k it would still take more than 0.9ms and the rest of the virtual RTC and timer functions already consume 100us, so that messes the 1ms timing.
Well this code doesn't work on the quickstart?
Propeller .:.:--TACHYON--:.:. Forth V24150105.2330
VER: Propeller .:.:--TACHYON--:.:. Forth V24150105.2330
FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X)
NAMES: $5866...74B6 for 7,248 bytes (+643)
CODE: $0924...40E2 for 14,270 bytes (+1,577)
CALLS: 326 vectors free
RAM: 6,020 bytes free
BOOTS: 138
BOOT: EXTEND.boot
POLL:
MODULES LOADED:
3AB9: RHTP.fth Rel Humidity Temp Driver V1.3 20150202-1630
3A3B: HONEYHC.fth HoneyWell HC Driver - v1.0.0 150125.0230S
1A00: EXTEND.fth Primary extensions to TACHYON kernel - 150116-1700
BOOT: EXTEND.boot
POLL:
----------------------------------------------------------------
\ ok
ok
TIMER blinktimer ok
ok
WORD blinky ok
: BLINKY
#17 PIN@ 0= #17 PIN! \
blinky W@ blinktimer TIMEOUT \
; ok
\ ok
' BLINKY 0 ALARM ok \ ERROR here need to be blinktimer not 0 new syntax.
\ ok
#100 blinky W! ok
\ ok
#5,000 blinktimer TIMEOUT ok
I have manually toggled pin 17 just to make sure the hardware is gortched.
I have manually toggled pin 17 just to make sure the hardware is gortched.
Never mind see error above.
So you caught that bug then? The original timers were fixed at 8 but later on I changed that to linked timers and that's when I introduced the TIMER construct as well. When TIMEOUT is invoked that's when it checks to see if the timer has been linked in yet and does so if necessary. That way the TIMERTASK will handle as many timers by name as required. There is also a watchdog timer which once started will continue until it reboots unless retriggered of course.
[B]TIMER hwtimer[/B] ok
[B]TIMER polling[/B] ok
[B]TIMER updates[/B] ok
[B].TIMERS[/B] ticks = 1/1,000
3310: 000,000ms =0000.0000 L0001 ALARM=REBOOT ok
[B]-1 hwtimer TIMEOUT[/B] ok
[B]-1 polling TIMEOUT[/B] ok
[B]-1 updates TIMEOUT[/B] ok
[B].TIMERS [/B] ticks = 1/1,000
5160: updates 966,149ms =FFFF.FB83 L5150
5150: polling 958,537ms =FFFF.DDC7 L5140
5140: hwtimer 954,239ms =FFFF.CCFD L3310
3310: 000,000ms =0000.0000 L0001 ALARM=REBOOT ok
Wonder how interactive this Easynet software is? Have a look over my shoulder as I play with the console and network interface in this short and silent 3 minute video.
This one is still running on a 80MHz Prop whereas the +P8 version is 96MHz. However I am just getting around to building a higher speed version by dedicating a cog for SPI so I can run SPI at 24MHz using the counters. At the moment except for the serial receive and background timing all this is done in one cog. Expect it to really fly when I'm done!!!
I've read through #698 of this thread and through about 60% of the Introduction,
Were you aware that your INTRODUCTION has lots of typos in it. I expect them in this tread as it is fluid. But the current INTRODUCTION should be correct shouldn't it?
Symtomatic of what I see is the following:
: REG$ ( index -- addr ) 2 SHL " PAR CNT INA INB OUTAOUTBDIRADIRBCTRACTRBFRQAFRQBPHSAPHSBVCFGVSCL" + ;
: SPRS \ Dump the cog's SPRs with labels
$10 0 DO CR I $1F0 + .WORD ." : "
I REG$ 4 TYPE
." = " I SFR@ .LONG
LOOP
;
SPRS
Finding the error is easy if you know what's going on. But if you're reading the Introduction, you probably don't know what's going on.
Also, I still haven't tripped over a dictionary telling me what your words do. I'm left to writing programs to extract the words from the QWORDS and WORDS words; extracting from the SPIN code; and extracting from the EXTEND.fth code. Surely in two years someone has written a dictionary. Can you point me to it?
===============================
Result of QWORDS with EXTEND.FTH installed
===============================
% $= $! @. <= => >| |< ^ / == ~~ ~ -- ++ \\\ *** --- ... ]~ [~ + - = > @ +! ! * <> (:) : ; \ '' ( { } " ." (.") | || , < . #> <# # ['] ' 0 0= 0<> 0< 0EXIT 1 -1 1+ 1- 16 ^2 2 2/ 2* 2+ 2- 2DROP 2DUP 3 3DROP 3RD 4 4TH 64K? 8 A ABS ackI2C@ ADC@ !ADC #adc ADCBUF .ADDR ADO AGAIN ALARM ALIGN ALLOCATED ALLOT AND ANDN ANSI? ansi ANY any APIN APPEND$ ATN! ATN@ ATN? atr @ATR .ATRS AUTO! AUTORUN .AUTORUN autorun AVAR B >B ?BACKUP BACKUP base baudcnt BCA BCD++ BCOMP BDUMP (BDW) bdw BEGIN BELL BINARY BIT! BL blksz .BLOCK BOLD boot .BOOTS BOUNDS BPIN BRANCH> BREAK BUFFERS BURNROM BUTORUN BYTE .BYTE BYTES B>L B>W C~~ C~ C-- C++ C@ C+! C! C@++ C, CALL +CALL CASE @CE +CHAR >CHAR CLK .CLKFREQ CLKFREQ CLKSET CLOCK @CLOCKPINS CLR CLS CMOVE <CMOVE CMPSTR @CNT CNT CNT@ codes COG@ COG! COGDUMP COGID COGINIT COGINIT COGREG@ COGREG! COGREG COLD COMPARE$ COMPILE [COMPILE] CON] [CON CON CONBAUD CONIO consav CONSOLE CONSTANT COPY$ COS CountDown COUNTUP <CR> CR CREATE$ create (CREATE) CREATE CREATEWORD CTR! CTR@ CTR ctr CTRA CTRB CTRMODE CTYPE CURSOR DAC! .DATE DATE! DATE@ date days DEBUG .DEC DECIMAL .DECX delim DELTA DEPTH >DIGIT digits DIRA DIRB DISCARD DO DOUBLE DPL DROP DS DS+ dst .DT DUMP DUMPA DUMPL DUMPROM DUMPW DUP ?DUP DUTY dwidth E! E@ EC@ EC! ECHO ECOPY EE @EE eeadr eebuf EEPROM EERD @EEWAIT EFILL ELOAD ELSE (EMIT) EMIT EMITS END ENDIF ENDRD ENQ@ ENQ! ERASE$ ERASE ERLINE ERROR errors ERSCN ESAVE ESAVEB ESC[ (ESC) ESC? [ESPIO] EVERIFY EW@ EW! EXECUTE EXIT ?EXIT EXTEND.boot EXTEND.fth FALSE +FIB FILL FINDSTR FIXBIN flags FOR (FORGET) FORGET FREE FRQ FRQA FRQB GETRND GETWORD GRAB HDUMP .HEAD HELP here HERE HEX: +HEX HEX .HEX hexadr hexbuf hexch hexflg HEXLOAD hexptr .HHMM HOLD HOME HYPOT HZ I I2C@ I2C! I2C!? .I2CBUS I2CPINS I2CSTART I2CSTOP IDLE IDUMP IF IFDEF IFNDEF IMMEDIATE IN IN@ INA INB indent .INDEX .INFO INPUTS INVERT IX J JUMP K KEY! KEY@ KEY? KEY .KEYPOLL keypoll KEYPOLL KHZ KOLD>L L> .LAP LAP lastkey LBIT! LEAVE LEFT$ LEMIT LEN$ LIKE lines LISTKEY LITERAL LOADMOD LOCAL locals LOCATE$ LONG .LONG LONGFILL LONGS LOOKUP LOOP +LOOP lpace LSP LSTACK L>W M@ m@ .MAP (MAP) MASK? MASK MASKS MATCH? MATCH matchstr MAX MC@ mc@ MHZ MID$ MIN @MISO MOD MODPINS .MODULES @MOSI ms MUTE MW@ mw@ MY >N .NAME @NAMES names navar NCO -NEGATE ?NEGATE NEGATE NEWCNT NEXT [NFA'] NFA' NFA>CFA NIP NOOP NOP NORMALIZE NOT NOTFOUND NULL$ NULLOUT (NULLOUT) .NUM (.NUM) NUMBER OFF ok OK ON OR ORG org OUT OUT! OUTA OUTB OUTCLR OUTPUTS OUTSET OVER P@ P! @PAD PAR PASM !PCB >PFA PFA>NFA PHSA PHSB .PIN PIN@ PIN! PINCLR PININP PINLOAD? .PINS PINS@ PINSET PLAIN PLL PLLDIV [PLOT] pri PRINT$$ PRINT PRINT" PRINT$ PRIVATE] [PRIVATE PRIVATE prompt pub PUBLIC Published PULSEWIDTH PULSEWIDTHS PWM! [PWM32] [PWM32!] pwmchans PWMCOG.TASK pwmfreq pwmmask pwmpins pwmtbl PWM.START QHYPOT QW QWORDS >R R> RADIX> >RADIX RADIX radix RAM RCFAST RCSLOW READBUF REBOOT RECLAIM (RECLAIM) REG REG RELEASE REPEAT RESET RESTORE .RETSTK REV REVECTOR REVERSE RIGHT$ RND (rnd) ROL ROR ROT /ROUND !RP RUN RUNMOD .RUNTIME runtime .S #S SAR @SCK SCL @SCL SCRUB SDA [SDRD] [SDWR] SE SE97@ SEARCH second seconds (SEP) SERBAUD SERIN SEROUT SET SET? SETPINS SETPWM SETPWMS SETPWMW SHL SHR SHRINP SHROUT SI2C@ SI2C! SI2C!? SIN !SP SP! SPACE SPACES @SPICE @SPICNT @SPIINP SPINNER [SPIO] [SPIOD] @SPIOUT SPIPINS SPIRD SPIRDX @SPISCK SPIWR SPIWRB SPIWRX SPLASH SPR! SPR SPR@ .SPRS SQR SQRT [SSD] STACKS .STACKS .STATS STOP STREND STRING STRIP (STRIP) STROBE .SW SWAP SWAPB SWITCH SWITCH@ SWITCH= SWITCH>< switch TAB TABLE TACHYON TASK? TASK TASKREGS .TASKS tasks TERMINAL THEN tid .TIME TIME! TIME@ time TIMEOUT? TIMEOUT +TIMER TIMER .TIMERS timers timerstk TIMERTASK TO TRUE ttint TYPE U@ U! U> U/ U< U. uboot uemit ufind ukey UM* UNLOOP UNPRIVATE UNSMUDGE UNTIL unum UPPER us U/MOD U.N (VA) VC VCFG VCLS >VEC .VECTORS VECTORS VER .VER VirtualRTC VOLTS@ VP VSCL W~~ W~ W-- W++ >W W@ W+! W! WAITCNT (WAITHILO) WAITKEY WAITPEQ (WAITPEQ) WAITPNE (WAITPNE) WATCHDOG wcnt wdt WHILE WITHIN WKEY WORD .WORD word (WORDS) WORDS WORDS: WRITEHEX WWORDS W>B W>L @X X1 X2 X3 X4 XCALLS XOR XY
Looks like I've got lots of work ahead of me (1100 thread conversations yet to read; 150 SPIN defined words to decipher and catalog; 721 QWORDs listed words to decipher and catalog).
If anyone has cheatsheets, they're welcome. It's obvious to me this journey is worth the effort and I thank you Peter for your phenomenal contribution.
I've read through #698 of this thread and through about 60% of the Introduction,
Were you aware that your INTRODUCTION has lots of typos in it. I expect them in this tread as it is fluid. But the current INTRODUCTION should be correct shouldn't it?
<snip>
Finding the error is easy if you know what's going on. But if you're reading the Introduction, you probably don't know what's going on.
Also, I still haven't tripped over a dictionary telling me what your words do. I'm left to writing programs to extract the words from the QWORDS and WORDS words; extracting from the SPIN code; and extracting from the EXTEND.fth code. Surely in two years someone has written a dictionary. Can you point me to it?
<snip>
Looks like I've got lots of work ahead of me (1100 thread conversations yet to read; 150 SPIN defined words to decipher and catalog; 721 QWORDs listed words to decipher and catalog).
If anyone has cheatsheets, they're welcome. It's obvious to me this journey is worth the effort and I thank you Peter for your phenomenal contribution.
If I was retired or if Tachyon was a paying job I might have a bit more time to enhance all this but Tachyon is more of a means to an end, but a means I try to improve and share. This is where I need help and partly for that reason is why the documents are in the cloud so that they can be edited and commented on etc.
BTW, the precompiled "Spin" kernel only has a few lines of Spin to launch the cogs and besides the PASM kernel the rest is bytecode constructed with "byte" directives. A PASM macroassembler is what is really needed to write the kernel in an neat and efficient manner but we use the Spin compiler instead to assemble PASM and bytecode.
Rather than a static glossary document that needs maintenance I have been adding help in the form of {HELP <comments> } to the source code which if loaded onto a Prop with a filesystem (SD card) can interactively invoke various levels of help for that word. For instance typing COGREG@ and hitting ^? (ctrl+?) will display the stack comment directly after it in a non-intrusive manner. Use HELP COGREG@ for more information and usage or use SEE COGREG@ to view the comments and source code. At present the help comments are still being added to the sources and when I have half a day to spare I will implement the rest of the help system. However the help comments are available when browsing the source online.
The "SPR@" error in the introduction is of course not a typo, it was correct at the time it was written. The problem is that Tachyon has evolved and the use of the SPR@ word has been deprecated, that's all. I don't think though that you need to read through all the forum posts, a google search should help to locate those of a particular interest.
The bulk of the words used are standard Forth, and Tachyon is really only different for the same reason that Spin is different, because the Propeller is different. The Propeller also has it's own limitations such as 496 long PASM kernel including kernel registers, 32K total to load the cog images and the Forth bytecode and dictionary. Some opcodes like OUTSET for instance "set out" to convey the notion that the OUT register can be SET with a mask, all 32 bits, not just a single bit.
But there are a lot of things about Tachyon that people don't like:
- It's not ANS
- It uses UPPERCASE
- It's not C
The first one is funny because I never saw ANS as being formulated or applied to embedded systems and besides this standard overly complicated what was essentially a KISS language.
I've had at least one bad reaction to my use of uppercase as if there are 26 characters that are not to be used. Well I like to be able to glance at source and see a difference between variables, modifiers, and actions and comments (which can be in between on the same line). When I see VALVE I know that it takes action whereas if I read "valve" elsewhere then it is more than likely a variable. Besides the first book on Forth that I read "Starting Forth" used uppercase for Forth words. Lastly of course it's not C, how could you actually load a C compiler itself onto a Prop and interact and compile programs with it?
If you can get over any "dislikes" then there are a lot of things to like that far outweigh that and from which you can start having fun.
Again. Thanks for your contribution. When I wrote my GLEE language (WithGLEE.com), I didn't do it openly because I didn't want the inertia and the peanut gallery. I basked in the ability to make dozens of important decisions daily by myself ... make them wrong ... and adopt better alternatives all without outside intervention.
I knew up front, since it was a new language with a fluid definition, I would need to document and test as I went along. So I wrote the web pages at the same time I wrote the test and example cases. I then wrote a program that extracted all the examples from the pages, ran them, and flagged results that changed from the previous run. Thus I was able to guarantee that the documentation was correct for the current version of the language. That regression suit was a very valuable tool.
On your last 3 points:
ANS: Like SmallTalk, Forth is a user extended language. Documentation and standardization will always be a problem with it
UPPERCASE: GLEE retains case as delivered by the programmer ... but it is case in-sensitive. It is also whitespace insensitive (I reject languages like Python because they are not ... oops, SPIN is not either). It also has three ways of getting around the need for escape characters for dealing with control and other special characters. Finally, it is totally "symbol oriented". There are very very few natural language oriented symbols and there are no reserved words.
Not C: GLEE is written in C++ and GLEE itself. I like C++ for writing languages like GLEE. But I generally don't like it for writing application programs. With a good debugger it's tolerable for programming things like PIC chips. Without a good debugger I'll take Forth of whatever dialect any day.
I envy Forth's ability in general, and Tachyon's ability in particular, to get down to the metal. I need to add such a surface layer to GLEE but don't think it would be possible to leverage the hardware like you have with Forth. It would require an ancillary connection like a debugger.
Regarding the dictionary: I personally need such a cheat sheet. I will work to develop a program in GLEE which creates such a cheat sheet from your source code and them supplements it where appropriate with ancillary text. The listing I made from the SPIN code did this (the byte code numbers ... or at least the order the words are added ... are in the brackets [ ].) But it is then sorted alphabetically giving weight only to letters and numbers and not case and symbols.
Regarding reading the thread: So far, most of what I know about Tachyon I've learned from reading source code and your answers and examples in the threads. Unfortunately, I'm learning a moving target. But as I've said, the value of the work you have done is enormous ... especially for a chip like the Propeller that has no debugging features,
Comments
But yes, the (YY)YYMDD_HHMMSS permits sorting and avoids the DDMMYY vs MMDDYY problems.
It's a shame the computer industry didn't push (YY)YYMMDD to become more universal
Anyway Peter, I keep checking here at the advances you are making with Tachyon. Congratulations!
You are well on the way to 200,000 views.
A problem ones solved from the root will no longer exist and so can not be solved again.
I even have ideas to pack the dictionary names into a string list so that the "headers" are all fixed length with pointers to the string and include vocabulary masks as well. But the current method works well with the new EEWORDS hybrid dictionary so that might still be hard to beat.
Vectors are here to stay at present as that makes it possible to code the bytecode kernel relatively cleanly and directly (using all those "byte" operations) in the Spin compiler. They are also useful in reducing the length of a call operation but the vector table may be reduced from 2K down to 1K as runtime compilation allows for absolute CALL16 operations.
The end result will be that I can pack more useful opcodes into the kernel cog so that it will be more powerful and run faster overall in conjunction with selective LMM kernel hub code. Some RUNMOD modules which are internal PASM modules of up to 21 longs normally loaded into a fixed cog address to be run as a RUNMOD opcode can now free up that cog area and run as LMM if absolute speed is not an issue.
Coglets will also be implemented in this version, that is PASM objects which are loaded from hub or EEPROM into a cog via a coginit loader. These may be the PASM part of objects from the OBEX that have been adapted slightly to work with Tachyon. Coglets can be loaded by name at runtime, or anytime and include multi-port serial objects as well, just:
" SERIAL4" SERBUFS 2 LOADCOG
will load the SERIAL4 object if found in memory (including EEPROM and SD) into cog 2 with the parameter pointing to SERBUFS and run it.
This would also be a good time to introduce the MATH COG object for floating point (yuck) and transcendental functions (yay) etc.
So, now is the time to make any requests or suggestions as to what you would like to see in V3.
well Peter, this sounds like a new leap again.
Especially the Taychyon-OBEX for COGlets on SD.
Float is not something I really needed so far.
For me, I am still struggling with the random hangs on my Spinneret dynamic webserver.
I suspect the underlying network or W5100 layers, but it is hard to trace down for me.
1-Wire seems stable.
Float is something I never need, unless I'm emulating a calculator! I've always gotten by quite fine with scaling and integer mul/divs as we always know the range we are dealing with. Besides emulated float on a processor that doesn't have mul/div instructions falls far short of anything real-time.
Now about the Spinneret, I should be able to get those samples of the IoT5500 +P8 modules off to you this week so after you forward some to WIZnet in Germany for the embedded world exhibition, you will still have some for yourself, even though you are in Spain at present! Joachim is especially interesting in the Propeller version rather than just the Ethernet module.
Once you hook them up let's see if you still get random hangs then and if so it should be fairly easy to diagnose. To grok the whole packet process I used to dump a lot of the receive and transmit buffers and socket stats to find out what I was doing wrong, or needed to do different, and of course it's easy to customise special debug words for that in Tachyon.
Also nice to see the continuous improvements for Tachyon Forth. I will be using the Explorer-5-10-MHz.binary from your “Debug and explore your hardware the easy way!” thread to bring up the hardware for my latest project. If that raises my comfort level enough I will probably use Tachyon Forth instead of Spin/PASM for the software.
Coglets are a very nice and welcome addition.
No extra wishes... your work is great and the fact you are sharing it is the best feature.
Massimo
1-Wire code for Tachyon
http://forums.parallax.com/showthread.php/159692-Debug-and-explore-your-hardware-the-easy-way!?p=1311827&viewfull=1#post1311827
here on my PropBOE it works fine, should you encounter any irregularities, please let me know.
Markus
I'll be back soon almost full time to tachyon soon, been training my junior sys admin (and everything else) in SAP, gads. In the meantime can you elaborate the "flow, actions" in this code snippet from Peter as I learn how the tachyon "compiler, parser" is working? I could really use an in depth on the word WILL. Thanks up front.
pub SCHEDULE !SP schedules entries 4 * ERASE --- clear all the timers - but still in EEPROM for now DECIMAL ; pub DONE DEPTH IF CR ." Schedule has not been backup up due to errors " ELSE CR ." Backing up settings" BACKUP THEN ; pub +SCH ( long --- ) 0 #64 1 DO I @SCH @ 0= IF I OR LEAVE THEN LOOP ?DUP IF @SCH ! THEN ; { Y DAY[1] --- if set then interpret MMDD as week day mask M MM[4] 1-12 D DD[5] 1-31 3322222222 2 2111 11111 110000000000 1098765432 1 0987 65432 109876543210 AAAAAAAAAA Y MMMM DDDDD TTTTTTTTTTTT pub WILL ( time day month <action> -- ) IMMEDIATE [NFA'] NFA>CFA >VEC XCALLS - 2/ #22 SHL --- form the action code in the high bits of the long [COMPILE] GRAB ( vec time day month ) --- grab the time day month ?DUP IF ( time date month ) --- process a specific date #17 SHL SWAP #12 SHL + --- form MMMM DDDDD ELSE ( vec time day-mask ) --- handle field as a day of week mask $200 + #12 SHL --- Set day of week bit THEN ( vec time day ) SWAP #100 U/MOD #60 * + ( vec day minutes ) + + +SCH ; { Example of a schedule file that can be pasted in via the console - comments allowed SCHEDULE 08.30 AM DAILY WILL OPEN 11.00 PM DAILY WILL CLOSE 06.00 PM MON WILL CLOSE 06.00 PM FRI WILL CLOSE 07.30 PM SAT WILL CLOSE 06.00 PM SUN WILL CLOSE 01.00 PM 13 OCT WILL CLOSE 01.00 PM 14 OCT WILL CLOSE DONE }GRAB makes sure the stuff before the WILL gets parsed now, since it is NOT yet.
The rest is just normal shifting to put the date/time stuff into the long.
Once constructed the long is activated (stored to the schedule) by +SCH
that's it
a few nice tricks you can do in Tachyon ;-)
Tachyon could do with a nice CREATE DOES> to help extend the compiler but due to the bytecode and compile as you type methods it employs this renders the DOES> a little awkward. So the WILL is more of a mangled attempt to extend the compiler by sheer brute force. Prior to encountering the WILL word all the previous parameters have already been compiled in a temporary area at the end of code space. Once WILL is encountered it is not compiled but executes immediately however those parameters aren't on the stack yet as they have not yet been executed. This is where the GRAB (not the best choice of a name) comes in as it forces execution of everything that has been compiled up to that point which will result in the parameters being pushed onto the stack after which it can proceed as normal. In this compiler "mangulation" there are a few things that could do with a little attention and improvement which I hope to address in V3.
BTW, those "10 bits" are essentially 1 of 1,024 possible vectors which point to the code to execute, so this method allows packing into a long rather than trying to encode the full 16-bit absolute address and using more than one long (not as nice).
@Jon (and everyone) - when you have some time remember to throw a few suggestions into the Working with Tachyon Forth document
So to try this I just telnet to port 80 of google.com for instance and issue a incomplete GET request.
GET /
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.com.au/?gfe_rd=cr&ei=UH_EVO24O63u8wfd74GYAQ
Content-Length: 262
Date: Sun, 25 Jan 2015 05:29:52 GMT
Server: GFE/2.0
Alternate-Protocol: 80:quic,p=0.02
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com.au/?gfe_rd=cr&ei=UH_EVO24O63u8wfd74GYAQ">here</A>.
</BODY></HTML>
Connection closed by foreign host.
So there you have it, very easy to parse up to Date: and set the current time either in an on-board RTC or Tachyon's virtual RTC and perhaps check every hour and on power-up to resynch.
Couldn't be simpler and I will build this method into EASYNET to do just that. Does anyone see any problems with this approach?
so this would give us DNS resolution as well?
and the GET to just get any webpage
that we then parse as we like.
Looking forward to see the WORDs used to parse this from IO, should be usable for many outward facing data gathering opportunities!
VIRTUAL FILE MEMORY
To date the virtual memory access words have served me well but they are limited to 4GB addressing which happens to be the smallest SD card I can now buy. When I have been accessing files whose virtual memory address is greater than 4GB I have chosen to use the sector methods instead although this has really only been for music files. The other problem with the virtual memory addressing methods is that you can just as easily write to system areas of the card as address 0 is the very first byte of the boot block on the card. So to address these concerns I am implementing new file access words which address a "file" as virtual memory so that address 0 is the first byte of the file, previously the first byte of the file was addressed with the starting address of the file in the 4GB virtual memory range. So now the address can only access the contents of the file, not beyond its last cluster as it is clipped, but that file can be anywhere on the card, even beyond the first 4GB.
The basic methods for virtual card memory are as you know XADR XC! XC@ X! etc and so the basic methods for virtual file memory are similar as FADR FC! FC@ F! etc. These words work just like the basic Forth memory operations.
FAT32 CLUSTER
Those of you who have used EASYFILE know that I essentially ignore the file allocation table and work with files as flat contiguous address space from the starting address using just the first cluster. As the card would have files created back on the PC I don't try to create files so I can get away without having to mess with the FAT or following cluster chains which is not at all conducive for flat virtual memory anyway. However there are several good reasons for needing to create files at runtime so I am in the middle of testing that except that when I create a file I do not try to use up any loose clusters but work from the end of the used area so that the new file may grow and remain contiguous which is handy for log files and copy operations etc. For other files it is advantageous to preallocate plenty of clusters at creation time.
DIRECTORIES
EASYFILE has up to this point been limited to accessing files only in the root directory but selecting another directory isn't really all that complicated, just a matter of "opening" the directory as you would a file and using its starting address/sector as the current working directory. So I've added methods for this to permit access from the shell in the same way we would on DOS or Linux systems using the "cd" command. A "cd /" will also reset to the root directory while the "cd .." will of course access the ".." entry as a directory to go back to a higher level directory. The "pwd" will work the same and I may make it an option that the path becomes the prompt as it does in PCs.
RETURN STACK
As a side note the kernel was tweaked last week due to uncovering a very strange bug in one of my applications which I found nested a lot of return addresses, more in fact than I had room for in the cog, which is normally 22 levels deep. The return stack is really only ever used for implicit calls as there is the loop stack which is handy for pushing and popping from the data stack. However the return stack size was previously 22 levels as I've never had any applications touch the bottom until recently, and it wasn't even networked, just filesystem stuff but with many layers. So this has been increased to 26 levels and thoroughly tested to see whether I needed to perhaps expand the return stack into hub RAM. Thankfully I didn't need to as the extra code to do this would have to come out of other cog resources and also impact the speed of call/return.
The code is being updated on the Google pages at present and the Dropbox files will be updated after testing.
(Changing directories)
Seems so, but I don't get any output from the test below.
RS232.TASK has it's own taskreg "stack" of 76 bytes
?
Classic case of another cog trying to pull a pin low while another cog has it high. In this case the console cog has TXD and the alarm cog tries to use this pin too.
The only real way around is to introduce transmit buffering which is fine for these slow speeds of 115.2K and less while the high baud rates are better off just bashing it out then and there. V3 uses a full-duplex cog so any other cog can talk to the console. Q&D way around this is to have a pullup on the TXD and uncomment the second last line in the pEMIT word in the kernel. Alternatively a KEYPOLL event in the main cog could read a hub variable and emit this too.
BYTE emitter
pub ?EMITTER emitter C@ ?DUP IF EMIT emitter C~ THEN ;
' ?EMITTER keypoll W!
and an emit routine for the timer cog
pub (CONEMIT) BEGIN emitter C@ 0= UNTIL emitter C! ;
pub CONEMIT ' (CONEMIT) emit W! ;
That makes complete sense for console output but the code I was building just called a word in the ALARM action that created no console output just an action such as set a flag and I could not get any results?
The syntax is correct then, extend needs its example updated and intro as well, I'll get to that.
Will find the bug then in my other code I guess also or is this a TASKREG issue in my use case?
Could you post your code that just "set a flag" for instance?
Oh, just looking at running your code and there might be a bug in my code somewhere perhaps.
Seems it does start to count down, but after a delay, as if it were a CNT wraparound or something.
Well this code doesn't work on the quickstart?
Propeller .:.:--TACHYON--:.:. Forth V24150105.2330 VER: Propeller .:.:--TACHYON--:.:. Forth V24150105.2330 FREQ: 80MHZ (PLLEN OSCEN XTAL1 PLL16X) NAMES: $5866...74B6 for 7,248 bytes (+643) CODE: $0924...40E2 for 14,270 bytes (+1,577) CALLS: 326 vectors free RAM: 6,020 bytes free BOOTS: 138 BOOT: EXTEND.boot POLL: MODULES LOADED: 3AB9: RHTP.fth Rel Humidity Temp Driver V1.3 20150202-1630 3A3B: HONEYHC.fth HoneyWell HC Driver - v1.0.0 150125.0230S 1A00: EXTEND.fth Primary extensions to TACHYON kernel - 150116-1700 BOOT: EXTEND.boot POLL: ---------------------------------------------------------------- \ ok ok TIMER blinktimer ok ok WORD blinky ok : BLINKY #17 PIN@ 0= #17 PIN! \ blinky W@ blinktimer TIMEOUT \ ; ok \ ok ' BLINKY 0 ALARM ok \ ERROR here need to be blinktimer not 0 new syntax. \ ok #100 blinky W! ok \ ok #5,000 blinktimer TIMEOUT okI have manually toggled pin 17 just to make sure the hardware is gortched.
Never mind see error above.
So you caught that bug then? The original timers were fixed at 8 but later on I changed that to linked timers and that's when I introduced the TIMER construct as well. When TIMEOUT is invoked that's when it checks to see if the timer has been linked in yet and does so if necessary. That way the TIMERTASK will handle as many timers by name as required. There is also a watchdog timer which once started will continue until it reboots unless retriggered of course.
with the command all pins are checked for a pullup,
and if present the pin is scanned for 1-Wire devices.
The list of found device IDs is printed.
have fun
Markus
[video=youtube_share;jFHpfAei9yk]
This one is still running on a 80MHz Prop whereas the +P8 version is 96MHz. However I am just getting around to building a higher speed version by dedicating a cog for SPI so I can run SPI at 24MHz using the counters. At the moment except for the serial receive and background timing all this is done in one cog. Expect it to really fly when I'm done!!!
[video=youtube_share;jFHpfAei9yk]
I've read through #698 of this thread and through about 60% of the Introduction,
Were you aware that your INTRODUCTION has lots of typos in it. I expect them in this tread as it is fluid. But the current INTRODUCTION should be correct shouldn't it?
Symtomatic of what I see is the following:
: REG$ ( index -- addr ) 2 SHL " PAR CNT INA INB OUTAOUTBDIRADIRBCTRACTRBFRQAFRQBPHSAPHSBVCFGVSCL" + ;
: SPRS \ Dump the cog's SPRs with labels
$10 0 DO CR I $1F0 + .WORD ." : "
I REG$ 4 TYPE
." = " I SFR@ .LONG
LOOP
;
SPRS
Finding the error is easy if you know what's going on. But if you're reading the Introduction, you probably don't know what's going on.
Also, I still haven't tripped over a dictionary telling me what your words do. I'm left to writing programs to extract the words from the QWORDS and WORDS words; extracting from the SPIN code; and extracting from the EXTEND.fth code. Surely in two years someone has written a dictionary. Can you point me to it?
So far I have the following:
=============================
Words from SPIN code:
=============================
[127]AddACALL; [115]ALLOCATED; [114]ALLOT; [117]ATATR; [59]ATICK; [116]ATO; [78]ATPAD; [134]AUTORUN; [136]AUTOST; [37]BCA; [93]BCOMP; [94]BCOMPILE; [42]BELL; [46]BIN; [12]BRACE; [138]BUFFERS; [96]CCOMP; [39]CLS; [24]COGDUMP; [149]COGINIT; [139]COLDST; [118]COLON; [11]COMMENT; [95]COMPILE; [123]COMPILES; [74]CONSOLE; [43]CR; [124]CREATE; [126]CREATESTR; [125]CREATEWORD; [13]CURLY; [56]doCHAR; [22]DEBUG; [47]DECIMAL; [148]DEPTH; [133]DISCARD; [23]DUMP; [40]EMIT; [122]ENDCOLON; [8]ERASE; [131]ERROR; [29]ESPIO; [68]EXECUTE; [7]FILL; [67]FINDSTR; [137]FIXDICT; [135]FREE; [69]GETVER; [57]GETWORD; [76]GRAB; [83]HASH; [84]HASHS; [128]HERE; [48]HEX; [79]HOLD; [113]IDLE; [15]IFDEF; [65]IFEXIT; [14]IFNDEF; [146]InitStack; [143]IS; [144]ISEND; [142]ISEQ; [145]ISWITHIN; [51]KEY; [49]KEYQ; [150]LAST; [98]LCOMP; [82]LHASH; [92]LITCOMP; [27]LOADMOD; [3]LT; [9]ms; [109]MARK; [129]NFACFA; [60]NFATICK; [132]NOTFOUND; [72]NUMBER; [44]OK; [63]PFA; [36]PLOT; [121]PRIVATE; [90]PRT; [17]PRTBYTE; [91]PRTDEC; [16]PRTHEX; [19]PRTLONG; [20]PRTSTK; [21]PRTSTKS; [87]PRTSTR; [70]PRTVER; [18]PRTWORD; [86]PSTR; [120]PUBCOLON; [53]PUTCHAR; [54]PUTCHARPL; [34]PWM32; [35]PWMST32; [52]QEMIT; [38]RCMOVE; [50]READBUF; [25]REBOOT; [77]RESFWD; [81]RHASH; [55]SCRUB; [32]SDRD; [33]SDWR; [66]SEARCH; [64]SETPOLL; [2]SETQ; [41]SPACE; [45]SPINNER; [30]SPIO; [31]SPIOD; [147]SPSTORE; [28]SSD; [99]STACKS; [26]STOP; [88]STRLEN; [140]SWITCH; [141]SWITCHFETCH; [112]TASK; [73]TERMINAL; [58]TICK; [80]TOCHAR; [71]TODIGIT; [62]TOVEC; [10]us; [5]ULT; [110]UNMARK; [89]UPRT; [111]VECTORS; [97]WCOMP; [6]WITHIN; [1]XCALLS; [4]ZLT; [107]_AGAIN_; [105]_BEGIN_; [119]_COLON; [103]_ELSE_; [102]_IF_; [61]_NFATICK; [75]_NUMBER; [101]_PSTR_; [108]_REPEAT_; [85]_STR; [100]_STR_; [130]_TACHYON; [104]_THEN_; [106]_UNTIL_;
===============================
Result of QWORDS with EXTEND.FTH installed
===============================
% $= $! @. <= => >| |< ^ / == ~~ ~ -- ++ \\\ *** --- ... ]~ [~ + - = > @ +! ! * <> (:) : ; \ '' ( { } " ." (.") | || , < . #> <# # ['] ' 0 0= 0<> 0< 0EXIT 1 -1 1+ 1- 16 ^2 2 2/ 2* 2+ 2- 2DROP 2DUP 3 3DROP 3RD 4 4TH 64K? 8 A ABS ackI2C@ ADC@ !ADC #adc ADCBUF .ADDR ADO AGAIN ALARM ALIGN ALLOCATED ALLOT AND ANDN ANSI? ansi ANY any APIN APPEND$ ATN! ATN@ ATN? atr @ATR .ATRS AUTO! AUTORUN .AUTORUN autorun AVAR B >B ?BACKUP BACKUP base baudcnt BCA BCD++ BCOMP BDUMP (BDW) bdw BEGIN BELL BINARY BIT! BL blksz .BLOCK BOLD boot .BOOTS BOUNDS BPIN BRANCH> BREAK BUFFERS BURNROM BUTORUN BYTE .BYTE BYTES B>L B>W C~~ C~ C-- C++ C@ C+! C! C@++ C, CALL +CALL CASE @CE +CHAR >CHAR CLK .CLKFREQ CLKFREQ CLKSET CLOCK @CLOCKPINS CLR CLS CMOVE <CMOVE CMPSTR @CNT CNT CNT@ codes COG@ COG! COGDUMP COGID COGINIT COGINIT COGREG@ COGREG! COGREG COLD COMPARE$ COMPILE [COMPILE] CON] [CON CON CONBAUD CONIO consav CONSOLE CONSTANT COPY$ COS CountDown COUNTUP <CR> CR CREATE$ create (CREATE) CREATE CREATEWORD CTR! CTR@ CTR ctr CTRA CTRB CTRMODE CTYPE CURSOR DAC! .DATE DATE! DATE@ date days DEBUG .DEC DECIMAL .DECX delim DELTA DEPTH >DIGIT digits DIRA DIRB DISCARD DO DOUBLE DPL DROP DS DS+ dst .DT DUMP DUMPA DUMPL DUMPROM DUMPW DUP ?DUP DUTY dwidth E! E@ EC@ EC! ECHO ECOPY EE @EE eeadr eebuf EEPROM EERD @EEWAIT EFILL ELOAD ELSE (EMIT) EMIT EMITS END ENDIF ENDRD ENQ@ ENQ! ERASE$ ERASE ERLINE ERROR errors ERSCN ESAVE ESAVEB ESC[ (ESC) ESC? [ESPIO] EVERIFY EW@ EW! EXECUTE EXIT ?EXIT EXTEND.boot EXTEND.fth FALSE +FIB FILL FINDSTR FIXBIN flags FOR (FORGET) FORGET FREE FRQ FRQA FRQB GETRND GETWORD GRAB HDUMP .HEAD HELP here HERE HEX: +HEX HEX .HEX hexadr hexbuf hexch hexflg HEXLOAD hexptr .HHMM HOLD HOME HYPOT HZ I I2C@ I2C! I2C!? .I2CBUS I2CPINS I2CSTART I2CSTOP IDLE IDUMP IF IFDEF IFNDEF IMMEDIATE IN IN@ INA INB indent .INDEX .INFO INPUTS INVERT IX J JUMP K KEY! KEY@ KEY? KEY .KEYPOLL keypoll KEYPOLL KHZ KOLD>L L> .LAP LAP lastkey LBIT! LEAVE LEFT$ LEMIT LEN$ LIKE lines LISTKEY LITERAL LOADMOD LOCAL locals LOCATE$ LONG .LONG LONGFILL LONGS LOOKUP LOOP +LOOP lpace LSP LSTACK L>W M@ m@ .MAP (MAP) MASK? MASK MASKS MATCH? MATCH matchstr MAX MC@ mc@ MHZ MID$ MIN @MISO MOD MODPINS .MODULES @MOSI ms MUTE MW@ mw@ MY >N .NAME @NAMES names navar NCO -NEGATE ?NEGATE NEGATE NEWCNT NEXT [NFA'] NFA' NFA>CFA NIP NOOP NOP NORMALIZE NOT NOTFOUND NULL$ NULLOUT (NULLOUT) .NUM (.NUM) NUMBER OFF ok OK ON OR ORG org OUT OUT! OUTA OUTB OUTCLR OUTPUTS OUTSET OVER P@ P! @PAD PAR PASM !PCB >PFA PFA>NFA PHSA PHSB .PIN PIN@ PIN! PINCLR PININP PINLOAD? .PINS PINS@ PINSET PLAIN PLL PLLDIV [PLOT] pri PRINT$$ PRINT PRINT" PRINT$ PRIVATE] [PRIVATE PRIVATE prompt pub PUBLIC Published PULSEWIDTH PULSEWIDTHS PWM! [PWM32] [PWM32!] pwmchans PWMCOG.TASK pwmfreq pwmmask pwmpins pwmtbl PWM.START QHYPOT QW QWORDS >R R> RADIX> >RADIX RADIX radix RAM RCFAST RCSLOW READBUF REBOOT RECLAIM (RECLAIM) REG REG RELEASE REPEAT RESET RESTORE .RETSTK REV REVECTOR REVERSE RIGHT$ RND (rnd) ROL ROR ROT /ROUND !RP RUN RUNMOD .RUNTIME runtime .S #S SAR @SCK SCL @SCL SCRUB SDA [SDRD] [SDWR] SE SE97@ SEARCH second seconds (SEP) SERBAUD SERIN SEROUT SET SET? SETPINS SETPWM SETPWMS SETPWMW SHL SHR SHRINP SHROUT SI2C@ SI2C! SI2C!? SIN !SP SP! SPACE SPACES @SPICE @SPICNT @SPIINP SPINNER [SPIO] [SPIOD] @SPIOUT SPIPINS SPIRD SPIRDX @SPISCK SPIWR SPIWRB SPIWRX SPLASH SPR! SPR SPR@ .SPRS SQR SQRT [SSD] STACKS .STACKS .STATS STOP STREND STRING STRIP (STRIP) STROBE .SW SWAP SWAPB SWITCH SWITCH@ SWITCH= SWITCH>< switch TAB TABLE TACHYON TASK? TASK TASKREGS .TASKS tasks TERMINAL THEN tid .TIME TIME! TIME@ time TIMEOUT? TIMEOUT +TIMER TIMER .TIMERS timers timerstk TIMERTASK TO TRUE ttint TYPE U@ U! U> U/ U< U. uboot uemit ufind ukey UM* UNLOOP UNPRIVATE UNSMUDGE UNTIL unum UPPER us U/MOD U.N (VA) VC VCFG VCLS >VEC .VECTORS VECTORS VER .VER VirtualRTC VOLTS@ VP VSCL W~~ W~ W-- W++ >W W@ W+! W! WAITCNT (WAITHILO) WAITKEY WAITPEQ (WAITPEQ) WAITPNE (WAITPNE) WATCHDOG wcnt wdt WHILE WITHIN WKEY WORD .WORD word (WORDS) WORDS WORDS: WRITEHEX WWORDS W>B W>L @X X1 X2 X3 X4 XCALLS XOR XY
Looks like I've got lots of work ahead of me (1100 thread conversations yet to read; 150 SPIN defined words to decipher and catalog; 721 QWORDs listed words to decipher and catalog).
If anyone has cheatsheets, they're welcome. It's obvious to me this journey is worth the effort and I thank you Peter for your phenomenal contribution.
If I was retired or if Tachyon was a paying job I might have a bit more time to enhance all this but Tachyon is more of a means to an end, but a means I try to improve and share. This is where I need help and partly for that reason is why the documents are in the cloud so that they can be edited and commented on etc.
BTW, the precompiled "Spin" kernel only has a few lines of Spin to launch the cogs and besides the PASM kernel the rest is bytecode constructed with "byte" directives. A PASM macroassembler is what is really needed to write the kernel in an neat and efficient manner but we use the Spin compiler instead to assemble PASM and bytecode.
Rather than a static glossary document that needs maintenance I have been adding help in the form of {HELP <comments> } to the source code which if loaded onto a Prop with a filesystem (SD card) can interactively invoke various levels of help for that word. For instance typing COGREG@ and hitting ^? (ctrl+?) will display the stack comment directly after it in a non-intrusive manner. Use HELP COGREG@ for more information and usage or use SEE COGREG@ to view the comments and source code. At present the help comments are still being added to the sources and when I have half a day to spare I will implement the rest of the help system. However the help comments are available when browsing the source online.
The "SPR@" error in the introduction is of course not a typo, it was correct at the time it was written. The problem is that Tachyon has evolved and the use of the SPR@ word has been deprecated, that's all. I don't think though that you need to read through all the forum posts, a google search should help to locate those of a particular interest.
The bulk of the words used are standard Forth, and Tachyon is really only different for the same reason that Spin is different, because the Propeller is different. The Propeller also has it's own limitations such as 496 long PASM kernel including kernel registers, 32K total to load the cog images and the Forth bytecode and dictionary. Some opcodes like OUTSET for instance "set out" to convey the notion that the OUT register can be SET with a mask, all 32 bits, not just a single bit.
But there are a lot of things about Tachyon that people don't like:
- It's not ANS
- It uses UPPERCASE
- It's not C
The first one is funny because I never saw ANS as being formulated or applied to embedded systems and besides this standard overly complicated what was essentially a KISS language.
I've had at least one bad reaction to my use of uppercase as if there are 26 characters that are not to be used. Well I like to be able to glance at source and see a difference between variables, modifiers, and actions and comments (which can be in between on the same line). When I see VALVE I know that it takes action whereas if I read "valve" elsewhere then it is more than likely a variable. Besides the first book on Forth that I read "Starting Forth" used uppercase for Forth words. Lastly of course it's not C, how could you actually load a C compiler itself onto a Prop and interact and compile programs with it?
If you can get over any "dislikes" then there are a lot of things to like that far outweigh that and from which you can start having fun.
I knew up front, since it was a new language with a fluid definition, I would need to document and test as I went along. So I wrote the web pages at the same time I wrote the test and example cases. I then wrote a program that extracted all the examples from the pages, ran them, and flagged results that changed from the previous run. Thus I was able to guarantee that the documentation was correct for the current version of the language. That regression suit was a very valuable tool.
On your last 3 points:
ANS: Like SmallTalk, Forth is a user extended language. Documentation and standardization will always be a problem with it
UPPERCASE: GLEE retains case as delivered by the programmer ... but it is case in-sensitive. It is also whitespace insensitive (I reject languages like Python because they are not ... oops, SPIN is not either). It also has three ways of getting around the need for escape characters for dealing with control and other special characters. Finally, it is totally "symbol oriented". There are very very few natural language oriented symbols and there are no reserved words.
Not C: GLEE is written in C++ and GLEE itself. I like C++ for writing languages like GLEE. But I generally don't like it for writing application programs. With a good debugger it's tolerable for programming things like PIC chips. Without a good debugger I'll take Forth of whatever dialect any day.
I envy Forth's ability in general, and Tachyon's ability in particular, to get down to the metal. I need to add such a surface layer to GLEE but don't think it would be possible to leverage the hardware like you have with Forth. It would require an ancillary connection like a debugger.
Regarding the dictionary: I personally need such a cheat sheet. I will work to develop a program in GLEE which creates such a cheat sheet from your source code and them supplements it where appropriate with ancillary text. The listing I made from the SPIN code did this (the byte code numbers ... or at least the order the words are added ... are in the brackets [ ].) But it is then sorted alphabetically giving weight only to letters and numbers and not case and symbols.
Regarding reading the thread: So far, most of what I know about Tachyon I've learned from reading source code and your answers and examples in the threads. Unfortunately, I'm learning a moving target. But as I've said, the value of the work you have done is enormous ... especially for a chip like the Propeller that has no debugging features,
Again. Thanks for your enormous contribution.