How could I use the uTasker modbus package on our custom board which is based on K60F120?
I am using CodeWarrior and MQX4.0.1. Is it possible to port uTasker modbus?
Modbus RTU or modbus TCP?
If RTU then it was my determination that the UART functions in MQX4.0.1 were lacking. I could not find interrupt driven software ring buffer support like I have built this driver upon before (about 5 times in 30 years) in other environments.
So I am taking a different tack, augmenting "mbed" for a K60F100 chip, but it will be a few weeks before I am done with that. Until my hardware is ready I've been augmenting mbed for a different cortex board for prototyping. I like C++ and CMake for embedded work, and I have created a CMake build system for the portions of mbed that interest me along with my new contributions.
My Modbus RTU driver will not be made free, but the UART class is something I will make available, probably through a cloned github repo. If any of this sounds interesting, you may contact me by personal email.
The RTU driver is something I might make available for sale. But that is not why I am writing it.
I'm not familiar with uTasker so I cannot help with Daniel's question. Dick, I've found that the MQX interrupt-driven serial IO works fine. When I create my user_config.h to build a BSP, I include lines like:
#define BSPCFG_SCI3_QUEUE_SIZE 1024
... and things work fine. This is with a K60D, not F, but I would think that the F parts would work the same. Also, Freescale provides an RS-485 example dealing with the single-pair line turn requirement: Freescale_MQX_4_0\mqx\examples\rs485. I also have a Modbus driver to port to the K60, and from looking at the example code it appears the RS485 single-pair setup can be done with ioctls.when the port is opened.
Thanks Fred, this was very helpful. I confess to having missed significant portions of source code when I did a quick MQX scan, and I of course did no builds to test. Upon further review, MQX looks very well written and seems to be nicely done. Not sure how I missed the stuff I was looking for, just in a hurry I guess.
Mark's package looks topnotch also.
Long term, (cross project, over many years looking forward) I prefer to work in C++ over C. I don't like programming on my hands and knees. For the time being, I like that path I am on because of these reasons:
c) cross vendor cortex M3/4 support
I am very strong in software, so I know what I want, and I know what foundations I need to build on top of.
It is nice to have a number of choices and references in this cortex m3/4 area. I like Freescale since I am just down the street and I would typically root for a U.S. company to do well anyway.
I am using microprocessor MK60N1M0VLQ12 and did some change in hardware for RS485 so that sending and receiving can happen at same time.
I also tested the rs485 example code on our target board.
Did you start to port the modbus driver?
As you probably know, the uTasker MODBUS extension module supports master and slave modes in ASCII, RTU on UARTs (as many as physically available) and over TCP (as many sockets as required). It also allows bridging and routing operations and can operate over the USB connection (in slave mode) of the Kinetis (as alternative to UART). A detailed user's guide is at
and overview at µTasker MODBUS Extension pack
The extension package can be dropped into the uTasker project (with OS, TCP/IP and all drivers required) to give an industrial-proven solution for the user to configure his/her own MODBUS based application on.
The extension module however uses various uTasker resources and will not work directly with other OS solutions unless the resources are replaced accordingly and support the requirements.
I am assuming that you are interested in the UART based connections (TCP stack parts would be more complicated to mix), whereby it may be possible to run the uTasker OS as a task in (for example) MQX. The uTasker project footprint is small (the complete MODBUS package with all functionality enabled requires about 14k Flash on a Coldfire - and the ARM is more code efficient so probably about 10k - see page 60/78 of the user's manual for typical memory requirements. The OS and driver resources needed by the Modbus will probably require 5k Flash or so (RAM requirements depend mainly on settings for buffer sizes etc.).
Specifically - the Modbus UARTs require HW timers to control the RTU timing (the Kinetis doesn't do this automatically as various ATMEL parts do - but no big deal) and master mode requires (OS supplied) SW timers to monitor MODBUS timeouts. The serial driver controls most details, whereby the Kinetis supports RTS control in RS485 mode automatically (nice feature in Kinetis). The UART tx direction is usually run in DMA mode but Rx runs in interrupt driven mode. Some configurations (brdiging etc.) use addition queue drivers to temporarily store routing queues.
Depending on your complete project requirements, you may also find the the uTasker project package contains all that you need without mixing the extension module - it allows development and simulation of large parts of (or complete) Kinetis projects using VisualStudio [the MODBUS extension operates in real-time on COM ports or TCP hooked to the simulated Kinetis], which can result in greatly increased development efficiency compared to embedded IDE methods.
I am thinking to do my MODBUS over TCP/IP project by using K60 MCU, we already have the Freescale CW licence.
Is the utasker tool free?
Retrieving data ...