µTasker Forum

µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: mark on July 04, 2017, 05:35:42 AM

Title: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 04, 2017, 05:35:42 AM
Hi All

I would like to point out some new features which have been added to the uTasker project for Kinetis (supporting almost all KE, KEA, KL, KW, KM, K parts) which may be of interest to professionals who are looking for major advantages for their present and future developments.

1. MCUXpressor is now supported which means that any uTasker frameworked project developed with CW, KDS, Atollic or S32 can be moved to MCUXpress with no effort. It can also be built with IAR, Keil, Atollic, CooCox, Green Hills, VS or GCC standalone or moved between these - again with no (or almost zero) effort due to the projects inherent compiler/IDE independancy. The same holds true for most processor types - almost no porting is necessary between device types since all APIs adapt themselves to the underlying HW.

2. Slip and PPP have been added so that TCP/IP project can work on serial lines as well as USB-RNDIS and Ethernet (dual-homed and multiple interfaces possible).

3. Non-blocking FT800 support (this is an FTDI graphics controller which can be connected between an SPI interface and various display types to off-load graphic processing) has been added to the project along with full integration of FTDI's FT800 emulator in the the uTasker simulator so that the graphics controller/display is also simulated. Powerful graphics applications are thus possible with small, cheap Kinetis parts since little RAM and just the SPI is required.

4. Possibly the new feature that may be the most interesting for many developers is the integration of the latest FreeRTOSv9.0.0 into the project. This allows native FreeRTOS (no special port or additional libraries needed) to be used on all Kinetis parts (and future FreeRTOS versions can simply be "dropped in" when they are available) - but the most exciting is that two operating systems are run in parallel: FreeRTOS runs any tasks that can benefit from pre-emptive characteristics and any existing project code that may be available to be reused in new design; the uTasker OS runs in parallel to allow all task that are more suited to co-operative behavior (lower memory footprint, easier behavior monitoring) to be handled by this part, along with various libraries that are not otherwise available natively to FreeRTOS users (low footprint and wide-scope FAT, USB, TCP/IP or MODBUS libraries, for example) to be immediately usable - again with almost no project development overhead.

Although not yet fully possible with the present version, it is hoped that soon also FreeRTOS users will be able to benefit from full Kinetis simulation (peripherals, interrupts, DMA) and almost real-time pre-emptive OS operation in the Visual Studio development environment. FreeRTOS has very limited native Windows testing support at the moment (with no peripherals and no actual task switching code that can be viewed) and this would allow massive simplifications in the future once ready.

All new developments are validated in real product developments (not just examples that need to be completed and made reliable) and new users receive professional support when needed. There are potentially major advantages in Kinetis based project developments to reduce time-to-market, improved code reuse and ever increasing flexible, powerful OS/integrated features that cover a very wide range of requirements.

Regards

Mark
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: kingston on July 04, 2017, 11:54:38 AM
Great news Mark! Thank you for your hard work
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: kingston on July 07, 2017, 12:32:19 PM
Hi Mark,

I have a problem when trying to use the new FT800 feature.
As soon as I set all the required defines (SUPPORT_GLCD, FT800_GLCD_MODE, FT_800_ENABLE) KEIL cannot compile the project anymore and gives the following error:
Code: [Select]
.\Objects\EKFullDemo_KBED64.axf: Internal fault: [0xb3b91b:5060300]
.\Objects\EKFullDemo_KBED64.axf: Please contact your supplier.

When I compile with KDS it works but when I start debugging with Segger it crashes the gdb-server at 99% when the application should launch.

Also does the library already support FT81X too? If not do you plan on supporting those in the future?

Thank you!

Paul
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 11, 2017, 10:24:32 PM
Hi Paul

The Keil error suggests that it has to do with the ELF file (axf). Does this mean that it has otherwise compiled and built the project and then has a problem generating the elf? Make sure that the Keil project doesn't try to include any of the emulation files. Otherwise the error requesting conacting the manufacturer since it is presumably Keil that is crashing when trying to do one of the steps (?)

Can you otherwise load and run the KDS build if you don't try to debug it?

As far as I know the FTDI emulator can be used with various FT8xx types and the application code is essentially the same for each type (although sizes of the displays look to be different). The only HW that I have used is the basic FT800 (320x240) one but the emulator interface allows various ones to be selected:

    #if defined (FT_800_ENABLE)                                           // select the emulation mode
    Ft_GpuEmu_Mode = FT8XXEMU_EmulatorFT800;
    #elif defined (FT_801_ENABLE)
    Ft_GpuEmu_Mode = FT8XXEMU_EmulatorFT801;
    #elif defined (FT_810_ENABLE)
    Ft_GpuEmu_Mode =  FT8XXEMU_EmulatorFT810;
    #elif defined (FT_811_ENABLE)
    Ft_GpuEmu_Mode = FT8XXEMU_EmulatorFT811;
    #elif defined (FT_812_ENABLE)
    Ft_GpuEmu_Mode = FT8XXEMU_EmulatorFT812;
    #elif defined(FT_813_ENABLE)
    Ft_GpuEmu_Mode = FT8XXEMU_EmulatorFT813;
    #else
    Ft_GpuEmu_Mode = FT8XXEMU_EmulatorFT800;
    #endif


In the HW initialisation code there is one area which is different for the 320x240 display against the one that the FTDI reference defaults to.

        #if defined FT_800_ENABLE
           Ft_Gpu_Hal_Wr16(0, REG_HCYCLE, 408);                         // 320 x 240
           Ft_Gpu_Hal_Wr16(0, REG_HOFFSET, 70);
           Ft_Gpu_Hal_Wr16(0, REG_HSYNC0, 0);
           Ft_Gpu_Hal_Wr16(0, REG_HSYNC1, 10);
           Ft_Gpu_Hal_Wr16(0, REG_VCYCLE, 263);
           Ft_Gpu_Hal_Wr16(0, REG_VOFFSET, 13);
           Ft_Gpu_Hal_Wr16(0, REG_VSYNC0, 0);
           Ft_Gpu_Hal_Wr16(0, REG_VSYNC1, 2);
           Ft_Gpu_Hal_Wr8(0,  REG_SWIZZLE, 2);
           Ft_Gpu_Hal_Wr8(0,  REG_PCLK_POL, 8);
                Ft_Gpu_Hal_Wr8(0,  REG_PCLK, 8);
           Ft_Gpu_Hal_Wr16(0, REG_HSIZE, GLCD_X);
           Ft_Gpu_Hal_Wr16(0, REG_VSIZE, GLCD_Y);
        #else
            Ft_Gpu_Hal_Wr16(0, REG_HCYCLE, 928);                         // original reference
           Ft_Gpu_Hal_Wr16(0, REG_HOFFSET, 88);
           Ft_Gpu_Hal_Wr16(0, REG_HSYNC0, 0);
           Ft_Gpu_Hal_Wr16(0, REG_HSYNC1, 48);
           Ft_Gpu_Hal_Wr16(0, REG_VCYCLE, 525);
           Ft_Gpu_Hal_Wr16(0, REG_VOFFSET, 32);
           Ft_Gpu_Hal_Wr16(0, REG_VSYNC0, 0);
           Ft_Gpu_Hal_Wr16(0, REG_VSYNC1, 3);
           Ft_Gpu_Hal_Wr8(0,  REG_SWIZZLE, 0);
           Ft_Gpu_Hal_Wr8(0,  REG_PCLK_POL, 1);
                Ft_Gpu_Hal_Wr8(0,  REG_PCLK, 5);
           Ft_Gpu_Hal_Wr16(0, REG_HSIZE, 800);
           Ft_Gpu_Hal_Wr16(0, REG_VSIZE, 480);
           Ft_Gpu_Hal_Wr16(0, REG_CSPREAD, 0);
           Ft_Gpu_Hal_Wr16(0, REG_DITHER, 1);
        #endif


Probably I copied the low level initialisation from one of the various FTDI demos/configurations and so I suspect that if different type/size displays are being used a set of such values will probably be needed to be inserted in glcd_cglcd.h to allow the HW to be able to operate accordingly (configuration). Obviously, if the FTDI reference can be located, the values can be transferred - and it shouldn't be much work to adjust for each type.

Regards

Mark

P.S. Did you manage to get the VS simulator/FTDI emulator to operate?
\WinSim\LCD\FT800\ft8xxemu.dll needs to be copied into the simulation exe folder so that it can be found (I didn't find a way to tell VS where to find it...). FTDI made a new version for us since it originally required VS 2012 to be used but this one (and the library) should work also with VS2015.

Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: kingston on July 13, 2017, 07:31:41 AM
As usually I did not try the simulator sorry :)
We wanted to try a color/touchscreen display for some time now so when we read about the FT800 support we ordered a FT811 evaluation kit and wanted to try it directly with our hardware.

I'm currently tied up in a project so I can't put a lot of time into getting this to work but I will try again later.

"Can you otherwise load and run the KDS build if you don't try to debug it?" I tried but it did not run for some reason.

I will report back as soon as I have more info!

Regards

Paul

PS: Thank you for the usb stack fixes, all my problems seem to be gone :)
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 14, 2017, 02:08:26 AM
Paul

For the development I used a FRDM-K64F connected to an EVE display (VM800B35A) from FTDI (3.5" with touch controller). It was then used in a K60 based HW where it behaves the same.

http://www.ftdichip.com/Products/Modules/VM800B.html

I think that we need to identify whether your kit is compatible, whether it needs a different configuration, or whether there is a different issue. Mismatches shouldn't affect the overall firmware operation - the rest should continue normally - even if the graphic controller can't communicate.

Regards

Mark



Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: kingston on July 14, 2017, 09:41:49 AM
Hi Mark,

we are using this eval kit:
http://www.watterott.com/de/5-800x480-Display-mit-kapazitivem-Touchscreen-FT811CB-HY50HD

It is connected to our KBED64 (similiar to FRDMK64) for test purposes.

I will try to build the vanilla project for FRDM-K64 and see if it works.

Regards

Paul



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

I tried it with a FRDM-K64 and KEIL can compile just fine.
When I put the firmware on the board with the same pin config you used (SPI0 and PORTC_BIT5) the display does nothing and the LCD tasks never leaves "STATE_INITIALISING_4".
As this is the first occurence of a read command (Ft_Gpu_Hal_Rd8) and it always returns 0xff I think the problem could be with my connections.

Will have to recheck everything on monday
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 14, 2017, 01:37:42 PM
Paul

It sound like you are not getting past:
if (Ft_Gpu_Hal_Rd8(0, REG_ID) != 0x7c) {                     // read register ID to check if FT800 is ready
    uTaskerMonoTimer(OWN_TASK, (DELAY_LIMIT)(0.020 * SEC), E_INIT_DELAY); // 20ms delay before trying again
    return;
}

Perhaps your module returns a different ID to the hard-coded 0x7c? If that is the case the ID should be set accordingly as a define and selected based on the part used in the main configuration.

Regards

Mark
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 15, 2017, 03:53:52 PM
Paul

I have checked in some modifications which allow configuring for the various FT8xx types (also adding a readme.txt to the FT800 folder explaining how to use it with VS 2012 and VS2015).

Here is a short video showing it in operation in the simulation environment:    https://www.youtube.com/watch?v=XxC3Y2NaaU8

I found that FT800 works as expected. FT801 also operates and is larger in size.

The FT81x parts get stuck at the line of code that was suspected:

if (Ft_Gpu_Hal_Rd8(0, REG_ID) != 0x7c) {                     // read register ID to check if FT800 is ready
    uTaskerMonoTimer(OWN_TASK, (DELAY_LIMIT)(0.020 * SEC), E_INIT_DELAY); // 20ms delay before trying again
    return;
}


In this case an ID of 0x00 is returned by the emulator. If I let it continue running (ignoring that the ID is not matching) I also get no display shown, which suggests that the initialisation is not compatible for the FT81x parts.

What I can say is that, from my experiences with the initial development, the emulator is very accurate and I believe that the real FT811 will indeed return ID of 0 if the emulator is doing so.

Therefore I think that we can conclude that we need to take the reference code for the FT81x and integrate it into the initialisation because it will very probably be different. I will try to locate this and add it because the emulator will presumably also be able to show me when it is OK without needing real HW. I expect that the application code will be compatible apart from the screen size in some situations.

In the meantime I recommend that you pull the latest version to ensure no difficulties with operation - configure for FT800 in the simulator to do initial checks. Once the FT811 mode is also responding you should then be able to confirm the same operation on the HW.

Regards

Mark
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 15, 2017, 11:48:06 PM
Paul

I tried with the FT811 and managed to get the emulator operating. There is a different set of register addresses and by adding a define for the FT81X parts to select this correctly things started working.

They have been verified (pull latest check-in for mods.) for FT800, FT801, FT810, FT811, FT812 and FT813 in the emulator.

The application may not be adapting itself perfectly since things are not centered on larger display but that would be a code optimisation that can be done quite easily once we know that the HW is also operational.

Good luck

Regards

Mark
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: kingston on July 17, 2017, 09:05:21 AM
Thank you Mark I got it working in the emulator as well now! I will check my wiring now and see if I can make it run on the real board :)

BTW:

There seems to be still a bug in the USB-Host functions where it gets stuck requesting the IN token.
I can't really reproduce it but it happens sometimes after half an hour and sometimes after 5 hours :)


EDIT:

I got the SPI communication working on my K64 device and even get 0x7c after some time but the display stays dark :/

It looks like this was a coincidence as I couldn't reproduce the 0x7c afterwards...

You use "FLUSH_LCD_SPI_RX(4);" when writing/reading from the coprocessor but I had to comment it out for my software to work as there were never 4 bytes to flush (only 2).
I haven't found this flush in other FT81X libraries can you explain if and why it is needed?
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: kingston on July 20, 2017, 08:24:04 AM
Hi Mark,

just wanted to inform you that my colleague got it working!

He is not in the office yet so I can't give you the details but he told me yesterday that it had to do mainly with wrong SPI timings.

Regards

Paul
Title: Re: uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)
Post by: mark on July 22, 2017, 11:37:43 AM
Hi Paul

I have moved the FT800 discussion to the Graphics Library board : http://www.utasker.com/forum/index.php?topic=1948.0
I have also moved the USB-CDC host discussion to a new USB board: http://www.utasker.com/forum/index.php?topic=1950.0

Regards

Mark