Is Processor Expert recommended for MQX (Non-Lite)?

[anguel]

Hi!

I wonder if Processor Expert is really recommended for accessing peripherals like I2C and SPI in new MQX (Non-Lite!) projects or not. I know that PE cannot be used to configure advanced MQX components like USB and Ethernet but how about the simple ones? Is Processor Expert a production-proof best-practice

approach or is it just something novice developers should use to experiment with the device features? Unfortunately, I did not find any docs regarding this topic.

There are some new videos but they are all about using PE with MQX-Lite. So what about the full-featured MQX version? My target is Kinetis K70. I am asking because I have also found some older appnotes that show examples using file I/O to access SPI, I2C, etc. :

http://www.freescale.com/files/microcontrollers/doc/app_note/AN4345.pdf

So what is the recommended way to go for MQX? PE or do it yourself?

Thank you in advance.

Anguel

[xing_ch]

A good discussion，benefited a great deal

[Cdn_aye]

Anguel

I forgot to answer one of your questions

Do I then have to signal the MQX task from the PE ISR (I think this is called event in PE)? Should I use lightweight events for that?

My understanding of MQX is that you should not call RTOS system functions from within any ISR, regardless of whether you use PE or not. I think there may be a few select API's that are allowed but that is a guess. There is no need to signal MQX from PE, PE + MQX are the system. The PE LDD driver will work exactly like any other driver because PE is separate from the driver architecture. The way I use to indicate a transaction is to use a flag. The ISR traps, set the flag, exit the ISR, the task is evaluating the flag. There are more elegant ways but this serves to show the idea;

in the global section or as an external variable

volatile uint8      gu8_Flag_1;

a_PE_Driver_ISR(void)     // this gets generated by PE

{

     gu8_Flag_1 = ge_TRUE;     // this is your code

     return;

}

// in your scheduled task in your program

//------------ my Task ------------

while(gu8_Flag_1 != ge_TRUE){}

gu8_Flag_1 = ge_FALSE;               // reset for next ISR

Regards

Robert

[anguel]

Thank you once again Robert! But if I see correctly you are polling the flag in the task and this is what an rtos should exactly prevent. In an old style mqx driver one can use lwevents there, see for example adc demo. I hope that this is also possible with PE drivers.

Do I understand correctly that PE drivers run above the mqx kernel an the On....... events are the ISRs? I still do not really understand where PE puts driver init code? Does this code go into tasks for mqx non-lite or what?

Anguel

[Cdn_aye]

Anquel

I think you might be thinking about this more complicated than it is. The purpose of PE is to encapsulate and reduce the effort needed to work with the chip subsystems. You probably can use RTOS semaphores, I think they are allowed but as I said you need to check. I don't think the RTOS will prevent you from using the global flags as I have done... as far as I am aware.

Do I understand correctly that PE drivers run above the mqx kernel an the On....... events are the ISRs? I still do not really understand where PE puts driver init code? Does this code go into tasks for mqx non-lite or what?

PE is just code like any other code, what PE does is generate all the installs for the drivers it uses, you do not have to do anything special as far as I am aware. If you choose to use the spi component then PE generates the init code to setup the driver and also the install calls. All you do in your code is to enable or disable the driver using the "method" PE gives you. For example... Enable_spi(); would enable the component to receive interrupts. The exact call is shown to you in the header files or in the setup window or in the help files. In the older PE system you had to enable the component and also enable the recognition of the interrupts, but I believe that has changed. It is actually a very easy system to use. It does not compete or sit on top of anything now (it used to), now it is just generated code. I took PE generated driver code from CW6.3, and the Coldfire 51jm128 and ported it to the k20dx256 (Kinetis) processor to check a hardware design. It is just code.....

If you check this site it should help you a lot.

Processor Expert | MCU on Eclipse

Regards

Robert

[anguel]

Well, RTOSes are complex. And if I use an RTOS I would like to make use of its services from the PE generated ISR code. That is the way to go. So it would be nice if Petr could give me more information on that topic, I browsed through the manuals but did not find anything. The MQX Lite appnote also polls a flag, but again, this is not the proper solution for an efficient RTOS-enables system. The problem with MQX is that there is no clear guide which of its services should be used how, just compare its docs to uC/OS or FreeRTOS - the MQX guides are just listing the components but don't tell you how to use them. There are no books to buy. May be this is done on purpose to be able to sell expensive trainings. But small companies cannot afford that...

I will definitely have a look at the MCU on Eclipse site, although I would like to use MQX and not FreeRTOS.

Regards,

Anguel

[Cdn_aye]

Anguel

MQX has many examples; look under the root, for example

C:\Freescale\Freescale_MQX_4_0\mqx\examples\

There is an example for every MQX function and for every driver supported, you can load these into the FSL boards and try them. Many examples illustrate the call of more than one MQX API..

I might be mistaken but it is my understanding that within an ISR, functions or system level calls should never be done, regardless of which RTOS is used. You may be safe in using the light weight semaphore signaling, I haven't checked into that.

Regards

Robert

[anguel]

Robert,

I also started to look at the examples yesterday :-) Regading ISRs I also found this Discuss to Learn: 5. MQX RTOS Handling Interrupts -2

It describes how to use MQX calls from ISRs. And it seems like the ISRs need to be "installed" for MQX. See also MQXUG section 3.10. Now I have to find out how this fits into Processor Expert.

UPDATE: I looked into PE generated code for _int_install_isr() and found calls to that function, so it seems that they have taken care to make ISRs MQX-aware :-)

Anguel

[petr_uhlir]

Robert and Anguel,

to make your questions regarding PEx and interrupt clear let me add some comments.

1. As Anguel pointed out its not a good programming practice to use global flags in ISRs and then having some busy loops in task checking flag. It leads to wasting cpu time and other problems.

2. Preferred way is using RTOS synchronization objects.

LWSEM_STRUCT   semaphore;

void adc_isr(void)

{

     // read data from adc result registers and put it to buffer

     // and post semaphore to unblock adc_task

     _lwsem_post(&semaphore);

}

void adc_task

     (

          uint_32 initial_data

     )

{

     _mqx_uint result;  

     result = _lwsem_create(&semaphore, 0);

     if (result != MQX_OK) {

         // failed to create semaphore

          _task_block();

     }

     while(1)

     {

          // task gets blocked waiting for semaphore

          result = _lwsem_wait(&semaphore);

           if (result != MQX_OK) {

               _task_block();

           }

          // now we have adc data ready and we can process some calculations

     }

}

Its just simple code snippet demonstrating howto synchronize interrupts and tasks.

Its assumed that adc_isr is MQX interrupt installed by _int_install_isr().

In a case of PEx and RTOS adapter (available for Kinetis and ColdFire+ derivatives) all interrupts are installed as MQX interrupts so you do not need to worry and can call MQX API from PEx events.

The PEx for JM128 derivative does not support RTOS adapter and LDD components, so its not possible to call MQX API from its isr's. The only way is to hack init routine to install a_PE_Driver_ISR using _int_install_isr() function.

Regards Petr

[anguel]

Petr,

Many thank you for the clarification and for the examples. Looks like PEx has better MQX integration than the docs make us think.

Regards,

Anguel

[Cdn_aye]

Hi Anguel

You have correctly noted some of the problems of using PE with MQX. The main one being the difficulty of integration of a bsp that does not have a distributed PE aware *.pe bsp. Cloning a bsp as per the appnote, does not work if the core is different. For example you cannot clone a mkk20D part into a mkk20dxnnn part by tweaking a few issues. The packaging may not exist (pins are not available).... and so on. All that is changed is the directory tree and naming. But I believe this problem will be overcome in the near future in a future release of MQX.

That said, the major advantage of PE is that it allows encapsulation of methods and hardware into reusable software components and modules that can be easily migrated to new hardware. This is important if you find further along that you need to reduce costs by changing processors, or change up to a larger faster processor due to limitations or change of scope of the project.

The other major advantage PE now has is that with the new releases of CW and MQX, the device drivers are not integrated into PE. This used to be a major problem with the older PE code; because the PE driver interposed itself between the interrupts and user event structures. This could lead to serious problems in response time, missed interrupts and so forth. That is no longer the case. Now all the register level, bit functionality is in properties in the PE components and PE uses the MQX LDD driver architecture. This has overcome the one major liability.

There are a lot of reasons to use PE, but what often happens is that people try to use everything in PE and then hit a missing component  and use then not PE. For example there is no PE component for the FlexTimer, actually there is no driver as of MQX 4.0.0 for the FlexTimer. So you would have to write your own handler for this device whether you use PE or MQX. But there are many very amazing drivers that allow fast coding, i2c, spi, CAN etc. I was able to connect two CAN devices on two separate boards and get them to talk(pass messages back and forth) in about 15 minutes using PE on a 9sx12512 processor and CW6.3. And I had never used CAN before.

My personal opinion is that PE or something similar in the object oriented realm is the way of the future for embedded systems. The stumbling block right now is the bsp builds. If your processor bsp is PE aware then at the very least try using the LED component.

If you want a very good site to become familiar with the real potential of PE, check on this site. Erich Styger is an expert on PE and a FSL employee and has the best web site for anything related to PE (and a lot about the Kinetis)KL25. http://mcuoneclipse.com/

He deals with a non MQX rtos but the principles are the same.

Regards

Robert

[anguel]

Robert,

Thank you for the information.

You have correctly noted some of the problems of using PE with MQX. The main one being the difficulty of integration of a bsp that does not have a distributed PE aware *.pe bsp. Cloning a bsp as per the appnote, does not work if the core is different.

You are probably referring to Mehmet's BSP compilation problem but of course this is important to be aware of.

But there are many very amazing drivers that allow fast coding, i2c, spi, CAN etc. I was able to connect two CAN devices on two separate boards and get them to talk(pass messages back and forth) in about 15 minutes using PE on a 9sx12512 processor and CW6.3. And I had never used CAN before.

Here again my problem are the missing real world examples. If I look at the MQX's own driver examples there I find at least an ADC demo. Unfortunately. these demos do not show advanced features and documentation in the MQX I/O Drivers User Guide is very limited. For example does the ADC_IOCTL_CALIBRATE command do a self-calibration of the ADC and how is it really used?

Regarding the PE drivers I find no working examples at all, which is even more confusing to get started with.

The stumbling block right now is the bsp builds. If your processor bsp is PE aware then at the very least try using the LED component.

Let's look at the KWIKSTIK BSP, it looks like it contains a ProcessorExpert.pe file, so it should be PE aware. But there is no pe_demo project for that board. Is there a reason for that? Can I use KWIKSTIK with MQX + PE?

I already found Erich's blog and will look deeper into it, on the other hand I don't understand why a big company like Freescale is not able to write good documentation.

Thank you,

Anguel

[Cdn_aye]

Hi Anguel

You raise legitimate concerns; the biggest I think is the bsp issue, but I have been told this is being worked on for a near release. I agree about the doc set; volumes of pages do not a help... make. Most of us don't have the time to invest in a possible solution.

Regarding the bsp issue it is major, Petr can respond with more authority and accuracy than I on this issue.

What I have observed as an extensive user of PE, is that from MQX 3.7 to MQX 3.8.1 PE was added to many (if not all) Kinetis and Coldfire processors, this is the component that sets up the CPU. It is just not obvious that PE is the force behind the timing and setup therefore it is not immediately obvious that this is happening via PE.

FSL acquired the rights to PE from Unisys which was the company that authored Processor Expert... about a year and a half ago. FSL then re-engineered PE from the ground up and integrated it into the MQX driver architecture. Thus the LDD driver model for PE.

The reason I point this out is that the direction PE is going is a corporate vision by FSL. Codewarrior is heavily invested in PE integration. What you are seeing at present is not a poorly implemented system lacking documentation, but one stop on the train going from the West coast to the East coast, we are somewhere around Idaho right now. I think it will get better, for example there will be a tutorial released on how to create your own components using the CDT tool in Codewarrior in the not too distant future... and so on.

If you want to use PE, I would suggest you use the $12 Freedom board mentioned on Erich's web site. If you work through his examples, they are excellent. As I have said do not expect a PE component for all things, eventually every key component will be there and there will be a major investment in a smoother integration. But in its present form, it is still a major advantage in my opinion.

If you want to see further examples of PE but under CW6.3 you can look at www.imnmicrocontrol.com , I can't remember but there may be CW10.1 examples as well. The examples do not use MQX however. The best site is Erich's in my opinion.

What has not been mentioned about Processor Expert is that FSL integrates into the components, the knowledge base to correctly and automatically setup the 1000's of bit positions... via the corporate knowledge base in the FSL design team. We as customers do not have access to the chip designers and architectural design teams, but the PE team does. That is, when you choose to set a property like the clock speed, PE will recalculate all the related PLL, IO clocks and so on, ...correctly. When you want to choose a mode to access the IO system that may require multiplexing register setup, PE will set all the related registers correctly. Even if someone is an expert on a processor and can define all the definitions to manually set the conditions without causing a conflict, that person can't have that knowledge on all processors. The knowledge base of the processor is encapsulated for the benefit of the user by the FSL engineers into the PE components. This is a massive advantage.

What I am saying is that looking ahead, FSL will improve the product... it is not another appnote or tangential marketing burp. It is core to their toolset and corporate direction in my observation.

Regards

Robert

[anguel]

Robert,

Thank you for the long reply. The things you said are really interesting and it looks like PE will be the future.

At the moment I am still trying to understand how things fit together. So if I have a MQX + PE project how would both work together. Let's say I setup an ADC in PE and then want to have the processing of the data be deferred to an MQX task. Do I then have to signal the MQX task from the PE ISR (I think this is called event in PE)? Should I use lightweight events for that? Does PE code support such MQX calls from inside its event functions? Or is there some other mechanism that must be used? I really need to use PE together with MQX because Ethernet, File System etc. are still not supported by PE and MQX Lite.

Thank you,

Anguel

[Cdn_aye]

Anguel

It (a PE component) works exactly like a function. You call the component with the calling parameters that you want to use (assuming it has a parameter). Some components like the spi driver have multiple ISR entry points that get inserted into the vector table or handled by the driver and then your code is called at these entry points. It depends on the driver but PE accounts for the methods you enable in the configuration screen. Then stubs are then automatically inserted into your code or in an Events.c table (marked as ISR's) when you generate the project (automatically done if you are using PE). Then you simply put your code in the stub. PE also automatically creates the necessary include statements. Here is an example of some code for a CW6.3 project, for the 51jm128. This is an ISR for a freq in capture, the ISR is for the overflow bit.

You can use some or as many PE components as you want with MQX. I have not used MQX Lite as yet but I know that there is coming a File System component. Erich created one for freeRTOS on his web site.

Regards

Robert

/*

** ===================================================================

**     Event       :  FreqTrig_OnCapture (module Events)

**

**     From bean   :  FreqTrig [Capture]

**     Description :

**         This event is called on capturing of Timer/Counter actual

**         value (only when the bean is enabled - <Enable> and the

**         events are enabled - <EnableEvent>.This event is enabled

**         only if a <interrupt service/event> is enabled.

**     Parameters  : None

**     Returns     : Nothing

FREQ_OUT_ENABLE_CNT_MAX    u8_status = FreqCapture_Enable();

    u8_status = FreqOut_Enable();

/*--------------------------------------------------------------------------------------------------

((((((((((((((((((((((((((((((((( TimerOverFlow )))))))))))))))))))))))))))))))))))))))))))))))))))

----------------------------------------------------------------------------------------------------

    Function:   Timer overflow tracking

    Input:      Interrupt on TOF flag, TFLG2

    Return:

    Notes:      CaptureMode = 0xFF, flag off, 0x00 first edge, 0x01 second edge

--------------------------------------------------------------------------------------------------*/

void FreqCapture_OnOverflow(void)

{

    if((u8_capture_mode == ge_FIRST_EDGE) ||

       (u8_capture_mode == ge_SECOND_EDGE)){                   // active-count TOF

        gu8_OvrFlowCntr++;

    }

    return;

}

[petr_uhlir · Accepted solution]

Hi Anguel,

it depends on your personal preferences. If you like concept of components with GUI configuration and generated code you can use ProcessorExpert. It allows to mix MQX and PEx in the same BSP. So you can for example use UART, Ethernet, USB and  SPI from MQX and add I2C, DAC, ADC, PWM, GPIO from ProcessorExpert.

To select particular driver from MQX or the ekvivalent one from PEx depends also on your application.

If you require for example MFS running on SDCARD you have to use SPI or SDHC driver from MQX due to Posix.

For other cases like ADC, I2C I would rather choose PEx drivers as they are much lighter and easier to use.

Some drivers like DAC are not supported in MQX.

To make your decision easier you can test PEx drivers with MQX Lite and if found suitable you can easily transfer them into full MQX just by using Export / Import.

If you do not like generated code you can at least take some inspiration and reuse code from PEx drivers when you write your own drivers from scratch.

Some documentation about using PEx and MQX can be found in "mqx\doc\tools\cw\FSL_MQX_in_CW_10_x.pdf"

Petr

[anguel]

Petr,

Thank you for the important information.

If you require for example MFS running on SDCARD you have to use SPI or SDHC driver from MQX due to Posix.

This sounds important to be aware of. Are such things documented somewhere?

For other cases like ADC, I2C I would rather choose PEx drivers as they are much lighter and easier to use.

Lighter = faster ?

Some drivers like DAC are not supported in MQX.

Do I understand correctly that MQX simply does not offer a DAC driver and I therefore must use the PEx driver?

To make your decision easier you can test PEx drivers with MQX Lite and if found suitable you can easily transfer them into full MQX just by using Export / Import.

I don't quite understand why I should start with MQX Lite. Is it available for Kinetis K70 at all? It looks like PEx is also included in the full MQX or do I misunderstand something?

Some documentation about using PEx and MQX can be found in "mqx\doc\tools\cw\FSL_MQX_in_CW_10_x.pdf"

I have already seen that but would not really call it docs, it is just some getting started slides without any thorough explanation. Unfortunately, most docs for MQX are often very scarce or outdated.

Regards,

Anguel

Message was edited by: Anguel

[petr_uhlir]

Anguel,

If you require for example MFS running on SDCARD you have to use SPI or SDHC driver from MQX due to Posix.

This sounds important to be aware of. Are such things documented somewhere?

There is not so much information in MQX doc. The MQXIOUG just specifies which drivers are POSIX compliant (contains  open, close, read, write and ioctl function).

For other cases like ADC, I2C I would rather choose PEx drivers as they are much lighter and easier to use.

Lighter = faster ?

In a case of ADC, GPIO drivers there is POSIX implementation of which is quite a big overhead and its not needed at all. You can use also the MQX lightweight implementation called lwadc, lwgpio. But PEx implementation is even more optimized.

Some drivers like DAC are not supported in MQX.

Do I understand correctly that MQX simply does not offer a DAC driver and I therefore must use the PEx driver?

There is DAC driver in "mqx\source\io\dac" but it supports just just Coldfires and Kinetis K53. If you would like to use it for K70 you have to modify it. It is very similar to PEx implementation so it would be easier for you to use PEx DAC.

To make your decision easier you can test PEx drivers with MQX Lite and if found suitable you can easily transfer them into full MQX just by using Export / Import.

I don't quite understand why I should start with MQX Lite. Is it available for Kinetis K70 at all? It looks like PEx is also included in the full MQX or do I misunderstand something?

Yes MQX Lite is ProcessorExpert component integrated into CodeWarrior 10.3 (also ProcessorExpert Driver suite supporting other tool vendors like IAR and Keil)  and its available for K70 as well. If you would like to test some PEx driver like ADC, DAC, I2C, GPIO with MQX you can try it on Lite where its easier to use. There is MQX Lite new project wizard which configures the MQX for you, you can setup tasks, add PEx drivers and write your application code in tasks. If its working you can simply Export settings of ADC, DAC,.... components into PEF file and import it into ProcessorExpert project integrated in full MQX K70 BSP, copy & paste application code and it will work.

Some documentation about using PEx and MQX can be found in "mqx\doc\tools\cw\FSL_MQX_in_CW_10_x.pdf"

I have already seen that but would not really call it docs, it is just some getting started slides without any thorough explanation. Unfortunately, most docs for MQX are often very scarce or outdated.

Sorry I have to agree with you. We are working on to get it better.

Petr

[kleckerspur]

Hello,

Some documentation about using PEx and MQX can be found in "mqx\doc\tools\cw\FSL_MQX_in_CW_10_x.pdf"

>> I have already seen that but would not really call it docs, it is just some getting started slides without any thorough explanation.

>> Unfortunately, most docs for MQX are often very scarce or outdated.

>> Sorry I have to agree with you. We are working on to get it better.

Does the situation changed since more than one year (04.09.2014) ?

[anguel]

Petr,

Thank you once again for the good and thorough explanations. It is good to get some starting advice from experts like you and I am glad that I asked that question.

If you would like to test some PEx driver like ADC, DAC, I2C, GPIO with MQX you can try it on Lite where its easier to use. There is MQX Lite new project wizard which configures the MQX for you, you can setup tasks, add PEx drivers and write your application code in tasks. If its working you can simply Export settings of ADC, DAC,.... components into PEF file and import it into ProcessorExpert project integrated in full MQX K70 BSP, copy & paste application code and it will work.

After looking at the "mqx\doc\tools\cw\FSL_MQX_in_CW_10_x.pdf", I got the impression that PEx projects for MQX look and work just like PEx projects for MQX Lite (besides that MQX full does not create my tasks automatically). But I thought that I could add the PEx drivers in the exactly same way as in MQX Lite. But according to your description above there seem to be some other differences and therefore the PEF export is needed. Thank you for the hint, I will look into that.

BTW: Maybe you experts could write a very short overview which drivers YOU would implement using PEx (because of simplicity and lightness) and which you would implement using the old MQX way because this is required, not available in PEx or for some other reason. Such a short overview would be very helpful for people new to MQX.

Thank you once again.

Best regards,

Anguel

[petr_uhlir]

After looking at the "mqx\doc\tools\cw\FSL_MQX_in_CW_10_x.pdf", I got the impression that PEx projects for MQX look and work just like PEx projects for MQX Lite (besides that MQX full does not create my tasks automatically). But I thought that I could add the PEx drivers in the exactly same way as in MQX Lite. But according to your description above there seem to be some other differences and therefore the PEF export is needed. Thank you for the hint, I will look into that.

No, PEF export just makes it easier. You will not need to manually set all component parameters again if full MQX.

Just from MQX Lite project File -> Export -> Processor Expert -> Export Component Settings  and then in K70 BSP

File -> Import -> Processor Expert -> Component Settings to Project

Application code Ctrl+C & Ctrl+V, Done.