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

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

13334363839109

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-06 23:32
    D.P wrote: »
    Well I put
    0 STOP 
    
    Into my AUTORUN "word" and it still doesn't boot without the USB cable and as a bonus ^A doesn't abort the AUTORUN either so know I need to rebuild the world to get back in.

    I've had this issue with everyboard I use, I could really use a simple example of a booting tachyon system that does not rely on a USB connection.

    I'm doing something wrong obviously.

    I have an old Parallax demo board I could try it on, if you send me your code and I will see what is happening.
  • D.PD.P Posts: 790
    edited 2014-01-06 23:38
    I've always had to have my tachyon boards tethered, POE, PPDB, Quickstart. There must be something fundamentally I'm missing here. But here are the modules loaded.
    MODULES LOADED: 
    46F9: RELAY8.fth          ETHRLY8 Board (WIZNET W5200) driver 140105.1630 
    401A: W5200.fth           WIZNET W5200 driver 131211.1530 
    3756: MULTIFILE.fth       FAT32/16 MultiFile Layer V1.1 131207-0000 
    2FD7: SDCARD.fth          SD CARD Toolkit - 131114.0000 
    17C0: EXTEND.fth          Primary extensions to TACHYON kernel - 131124-0000 
    
    And I just sent you Relay8.fth by PM
  • max72max72 Posts: 1,152
    edited 2014-01-07 00:05
    Could it be the FTDI resetting? There are many discussion about that, and the symptoms are the same.

    Massimo
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-07 04:37
    I have used the VGA bitmap object directly but since that is just PASM that runs in it's own cog there wasn't anything much to change whereas most of the objects available have Spin wrappers which can't be used. In many instances I find that much of this Spin code is redundant anyway. I will take a look at SIDcog though to see if there is a possibility or using it.

    I have started to write the SIDcog interface for this and it looks fairly complete, now I only have to graft in the the PASM binary and the waveform table to start testing, but I probably won't have time to do anymore on this for at least a day or two. I have simplified the functions so that they can be combined easily and interactively from the serial terminal so it's very easy to experiment with SIDcog. It "sounds" like it will be a lot of fun once I can get back to finishing it.

    Example of interacting with SIDcog (in one line)
    0 CHAN 8 3 4 2 ADSR ON HP ON BP OFF LP ON SAWTOOTH #1000 NOTE

    What that was about:
    0 CHAN \ select channel 0
    8 3 4 2 ADSR \ Set attack, decay, sustain, release (ADSR(
    OFF HP \ Turn off highPass filter
    ON BP \ Turn on bandpass filter
    OFF LP \ Turn off lowpass filter
    ON SAWTOOTH \ Select SAWTOOTH waveform
    #1000 NOTE \ Play a note

    Of course if that was a sound effect (no idea what it sounds like yet) you could just then define it as a new word.

    Here's the link to the Tachyon Google webpage document for the SIDcog module.
  • base2designbase2design Posts: 78
    edited 2014-01-07 09:29
    Dang dude... do you ever sleep? I didn't mean for you to write the "whole dang thing" for me but I'll have loads of fun playing with it. I take it from the process you've indicated here that PASM parts of OBEX items will work unchanged with Tachyon but Spin parts have to be re-written. That's fair... I'm an old-time forth fan anyway so I'm up for a change of perspective. I won't be in front of a Propeller until tonight but will certainly fire up Tachyon tonight and get my bearings so I can start testing/contributing.

    Thanks again!
  • D.PD.P Posts: 790
    edited 2014-01-07 10:58
    Dang dude... do you ever sleep? I didn't mean for you to write the "whole dang thing" for me but I'll have loads of fun playing with it. I take it from the process you've indicated here that PASM parts of OBEX items will work unchanged with Tachyon but Spin parts have to be re-written. That's fair... I'm an old-time forth fan anyway so I'm up for a change of perspective. I won't be in front of a Propeller until tonight but will certainly fire up Tachyon tonight and get my bearings so I can start testing/contributing.

    Thanks again!


    Uh oh, you will not believe the treat you are in for. You may not be sleeping much yourself! While some of the syntax has very slightly changed in the Introduction to Tachyon webpage it is still a great way to get started and understand the layout. Look forward to your contributions.
  • Brian RileyBrian Riley Posts: 626
    edited 2014-01-07 16:54
    max72 wrote: »
    Could it be the FTDI resetting? There are many discussion about that, and the symptoms are the same.

    Massimo

    Excuse me for arriving late to this thread ... this BOE Tetherless Startup is old news ... as Massimo has stated it has already generated reams of discussion elsewhere in the Prop Forums and I don't know if any solution was ever reached ... perhaps @PhiPi knows ...
  • D.PD.P Posts: 790
    edited 2014-01-07 16:54

    One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.

    Here is/are the only word/s I have added:
    : BLINKY BEGIN #P17 PINSET 100d ms #P17 PINCLR 100d ms KEY? AND UNTIL ;
    AUTORUN BLINKY
    \ then executed a backup
    
    Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.

    When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.

    Let's see if we can figure out this very simple example of my "failure to understand".

    Thanks
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-07 17:16
    D.P wrote: »
    One step at a time, I have basic setup with only TACHYON and EXTEND.fth loaded on a quickstart REV A board with the Wiznet Quickstart Board attached so I have an external power connector to power the quickstart board sans USB cable.

    Here is/are the only word/s I have added:
    : BLINKY BEGIN #P17 PINSET 100d ms #P17 PINCLR 100d ms KEY? AND UNTIL ;
    AUTORUN BLINKY
    \ then executed a backup
    
    Everything works fine, the system boots and blinks until I hit a key and even ^A aborts BLINKY after boot! But that is a KEY? so I don't think this counts.

    When I unplug the USB cable (still have power from the wiznet board) the system doesn't blink any longer even after a power cycle.

    Let's see if we can figure out this very simple example of my "failure to understand".

    Thanks

    Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.

    Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.

    There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.
  • D.PD.P Posts: 790
    edited 2014-01-07 18:32
    Well that's a bit of a silly test now isn't it? It's accepts anything at all on the serial to abort the BLINKY, even a bit of noise from a misdriven (FT232 phantom power) receive line. How about using ESC? instead which will wait until it sees a valid escape character before aborting the loop.

    Just to be on the safe side can you modify your TF kernel with this, at the "frmerror" label just insert a "jmp #receive" instruction to get it to ignore any break conditions.

    There is the other possibility that the FT232 chip is resetting the Prop, but that's a hardware problem, isn't it? Why hasn't Parallax addressed this problem in it's Prop products? You could try keeping the transmit pin low so that it won't phantom power the FT232 chip, but you need to insert a "#P30 PINCLR" in your startup code but that mightn't work because the Prop might get reset before then. A quick fix is to place a load on the FT232 power rail by adding a 1K (or better still a 220R) or so resistor which should stop the supply rail from floating up high enough. The other thing is to insert a 10K series resistor in the transmit line to the FT232.

    Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.

    The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.

    Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
    And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.

    See any stray "Puppys" looking for a good home?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-07 19:03
    D.P wrote: »
    Desperate times breed trouble, what I love about Tachyon is that is took < 60 seconds to make the change and test, including getting some water to drink.

    The ESC? is in place and it works at expected, yes ^A does abort the AUTORUN as advertised.

    Now about the FT232, that's a tiny thing and I'm sure I could short every pin trying to "hack" at it. Can I cut a usb cable, re-wire it and fake the chip that way. And yes for all the commercial stuff parallax wants to get going you don't get there unless you address your own products first. If the hardware implementation was/is "wrong", fix it, your customers will appreciate you for it and reward you.
    And oh help them if David Carrier releases his new board with the same FT232 "bug" becuase it's the schematic they have always used.

    See any stray "Puppys" looking for a good home?

    Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.
  • D.PD.P Posts: 790
    edited 2014-01-07 19:51
    Just looking at a typical Parallax product such as the Activity Board and it uses a FT231 chip with a gate to disable "garbage" on the receive line to the Prop but why there as the problem is that the Prop's TX if activated will idle high and still phantom power the chip. All it needed was a series resistor to limit the current so the FT231 can't power-up, that's all.

    Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?

    I've got sharp things and feeling like cutting something right now.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-07 20:35
    D.P wrote: »
    Not to mention running with the C rowd, don't get me going here. It seems that with my laptop sleeping and the usb plugged in the board behaves the way I want it to so I should be able to do something with a cut USB cable no? Grab one of the bare lines and tie it low or high on the quickstart?

    I've got sharp things and feeling like cutting something right now.
    I just tie VBUS to VCC as I normally run it off USB power or external power but then again, I haven't had any problems with it that way either. The bonus is that when you are developing you don't need any external supply.
  • D.PD.P Posts: 790
    edited 2014-01-07 22:35
    I just tie VBUS to VCC as I normally run it off USB power or external power but then again, I haven't had any problems with it that way either. The bonus is that when you are developing you don't need any external supply.

    Well it cost me a quickstart board because I made a pinout mistake. But your solution works on the BOE and the PPDB and I'm sure the quickstart as soon as I purchase another (if I do) thanks for all the patience Peter. This whole experience has not won any good feelings from me toward Parallax. Hey David Carrier: don't use the FT232 design that is broken on the quickstart board, the PPDB and the BOE board on your new Spinnerette design okay. No one in the field it seems has implemented the FT232 the way parallax has on these boards.

    Now back to Tachyon and my project since this accidental complexity is gone, thanks again Peter.

    dp
  • max72max72 Posts: 1,152
    edited 2014-01-08 04:54
    As an alternative to FTDI modding consider a BT of wifly module. It costs 2 pins, but worth the experience!
    In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
    OT: If you program with spin there is a pst dummy object to simplify debugging
    Massimo
  • base2designbase2design Posts: 78
    edited 2014-01-08 12:58
    Max, can you expand a bit on this?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-08 14:57
    max72 wrote: »
    As an alternative to FTDI modding consider a BT of wifly module. It costs 2 pins, but worth the experience!
    In this case you set the serial console pins to the wireless module, p30 and p31 are left alone, and no spurious reset occurs.
    OT: If you program with spin there is a pst dummy object to simplify debugging
    Massimo

    Most of my boards don't have USB embedded in them as I simply have a 4x2 PropPlug compatible header instead. The second set of 4 pins include +5V and I2C signals so it is possible to power any adaptor that is plugged in such as my own Bluetooth modules or in the case of USB allowing it to power the board. The I2C lines are handy too as I can directly access the EEPROM and this allows for field programming where I have a little module that plugs in, blinks, and reprograms boards. The I2C can also be used as an expansion header to a peripheral board.

    These modules can be plugged in as required or left in permanently.

    BTSER+USB-m.jpg


    @Max: A Bluetooth module does not allow for normal program download via the Spin tool so there is no need for it to reset the Prop anyway although my Bluetooth module does include remote programming support.
    1024 x 1127 - 264K
  • max72max72 Posts: 1,152
    edited 2014-01-08 15:00
    With some boards the reset happens when you have a serial stream to the ftdi chip, and the usb cable is not connected.
    If you send tachyon console message to other pins you avoid the issue.
    a cheap option is to get the bluetooth modules, attach one to a couple of spare pins, reload tachyon after changing the console pins (not 30 and 31 but your wireless module pins) and wirelessly connect using your pc's bluetooth or your android tablet. Not ipad/iphone. With ipad there are the wifly serial to wifi modules. More expensive and a little bit more complex to use.
    Anyway with a little expense you have the possibility to remotely connect to the tachyon console and avoid the reset issue.
    Check the forum for threads about the cheap bluetooth modules, or propforth wiki. They are sold also by obc on propellerpowered.
    Peter discussed about them too.
    connecting to a remote console, even if 5 cm away, is truly a great experience offered by forth on the propeller.
  • max72max72 Posts: 1,152
    edited 2014-01-08 15:07
    Sorry Peter, I wasn't clear.
    My approach is to program the propeller using the "traditional", tethered way, and then remotely connect.
    Your modules are very cool!
    Thanks for sharing.
    Massimo
  • D.PD.P Posts: 790
    edited 2014-01-12 11:05
    Running this code in a separate COG does not "blink the lights" at 3 Hz but at ~164KHz?
    Do I have a COGREGS issue?
      Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
    
    MODULES LOADED: 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200
     
    : TOG  A  #15 APIN #14 BPIN 3 Hz 5 CTRMODE  #10000 ms MUTE ;    
    TOG      / RUNS AT 3 HZ  and quits after 10 seconds
    ' TOG 4 RUN    / RUNS AT ~164 KHz  and quits after 10 secs
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-12 14:53
    D.P wrote: »
    Running this code in a separate COG does not "blink the lights" at 3 Hz but at ~164KHz?
    Do I have a COGREGS issue?
      Propeller .:.:--TACHYON--:.:. Forth V23131230.0000
    
    MODULES LOADED: 
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200
     
    : TOG  A  #15 APIN #14 BPIN 3 Hz 5 CTRMODE  #10000 ms MUTE ;    
    TOG      / RUNS AT 3 HZ  and quits after 10 seconds
    ' TOG 4 RUN    / RUNS AT ~164 KHz  and quits after 10 secs
    
    Remember that if you test this out in the console cog first that it will set the pins to outputs for that cog so you either have to avoid doing this or reset the pins back to inputs with #15 PININP etc. Also each cog only has a 4 level stack now which might need to be expanded with an external stack, just as the console cog does at startup. This is certainly the case here as there are some calculations made to setup these modes and it looks like the internal stack is overflowing and returning the wrong result.

    To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.
  • D.PD.P Posts: 790
    edited 2014-01-12 17:52
    Remember that if you test this out in the console cog first that it will set the pins to outputs for that cog so you either have to avoid doing this or reset the pins back to inputs with #15 PININP etc. Also each cog only has a 4 level stack now which might need to be expanded with an external stack, just as the console cog does at startup. This is certainly the case here as there are some calculations made to setup these modes and it looks like the internal stack is overflowing and returning the wrong result.

    To avoid an external stack you could optimize the CTRMODE calculation by replacing the $1F #26 SHL with $7C.00.00.00 which should keep your task to within 4 levels In fact I might do this to the source code anyway.

    I was in the code digesting your message and now I find out you have already changed it!

    Tested, working. Moving right along. BTW very nice modules, your puppy's have bones it seems. Thanks for sharing.
  • edited 2014-01-13 18:55
    Hello,

    I am using a Parallax Propeller Quick Start running TACHYON FORTH.

    I would like to do this:


    1. Pin 16 and Pin 17 are both LOW
    2. At time t=0, pin 16 goes HIGH
    3. 5 u-sec elapse
    4. Pin 16 goes LOW
    5. 2 u-sec elapse
    6. Pin 17 goes HIGH
    7. 3 u-sec elapse
    8. Pin 17 goes LOW
    9. At this point, a total of 10 u-sec have elapsed
    10. Now 990 u-sec elapse, and the process repeats

    Thus the two pulses are given 1000 times each second.


    I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.


    Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?


    I like FORTH very much :) Thank you Peter!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-14 00:45
    Hello,

    I am using a Parallax Propeller Quick Start running TACHYON FORTH.

    I would like to do this:


    1. Pin 16 and Pin 17 are both LOW
    2. At time t=0, pin 16 goes HIGH
    3. 5 u-sec elapse
    4. Pin 16 goes LOW
    5. 2 u-sec elapse
    6. Pin 17 goes HIGH
    7. 3 u-sec elapse
    8. Pin 17 goes LOW
    9. At this point, a total of 10 u-sec have elapsed
    10. Now 990 u-sec elapse, and the process repeats

    Thus the two pulses are given 1000 times each second.


    I have successfully used the PWMs to create signals of various frequency and duty-cycle, but I can not figure out how to implement the process described above.


    Is it possible to start counters A and B at the same time? Is it possible to introduce a phase-shift between one and the other? What is the best way to achieve the process I have described?


    I like FORTH very much :) Thank you Peter!


    I wouldn't say that this is the best way to do it but I couldn't resist just converting your steps into Forth code. Obviously you have some small delays of a few microseconds and these would need to be trimmed to account for the instruction timing etc but it gives you an idea. What I would probably be more inclined to do is to have a small PASM module that gets LOADMOD'd just for the fast pulse sequences and then use the WAITCNT loop but try replacing some of the delays with NOPs instead to get your timing. I don't know how critical the timing should be but if it is very critical then a PASM module might be the way to go. When I get to sit down in front of a board I might try some other methods including counter methods.
    [FONT=courier new]( 1. Pin 16 and Pin 17 are both LOW )
        #P16 PINCLR #P17 PINCLR
         #80,000 DELTA        \ 1 ms WAITCNT @80MHz
    ( 2. At time t=0, pin 16 goes HIGH )
        BEGIN
           #P16 PINSET
    ( 3. 5 u-sec elapse )
           5 us
    ( 4. Pin 16 goes LOW )
           #P16 PINCLR
    ( 5. 2 u-sec elapse )
           2 us
    ( 6. Pin 17 goes HIGH )
           #P17 PINSET
    ( 7. 3 u-sec elapse )
          3 us
    ( 8. Pin 17 goes LOW )
           #P17 PINCLR
    ( 9. At this point, a total of 10 u-sec have elapsed )
          WAITCNT        \ synchronized to 1ms interval for precise 1kHz operation
    10. Now 990 u-sec elapse, and the process repeats
    [FONT=courier new]     AGAIN
    [/FONT]
    [/FONT]
    
  • edited 2014-01-14 21:23
    Peter,

    I understand the code you posted, but I could not get it to work correctly.

    I believe that the "us" word messes up WAITCNT.

    I was able to achieve what I wanted to do by using only WAITCNT several times.

    Here is a simplified version of the code you posted:
      Propeller .:.:--TACHYON--:.:. Forth V23131230.0000                 
                                                                                   
    AUTORUN BOOT                                                                   
    MODULES LOADED:                                                                
    306B: sean4th.fth         Some FORTH for Sean 01/13/13                         
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200   
    ----------------------------------------------------------------       
    
    : FT
    
       #16 PINCLR
       
       #80,000 DELTA
    
       BEGIN
          
          #16 PINSET
          #100 us
          #16 PINCLR
          
          WAITCNT
          
       AGAIN
    ;
    
    ' FT 3 RUN
    

    When I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.

    It appears that the "us" word is resetting the value of DELTA.

    If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.


    The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:
    : FT
    
       #16 PINCLR
       
       #20,000 DELTA
    
       BEGIN
          
          #16 PINSET
          WAITCNT
          #16 PINCLR
          WAITCNT
          WAITCNT
          WAITCNT
          
       AGAIN
    ;
    
    

    Also COGSTOP does not seem to work.
      ok
    ' FT 3 RUN  ok
    TASKS 
    0001: CONSOLE                         0000 00 00 00 00 00 00 
    0002: IDLE                            0000 01 00 00 00 00 00 
    0003: FT                              30E2 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                       2738 01 00 00 00 00 00  ok
    
    3 COGSTOP  ok
    
    TASKS 
    0001: CONSOLE                         0000 00 00 00 00 00 00 
    0002: IDLE                            0000 01 00 00 00 00 00 
    0003: FT                              30E2 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                       2738 01 00 00 00 00 00  ok
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-15 00:03
    Peter,

    I understand the code you posted, but I could not get it to work correctly.

    I believe that the "us" word messes up WAITCNT.

    I was able to achieve what I wanted to do by using only WAITCNT several times.

    Here is a simplified version of the code you posted:
      Propeller .:.:--TACHYON--:.:. Forth V23131230.0000                 
                                                                                   
    AUTORUN BOOT                                                                   
    MODULES LOADED:                                                                
    306B: sean4th.fth         Some FORTH for Sean 01/13/13                         
    1800: EXTEND.fth          Primary extensions to TACHYON kernel - 131212-1200   
    ----------------------------------------------------------------       
    
    : FT
    
       #16 PINCLR
       
       #80,000 DELTA
    
       BEGIN
          
          #16 PINSET
          #100 us
          #16 PINCLR
          
          WAITCNT
          
       AGAIN
    ;
    
    ' FT 3 RUN
    

    When I run the above code, I get a 50% duty cycle square wave which is 4.621 kHz. That is, a square wave which is ON for 100 us, then OFF for 100 us.

    It appears that the "us" word is resetting the value of DELTA.

    If I change "#100 us" to "#750 us" I still get a 50% duty cycle square wave, but it is ON and OFF for 750 us.


    The following code gives a wave which is 1.000 kHz; it is on for 250 us and off for 750 us:
    : FT
    
       #16 PINCLR
       
       #20,000 DELTA
    
       BEGIN
          
          #16 PINSET
          WAITCNT
          #16 PINCLR
          WAITCNT
          WAITCNT
          WAITCNT
          
       AGAIN
    ;
    
    

    Also COGSTOP does not seem to work.
      ok
    ' FT 3 RUN  ok
    TASKS 
    0001: CONSOLE                         0000 00 00 00 00 00 00 
    0002: IDLE                            0000 01 00 00 00 00 00 
    0003: FT                              30E2 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                       2738 01 00 00 00 00 00  ok
    
    3 COGSTOP  ok
    
    TASKS 
    0001: CONSOLE                         0000 00 00 00 00 00 00 
    0002: IDLE                            0000 01 00 00 00 00 00 
    0003: FT                              30E2 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                       2738 01 00 00 00 00 00  ok
    

    My bad, I did this away from my system so I just did a quick code of it but yes, the us and ms both use DELTA so that won't work just like that. Sometimes for small delays it's better just to use some dummy instructions instead of the small delays and then just use WAITCNT for the 1kHz timing.

    COGSTOP only stops the cog itself and effectively freezes the process so this can still show up in the task list. Normally once a task is started it is left to run unless it exits back to the IDLE loop.I may do some more work on this at least to make the TASK list reflect what's going on a bit better, it's just a simple listing really.
  • edited 2014-01-16 14:52
    Fast Pulse Generation in TACHYON FORTH

    This code will produce two 1 us pulses, once every milisecond.

    When I make just one pulse this way, it appears to be 1 us (or less) on the scope.

    This code makes two pulses with a short delay between them. Together, they seem to fit within a 2 us division on the scope.
    : FOUNTAIN 
     
    $FFFF_FFFF $1F6 COG!   \ set pins as outputs
    
    #80_000 DELTA   \ WAITCNT every 1 ms
     
    BEGIN
       $0000_0000 $1F4
       $00FF_0000 $1F4
       COG! COG!
       
       $0000_0000 $1F4
       $00FF_0000 $1F4
       COG! COG!
       
       WAITCNT 
    AGAIN 
    ; 
    
    

    If you want longer pulses, you can put some NOP's between the two COG!

    If you want longer delay between the two pulses, put some NOP's after the first two COG!

    I hope this is useful to someone (like me) who needs to do some precise timing :)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-17 05:17
    Fast Pulse Generation in TACHYON FORTH

    This code will produce two 1 us pulses, once every milisecond.

    When I make just one pulse this way, it appears to be 1 us (or less) on the scope.

    This code makes two pulses with a short delay between them. Together, they seem to fit within a 2 us division on the scope.
    : FOUNTAIN 
     
    $FFFF_FFFF $1F6 COG!   \ set pins as outputs
    
    #80_000 DELTA   \ WAITCNT every 1 ms
     
    BEGIN
       $0000_0000 $1F4
       $00FF_0000 $1F4
       COG! COG!
       
       $0000_0000 $1F4
       $00FF_0000 $1F4
       COG! COG!
       
       WAITCNT 
    AGAIN 
    ; 
    
    

    If you want longer pulses, you can put some NOP's between the two COG!

    If you want longer delay between the two pulses, put some NOP's after the first two COG!

    I hope this is useful to someone (like me) who needs to do some precise timing :)

    That code looks all wrong as you are setting ALL the port pins to outputs plus you don't have to explicitly set any pins as outputs as the OUTSET and OUTCLR instructions already take a mask for this purpose, set or clear those pins and make sure the pin is an output. Even so the timing is much longer than 2us as a literal pushed to the stack plus just one OUTxxx instruction can take from 2.4us (fast literal) to 4.8us (user constant).

    Writing directly to the DIR and OUT registers using cog addresses is slow and inefficient and unnecessary. I will look at some code that will give you precise timing (measured) and let you know.

    EDIT: Here's some tested code that produces 5us high then a 2.4us gap then 3us high at 1kHz
    [FONT=courier new]#P16 |< == P16
    #P17 |< == P17
    P16 P17 OR == P1617
    
    : FOUNTAIN
       P1617 OUTCLR
       #80,000 DELTA
       P16 P17                                 \ setup port masks on stack for faster access
       BEGIN
         OVER OUTSET 8 DROP OVER OUTCLR        \ 5us hi
                                               \ 2.4us gap
         DUP OUTSET NOP ?DUP OUTCLR            \ 3us hi
         ESC? IF EXIT THEN                     \ allow an escape back to the console
         WAITCNT
       AGAIN
       ;
    [/FONT]
    
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-01-21 04:48
    Some of you may have been using the countdown timers that are built into EXTEND.fth that run in their own cog. Some changes have been made to improve integration with modules as previously a fixed table of 8 counters were assigned and a module would be assigned one or more manually. I then tried a dynamic assignment method a week ago but I wasn't all that happy with it so I have now scrapped the fixed table approach and introduced a linked timer method. Initially no timers are assigned but as soon as a "timer" address is passed to TIMEOUT then this is linked into the timer list and maintained accordingly. Normally these timers are simple countdown to zero and execute an ALARM condition if set or else do nothing style counters but they can now also be set to up-count as well.

    As with before there are 8 bytes required for each timer and they are:
    timer value (4)
    alarm (2)
    link (2)

    DOUBLE timer1

    To startup (and link) a timer it is the same as retriggering it:
    #1000 timer1 TIMEOUT

    So there is no need to specially link in the new timer as TIMEOUT will check this. You can use as many timers as would be practical.but now you specify the variable/address to use, that's it.
    Here's a quick test of it in operation:
    [FONT=courier new][B]DOUBLE timer1[/B]  ok
    [B]DOUBLE timer2[/B]  ok
      ok
    [B]-1 timer1 TIMEOUT[/B]  ok
    [B]-1 2/ timer2 TIMEOUT[/B]  ok
    [B]TIMERS?[/B]  ticks = 1/1000
    30B4: timer2              =7FFF.FFEC L30A8 
    30A8: timer1              =FFFF.FFD0 L0001  ok
    [B]DOUBLE lockout[/B]      ok
    [B]#10,000 lockout TIMEOUT[/B]  ok
      ok
    [B]TIMERS?[/B]  ticks = 1/1000
    30C0: lockout             =0000.02C0 L30B4 
    30B4: timer2              =7FFF.DB66 L30A8 
    30A8: timer1              =FFFF.DB49 L0001  ok
    [/FONT]
    
  • nglordinglordi Posts: 114
    edited 2014-01-22 11:11
    I have posted a TACHYON based robot control language in the Robotics forum. I include the RCL Core here for comment.

    pub  BOEPAB.fth   ." TACHYON Robot Control for BOE Platform & Prop Activity Board "   ;
    
    {
     Motor drivers and utilities.
    }
    
    #P12 2 MASKS  ==  pwmpins
    
    #1495 #80 * == ld0  \ sets zero position of left servo
    
    #1504 #80 * == rd0  \ sets zero position of right servo
    
    LONG lduty, rduty
    
    pub .duty ( -- ) \ displays current right & left duties
        lduty @ . SPACE rduty @ . CR ;
    
    pub M1 ( duty -- ) \ sets left servo duty: -1000 - 1000
      #10 * ld0 + lduty !  ;
    	
    pub M2 ( duty -- ) \ sets right servo duty: -1000 - 1000
      NEGATE #10 * rd0 + rduty !  ;
    
    pub S ( -- ) \ abruptly stops bot motion 
        0 M1  0 M2  ;
    
    pub D1 ( -- )  \ toggles left wheel direction
        lduty @ ld0 - NEGATE ld0 + lduty ! ;
    
    pub D2 ( -- )  \ toggles right wheel direction
        rduty @ rd0 - NEGATE rd0 + rduty ! ;
    
    pri rc_motors ( -- ) \ left and right servo pwm drivers
        pwmpins OUTCLR  S
        A NCO #P12 APIN  1 FRQ 0 PHSA COG!
        B NCO #P13 APIN  1 FRQ 0 PHSB COG!    
        BEGIN
          lduty @ NEGATE PHSA COG!
          rduty @ NEGATE PHSB COG!
    
          20 ms
        0 UNTIL  ;
    
    pub MSTART  ( -- ) \ executes servo drivers in a cog
        ' rc_motors TASK? RUN  50 ms  ;
    
     
          
    {
      Encoders record current total counts per wheel. 
    }
    
    #P14  2 MASKS  ==  encpins
    
    LONG lenc, renc, xl, xr
    
    pub .enc ( -- ) \ lists current  encoder counter values
        lenc @  . SPACE  renc @ . CR ;
    
    pub zenc ( -- ) \ set left and right encoder counters to 0
        0 lenc !  0 renc !  ;
    
    pri rc_enc ( -- ) \ simple encoder drivers based on basic stamp boebot program
        TRUE xl ! TRUE xr !  encpins INPUTS  zenc 
        BEGIN
          #P14 PIN@ DUP xl @ = IF DROP ELSE xl ! lenc ++  THEN
          #P15 PIN@ DUP xr @ = IF DROP ELSE xr ! renc ++  THEN
        0 UNTIL ; 
     
    pub ESTART  ( -- ) \ executes encoder drivers in a cog
         ' rc_enc TASK? RUN 50 ms ; 
    
    {
     Ping ultrasonic distance measurement (inches).
    }
    
    #1400 == p0   \ sets standard servo 0 position
    #8 == dist?   \ sets ping stop condition in inches
    
    LONG (dist), pos
    
    pub !pos  ( angle -- ) \ where angle is -90 - 90 degrees (right to left)
       #10 * p0 + #80 * pos !  ;
    
    pub dist ( -- value ) \ places current ping value (inches) on stack
        (dist) @ ;
    
    pub .dist ( -- ) \ displaces current ping value (inches)
        dist . CR  ;
    
    BYTE (stp)  \ stores stop flag
    
    pub restp ( -- ) \ resets stop flag to TRUE
        TRUE (stp) C!  ;
    
    pub stp ( -- flag ) \ places stop flag on stack
        (stp) C@  ;
    
    pri rc_ping ( -- ) \ ping driver - automatic stop condition 
       #P17 PINCLR 0 !pos
       B #P17 APIN  NCO  1 FRQ
       A 1 FRQ
       BEGIN
         #P16 PINCLR
         A #P16 APIN NCO #400 NEGATE PHSA COG!
           #1000 CTRMODE 0 PHSA COG! #P16 PININP
         pos @ NEGATE PHSB COG!
         50 ms
         PHSA COG@ #11800 / DUP (dist) !
         dist? < stp  AND IF
            FALSE (stp) C! S THEN 
       0 UNTIL  ;
      
    
    : PSTART  ( -- ) \ executes ping driver in a cog
       restp ' rc_ping TASK? RUN 50 ms ;
    
    {
      User parameters.
    }
    
    
    \ user constants - 2.625 inch wheel diameter  4.312 inch between wheels
    
       #8   ==   wcirc   \ wheel circumference in inches
     
      #64   ==   counts  \ number of counts per wheel rotation
    
       #8   ==   ctin    \ counts per inch
     
     #136   ==   rcirc  \ rotation circumfirence in 0.1 inch units
    
     #271   ==   tcirc  \ turn circumfirence in 0.1 inches
    
    pub R  ( -- )  \ hardware reset - execute START to continue
        #P9 PINCLR  ;
    
    pub START
        MSTART  ESTART  PSTART  DECIMAL ;
    
    
    
    {
    ********************************************************************************
    This completes the RCL Core.    
    
    Simple (indefinite) motion commands, which use indexed tables to select duties.
    }
    


    NickL
Sign In or Register to comment.