chSequentialStreamRead issues

[Rick Burnett]

I'm not sure what I am doing wrong here.

I have a device (Xmega) sending to the STM32F4 at 9600 8N1 verified (with scope).

Right now I just have a chSequentialStreamRead then calling chprintf and sending the individual bytes out.

Code: Select all

static THD_WORKING_AREA(waCheckSerialThread,256);
static THD_FUNCTION(CheckSerial,arg) {
  (void)arg;
  uint8_t serial_val;
  chRegSetThreadName("CheckSerialThread");
  ser = (BaseSequentialStream *)&SD1;
  while (1)
  {  chSequentialStreamRead(ser,(char *)&serial_val,1);
     chprintf(ser,"%c",serial_val);
  }
}
     

If I send 1 single byte from my other processor, it gets it every time. If I send a string of them, I notice that most of the time it gets them, but then just stops at some point and never starts again in that transmission group (meaning sending them out as fast as possible on the other processor).

When it echoes them out, they are always correct. Just don't understand what could happen to prevent it from continuing to get them and not stopping.

Could this be a buffering problem?

Am I using this code incorrectly?

This is how I am setting up the serial pins (and driver):

Code: Select all

 const SerialConfig serial_cfg = {
      9600, //bitrate
      0, //CR1
      0, //CR2
      0, //CR3
   };

   palSetPadMode(GPIOA, 9, PAL_MODE_ALTERNATE(7));
   palSetPadMode(GPIOA, 10, PAL_MODE_ALTERNATE(7));
   sdStart(&SD1, &serial_cfg);
   chThdCreateStatic(waCheckSerialThread, sizeof(waCheckSerialThread), NORMALPRIO,CheckSerial,NULL);
   

Just not sure what to check next. I have basically a 2k resistor (2 1k in series) between both chips as I wanted to have over-current protection. For 9600 that should be absolutely fine (and the waveforms are fine on the scope).

Thoughts?

[Rick Burnett]

Hmmmm, digging deeper in the forum it was seem that I am probably getting overruns given I have ADC and timer code going on as well driving a DAC at 39k, thought I have not checked the flags yet.

Before I start to run down that thread of information, I guess I am just not getting the concept here. What I was trying to do is have the serial thread have a buffer that fills up with incoming data. I wanted to poll for that data and if it exists, pop it off that buffer as I need it.

Why I do that is the first byte I receive tells me how many more to consume.

In this case, I need to read about 48 Bytes after that first one. However, if the system is doing something else like the DAC thread, it could be busy for a bit, which I can see would cause an overrun.

I could change my code to pull as many bytes as I know I will be getting. But, that wont solve if something else is active at the time and it starts getting data.

Is there a way to control the internal buffer size?

I want to keep the timer EXACTLY being called 39k a second so I don't want the serial to change any of that.

[Rick Burnett]

Now after a bit of debugging it seems that the issue is relative to a H/W buffer overflow. Given my DAC timer callback is eating up a substantial amount of processor time, and that the internal FIFO is small, this would seem to indicate that this is why I am getting OVERRUN errors (I am checking the flags).

Given I am already at 9600 baud, I really don't want to go slower.

I am thinking the next thing I should try is with the UART driver and DMA. I understand these single line transactions are not as efficient with DMA, but I'd be okay with a little bit of latency if it meant I wasn't getting overruns.

What kind of limitations are there when using the DMA/UART directly? Trying to understand why I might not want to go down that path.

[Giovanni]

Hi,

The UART driver is unbuffered, data is not copied, passed buffers must not be touched until transfers are complete, this is the main difference. The synchronous API should not be particularly difficult to use, callbacks are a bit more tricky as usual. The driver is much more efficient of the serial driver when data is transferred in blocks instead than few chars at time.

Giovanni

[Rick Burnett]

After spending more time thinking about it, I put the serial UART IRQ priority at 3 and the GPT IRQ at 4. Then I sent A LOT of serial over the line and I am happy to report that I am not seeing any issues with my code. Given I just need to make sure the H/W FIFO doesn't overflow, and now that does not happen, the impact on the GPT seems to be negligible. (And the conditions where I am sending a large number of serial bytes, I reset the DAC anyways).

I guess one of the big balances with RTOS is priority, I seem to struggle with it quite a bit when I am really pushing the CPU. At least I am getting better at it!