-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New library (or libraries): TimerB #481
Comments
Given that the possible results of the ISR are going to be a pretty small set, would a default ISR in the library with a defined structure (result_updated/value(s)/overflow) make sense? |
What do you mean by this? There are often things that need to be done in the ISR with the duration captured by the input capture module; Consider Input Capture on Event mode where the user needs to know the duration of both the highs and the lows (this is often critical for OOK RF receiving for example). The only way I can see to do this is to use input capture pom event ,and swap Edge during every ISR - plus also do some logic on that captured duration too - if state = idle, check if it'sthe right length for a start pulse, if it's in rx state, check for whether it's a 0, 1, portion of rthe signal that has nothing to say either way (in the protocol I made for AzzyRF, only high has meaning, but the lows between them had to be within a range to be valid., or an invalid length in which case we we reset the state back to idle. In that sort of use case, you cannot rely on loop running between each bit to process the latest capture. |
Definitely requires some tough design decisions, The overhead of simply calling a function from an ISR is sort of shocking. |
The capabilities of the type B timers are being ignored, and that is unjust, The type B timers deserve better! I am inclined to not impement this as classes due to the overhead and the fact that the compiler can't seem to optimize them worth half a crap. There are a considerable number |
so given the overhead of a callback function invocation from the ISR (are inline weak functions a thing?) what about some wrappers around the register manipulation + some examples for how to do these things while letting the user own the ISR might end up working better than a fully featured library here |
Yeah, I personally favor a library that doesn't define the ISR and instead shows how youd use it in the examples - but frankly for the TCBs there are a lot of cases where you don't even need an interrupt that does more than clear the intflag set another flag and read the capture register and maybe not even that. I mean a TCBOneShot library? All the interrupt would need to do is clear the flag so it would't get caught in an interrupt death spiral. And the rest is writing 5 bytes or so to the TCB control registers. but right now, I'm, what's the phrase "Up to my face in alligators", (you know, how the head of none of the three cores will compile bare minimum for starters), this isn't happening any time soon unless I end up inadvertantly making an example for something else that I could chop out and include, Hence why the milestone is "some future version" |
Oh - and as far as library priorities go, this is miles below sleeplib the planned sleep and power consumption library. |
anything stuck where another set of eyes would be useful? |
What angle are you coming at this from? I mean, do you know how to use the TCB, and want others to use it too, or are you having TCB problems and want some libraries to help make this work? Also, are you one of the PIO folks? I don't even know what PIO needs, but the other threads made it sound like I should be providing more resources for PIO; if you are familiar with it, I'd like to get an explanation, so we can figure out how to achieve it in light of the new boards.txt builders (I;llbe checking in a new version soon - I have code that isn't checked in for mTC) but I have this problem with the work I did for a client last week and eaglecad has me in it's talons and is ascending a thermal towards it's nest to feed me to it's eglets (I think that's what baby eagles are called?) anyway I'm on the fifth try after corrupting the files four times and ending up with unusable results. Just trying to rename nets so they match another design. (issue was that he told me two wrong connections but had I named the nets the same way, the problem would have been caught, and yeah, it's impossible to compare the two designs the way they're named now, he's right. (based on the issues and comments I get, more people are using the my mTC and DxC with PIO than with Arduino, or maybe they just have more problems because I don't make life easy for them, because I know about as much asbout PIO as my cat knows about AVR assembly. (and to be clear, she doesn't know AVR assembly, and doesn't even claim to by walking on the keyboard like some cats to) |
I was coming at this particular one from the angle of trolling through the issues to see if there was anything I might be able to help with and having a potential approach occur to me and so I wrote a comment suggesting it. In general I've found TCB to be powerful but every time I have tried to use it I ended up spending hours staring at the data sheet + a bunch of trial and error to get it to do what I want so I guess I'm on the latter camp. I also tend to use non-TCB approaches where TCB would be a better solution because I know the worse approaches will work and be working much faster. For example, my clock calibration should have been written using TCB. I am mostly not one of the PIO folk. I'm kind of surprised by the contrast of your approach to Arduino 2.0 (my perception is you think it is unsupported beta crap that you don't want to think about) vs your desire to support other alternate environments like PIO. Pre Arduino 2.0 I sometimes used PIO because it is a better IDE than 1.x. But at least when I used it I found the ability to fire up an example hard to use, the configuration hard to use, and found myself running into many problems where various defines weren't set right. At this point the one killer feature PIO has for me is the ability to set global defines. Arduino 2.0 now has library version management and some amount of settings management that is nearly as good. So I haven't used PIO in quite a while and was never really comfortable in it. From my experience with PIO I suspect the disproportionate reports are more a sign of it causing problems than it being most of the usage. I would suggest that you discourage its use by non-experts unless and until you get a community member who understands it well and is willing to help. The pull request documenting how to set it up seemed counterproductive as it mostly helped people get started down a badly documented path but wasn't deep enough to help people avoid/solve the issues. |
The reason I'm not working on Arduino 2.0.x is that 1) most of the issues being reported aren't bugs I can fix, they're regressions in the IDE that need to be corrected by the Arduino team. Clearly from the volume and nature of reports of problems,. 2.0.x is not yet ready for prime time. and 2) It's not a low priority per se, but there are months of higher priority work ahead of it in the queue - that matters more to more users, and I already work on the cores almost full time. So I've gotta set priorities, and supporting a known buggy version of the IDE comes below making everyhing work on the last release that was actually usable. and I'm hopping by then it will actually be mature and usable and half the problems will have gone away as they unbreak stuff. I don't think there's any way around the fact that the initial 2.0.x releases were shitshows and still are. Re: PIO, we have a HUGE number of users who use it, and they start gathering outside my apartment with pitchforks if I don't do what they tell me. And usually they will tell me exactly what I need to do, while the Arduino bugs also require figuring out what's wrong, and doing a full investigation. Lets not forget that only maybe 20% of Arduino IDE releases historically have been remotely fit for prupose :-/ |
Regarding the original matter of a TCB library or libraries: I think it would be very nice to have a way to set up input capture, since now it's a multiphase process, where the EVSYS and TCB both need matching configurations. Either by using event.h's assign funcions, or implementing channel selection yourself. I will note that in typical input caputure modes, speed is enough of a concern that an attachInterrupt like mechanism makes the library DOA. I don't see a way around the user having to do the raw ISR themselves to get acceptable operformance in most cases. Right now, baically nobody uses input capture. Why? Because it's too complicated and there are neither examples showing how to do it nor libraries for it.... |
If my name was "nobody" your statement is accurate "Nobody uses it". Or do you refer to just input capture on timerB?
|
o_o Well, I said basically nobody, not nobody (though I managed to spell basically wrong). That just means that there aren't enough people using it to invalidate approximations made by a model which assumes that such persons do not exist. Besides, what you're doing doesn't count, because this issue is in reference to the type B timers. I'm pretty confident that fewer people are using the TCD than a TCB for input capture, so your're part of an even smaller subpopulation that does input capture with that monster. You're using a type D timer, because... well... why? It's not clear to me why you'd intentionally subject yourself to that - and in fact, your code manages to step around the pitfalls of the sync process, since you spend enough time doing other stuff after calling takeOverTCD0 that you can confidently write to the "static"
|
Good to know that takeOverTCD0 is not waiting itself for the synchronizing to be done, before it returns. So if I would have placed it right above "configure timer D" I would have to add a "while" to check the ENRDY (or something) in the status reg. And yes, servo was eating the other timer, so I decided to bite the TCD0 bullet. |
Yeah, takeOverTCAn() guns the timer and resets it to POR state. TCD has no such reset function Maybe takeOverTCDn() should be takeOverTCDn(bool reset = 0) and if 'true' is passed, it will wait out the sync delay, then write 255 to every register with "flags" in it and then memset 0 to everything, I feel like that's a little too hand-holdy tbh |
Closing this issue. This feature is no longer explicitly planned, though some portions of it may be added to the core at some point. |
We really ought to have a minimal wrapper class for at least the two most common non-PWM uses of a type B timer, and ideally the third as well. These are:
The additional parameters should include an option to repeat or not-repeat, at minimum. Preferably, this should allow more complexity - see the Modes section for TimerB
3. Periodic interrupt mode - User provides a function to be called from the ISR.
4. Event Counter (2-series only)
Notes: All of these require that the ISR, and some timer-specific call, be located in a separate .c file, and hence in a separate compilation unit, so that the ISRs do not generate duplicate vector errors when not used.
These are also currently blocked by #480 - I want to use the Event library for this, and if we don't have an event library capable of this, then either the current one must be extended or replaced to rectify this.
The text was updated successfully, but these errors were encountered: