hi
i got this error when i try to convert my miliseconds (ms) to microseconds (us).
i am using 16f628a with 4 mhz external xtall osc for driving a step motor on single arm isosceles barn door.
i had 2 problems when i changed my step motor from 48 steps to 4096 steps.
1- a simple calculation shows i need ~20.5 ms for 4096 stepper instead of 1750 ms for the 48 stepper (1750*48/4096). but i figured out even 21 ms is too fast, then i found my sweet spot ~36 ms. i don't know why the math doesn't work.
2- i wanted to do more precise timing by using us as the unit. when us failed at compilement then i tried 10us unit. it works but, again, too much faster (~10 times!)
so it seems 36 ms is not equal 3600 10us or it is?
btw if 4 mhz is not enough for microsecond resolutions what mhz needed?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Things must have changed a bit between what your compiler edition is, to what I'm using now. 0.9 22/9/2013. It is now opposite of what i remember as it allows word size variables for for "wait us", and bytes size for "wait 10us". I would update to 22/9/2013.
Didn't have a 16f628A, but tested with a 16f648A, and everything O.K. I got 50Hz and width of 19.99ms with DMV. Test code:
'Set chip model:
#chip 16F648A, 4
#config OSC=XT
#define led PortA.0
Dir led Out
Start:
Set led ON
Wait 20000 us
Set led OFF
Goto Start
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reread the OP and missed it. Word variable for "wait 10us" isn't allowed, as far as Help file is concerned. Indeed using say 2000 (word variable) is truncated to 200 (byte variable) or 10 times faster clock. No error is generated by the compiler, but should.
Ooops, my example above is using a Word constant for "wait us", my bad.
Tried a 12Mhz, it worked, so 12Mhz and up it looks like. 8 Mhz gives a compiler error, like the 4 Mhz, for variable us delays.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem here is that it takes (from memory) about 7 clock cycles to decrement and check a word variable. If you have a 4 MHz clock, this will take 7 us to run - which adds quite a bit of time to the 10 us delay. That's an even worse problem with the 1 us delay units. When you have a constant length delay (like 20000 us in Kent's example), the compiler will produce a delay of exactly the right length using loops and nop instructions. But when the length of the delay is specified in a variable, the compiler can't do any tricks like that. So instead, it generates code that will at least work to some extent, and displays that warning so you know to expect strange things.
As clock speeds increase, the error becomes less and less significant. At 12 MHz and above, there shouldn't be a noticeable problem.
Possible solutions are
- Replace the 4 MHz crystal with one at 12 MHz or higher (I would suggest a 20 Mhz one)
- Somehow hard code the delay length
- Put a 100 us delay inside a repeat 36 (or whatever is appropriate) loop.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Hugh,
first, i tried to replace crystal with 20mhz one. that was a big mistake for me because i am really bad at soldering :(
however finally i tried on breadboard and the pic didn't work with the 20 mhz. i don't have any other faster xtall to try so i re-replaced 4mhz and it is ok now. btw: i had 22pF capacitors, i tried 10pF but i got same results.
hardcoding maybe possible but it is far from ideal solution.
i don't know how to code for example 36500 us. 100 us delay x 365 times repeat? or 10 10us x repeat 365 or 250 us x repeat 146?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi
i got this error when i try to convert my miliseconds (ms) to microseconds (us).
i am using 16f628a with 4 mhz external xtall osc for driving a step motor on single arm isosceles barn door.
i had 2 problems when i changed my step motor from 48 steps to 4096 steps.
1- a simple calculation shows i need ~20.5 ms for 4096 stepper instead of 1750 ms for the 48 stepper (1750*48/4096). but i figured out even 21 ms is too fast, then i found my sweet spot ~36 ms. i don't know why the math doesn't work.
2- i wanted to do more precise timing by using us as the unit. when us failed at compilement then i tried 10us unit. it works but, again, too much faster (~10 times!)
so it seems 36 ms is not equal 3600 10us or it is?
btw if 4 mhz is not enough for microsecond resolutions what mhz needed?
Things must have changed a bit between what your compiler edition is, to what I'm using now. 0.9 22/9/2013. It is now opposite of what i remember as it allows word size variables for for "wait us", and bytes size for "wait 10us". I would update to 22/9/2013.
Didn't have a 16f628A, but tested with a 16f648A, and everything O.K. I got 50Hz and width of 19.99ms with DMV. Test code:
Reread the OP and missed it. Word variable for "wait 10us" isn't allowed, as far as Help file is concerned. Indeed using say 2000 (word variable) is truncated to 200 (byte variable) or 10 times faster clock. No error is generated by the compiler, but should.
Ooops, my example above is using a Word constant for "wait us", my bad.
Tried a 12Mhz, it worked, so 12Mhz and up it looks like. 8 Mhz gives a compiler error, like the 4 Mhz, for variable us delays.
The problem here is that it takes (from memory) about 7 clock cycles to decrement and check a word variable. If you have a 4 MHz clock, this will take 7 us to run - which adds quite a bit of time to the 10 us delay. That's an even worse problem with the 1 us delay units. When you have a constant length delay (like 20000 us in Kent's example), the compiler will produce a delay of exactly the right length using loops and nop instructions. But when the length of the delay is specified in a variable, the compiler can't do any tricks like that. So instead, it generates code that will at least work to some extent, and displays that warning so you know to expect strange things.
As clock speeds increase, the error becomes less and less significant. At 12 MHz and above, there shouldn't be a noticeable problem.
Possible solutions are
- Replace the 4 MHz crystal with one at 12 MHz or higher (I would suggest a 20 Mhz one)
- Somehow hard code the delay length
- Put a 100 us delay inside a repeat 36 (or whatever is appropriate) loop.
thanks both of you
@Hugh,
first, i tried to replace crystal with 20mhz one. that was a big mistake for me because i am really bad at soldering :(
however finally i tried on breadboard and the pic didn't work with the 20 mhz. i don't have any other faster xtall to try so i re-replaced 4mhz and it is ok now. btw: i had 22pF capacitors, i tried 10pF but i got same results.
hardcoding maybe possible but it is far from ideal solution.
i don't know how to code for example 36500 us. 100 us delay x 365 times repeat? or 10 10us x repeat 365 or 250 us x repeat 146?
i changed all timing variables to byte and used 190 us as base then my problem solved.
...
dim times as byte
times = 194
...
repeat times
wait 190 us
end repeat
thanks a lot