produce some code and post it for comment
produce some code and post it for comment
Warning I'm not a teacher
You might be looking at this the wrong way around and have the stuff you're doing in the interrupt and the main loop backwards....LEDs need to look like they're stable, not flickering due to the speed of the matrix scanning being interrupted by the code going to process a pot-change etc.
I usually reserve using interrupts for events that must be done at a high priority, and leave the not so important things that aren't as time sensitive and can wait a bit for handling in the main loop.
For example, the matrix scanning would be done by a timer ISR running fast enough to do the scanning w/out producing any flickering (like Richard's charlieplexing routine)
All the other stuff would be done by polling in the main loop ie looking for key press, reading knobs, etc. That way no matter what your main loop is doing the matrix scanning always gets done when it needs to.
Co-operative multi-tasking is the way to do it. Every task that you want to execute has to execute in a RTC(run to completion) manner. You should write tasks in such a way that no single task ever blocks(hogs the CPU). Every person may implement this differently. Most will prefer the super-loop structure of task management in tiny embedded systems. Medium / large embedded systems can afford the use of RTOSes since they have sufficient memory to handle such overheads.
A good way would be to read up on ProtoThreads and see how they mangle C to implement the super-loop task management. Wikipedia might help for information on co-operative multitasking.
There are a bunch of PBP commands which cause delay which you can’t use, Pause being a good example,
or at least not with a high value behind it![]()
and some commands that need to be used a particular way which is always contrary to the manual,
in a manner that only deals with bytes at a time. Any serial command is a good example of that.
For the LED display I don’t think any of these enter into it.
Assuming just a loop, your program would be something like:
As the program progresses it may be the last step increases time to execute,Code:Set up an initial graphic frame cycle: Draw the frame to the LED display Delay to display the frame to the User Read input from buttons/interface Process the next frame based on input and/or the program goto cycle
and the deliberate delay can be shortened or eliminated.
For an LED display it may or may not be helpful to use a timer for the framerate,
but that doesn’t really relate to your question.
Last edited by Art; - 13th July 2016 at 17:24.
Thanx so much for everyones input, something for me to consider and learn mroe about, i'd never even heard of co-opeartive multitasking, let along how to implement it in a pic/picaxe lol. (more reading for me).
Overall, to simplify my initial question/example, I wanted to know what preferred methods programmers use when it comes to nesting loops and how to interlace them in order of importance, like loop 1 (main) is the housekeeping loop, loop2 is the led matrix data, loop 3 and 4 read posts & switches, then a preferred structure of how loop1,2,3&4 would nest together for fastest (least interruptions) code operation.
I'm feeling Co-op multitasking is perhaps the best solution to consider? unless there's a general rule of thumb about nesting loops nicely to share time with eachother?
Thanx again,
Marty.
Bookmarks