I'm a bit embarrassed asking so many questions. But there another phenomenon bothering me for which i cannot find the answer alone:
I've implemented a serial driver which puts data comming from SPI-based RF-module into an input-queue via chIQPutI() and makes it available via the serialDriver interface:
Code: Select all
static msg_t gett( void *ip, systime_t timeout )
{
return chIQGetTimeout( &( ( SerialDriver * ) ip )->iqueue, timeout );
}
In my code the following line gets very frequently called:
Code: Select all
uint8_t pocketbus_recv(struct PocketBusCtx *ctx, struct PocketMsg *msg)
{
int data;
uint8_t c;
while( (data = chIOGetTimeout( ctx->fd, MS2ST(50) )) >= Q_OK )
{
/* Process incoming characters while buffer is not empty */
// returns 1 if valid telegram
// if errors occur (crc-error, length error etc.) the loop continues
}
return 0;
}Calling thread:
Code: Select all
static WORKING_AREA(waThread2, 512);
static msg_t Thread2(void *arg)
{
(void)arg;
uint8_t rec;
chRegSetThreadName("Pocket-RX");
for(;;)
{
rec = pocketbus_recv(&busCtrlRfm, &msg);
palSetPad(GPIOD, LED_RED);
if( rec == 1 )
{
chprintf((BaseChannel *)&SD2, "payload: %s lenght: %d \n\r", msg.payload, msg.len);
}
palClearPad(GPIOD, LED_RED);
//chThdSleepMilliseconds(200); // uncomment to delay the described phenomenon
}
return 1;
}
If the first telegram passes, the function pocketbus_recv returns with 1, but after calling it again it delivers garbage without any real incoming data! The input-queue is empty at this point, but chIOGetTimeout delivers something and doesn't stop. If i pause the program via debugger the input-queue shows a q_counter of zero. After resuming the program, this thread receives one telegram correctly and after that garbage again. If i put a chThdSleepMilliseconds(xxx) into the calling thread the phenomenon takes much longer to appear (10 - 15 min).
Is chIOGetTimeout( ) not meant to be called frequently?
Thanks for hints.
P.S.
Hardware STM32F4-Discovery, ChibiOS latest trunk.
