??? 08/01/05 13:10 Read: times |
#98582 - other way round Responding to: ???'s previous message |
Of course I don't want to make something time critical (like precise delay loops). Contrary - I want to avoid something stops working because something else grew uncontrolled. See the thread where this one came from.
For example, the timer - imagine one makes it 10ms periodic, highest priority, why not, it is a nice unit and there are 10kcycles on the plain vanilla available between two interrupts. And then he makes a clock, counting up to 100 in the 10ms and displaying the time. Then somebody else adds more and more features - and suddenly it starts running somewhat slow... My pseudosolution would be: #pragma cc_begin Timer_ISR: ... code here ... ... with branches ... ... more branches ... ... manually (in simulator) almost untraceable ... ret(i) #pragma cc_end #pragma cc_maxcount 9000 and upon reaching 9000 cycles it would emit a warning or error... Still looks useless? Jan Waclawek |
Topic | Author | Date |
Counting cycles... possible in C? | 01/01/70 00:00 | |
You need a Profiler | 01/01/70 00:00 | |
The compiler knows | 01/01/70 00:00 | |
Source code useless | 01/01/70 00:00 | |
That's why you need Assembler! | 01/01/70 00:00 | |
nohohoho | 01/01/70 00:00 | |
Speed is not everything! | 01/01/70 00:00 | |
Cycles vary? | 01/01/70 00:00 | |
I know | 01/01/70 00:00 | |
absolutely, but what good does it do | 01/01/70 00:00 | |
other way round | 01/01/70 00:00 | |
Yes, the things posted apply in this cas | 01/01/70 00:00 | |
exactly for this reason | 01/01/70 00:00 | |
how can you automate that it is small en | 01/01/70 00:00 | |
Use Microsoft Excel | 01/01/70 00:00 | |
excel and conditional branches ? | 01/01/70 00:00 | |
That's why | 01/01/70 00:00 | |
That makes absolutotally no difference,![]() | 01/01/70 00:00 |