Shop OBEX P1 Docs P2 Docs Learn Events
cogstop question — Parallax Forums

cogstop question

mikeamikea Posts: 283
edited 2013-02-24 10:43 in Propeller 1
Is there a way to use cogstop and have it pick up where it left off rather than starting it with cognew and beggining at the top of the code? The main code gets gps data and sends it to an lcd. There are a lot of pauses so theres another cog to jump in and take over the lcd momentarily so i need to pause the first cog off without losing its place. Any suggestions would be great.thanks-mike

Comments

  • kwinnkwinn Posts: 8,697
    edited 2013-02-23 09:42
    Cogstop will not work for that, but you could have a routine where the cog monitors a location in hub ram and pauses or goes into an idle loop when that location has a specific value (the stop value). By calling that routine from various parts of the cog program it could go into the idle loop, monitor the hub location, and continue execution once the value changes to something other than the stop value.
  • MagIO2MagIO2 Posts: 2,243
    edited 2013-02-23 09:52
    COGSTOP is final!

    Is the LCD a serial LCD or a 4/8bit parallel LCD?
    If it is a parallel, do you have a chip-select or is the CS connected to "ALWAY SELECTED"?
    If it is a real CS you could use the CS to see if the other COG is finished with writing to the LCD. You could use waitpeq/waitpne instructions to set the COG into "sleep"-mode until CS changes.

    If you don't have a real CS and/or you don't have a parallel LCD you could also use another pin to synchronize both COGs.

    Another way would be to use a HUB-RAM location to send instructions from one COG to the other. For example there could be messages like SUSPEND and RESUME. In case of SUSPEND the COG could simply run a waitcnt-loop until it finds the RESUME instruction. (Instead of HUB-RAM you could also use the LOCKs available in the Propeller)

    All waitxxx instructions will reduce power-consumption in the COGs. The difference in the 2 methods (use waitpne/waitpeq versus waitcnt) is, that waiting for a pin-change will immediately react but it needs a pin. The waitcnt will only react within the time you have chosen as waittime. So, depending on the requirements it might be good enough.
  • mikeamikea Posts: 283
    edited 2013-02-23 09:53
    Thanks Kwinn. Are you saying to have checkpoints like an "if" statement in the main code between the pauses.
  • mikeamikea Posts: 283
    edited 2013-02-23 10:04
    Thanks MagIO2, it's a serial lcd. The lcd shows longitude, latitude, speed,date,ect. I would like it to only display speed while a pushbutton is held down and resume the whole list of data when its released. The main code is pretty long so i was hoping to not have to add conditional statements between all the waitcnt's that are there for time to read the display. When using hub-ram location does that happen through global variables?
  • JonnyMacJonnyMac Posts: 9,108
    edited 2013-02-23 10:43
    You could use a flag (global variable). When you want the LCD to be updated, set that flag to true. In the LCD cog it will wait for the flag to go true, immediately change it to false, then display the values. I just did this today with a program that updates a monitor screen (which runs in its own cog), but only after values have arrived.
  • MagIO2MagIO2 Posts: 2,243
    edited 2013-02-23 11:02
    Well ... things usually become much easier when you operate thing which belong together just from one COG. In this case I'd propose to have one COG dedicated to the user interface, the LCD and the pushbutton. All COGs that gather data as long/lat, speed ... will store the results in some global memory also known by the UI COG. That's it! The UI can autonomously choose which data to show. The other COG do not even need to know and definitely do not need to care about timings.
  • Mark_TMark_T Posts: 1,981
    edited 2013-02-23 14:32
    Sounds like you want to use a lock to manage the LCD resource - every cog wanting to use the LCD should claim
    the lock first, and release it after drawing to avoid hogging it. Other global hub variables can signal when the LCD
    has been overwritten so each cog knows how much to redraw after reclaiming the lock.
  • kwinnkwinn Posts: 8,697
    edited 2013-02-24 10:43
    mikea wrote: »
    Thanks Kwinn. Are you saying to have checkpoints like an "if" statement in the main code between the pauses.

    I was thinking more along the line of a call to a subroutine that checks a shared variable for a stop command. When the subroutine sees the stop command it goes into a continuous loop that checks the shared variable and returns to the next instruction or a specific location when a new command is written into the shared variable by another cog.
Sign In or Register to comment.