SpenceKonde
commented
3 years ago I have been thinking about this as well!
The AVR-Dx series is a superset of megaAVR 0-series and tinyAVR 2-series (only the tinyAVR 0/1-series is weird (it's weird with a number of the big "modern AVR" features: the PORTMUX registers have non-descriptive names, CCLs can't do interrupts... and the event system; my understanding is that they were also the first to come out, too - so that's why they are weird... by the time the realized "Okay, this sync/async channel distinction is a complicated mess that makes the event system worse", it's worth centralizing the synchronizers" (see, on tinyAVR 0/1, only TCA0 and USART1 IRDA input required a sync channel.... but most other peripherals have their own synchronizers* according to the datasheet (that is, just because it will consume an asych channel doesn't mean it treats it as such, or does under all/most circumstances). So on the next part families, they did those things right.
- Okay, the 2-series leverages the fact that there are 3 ports, 6 event channels - each pair of channels gets 2 ports - 0 and 1 get A or B, 2 and 3 get C or A, and 4 and 5 get B or C. Dx/0-series have channels with no pin inputs, which IMO is kinda stupid.... I haven't seen any data leak out about the DD-series' EVSYS, but looking at what ports there, PORTC and PORTD would have been no-brainer choice, being as that's the only two ports that
I think they're trying to do that again with the crazy ADC in the 2-series (I think it's going to be everywhere in the post Dx-generation. The AVR product line is advancing by leaps and bounds these days, it's great times for someone who loves AVR (as I do) - though as the one who is going to have to write the arduino abstraction (and inevitably, a library to expose it's functionality), I'm grateful for the delays!
Anyway, back to event library - the implementation I think, as you said, is straightforward. The problem is the design here; this issue rears it's head with Logic as well - but is a much bigger deal on the event system.
Sure, we want a slightly more friendly library than directly configuring the registers - though frankly it's pretty easy compared to almost every other peripheral...
The problem is that it's extremely awkward to write a reusable library that makes use of the that doesn't fight unnecessarily with any other library that tries to use an event channel (or LUT, for Logic)... And gee, there sure are a lot of things that rely on the event system.. (input capture comes to mind, eg, porting whatever 433 MHz RF receiver library everyone uses, or the TV-remote-control one). There's rarely an actual shortage of channels (or LUTs), but any library that needs one
The "user" of an event library, I feel like would be more library authors that end-users, almost... right? In the case of event channels, whatever was asking Event for a channel would call Event::getChannel(), getChannel(Event::withPinInput(DigitalPinNumber)) or getChannel(generator::rtc_div512)? I can imagine a bunch of approaches... whatever you do, i'd think it'd have to give the caller a pointer to the event channel object? in any event, IMO would be totally cool to say "you need to set the channel generator to something before some other constructor/begin() method/etc might ask for a channel, otherwise no guarantee we won't see that you're not using it and give it to someone else" that way you wouldn't need to track which ones had been checked out... though I think to do a similar thing for Logic you probably would need to keep track of which blocks had been handed out. The more I've thought about this, the more I've realized that Logic really does need a way to allocate LUTs to requesting functions/libraries... (and the Logic class ought to have LogicN.getGenerator() ( just return (EVSYS_CHANNEL0_CCL_LUT0_gc+block_number;).... or maybe the EventChannel class should have setGenerator() and routeTo() methods...
Naturally I'd imagine that the EventChannel (or whatever it gets called) class would have routeTo(ptr,eventuser::event_type) method (which would have a bunch of signatures - you'd pass it a pointer to the thin you wanted to route to and a constant telling it which event input you wanted it routed to (and the event routeTo() method would have a ton of signatures, for pointers to Logic objects, and timers, and so on and so forth.)
That's sort of the lines along which I've been thinking it would need to be. I'm not terribly good with pointers and C++ classes though... and have WAY too much on my plate with the cores currently. Everything is an "on fire" priority, still... and for me getting low power library is the first library I need to work on when I finally can do that - so many people are asking me about how to save power on these things :-( and I have no clue!
MCUdude
per1234
Hi!
I have an idea I'd like to discuss with you. As you already know, the event system is pretty powerful and certainly useful if you can wrap your head around it. I wasn't really able to do just that before I really deep dived into the datasheet. And then it appeared to me; It's very simple! A lot simpler than the CCL hardware!
I'm sure other users will find the event system useful, and even easy to use if they have a sleek library to work with. So what do you think about creating a library that works for MegaCoreX, DxCore and megaTinyCore? I can create a working library for MegaCoreX, and you can modify it to work with "your" hardware? According to the datasheets I've read, the event system hardware are very similar across these three "hardware families".