SPC560D30L3 - Serial driver

ssk · ‎2015-03-17

Posted on March 17, 2015 at 16:11

Hello,

I am trying to use the serial driver for SPC560D30L3 device using Discovery kit (I have replaced SPC560D40 with SPC560D30 MCU). When I try to configure the 'Serial Driver Settings' for buffer size, it only accepts value of 16. Is it ok? As per HAL document, the default value is 16. What is the valid range for it? I tried entering values of 1, 2, 3 etc but it gives an error as incorrect value which prevents me from generating the application. What is the reason for the error? Any other settings required?

Secondly, I am trying to read or write to the serial buffer/driver. I tried using functions 'sdGet' and 'sdPut' for reading / writing single byte to the serial. I am able to read the byte as it shows inside the watch window for SD1 but not able to transmit it back to terminal. Am I using correct function to achieve this? Any guidance/help will be highly appreciated.

Thanks in advance.

Mike.

#serial

Erwan YVIN · ‎2015-03-18

Posted on March 18, 2015 at 10:13 Hello Mike , The buffer size should be greater than 4. to transmit it back on serial port you should use this API :

chnWriteTimeout(&SD1, (uint8_t *)

myValue

, length(myValue), TIME_INFINITE);

Anyway , you can use an OS ChibiOS which contains a shell terminal that you can customize as you want. (cf shell_cmd.*) Best regards Erwan

ssk · ‎2015-03-18

Posted on March 18, 2015 at 11:55

Hello Erwan,

Thanks for the reply.

Earlier I did succeed using the functions 'chnRead' and 'chnWrite' for reading and writing from serial driver. I implemented a state machine using SDx states. My question is how the handshaking between serial driver and application layer is handled? I find that SD_READY is the state when both receive or transmit can take place but how is the indication to handle when a character or a byte is received by the serial driver? Even the SDx.events.flags handle only the status for parity, overrun etc but no handshaking for character or byte received or not? Is it required to check the DRF or DTF or RMB flags to ensure that the serial activity is over? I see this handling inside the HAL driver but app layer how to handle it? I am calling function 'chnRead' every time to get a byte received over serial. This is called even if no byte is received. How to handle it?

Thanks in advance.

Mike.

Nickname16641_O · ‎2015-03-18

Posted on March 18, 2015 at 12:52

Hi,

There are event flags also for the status of queues:

CHN_INPUT_AVAILABLE is raised when the RX queue becomes non-empty.

CHN_OUTPUT_EMPTY is raised when the TX queue becomes empty (the UART is still transmitting the last byte fetched from the queue).

About the API, there are also function variants with timeout, this could help in case you are implementing a state machine and have transitions for communication timeouts, see:

chnPutTimeout(), chnGetTimeout(), chnReadTimeout() and chnWriteTimeout().

Giovanni

ssk · ‎2015-03-18

Posted on March 18, 2015 at 14:35

Hello Giovanni,

Thanks for your reply. If I understand correctly, is the following implementation correct?

case SD_READY:

if (CHN_INPUT_AVAILABLE == SD1.event.flags)

{

chnReadTimeout(&SD1, (uint8 *)&sw_val, 1, TIME_INFINITE);

}

break;

If it is correct, it is not working. I do not receive any character but if I remove the flag checking, it works.

Thanks in advance for your help.

Mike.

Nickname16641_O · ‎2015-03-18

Posted on March 18, 2015 at 17:13

If you check for data availability then you may want to use TIME_IMMEDIATE, not TIME_INFINITE, this way you will not block into the read function which would block until all the specified bytes are read, even if not yet in the queue.

Another point, why you want to check the driver state? after starting it, it will always be SD_READY. Also note that you can have a callback when the status flags change.

Also, use osalEventGetAndClearFlags() in order to read flags, this functions returns the current mask and clears it (if you don't clear the flags how would you tell that MORE data arrived).

There are several ways to use the driver:

1) Superloop checking flags and reading/writing in a non blocking way (TIME_IMMEDIATE).

2) Superloop using the API in a blocking way (TIME_INFINITE or specifying timeouts), no need to check flags except for error detection.

3) From within the driver callbacks, this is especially useful if you are implementing some kind of state machine.

4) If you use an RTOS then you may have a dedicated task using the driver in a blocking way.

Giovanni

ssk · ‎2015-03-19

Posted on March 19, 2015 at 10:08

Thanks Giovanni for clarifications.

For callback, which section of 'Application Configuration' offers to configure the callback function? ADC or PWM have such configuration but for serial it is not found.

Regarding the flag handling, which document mentions about this function and its syntax? I tried looking at .chm documents but could not locate it.

Thanks.

Mike.

Nickname16641_O · ‎2015-03-20

Posted on March 20, 2015 at 09:39

Hi,

The serial driver uses a different callback method (event sources), you need to set the callback vector into the SDx structure at runtime, see the event sources there (you can also revert it back to NULL).

Note that when using an RTOS the event sources can be mapped to the OS own event flags handling mechanism and not have a direct callback.

Giovanni

ssk · ‎2015-03-24

Posted on March 24, 2015 at 15:40

Hello Giovanni,

Thanks for your reply.

My application does not use any RTOS. Can you please explain/elaborate more on 'event source' and defining the callback vector? Which document can I refer for this?

Thanks.

Mike.

Erwan YVIN · ‎2015-04-30

Posted on April 30, 2015 at 10:25

Hello Mike ,

a callback vector(function pointer) is very efficient way to catch an event.

for a SPC5-HAL driver configuration, when an interruption is handled .. the callback is called.

Best Regards

Erwan