4
My guess is that an interrupt is occurring during your reading or writing of the counter variables.
Since the variables are bigger than the native size of the registers in the CPU multiple instructions are required to work with them, and an interrupt can occur right in the middle of that work which changes the values it's working on. That can cause a mess (...
3
Your diagnostic about the interrupt handled too fast is correct. When a
byte arrives at the serial port, the start bit will trigger the
interrupt, but the byte is only available for reading once the UART
receives the stop bit, which is about one millisecond later.
to disable/re-enable the pin-change interrupt, the right way seems to
be to use the PCMSK ...
2
The AVR CPU cannot execute instructions from RAM. It's not a question of what the compiler can do or should be able to do, the physical chip itself cannot do it. There is simply no physical pathway between the RAM and the instruction decoder in the CPU.
Instructions can only be executed directly from Flash memory. That is how the chip works. You can only ...
2
I guess you are sending 5 and have the line ending set to newline only. Then everything is correct and as expected. You see 2 bytes, that are transmitted. Serial.print() will cut out the leading zeros of the byte, so all other digits before that are just zero.
The first byte is the character 5 encoded in ASCII (53 is the decimal representation of the ASCII ...
2
On an UNO pin 1 is one of the hardware serial pins. You can’t use pin 0 or pin 1 for other things if you are using Serial in your code.
Even if you aren’t using Serial, you use pins 0 and 1 when uploading your code and having other things connected can mess up that process. It’s generally advisable to stay away from pins 0 and 1 unless you absolutely must ...
2
The Serial.flush() is doing nothing. It delays until all bytes have been sent out of the UART. Since nothing has been sent it's not got anything to wait for.
The delay after the available call is very bad practice. It's a really really bad way of dealing with serial reading.
You should read this for a better understanding of serial communication.
1
The problem is the BIN in your print statement. Everything is ALWAYS binary. The BIN means to break that binary up into ascii digits 0 and 1. So if you send
Serial.print(21, BIN);
then the print function takes 21 as a binary number, 00010101 and then sends those binary digits as ascii. So what goes out on the wire is 8 separate bytes, it goes 48, 48, 48, ...
1
Yes, you can use those pins like regular digital pins on the Uno. They are numbered 0 and 1. That is... provided you do not try to use Serial.
1
This isn't the exact answer but it helps.
Uploading without avrdude is complicated and generally slow. The best solution to not using the IDE is to open and close a port then use the avrdude command that the ide usually uses.
from serial import Serial
from time import sleep
from subprocess import run
while input('Press enter to upload ') == '':
Serial('...
1
Looking at the pin configuration, the SPI pins are not in the same location as the UNO. Remove the Shield from Due and use cables to connect to the SPI pins
Only top voted, non community-wiki answers of a minimum length are eligible
