Hello,

As I'm debugging a serial communication protocol, and the only available debugging port on my board is the one serial port I'm running the protocol on, I can't use the debugger as it interferes with my data.

It would be awesome if the debugger could create a virtual serial port used to output serial data stripped of debug information, that my host application could open and use to communicate with the board. (And obviously, the same thing would be done on the board, filtering out debugger data from Arduino's Serial.read()).

This is hackish, but it would definitely help me.

Thank you for the link. However, I'm already using a SoftwareSerial and a second one would take away way too many processor cycles.

I'm testing this on various hardware. Right now I'm having difficulties with a custom board based on the ATmega328P (same as Arduino Uno).

I'm not sure what you're asking me about the code.

Just to clear things up, this was a feature suggestion for an edge case. If this can't be done it is not really a problem, I'll just test on another board and then port the code 

What I had in mind for the implementation was either hooking into Arduino's library with custom code or substituting the Serial.write() and .read() calls in compiled user code to pass through a shim implementing the filtering functionality.
(This would provide, as a side effect, a way to easily implement an escaping mechanism to avoid mixing up debug information with other data, which is something that as far as I can see is not being done now)

On the computer side I have no idea whatsoever as I don't know how VS plugins work or how your plugin works specifically. But I guess it would be easier, as the filtering functionality is already up and running for the serial console, the only thing to work out would be the virtual serial port. Afaik there are loads of products that offer OEM options with different licensing options (e.g. com0com and Eltima, if they are still alive).


This has become a bit of a flight of fancy, but I'll still post it. Maybe you can get some ideas out of it. 

Visual Micro wrote on Jul 15^th, 2017 at 10:27pm:


I haven't actually tried this but I suspected this was the case.
It may be over-engineering but it should definitely be possible to implement this by way of a transport protocol over serial. You could make use of already-existing Arduino abstractions to make it work without having to write too much platform-specific code. I don't see it as a problem as you're obviously already injecting code to make the debugger work. I was thinking about something along the lines of hooking all the Serial.read() and Serial.write() function calls, placing your transport layer* between those and whatever Arduino already does to read and write serial data.

*which in principle could be as simple as "the next n bytes are for [the debugger|the user's code]".

Only problem I see is that this is way too much work on edge cases stuff for a one-guy company. So, again, flight of fancy  maybe one day.

Thank you for your continuous and precise responses, by the way! Awesome product and awesome communication.

The data would be physically transferred through the only serial port available, that would at this point be used for programming, debugging and exchanging data between the Arduino code and the user's PC program.

I made you a drawing!

https://www.dropbox.com/s/3ulziiynjwn0xy8/2017-07-16%2017.22.41.jpg?dl=0

When compiling code with "Debug" target, you change every debugger-injected code's Serial.write(...) to TransportLibrary.write(TYPE_DEBUG, ...) and every user program code's Serial.write(...) to TransportLibrary.write(TYPE_USER, ...). This function would encapsulate whatever payload it's given into an hypothetical transport header (see drawing) that would indicated whether the payload has originated from code that the user has written or code the debugger has generated.
At this point, on the computer side, the debugger is attached to the serial port, and receives the header and the payload. It de-encapsulates and demultiplexes i.e. if the header had TYPE_DEBUG it keeps the payload and processes it exactly as it does now and if it had TYPE_USER it prints it on the serial console/relays it, depending on the settings, exactly as it does now.

The same principles apply the other way: what's typed into the serial console or received by the "relay" serial port is encapsulated with TYPE_USER, what's written by the debugger for the injected code on the Arduino is encapsulated with TYPE_DEBUG, and on the Arduino Serial.read(...) calls are replaced by TransportLibrary.read(TYPE_whatever, ...) which de-encapsulates and demultiplexes Arduino's receive buffer into two separate debug & user buffers and returns the data from the right one depending on the TYPE parameter.