Topics

31

NXP^TM M522XX, KINETIS and i.MX RT / uTasker for Kinetis Update (PPP, FT800, FreeRTOS, MCUXpresso)

« 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

32

µTasker general / Application using FAT Emulation

« on: April 22, 2017, 07:39:09 PM »

I'm going to work on trying to get an emulated FAT working next, with the full speed mode, so that I can get the MSD requests into my code, and then I'll have to figure out what kind of backside transfer protocol I'm going to use, to transfer the data to the pi, and back.  I'm still willing to do more testing, if I can help you with the HS side of things, so just let me know if there's something you want me to try.  I've also got another idea on how to maybe help the process along, I'll shoot you a private message about it, in a bit :-)

There is a guide at http://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf

Mark,

Well, I've spent tonight working my way through the emulated fat tutorial, and poking around in the code that supports it.  As a result, I have another question for you.  :-)

From what I can see in the code, it appears that the emulated drive is entirely setup in memory, as arrays, when the program is initialized, and then those data structures are used to answer the USB MSD requests from the host.

I've been looking in the code, trying to figure out how, if it's possible, I would go about doing things dynamically.  i.e. ideally I would want to be able to proxy requests for a specific file across my back side interface to the Raspberry Pi, so that I could then lookup the given path on the Pi's USB hard drive, and return the appropriate file.

I am not seeing a way to implement this within your current framework though, and I am wondering if I am on the wrong path here.  Would it maybe be better for me to try to proxy the actual MSD requests across the back interface, and then attempt to implement those on the Pi side of the fence?  Or is there something I'm missing in your emulated FAT layer, that would allow me to do what I want?  Or maybe I could write a replacement for the emulated FAT layer that would allow me to do what I want?

If you were trying to implement my project, knowing what you know about your codebase, how would you go about attacking it?

Thanks in advance for any advice you can give me,

Chris

Chris

The emulated FAT uses const FAT content but not const data content. The data content can be taken from anywhere - also dynamically.

The FAT itself can't be dynamic because it is read in by the host on USB connection (that is, the host then has a local copy of the FAT and so knows how many files are available, their file objects and such. If this were to dynamically changed the host would not know about it unless the USB were enumerated again to synchronise it.

This means that your files (location, size, names etc.) must be fixed at enumeration. The content can be defined/generated when the host requests it.

The restriction of USB-MSD is that only the host may write. If the device writes (or changes things) after enumeration the host knows nothing about it because this is not something expected with USB-MSD and it can result in corruption if both sides could change things. There is no 'synchronisation' mechanism where the device informs the host that it has changed something apart from doing a complete new enumeration (disconnect/connect).

Regards

Mark

Mark,

Quote from: mark on April 21, 2017, 09:02:54 AM

    The FAT itself can't be dynamic because it is read in by the host on USB connection (that is, the host then has a local copy of the FAT and so knows how many files are available, their file objects and such. If this were to dynamically changed the host would not know about it unless the USB were enumerated again to synchronise it.

    This means that your files (location, size, names etc.) must be fixed at enumeration. The content can be defined/generated when the host requests it.


I was aware of the writing restriction, and I think I wasn't clear in what I want to do before.  I understand the FAT must be static once the USB host has connected to the device, and that basically the host then owns the writing to the device.  What I meant by dynamic is this:

I'm going to be using a USB external hard drive, plugged in to my Raspberry Pi, as a media storage drive.  This drive's contents are read-only and fixed for any given running session of the system.  (The contents on the drive will change from time to time, as I add/remove media files, but this will be done while the drive is disconnected from the car computer system, and is connected to my PC.)  So, while the Pi, and the Teensy are connected to the drive, it is read-only, and the FAT is const.

The only other consumer of the drive, will be the Raspberry Pi, but it will also interact with it in a strictly read-only fashion (i.e. streaming the same media content via a wifi connection to my kids tablets/phones etc).

The problem I was trying to figure out a design to, within uTasker, is this:  currently your emulated FAT code, has a hard coded array, down in the mass storage code, stored in RAM, with hard coded file names and sizes.  I am going to have to build this FAT structure dynamically, when the device starts, by communicating with the Raspberry Pi, and enumerating the files on the USB drive.  I'm not yet sure if I can do this in RAM, or if I will have to store it on the SD Card, as the FAT will probably be a decent size, because the drive has hundreds of folders, and thousands of files (currently about 30 GB of files, but will expand in the future I'm sure), all using long filenames.

So, I am trying to determine within your code, what functions/callbacks I have to hook, to pull this off.  From what I've seen so far, I think I'm going to have to replace your const data, with function calls back to my code, that will communicate with the Pi, and return the results.  Maybe I just need an initial function to build the FAT structure from the Pi, and then store it in RAM, or on the SDCard, and then use that to serve the USB.  I'm really not sure yet, I was just asking if you had any pointers on which would be the easiest route to attempt, or how you would attempt to tackle a project like this, given your codes architecture.  :-)

Thanks,

Chris

Chris

I haven't used the FAT emulation for some time so took a quick look at it to refresh my memory.
In fact I don't think that it is fixed in any way, as long as the define MAXIMUM_DATA_FILES is set to be adequate for your maximum requirement. mass_storage.c is not responsible for the files, just for managing the interface between the user code and the FAT emulation.

It is the application code that defines how many files there are, how they should be named, their length, etc. and later for passing data to be read from them when the host reads them. The application code is free to do this in any way it wants - the simplest being a const method which is fixed for the product or else dynamically, based on whatever needs to control it.

In case of the reference it is the application that prepares the file list (see fnPrepareEmulatedFAT() in application.c). This has a fixed set in the reference but if you supply your own version of this routine (which is the idea) you can generate a list based on the present SD card content - you will just need to delay the start the USB task till after the SD card is ready and you have collected the list for insertion.

The functions that you need to support are:

•     fnGetDataFile() to inform the mass storage task of the files that it wants to be 'visible'
•     uDatacopy() to pass data from these files to the mass storage task when it is feeding the USB-MSD with file content.

These functions may be used as they are (probably possible in most cases) or can be modified to do whatever else they need - like generating random file content or encrypting it, etc.

Therefore I don't in fact think that there are any restrictions; you just need to insert your own file list.

Regards

Mark

P.S. If you haven't done it before, set a break point in fnPrepareEmulatedFAT() to see the application setting a fixed list of files - imagine now how you could insert a dynamic list instead.
Then set a break point in fnGetDataFile() to see how the application informs the mass storage task of the list to be used. See whether that is already adequate once you have your file list ready, or else imagine how you could do this call back in a different way to suite your requirement. This is called for each file, until you terminate the list by returning 0.
Of course, do this in the simulator since it is called on each start.

33

µTasker general / MOVED: Trying to get uTasker to work with my Teensy 3.6 board

« on: April 18, 2017, 09:09:55 PM »

This topic has been moved to Freescale^TM 522XX and KINETIS.

http://www.utasker.com/forum/index.php?topic=1936.0

34

µTasker general / uTasker SHORTS playlist

« on: January 25, 2017, 05:16:57 PM »

Hi All

The following Youtube Playlist has been started to group together a series of videos that attempt to be short and to the point concerning a specific topic or demonstration:

https://www.youtube.com/watch?v=kWNlsAoMly4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q

The original intention was to have 3 minutes each. In reality they tend to be a little longer than 4 minutes on average (3 minutes just seems to be too short to pack in the minimum information) and some, which seemed short when making them, actually stretch to twice that....

An "In-depth" series is being planned too which will look at larger projects or topics that naturally require a more relaxed and time-consuming 'tutorial' approach where more "rambling" will be allowed!

Regards

Mark

35

NXP^TM M522XX, KINETIS and i.MX RT / KDS 3.2 Debug Difficulties when low power operation is enabled

« on: January 17, 2017, 05:28:48 PM »

Hi All

KDS3.2 debugging has not been reliable (hardly possible) when SUPPORT_LOW_POWER is defined.

To solve this (rather than disable the low power operation) use the "Check for Updates" command in the KDS Help menu and then allow it to install a newer version of "GNU PEMicro Interface Debugging Support".

After installing this (and optionally other updates) KDS needs to be restarted.

Then debugging works normally again!!

Regards

Mark

36

µTasker general / USB-CDC (VCOM and RNDIS) driver requiremets/installation under Window 10

« on: September 30, 2016, 12:16:43 AM »

Hi All

This is a useful reference for details about how Windows 10 accepts automatic CDC installation and how to also do a driver-less manual install if needed.

https://community.nxp.com/thread/435664

Regards

Mark

37

NXP^TM M522XX, KINETIS and i.MX RT / Kinetis USB Device Check-List

« on: July 20, 2016, 03:07:35 PM »

Hi All

I have been involved with USB Device projects on a large number of Kinetis KL, KV and K parts. During this time there have been ocassions when the USB device hasn't worked immediately - either due to a SW setting or HW problem - and the following is a list of things to consider when this is the case.
Point 1 is the most criticial for new HW since I have experienced several prototypes that didn't work until corrected!

Otherwise the USB device driver is compatible between all parts as long as the following settings don't have any deviations.

1 - HW must have correct USB regulator design (check the recommendations in the corresponding user manual and follow them accordingly)

2 - USB clock must be correct - 48.000MHz - and the minimum system/core clock of 20MHz be respected

3 - The USB bus master must be given rights to access Flash so that the descriptors can be taken directly from const memory (flash). Check FMC_PFAPR (not applicable to KL parts)

4 - The USB OTG interrupt vector ID must be correct

5 - If the chip has MPU concurrent access to MPU controller must be allowed. Check MPU_CESR on parts with a memory protection unit.

This list is believed to be complete since no other problems have ever been encountered.

Regards

Mark

38

µTasker general / uTasker Newsletter: New Year 2016

« on: January 06, 2016, 04:54:35 PM »

Hello uTasker users

Happy New Year and best wishes for a successful time in 2016!!

It has been some time since a uTasker newsletter was last sent out but the close of the old and start of the new year seems like a good opportunity to combine sending regards to the many colleagues that I have been able to collaborate with in the past and giving information to both new and old users about the present state of the project, and the direction that it is moving in.

So I'll start with some statistics to get things rolling:
- The project is now 11 years old - there is a brief history at http://www.utasker.com/history.html, which is valid up to around 2014.
- There are presently around 3'500 registered users
- The most popular target is the Kinetis with close to 1'000 registered users - this is in keeping with the fact that some of the targets have become legacy and the Coldfire V2, the most popular target up to 2012, tends to be replaced by these. In addition, the Kinetis is the target that is the present main focus of the uTasker project.

2015 proved to be the year where low power and USB devices took off in new product developments. Originally the uTasker project focused on networking, with its integrated TCP/IP stack being what most users were mainly interested in. Although there continues to be activity (such as new multi-homed support, SNMP and IGMP added in the last year or so) the jump in demand for USB and low power modes in new products meant that the uTasker USB stack has also seen some interesting advancements, such as simple configuration of composite devices, addition of new classes (including audio and network adapter classes which are in the validation stage) as well as USB-MSD and CDC "host" modes now integrated into the project.

The uTasker serial loader (with a larger amount of options and compatible on a large range of parts - http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF) has also attracted new users since it allows any application to be used with it and has saved large amounts of developing or porting time in comparison to various other options that such projects were otherwise faced with. A number of new uTasker serial loader users have in addition realised that the uTasker main project also allows their applications to be realised more efficiently, so have completed the full transition to the environment.


What I expect from 2016 is the continuation of the trend with ever more products adopting the uTasker boot loader capabilities and also requiring USB. The uTasker project is now very well equipped for these requirements and, with additional classes soon to leave the validation phase and enter production status, is destined to help save development time by being able to quickly and easily adopt this extended pallet of proven solutions together with its more traditional core (reliable scheduler, TCP/IP, low memory footprint, peripheral drivers, simulation capabilities and support).
With most of the ground work now completed for the majority of networking and USB requirements, in addition to a high percentage of coverage of existing Kinetis peripherals, the direction in 2016 is quite firmly pointing to security. The IoT trend (whatever that actually means) is certainly highlighting security requirements in small sensor based devices and so the call for an integrated solution is getting noticeably louder. Some tentative work was stared in 2015 but was overrun by other (said) requests before much progress could be made - in 2016 the tables are likely to turn so I am expecting real results and looking forward to the extended feature set to start making bigger waves.


I would like to thank everyone who has been active in the project, both recently and over the years - it is alway great to hear from people/companies who have been successfully developing their products in the uTasker environment, especially when it has proven suitable for their requirements over a period of several years. The goal is to continue developments to match changing requirements so that it continues to be suitable and efficient in a high percentage of real-work projects. If you have comments and feedback this is always welcomed and taken seriously in defining where effort is channeled to.

Again I wish you the best for the new year and great success with your work!!

Regards

Mark

39

NXP^TM M522XX, KINETIS and i.MX RT / Kinetis Flash Swap Block

« on: November 14, 2015, 08:47:06 PM »

Hi ALl

I have been doing some work with the Flash Swap Block operations and added an application/loader at the FRDM-K64F page [ http://www.utasker.com/kinetis/FRDM-K64F.html ] in case anyone is interested in îts capabilities. Also quite a lot of detail at https://community.freescale.com/message/587699#587699

Personally I don't think that it has real advantages in most applications/loaders but it is cool how two firmware versions an be swapped between. However there may still be a few cases where it could prove to provide the solution that isn't possible without the swapping mechanism.

Regards

Mark

40

µTasker general / FAT Emulation

« on: October 30, 2015, 04:36:15 AM »

Hi All

There are many appliations where a processor is used to collect data and save it to memory. Sometimes it will be saving to an SD card but often to a robust linear memory such as internal Flash or a Flash device connected via SPI.

FAT emulation is a very interesting and pratical method of using an available USB interface to allow this memory to appear as an external drive to the host (USB-MSD). It doesn't require the data to be stored in a FAT (linear storage is often much faster and more pratical for the Flash involved and also the storage algorithms when FAT is avoided) and it can be stored as raw sampled data but still be viewed/retrieved in formatted form.

I have just completed a document explaining this in more detail and also a reference allowing a Kinetis part with USB to be used to access raw sampled data as formatted .csv file for direct import to a calculator program (like Excel).
The document is at http://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf

There is a binary file that can be tested at http://www.utasker.com/kinetis/FRDM-K64F.html#MSD4

When connected to the PC host it will display some files that are in fact 'just' data in the internal Flash (that have been primed) as shown in the document.

The data from the internal Flash is visible as either raw sample data (eg. "RawData File 1.bin") which can be copied from the emulated FAT virtual disk, or as comma separated value format (the data is not stored like this but instead the emulated FAT converts it on demand) such as "Formatted Data File 1.cvs" so that it can directly be opened in Excel (for example) - see the document for an image.

This is a great technique for adding such professional data retrieval/formatting with little overhead (aso to existing applications that are based on linear storage and not FAT).

For example: this application with emulated FAT requires less that 3k more code that a USB-CDC class. The USB-MSD part (including USB device driver, FAT emulation and application) requires just 11.5k in total and so saves FAT overhead and easily fits into smallest data sampling devices with USB.

uTasker users can now add/use this technique in their projects by just enabling a single new define (FAT_EMULATION) to their existing project.

Regards

Mark

41

NXP^TM M522XX, KINETIS and i.MX RT / Protecting Access to Memory

« on: October 23, 2015, 07:06:22 PM »

Hi All

There are often requirements to protect code programmed in embedded products and both the Kinetis and Coldfire MCU devices do thsi via their Flash Configuration.

The following is a short discussion of how this can be enabled in the uTasker project; details are specifically for the Kinetis (K64) but the Coldfires are very similar.


The device security is controlled by the standalone application or primary loader's Flash configuration stetting, which is defined in app_hw_kinetis.h

Eg:
KINETIS_FLASH_CONFIGURATION_SECURITY     (FTFL_FSEC_SEC_UNSECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)

This is the case where no security is set.

The options are

    #define FTFL_FSEC           *(volatile unsigned char *)(FTFL_BLOCK + 0x02) // Flash Security Register (read-only)
      #define FTFL_FSEC_SEC_SECURE       0x00                            // MCU security status is secure
      #define FTFL_FSEC_SEC_UNSECURE     0x02                            // MCU security status is unsecure (standard shipping state of new devices)
      #define FTFL_FSEC_FSLACC_DENIED    0x04                            // freescale fatory access denied (only relevant in secure mode)
      #define FTFL_FSEC_FSLACC_GRANTED   0x0c                            // freescale fatory access granted
      #define FTFL_FSEC_MEEN_DISABLED    0x20                            // mass erase is disabled (only relevant in secure mode)
      #define FTFL_FSEC_MEEN_ENABLED     0x30                            // mass erase is enabled
      #define FTFL_FSEC_KEYEN_DISABLED   0x40                            // backdoor key access disabled
      #define FTFL_FSEC_KEYEN_ENABLED    0x80                            // backdoor key access enabled

The values are described in the K64's user's manual in section 29.34.3 (FTFE_FSEC) {don't worry about FTFL and FTFE since these are two slightly different flash controller implementations, depending on part type. The uTasker project defines use just the FTFL names since the registers are in fact compatible}.

One just needs to set FTFL_FSEC_SEC_SECURE rather than FTFL_FSEC_SEC_UNSECURE. Generally don't disable mass erase (FTFL_FSEC_MEEN_ENABLED) since then it would not be possible to un-secure over debug or EzPort based on the mass erase command in case ever needed!!!

Once the secure mode has been configured neither the debugger interface nor EzPort will be able to debug/read memory. They will however still be able to command a mass erase and unsecure the device as a part of the process. It is recommended to check that the available tools correctly support unsecuring before use. Some debuggers don't let you set this mode (they protect to avoid risk of 'bricking' development boards) but EzPort programmers should do. In case of difficulties, contact the specific debugger manufacturer to find out how to allow the mode to be programmed.

For emergencies there is a define in debug.c (EZPORT_CLONER) in both Kinetis and Coldfire projects which adds an EzPort menu so that one board can be used to command a few things via EzPort to another board (when the wires have been connected), including erasing and un-securing. The idea was to include an EzPort cloning function (hence the define name) but presently only the commands have been used.

Regards

Mark

42

µTasker general / Using SPI master in the uTasker project

« on: October 18, 2015, 03:49:58 PM »

Hi All

Since SPI usage is very particular to different slave devices it is realised based on macros which can be found in app_hw_xxxx.h for each board.
[app_hw_xxxx.h is processor family dependent, whereby xxxx specifies the type, such as app_hw-kinetis.h]

Generally it is advised to use the SPI SD card or an SPI Flash [eg. spi_flash_xxxx_atmel.h] interface as reference, whereby the following example is valid for Kinetis KL parts (other processors and sub-families may vary in the detail but the priciple remains true - see the specific references for the full details)

For example, SPI configuration for the pins that are used is something like:

        // Configure to suit special connection SPI mode at between 100k and 400k (SPI0)
        //
        #define SPI_CS1_0              PORTC_BIT4
        #define INITIALISE_SPI_SD_INTERFACE() POWER_UP(4, SIM_SCGC4_SPI0); \
        _CONFIG_PERIPHERAL(C, 5, PC_5_SPI0_SCK); \
        _CONFIG_PERIPHERAL(C, 6, (PC_6_SPI0_MOSI | PORT_SRE_FAST | PORT_DSE_HIGH)); \
        _CONFIG_PERIPHERAL(C, 7, (PC_7_SPI0_MISO | PORT_PS_UP_ENABLE)); \
        _CONFIG_DRIVE_PORT_OUTPUT_VALUE(C, SPI_CS1_0, SPI_CS1_0, (PORT_SRE_FAST | PORT_DSE_HIGH)); \
        SPI0_C1 = (SPI_C1_CPHA | SPI_C1_CPOL | SPI_C1_MSTR | SPI_C1_SPE); \
        SPI0_BR = (SPI_BR_SPPR_PRE_8 | SPI_BR_SPR_DIV_16); \
        (void)SPI0_S; (void)SPI0_D

which is used by the FRDM-KL27Z for its SD card interface (the last two instructions are required to prepare the SPI for use).


The SPI master speed is set by the SPI0_BR values - depending on the clock rate the prescaler and divide settings are chosen to give the required frequency. The values above are for 48MHz clock operation to give 375kHz SPI (48MHz/8/16)

The clock polarity and phase are configured in SPI0_C1
SPI_C1_CPHA | SPI_C1_CPOL
is 3 and with them removed it gives mode 0.

Master mode is controlled by SPI_C1_MSTR (without it it would be a slave)

To write to the SPI the macro

#define WRITE_SPI_CMD(byte)    SPI0_D = (byte)
is used.
To read
#define READ_SPI_DATA()        (unsigned char)SPI0_D

Note that it is usually necessary to wait until a byte transmission/reception has terminated:

#define WAIT_TRANSMISSON_END() while ((SPI0_S & (SPI_S_SPRF)) == 0) {}

Finally note that the SPI in the KL27 has no automatic chip select line control so a port output is also configured during initialisation.
To control the chip select line macros are also used:
        #define SET_SD_CS_LOW()      _CLEARBITS(C, SPI_CS1_0)            // assert the CS line of the SD card to be read
        #define SET_SD_CS_HIGH()     _SETBITS(C, SPI_CS1_0)              // negate the CS line of the SD card to be read


Generally the initialisation must be called once:

INITIALISE_SPI_SD_INTERFACE();

Then data can be sent and returned data from the slave read using the sequence:

SET_SD_CS_LOW();
WRITE_SPI_CMD(0x55);
WAIT_TRANSMISSON_END();
ucReceivedByte = READ_SPI_DATA();
SET_SD_CS_LOW();

This assumes that the CS line has to be asserted (low) around the Tx/Rx.

If the returned data is not required by teh code, it should normally still be read
(void)READ_SPI_DATA();
in order to clear the buffer and reset flags for the next use.

Loops can be inserted round the tx/rx code in order to transmit or read multiple bytes of data.


Based on these macros it is possible to write custom SPI code to control slve devices that have a high degree of portability and moving between interfaces, eg. SPI0 to SPI1 would require just editing the registers used in the macros.
Some SPI designs (in the processor) may vary slightly - for example some may have FIFOs to allow multiple writes to be prepared without waiting for the first to complete, or allow the SPI master to automatically control the chip select line - but the above is usually a good starting point and the additional capabilities can then be enabled in order to possibly optimise in a certain case.

Regards

Mark

43

µTasker general / XC Tracer - 72MHz K20 based Time-lag-free Variometer for Paragliders

« on: October 08, 2015, 03:29:06 AM »

Hi All

The XC Tracer [ http://www.xctracer.com ] is the result of a crowd funded project [ https://www.indiegogo.com/projects/xc-tracer/#/ ] to develop a time-lag-free variometer for use by paragliders who use it as a primary flight instrument. Flight data such as location, climb/sink rate, altitude etc. is sent over Blue Tooth to a tablet or a phone. Additional to that the flight is also recorded as an IGC or a KML file, and the flight can be displayed later on smart phone, PC or tablet.

Based on a 72MHz Kinetis K20 and using open source code with Arduino compatibility it even allow owners to adapt or futher develop its functionality if required.

Developed and manufactured in Switzerland it is already being take up as preferred flight instrument by many paragliders over the Alps, as well as other areas in the world.

Since Arduino doesn't allow connecting the device to a PC via USB in order to retrieve logged flight data (the SD card would need to be removed and inserted into a reader) nor updating the firmware via such a link, the product and project have adopted the uTasker Serial Loader as a simple method of upgrading and extending the product's capabilities. The uTasker serial loader is configured as SD card loader with USB-MSD functionality for the K20 and allows the logged data to appear on the external drive that automatically appears when the XC Tracer is connected via USB to a PC. New product firmware can now also be simply updated by owners by simply dropping it onto the disk and restarting the device.

The XC Tracer developers needed to do no more that change the start address of the product's original application and let the additional features be plugged in by the uTasker Serial Loader's proven capabilities in many Kinetis driven devices.

Hope this is of interest to all you paragliders out there!!

Regards

Mark

44

NXP^TM M522XX, KINETIS and i.MX RT / Kinetis ADC threshold/range triggering

« on: May 14, 2015, 08:31:29 PM »

Hi All

The Kinetis ADC contains value comparators which allow it to selectively sample input data depending on its input value. This means that the user can define that only samples above a certain analoge level should be recognised or values below a certain level. Furthermore, the same can be done for input values outside or inside of a range (eg. only values between 2.00V and 2.50V should be recognised, or only samples outside of this range).

If such a mode is configured the ADC is in fact operating autonomously but will only actually save the value if it is within range, meaning that it will also only inform the processor that the conversion is ready (interrupt) in this case.

The ADC operation, monitoring analoge values and/or ranges, can also continue when the processor is in a low power mode, which allows the processor to only be worken when an input in a certain range is sampled.

For example, if an analoge input is to be monitored which the procssor is only interested in when it exceeds a threshold the ADC can be configured to autonomously monitor this and only interrupt the processor when the threshold has actually been exceeded. This removes the need for the processor to poll the value and check against a limit condition (or a range) but provides immediate interruption as soon as the condition is detected by the ADC as being true.

The use of selective ADC triggering is documented in the following uTasker user's document (chapter 2), showing how it can be very simply used:

http://www.utasker.com/docs/uTasker/uTaskerADC.pdf

The uTasker simuator alows the use of selective ADC triggering to be accurately simulated in complete project code.

Regards

Mark

45

NXP^TM M522XX, KINETIS and i.MX RT / Kinetis Multipurpose Clock Generator

« on: May 06, 2015, 03:38:55 AM »

Hi All

Since the clock generator in the Kinetis is something that tends to put fear into the hearts of Kinetis users, the following discussion attempts to handle it practically based on block diagrams to show that it can in fact be easily understood and used.

See http://www.utasker.com/kinetis/MCG.html

Regards

Mark