,

Author: SpenceKonde

megaavr/libraries/Event/README.md

@@ -170,12 +170,16 @@ Below is a table with all of the event users for the tinyAVR 0/1/2-series parts
 pinless: The parts potentially (per pinout) have this many event channels that can't be connected to any port's event generator
 
 
+`*` Likely AB-CD-EF
 
 The tinyAVR 0/1-series layouts are really weird. See the documentation included with megaTinyCore for the table; 0-series don't have any RTC-PIT options, and 1-series has them all crowded onto one channel; both of them have two kinds of channels, and are generally a lot less flexible. The tinyAVR 2-series, on the other hand, is almost normal - except they have a better layout - (channels 0/1 get PA, PB, 2/3 get PC, PA and the last 2 get PB, PC. It's unclear how EA will be handled, Taken at face value the EA's product brief implies 6 channels in the standard layout, for 2 channels per port. 14-pin AVR-DD will have only 2 pins in PORTA (and with no portB, those 2 pins have channels 0 and 1 to themselves), and with no port E either, the 14 and 20pin parts will have only the two pins on PORTF, which are not going to be everyone's first choice for I/O (PF6 and PF7 are Reset and UPDI), so channels 4 and 5 are nearly pinless - assuming that what's in the headers pre-release is what they will ship. There is room for improvement, though it's really not bad.
 
 
 ## Okay, so how do I read the state of these event channels?
-All you can do is use it for something that you can detect the response of. Yes, this is bizarre. They're already syncingh it for the sync subchannel! Use that to feed a register
+You don't? Even though each channel on the 2-series supposedly has a synchronizer on it, they for some reason didn't pipe those synchronized bits to a register that we could read from software, that would seem to be the natural thing to do. I'm not sure why, or whether there was a well-reasoned decision making process around this, or it was simply an oversight. An argument can certainly be made "what are you doing reading it from software?" (to which the obvious answer is "Because it's not working and I'm trying to figure out why").
+
+The best you can do is pipe the outputs to a pin and read the pin....
+
 
 ## The Event class
 Class for interfacing with the Event system (`EVSYS`). Each event channel has its own object.
@@ -207,6 +211,7 @@ These class methods return a reference to an event channel (an Event&), or Event
 | Event::assign_generator()       | gen::generator_   | return channel that has that generator,<br/> pick one and set if none currently set |
 | Event::assign_generator_pin()   | uint8_t           | return channel that has that pin as generator,<br/> pick one and set if none currently set |
 
+
 Class methods for working with users or looking up generator or user numbers
 | Class Method                     | Argument Types               |                                                  |
 |----------------------------------|------------------------------|--------------------------------------------------|
@@ -345,7 +350,7 @@ Event0.soft_event(); // Create a single software event on Event0
 ### long_soft_event()
 soft_event() is only one system clock long. Often you need something a little longer. 2 clocks? 4 clocks maybe? Maybe it needs to get past the 'filter' on a CCL... Or you've got 2 things that need to happen a fraction of a microsecond apart; you've tried triggering one on the rising edge of a soft_event and the other on the falling edge, but it's just a hair too fast, and the other obvious solutions aren't viable due to the specifics of your scheme. The only way that a soft-event can last multiple system clocks is if the register is written every clock cycle. There is no time for a loop; only brute force (ie, a contiguous block of 'ST'ore instructions) will do the trick. Now in many ways this defeats the point of the event system; however, there are times when it is not entirely unreasonable to do this (as noted above), particularly if doing weird things with the CCLs, event system, and other peripherals.
 
-The lengths that are available are 2, 4, 6, 10 and 16 (any number less than 4 will give 2 clock-long pulse, only 4 will give a 4 clock long one. Anything between 4 and 10 will give 6, exactly 10 will give 10, and anything larger will give 16). Those numbers were chosen  based on perceived usefulness while staying within reason.  The wacky rounding is a function of the way I cut clock cycles. [It's a block of 16 consecutive st instructions, prior to that, the code (in asm) checks the argument against 4. I then use a breq and a brmi. If you need longer, you shouold definitely use a different approach.
+The lengths that are available are 2, 4, 6, 10 and 16 (any number less than 4 will give 2 clock-long pulse, only 4 will give a 4 clock long one. Anything between 4 and 10 will give 6, exactly 10 will give 10, and anything larger will give 16). Those numbers were chosen arbitrarily to keep the size small, and give a selection that covered the reasonable use cases I could think of. If you need longer, you shouold definitely use a different approach.
 
 #### Usage
 ```c++
@@ -355,6 +360,11 @@ Event0.long_soft_event(10); // will invert the state of the event channel for 10
 ```
 Don't forget that this is an invert, not a "high" or "low". It should be entirely possible for the event that normally drives it to occur resulting in the state changing during that pulse, depending on it's configuration. Note also that the overhead of long_soft_event is typically several times the length of the pulse due to calculating the bitmask to write; it's longer with higher numbered channels. if that is a problem, whatever your use case is, it is not one of the ones this was intended for...
 
+#### Usage
+```c++
+Event0.soft_event(); // Create a single software event on Event0
+```
+
 ### start()
 Starts an event generator channel by writing the generator selected by `set_generator()` method to the `EVSYS.CHANNELn` register.
 
@@ -400,7 +410,7 @@ Shown below, generators/user per instance  (second argument should be less than
 
 `*` - the tiny1 parts with 1 AC work normally. This is unfortunately not supported for tiny1 parts with the triple-AC configuration:
 `**` - There is only one CCL peripheral, with multiple logic blocks. Each logic block has 1 event generator and 2 event users. If using the logic library, get the Logic instance number. The output generator is that number. The input is twice that number, and twice that number + 1.
-`***` - This peripheral is not supported by t6his function, as the the generator numbers are channel dependent. Only effects aging parts anyway (though not that they do;t have some worthy features)
+`***` - This peripheral is not supported because the generator numbers are channel dependent.
 
 `!` - These parts do have an option, but we didn't bother to implement it because it isn't particularly useful. But the Event RX mode combined with the TX input to the CCL permit arbitrary remapping of RX and very flexible remapping of TX.
 

megaavr/libraries/Event/src/Event.cpp

@@ -197,9 +197,8 @@ Event& Event::get_generator_channel(uint8_t generator_pin)
   uint8_t gen = 0xFF;
   if (port != NOT_A_PIN && port_pin != NOT_A_PIN) {
     #if defined(PORTA_EVGENCTRL)
-      #error "what the f?"
       volatile PORT_t* port_ptr = portToPortStruct(port);
-      uint8_t temp = port_ptr.EVGENCTRL;
+      uint8_t temp = port_ptr->EVGENCTRL;
         if ((temp & 0x0F) == port_pin) {
           gen = 0x40 + (port << 1);
           _SWAP(port_pin);
@@ -834,19 +833,35 @@ int8_t Event::set_user_pin(uint8_t pin_number) {
   int8_t event_user = -1;
   if (port != NOT_A_PIN && port_pin != NOT_A_PIN) {
     #if !defined(TINY_0_OR_1_SERIES)
-    /* Woah, we were missing a huge optimization opportunity here....
+    /* Woah, we were missing a huge optimization opportunity here.... but only for DA/DB-series parts
        - The users are numbered in the same orderas the ports.
        - PA is #defined as 0, PB as 2, etc.
        - there are no parts for which a port exists that has a pin 2 or 7, but which does not allow that pin to be used as an event output, except for tiny 0/1, where only pin 2 is an option...
        We basically **don't have to test the port** as long as it's a valid port as we just tested. This is probably like 6-8 instructions instead of several dozen */
 
-      uint8_t evout_user = (int8_t) event::user::evouta_pin_pa2;
-      if (port_pin == 2) { //non-0/1 pin 2 handling
-        event_user = (evout_user + port);
-      } //non-0/1 pin 7 handling
-      else if (port_pin == 7) {
-        event_user = (0x80 | (evout_user + port));
-      }
+      #if !defined(__AVR_DD__)
+        uint8_t evout_user = (int8_t) event::user::evouta_pin_pa2;
+        if (port_pin == 2) { //non-0/1 pin 2 handling
+          event_user = (evout_user + port);
+        } //non-0/1 pin 7 handling
+        else if (port_pin == 7) {
+          event_user = (0x80 | (evout_user + port));
+        }
+      #else
+        uint8_t evout_user = -1;
+        if (port_pin == 7 || port_pin == 2) {
+          evout_user = port_pin == 7 ? 0x89 : 0x09;
+        }
+        if (port >= PC) {
+          port--; // PA = 0 PC = 1, PD = 2, PF = 3
+          if (port == PE) {
+            port--; // We decremented port once already if it was >= PC, so the last valid port, PF now is PE.
+          }
+        }
+        if (port <= PD) {
+          event_user = evout_user + port;
+        }
+      #endif
     #else // Ugh, it's a 0/1-series....
       if (port_pin == 2) {
         #if defined (PIN_PB2)
@@ -863,7 +878,7 @@ int8_t Event::set_user_pin(uint8_t pin_number) {
         #else // No PIN_PB2, meaning it could only be an 8-pin tiny, and the only evout pin there is PA2.
           event_user = (int8_t) event::user::evouta_pin_pa2;
         #endif
-        } // end if (port_pin==2)
+      } // end if (port_pin==2)
     #endif // end 0/1-series
     else {
       return -1;
@@ -1035,7 +1050,7 @@ void Event::soft_event() {
   #endif
 }
 
-static void __attribute__((unused))  _long_soft_event(uint8_t channel, uint8_t length);    // holds the bulky assembly routine for the long softevent.
+static void __attribute__((__unused__)) _long_soft_event(uint8_t channel, uint8_t length);    // holds the bulky assembly routine for the long softevent.
 
 void Event::long_soft_event(uint8_t length) {
   _long_soft_event(channel_number, length);
@@ -1110,7 +1125,7 @@ event::gen::generator_t Event::gen_from_peripheral(__attribute__((unused))TCB_t&
   #if defined(TINY_0_OR_1_SERIES)
     badCall("gen_from_peripheral() does not support channel-specific generators. The TCBs on 0/1-series are.");
   #else
-    #if !(defined(DXCORE) || defined(TINY_2_SERIES))  // Dx-series and 2-series have ovf event. Others dont.
+    #if !(defined(DXCORE) || defined(TINY_2_SERIES))  // Dx-series and 2-series have ovf event. Others don't.
       if (event_type != 1) {
         return (event::gen::generator_t) -1;
       } else {

megaavr/libraries/Event/src/Event.h

@@ -20,7 +20,7 @@
  * set_generator(uint8_t pin_number) - to handle to more complicated setup of pin generators.
  *
  */
-
+/* *INDENT-OFF* */
 class Event {
   public:
     Event(uint8_t channel_num, volatile uint8_t &channel_addr);
@@ -34,7 +34,7 @@ class Event {
     void set_generator(uint8_t pin_number);
     static Event& assign_generator_pin(uint8_t port, uint8_t port_pin);
     static Event& assign_generator_pin(uint8_t pin_number);
-    // *INDENT-OFF*
+
     #if defined(TINY_0_OR_1_SERIES)
       void get_generator_channel(event::gens::generator_t generator) {
         get_generator_channel((event::gen::generator_t)generator);
@@ -52,7 +52,7 @@ class Event {
     #endif
     // *INDENT-ON*
     static int8_t get_user_channel_number(event::user::user_t event_user);
-    static Event& get_user_channel(event::user::user_t event_user);
+    static Event &get_user_channel(event::user::user_t event_user);
     void set_user(event::user::user_t event_user);
     int8_t set_user_pin(uint8_t pin_number);
     static void clear_user(event::user::user_t event_user);
@@ -61,14 +61,14 @@ class Event {
     void start(bool state = true);
     void stop();
     /* event_types: They start from 0x00 for inputs. Outputs start at 0x40 */
-    static event::gen::generator_t gen_from_peripheral(TCB_t& timer, uint8_t event_type  = 0);
-    static event::user::user_t    user_from_peripheral(TCB_t& timer, uint8_t user_type   = 0);
-    static event::user::user_t    user_from_peripheral(USART_t& usart                       );
-    static event::gen::generator_t gen_from_peripheral(TCA_t& timer, uint8_t event_type  = 0);
-    static event::user::user_t    user_from_peripheral(TCA_t& timer, uint8_t user_type   = 0);
-    static event::gen::generator_t gen_from_peripheral(CCL_t& logic, uint8_t event_type  = 0);
-    static event::user::user_t    user_from_peripheral(CCL_t& logic, uint8_t user_type   = 0);
-    static event::gen::generator_t gen_from_peripheral(AC_t&  comp                          );
+    static event::gen::generator_t gen_from_peripheral(TCB_t &timer, uint8_t event_type  = 0);
+    static event::user::user_t    user_from_peripheral(TCB_t &timer, uint8_t user_type   = 0);
+    static event::user::user_t    user_from_peripheral(USART_t &usart);
+    static event::gen::generator_t gen_from_peripheral(TCA_t &timer, uint8_t event_type  = 0);
+    static event::user::user_t    user_from_peripheral(TCA_t &timer, uint8_t user_type   = 0);
+    static event::gen::generator_t gen_from_peripheral(CCL_t &logic, uint8_t event_type  = 0);
+    static event::user::user_t    user_from_peripheral(CCL_t &logic, uint8_t user_type   = 0);
+    static event::gen::generator_t gen_from_peripheral(AC_t &comp);
 
   private:
     const uint8_t channel_number;      // Holds the event generator channel number