I have implemented task with software USART receiver where is call USART_bit_delay routine.
This routine is implemented with delay_us OR delay_ns based on delay_cycles(count)
delay have to be exact tick count but these routine consumes task running state time.
void readByte()
{
uses 8x bit delay function delay_cycles in ASF framework,
how can be implemented in FreeRtos delay alternative?
}
void task()
{
while(1)
{
readByte(); // function consume running state and other tasks are blocked
}
}
Looks like you’re using bit delay for sampling, so they have to be pretty precise, and I’m guessing pretty fast, much faster than 1mS. I’d suggest using a timer with an interrupt, set the timer to the sample period you want, and grab the bit there.
Keep some static variables so when you accumulate a byte, you could push it into a queue and use the queue as your blocking mechanism.
I have implemented task with software USART receiver where is call USART_bit_delay routine.
This routine is implemented with delay_us OR delay_ns based on delay_cycles(count)
delay have to be exact tick count but these routine consumes task running state time.
void readByte()
{
uses 8x bit delay function delay_cycles in ASF framework,
how can be implemented in FreeRtos delay alternative?
}
void task()
{
while(1)
{
readByte(); // function consume running state and other tasks are blocked
}
Yes same idea: install a timer interrupt, which takes RX samples at fixed intervals.
If the baudrate is 9600, the interrupt rate should be 3 to 5 times faster: 28.8 or 48 Khz.
If you want to make your timer interrupt ‘lighter’, you could put the samples in a circular buffer with a head and a tail pointer: the head for writing samples (from the interrupt) and the tail for reading them (from your task).
And as soon as you see a stable high (e.g. 8 bit times), you might want to call xSemaphoreGiveFromISR(), so your task will be woken up to process the received data.
A second method is installing a GPIO interrupt on the RX pin. When the interrupt fires you could register the current time and the RX value. This needs a high precision time, for instance the COUNT value of a fast running clock.
I have used both methods successfully. The GPIO interrupt gives a lower CPU load of course, but it is a bit more difficult to analyse the data.
I have coded finall version of Software UART based on interrupts. edge detection start bit + timer counter that counter periode is max half delay of bit, freq = 2*baudrate Hz.
it is enough to call the handler 2 times for 1 bit sampling, without any while waiting. After receiving 1 byte timer counter is disabled and edge detecotor enabled.
It’s a good idea to use a GPIO interrupt on a falling edge to start the TC timer for recognition, and switch it off at the stop bit.
Now it syncs on the start-bit, which should be good enough in most cases.
I made my algorithm to recognise a continuous stream of rs232 data from devices with a less precise clock and also for lower-quality hardware ( I want to be able to inform the hardware people and say: look at these errors! Otherwise software always gets the blame of a failure )
One remark: when you assign “usartState = 2”, you might want to “fall through” and stop the TC immediately, in order not the miss the GPIO interrupt of the next start bit?
TC interrupts may come too late, but never too early.
I think , the error detection can be implemented on higher layer (checksumm etc.),
last stop bit delay is probably nessesary , because pin_falling_edge_handler can raise on last data bit. time-moment for pin reading is exactly in half periode of pin level state:
state time element:
t0>----reading T/2----<t1 , T = 1s/BaudRate,
this time-read-position is set by first 1,5T delays from start bit.
edge handler raise at time moment = (t0 state start bit) + few const cycles = C and C << T.
C is time for edge detection processing + handler subroutine call instructions.