alt Hacker NewsCould you clarify what you mean about getting serial over the USB port in the context of debug pins?
I've been using Teensy devices for over a decade and have always had it just recognize the device as if it were a USB to serial adapter and I can talk to it as what I'd call "serial over the USB port". But that obviously doesn't involve what I think software people usually mean when they're talking about firmware debug -- which usually entails stepping through execution, right?
I'm used to just printing debug statements to the Serial.println() function, I learned on the 8051 where the best bet was to toggle different pins when code lines are passed, so even Serial.println() was a huge step up.
It wasn't specifically in the context of debug pins.
On a "normal" arduino, an FTDI chip on the board handles the job of exposing a serial adapter to your computer over USB. The atmel chip on the other side of the FTDI chip runs your code and getting serial out from your firmware is a short codepath which directly uses the UART peripheral.
On a teensy, there is still a secondary chip, but its just a small microcontroller running PJRC code. This microcontroller talks over the debug pins of the main chip, and those pins aren't broken out (at least back when I last used a teensy). Despite covering the debug pins, this chip only handles flashing and offers no other functionality. Since there is no USB serial adapter, for hobbyists trying to use it for running code with an arduino HAL, the HAL has to ship an entire USB driver just for you to get serial over USB. And this itself means you can't use the USB for other purposes.
For advanced users, this makes debugging much harder, and god forbid you need to debug your USB driver.
It's kind of just a bunch of weird tradeoffs which maybe don't matter too much if you are just trying to run arduino sketches on it but it was annoying for me when I was trying to develop bare metal firmware for it in C.