Hi,
I had many requests about pic timers, so that I wrote a little C example to show how to make multiple non-blocking asynchronous delays with only one pic timer :
Comments & questions are welcome
Bruno
Hi,
I had many requests about pic timers, so that I wrote a little C example to show how to make multiple non-blocking asynchronous delays with only one pic timer :
Comments & questions are welcome
Bruno
good grief 1600+ bytes for 2 little delays! if i'de written that I wouldn't ever publish it. You should be able to get the guts of this down to 50 bytes at most maybe half that with some effort.
a écrit dans le message de news: snipped-for-privacy@e56g2000cwe.googlegroups.com...
Hi, thanks for having a look at it.
this code is intended for beginners, and shows the way to handle interrupts with mikroC. it surely won't help you if you are an experienced programmer.
by the way, I would be curious to see a 50 bytes program that will do the same. So don't be shy and post your C code. it will have to do the same :
- user-configurable numbers of delays
- user-configurable pointers to end of countdown function
- user-configurable delays in ms for each countdown
- non-blocking delays
- asynchronous delays
- only one timer used
Bruno
an
Thanks for reply, but please do not compare C code with ASM code, PIC code and 8051 code, and two different applications !
Your code is surely efficient in its categorie, which is different than mine.
Bruno
It shows how to way to handle an interrupt.
agreed
.In the ISR all you need is
dec time1lowbyte if zero set time1flag dec time2low byte if zero set time2flag
thats about 6 instructions
In your main idle loop ie. where your for{;;} is
test time1flag if set clr time1flag dec time1high byte if zero do whatevertime1
test time2flag if zero clr time2flag dec time2high byte if zero do whatevertime2
thats about 8 instructions
All you have to remember is that when you load the time values the high byte needs to be incremented by 1.
On 5 Mar 2006 03:42:20 -0800, snipped-for-privacy@aol.com wrote:
LMAO, this is what happens when software people play with hardware, HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA cough!!
a écrit dans le message de news: snipped-for-privacy@i39g2000cwa.googlegroups.com...
Ok that's enough, I can't push you to post a real code in a known language. I think even beginners have now made their mind.
Bruno
maxfoo wrote: snip
Oh, shit! Bird Flu.
Ian
the
e :
e=2E
html
I dont have the spare time to write, compile and debug code just for you. If you cant see how simple your code should have been then you need to find another occupation.
a écrit dans le message de news: snipped-for-privacy@t39g2000cwt.googlegroups.com...
Sure you will not have enough time, eternity will not be long enough to rewrite this within 50 rom bytes.
This example is written for 2 delays, but it can handle up to 255 delays with the same rom size (1690 bytes) just changing the #define directive. I added a comment in the source code to notice it to beginners, thanks.
Bruno
If you liked that, you should see the mess that hardware experts make when they try to write software. ;-)
"BrunoG" schreef in bericht news:440b8053$0$20177$ snipped-for-privacy@news.wanadoo.fr...
This is probably what eats most of the 1676 bytes:
unsigned long d d /= 1000 ; // divide by 1000 because d /= (long)Clock_Khz() ; // clock frequency is known in Khz
And these lines only add a bit of convenience... would be nice to see how many bytes you need without these lines.
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
"Frank Bemelman" a écrit dans le message de news: 440c3b75$0$6581$ snipped-for-privacy@dreader30.news.xs4all.nl...
Yes sure, long div is costly, as well as struct members and arrays usage. But the goal of this program is to show how to use interrupts, timers and pointers in mikroC, not to have an optimization challenge.
A math trick to replace long type calculations would spare a few hundreds of bytes, but the example would loose its clarity.
For those are interested by a high-level language optimization challenge (basic or C) for pic microcontrolers, please see :
Thanks Bruno
html
I tell you what, you build me a website and i'll write some decent code for yours.
"BrunoG" schreef in bericht news:440c42dc$0$20160$ snipped-for-privacy@news.wanadoo.fr...
de
of
"BrunoG" schreef in bericht news:440c42dc$0$20160$ snipped-for-privacy@news.wanadoo.fr...
of
Indeed. As an example it fits its purpose, and even for a real application it's okay to use, if speed/space is not an issue.
-- Thanks, Frank. (remove \'q\' and \'.invalid\' when replying by email)
Did that crack make you feel better about the difficulties you have with hardware design?
make
Given the commentary by cbarn24050 and maxfoo, I really don't consider mine to qualify as a "crack". In fact, I think it to be quite appropriate. At least I wasn't publicly ridiculing anyone.
I wasn't trying to humiliate anyone either, he asked for comments. The fact is needing multiple delays in a program is very commonplace and it's normaly done with a few lines. What the author produced, however well meaning, was just terrible. Thats not a problem for most people, they just delete it in a heartbeat but a real beginner doesn't know any better. Iv'e shown him how to do it, if he did it again that way he would see for himself but his pride has been hurt, that was never my intention, and so he's gone on the defensive. Your right about hardware engineers messing up software but then again so do software engineers.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.