BSP inititalisation order

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

BSP inititalisation order

Jump to solution
593 Views
billnd
Contributor IV

Currently writing a new BSP and wondering what things should go where. There are two routines that jump out at me as being useful places to put hardware/board initialisation bits and pieces, _bsp_initialize_hardware and _bsp_enable_card. But I'm unclear what should go in each one. I've a number of things to do, eg external clock config, global event flag creation, ADC scheduling, UART driver installation.

So my guess is that hardware things that do not need MQX, and indeed MQX may rely on should be done in _bsp_initialize_hardware. So external clock config should be done here?

But by the time _bsp_enable_card executes, MQX is pretty much fully up and running. So MQX routines like _lwevent_create could be put here to create the MQX environment before autostart tasks are generated?

ADC, UART things could go in either _bsp_enable_card or a standard task once MQX is fully up and running.

So is that about right, or am I way off the mark? I have to admit I'm finding MQX just a little overwhelming, and there seems to be a lack of clear documentation for PSP/BSP tailoring. I couldn't even find a book about it on Amazon!!

Cheers in advance for your advice.

Tags (2)
0 Kudos
1 Solution
330 Views
DavidS
NXP Employee
NXP Employee

Hi Billnd,

My fingers crossed that a MQX book will be developed but currently there is not one.

There is much documentation in the MQX4.0/docs path.  The MQX4.0/docs/mqx has MQXUG.pdf and MQXIOUG.pdf are a good read.

Lots of appnotes can be found at http://www.freescale.com/mqx .

In general the method you outline is OK.

The BSP is used to setup and "register" IO drivers to the RTOS for later application use (ex: UARTs) .  But MQX is flexible to allow the drivers to be loaded within the MQX application rather than BSP which saves having to recompile it during development.

Many of the MQX4.0/mqx/examples use the application to load a driver as reference.

MQX can be quite overwhelming but with blood sweat and tears it becomes more manageable.

Our Kinetis L family has MQX Lite with is implemented using PE (in CodeWarrior or as standalone app) to configure and develop RTOS applications.  This will be implemented for the Kinetis K family in the next couple of months.

Regards,

David

View solution in original post

0 Kudos
1 Reply
331 Views
DavidS
NXP Employee
NXP Employee

Hi Billnd,

My fingers crossed that a MQX book will be developed but currently there is not one.

There is much documentation in the MQX4.0/docs path.  The MQX4.0/docs/mqx has MQXUG.pdf and MQXIOUG.pdf are a good read.

Lots of appnotes can be found at http://www.freescale.com/mqx .

In general the method you outline is OK.

The BSP is used to setup and "register" IO drivers to the RTOS for later application use (ex: UARTs) .  But MQX is flexible to allow the drivers to be loaded within the MQX application rather than BSP which saves having to recompile it during development.

Many of the MQX4.0/mqx/examples use the application to load a driver as reference.

MQX can be quite overwhelming but with blood sweat and tears it becomes more manageable.

Our Kinetis L family has MQX Lite with is implemented using PE (in CodeWarrior or as standalone app) to configure and develop RTOS applications.  This will be implemented for the Kinetis K family in the next couple of months.

Regards,

David

0 Kudos