Topics

1

µTasker general / Does uTasker support a way to detect that I2C bus communication has stopped?

« on: October 04, 2021, 05:36:17 PM »

A recent problem was identified on the I2C bus with uTasker as the master.  An I2C RFID device was causing the SCL line to not go low enough in voltage to be detected by the other slave devices.  A start condition could be sent, but the slave devices could not detect it because of SCL.  Does the Kinetis (KE15Z) version of the uTasker I2C driver support a way to detect that the I2C bus has failed to communicate.  I found an earlier message, https://www.utasker.com/forum/index.php?topic=872.msg3822#msg3822, on this forum that said there was a MASTER_TX_DATA_NOT_ACKED case for the LPC device driver that would detect that the slave was not able to acknowledge the message.  I could not find that same MASTER_TX_DATA_NOT_ACKED case in the Kinetis I2C uTasker source code.  Does anyone know of an already programmed way to detect this situation for uTasker's Kinetis I2C driver?

Thank you.

2

µTasker general / How to distribute my application as a uTasker Simulation?

« on: September 14, 2021, 10:46:38 PM »

I would like to build my uTasker application as a distributable simulation on the PC.  I have done this, but the graphics for the Kinetis logo and the FRDM-KE15Z are missing when it is built using a setup project in Visual Studio 2017.  Does anyone know what I need to add to the VS setup project to add the missing graphics.  Also where are the missing items located in the uTasker directory?  I am sure there is a message on this forum that has this information on what is needed, but I cannot find it.  If you know where the message is, please send a link to it.

Thank you

3

NXP^TM M522XX, KINETIS and i.MX RT / uTasker FlexNVM Simulator support

« on: March 03, 2020, 02:54:19 PM »

Does anyone know if uTasker supports FlexNVM for EEPROM emulation?  NXP has two application notes on the subject:

• AN4282 - Using Kinetis Family Enhanced EEPROM Functionality
• AN5338 - How to use FlexMemory as D-Flash and EEPROM in KE1xF

I have looked through uTasker 1.4.12 and found no driver for FlexNVM so I added the necessary driver code from the NXP SDK 2.7.0 flexnvm_eeprom.c example.  I now have access to EEPROM emulation using FlexNVM when run on the hardware.  When I run on the uTasker simulator, I receive exceptions on access to the registers that control FlexNVM partitioning and status.  Has anyone else run into this situation?  Is there a way to work around it?

Thank you.

4

µTasker general / Does uTasker support independent use of multiple I2C channels?

« on: February 03, 2020, 07:52:16 PM »

Has anyone tried using two I2C channels on one microcontroller devices independently without issue?  The "uTasker Support Demo and Simulation V1.4" document describes using the I2C interface, but does not mention (or give examples) using multiple I2C channels independently: usSpeed, TxQueueSize, RxQueueSize, Task_to_wake.  Also, will the simulator be able to handle simulating separate I2C devices?

Thank you.

5

µTasker general / uTasker, Eclipse (MCUXpresso), Visual Studio, and the Indexer

« on: November 27, 2019, 05:14:45 PM »

The uTasker project uses definitions in application.c to enable specific features for testing:

#if !defined NO_PERIPHERAL_DEMONSTRATIONS
    #define _SPI_READ_CODE                                               // SPI reception checking
        #include "spi_tests.h"                                           // include SPI code to handle reception
    #undef _SPI_READ_CODE

    #define _I2C_READ_CODE                                               // I2C reception checking
    #if !defined BLAZE_K22
        #include "i2c_tests.h"                                           // include I2C code to handle reception
    #endif
    #undef _I2C_READ_CODE

    #define _ADC_POLL_CODE                                               // ADC polling operation
        #include "ADC_Timers.h"
    #undef _ADC_POLL_CODE

    #define _PORT_NMI_CHECK                                              // {53}
        #include "Port_Interrupts.h"                                     // port interrupt timer interrupt event handling - ranges
    #undef _PORT_NMI_CHECK
#endif

Specifically, the i2c_tests.h file has TEST_DS1307 defined.  When looking at the code in:
   1. Visual Studio, the code defined for TEST_DS1307 is enabled to be compiled and shown unghosted.
   2. Eclipse (MCUXpresso), the code defined for TEST_DS1307 is enabled to be compiled and shown ghosted.

Visual Studio does a good job of showing code in the editor that will be executed.  Eclipse does not do this for code included in the C source file with the definition defined in the C source file.

Is there a setting in Eclipse to make it work like it does in Visual Studio?  I believe the Eclipse Indexer is responsible for associating code and definitions viewed with the editor used in the application.  I have set the indexer with the following settings shown in the attachment.  I have been using both Visual Studio to help identify code that will be executed for the Eclipse during development, but would like eliminate this duplication and have Eclipse correctly show the executed code in the editor.

Tom

6

µTasker general / My experience on Upgrading uTasker for the KE15Z

« on: November 21, 2019, 10:40:19 PM »

Recently, I found that an issue with a task not being awakened after an I2C read call (see http://www.utasker.com/forum/index.php?topic=2047.0).  Since this issue was fixed since the build I started using for my project with uTasker, I thought it would be a good idea to use a later build that incorporated the changes I had found.  Created the following steps to upgrade my project.

Steps to Update
   1. Obtain the latest stable uTasker operating system.
   2. Unzip to a directory uTasker_latestStableBuild
   3. Create a MCUXpressoWorkspace directory
   4. Follow the uTaser instructions for creating the MCUXpresso integration of the workspace and project, but copy then import the present .cproject, .project, and .settings directory of the previous uTasker project.
   5. Copy all the .launch configurations and Revision History to the new project.
   6. Use WinMerge to find the differences.  Copy what is appropriate to recreate the project, the project directory located in the Applications directory.
   7. Clean and build the project.

I did this upgrade with uTasker_1.4.12.2019.11.15_11.40.37
After going through the "Steps to Update", on first build found that file CO_driver.h line 382, in structure definition CO_CANmodule_t had and unknown definition called QUEUE_HANDLE for CAN_interface_ID.  I found in the previous version of the file that I had, QUEUE_HANDLE was not used in CO_driver.h.    To work around this issue, I included file "types.h" since QUEUE_HANDLE is defined in this file:

#include "types.h"

Although, I did set up and build the uTaskerV1.4 project in MCUXpresso without my application code and it compiled without a problem for the FRDM_KE15Z.  I found that keeping the same Application files and importing the MCUXpresso project from the previous uTasker_1.4.12.2019.02.28 build did have one compiler problem.

After that change, the program would build, but when run, LPUART0 data was being ignored for our project.  Found that file kinetis.h did not have PA_2_LPUART0_RX and PA_3_LPUART_TX defined for PORT_MUX_ALT6 which is used in our project:

#define PA_2_LPUART0_RX           PORT_MUX_ALT6
#define PA_3_LPUART0_TX           PORT_MUX_ALT6

Found that kinetis_uart_pins.h is missing configuration of the LPUART0 port for PORT_MUX_ALT6.
Added after _CONFIG_PERIPHERAL(A, 2, (PA_2_LPUART0_TX | UART_PULL_UPS)), added line:

#elif defined KINETIS_KE15
            _CONFIG_PERIPHERAL(A, 3, (PA_3_LPUART0_TX | UART_PULL_UPS)); // LPUART0_TX on PA3 (alt. function 6)

Added after _CONFIG_PERIPHERAL(A, 1, (PA_1_LPUART0_RX | UART_PULL_UPS)), added line:

#elif defined KINETIS_KE15
            _CONFIG_PERIPHERAL(A, 2, (PA_2_LPUART0_RX | UART_PULL_UPS)); // LPUART0_RX on PA2 (alt. function 6)

I had added these definitions (see attachment files) on the previous version of uTasker and WinMerge helped identify some corrections I made to those uTasker driver level files.  The upgrade process was easy and went better than expected.  My conclusion is that uTasker is designed in a very modular which simplifies the process of upgrading your application code.

Tom

7

µTasker general / Should multiple handles be used on a single physical I2C channel?

« on: November 19, 2019, 08:03:02 PM »

After reading the "uTasker - I2C Support, Demo and Simulation V1.4" document, I have two questions concerning uTasker task scheduling after an I2C read and write.:
Given the following information:
   There are two devices on the I2C bus: ALTITUDE_SENSOR and LED_DRIVER

   1. If one physical I2C channel is being used on the microcontroller that both ALTITUDE_SENSOR and LED_DRIVER are connected to, would more than one call be needed for fnOpen():?

void
configureI2CInterface (void)
{
    /*~~~~~~~~~~~~~~~~~~~~~~~*/
    I2CTABLE    tI2CParameters;
    /*~~~~~~~~~~~~~~~~~~~~~~~*/

    tI2CParameters.Channel = OUR_I2C_CHANNEL;
    tI2CParameters.usSpeed = 100;   // 100k
    tI2CParameters.Rx_tx_sizes.TxQueueSize = 64;    // transmit queue size
    tI2CParameters.Rx_tx_sizes.RxQueueSize = 64;    // receive queue size
    tI2CParameters.Task_to_wake = TASK_ALTITUDE_SENSOR;                // task to wake on transmission

    if((I2CAltitudeSensorID = fnOpen(TYPE_I2C, FOR_I_O, &tI2CParameters)) != NO_ID_ALLOCATED)
    {   // open the channel with defined configurations
        g_I2CAltitudeSensorIDIsActive = TRUE;
    }

    tI2CParameters.Task_to_wake = LED_DRIVER;                // task to wake on transmission

    if((I2CLedDriverID = fnOpen(TYPE_I2C, FOR_I_O, &tI2CParameters)) != NO_ID_ALLOCATED)
    {   // open the channel with defined configurations
        g_I2CLedDriverIDIsActive = TRUE;
    }

Then when a write takes place it is of the form:
   For ALTITUDE_SENSOR:
      bufferToWrite[] = { 0xc0, 0xfd, 0x0b };
      fnWrite(I2CAltitudeSensorID, (unsigned char *)bufferToWrite, sizeof(bufferToWrite));
      bufferToRead[] = {1, ALTITUDE_SENSOR_ADDR, TASK_ALTITUDE_SENSOR};
      fnRead(I2CAltitudeSensorID, (unsigned char *)bufferToRead, 0);
   
   For LED_DRIVER:
      bufferToWrite[] = { 0xe8, 0x00, 0x55 };
      fnWrite(I2CAltitudeSensorID, (unsigned char *)bufferToWrite, sizeof(bufferToWrite));
      bufferToRead[] = {1,LED_DRIVER_ADDR, TASK_LED_DRIVER};
      fnRead(I2CLedDriverID, (unsigned char *)bufferToRead, 0);
      
By setting up two handles: I2CAltitudeSensorID, I2CLedDriverID uTasker can wake the appropriate task when data is written and read.
   2. If what I proposed in question 1 is not true, how would I set up uTasker to make active the task when data is written and read given only one I2CPortID handle?

Right now I have one handle for both devices called I2CPortID.  The problem is that uTasker seems to not activate the task to handle fnRead() after the data has been read unless a breakpoint is inserted after the fnRead().  When a breakpoint is inserted after the fnRead(), the the proper I2C task will handle the buffer, otherwise the task will not become active.

Any ideas of how I should proceed?

8

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.

9

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?

10

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.

11

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.

12

µ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.

13

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.