• AVR Freaks

Helpful ReplyUSART Driver check Receiver Idle

Author
Memen
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2017/04/08 12:17:32
  • Location: 0
  • Status: offline
2017/06/03 02:57:39 (permalink)
0

USART Driver check Receiver Idle

How can the receiver idle state of the USART driver be checked in Harmony?
I used to check the RIDLE bit of the uart module before starting transmission of a new byte. This is still possible with Harmony's peripheral library (PLIB_USART_ReceiverIsIdle(USART_MODULE_ID index); ). However when using the USART driver, I can not know the specific USART_MODULE_ID, only the 'usart Handle' you get when initializing the driver. What is the proper way to find out if the receiver is idle and the software can start transmitting?
#1
Mysil
Super Member
  • Total Posts : 3951
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: USART Driver check Receiver Idle 2017/06/03 05:48:31 (permalink)
3 (1)
Hi,
Normally, the point of using a Driver, is that handling and checking hardware, like 'Receiver_Idle' shall be a responsibility of the driver, and not a concern of application code. 
Application code,  is supposed to use only those functions and status codes provided by the Application Interface of the driver, which should have some function to inquire for status, or report problems,
one of those might be that hardware is not able to transmit fast enough, or remote receiver not willing to accept.
Then, the queue of transfer request entries will become full, and this must be checked by application code.
 
UART data transfer, conceptually is full duplex, with transmission not depending upon the local Receiver, 
but even if half-duplex communication is used, turning the line around, should be a responsibility of the driver.
 
Now for UART, Harmony have at least 3 different modes of operation, with, or without a transfer queue,
to be configured before the program is generated, and I think there is Not sufficient information about what selections have been made.
 
Regards,
   Mysil
#2
Memen
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2017/04/08 12:17:32
  • Location: 0
  • Status: offline
Re: USART Driver check Receiver Idle 2017/06/03 10:08:24 (permalink)
0
Ah, it is indeed a half duplex network, so I have to check whether I can send something or not. There are multiple clients connected and the echo has to be checked for every byte. Also there is a certain timeout before turning the line. I set up the driver as byte model using interrupts with callback as attached (using Harmony v2.03b). Also I set up a timer for complying with the timeout.
 
It appears from the help_harmony.pdf that there is no separate driver/mode for half duplex. Does this mean I would have to build it upon the harmony peripheral library instead of the driver library?
 

Attached Image(s)

#3
Mysil
Super Member
  • Total Posts : 3951
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: USART Driver check Receiver Idle 2017/06/03 11:47:18 (permalink) ☄ Helpfulby Memen 2017/06/04 11:57:36
4 (1)
Aha,
There have been some heated communication in other threads of this Forum,
about very similar questions about UART driver and code.
 
I am not currently a active user of Harmony, so shouldn't say too much,
but the conclusion seem to be that if using a half duplex protocol with specific requirements to record separation, 
acknowledgement handling, alternating between character and binary transfer, line turnaround, break signalling, or whatever,
like in most of those industrial or automation protocols using UART in a multidrop configuration,
They end up bypassing Harmony drivers, and implement their own driver code instead.
 
This may be done by calling Harmony Peripheral Layer functions,
Programming hardware registers by use of Device datasheet and symbolic constants and register struct expressions defined in the device support files installed together with XC32 compiler,
or by porting those parts of (legacy) Plib that you really need.
 
Harmony peripheral layer, provide a way of referring one of several UART modules by a argument value,
but then invent new names for everything, making debugging more obscure.
It doesnt provide much gain as long as you stay with PIC devices,
It may help you along if harmony is ported to a different platform, like Atmel, and you want to follow there.
 
Programming hardware according to datasheet isn't as scary as may sound. Datasheet and device support file correspond very closely, and have good descriptions of hardware behaviour.
If you have existing driver and protocol engine code for PIC32MX or PIC24/dsPIC33,
I would try to use that as much as possible.
 
Functions in legacy Plib are mostly very simple, and may mostly be replaced or ported, even to PIC32MZ.
There is some hurdle with C preprocessing depending on the macro __PIC32_FEATURE_SET__
which is defined to be a character constant on PIC32MZ.
 
UART modules are very similar for PIC32MX, PIC32MZ, PIC24 and dsPIC33,
with RIDLE bit in UxSTA register in all devices, and even in the same position in the register:
The struct expression:
     UxSTAbits.RIDLE
will work on all these devices,
alternatively:
    if (U1STA &  _U1STA_RIDLE_MASK) ...
It is possible to define a macro to substitute the actual peripheral to use:
#define   UxSTA        U3STA
#define   UxSTAbits   U3STAbits
or use other constructs.
 
Regards,
   Mysil
#4
Memen
Starting Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2017/04/08 12:17:32
  • Location: 0
  • Status: offline
Re: USART Driver check Receiver Idle 2017/06/04 11:57:28 (permalink)
3 (1)
Thanks a lot for your elaborate answer Mysil!
 
It is weird that the Harmony Driver does not support this as it seems a common use case of the usart module. I had the code working using the legacy plib, however with every update of the compiler the plib has to move as well. It shouldn't be too difficult to adapt it to the new libraries from harmony (same functions, different names) or add some lines of code to the driver.
#5
Totem
Super Member
  • Total Posts : 266
  • Reward points : 0
  • Joined: 2014/12/04 02:18:11
  • Location: Mars
  • Status: offline
Re: USART Driver check Receiver Idle 2017/06/11 19:43:14 (permalink)
0
Hi Memen,
 
I think full duplex of UART is a specific use case.
But, Harmony UART driver has capability to handle this with buffer queue model.
Please go ahead and raise a ticket for this. :-)

Everything is Relative!
#6
Jump to:
© 2020 APG vNext Commercial Version 4.5