_______ 
 |__   __|
    | |   
    | |   
    | |   
    |_|   
          
          

         
         
  ####   
 ##  ##  
 ##  ##  
 ##  ##  
  ####   
         

   ____  
  / __ \ 
 | |  | |
 | |  | |
 | |__| |
  \___\_\
         
         

    ##   
         
   ###   
    ##   
    ##   
    ##   
 ## ##   
  ###    

 _____ 
|  __ \
| |  \/
| | __ 
| |_\ \
 \____/
       
       

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Study material for developers''' For many applications you need to do some timed events (like setting a port bit that controls something, or enabling an interrupt) There are several ways to time events: * multichannel hardware TPU (this is nice if you have it, but the number of channels is hard-limited, for most uC it is zero - 0 without added HW). * busyloop (this is usually a bad thing) * timer-based event execution controlled by software When you sleep at night, do you watch your clock every 5 minutes to know when to wake up? You don't do that, do you? Most people set an alarm-clock to wake him up. This enable them to do what they really want: sleeping. This makes the difference. The busyloop people cannot do what they want, because they frequently watch the time. With no TPU, (thus software eventqueue) the issue boils down to the following simple principle: #Find what needs to be done next (and when it's due) #Set your alarm clock #Execute it The 2. keeps us from doing a busyloop and wasting our cycles. 3 is almost trivial. The implementation question is about number 1: ---- '''How to find what to do next''' There are 2 reasonable ways to handle it: * '''H:''' keep the events in a heap-structure, sorted by due-time (let's call it key) * '''M:''' minimum calculation of multi concurrent channels. ---- '''H is the OnlineCourse/EventQueue which is currently implementd''' It utilizes the efficiency of the well known OnlineCourse/HeapStructure. ---- '''M , thus finding the minimum might sound simpler''' You can put several events to a channel as long as you can tell the minimum key. (This is trivial if the events in the channel are of some sequence by nature). When you have the min-keys per channel, you just need to calculate the minimum of them, that is the value you'll need to set your alarm clock. This calculation is simple and linear function of the number of concurrent channels. For an 8 cyl staged injection you will have max 17 channels: 8+8+1 - ignition is only 1 channel engine-wise for dummy igndrivers: no concurrency between cylinders. This is awfully lot, would not be faster than with the above H (heap-based) method with 32 events. It seems hard to do this right with all the flexibility in our application: when the sequences are not apriori known, H is the way to go (it suits a large number of applications and simple to use). Note that there can be a hibrid solution that have H as one channel of an M setup. ---- See OnlineCourse/EventQueue for an implementation (of H).
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.