Messages

16

µTasker general / Re: multiple fnInterruptMessage's

« on: November 18, 2019, 05:44:19 PM »

Thank you, Mark, for providing an alternate way to handle this situation.  I will take your advice and incorporate the changes in my code.

Regards,

Tom

17

µTasker general / Re: multiple fnInterruptMessage's

« on: November 16, 2019, 12:09:09 AM »

I have figured out what is happening.  uTasker will activate the task each time a new message is created.  If it happens that several messages are sent right after each other, only one of the activations for the task will occur.  To work around this, I read out all the messages sent into a two dimensional ucInputMessage array:

    // read out all the messages to be handled in this session
    numOfMessagesToHandle = 0;
    while(fnRead(PortIDInternal, ucInputMessage[numOfMessagesToHandle], HEADER_LENGTH))
    {
        if(++numOfMessagesToHandle > MAX_NUM_MSG_TO_HANDLE_FOR_TASK_ALT_TEMP_DRIVER)
        {
            errorCode.uTaskerTooManyAltTempMessages = TRUE;
         break;
        }
    }
 
After this, the code handles each of the messages in the ucInputMessage[][] array:

    for(index = 0; index < numOfMessagesToHandle; index++)
    {
           .....
     }

This solution will allow a task to handle all messages regardless of when they were sent allowing for the task to complete even if messages and timeouts are created within the handling task itself.  The issue with using a while loop on reading its message and handling it one at a time is it is possible for the handling task to create new messages to itself thereby not allowing the other tasks in uTasker operating system to have CPU time.  By leaving the handling task, other tasks will get CPU time and the handling task will be activated sometime after the other tasks have had CPU time.

18

µTasker general / Re: multiple fnInterruptMessage's

« on: November 14, 2019, 10:54:50 PM »

I have found that if I send multiple messages, one after the other, only the first message, INITIALIZATION, is recognized:

fnInterruptMessage(TASK_ALT_TEMP_DRIVER, INITIALIZATION);
fnInterruptMessage(TASK_ALT_TEMP_DRIVER, EV_ALARM_CONTROLLER_INITIALIZED);

I have looked through the uTasker documentation and cannot locate how to define a message queue large enough so that the second message, EV_ALARM_CONTROLLER_INITIALIZED, can be handled.  The task definition with the queue size is:

{"7_alt_temp_Driver",fnAltitudeTempDriver, LARGE_QUE,(DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP}

I have noticed if that if the first message is sent and handled, then the second, both will wake the task, TASK_ALT_TEMP_DRIVER, and be read and handled correctly.

Any help would be appreciated.  Thank you.

19

NXP^TM M522XX, KINETIS and i.MX RT / Re: Need a suggestion on best way to implement a 10ms timeout

« on: November 04, 2019, 08:05:41 PM »

I have determined why I am not getting the 10ms delay after it being set with fnConfigureInterrupt().  It is due to the architecture of the Kinetis KE part.

It was found that a timeout of the desired time TIMER_MS_DELAY(10) was occurring 16us (immediately after the fnConfigureInterrupt() call.  This interrupt time did not change when the desired interrupt time was changed.  Stepping through the code of fnConfigureInterrupt(), in file, kinetis_FlexTIMER.h, showed that bits FTM_SC_TOF and FTM_SC_TOIE were not being cleared/set.  The reason for this is due to incorrect bit mask definitions for  FTM_SC_TOIE and FTM_SC_TOF in file kinetis.h.  These two definitions need to be changed for a KE1xZ device according to their datasheet (see attachment).


In file kinetis.h, they are defined as
  #define FTM_SC_TOIE       0x00000040                                   // timer overflow interrupt enable
  #define FTM_SC_TOF        0x00000080                                   // timer overflow flag (write '1' to clear)
They need to be defined for KE1xZ devices as:
  #define FTM_SC_TOIE       0x00000100                                   // timer overflow interrupt enable
  #define FTM_SC_TOF        0x00000200                                   // timer overflow flag (write '1' to clear)

The other improvement that can be made is to add the present FTM_CNT to the FTM_MOD value since FTM_CNT is not zero after the first call to fnConfigureInterrupt().

Change from:
   ptrFlexTimer->FTM_MOD = ulDelay;

To:
   ptrFlexTimer->FTM_MOD = ptrFlexTimer->FTM_CNT + ulDelay;

Once this is done, the correct delay time will occur.

20

NXP^TM M522XX, KINETIS and i.MX RT / Re: Need a suggestion on best way to implement a 10ms timeout

« on: November 01, 2019, 08:17:28 PM »

Thank you, Mark for your confirmation that the Kinetis part is compatible with the general purpose timer setup.

I set up the timer for a 10ms timer interrupt using:

timer_setup.int_handler = flexTimer1DelayIntHandler;
timer_setup.timer_value = TIMER_MS_DELAY(10);             // timer delay until interrupt

When I measure the time from the call to fnConfigureInterrupt((void *) &timer_setup) until the callbck_interrupt, flexTimer1DelayIntHandler, I measure exactly 16us on the oscilloscope.  Changing the value in the TIMER_MS_DELAY() (for example: 1000) does not change the 16us interrupt time.

I have stepped through the kinetis_FLEXTIMER.h code and noticed that after the iPrescaler is determined, the updated uDelay is directly assigned to the ptrFlexTimer->FTM_MOD register.  Should it not be assigned to "ulDelay+ptrFlexTimer->FTM_CNT" since the FTM_CNT cannot be assumed to be zero except after reset.  I changed this, but it had no effect in changing the 16us time in servicing the interrupt.

Do you have any suggestions on why I get such a short timeout?  I have gone through the program code and the iPrescaler, ulDelay, and assignments look correct for a 10ms timeout but what I measure on the oscilloscope shows this not to be true.
 

21

NXP^TM M522XX, KINETIS and i.MX RT / Need a suggestion on best way to implement a 10ms timeout

« on: October 31, 2019, 10:12:48 PM »

I am using a Kinetis microcontroller and I would like to know what is the preferred way to add a timeout after waiting 10ms for the I2C queue have enough room for the next message to send.  I have read both uTasker documents "Global Software and Hardware Timers" and "uTasker - Hardware Timers".  Based on the documentation and uTasker code, it looks like the best way to go is to use a hardware timer since the global timer tick resolution is 50ms and I need a 10ms timeout.  It looks like the FlexTimer is the hardware timer to use with a Kinetis microcontroller.  Would the correct settings be:
void
flexTimer1Delay (unsigned long timerDelayInUsec)
{
    /*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
    static TIMER_INTERRUPT_SETUP    timer_setup = {0};              // interrupt configuration parameters
    //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    timer_setup.int_type = TIMER_INTERRUPT;
    timer_setup.int_priority = PRIORITY_TIMERS;
    timer_setup.int_handler = flexTimer1DelayIntHandler;
    timer_setup.timer_reference = (_TIMER_1 | 0);   // timer module 1, channel 0;
    timer_setup.timer_mode = (TIMER_SINGLE_SHOT | TIMER_US_VALUE);  // single shot us timer
    timer_setup.timer_value = timerDelayInUsec;                     // 100? delay
    fnConfigureInterrupt((void *) &timer_setup);                    // enter interrupt and start timer
}

I do not see TIMER_SINGLE_SHOT or TIMER_US_VALUE used in the kinetis FlexTimer code, so I am uncertain of what to set the timer_mode to.  Any suggestions on how to set this timer up for a 10ms timeout to call the int_handler function would be appreciated.

Thank you.

22

NXP^TM M522XX, KINETIS and i.MX RT / Attempt to add the FreeMASTER 2.0 Driver to uTasker

« on: September 11, 2019, 10:09:52 PM »

I know uTasker has optimized FreeMASTER support built into it, but I wanted to see if I could integrate the latest FreeMASTER driver that NXP supplies and use that with uTasker instead.  I was going to first start with a known working FreeMASTER communication driver (version 2.0) I have used in the past with FreeRTOS with uTasker, then move onto the latest 3.0 driver.

Installation
In order to use the FreeMASTER 2.0 driver, the present Freemaster.c file must be excluded from the build and definition FREEMASTER_UART must be defined.
Proceed with the following steps:
   1. Add the FreeMASTER 2.0 driver source code to the project.
      a. Include the necessary source code files and exclude the others.
   2. Add the include directories to the project.
   3. Modify the freemaster_cfg.h file as appropriate.
   4. Modify freemaster_serial.c
      a. Change FMSTR_Poll(void) to FMSTR_Poll(QUEUE_HANDLE FreemasterPortID, unsigned char ucInputMessage[])
      b. Change FMSTR_ProcessSCI(void) to FMSTR_ProcessSCI(QUEUE_HANDLE FreemasterPortID, usngined char ucInputMessage[])
         i. Disable direct serial register reads and writes in this function, use uTasker fnWrite() and fnRead() instead.
   5. Modify application.c
      a. Add an include to freemaster.h
      b. Comment out the while loop for fnHandleFreeMaster() and replace with FMSTR_Poll(FreemasterPortID,ucInputMessage) call.

Result
The uTasker application runs, but the FreeMASTER communication fails.  When FreeMASTER PC application version 2.5.13.0 is set for COM port and baud rate of uTasker FreeMASTER port, the communcation fails.

Any suggestions on what might be causing the board to not detect the PC connection?

23

NXP^TM M522XX, KINETIS and i.MX RT / uTasker OS - Small FLASH/RAM footprint with Solid Performance

« on: September 10, 2019, 08:55:21 PM »

I wanted to share with this group my experience with finding an operating system that "out of the box" had most of the features our product, an oxygen concentrator, needed in a small FLASH footprint with solid performance.

I am the embedded firmware developer for this project.  I have had over 33 years working with embedded systems, starting out with an Intel 8051 for an infrared touch panel controller for a flat panel AC plasma display to using the latest Kinetis KE14Z ARM Cortex-M0+ microcontroller for an oxygen concentrator.  In the 1980s and 90s designing code to meet the requirements of a product that used a microcontroller was manageable for a single individual.  As time marched on, the requirements for a product became more challenging to meet.  Some of these features are USB connectivity (MSD), File Systems (FAT32), Ethernet connectivity (TCP/IP), bootloader for field upgradeability, cryptography, and LCD support.  Designing embedded code with these features and without a reliable OS today can be an overwhelming task.

My recent project had me looking for a very low cost microcontroller that could meet the growing marketing requirements of this marketing such as:
   1. Allowing reliable field upgradeability through an easy and reliable method to update the firmware through a UART connection.  uTasker has many other options to update firmware in the field securely through USB, MSD, SD, Ethernet, SPI FLASH.
   2. LCD support
   3. Fault tolerate storage of non-volatile data
   4. Smallest FLASH/RAM footprint because of high volume of the product
   5. A way to visualize during development, manufacture, and service the operation of the device.

After evaluating several manufacturer's microcontrollers, the most cost effecive solution was NXP's KE14Z microcontroller.  The big differentiator was FreeMASTER.  FreeMASTER far surpased the closest competitor, uC/Probe in my evaluation.  The next step was to find an operating system and middleware.  Looking first at FreeRTOS with FreeMASTER and SDK support worked well, but was lacking in requirements 1, 2, 3 and 4.  As I searched the internet, I came across a product called, uTasker, by M.J.Butcher Consulting.  Studying uTasker website, www.utasker.com, and its documentation/videos, it became clear that this product could meet all the requirments "out of the box".  Since the full source code is available for evaluation as well as support from the author himself, Mark Butcher, I found the only cost I had was the evaluation time.  What I have found during my 4 months of development on the project:
   • uTasker is extremely code efficient.  Most options are dependent on preprocessor definitions which only allow code to compile if the option is defined.  Evaluating MCUXpresso SDK with the ConfigTools was found to use a much greater amount (8x) of code space than uTasker.
   • uTasker is deterministic.  I have designed my system for a 1 ms interrupt timer which is exactly 1 ms while maintaining the other support options being event driven in the background.
   • DMA as well as hardware ADC sampling are designed into uTasker for the most efficient operation automatically taking advantage of hardware built into the microcontroller.
   • Low power is designed into uTasker in every area that can be put into a low power mode when not used.  If low power is not desired, using one simple definiton allows you to turn off this feature.
   • uTasker is NOT multi-threading, but co-operative.  This is an important point to remember.  If you want to run two independent threads, you will need to design your code to manage them co-operatively.  I found being forced to design this way made me more aware of potential problems and how to design them out before they became a problem.
   • uTasker has a FREE simulator mode built in it that is really very good.  uTasker was designed to work with Visual Studio.  The same code that drives your embedded product can be recompiled to drive a virtual project.  All the GPIO, USB, Ethernet, UART have been rerouted to use your PC resources within uTasker.  You can even interact and customize the simulator graphics using various common PC tools.
   • The cost of uTasker is very resonable for the quality and support that is given.
   • Mark Butcher has been working on uTasker for over 12 years, so the product is very mature, stable, and continues to be supported with useful interfaces.

The only commitment is that you will need to put some time into reading the documentation and watching the videos to understand how to modify uTasker for your needs.  From my point of view though, this is educational time (and fun) that even if you decide not to use uTasker, you will be a better embedded software developer because of this time investment.

24

NXP^TM M522XX, KINETIS and i.MX RT / Re: Does built in FreeMASTER support of uTasker allow write of global variables?

« on: September 03, 2019, 10:24:28 PM »

Thank you for the suggestion, Mark.

I did change FMSTR_USE_WRITEVAR and FMSTR_USE_NOEX_CMDS from 0 to 1, but it did not give FreeMASTER the ability to write a new value to a global variable.  What I did find after looking through the code is that if I define "FREESCALE_FREEMASTER" and pass the FreemasterPortID in the function call FMSTR_ProtocolDecoder(FreemasterPortID,ucFreemasterBuffer), which are now enabled by the FREESCALE_FREEMASTER definition in function fnHandleFreeMaster(), FreeMASTER with uTasker allows global variable modifications.  I also tried setting FMSTR_USE_WRITEVAR and FMSTR_USE_NOEX_CMDS back to 0 and the write ability to global variables is not affected.  I think the call the FMSTR_ProtocolDecoder() was what was needed to give FreeMASTER the ability to modify global variables.

You mentioned that uTasker environment does add the capability to write values in Flash or SPI Flash.  How is this enabled and used with FreeMASTER?  One of the features I want to add to FreeMASTER is the ability to read and modify the Parameter memory through the temp_pars pointer in application.c, but I cannot seem to find a way that FreeMASTER can address the temp_pars pointer structure.

Thank you for your help.

Tom

25

NXP^TM M522XX, KINETIS and i.MX RT / Does built in FreeMASTER support of uTasker allow write of global variables?

« on: September 03, 2019, 05:23:57 PM »

I have been able to use the built in FreeMASTER driver provided with uTasker by enabling the "FREEMASTER_UART" definition and using the UART channel set for DEMO_UART (I changed the DEMO UART channel to a different UART number from FREEMASTER_UART_CH).  When I run FreeMASTER, I have found that it is not possible to modify the value of a global variable.  I can read and plot the global variables, but I cannot modify (write) them.  I have enabled FreeMASTER variable watch to allow modification of the variable using the "Modifying" tab, but stepping through the code, I do not see the variable modified and FreeMASTER does not show the variable modified on the Variable Watch display.  I have looked through the FreeMaster.c file included in uTasker version 1.4.12 19.02.24, and I do not see a case statement that allows a global variable to be modified in function, fnHandleFreeMaster().  Does the uTasker FreeMASTER version handle modification of global variables?  Would I need to enable FREESCALE_FREEMASTER definition in uTasker to allow the global variables to be modified?

Thank you.

26

µTasker general / Does uTasker support a UART connection to its Web Serrver?

« on: August 20, 2019, 10:28:24 PM »

Hi Mark,

Can uTasker support a UART connection to the Web Server?  The uTasker "Kinetis Tutorial - Ethernet and the Simulator" document demonstrates the web server built into uTasker through an Ethernet connection.  Is it possible to route the Ethernet connection through the UART on a NXP KE15Z microcontroller with uTasker?  On the PC side, it is desired to use a browser such as Google Chrome to communicate through the a COM port connected to the KE15Z UART.  If this is possible, does the uTasker project contain definitions that would make this happen and allow the Demo Web Server to work as detailed in the section 6 of the Kinetis Tutorial document?

Thank you.

27

NXP^TM M522XX, KINETIS and i.MX RT / Re: Peripherals+ view does not show many special function registers using uTasker

« on: June 27, 2019, 10:12:18 PM »

Hi Mark,

Thank you so much for that information.  You are correct, it was the processor setting.  I went into the Properties for the uTasker project and changed the C/C++ Build->MCU settings processor from Preinstalled MCUs "Generic-M0plus" to SDK MCUs "MKE15Z256xx7".  When I started a new Debug session, All of the registers that were shown in the SDK wizard generated program show up in the uTasker project.

28

NXP^TM M522XX, KINETIS and i.MX RT / Peripherals+ view does not show many special function registers using uTasker

« on: June 27, 2019, 09:43:38 PM »

Does someone know how to add more special function registers (SFRs) to the MCUXpresso "Peripherals+" view when the uTasker configuration is used?  When I debug I get three SFRs: DCR and NVIC, but when I debug with a project generated by an MCUXpresso SDK wizard I get all the SFRs.