Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - mark

Pages: 1 [2] 3 4 ... 19
16
NXPTM M522XX, KINETIS and i.MX RT / i.MX RT 1020 Reference goes on-line
« on: February 21, 2020, 03:12:09 AM »
Hi All

First full-featured uTasker i.MX RT reference is now on-line: https://www.utasker.com/iMX/RT1020.html
Showing HS USB, TCP/IP and boot loading concept as integrated solution:

- USB-MSD / KBOOT composite loader
- Embedded FTP and web server with files in QSPI flash
- Telnet, USB-CDC, UART command line interfaces
- HS USB MSD composite with emulated FAT for viewing and transferring logged data


Complete reference project (including boot loader concept) runs on any i.MX RT or Kinetis part with the necessary peripherals.

Regards

Mark

17
NXPTM M522XX, KINETIS and i.MX RT / i.MX RT 1021 User's Guide
« on: November 14, 2019, 02:18:25 AM »
Hi All

This is the i.MX RT 1021 User's Guide that is being prepared for the release of the i.MX RT project:
http://www.utasker.com/docs/iMX/i.MX_RT_1021_uTasker.pdf

For those interested in these parts this document is a good reflection of the development state. Although it is specifically for the i.MX RT 1021 much of its content is valid for other types.

The document also states some specific aims of the project concerning project compatibility between Kinetis and i.MX RT 1021 focus on achieving maximum performance with minimal costs.

Regards

Mark

18
µTasker general / Nested Interrupts in Cortex Projects
« on: August 18, 2019, 03:32:54 AM »
Hi All

Cortex processors support nested interrupts, which means that interrupts with a higher priority than the present interrupt can interrupt the present interrupt.
This allows prioritising interrupt handling but at the same time means that each interrupt routine has to be careful with its use of variables and subroutines if it knows that it could be interrupted by others that are accessing the same variables or could both use subroutines that are not designed to be thread-safe.

uTasker driver interrupt handlers use the following strategy by default: they disable the global interrupt when user interrupt callbacks are executed. This can be seen in the looking at the interrupt handler in the Kinetis Periodic Interrupt Timer:

        if ((ptrCtl->PIT_TCTRL & (PIT_TCTRL_TIE | PIT_TCTRL_TEN)) == (PIT_TCTRL_TIE | PIT_TCTRL_TEN)) { // if the channel and its interrupt are enabled
            if ((ptrCtl->PIT_TFLG & PIT_TFLG_TIF) != 0) {                // {8} if this channel's interrupt has fired
                WRITE_ONE_TO_CLEAR(ptrCtl->PIT_TFLG, PIT_TFLG_TIF);      // clear pending interrupts
                if ((ucPITmodes & (PIT_PERIODIC << (iChannel * 2))) == 0) { // if not periodic mode (single-shot usage)
                    fnDisablePIT(iChannel);                              // stop PIT operation and power down when no other activity
                }
                uDisable_Interrupt();
                    pit_interrupt_handler[iChannel]();                   // call handling function
                uEnable_Interrupt();

                if (IS_POWERED_UP(6, PIT0) == 0) {                       // if the PIT module has been powered down we return rather than checking further channels
                    return;
                }
            }
        }


Assuming the PIT interrupt has a priority of 2 it can be interrupted (nested interrupt) by higher priority interrupts during its execution up to the point where uDisable_Interrupt() is called. When the user interrupt callback is executed [pit_interrupt_handler[iChannel]() in the example] all interrupts are disabled and so the user doesn't need to 'worry' about being interrupted by a higher priority interrupt. There is therefore no 'risk' the variables that it is accessing could be modified by other interrupts with higher priority or that subroutine calls that it uses could fail since they haven't been designed to allow being called but other interrupts that could take place during their execution.
Although there may be a potential disadvantage in not allowing higher priority interrupts to be executed this technique ensures reliability (by default) without needing to consider carefully any dangers that nested interrupts could pose.


If the user does prefer to allow higher priority interrupts to be taken during the execution of the handler the user can add
uEnable_Interrupt();
...
uDisable_Interrupt();

around the code in the interrupt callback that should allow nested interrupt operation, in which case higher priority interrupts can be taken.
The user must however carefully consider what could happen when other interrupts interrupt the code - could the other interrupts potentially cause variable corruption when both could modify the same variable? And are used subroutines safe to be called by the present interrupt and potentially be interrupted and called by a higher priority one?


In the case of Cortex M3/M4/M7 (but not Cortex M0, which doesn't have the capability) a further strategy is supported in the uTasker project [check the exact project version used to see whether this support is included] and requires the following defines to be enabled and set accordingly


    #define SYSTEM_NO_DISABLE_LEVEL       1                              // allow interrupts of higher priority than this to not be blocked in critical regions
    #define LOWEST_PRIORITY_PREEMPT_LEVEL 0                              // normal level is for all interrupts to be able to operate


When SYSTEM_NO_DISABLE_LEVEL is enabled the effect of
uEnable_Interrupt()
and
uDisable_Interrupt()
changes from disabling and enabling the global interrupt to changing the interrupt acceptance mask (using the BASEPRI "Base Priority Mask Register" as detailed at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/CHDBIBGJ.html).

When the user callback is executed, all interrupt below a certain priority level (greater priority than 1 in the example) are still allowed to be nested but not interrupts of equal or lower priority.
This allows the user to easily specify which interrupts (higher than SYSTEM_NO_DISABLE_LEVEL) are allowed to interrupt lower priority ones and which ones are not (lower or equal to SYSTEM_NO_DISABLE_LEVEL).

Again it is up to the user to carefully check that interrupts that can nest others are not potentially corrupting shared variables or using subroutines that are not safe to use when a lower priority interrupt is already executing them.

Regards

Mark



19
NXPTM M522XX, KINETIS and i.MX RT / i.MX RT 1020 GPIO and Pin Multiplexing
« on: February 10, 2019, 01:47:34 AM »
Hi All

The following video shows the level of compatibility of uTasker projects with the i.MX RT 1020 (300MHz Cortex-M7) by looking a the GPIO and pin multiplexing philosophies and use of port macros: https://youtu.be/SmFTi8hlba0

The pin mux. spread sheet shown there is attached to this post.

The latest version of the document is included in the project folder: \Hardware\iMX\GPIO_PERIPHERALS

Regards

Mark


20
STTM STM32 and STR91XF / Arduino Blue Pill
« on: January 27, 2019, 11:55:40 PM »
Hi All

I have just completed integration of the Arduino Blue Pill - a < $2.00 development board - and published this video showing the uTasker USB-MSD loader used to load a couple of application configurations:
https://youtu.be/dq-m-Dokq7E

Overview of the board and some binaries: http://www.utasker.com/stm32/BluePill.html

Regards

Mark

21
STTM STM32 and STR91XF / STM32F4xx Flash Options Video
« on: December 01, 2018, 02:28:28 AM »
Hi All

The following video explains and demonstrates Flash Option settings for Flash Sector write protection and Flash read-out protection on the STM32F429 (valid or similar for various other STM32 processors too):
https://youtu.be/IN_U7QsYQlc

The binary used in the video is attached to this post for anyone wishing to try it themselves on a NUCLEO-F429ZI.

Regards

Mark

22
Hi All

Optional addition AES-256 strength encryption/decryption has been added to the KBOOT compatible (UART and/or USB-HID) modes of the serial loader. This can be seen in this new video:
https://youtu.be/MXsJvTdCcH4

The encryption is performed by the new version of the the uTaskerConvert V1.11 utility: http://www.utasker.com/forum/index.php?topic=1445.0

Regards

Mark



23
µTasker general / MQTT Implementation in the uTasker project
« on: March 13, 2018, 03:26:30 AM »
Hi All

Please see the following new video, user guide and test binaries for the new MQTT implementation:

The following video shows MQTT in action on FRDM-K64F and FRDM-K66F boards:
- https://youtu.be/-_CV2aXHyjw

The uTasker MQTT User's Manual can be found here:
http://www.utasker.com/docs/uTasker/uTasker_MQTT.pdf

and binary files for experimenting with live MQTT on FRDM-K66F and FRDM-K64F boards can be found at
- http://www.utasker.com/kinetis/FRDM-K64F.html#MQTT
- http://www.utasker.com/kinetis/FRDM-K66F.html#MQTT

Regards

Mark

24
Hi All

There is a new video at https://youtu.be/_7Rxdr0NKWE
showing how to clone the uTasker application to a new project directory when using an Eclipse based IDE - the example used KDS.

This has the advantage that the environment/drivers/libraries can be shared between the two (or more) applications and also be kept synchronised to its GIT repository.
Each application can have its own repository if desired.

Regards

Mark

25
Hi All

The Kinetis project includes a BAT file that can be used as a port-build step in Visual Studio to cross-compile for the HW target.
I don't know why but some versions of make.exe, which is used in the GNU tool chain (for example by KDS) gives an error when it tries to work with the make file and the error is
make (e=2): The system cannot find the file specified.

Possibly it has something to do with formatting in the make file (like use of TABs and/or spaces) since I know that this was rather sensitive in the past.

If this problem occurs I use a version of make.exe that i have copied for a version of the tool-chain that has always operated well/correctly and simply replace the one that fails.

This version is attached for use by anyone who encounters the same issue...

Good luck

Regards

Mark

P.S. The attached version is as follows (make -v)

GNU Make 3.82
Built for i686-w64-mingw32
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


An example of a version that fails can't display its details due to a missing DLL called "intl.dll", which may be the reason for the error when not used in a certain environment.



26
µTasker general / I2C Slave loader - document and video
« on: January 23, 2018, 05:48:16 PM »
Hi All

Please note that I2C Slave loading has been added to the Serial Loader as explained in the updated document at http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf

There is a new video showing it in operation and also discussing some I2C slave operation details based on a logic analyser recording of the process:

https://youtu.be/awREsqeCEzQ

Regards

Mark


27
µTasker general / Cortex-M4 Bit-banding
« on: October 19, 2017, 06:32:18 PM »
Hi All

Note that there is a new video discussion practical use of bit-banding on Cortex-M4 Kinetis.

https://youtu.be/FZnkZ1h_EAQ

Regards

Mark

28
USB / USB-CDC Host
« on: July 22, 2017, 11:58:15 AM »
Hi All

This topic has been created from snippets from a different thread (from Paul) and will be continued here:

PS: Thank you for the usb stack fixes, all my problems seem to be gone :)

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 :)


Continued...

29
USB / Welcome to the USB board
« on: July 22, 2017, 11:54:36 AM »
Hi All

Although USB device has been supported on various processor since around 2008 there hasn't previously been a board specifically for USB. During the project development a number of device classes have been added and flexible composite operation, as well as some host classes.

This board has now been added to allow discussions specific to USB to be be better maintained.

Regards

Mark

30
LCD Graphics Library and Simulator / FT800
« on: July 22, 2017, 11:19:16 AM »
Hi All

This topic has been deviated from a more general thread (based on K64F) and continued here.

Original announcement:
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.

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

Specific technical question:
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?


Continues here....

Pages: 1 [2] 3 4 ... 19