Add #define to support moving serial to UART1

[vintagepc]

This adds an alternate wiring option to route the serial output from USB to UART1 (the TX/RX pins on the white 10 pin header)

To use:

• #define (uncomment) USE_UART1_SERIAL in HardwareSerial.h
• Change SERIAL_PORT from -1 to 1 in Configuration_A3ides_2209_MINI.h

[Turro75]

Thanks for the commit, I'm trying adding it to 4.3.0 branch but no way to get TX working, I moved your code to usart6 to enable the esp8266 serial comms but I get the same, receive is fine while transmit does not work. Any idea?

Edit : Sorry I mean the buddy is able to send strings outside, the problems are the receive buffer.

[vintagepc]

I can't say for sure without seeing your specific code changes, but the built-in Marlin is not equipped to handle the DMA receive interrupt or buffers by default (uartrxbuffer doesn't support the required functions that check whether data is available). Make sure you have disabled that for UART6, else the data will get shuttled away before it ever sees an RXNE flag.

[Turro75]

I'm getting the same problem even on uart1 by using Your commit, does it works on your side?

[vintagepc]

Hmmm... I have not run it on real hardware but I do know it works on simulated hardware.

[Turro75]

Ah that's probably the reason, can You kindly address me a page that explains how to setup eclipse to debug this? Switching to another ide isn't a problem to me.

[vintagepc]

Sorry, the hardware simulation is a (temporarily) private project that is not yet ready for public release. Eclipse's support for the STM32 platform is basically limited to GPIO and is not usable for this.

[Turro75]

ok no problem, in case You want to send me some bbf to test on a real device I'm here.

Best Regards

[vintagepc]

Thanks, I'll keep that in mind. My best guess why it many not work is probably some missing serial port/uart configuration since these ports are not used by default.

[Turro75]

Well,

I understood what is the failure, setting in cutecom a delay of 2msec between each char allows the buddy board to successfully reading all chars. So this PR provides a functional but slow code, may be the switch to a buffer where data are appended by IT or DMA will be the solution then Marlin can pick one char at a time without the risk to skip something.

[vintagepc]

That is possible but does require further work to uartrxbuffer to support checking the level.

[Turro75]

I found a working code for uart6, anyway unless this #1076 won't be implemented wireless serial interface is quite useless

[vintagepc]

ok no problem, in case You want to send me some bbf to test on a real device I'm here.

Best Regards

I'm happy to announce that said project being private is no longer the case, if you are still interested :)

https://github.com/vintagepc/MINI404

[OJFord]

Sorry, this is a tangential question, but it seems like you'd know (and is potentially related in the sense that if 'yes', I'm also interested in configuring it differently): is the serial port hard coded to the micro USB on the Mini, in the released 4.3.1?

I have an ESP8266 device connected and seemingly working (spewing gcode from Octoprint if I plug it into my computer instead of the Mini) but it has full-size USB type A only, and in that port of the Mini it can't connect.

I then noticed the Octoprint guide mentions the Mini's micro USB port (which I hadn't even noticed it had until then, heh.) but doesn't say why / if that's the only one supported? The guide also expects you to be connecting a RPi directly, for which a USB A -> micro would be more natural I suppose, so I'm not sure if it's just an arbitrary choice; may as well leave the bigger port free for flash storage if you can sort of thing.

I don't know (because I don't know the physical mapping of USART6?) if this is the same issue @Turro75 mentioned in #1246 (comment) above?

Cheers.

[vintagepc]

If I'm understanding your question correctly, then no, the full-size USB port does not support anything other than USB drives. It explicitly expects a mass storage device (can't even connect a hub) unless you make significant alterations to the firmware to swap the ports (and I'm not even sure if that would work given it lacks the 5th OTG sense pin to determine if the connection is supposed to be host or device-mode (in other words, who "owns" the bus)

You might have some success with some variant of this though to adapt your ESP until such time as the internal port becomes usable:
https://www.amazon.com/UGREEN-Adapter-Samsung-Controller-Android/dp/B00N9S9Z0G/ref=sr_1_4?dchild=1&keywords=usb+a+to+micro&qid=1624115593&sr=8-4

[OJFord]

Great, thanks. Of course, I would've just checked it if I had/could've found an adapter like that, but wanted to confirm that was the issue before buying (and waiting for) one. Many thanks!

[vintagepc]

No problem. Hopefully we'll see some ESP movement soon given the hints about PrusaConnect they've teased in recent livestreams :)

[teotwaki]

@vintagepc Is this PR still relevant? If not, could it be closed?

[vintagepc]

Closing, the changes are stale.