Re: USART Driver check Receiver Idle
☄ Helpfulby Memen 2017/06/04 11:57:36
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:
will work on all these devices,
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.