Shop OBEX P1 Docs P2 Docs Learn Events
TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++ - Page 61 — Parallax Forums

TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++

15859616364109

Comments

  • Cluso99Cluso99 Posts: 18,066
    edited 2015-01-06 00:02
    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.
  • ErNaErNa Posts: 1,738
    edited 2015-01-06 02:48
    Cluso99 wrote: »
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-01-19 21:53
    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.
  • MJBMJB Posts: 1,235
    edited 2015-01-21 03:52
    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.

    1-Wire seems stable.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-01-21 04:34
    MJB wrote: »
    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.
  • kwinnkwinn Posts: 8,697
    edited 2015-01-21 07:31
    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.
  • max72max72 Posts: 1,155
    edited 2015-01-21 08:15
    That's great.
    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
  • MJBMJB Posts: 1,235
    edited 2015-01-21 09:21
    kwinn wrote: »
    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.
  • MJBMJB Posts: 1,235
    edited 2015-01-21 09:27
    Just a link here, so the reference does not get lost with the now multiple Tachyon related threads.

    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
  • D.PD.P Posts: 790
    edited 2015-01-21 11:10
    MJB wrote: »
    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
    
    }
    
    
  • MJBMJB Posts: 1,235
    edited 2015-01-21 13:11
    D.P wrote: »
    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 ;-)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-01-22 16:27
    D.P wrote: »
    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 :)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-01-24 21:29
    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?
  • MJBMJB Posts: 1,235
    edited 2015-01-27 02:31

    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.
  • D.PD.P Posts: 790
    edited 2015-01-27 11:14
    MJB wrote: »
    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.

    Looking forward to see the WORDs used to parse this from IO, should be usable for many outward facing data gathering opportunities!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-01 18:34
    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]
    
  • D.PD.P Posts: 790
    edited 2015-02-04 19:40
    Did the Timer Alarm Syntax in the Kernel/Extend change since the example?

    Seems so, but I don't get any output from the test below.
    VER:    Propeller .:.:--TACHYON--:.:. Forth V24150105.2330
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $53AB...74B6 for 8,459
    CODE:   $0924...4A1F for 16,635
    CALLS:  207 vectors free
    RAM:    2,444 bytes free
    BOOTS:  65
    BOOT:   EXTEND.boot
    POLL:
    
    MODULES LOADED:
    4369: RHTP.fth            Rel Humidity Temp Driver  V1.3 20150203-1730
    42EA: HONEYHC.fth         HoneyWell HC Driver - v1.0.0 150125.0230S
    3787: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 141211-1100
    31A4: SDCARD.fth          SD CARD Toolkit - 141202.0000
    30D1: +P8.fth             P1432 +P8 HARDWARE DEFINITIONS 141118.0000
    2E0B: EEWORDS.fth         TACHYON DICTIONARY WORDS in EEPROM 150116.1900
    1A06: EXTEND.fth          Primary extensions to TACHYON kernel - 150116-1700
    
    
    TIMER hwtimer      
    WORD hwfreq
    
    pub HWMESSAGE
     	CR ." Hello World "			\ the basics 
     	hwfreq W@ hwtimer TIMEOUT   \ reload timer 
    ;
    
    \ Setup the timeout vector for TIMER 0
    ' HWMESSAGE hwtimer ALARM        \ source says ALARM (  PFA addr  --  )
    
    \ Write a reload value to timer's memory which we can change anytime
    #10,000 hwfreq W! 
    
    \ Setup timer 0  ( hwtimer ) to timeout in 5 seconds
    #5,000 hwtimer TIMEOUT
    
    .TASKS
    0000: CONSOLE                         0000 00 00 00 00 00 00
    0002: RS232.TASK                      45DD 01 00 00 00 00 00
    0003: IDLE                            0000 01 00 00 00 00 00
    0004: IDLE                            0000 01 00 00 00 00 00
    0005: IDLE                            0000 01 00 00 00 00 00
    0006: IDLE                            0000 01 00 00 00 00 00
    0007: TIMERTASK                       2A5E 01 00 00 00 00 00  ok
    
    
    

    RS232.TASK has it's own taskreg "stack" of 76 bytes



    ?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-04 20:00
    D.P wrote: »
    Did the Timer Alarm Syntax in the Kernel/Extend change since the example?

    Seems so, but I don't get any output from the test below.
    VER:    Propeller .:.:--TACHYON--:.:. Forth V24150105.2330
    FREQ:   96MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $53AB...74B6 for 8,459
    CODE:   $0924...4A1F for 16,635
    CALLS:  207 vectors free
    RAM:    2,444 bytes free
    BOOTS:  65
    BOOT:   EXTEND.boot
    POLL:
    
    MODULES LOADED:
    4369: RHTP.fth            Rel Humidity Temp Driver  V1.3 20150203-1730
    42EA: HONEYHC.fth         HoneyWell HC Driver - v1.0.0 150125.0230S
    3787: EASYFILE.fth        FAT32 Virtual Memory Access File System Layer V1.1 141211-1100
    31A4: SDCARD.fth          SD CARD Toolkit - 141202.0000
    30D1: +P8.fth             P1432 +P8 HARDWARE DEFINITIONS 141118.0000
    2E0B: EEWORDS.fth         TACHYON DICTIONARY WORDS in EEPROM 150116.1900
    1A06: EXTEND.fth          Primary extensions to TACHYON kernel - 150116-1700
    
    
    TIMER hwtimer      
    WORD hwfreq
    
    pub HWMESSAGE
     	CR ." Hello World "			\ the basics 
     	hwfreq W@ hwtimer TIMEOUT   \ reload timer 
    ;
    
    \ Setup the timeout vector for TIMER 0
    ' HWMESSAGE hwtimer ALARM        \ source says ALARM (  PFA addr  --  )
    
    \ Write a reload value to timer's memory which we can change anytime
    #10,000 hwfreq W! 
    
    \ Setup timer 0  ( hwtimer ) to timeout in 5 seconds
    #5,000 hwtimer TIMEOUT
    
    .TASKS
    0000: CONSOLE                         0000 00 00 00 00 00 00
    0002: RS232.TASK                      45DD 01 00 00 00 00 00
    0003: IDLE                            0000 01 00 00 00 00 00
    0004: IDLE                            0000 01 00 00 00 00 00
    0005: IDLE                            0000 01 00 00 00 00 00
    0006: IDLE                            0000 01 00 00 00 00 00
    0007: TIMERTASK                       2A5E 01 00 00 00 00 00  ok
    
    
    

    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! ;
  • D.PD.P Posts: 790
    edited 2015-02-04 20:35
    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?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-04 20:44
    D.P wrote: »
    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-04 21:00
    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.
  • D.PD.P Posts: 790
    edited 2015-02-04 22:04
    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.

    Never mind see error above.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-04 22:30
    D.P wrote: »
    Well this code doesn't work on the quickstart?

    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
    
  • MJBMJB Posts: 1,235
    edited 2015-02-16 13:53
    This is an image of Peter's Tachyon based Propeller explorer with my 1-Wire code loaded.
    with the command
    lshw
    or
    1W.DISCOVER
    
    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
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-22 19:30
    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.

    [video=youtube_share;jFHpfAei9yk]
  • mindrobotsmindrobots Posts: 6,506
    edited 2015-02-22 20:40
    Wow! Lookin' good!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-22 21:32
    mindrobots wrote: »
    Wow! Lookin' good!

    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]
  • Todd MarshallTodd Marshall Posts: 89
    edited 2015-02-23 11:08
    Peter:

    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.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-02-23 16:21
    Peter:

    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.
  • Todd MarshallTodd Marshall Posts: 89
    edited 2015-02-23 19:26
    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,

    Again. Thanks for your enormous contribution.
Sign In or Register to comment.