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 8 — Parallax Forums

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

15681011109

Comments

  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-08-16 14:14
    Thanks. I was probably being a bit too literal; I saw an RX object declared, but no TX object.

    Update: Up and running between work tasks.
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-16 17:03
    IN the VGADEMO.fth, the last lines of the file are
    \ CORRECT THE 5X7 FONT FOR USE WITH VGA
    FONT $1D + C@ $0F = IF FONT $60 7 * ADO I C@ #27 REV I C! LOOP THEN
    \ back it up into EEPROM - don't use paging NOTE: this becomes redundant once the font table is fixed
    FONT DUP $60 7 * ESAVEB
    END
    

    what is "ESAVEB" ??? It gets a "???" and I have looked all over without finding a clue!
  • prof_brainoprof_braino Posts: 4,313
    edited 2012-08-16 21:34
    Rsadeika wrote: »
    Read post #195.

    Wow. 195 posts. If there were one post detailing each word in the dictionary, the thread would be done already.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-08-16 21:37
    Hi Jeff, I'm shocked, absolutely shocked (Casa Blanca I think) that the extended features didn't backup to EEPROM. Normally after loading in a fresh kernel the idea is to download EXTEND.fth and if there were no errors in download (usually due to coming in too fast without handshaking) then it will do an automatic backup. So just make sure that you have enough line delay on your terminal settings (30 to 50ms) and that there were no errors. However the VGA DEMO does not do an automatic backup because it's a demo but you can tell it to at any time by typing BACKUP. The VGA demo is overlapping into ROM until I free up some more memory so you will see some garbage at the bottom of the screen when it's not blanked. Is that what you mean by "glitched".

    I'm going to try the EEPROM thing again on the Quickstart, with and without my plug-in-board. I'm wondering if something there is getting in thew way. (Like USB power enable jumper maybe?) -I'll report back..

    (Darn it! I took another chip!) :)


    Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.
    Jeff
  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-08-17 07:20
    Edit, It seems the "ms delay" setting was key to getting this work. I switched to "TeraTerm" under Windows which has this delay setting, and it seems to be accepting the code now.

    I went through the same thing until I found the line delay setting in TeraTerm.
  • TorTor Posts: 2,010
    edited 2012-08-17 07:40
    Been following the thread. Seems like I should be able to run this thing on a QuickStart, with or without my VGA+ board. That combo is such a nice little "mini"computer which just might be the thing for playing around with Forth.

    In the past when I've looked into Forth and Forth-like languages I always found it interesting, but I always ran into a wall when I wanted to try Forth for the stuff I normally do in some high-level language on the computer.. writing emulators and data processors. Forths in general won't seem to let me work that way, with programs taking input from files, letting me edit source in my editor and so on. But with a QS I can as well do the interactive thing, as there's no operating system or filesystem there anyway.. so I'll have a go at it this weekend.

    -Tor
  • prof_brainoprof_braino Posts: 4,313
    edited 2012-08-17 07:42
    Tachyon does the interpreter's compilation in-line, it does not send it over to another cog so is susceptible to overrun on the input.
    This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-18 04:59
    Tachyon does the interpreter's compilation in-line, it does not send it over to another cog so is susceptible to overrun on the input.
    This makes it simpler, but needs the user to be aware how this works to avoid the issue. This one design decision that is different from other implementations.
    But Tachyon does not go through long long development cycles before release, it is a work in progress and the primary focus was to get it up and running as fast as possible and build up from there. So I use the expression "bear in mind" a bit but it's a reminder that any deficiencies Tachyon has now is simply because of it's being incomplete although it is "complete at any particular stage" in that it functions well and it's no slouch at 7 weeks. Compile speed is not really that important in the whole scheme of things so it has a lower priority at present as other things are far more important. IIRC PropForth had problems with line delays being required for a long time before that was finally fixed up and now it works really well. Being able to squeeze as much as I do out of one cog without having to resort to special PASM operations simply means that Tachyon will not fail to impress when it opens up to full throttle.

    Also, the compilation in-line is very deliberate and can and will perform a lot faster than all that multiple buffering that goes on with serial buffers, terminal input buffers etc. The main offender at present is not having a dependable method of handshaking as some terminals support XON/XOFF and some don't. Putting in a longer line delay means it takes 5 seconds instead of 1 or 2 to compile a file, hardly anything to lose sleep over. In the end runtime speed is far more important which Tachyon cannot be faulted for, especially in the area of I/O and common operations which is where an MCU needs to perform. If that's a temporary tradeoff then I'm certainly happy with that :)
  • prof_brainoprof_braino Posts: 4,313
    edited 2012-08-18 14:25
    yes its perfectly fine and a valid choice, just noting that it is different in one of the many ways it can be different. Propforth tends to have many, very long scripts, and the delay was getting bothersome. We figured the chance to have an overrun meant we would get false bugs, so we made a different choice. Tachyon is attracting more of the advanced users and so this should not be an issue. Anything that works really well is fine in my book.

    It is really cool how far you've come in such a short time. Clearly you don't waste as much time watching TV as some of us. :)
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-18 15:48
    Another Tachyon script ... Ping))).

    I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.

    Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.

    One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-19 18:36
    I have started playing with SimpleIDE and have also been using this for editing Forth source code files (.fth) as well. It got me thinking that it would be nice if SimpleIDE had a terminal built-in especially if it supported common ANSI controls and allowed source code to be downloaded along with XON/XOFF handshaking. So I will try to find out about this but in the meantime some of you may have noticed that various snippets of code look a little Spin-like. You know, instead of the colon they start with pub or pri plus instead of a long line of code it is spread over multiple lines. Well, I'm trying to make this more readable for Spin users and it is just as readable to Forth users yet it does not compromise the simplicity of the Forth compilation process. There are probably other changes I will make as they seem practical and conducive to learning to program in Tachyon Forth (and have others understand it).

    So where I can and as long as it doesn't compromise Tachyon itself I have been renaming or creating aliases of functions so that they are more familiar to Spin (and C) users but of course taking into account the RPN stack notation. Here's a snippet of LCD code that uses ++ and ~ and pub etc, even LOOKUP in a slightly different form:
    pub LCDHOME
        ypos C~        '' clear y line position 
        xpos C~        '' clear x character position
        2 LCDCMD        '' Raw home command for LCD 
        1 ms        '' Just give the LCD time to execute it
        ;
    
    pub LCDCLS        '' Clear the LCD screen
        1 LCDCMD        '' Raw LCD command to clear it's screen
        1 ms        '' The only command that you really need to wait for
        LCDHOME    
        ;
    pub LCDCR        '' Carriage return
        xpos C~ XYCUR    '' Return to X position zero and update LCD's cursor
        ;
    pub LCDLF        '' Line feed
        ypos C++
        ypos C@ #lines =>    '' Wrap-around to the top of the display?  
          IF ypos C~ THEN
        XYCUR        '' Update the LCD's internal cursor
        ;
    pub LCDCHAR ( char -- )    '' Treat character as data
        LCDDAT
        xpos C++        '' increment character position
        xpos C@ chars =>    '' and wrap to next line if necessary
          IF 
          xpos C~
          LCDLF 
          THEN
        ;
    pub LCDchar ( char -- )
        0 REG C@ LCDCHAR    '' Restore character and pass as a character to the LCD
        ;
    pub LCDCtrls ( ctrl -- )    '' Look up and execute the code that corresponds to the ctrl character
        $10 LOOKUP LCDchar    { Default vector if above limit of $10 }
        LCDchar LCDHOME LCDchar LCDchar 
        LCDchar LCDchar LCDchar BEEP 
        LCDchar LCDchar LCDLF LCDchar 
        LCDCLS LCDCR LCDchar LCDchar 
        ;
    pub LCDEMIT ( char -- )    '' Process the ASCII character either as a control or as a printable character
        DUP BL <        '' Less than a BLANK ($20) is a control character
          IF DUP 0 REG C! LCDCtrls 
          ELSE LCDCHAR    '' else it is display data
          THEN
        ;
    
  • prof_brainoprof_braino Posts: 4,313
    edited 2012-08-20 06:08
    I have started playing with SimpleIDE and have also been using this for editing Forth source code files (.fth) as well. It got me thinking that it would be nice if SimpleIDE had a terminal built-in especially if it supported common ANSI controls and allowed source code to be downloaded along with XON/XOFF handshaking. So I will try to find out about this but in the meantime some of you may have noticed that various snippets of code look a little Spin-like. ....

    Don't know if you're open to this, but it got me thinking....

    I hear Go language compiler also compiles C code. The Go language terminal utility example Sal wrote uses the host PC's OS functions, so it gives tab completion, command history, command line editing, stuff like that for free. And it provides the channel interfaces, so the PC app can talk directly to the prop over a fast channel, if you chose to expand in this direction...
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-20 09:49
    Yet another Tachyon Forth script ==> Parallax PIR Sensor module

    Like my script for the Ping, my PIR code is a transcription of Josh Donelson's SPIN code to Tachyon Forth.


    **** The code in PIR.ZIP is good under kernel 120815.0930 ****


    **** The code in PIR2.ZIP is good under kernel 120820.1445 ****


    Enjoy!!
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-22 12:20
    Peter,

    I the new code for the SD card, in the top of the file you have a iomask constant for "Card Detect" called ".CARD"
    TACHYON
    
    : SDCARD.fth	." SD CARD Access and file system layer - 120821.2100 " ;
    
    #23 MASK	CONSTANT .CARD	'' Card detect - active low
    #24 MASK	CONSTANT .SDCS	'' SD Card chip select
    #25 MASK	CONSTANT .SDCK	'' SD Card clock
    

    Then down around line 179 you have a word defined ".CARD" ... Is this a problem?
    CREATE tval	
    	#00 | #10 | #12 | #13 | #15 | #20 | #25 | #30 |
    	#35 | #40 | #45 | #50 | #55 | #60 | #70 | #80 |
    
    '' Card information
    : .CARD
    ''	  CR ." BYTES:  " SDSIZE? .
    	  ''    0123456789ABCDEF012345
    	  CR ." MFG:    " cid C@ .BYTE
    	  CR ." OEM:    " cid 1+ 2 TYPE
    

    Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?
  • mindrobotsmindrobots Posts: 6,506
    edited 2012-08-22 12:45
    Another Tachyon script ... Ping))).

    I started with Chris Savage and Jeff Martins spin code from 2006 in v 1.5 of the Ping manual.

    Initially all I did was 'transcribe' the Spin code to Tachyon Forth and get it, first, to run ... and, second, to run right! It did, then I settled down to smooth it out and comment it.

    One neat set of words that were very useful were NEWCNT and LAPCNT ... check them out, buried in the kernel.

    Brian,

    I took the liberty of porting your wonderful PING.fth for Tachyon to PropForth and posted it to the PropForth 5.0 thread here. I don't want it to feel left out since everyone is playing with the new kid. (Sibling rivalries and all that! :lol:)

    I'm going to do the PIR next, when I get more play time if there are no objections.

    Thanks for the words!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-22 16:04
    Brian,

    Since I don't use the card detect switch I never noticed it :) It just so happens that last night I came across this and renamed the card detect switch to .CD although I may improve my convention for naming pins as it can get confused with the standard Forth dot word for print.

    My detect routines assume you have not used the seemingly obligatory pull-up resistor on the chip select line then you can use this routine to detect whether a card is present or not
    : CD?    ( -- flg ; Is SD card present? )
        ON SDCS            '' Force CS line low
        .SDCS INPUTS        '' Float CS
        .SDCS IN        '' Is it still low or has it been pulled up (by the card's pullup)
        OFF SDCS
        ;
    
    brian wrote:
    Also I have several Prop Platform USB boards with microSD slots on P0 to P3 with CS, DO, DI, and SCLK, but no Card Detect. How difficult to adapt the code? I was looking it over, searching against ".CARD" (that's how I found the dual definition) and a first glimpse it doesn't look too tricky to excise CD code ... am I missing anything critical?

    So as you can see the card detect switch is not being used as I rely on the documented CS pull-up that is present on SD cards internally. If you have a pull-up to the CS line on your board then disconnect it.
    After power up, this line is input with 50Kohm(+/-20Kohm) pull-up (can be used for card detection or SPI mode
    selection). The pull-up may be disconnected by the user, during regular data transfer, with
    SET_CLR_CARD_DETECT (ACMD42) command.

    Here's a schematic of the SD hookup that is used in the code (although I have many others I test as well).
    Prop MicroSD.png
    913 x 399 - 36K
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-22 20:13
    Seeing that a version of my L6470.fth has just been posted in the PropForth thread I thought I would post my Tachyon version of the original L6470.fth file. This is not totally optimized yet for Tachyon but the code takes 1.8K. These files are also available through the link section of the Tachyon Intro page. One of the aims with Tachyon was to avoid any cryptic PASM code when programming in Forth and so Tachyon had to be fast but it is also supported with a sensible set of instructions in it's VM.

    L6470 Microstepper code for dual motors - L6470 1V1.txt
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-26 18:02
    It's not quite two months since I started the Tachyon project and for the last couple of weeks I have been porting applications across to Tachyon and tweaking the kernel that little bit more etc. I have now released V1.1 which also introduces multi-tasking using cogs 4 to 7. There's also a KEYPOLL background function that can be used from the primary terminal task that's useful for checking for status updates such as SD card insertion/removals etc without resorting to using another cog.

    The SD card "toolkit" has been up and running but I am still doing some more tests with various cards before I add on the full virtual memory and file system extensions. At the moment it's very useful for investigating SD cards and you can even backup the hub ram directly into the SD card as if it were just a very large SPI memory chip (and unless you want to use it in a PC, who cares). It's possible to do bitmap screen updates at around 20 fps with this method which just uses a PASM kernel routine for bit-bashing SPI. I might look at the counter approach later on once functionality is fully established (so 60fps would be possible!). BTW, I favor non-fragmentation of files as it simplfies file access and makes them far more efficient. Sometimes I even create one big non-fragmented file which may hold lots of smaller files. Certainly many of my logging files preallocate a large chunk as non-fragmented so that it becomes a simple virtual memory and avoids all those traditional and cumbersome file access methods. The virtual memory address is the handle and the virtual memory access words hide the caching and flushing etc.

    Now there's also a lot of peripheral chip interfacing that I'm doing but let me know if there are any special requests as I will be testing and releasing this source daily.
  • PowersoftPowersoft Posts: 72
    edited 2012-08-27 07:40
    Peter,

    Do you have experiance to communicate with a mcp3004/3008 or mcp3208

    Thanks in advance.

    Jan
  • PowersoftPowersoft Posts: 72
    edited 2012-08-27 07:59
    Peter,

    Another thing I dont get fix is to output a PWM signal on a specific pin.
    Do you have an example in TACHYON

    Thanks in advance,

    Jan
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-27 12:13
    It's not quite two months since I started the Tachyon project and for the last couple of weeks I have been porting applications across to Tachyon and tweaking the kernel that little bit more etc. I have now released V1.1 which also introduces multi-tasking using cogs 4 to 7. There's also a KEYPOLL background function that can be used from the primary terminal task that's useful for checking for status updates such as SD card insertion/removals etc without resorting to using another cog.

    The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?

    So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?

    ... and the answer is 4..7 only, a request for 0 or 3 executes but nothing
    Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200
    
    
    TACHYON
    
      Propeller .:.:--TACHYON--:.:. Forth V1.1 rev120827.0200
    ok
    : TASK1  ( -- )
             BEGIN
                     0 MASK OUTSET
                     #500 ms
                     0 MASK OUTCLR
                     #500 ms
             AGAIN
             ;  ok
    : BLINKY   200d FOR 0 MASK OUTSET 100d ms 0 MASK OUTCLR 100d ms NEXT ; ok 
    END
    End of source code, there were 0 errors found
    CODE   @$3E9D  - bytes used in this load = 39
    NAMES  @$1DCB  - bytes used in this load = 17
    YCALLS @ 180 entries free
     ok
    NOVGA  ok
      ok
    ' BLINKY >PFA 3 RUN  ok
    .
    ' BLINKY >PFA 7 RUN  ok
    7 STOP  ok
    ' BLINKY >PFA 0 RUN  ok
    
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-27 13:33
    There is a problem in the multi-tasking. Once you excercise a COG, say " ' BLINKY >PFA 5 RUN " and it runs for a while, and then you decide its usefulness is over and you issue a " 5 STOP" ...

    THAT"s IT for COG 5 ... you can issue this, " ' BLINKY >PFA 5 RUN " until the cows come home and it isn't going to blink, because it never gets back to that SPIN initialization in COG 0 where the Tachyon VM idle loop is called for COG 5 "cognew(@RESET, @IDLE)"

    Now maybe I have made the mistake of loading my expectations on to your project, but it seems to me that being able to start a cog with a task and then stop it and run yet another task and maybe go back to the first task or on to a third or fourth one is what we've come to expect from Prop based systems.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-27 16:18
    Powersoft wrote: »
    Peter,

    Another thing I dont get fix is to output a PWM signal on a specific pin.
    Do you have an example in TACHYON

    Thanks in advance,

    Jan

    Do you want PWM or duty mode DAC?
    If it's a duty mode DAC then that's real easy, you can even do that in interactive mode as you have direct access to the counter registers. Just type this in:
    #11 APIN
    DUTY

    To get a square wave (50%) type:
    $8000.0000 FRQ

    To get 25% type:
    $4000.0000 FRQ

    To make that into a convenient word say as an 8-bit DAC:
    pub DAC! ( level -- )
    #24 SHL FRQ DUTY
    ;
    The pin can be specified once as shown above or changed on the fly. By default the A counter is accessed but you only have to type in "B" to change it like this:
    B #12 APIN
    $40 DAC!
    Which will set pin 12 to use counter B with a 25% duty cycle.


    Now if it's PWM (fixed frequency) you need then normally we dedicate a cog to looking after that (plus other things). That's not so hard either but this duty mode is simple and normally what you would use if you had an RC network to filter it to a voltage.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-27 16:26
    To answer this and your other question:
    It's easy enough to use cog 0 but why bother as we already have 5 cogs running a Tachyon VM and I might want another one for an object from the OBEX (maybe). Each cog has an "run" vector but unless all cogs are runnning Tachyon (possible) they won't all be needed. At startup cogs 4 to 7 are loaded with the VM but told to execute an IDLE loop which just waits for it's run vector to come alive. Once it's off and running there is not much in the way of control that we have with these little cogs but that's the way the Prop is. You can stop them but you can't restart them unless you do another coginit which I can do but it's only necessary when you are mucking around testing and it's easier just to reset the Prop (^C or <break>).
    The kernel spin file starts things up and then terminates COG 0. Comments there led me to think that COG 0 would be available in addition to COGs 4..7 ... and then what about COG 3 if VGA is not compiled in, or you manually turn off VGA?

    So is the RUN method hard coded only to accept 4..7 or are 0 and 3 also acceptable ?
    <snip>
    [/code]


    However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
    EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-27 16:43
    Powersoft wrote: »
    Peter,

    Do you have experiance to communicate with a mcp3004/3008 or mcp3208

    Thanks in advance.

    Jan
    I've started up an MCP3208 code document and I will hook-up a chip later as I have used these in old projects. You are welcome to follow my progress but be quick about it as it won't take long at all. Although this is the default ADC solution for many as it's easy I don't really use these chips anymore as I use cheaper solutions based on single-chip processors with embedded ADCs and I2C etc.

    EDIT: The solution should have taken 5-10 minutes once I hooked up the pcb except I forgot that this board had a deliberate and hidden short between the Din and Dout of the chip and I was wondering why I kept reading back 0's until I decided to float the MOSI from the Prop after the first 8 bits. Anyway it's working now, there's both a fast and slow method. I checked it on my old pill counter sensor pcbs which use 1" photodiodes connected to opamps and into the MCP3208. It's all working well.
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-27 18:21
    However, I could make the IDLE loop kill the vector before it runs the user code, then call the code so that if it returns it will be back to idle. I will check this method out.
    EDIT: Just changed it so that it clears the vector when taken and if you exit your code it will wait back in the IDLE loop

    Before I was running a "BEGIN..AGAIN" loop with no exit and stopping it was simple matter of "<cogid> STOP" With a foreground processes you test a "KEY?" to break a loop. Is there a way to send a cog a character? Or do we do it the old fashioned way cog abort flag in hub ram?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-27 18:52
    Since it's not possible to interrupt a cog then the only way to break into anything is if the user code polls for something. So I guess your code may have poll a variable then. I don't know if there's a better way. I will see if I can include something as a VM instruction that simplifies this. But remember this really only applies when you are testing out code and wish to stop it without resetting. Every other time we want to stop any kind of code we have to reset it anyway.
  • Brian RileyBrian Riley Posts: 626
    edited 2012-08-27 21:23
    OK, when you put it that way. Most tasks will come in execute and exit back and the VM Idle Loop resumes. If you have and endless loop its still good to have control, so instead of "BEGIN.. AGAIN" You code "BEGIN.. ?hubflag UNTIL"so the loop can be forced out without a system reset.

    Question: you said you made a change for multi-tasking several hours ago "Tachyon1v0-VGA.spin" was altered 4 hours ago and "Tachyon1v1-VGA.spin" 20+ hours ago. Did you mean to alter v1.0 or v1.1 ????
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-27 21:31
    Whoooops, what's in a name??? Okay, I fixed the name of the files and removed 1V0 so there is no confusion. I will put that flag in shortly, maybe even use the vector location with a single-byte command rather than an address.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2012-08-27 21:57
    Okay so I have made an addition to allow other Tachyon cogs to receive a command, a bit like hitting a key. It's really very simple, we just insert ATN? which returns with a non-zero byte command which is inserted by another cog. You can interpret the command anyway you want, just like a key. The command is read from the cog's "tasks" vector which won't cause it to run wild as it will simply clear a byte command in the idle loop without trying to execute it.

    Here's what my blinky looks like:
    #13 MASK    CONSTANT .RDY
    : BLINKY    BEGIN .RDY OUTSET 50d ms .RDY OUTCLR 50d ms ATN? UNTIL ;
    ' BLINKY >PFA  4 RUN
    
    Now when I type:
    1 4 RUN
    where 1 is a "command" for cog 4 the loop will terminate and I can get control of it once again in the idle loop. This is also a neat way to pass commands to the cog if it is setup to process them like this:
    #13 MASK    CONSTANT .RDY
    : BLINKY    50d BEGIN .RDY OUTSET DUP ms .RDY OUTCLR DUP ms ATN? DUP 1 > IF NIP DUP THEN 1 = UNTIL ;
    ' BLINKY >PFA  4 RUN
    
    So blinky will start off with a fast blink, but now:
    #200 4 RUN
    will cause it to slow blink
Sign In or Register to comment.