I wish Serial.flush() was implemented... about opencm9.04 HOT 11 CLOSED

from opencm9.04.

Hi, @KurtE.

I just updated to the develop branch. Could you check it out?

from opencm9.04.

Hi @OpusK,

Looks like your change helps out. If I try running a stripped down version of #31 which referenced a NULL pointer before nothing would show up on the screen. Sample sketch:

#include <DynamixelSDK.h>
dynamixel::PortHandler *portHandler;
dynamixel::PacketHandler *packetHandler;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  while (!Serial);
  Serial.println("Start..");

  Serial.println("Before BOOM");
  Serial.flush();
  
  portHandler->openPort();
  Serial.println("After Boom, should never get here");
}

void loop() {
  Serial.println("How did I get here?");
  delay(1000);
}

When I run this on the current released version, nothing shows up on the screen, then everything hangs...

When I run it using your update, I get:

Start..
Before BOOM

Then it dies as expected!

Notes: In both this and the OpenCR implementations, I don't know how CDC_Itf_TxISR is triggered/called. That is, is it called by a timer? Or everytime the USB timeframe for this unit is checked... If it is like FTDI with some timeout value, than maybe would be nice to somehow trigger it NOW instead of wait for timeout... Not sure if that makes sense?

Also currently when I am building using the develop branch I am still getting debug warning on every compile line...

The last couple of files compiled:

"C:\Users\kurte\AppData\Local\Arduino15\packages\OpenCM904\tools\opencm_gcc\5.4.0-2016q2/bin/arm-none-eabi-gcc" 	-c -g -O2 -std=gnu11  -MMD -ffunction-sections -fdata-sections -DARM_MATH_CM3 -DUSE_HAL_DRIVER -DBOARD_OpenCM904 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10805 -DARDUINO_OpenCM904 -DARDUINO_ARCH_OPENCM9.04    -mthumb  -DSTM32F103xB -D__OPENCM904__ "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/bsp/opencm" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/bsp/opencm/include" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw/driver" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw/usb_cdc" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/lib/STM32F1xx_HAL_Driver/Inc/" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\cores\arduino" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904" "C:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904\lib\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.c" -o "C:\Users\kurte\AppData\Local\Temp\arduino_build_880127\core\lib\STM32F1xx_HAL_Driver\Src\stm32f1xx_ll_usb.c.o"
<command-line>:0:21: warning: ISO C99 requires whitespace after the macro name

"C:\Users\kurte\AppData\Local\Arduino15\packages\OpenCM904\tools\opencm_gcc\5.4.0-2016q2/bin/arm-none-eabi-g++" -c -g -O2 -std=gnu++11 -Wno-write-strings  -MMD -ffunction-sections -fdata-sections  -fno-rtti -fno-exceptions -DARM_MATH_CM3 -DUSE_HAL_DRIVER -DBOARD_OpenCM904 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10805 -DARDUINO_OpenCM904 -DARDUINO_ARCH_OPENCM9.04     -mthumb  -DSTM32F103xB -D__OPENCM904__ "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/bsp/opencm" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/bsp/opencm/include" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw/driver" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw/usb_cdc" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/lib/STM32F1xx_HAL_Driver/Inc/" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\cores\arduino" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904" "C:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904\main.cpp" -o "C:\Users\kurte\AppData\Local\Temp\arduino_build_880127\core\main.cpp.o"
<command-line>:0:21: warning: ISO C++11 requires whitespace after the macro name

"C:\Users\kurte\AppData\Local\Arduino15\packages\OpenCM904\tools\opencm_gcc\5.4.0-2016q2/bin/arm-none-eabi-g++" -c -g -O2 -std=gnu++11 -Wno-write-strings  -MMD -ffunction-sections -fdata-sections  -fno-rtti -fno-exceptions -DARM_MATH_CM3 -DUSE_HAL_DRIVER -DBOARD_OpenCM904 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10805 -DARDUINO_OpenCM904 -DARDUINO_ARCH_OPENCM9.04     -mthumb  -DSTM32F103xB -D__OPENCM904__ "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/bsp/opencm" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/bsp/opencm/include" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw/driver" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/hw/usb_cdc" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/lib/STM32F1xx_HAL_Driver/Inc/" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904/" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\cores\arduino" "-IC:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904" "C:\Users\kurte\Documents\Arduino\hardware\opencm904\opencm9.04\variants\OpenCM904\variant.cpp" -o "C:\Users\kurte\AppData\Local\Temp\arduino_build_880127\core\variant.cpp.o"
<command-line>:0:21: warning: ISO C++11 requires whitespace after the macro name

from opencm9.04.

Hi, @KurtE.

In both this and the OpenCR implementations, I don't know how CDC_Itf_TxISR is triggered/called.

For OpenCM9.04, TxISR() is registered with the software timer when CDC_Itf_Init() is called.

For OpenCR, it is called by HAL_PCD_IRQHandler().
HAL_PCD_IRQHandler() called HAL_PCD_SOFCallback().
HAL_PCD_SOFCallback() called CDC_Itf_SofISR().
CDC_Itf_SofISR() called CDC_Itf_TxISR().

I am still getting debug warning on every compile line...

In this regard, we will commit later.

from opencm9.04.

Thanks, my earlier search on OpenCM did not find some information, probably had query options set bad...

So it looks like, CDC_Itf_TxISR is called every 5ms, and if there is anything in the TX buffer it is sent out at that time. Minor note: looks like if the in pointer wraps around, the Output will only output that part from the current out pointer to the end of buffer and then wait for the next timer to output from start of buffer to whatever the in pointer is at that time...

As for the Warning, I assumed you already was aware of it, but thought I would mention it, in case...

from opencm9.04.

You are right.
Since TxISR() is executed every 5ms, it may happen that depending on the situation, it may wait for 5ms.
We could change this to 1ms, or use another timer or change it like OpenCR.

As for the Warning, I assumed you already was aware of it, but thought I would mention it, in case...

I have not used OpenCM 9.04 very often, so I have not noticed the warning problem!
Your report has helped me :) Thanks again for your contribution!

from opencm9.04.

It looks like the the OpenCR version is more advanced. Hard for me to say if it is worth it for you to do it on the lower end boards. Especially since I am not very experienced with the STM32 layers and hardware.

I know on the Teensy boards, the USB code works a lot differently. Maybe partially as the USB can be configured to act like a Serial port, or Mouse, or Keyboard, Joystick, MIDI, RAW and several combinations of these. With the Serial write code on these devices. The Serial.write code is setup to start filling a buffer, if it has enough information to fill a USB Packet (I believe your code is setup for 64 data bytes?), it then allocates a USB data buffer, and schedules it to output on the next USB slot, if there are more than one full packet available to output, the ISR code will see that there is additional packets, if so will schedule the next one into the next free USB frame...

With each write, if there is still a partial frame of data, it will reset the timeout counter, back to the initial value. Only after there are no more calls to Serial.write for the timeout period or the user calls Serial.flush , will it output a non full frame. But again very different setup done by Paul of PJRC... Sorry for being slightly off topic 8)

For this one, what you put in is probably good enough. As it solved the problem of not being able to force the print statements to show up before code crash...

But wonder if maybe it would make sense? to potentially have a swTimer function like:

swtimerTriggerNext(uint8_t TmrNum),

Which maybe sets: wtimer_tbl[TmrNum].Timer_Ctn = 1;

So it forces it to call of on the next counter... Maybe need to protect the setting of variable, although I suppose that even if the ISR happened before we set this, then we set it to 1, it would simply call our function and see there is nothing to do... So maybe not too bad. But again maybe not worth the risk or effort.

from opencm9.04.

I will discuss this with the people involved.

As you said, we will need to first determine the value, opportunity cost, and priority of this update, considering our resources, the limitations of the OpenCM 9.04 CPU, the nature of the firmware, and so on.

from opencm9.04.

Understood, I might play around some, to see if it can help. Where I can see it helping out, is if for example I wish to use an OpenCM board like you do the OpenCR board talking with other board like RPI and working like the servo controller, like the R++2 code (Restore firmware), Is the Source for this some place?

Where I can see that when the 904 sees the response packet from servos and forwards to USB, it would be good to flush it out after the full packet has been received from Serial1 or Serial3...

I played around with test Example program, where I output when servo revolution was seen, or if I turn on output position data. To the app, I added a Serial.flush() after these messages. You can see the result of this on the Logic Analyzer...

The top two lines are the USB traffic. The third line is data on DXL of Serial 3... You can see the Serial packets going one after another until the Serial.print()... Serial.flush() and then you see up to the 5ms delay. During that time you can see all of the USB traffic, each gap there is a USB frame. Maybe does not show up easily in printout but the last one before the next data shown on DXL is wider as it shows the actual packet showing the text...

Minor NIT probably not worrying about is it is showing new data actually going out Serial3 before the actual USB output has been fully output. That is we actually only wait until we have called: USBD_CDC_TransmitPacket, not when the hardware has actually output the packet. Again not worth trying to fix this.

from opencm9.04.

@OpusK ,

Quick update on my playing around:

I tried making the code more similar to the OpenCR board. And instead of using the 5ms timer to flush the Serial data back from the OpenCM board to the host, instead tried turning on the Start Of Frame(SOFM) interrupt and then do like OpenCR and output on the next frame... First tried turning on and leaving it on... It appeared to interfere with the code reading results back from servos (or maybe I screwed something up...), Tried turning the SOFM on and Off. That is anytime you called: Serial.write() it turned it on. The code then turns it back off after the SOF interrupt is processed... Still had issue.

So for now will punt using this technique. I put this in a new local branch on my machine, which I have not published back to github... Can if anyone is interested...

Next up, maybe see what happens if maybe change 5ms to maybe 2 or 3ms. And/Or maybe have flush update the timer counter to 1, so the write would happen on the next ms...

Again all of this is probably out of the scope of this issue. So you could easily close it if you like and if anything looks promising, could either reopen, or open new one, or simply do a Pull Request.

from opencm9.04.

@KurtE,
This issue is currently underway to PR, so can I close it?

from opencm9.04.