Hi everyone, i have done very complex and simple thing with both pic and atmega microcontrollers. The ease of use of atmega chips are great but a question bothers me. Why PIC interrupt requires only 1 current limiting resistor to input pin and the arduino or any atmega based board needs even a schmitt trigger to work stable. I can directly connect a pin to a button with current limiting resistor in PIC and enable the interrupt and thats it. It works perfectly with no triple trigger per push or ghost push. But in arduino i need to put a RC filter and schmitt trigger to make it robust and as good as pic. Why is this happening ? I am not trying to put dirt on atmega i just dont understand. No one points out to this. And this is just an example btw. There are other problems like library efficiency etc in arduino but thats my lazyness of not writing the code myself and use a general library. Please if you can point me to the right direction i would like to know the roots of this difference. Whenever i decide to build a project using arduino it works very quickly but then the bugs start to reveal.
My ATmega boards don't need that. Maybe the rest or your circuitry isn't correct?
On an ATmega you don't even need a current limiting resistor.
If that's true, then interrupts must be ultimately slow on the PIC.
Probably because on the ATmega an interrupt is handled quite fast usually so the usual mechanical bouncing of a button or switch triggers the interrupt multiple times.
I have some doubts that this is because of the MCU choice. There are differences between the processors and I don't know the PIC very well (only did 2 or 3 projects with it some years ago) but I'm quite convinced they differ only in details except the way they are programmed.
Your hypothesis is scrambled-eggs.
The reason that AVR and PIC are different is because the scientists and engineers that built those microcontrollers had different objectives and different marketplaces.
Business/engineering decisions are made for a line of product to satisfy a market and hardly makes sense to outsiders because the outsider is unaware of corporate-proprietary secret marketing and technical capabilities.
Now that Microchip Technology owns both products, we are seeing changes in the actual AVR'ish products being released.
Practice makes perfect, or at least, better. Keep at it!
I wanted to know what is the difference. Since you didnt use pic as much as atmega, doesnt it a blind guess to this point ? For example i put a current limiting resistor for safety not for requirement but you missed the point that it does not work properly in atmega chips with only current limiting resistor. I need to debounce the input and if the input is high frequency, i then need to put a schmitt trigger. No need for that in pic and i just wanted to know why.
This actually makes sense. How can i study the speed comparison of two uc family ? It would be great if you could just point the way.
A button push doesnt need 100 kHz speed but i get the point and as far as my experience, didn't have problem with speed.
Thats the point, only change i make is the microcontroller and pic runs it as i designed and atmega does not. As i said before, atmega chip might be handling the interrupts much faster. But i would like to study and see the numbers if you can point me to right direction.
As i know(correct me if im wrong) both execute commands line by line using internal or external clock signal. Time required to complete 1 line might be different for pic and atmega and this might be the cause. Nick Gammon was posted a study on this if im remembering correctly. I will look in to it but i dont know a reliable source for pic.
Thats what i asked. What is the difference that make atmega more sensitive and fragile then pic. Ofcourse they are designed in different aspects. Im asking what are those aspects that causes sensitivity difference..
As an EE, there is absolutely nothing to suggest that AVRs are "more sensitive" or "more fragile." My guess is you are just more comfortable using PIC.
Have you compared the PIC assembly code to the AtMega assembly code?
The PIC16 chips, at least, have an internal Schmidt trigger on the External INT input. It appears that the atmega328 does not. Maybe that is the difference.
If you're speaking of the pin change interrupts from a typical GPIO pin, I don't know what the difference might be.
this is the reason ! I am relieved. I do it externally and it bothers me on avr. Now it will not. I will compare input and output schematics of both uC. Thank you very much ..
You're welcome. Maybe that will help make things clearer.
It seems to me that all the ATmega328 pins have a Schmitt trigger.
https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf - on page 59.
I can't determine from the data sheet what happens to the 328 signal after it is squared up by the Schmidt trigger. Without a low pass filter before the Schmidt, there will be multiple pulses from a bouncing input. The "synchronizer" will capture either a low or a high and pass it on to whatever circuitry is down stream. The drawing on Page 63 of the data sheet shows a signal from before the latch going down stream. Maybe these two signals are used to determine whether the interrupt is level triggered or edge triggered.
The PIC drawing is equally missing some key detail for me. It does illustrate that there is a separate path for the signal when the pin is programmed to be an interrupt input, but it doesn't show what happens to the signal "deeper" in.
Do you mean a pull up resistor ?
I have never heard that PICs are immune to contact bounce on their input pins.
Which PIC are you using, and what software environment? It could matter - for example, the SAM3x8 on Arduino Due has some fancy filtering on inputs to take care of bouncing in hardware.
No i meant current limiting resistor as in series with input signal and input pin. Thats just a precaution not requirement.
PIC18 series, mostly 18F452 and 18F4xk2x depending on the application and memory requirements. I am using mplabx ide and xc80 compiler with paid optimization for memory. I just assembled a board processing a signal from a source that generates 10 ms period signals. I determine the signal width and do things accourding the data. Thats not relevant. The relevant thing is, exactly the same setup needs RC + schmitt trigger to work correctly with atmega 2560 based board. Sometimes there is not an easy or cheap availability to pic or atmega chips around where i live. So i make different microcontroller based boards for the same job so that i dont have a loyalty to a certain brand or model. Atmega based boards cost nearly twice due to external components. A reply suggested that atmega uC is so fast that it can detect the bouncing signals and pic is slow and this acts like debouncing. I compared the datasheet and as previously stated their input signal processing structure are almost identical ...
Working correctly means there will be no ghost trigger and false signal width determination. It works without RC + schmitt trigger but it fails time to time. This is a HUGE thing for my application even 1 signal cannot be processed wrong.
I have trouble believing this. I've followed both PIC and AVR since forever, and I've never heard even rumors that the AVR has this sort of problem.
I'm suspecting that there is something else wrong with your circuit or firmware, perhaps due to a misunderstanding of the Arduino framework (assuming that you're using Arduino on the m2560, rather than bare C or assembly language.)
Your soapbox is full of holes: you make statements, reference your projects and coding, but outside of your attestation, there is no hard evidence; scope traces, sample code, logic printout.
You blast AVR microcontrollers and promote PIC: products owned (for many years) by the same company.
Every EE that does hardware qualifications deal with manufacturer's reference manuals and real-world lab validation directed at specific performance and behavior in a design. Even when concerns are identified, higher authority will often select the inferior part if the EE can mitigate the concern(s) economically or with creativity.
Everyone here has a (reasonably) open sounding board and your being vocal for PIC and down on AVR is certainly permitted within the scope of forum rules. But if you have hard evidence, something you can prove, maybe you can take it to Microchip Technologies. Repeating the same old concern over and over is not some magical chant that will summon a hardware fix and my belief is few (if any) in the forum cares because hobbyists and weekend Arduino users are going to utilize software debouncing anyway.
Ray