* clear newtimeout_pending flag
* fix initial newtimeout_pending flag value on win32
* remove all _atomic as anyway a load+clear wouldn't be atomic and we're not in a critical situation: just one writer seldomly called on reconnect
* move new timeout poll to uart_recv for faster deployment
* remove redundant uart_reconfigure_timeouts(UART_FPC_CLIENT_RX_TIMEOUT_MS);
* using WITH_FPC:
* activate basic usart
* no double buffer for now, no interrupt
* usart_dataavailable/usart_readbuffer/usart_writebuffer, to demo it:
* pm3 client over USB, minicom over usart
* analyse a d 414243
* using WITH_FPC_HOST:
* it implies WITH_FPC as it's based on it
* control pm3 with client over usart
* EXPERIMENTAL! still some frame desync issues
* you can connect both from usart & USB with two pm3 clients
* actually you *have* to connect USB for the moment because
it's used to send debug messages about buggy usart... See Dbprintf_usb below
* "sessions": msgs are directed to the latest client to have sent a cmd
* Dbprintf_usb macro to send msgs to USB client to help debugging usart...
* We now have an option to run client at different speed as usart is 115200:
client/proxmark3 /dev/ttyUSB0 -b 115200
* Consequently, argc,argv handling is a bit revamped, it was so messy...
* USB and flashing are still at 460800, don't try flashing over usart yet ^^
* Add \r\n to sent strings
* remove usart_init() from UsbPacketReceive cmd, it's already init in main.
* Add PLATFORM PM3RDV4FPC to ease dev
* TX: US_TCR is len of data to send, not len of buffer
* Use only one PDC bank as we're using it in sync
* Busy loop to wait for end of TX as we'using it in sync
* Change usart speed to 115200
* Don't downgrade USB speed, keep 460800
* Attempt to detect received data, fail so far
On ChromeOS Linux apps can't access serial port but they can connect to TCP,
so I wrote a simple app to forward TCP to serial. I suppose this can have other uses as well.
see: 538d10d651
