-
Notifications
You must be signed in to change notification settings - Fork 0
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
Activate reading FBus based on serial interrupt #9
Comments
I added a process() routine that checks the queue and processes all bytes when it sees some. This process() routine should be called in the loop() routine. We might want to rename it loop() to make it more clear |
Rename process() to loop()? Does that create conflicts with the default loop() function in Arduino? |
No, this loop will be in the class |
Okay, so this would be addressed with my |
Yes. We could add interrupts, it would be pretty straight forward but it would make it more difficult for the user to switch serial ports. Based on the AttachInterrupt() page (https://www.arduino.cc/en/Reference/AttachInterrupt) the interrupts are constants, we could have a #define that says which serial port we are using, but passing the Serial1 object on class creation seems a little cleaner. We could also look into something in the serial class and attach the interrupt automatically |
SerialEvent() is interesting. It's not an interrupt driven function, but it's called after loop(). This post states, "The serial data is captured using an interrupt to put each character into the serial input buffer. If you add any additional processing to that interrupt or trigger another interrupt then you may lose incoming characters because the arduino disables interrupts when it is in an interrupt handler." I think this relates to an interrupt on one of the serial port pins. |
Each incoming FBus byte should be process individually. The process can probably run hundreds of instructions between each incoming byte. It would be good to have the incoming byte processing funciton be triggered on a serial input interrupt.
I believe that when the phone receives a text message it sends a packet on the FBus line. If this is true, a microcontroller would be able to just sit and wait until there is a serial input interrupt. Maybe on a longer loop the microcontroller would request info from the phone just to make sure it is still connected.
The text was updated successfully, but these errors were encountered: