Understanding 20X2 timers

[cpedw]

I'm trying to find how independent the timers are in a 20X2. In particular, are TIME, TIMER and TIMER3 unrelated in their timekeeping? I think I have got to grips with SETTIMER and TMR3SETUP commands.

My application is a POV display. I plan to have a Hall effect pulse each rev then 120 rotational pixels per rev. So I need to time 1/120 of a rev to control the output but also I must measure the time of 1 rev to allow for motor speed changes. At the moment, I'm thinking of using TIMER and TIMER3 for these 2 roles. Or has a better way been described?

Derek

 

[oracacle]

you could use either, I have used timer to measure the time between 2 input in the past.
Something to note is setting the period value above about 65525 can cause issues with execution time.

I would be tempted to leave the timer running and just read and reset in an interrupt for each rotation
Another problem you may face is execution time of maths, which can also effect the resolution you get. Needless to say all this is going to depend on the expected RPM range you plan on measuring. I would be helpful if you could supply a little more information about the project, in particular how things ate going to be read - is it one hall affect and 120 'detents' on the spinning object.

thinking about it, depending on the application, fast nested loop maybe a better way of doing it

setfreq m8
symbol detent_count = b0
symbol rpm_time  = b1
detent_count = 0
rpm_time = 0
bptr = 56     'store 1/120 times above normal variables
main:
settimer count 65525   'overflow ever 320us
timer = 0   
do
  do while pinb.0 = 0 'hold here until another input detected
  loop
  inc detent_count
  @bptrinc = timer  'store 1/120 intervals
loop while b0 <120
let rpm_time = timer
'due to the timer being left running each of the 120 times are incremental and shold have their differences calculated
'at 120 count drop troung and toflag contains total time of a single rotation
'sertxd data, debug stops timer from running so may cause issues
goto main    'loop forever

 

[inglewoodpete]

I'd be upping the speed to SetFreq m64, since it is easily done with a 20X2. This allows 8 times more commands to be executed (than m8) and can also allow time increments to be measured with improved resolution.

 

[oracacle]

I used m8 as I was unsure if there was something that needed that clock speed, ie the display. But yes I agree m64 would be better on regards to resolution and command execution

 

[cpedw]

I would need to upsize to a 28X2 to use COUNT wouldn't I?

The speed will be 30 rev/s, just one pulse per rev - input to the controller. The controller must supply 120 signals per rev to the display, based on the previously measured rev period.

The rev period to be measured is 33 millisec and control signals are needed at 278 microsec.

Because the current plan has a 20X2 doing all the display work (driving APA102s) I am considering outsourcing the speed measure/pulse control to an 8M2 that is doing nothing else, for simplicity. I think timer1 may be best suited in this case. Does that sound reasonable?

Derek

 

[hippy]

The speed will be 30 rev/s, just one pulse per rev - input to the controller. The controller must supply 120 signals per rev to the display, based on the previously measured rev period.

The rev period to be measured is 33 millisec and control signals are needed at 278 microsec

You can fairly easily determine the time for one revolution to 1us resolution simply by clearing the timer on one trigger, incrementing at a 1us rate, and reading what that has reached at the next trigger. The result will be 0-65535us, so no overflow risk.

You can increment the timer every 500ns to double your resolution. There will be a wrap-round zeroing of the timer after 32768us but that's easy to handle because you can be sure >= $8000 and the time is between 16384us and 32767us, and when it's < $8000 it has wrapped-round and is 0+32768us to 16383+32768us.

       $0000  $8000  $0000  $8000
        ______ ______ ______ ______
Timer  |______|______|______|______|

31ms   |--------->| | | |
32ms   |----------->| | |
33ms   |------------->| |
34ms   |--------------->|

But what I am not clear about is how you are going to accurately output T/120 rate pulses, or how you are going to achieve consistent latency in using those.

If, because of PICAXE command timings, things are going to drift about by +/-10us per tick, you might be better off simply generating a fixed tick rate and not worry about what the actual revolution time is. You might be creating more 'wobble' than there is in the actual motor speed.

 

[AllyCat]

Hi,

I would need to upsize to a 28X2 to use COUNT wouldn't I? ..............
I am considering outsourcing the speed measure/pulse control to an 8M2 that is doing nothing else, for simplicity. I think timer1 may be best suited in this case. Does that sound reasonable?

COUNT is a PICaxe Basic "blocking" command, so the PICaxe cannot do anything else during the measurement. Therefore, generally PULSIN is preferred (and can give much higher resolution) but you have to consider that it's measuring the time between "edges" of opposite polarity, not a full revolution.

In M2s, "Timer 1" is used by the Operating System, "ticking" at 1 MHz (with a 4 MHz clock) and overflowing every 20 ms. However, it can be used for other purposes and the on-chip "Timer 1 Gate" hardware may be useful, for example measuring the time between edges of the same polarity (i.e. one exact revolution). If you don't want to dig deeply into the 08M2 "base PIC" data sheet, then I might be able to find a few of the posts I've written on the topic.

Cheers, Alan.

 

[hippy]

The rev period to be measured is 33 millisec and control signals are needed at 278 microsec.

Because the current plan has a 20X2 doing all the display work (driving APA102s)

I would assume form that description this is some sort of propeller clock using APA102 for the LED's.

How many LED's do you actually have ? If it's 8 then you will need to have sent 40 bytes, 4 for head, 4 per LED, 4 for tail in that 278us period. That would mean a byte being sent every 6.9us, a baud rate around 1.5 Mbps.

It might help to explain exactly what you are trying to achieve as that might shed light on whether it is possible and how best to do it.

 

[cpedw]

Hi,

COUNT is a PICaxe Basic "blocking" command, so the PICaxe cannot do anything else during the measurement. Therefore, generally PULSIN is preferred (and can give much higher resolution) but you have to consider that it's measuring the time between "edges" of opposite polarity, not a full revolution.

In M2s, "Timer 1" is used by the Operating System, "ticking" at 1 MHz (with a 4 MHz clock) and overflowing every 20 ms. However, it can be used for other purposes and the on-chip "Timer 1 Gate" hardware may be useful, for example measuring the time between edges of the same polarity (i.e. one exact revolution). If you don't want to dig deeply into the 08M2 "base PIC" data sheet, then I might be able to find a few of the posts I've written on the topic.

Cheers, Alan.

The COUNT I wrote is the adjunct to SETTIMER described by oracacle.

I have seen one or two posts on timer 1 gate but failed to understand them. A pointer to a primer on the topic would be appreciated.

Derek

 

[cpedw]

I would assume form that description this is some sort of propeller clock using APA102 for the LED's.

How many LED's do you actually have ? If it's 8 then you will need to have sent 40 bytes, 4 for head, 4 per LED, 4 for tail in that 278us period. That would mean a byte being sent every 6.9us, a baud rate around 1.5 Mbps.

It might help to explain exactly what you are trying to achieve as that might shed light on whether it is possible and how best to do it.

My plan uses 16 APA102 LEDs so that's worse, 72 per 278us so 3.86us per byte- I think about 2Mbps? Will a 20X2 running at 32 or 64 MHz be able to cope?

Derek

 

[hippy]

I have seen one or two posts on timer 1 gate but failed to understand them. A pointer to a primer on the topic would be appreciated.

There's not really a primer to be had for the PICAXE. Gated timers/counters are simply ordinary timers/counters which have an AND gate in front of them so clock pulses are counted when enabled, not counted when disabled.

As far as I can recall the gating can be enabled and disabled in software, or controlled by an external input pin, and there is a one-shot mode which enables the gating to only be enabled during the first pulse which is seen.

The X2 PICAXE's supports a free-running SETTIMER timer or an externally clocked SETTIMER COUNT counter. Gate control, one-shot, and anything fancy has to be setup by twiddling the control bits using PEEKSFR and POKESFR.

Timer1 Gate - Developer Help

microchipdeveloper.com

My plan uses 16 APA102 LEDs so that's worse, 72 per 278us so 3.86us per byte- I think about 2Mbps? Will a 20X2 running at 32 or 64 MHz be able to cope?

I wouldn't expect it to. The UART hardware can handle up to 4Mbps at 32MHz but the PICAXE code won't be able to run quickly enough to keep data flowing at the necessary rate.

I recall the rule of thumb 'per token' time is about 8us at 64MHz and, even with all bytes being output in a single HSEROUT that would still be too slow.

 

[AllyCat]

Hi,

I think about 2Mbps? Will a 20X2 running at 32 or 64 MHz be able to cope

No, I think you're probably at least an order of magnitude adrift for a PICaxe. Seems like you need Assembler or hand-crafted Compiler if using only an 8-bit microcontroller.

I don't use X2s, but the fastest data transfer from RAM that I can think of is a linear block of POKESFR xxx , @BPTRINCs which (extrapolated from my M2 measurements) should execute in about 40us at 64 MHz (and you may need to work around the "bptrinc double-incrementing bug).

But also, if you want 120 segments of 72 bytes, that's 8,640 Bytes, AFAIK well beyond that accessible in any PICaxe. And when/how do you plan to update the contents of the display RAM?

Cheers, Alan.