Recent Posts

Pages: [1] 2 3 ... 10
µTasker general / uTasker, Eclipse (MCUXpresso), Visual Studio, and the Indexer
« Last post by tdrobnak on November 27, 2019, 05:14:45 PM »
The uTasker project uses definitions in application.c to enable specific features for testing:

    #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
    #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

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.

µTasker general / Re: My experience on Upgrading uTasker for the KE15Z
« Last post by mark on November 22, 2019, 11:49:42 PM »

Great - thanks for the feedback!


µTasker general / Re: Should multiple handles be used on a single physical I2C channel?
« Last post by mark on November 22, 2019, 11:47:31 PM »

I found GIT to be a game changer for me. It is possible to have one repository for the framework and then a repository for each individual project in the framework. This allows all projects to share the framework (and its repository with capability to switch between each individual version at will) and each project directory to have its own such independent control too.

This I find both very convenient (history, change documentation, backup) and efficient.

Once a project is completed one can either commit the total code base to a dedicated, frozen project repository (to be sure of the complete code base) or else the framework check-in point noted so that it can be exactly recreated from the framework repository if ever needed. Any framework bug fixes that are made are valid for all projects and so each project can also be rebuilt at any time in the future to potentially benefit from such.


µTasker general / Re: My experience on Upgrading uTasker for the KE15Z
« Last post by tdrobnak on November 22, 2019, 10:47:19 PM »
Thank you for the update, Mark.  I just pulled them into my latest uTasker project, built the executable, and FreeMASTER on the serial port is working well with your new changes to the LPUART0 ALT 6 configuration.


Thank you, Mark for your recommendation on pulling the latest version.  I am new to GIT since we use SourceGear Vault at the company I work for.  I have found that GIT does make it very easy to update uTasker by doing a "git pull" on the latest commit.  My project directory is not affected by the pull since it is in the Untracked files.  Only the updated uTasker files will be replaced.

µTasker general / Re: My experience on Upgrading uTasker for the KE15Z
« Last post by mark on November 22, 2019, 01:43:04 AM »
Hi Tom

1. I think your problem with CO_driver.h is that you used an older MCUXpresso project which doesn't exclude the file CO_OD.c. CO_OD.c is a file that is generated by CANopen tools and included when needed (when CAN and CANopen are enabled) via a different C file that supplies the headers to it.
If you exclude this file in the Eclipse tool chain (which will add all found C-files to the project by default if not done) it will also solve the issue.

2. The KE15 has only been set up for LPUART1 (for its evaluation board) so I suspect that you added these changes previously and they are missing when you update to the latest version.

To cover all LPUART0 pin-out possibilities for the KE15 I have just added:
        #define PB_1_LPUART0_TX          PORT_MUX_ALT2
        #define PA_3_LPUART0_TX          PORT_MUX_ALT6
        #define PA_10_LPUART0_TX         PORT_MUX_ALT3
        #define PB_0_LPUART0_RX          PORT_MUX_ALT2
        #define PA_2_LPUART0_RX          PORT_MUX_ALT6
        #define PA_11_LPUART0_RX         PORT_MUX_ALT3

and (for LPUART0_TX config)
            #if defined LPUART0_ON_B
            _CONFIG_PERIPHERAL(B, 1, (PB_1_LPUART0_TX | UART_PULL_UPS)); // LPUART0_TX on PB1 (alt. function 2)
            #elif defined LPUART0_ON_A_HIGH
            _CONFIG_PERIPHERAL(A, 10, (PA_10_LPUART0_TX | UART_PULL_UPS)); // LPUART0_TX on PA10 (alt. function 3)
            _CONFIG_PERIPHERAL(A, 3, (PA_3_LPUART0_TX | UART_PULL_UPS)); // LPUART0_TX on PA3 (alt. function 6)

and (for LPUART0_RX config)
            #if defined LPUART0_ON_B
            _CONFIG_PERIPHERAL(B, 0, (PB_0_LPUART0_RX | UART_PULL_UPS)); // LPUART0_RX on PB0 (alt. function 2)
            #elif defined LPUART0_ON_A_HIGH
            _CONFIG_PERIPHERAL(A, 11, (PA_11_LPUART0_RX | UART_PULL_UPS)); // LPUART0_RX on PA11 (alt. function 3)
            _CONFIG_PERIPHERAL(A, 2, (PA_2_LPUART0_RX | UART_PULL_UPS)); // LPUART0_RX on PA2 (alt. function 6)

This means that the three options can be selected (from app_hw_kinetis.h) but it defaults to the one you use. This means that if you pull the version again you will have the configuration suitable for your HW.

As you know it is easy to add new pin configurations and, since there are a large number of possibilities for all possible part types the list is probably never 100% complete. In such a case simply add the new pin config as you did and send me the file - then i can ensure that any such setups are specifically added to the repository so that they are there for all future pulls.

If you haven't seen the video showing how to work with your own project embedded in the uTasker framework you can see it at:
In the case of Eclipse projects your setup (in the root) can be copied to the MCUXpresso\Project_Settings director in your own application folder before cloning the framework (since it will be overwritten). Afterwards copy it back to the root. This is a minor complication with the Eclipse project method but not a big deal.



P.S. Before I check in the new LPUART muxes I'll make sure also LPUART1 and LPUART2 Rx/TX set is included for the KE15
µTasker general / Re: Should multiple handles be used on a single physical I2C channel?
« Last post by mark on November 22, 2019, 12:47:46 AM »

The aim is to be retain backward compatibility in the framework so generally it should be always possible to pull the latest version to get newest bug fixes and additional features. Pulling the latest version will not cause code size increases due to new features since these first need to be enabled (config.h and app_hw_xxx.h in the uTaskerV1.4 can be used to see new defines).

It is not possible to guarantee 100% due to the large possibilities (many boards, processors and options/features) but in case of anything not working post a report and switch back to an earlier check-out to continue working.



µTasker general / My experience on Upgrading uTasker for the KE15Z
« Last post by tdrobnak 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  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.

Hi Mark,

Thank you for identifying the difference in version I am using and a later one that you have coded to handle the repeated start condition.  Replacing the kinetis_LPI2C.h file with the newer one you provided fixed the missed uTaskerStateChange(ptrRxControl->wake_task, UTASKER_ACTIVATE).  My application is now working with both TASK_ALTITUDE_SENSOR and TASK_LED_DRIVER.

I did run into one compilation error on the kinetis_LPI2C.h file.  It looks like a new macro is used: WRITE_ONE_TO_CLEAR_INTERRUPT(ptrLPI2C->LPI2C_MSR, LPI2C_MSR_SDF, irq_id).  This one does not exist in my code version, so I replaced it with WRITE_ONE_TO_CLEAR(ptrLPI2C->LPI2C_MSR, LPI2C_MSR_SDF) and the code now compiles and executes with the desired result.

This leads me to the question of if it would be a good idea to update my version of uTasker to the latest in the GIT repository or do you have a specific version that you would recommend.  It might be a little effort on my part to merge my code into the latest version of uTasker, but if this will fix some behind the scene driver issues and not cause what has been working to fail, I will do it.  This missed scheduled task activation issue has cost me a few days of lost time while I try to understand the uTasker code and provide detailed enough observations for some assistance.  If you think using your a later version than uTasker_1.4.12.2019.02.28 for the Kinetis KE15Z processor then please let me know.

Thank you.

µTasker general / Re: Should multiple handles be used on a single physical I2C channel?
« Last post by mark on November 21, 2019, 12:32:53 AM »

Reads and writes are queued and so adding a write while a read in is process should not have any impact on the read.

Note that when a read is started the state is set to
I2C_tx_control[Channel]->ucState |= (RX_ACTIVE | TX_ACTIVE);

Then note that when a write is started the generic I2C driver layer (i2c_drv.c) will copy the write to the output queue:

rtn_val = fnFillBuf(&ptI2CQue->I2C_queue, ptBuffer, Counter);

and then initiate it ONLY when the channel is idle:

            if ((ptI2CQue->ucState & (TX_WAIT | TX_ACTIVE | RX_ACTIVE)) == 0) { // if idle we can initiate transmission
                fnTxI2C(ptI2CQue, channel);                              // initiate transmission

Therefore the fact of queuing a write during a read transfer simply puts the write to the queue (without affecting the in-progress read in any way).

What I can't exclude is a problem in the LPI2C driver itself since it was added a long time after the standard I2C driver (in Kinetis project) and is only available in a small number of Kinetis parts (less well used/verified). So taking a quick look I immediately see that your version is not the same as mine (yours is pre-24.3.2019 check-in), which means that it probably makes sense to ensure you are using the present version in case such behavior may have been improved since then.

I have attached my file - there is no mention of a fix in its header (added new features) but the idea is that the RX_ACTIVE flag can only be changed after a read transfer has terminated and the owner task is scheduled each time the final expected byte has been put into the I2C Rx buffer. I didn't see that this could be missed but I do question that (in your version) the code that you show is executed only on a stop condition detection (a read immediately followed by a write tends to be performed with a repeated start and then there is no stop bit (??)). Therefore the latest version does look more realistic in this respect....



Pages: [1] 2 3 ... 10