So many counters just sitting there

T Chap

I wish there was a way to launch a counter in any cog, and update any parameter of any counter without having to pass addresses to the cog(s) on launch as well as having to have code running inside of every cog looking for updates. For example, a serial object is sitting waiting on data, it cannot be doing something else, yet it has two counters idle that I could sure make use of for PWM/DAC etc. What would be nice is some method to access the counter via a register and update the counter the same way without having to compromise the code that is in the cog.

evanh

If the counter doesn't function exactly how you want it to then it's worse than having just plain RAM. Programmable logic and bit-bashing are the two general solutions around this problem. The Prop excels at bit-bashing through the use of multi-core. It works well but obviously is limited to the eight cogs.

Prop2 is bringing in extended support for multitasking but this might be quite difficult to use with I/O level realtime processing. Anyone got views on this?

kwinn

Perhaps it could be done in a manner similar to what the quad serial object does to give us four serial ports using a single cog. A co-routine to access and control the cog counters from hub ram.

Dr_Acula

For example, a serial object is sitting waiting on data, it cannot be doing something else

For a serial object if you keep the checking loop fast and small you should be able to do other things. You just want to make sure that you don't miss too much of the start pulse - eg your loop needs to be under maybe 5% of the width of the start pulse.

So your main loop in the cog would check for changed values in some hub locations (one or several), then check if a pin has changed.

If a byte is coming in a serial port, probably best to complete that task first (although as pointed out above, the 4 port serial driver is able to handle 4 ports at the same time. Very clever code). If the cog is idle, then it can be multitasking all sorts of things. Just need to work out the priorities and the timing and the maximum allowable delays within each task.

Phil Pilgrim (PhiPi)

Dr_Acula wrote:

For a serial object if you keep the checking loop fast and small you should be able to do other things. You just want to make sure that you don't miss too much of the start pulse - eg your loop needs to be under maybe 5% of the width of the start pulse.

It's not even that stringent. A polling rate of three times the baudrate is all you need to sync on a start bit and receive an incoming character reliably.

-Phil

pjv

Hi TChap;

What you suggest is very do-able...... 'been doing it for years!

Although my purpose is not specifically to make use of idle counters, I use the spare time in a Cog to simultaneously run other assembly programs. It could be possible for my Multi-Tasking OS to hand back a a long to a hub location every 10-ish usec while the Cog continues to run its assembly programs.

For more infromation, search the Parallax site for "previous contests" of a few years ago where I demonstrate the concepts, post code and give explanations. I think it was called a Multi-Threaded RTOS or something like that.

@Phil... that's exactly what I use.

Cheers,

Peter (pjv)

SRLM

T Chap wrote: »

I wish there was a way to launch a counter in any cog, and update any parameter of any counter without having to pass addresses to the cog(s) on launch as well as having to have code running inside of every cog looking for updates. For example, a serial object is sitting waiting on data, it cannot be doing something else, yet it has two counters idle that I could sure make use of for PWM/DAC etc. What would be nice is some method to access the counter via a register and update the counter the same way without having to compromise the code that is in the cog.

I'm working on an object right now (literally! this is my programming break) that is a modified FDS+. This object waits for a byte to be received, and then it processes it. The serial port is running at 115200 baud, and it's reliable. I can get maybe 30 instructions in between bytes before it starts to hiccup. If you're interested in taking a look I'll be posting it sometime in the next week or so.

T Chap

It is easy to switch to ser.rxtime(1) and the next line updates frqa for example. This does a decent job of handling a counter. But it is not ideal. Increasing the wait can all but guarantee you will not miss something that comes in on the data input, but the frqa update line will surely miss some updates.. which is not that critical I suppose but the solution is still makeshift.

pub ramp 
   x~
   repeat while x < 2_000_000_000
     x := x + 100_000
      

pub serialmethod(y)   |  i
   i :=  ser.rxtime(1)
   if i == -1
      frqa := long[y]   ' update from the pointer

This example will pick up most of the updates, and most likely missing an update here or there will not be noticed if there is no data in. However this is an easy example, some examples are not this straight forward. What is needed is direct access to the counter and parameters by a register address through a back door. Adding locks or variables as psuedo locks can force the main loop to wait before updating again, and avoid missing any updates, but then if some data comes in and the serial method has to drop everything to parse and handle commands, the main method loop can be locked for a while, and the locks will require time out code.

So the answer is, in some cases you can multitask a data-in method while updating a counter, others maybe not. If the sole purpose of the counter is ramping a DAC in a timing specific task, then what when the serial method has to act on a command that takes some time? Keep adding the frqa := code throughout the serial method including it's own sub methods?