Has anyone else had the problem with remote debugging on Raspberry pi where serial events do not fire. Command to send data does work, but the DataAvailable event never fires.
Windows 10 -> RPi 3, 3B
Remote debugger for ARM desktop
BTW, compiled versions do work, and remote debugging using the same settings work when remote debugging on a Linux Mint box.
Any ideas would be greatly appreciated!
I have not noticed that issue, almost all my serial is raspberry.
tested on v16r3, 19r1.1 and 19r2 (only using API 1).
using Mac 10.13.6
but I do not do any processing in the event and break at the method called from the event which handles all the data parsing.
I can not actually say I ever had a break point in the event.
too late to try right now but should get chance to do so later in the day.
Thanks for your feedback Mark.
I am currently testing with a 3b+ running Buster on it. With this OS it does work.
Might have something to do with Jesse. Not really sure.
I have tested just now.
19.11 (with the code I wrote in 19r2) using ONLY API 1.
Remote Debugger Desktop 2.3, which I confess I do not know if its a new version or one from 16r3.
using ethernet in this test, normally use WiFi which works the same, its just not available right now.
Pi3B+ with mini 5 inch HDMI monitor on it.
my serial port is the inbuilt hardware port that is normally routed to the bluetooth (from version 3B+) which I feed into a USB converter, this should have absolutely no impact (but you never know) as the Pi code is talking to the USB converter not the Pi hardware as such.
My converter in this case is a Prolific chip set, again should not matter.
can not help with testing windows as I don’t have anything that runs it in real hardware.
I use DietPi (which has none of the rubbish you get with the raspbian strains) for the OS (based on some version of Rasbian from the official source) but its at least a year old (which should not be important), i do not want it updated as its effectively working as an embedded processor in read only so the SD card is never written to and can never get wrecked when the power is lost.
EDIT, sorry was typing when you posted.
second edit, I never mentioned that it break perfectly in the event!
Your setup seems similar other than I am using the UART direct to Optically Isolated RS485 @ 9600bps.
I’ll have to look at Diet Pi. I was trying to keep it all pretty much generic, although I did uninstall most all of the other apps that are included. I kept the desktop and added Team Viewer. I am curious of Diet supports the Pi 4+ version with all of the increased memory.
Thanks for looking at this - I really appreciate the confirmation. I think it just failed with the older OS…
DietPi is just a hand stripped version of the original from Raspberry.org, it supports everything the official one does and update uses the official servers.
they add a couple of bespoke bits and one good thing I like, the ram log which eliminates all SD writes so the SD card does not get mangled on power loss.
from your description I have to ask about the Pi port you are using, I had some issues at the start when the 3B+ came out.
main issue was the bluetooth addition which altered the previous standard for the port and changed the default name for serial port 1 and 2.
I was not interested in bluetooth nor a second port so I switched off bluetooth and assigned the hardware serial port to the console so there we no processor speed issues that change the baud rate of the software serial port.
second issue for me was to get the console to stop sending crud on the serial port after boot up, that was a bit of a pain for some reason but now turned off.
as it happens the Pi serial port for me is worked in two hardware modes, debug in the IDE is via a USB adaptor, in real life it is via a transistor inverter directly into a port on a PIC micro in a device I designed.
both work perfectly and it shows why the ‘legacy’ serial port is not going away anytime soon.