Hi Dave, I want to take this opportunity and personally thank you for writing task manager. I have used it every day for years since the win95 days to end pesky tasks and since XP to monitor the CPU. It has made my life lots easier.
@TheEmbeddedHobbyist
3 жыл бұрын
I'd also like to thank the person, who wrote the mouse driver, had loads of windows crashes where the mouse pointer still moved but nothing else worked. :-)
@ratbag359
3 жыл бұрын
@@TheEmbeddedHobbyist lol yea been there many times windows subsystems not responding task manager won't come up but i can still move my pointer lol
@perwestermark8920
3 жыл бұрын
@@TheEmbeddedHobbyist Many graphics cards uses a hardware mouse cursor. This means that the hamster may be dead, but as long as the mouse ISR picks up the x-ticks and y-ticks from the mouse and sends the actual mouse location to registers in the graphics card, you can see a moving mouse cursor even if all paint code of the applications have died or the graphics driver code to actually perfor paint commands have crashed. You end with a static image of last computed display bitmap with a moving mouse cursor on top. It is quite common that interrupt handlers keeps working while the actual processing code is dead . Some lockup have made the OS stop task-switching. Just that the ISR doesn't use OS task switching but instead the CPU hardware logic for interrupt prioritization/activation. I guess more people than me have used caps-lock, num-lock or similar to check the machine. Fast LED response shows the OS is generally fine but the current program may be dead. Slow LED response indicates the machine is alive but at a huge load. No reaction at all on keyboard LED's and the hamster is likelly dead.
@ratbag359
3 жыл бұрын
@@perwestermark8920 very interesting i too use tje caps lock / num lock to check the system is still "alive" good for seeing if bootloader has locked up and in os is there hope of resuming normal operation. I used to have a laptop where the battery or battery logic used to. create so many interupts the system would be unusable and caps lock would take 5 seconds to toggle.
@perwestermark8920
3 жыл бұрын
@@ratbag359 One of my machines running Win10 has some broken driver making the machine sometimes spend most time doing interrupts. But Win10 isn't as helpful as Linux to tell what interrupt source keeps counting interrupts. Or what drivers may be hooked to that interrupt source. Microsoft doesn't seem to think that information is relevant to an end user 😪 I had a Linux with similar issues and the /proc file system made it trivial to figure out that machine had a hw issue with a PCI bridge chip. For more normal problems, Task Manager has enough information to help pinpoint most problems with CPU hogs, resource leaks etc.
@VraccasVII
3 жыл бұрын
Highly interesting, I love whenever software starts to adapt to real world physics
@friendlyhonda3187
3 жыл бұрын
I remember having to do a button bounce in Assembly in second year lab when I was in Uni. Not a terribly happy memory, but I did get a respect for the border lands between physical controls and the digital world that we programmers play in all day. This is probably why we love touch screen HMIs so much.
@davidbundgaard
3 жыл бұрын
Hi Dave, Yes please, we are interested in your amazing projects! Thank you for taking your time and share all of this.
@rabbittguy1410
3 жыл бұрын
I was trying to figure out how to do that years ago when I first bought those 3m led strips they said you can cut them and make them individually light up , the code was a nightmare and I eventually gave up . But this is very close to what I wanted to do 😃 more please 👍
@johnrevill9592
3 жыл бұрын
Great project. This reminds me of a project I make about 8 years ago using an Arduino. I added Stop, Indicate, reverse lights to a Remote control car. It monitored the servo PWM signals and deduced from that if the car was turning, braking, reversing etc. It worked really well. When I find the videos of it in action, I'll post it.
@MrStretch148
Жыл бұрын
i'm finding your videos very helpful in my everyday work, as well as exploding my mind w/ micro controllers. I learned basic on the trs80 model 3 and got a trs80 color that Christmas. I'm designing my own IoT device and am getting deep into chip/power efficiency and your videos are feeding that hunger. Please do keep doing deep dives into code. I'm going to go watch your assembler vids (dabbled as a teenager). And PLEASE, do a deep dive into your night rider code!! Very interested in multithreading and interupts in C++ all the whens and whys etc. I subscribed after the first vid and have liked everyone I've seen (some more than once but you only get one like). Loved the tour of your home. thanks again. oh..maybe a lesson on STYLE or Coding Standards... example...why do you use _variable in a class? is it because its private? more info required for things like, extern volatile double variablename why and when. ok...till next time.
@spatch22
3 жыл бұрын
Would love to see more of this project. Would really like to add this to my SUV! Thanks for sharing high quality content.
@ddhanlin
3 жыл бұрын
Mechanical Switch debounce. What a great topic and a great memory. Picture 1993/94. A DDE/PLC interface written in C++ and running on WFW 3.11 in a manufacturing environment. A server side C data collection interface running on HPUX and communicating with the WFW PC. Another communication interface written in C and communicating with a Motorola Pagemaker 8. Put it all together and what happens when a conveyor system faults? No less then 70-100 pages sent out on the paging system in < 1 second. Every page was a mechanical switch bounce. LOL! I begged the engineers to code a latching circuit on the PLC. They refused to. So I ended up writing some debounce logic on the server side application. All that useless data was still be sent over the WAN, but at least I was only sending out 1 single page on a conveyor fault. I still can't believe the DDE/PLC interface would pick up that many switch bounces. LOL!
@Karreth
3 жыл бұрын
I would like to see more of this project, I found it very interesting.
@dmzar
3 жыл бұрын
Are you going to discuss why, in software, you really should debounce a stop switch (not just a start/stop switch?) 😀 This would be so interesting... Likely not for most of your viewers who want to learn coding techniques... But this embedded HW/SW guy with a background in academia would love it. Always enjoy your take on things.
@DavesGarage
3 жыл бұрын
The code I demo debounces both states, start and stop. Basically, it denounces any change in state!
@dmzar
3 жыл бұрын
@@DavesGarage Terrific. Always good to solve the general problem so when you reuse the code, it doesn't break when using it in a way that doesn't match some special case. Thanks for teaching people good design practices! This is really important in embedded systems where updates are often hard, if not impossible, once deployed.
@ratbag359
3 жыл бұрын
Any analog input (from non digital sources) should be debounced as transient's can easily be picked up.
@perwestermark8920
3 жыл бұрын
@@ratbag359 You often only need to debounce in one direction, unless you have designed an antenna where cable or PCB traces picks up noise. The I/O pins are normally used with pull-up or pull-down that is strong enough to not give incorrect readings from spurious noise. But there are situations where you want symmetric response - so same delay for on or off. And there are obviously situations with human safety etc where even a lightning strike must not trig an activation (assuming of course the electronics is protected enough to not get destroyed).
@ratbag359
3 жыл бұрын
@@perwestermark8920 as this is going to be used in a automotive application I would implement hardware filtering on the input. As for debounccing as it is interrupt based the number of interupts could be many for instance a loose connection to the trailer so in this case as interupts are set for rising and falling edge it would be best practice to debounce both transitions. my preference would not be interrupt driven instead poll based.
@5lickwi11
3 жыл бұрын
Is there going to be a follow up of this where you install it into a car and make things work? That would be pretty neat.
@sleepib
3 жыл бұрын
When possible, I prefer using latched debouncing with a double throw switch. If the NC contact is closed, the switch is definitely not pressed. If the NO contact is closed, the switch is definitely pressed. If neither contact is closed, maintain state. So you can use a non-inverting buffer to provide positive feedback to the common pin, and connect the NC and NO pins to opposite rails. This makes the firmware stupid simple, delay-free, and doesn't trigger several times when the switch starts wearing out. If your microcontroller has both pull up and pull down resistors you can do this in firmware. You can also just use two inputs. As for debouncing single contact switches, you only need a delay when the contact goes from closed to open, though in some cases you need a lot more than 30ms, especially when the switch starts wearing out. Example, I have 8 buttons with the positive feedback based hardware debouncing, all wired to port 0 on my microcontroller. The code that reads all 8 of my buttons is only one line in my main loop: Buttons |= ~P0; // switch is wired active low After I decide how to act on the currently pressed buttons, I clear that variable.
@Rx7man
2 жыл бұрын
always interesting to see software solutions to it, but in cases where you know you're going to get a lot of switch bounce, etc, and were designing a production hardware solution, I think doing it in hardware is the better, safer choice... a capacitor and schmitt trigger chip could do it all easily and reliably
@Decxcraft45
3 жыл бұрын
Hi Dave, would definitely like too de more of this project. I find it really interesting and hope to one day make an implementation of my own.
3 жыл бұрын
Hi Dave and thanks for a great channel. I noticed that you use header only c++ classes. That is not C++/h pairs as we teach in schools :) I'm an old cpp teacher. Is this common practice at Microsoft or is it something you use? Sorry if you have addressed this somewhere else. Take care and thanks again for great content.
@DavesGarage
3 жыл бұрын
No, not common at MSFT, it's my own habit. Now the compilers are generally smart enough to inline/outline code as needed, I put it all in one place as much as possible. So really only statics and globals go to CPP for me!
@MathijsWijers
3 жыл бұрын
I actually bought an old trailer/folding caravan, and intend to replace all electronics with modern stuff, so, yes, I'm particularly interested... :)
@jmr
3 жыл бұрын
Great video! We are interested in the whole project.
@MikeBramm
3 жыл бұрын
Yes, please show more of this project.
@dstarfire42
3 жыл бұрын
I deal with this phenomenon every day at work with the forklifts I drive. When you release pressure on the joystick after the vehicle is stopped it will then shimmy backwards and forwards for several seconds and you usually have to step on the actual brake* to make it stop moving completely. It's especially unnerving when it happens with the vertical movement controls, as that feels like it's trying to launch you catapult-style. *We normally slow/stop by reversing. The brake there just for emergencies. Or, quite often, to stop the d*mn thing from shimmying forever. This is according to the manufacturer's recommendation and standard industry practice (except for the shimmying part, obviously).
@cwinter90
3 жыл бұрын
I actually ran into this at my last job. I had to make a prototype for an interactive display. I used a Trinket M0. I'm also a web dev and had zero experience with C lol. They used some big huge $300 emergency stop looking button lmao.
@byronwatkins2565
3 жыл бұрын
This PROBABLY works (almost every time). If your world depends on correct function, you should use a double pole switch and a SR latch.
@91795jc
3 жыл бұрын
Hi Dave, love your videos, very educational. Any particular reason as to why you would use IRQs for each change? As far as I understand, it makes sense on a processor with a lot of other subroutines running, but interrupts usually require some time to trigger and a lot of redundant cycles to run (saving and loading the previous registers and whatnot), which may or may not affect the performance of a small microcontroller. If I remember correctly from my uni days, the least amount of additional instructions required for the atmega386 interrupts (disregarding the trigger time) was 5, provided you were sure you did not have anything important in the relevant registers at that time and you wrote the interrupts in assembly. Best regards
@RuneSmedstuen
3 жыл бұрын
Nice... just joined for "thats it for today" :) Have a great day, Dave!
3 жыл бұрын
I'm interested in your project. Keep them coming.
@jeffmoye
3 жыл бұрын
Suggestion: add a CAN input. Lots of scope for content there. CAN transceivers are cheap. But understand that it is very likely to be vehicle-specific (well, the codes will be. Hardware will be universal across all vehicles with CAN lighting. As will the process of monitoring the bus to identify which codes to respond to during the design process).
@jeffmoye
3 жыл бұрын
@@ABaumstumpf what? Stop using a network protocol with zero security? What could possibly go wrong? It’s only used in cars. And lifts. And aeroplanes.
@turtius
3 жыл бұрын
when in doubt, take the polling route :D
@treyquattro
3 жыл бұрын
OMG! Dave's comments: 2 spaces after a period. Dave is Satoshi!!! Mystery solved, QED.
@MarkoMarjanovicKackavaljer
3 жыл бұрын
Hope to see more :) Cool video
@noweare1
2 жыл бұрын
I will normally poll the switch, software debounce then just call a routine. Debounce routine just keeps reading the pin until it does not change state x number of times.
@MDMAviation
3 жыл бұрын
How I debounce the button: bool buttonPressed = false; // Inside an interrupt or whatever if(isButtonPressed() != buttonPressed) { delay(30); //ms buttonPressed = !buttonPressed; } I know this stops the code from running for 30ms, but for most simple things it's gonna be enough (turning on and off LEDs or things like that.
@onlyeyeno
3 жыл бұрын
[@Dave's Garage] Thanks for another interesting and entertaining video. And I for one would claim that "Interest exists" :) Best regards. P.S. I would really love to hear You explain the function of, as well as Your opinion of the (hardware) TPM and it (possible) becoming a requirement for uses of Your computer going forward. D.S.
@Bazzeee
3 жыл бұрын
Hi Dave, did you consider using a callback when a state has changed instead of polling? If so, why did you opt for polling in this setup?
@LittleRainGames
3 жыл бұрын
Can also just use a capacitor and resistor.
@bluetrepidation
3 жыл бұрын
oooh the ESP32 dual core!
@BDBD16
3 жыл бұрын
Police officers in plainclothes must identify themselves when using their police powers; however, they are not required to identify themselves on demand and may lie about their status as a police officer in some situations (see sting operation).
@ratbag359
3 жыл бұрын
I would just poll the state of the input pins for example every .25 seconds. I use interrupt for time sensitive things like timers and serial buffer has data to be handled.
@perwestermark8920
3 жыл бұрын
Polling can work, unless your design is sensitive to noise, in which case your poll might happen during a nanosecond long, spurious, noise pulse. If instead polling every 1 or 5 ms, then "three identical in a row" could be used as debounce.
@ratbag359
3 жыл бұрын
@@perwestermark8920 exactly still needs debouncung regardless but removes the the opertunity for sporadic operation and wasted cpu time if a loose connection exists also in this case the only time sensitive state change is the brake state on transition every other can take 1 second and would not cause confusion for other drivers
@mrlazda
3 жыл бұрын
You should enable pull down resistors on ports just to make solution more robust, if you live pins floating they can detect residual voltage. There is even easier solution for denouncing pins is to do it in hardware with 2(1) resistor and capacitor, it take no time to develop and taken no microcontroller cycles.
@perwestermark8920
3 жыл бұрын
Debouncing inputs is not a task that stresses the processor. Adding components is fine for a hard-coded design, but not too much wanted for a generic microcontroller card. By the way - the code shown in the video did show pull-down (I think it was) enabled. Edit: See at 5:50 in the video - the pin initialization lines.
@mrlazda
3 жыл бұрын
@@perwestermark8920 you was right that he enabled pull down resistors, I did not notice that when I was watching video (I am getting to old to watch on mobile). Every cycle you do not need to use on microcontrollers is stressing microcontroller for nothing, but bigger problem is waste of time on writing code that you can do in 10 seconds in hardware.
@perwestermark8920
3 жыл бұрын
@@mrlazda One thing about pull-up/pull-down is that it should not just be done for used pins. If there isn't a library that forces it for all pins in the startup code, then the application itself should make sure no pin is left as high-impedive input or tristated output unless there are external components that will keep the pin in check. Debounce is something you normally write once (for each type of switch connection mode. So no waste of coding time. When it comes to CPU load, it's so low that it's normally irrelevant to the main task. When power consumption is important, it's possible to use processors that draws way below mW and still manages proper debouncing in software. If I personally do debounce, it's for a product that will go out in a significantly large quantity. One cent times 10k or 100k or more will add up. Besides the advantage that the software path allows the timing to be changed. Another thing - I might use an ADC with an resistor ladder and many switches. So one processor pin might handle 4 or maybe 6 buttons where the processor checks for one of 16 or 64 different voltage bands. Sometimes it isn't one switch but maybe a keypad of maybe 4x4 keys that is row/column-scanned. In many situations, it's even programmable I/O so the end user may want to decide if they want debounce (maybe 50 ms for a switch or 60 seconds for an open door) or if they want ADC measurements with sw low-pass filtering or if they want something else. So there are many situations an RC circuit isn't managing that well. But as I mentioned - a RC-filtered button requires a digital input with hysterese or you may still get multiple activations from noise when the RC ramp is passing the forbidden zone between highest allowed zero and lowest allowed one. So in the end, it's quite unusual with hw-based debounce in microcontroller-based projects. It's so simple to make a sw-based "leaky bucket".
@perwestermark8920
3 жыл бұрын
I forgot one thing - if running on small batteries, you don't want any measurement voltage to the switch between each time you poll. This is complicated if using hw-based debounce.
@mrlazda
3 жыл бұрын
@@perwestermark8920 your arguments are valid, but you can look same situation other way, adding couple of cent in resistors and capacitor can be less then having need to buy bigger microcontroller. Rc filter on pin are not general solution same values not fit any case, sw solution is more universal but as any universal solution in generally it is suboptimal for specific case. And interesting is that most microcontroller project use hw denouncing, even ones that do not have any input ( look at reset pin 😀). As pull down resistors on unused pins that is microcontroller depending, for lowest power consumption some microcontrollers like unused pins to be declared as analog inputs for lowest power consumption some like to be left in high importance some do not care, that depends ...
@JeffL8795
3 жыл бұрын
Great stuff! Any chance that you can put the code on Github? :)
@pskry
3 жыл бұрын
Is there a reason why you don't debounce the buttons with debouncing circuitry?
@perwestermark8920
3 жыл бұрын
You normally want software instead if hardware since that is cheaper. And less components and solder points to fail. Most electronics has ready digital inputs, so there is no good place to add the extra components if you add a switch. One thing else - a capacitor can "eat" short pulses. But it also creates a ramp when charging/discharging. This ramp, together with noise, ends up giving bounces if the digital input doesn't has a hysterese. Not all digital inputs has hysterese, but a forbidden zone where you do not want the input voltage because the actual reading for a voltage in this zone is undefined.
@altimmons
3 жыл бұрын
What framework are you using here? Does Vanilla Arduino use .h files and have classes now?
@DavesGarage
3 жыл бұрын
Arduino framework under PlatformIO
@KTheXIII
3 жыл бұрын
IIRC Arduino uses C++11 and the library from Arduino is written in C++.
@winnie8614
3 жыл бұрын
Why just don't use a simple capacitor attached to one leg of a switch?
@TheEmbeddedHobbyist
3 жыл бұрын
Do you need to debounce a stop switch (title), as it only has one function to stop. So on the first change in state to the stop state is all you need. I would not care if it bounced as I would have killed the process there and then. Plus I would do the stop switch in hardware just in case the software was playing up. Now a start/stop switch (text) and most other mechanical switchs needs to be debounced as moving contacts just love to bounce. How about the leaky bucket method of holding the high's, if you keep putting highs in the bucket will fill after a time, so you have a high, if you stop the buckit empties and you have a low. as it bounces it just goes up and down a bit but ends at one state in the end.
@DavesGarage
3 жыл бұрын
If it's a latch (stops and never restarts), then no. It a switch only enters and never leaves a state, I guess you'd not need to at al!
@dmzar
3 жыл бұрын
Be careful! It depends on what you do when you detect the switch contact. For example, are you setting an interrupt? Is there a limit to the number of interrupts per second of your CPU? What if you are logging messages when the button is pressed? How about sending messages to other processes (much like the ISR case)? This is a common error when doing debounce work. I think Dave will do it right and solve for the general case of debouncing a switch and then it will always work as intended even if you only use it as a STOP switch and do something really simple (like terminate your program). But it won't break when using it in other ways and whoever users your code next (which could be you five years from now after you forgot what you did) will thank you!
@TheEmbeddedHobbyist
3 жыл бұрын
@@dmzar I normally read a STOP switch as "it stops all what it's doing as fast as possible" like in an emergency stop! Where I want the stop acted on as fast as possible. So the stop interrupt won't get re-entered as it will stop all required actions and halt. So interrupts may be still disabled. So a reset may be required to get it running again. Maybe it's a UK / US thing.
@dmzar
3 жыл бұрын
@@TheEmbeddedHobbyist I was thinking from the other side where I am building a debounce circuit (code) that could be used everywhere we do want to read a key/button. In that case, we should not design it to only work in a specific case or two (or there or...). Make it general so that if you used my code, it would do what you expect without you having to read my code nor ask me under what circumstances it works. To be clear, I have done what you propose at times, but in recent years, I always debounce such signals, too, as it rarely hurts. But if you care about absolute latency, I could see not debouncing emergency stop signals under the right circumstances ... but I would document that clearly. 😀 I've seen too many systems hang when someone wanted to terminate them... And by hang I mean: continues to operate at some level with no way to stop it without physically removing power. Yikes!
@TheEmbeddedHobbyist
3 жыл бұрын
@@dmzar I've worked on medical systems where our H/W made the decision to kill the power to the heater then flagged the fault, better to get the latency of the software out of the way. Patient safety first! Plus it’s easier to test the hardware than it is the software. A side issue with interrupts is they make the software impossible to fully test, so polling is better but that increases the latency further if your fault occurs just after you polled that input. With interrupts; they can be triggered in any part of the software flow, therefore it’s impossible to perform an interrupt after ever instruction to test for run time errors. Had a fun year doing software V&V never again.
@92gunnerjoe
4 ай бұрын
youre good at this programming stuff, you should do it as a job
@domk0m
3 жыл бұрын
hello
@_c_e_
3 жыл бұрын
world
@6754bettkitty
3 жыл бұрын
jello
@lucidmoses
3 жыл бұрын
When I did this for a COCO computer keyboard. I did, First on sends the signal and then sets a cool-down timer. That made the code small and faster. Also, are you sure the IRQ could be called twice? What ever is doing the line polling likely has a frequency and some smaller cpu's can't send another IRQ until the existing one returns. In the coco project this was the case because we were using one of the computers timing interrupts (memory refresh if I remember). But maybe yours can.
@perwestermark8920
3 жыл бұрын
Some processors allows nested interrupts. Some do not. It isn't uncommon that the ISR needs to explicitly tell "ok - nesting allowed" to allow multiple interrupts. At least for the very same source. But the critical section wasn't really for nested interrupts but to make sure to synchronize access to variables shared between ISR and the polling code.
@lucidmoses
3 жыл бұрын
@@perwestermark8920 The critical section is just an easy way to make the code reentrant. There are other ways to do it but I guess he has the cpu power to spare so no big deal. In hardware you do have to setup the irq jump address. I don't think that's what he's doing. That looks more like a library call that's dealing with the hardware. But ether way, the actual hardware or the lib he's using may already single execute the interrupt response code.
@perwestermark8920
3 жыл бұрын
@@lucidmoses The critical section in the ISR makes sure the access to global state is serialized. It doesn't matter if the processor supports reentrant interrupts or not - the critical section is still needed. Note that the ISR assigns state to three variables - and two are int which means they may not even support atomic assign depending on processor. And the method CheckForButtonPress() uses the same mutex (_mux) to be able to read out the current state of these three variables in a consistent way, without the ISR breaking in during the read. Without the critical section, the ISR could trig, and change state of one or more of these variables while CheckForButtonPress() is busy reading them. So if the processor supports reentrant interrupts or not, you still need to protect and serialize access to variables that are processed by both an ISR and main code. Or in case of using a task-switching OS, to serialize access to the variables between different tasks. The compiler will not understand that the underlying hardware may suddenly jump away and run some other code in the middle, that will magically change some of the variable states - hence the need for a mutex. Mapping address of the interrupt service handles are done at 5:40 in the video - line 182 to 185. Somewhere there is a LeftTurnISR() helper function that will call the ISR method of the proper C++ object, i.e. g_LeftTurn.ISR().
@lucidmoses
3 жыл бұрын
@@perwestermark8920 reentrant refers to how you code something. It's how you coded your function. It means you can call it twice before the first time you called it returns and everything will be ok. It has nothing to do with why it's called. i.e. multi threaded, hardware irq, software irq, OS/Lib call backs or whatever. Critical section is just one way to help you making your code reentrant. There are plenty of others. The attache interrupt call is exactly why I stated it looks like he is using a library. Actual processor interrupts wouldn't be coded like that. But I can't be 100%, I've not used an Arduino.
@perwestermark8920
3 жыл бұрын
@@lucidmoses No need for describing the meaning of the word reentrant - this is my profession since a huge number of years. Making the ISR reentrant just happens to be a side effect of the mutex code. And no - critical sections aren't just there to make code reentrant even if they can result in reeentrancy as a side effect. There are more than one way to create a critical section - in this case it is implemented using a mutex. And that mutex is used to synchronize access - but these accesses doesn't need to happen in that same routine. That poll code isn't reentrant but must synchronize variable access with the writes done in the ISR. And I'm almost 100% sure the ISR isn't configured to allow reentrant interrupts, even if Dave mentions reentrant in the video. So most likely, the ISR does not need any protection to make it reentrant. But the ISR *must* synchronize with the main loop. And that happens through the use of that mutex. That _mux aka mutex means "mutual exclusion". So any parts of code sharing variables that gets updated in a task-switching manner (multiple threads or in this case ISR and main loop) needs to make use of the same mutex. All to guarantee mutually exclusive access to these three shared variables. In many cases, it's enough to have a C-style function with some compiler-specific keywords like __isr to have the compiler supply the additional code lines to protect some processor registers etc, so it's seldom a library is needed. If the compiler doesn't support any magic "isr" attribute, then the setup code needs to be in assembler. It's more common to need to write own code if allowing nested interrupts, by acknowledging the current interrupt so the interrupt prioritizer hardware knows it's safe to sample that (or other) interrupt sources and issue new interrupts. Some processors like ARM Cortex-M3, have automatic hw support to set up the ISR context - so there is no need for any assember code or any magic "isr" attribute - it looks and behaves as a standard C function. In the end, we all uses libraries - own or others. It's boring to write 10 lines of code to initialize a GPIO as input with pull-down if a single function call can be used. It's boring to write 10 lines of code to set the ISR address, configure the priority and enable the interrupt source when a single line can be used. Why don't I belive the code needs a reentrant ISR? Because most ISR aren't written to be reentrant. And if the prologue code acknowledges the interrupt source to allow the interrupt priority controller to sample and issue new interrupts for the same interrupt source, then you can have a situation that interrupts happens faster than the average ISR execution takes - with the net result that you crash the program with a stack overflow. So this is not a good generic implementation of an interrupt handler - more something you create if you really needs it but when you at the same time have control of the amount of nesting you may suffer. This isn't good logic to have in any generic library. Dave's code primarily needs to process the latest pin change interrupt - it isn't important to care about the actual number of bounces. So adding complexity for that just isn't needed - that is also why the code was changed from counting number of interrupts to instead just having a bool variable to tell if at least one pin change had been handled since previous time the poll code cleared that flag. What is way more common is to allow traditional nesting of interrupts - i.e. that a higher prioritized interrupt may trig while a lower priority interrupt is still being serviced. In this case, there is a limit to amount of stack needed since there is a limit to number of different interrupt sources and interrupt priorities. But for nested interrupts, each individual ISR doesn't need to be reentrant. But nested or not, reentrant or not, the rule is still the same - access to global variables needs to be synchronized between ISR and main code. In some situations, it may be enough to tag variables as volatile but for the more general case, a mutex is normally needed.
@KG5IZE
3 жыл бұрын
+++ more
@forcebewhithyou94
3 жыл бұрын
Usually, you tuber use a link to the code, Dave is too smart to let this happen?
@manojstriker
3 жыл бұрын
Can I get Source code? 😎
@dtiydr
3 жыл бұрын
"Turn of the YMCA mode" xD
@mytech6779
2 жыл бұрын
Golly, I'd slap on a $0.50 thermal-interupt osillating switch and call it a day...
@Darklor_WCF
3 жыл бұрын
YMCA mode. rofl
@bruceliu1657
3 жыл бұрын
hard were list plz
@tikabass
3 жыл бұрын
Why not simply poll the switch every 30ms, be done with it, and have enough time in your evening for one more beer (or a cuddle with your favorite person) ?
Пікірлер: 105