Understanding OS Layer in NullOS conficuration in NFC library (help needed)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Understanding OS Layer in NullOS conficuration in NFC library (help needed)

1,201 Views
Pochie
Contributor I

Dear NXP Community,

I am trying to understand the “NxpNfcRdLib_PN5180_LPC1769_v05.22.01_Full” library through the basic discovery loop example.

1.Even in Null Os configuration it seems that hardware specific timer functions are needed? Is that true for the complete library or just the examples?

An example for the functions are given in:

phOsal_Port_CM3.c

phOsal_Port_CM4.c

phOsal_Port_PN74xxxx.c

that are defined in phOsal_NullOs_Port.h and those Timer are configured in the differened ...TickTimer(void) functions in the phOsal_Port_...c files in the NullOs/portable foldel?

2.On the other hand “phOsal_Port_PN74xxxx.c” returns all ...TickTimer(void) functions with just an “PH_OSAL_SUCCESS”. Is it because The PN7462 family has a 32-bit Arm®Cortex®-M0 that may already be integrating an Os?

But why do the files phOsal_Port_CM3.c and phOsal_Port_CM4.c (which I guess stand for Arm®Cortex®-M3 and Arm®Cortex®-M4) have dedicated software and register settings?

Inside the phOsal_Port_XXX.c files and also the phOsal_NullOs_Port.h are functions to put the processor to sleep and to wake it up. That would be lees of a problem if its just for the examples. As part of a bigger project it would not be feasible to put the MCU into sleep mode just for NFC. So the question is, do I have to put the MCU to sleep for the library to function or is it for this example?

3.It seems mandatory since the phOsal_Sleep() function is called inside the phOsal_EventPend(...) function with out a condition in an endless loop (while(1)).

That function again is called by many other functions (if I look at the call hierarchy), with one of the most important “phhalHw_Pn5180_Exchange”. From that call hierarchy it would seem, the Osal layer is mandatory for the NFC library, as well as the sleep mode of the MCU right?

4. So the NFC library puts the used controller to sleep? That would seem strange and not very practical if NFC is just part of a bigger projects that uses the same MCU.

5. At least in the “phhalHw_Pn5180_Exchange” function, there is a condition for sending the MCU into sleep mode. That would be if (pDataParams->bPollGuardTimeFlag == PH_ON). Dose that mean the Exchange function can be used, with out sending the MCU into sleep?

6.In my eyes the most critical functions in the NullOs configuration would be

phOsal_Sleep

phOsal_WakeUp

phOsal_Sleep with its assambler instruction “wfe” is quiet clear but phOsal_WakeUp with its assambler instruction “sev” seem to only make sense in a multi cpu configuration, since a sleeping cpu does not seem to be able to send it. So the wake up need to come from an interrupt source like the tick timer? How dose the MCU wake up in this library?

7. That timer would need to be a separate timer from the one configured in the Driver Abstraction Layer, like in the function ...phDriver_TimerStart...(…) in the phDriver_...c file, right?

To sum it up: Do I need the OS Layer even in the NullOs configuration and if so are there information further information about this layer? If the OS Layer is mandatory for the NFC library can it be used with out the sleep mode of the MCU? And if so what may be the possible drawback or implications?

Best regards

Pochie

Labels (2)
Tags (5)
0 Kudos
1 Reply

1,173 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @Pochie ,

 

Please kindly have my comments as below:

 

1.Even in Null Os configuration it seems that hardware specific timer functions are needed? Is that true for the complete library or just the examples?

An example for the functions are given in:

phOsal_Port_CM3.c

phOsal_Port_CM4.c

phOsal_Port_PN74xxxx.c

that are defined in phOsal_NullOs_Port.h and those Timer are configured in the differened ...TickTimer(void) functions in the phOsal_Port_...c files in the NullOs/portable foldel?
-Yes, timers are needed for users when they have to wait/pend on events.

2.On the other hand “phOsal_Port_PN74xxxx.c” returns all ...TickTimer(void) functions with just an “PH_OSAL_SUCCESS”. Is it because The PN7462 family has a 32-bit Arm®Cortex®-M0 that may already be integrating an Os?

But why do the files phOsal_Port_CM3.c and phOsal_Port_CM4.c (which I guess stand for Arm®Cortex®-M3 and Arm®Cortex®-M4) have dedicated software and register settings?

Inside the phOsal_Port_XXX.c files and also the phOsal_NullOs_Port.h are functions to put the processor to sleep and to wake it up. That would be lees of a problem if its just for the examples. As part of a bigger project it would not be feasible to put the MCU into sleep mode just for NFC. So the question is, do I have to put the MCU to sleep for the library to function or is it for this example?
-Per “phOsal_Port_PN74xxxx.c”, the following statement is mentioned:
/**
* NULL OS implementation of PN74XXXX or PN73XXXX controller is just stub.
* In NULL OS implementation, RdLib with PN74XXXX or PN73XXXX HAL will not use any phOsal functionality.
*/

3.It seems mandatory since the phOsal_Sleep() function is called inside the phOsal_EventPend(...) function with out a condition in an endless loop (while(1)).

That function again is called by many other functions (if I look at the call hierarchy), with one of the most important “phhalHw_Pn5180_Exchange”. From that call hierarchy it would seem, the Osal layer is mandatory for the NFC library, as well as the sleep mode of the MCU right?
- Yes , the Osal layer is mandatory, but the sleep mode is just for null OS case.

4. So the NFC library puts the used controller to sleep? That would seem strange and not very practical if NFC is just part of a bigger projects that uses the same MCU.
- Well, that is some kind of compromise, if you enable RTOS, you have better performance, and if you enable null OS, you have less size of image.

5. At least in the “phhalHw_Pn5180_Exchange” function, there is a condition for sending the MCU into sleep mode. That would be if (pDataParams->bPollGuardTimeFlag == PH_ON). Dose that mean the Exchange function can be used, with out sending the MCU into sleep?
- Yes, if the guardtimer is not enabled, you needn't put the MCU into sleep mode/wait for the guardtimer expired.

6.In my eyes the most critical functions in the NullOs configuration would be

phOsal_Sleep

phOsal_WakeUp

phOsal_Sleep with its assambler instruction “wfe” is quiet clear but phOsal_WakeUp with its assambler instruction “sev” seem to only make sense in a multi cpu configuration, since a sleeping cpu does not seem to be able to send it. So the wake up need to come from an interrupt source like the tick timer? How dose the MCU wake up in this library?
- Yes, sev instruction is just available for multi core cpu, for single core, MCU wakes up from sleep mode by interrupts or events.

7. That timer would need to be a separate timer from the one configured in the Driver Abstraction Layer, like in the function ...phDriver_TimerStart...(…) in the phDriver_...c file, right?
- Which timer are you referring to?

To sum it up: Do I need the OS Layer even in the NullOs configuration and if so are there information further information about this layer? If the OS Layer is mandatory for the NFC library can it be used with out the sleep mode of the MCU? And if so what may be the possible drawback or implications?
- Yes, you need OS Layer even in the NullOs configuration, if you unzip the PSP, you may find the information related with OSAL in the folder of "\docs\OSAL", the OS Layer is mandatory for the NFC library, but it can only be uses with FreeRTOS if you don't want to use the sleep mode of the MCU. NullOs option has less size but RTOS brings better performance.

Hope that makes sense,

 

Have a great day,
Kan


-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

 

0 Kudos