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

Pages: [1] 2 3
µTasker general / Tools that might be of interest to uTasker users
« on: October 25, 2018, 11:57:16 AM »
Below is a list of windows based tools that might be of interest to uTasker users, these are tools that I have used before

Virtual Serial Ports
Source files
Signed drivers
Run the setupc.exe program then type
"install portname=com10 portname=com11" to create a virtual com port pair linked together

Below is the help text from setupc.exe

Setup for com0com

  [options] <command>

  --output <file>              - file for output, default is console
  • <to>               - wait <to> seconds for install completion. If

                                 <to> has '+' prefix then ask user to continue
                                 waiting after <to> seconds elapsing
                                 (by default <to> is 0 - no wait)
  --detail-prms                - show detailed parameters
  --silent                     - suppress dialogs if possible
  --no-update                  - do not update driver while install command
                                 execution (the other install command w/o this
                                 option expected later)
  --no-update-fnames           - do not update friendly names
  --show-fnames                - show friendly names activity

  install <n> <prmsA> <prmsB>  - install a pair of linked ports with
   or                            identifiers CNCA<n> and CNCB<n>
  install <prmsA> <prmsB>        (by default <n> is the first not used number),
                                 set their parameters to <prmsA> and <prmsB>
  install                      - can be used to update driver after execution
                                 of install commands with --no-update option
  remove <n>                   - remove a pair of linked ports with
                                 identifiers CNCA<n> and CNCB<n>
  disable all                  - disable all ports in current hardware profile
  enable all                   - enable all ports in current hardware profile
  change <portid> <prms>       - set parameters <prms> for port with
                                 identifier <portid>
  list                         - for each port show its identifier and
  preinstall                   - preinstall driver
  update                       - update driver
  reload                       - reload driver
  uninstall                    - uninstall all ports and the driver
  infclean                     - clean old INF files
  busynames <pattern>          - show names that already in use and match the
                                 <pattern> (wildcards: '*' and '?')
  updatefnames                 - update friendly names
  listfnames                   - for each bus and port show its identifier and
                                 friendly name
  quit                         - quit
  help                         - print this help

Syntax of port parameters string:
  -                       - use driver's defaults for all parameters
  *                       - use current settings for all parameters
  <par>=<val>[,...]       - set value <val> for each parameter <par>

  PortName=<portname>     - set port name to <portname>
                            (port identifier by default)
  EmuBR={yes|no}          - enable/disable baud rate emulation in the direction
                            to the paired port (disabled by default)
  EmuOverrun={yes|no}     - enable/disable buffer overrun (disabled by default)
  EmuNoise=<n>            - probability in range 0-0.99999999 of error per
                            character frame in the direction to the paired port
                            (0 by default)
  AddRTTO=<n>             - add <n> milliseconds to the total time-out period
                            for read operations (0 by default)
  AddRITO=<n>             - add <n> milliseconds to the maximum time allowed to
                            elapse between the arrival of two characters for
                            read operations (0 by default)
  PlugInMode={yes|no}     - enable/disable plug-in mode, the plug-in mode port
                            is hidden and can't be open if the paired port is
                            not open (disabled by default)
  ExclusiveMode={yes|no}  - enable/disable exclusive mode, the exclusive mode
                            port is hidden if it is open (disabled by default)
  HiddenMode={yes|no}     - enable/disable hidden mode, the hidden mode port is
                            hidden as it is possible for port enumerators
                            (disabled by default)
  AllDataBits={yes|no}    - enable/disable all data bits transfer disregard
                            data bits setting (disabled by default)
  cts=[!]<p>              - wire CTS pin to <p> (rrts by default)
  dsr=[!]<p>              - wire DSR pin to <p> (rdtr by default)
  dcd=[!]<p>              - wire DCD pin to <p> (rdtr by default)
  ri=[!]<p>               - wire RI pin to <p> (!on by default)

The possible values of <p> above can be rrts, lrts, rdtr, ldtr, rout1, lout1,
rout2, lout2 (remote/local RTS/DTR/OUT1/OUT2), ropen, lopen (logical ON if
remote/local port is open) or on (logical ON). The exclamation sign (!) can be
used to invert the value.

Special values:
  -                       - use driver's default value
  *                       - use current setting

If parameter 'PortName=COM#' is used then the Ports class installer will be
invoked to set the real port name. The Ports class installer selects the COM
port number and sets the real port name to COM<n>, where <n> is the selected
port number. Thereafter use parameter RealPortName=COM<n> to change the real
port name.

  install - -
  install 5 * *
  remove 0
  install PortName=COM2 PortName=COM4
  install PortName=COM5,EmuBR=yes,EmuOverrun=yes -
  change CNCA0 EmuBR=yes,EmuOverrun=yes
  change CNCA0 PortName=-
  busynames COM?*

File Comparison

Standalone DHCP server for windows

CURL windows file transfer
(Useful for downloading files to utasker projects)

Hi Mark,

I know this part of the forum has not seen any updates in ages, and will be of interest to people supporting legacy product, as we are.

We have some old Luminary projects that we are transitioning from V1.7 to V3.5 of rowley, and I wanted to document the process for others, hence me asking questions in the forum.

In the Luminary uTasker library you have the following comments in a text file

1) Install the Texas Instruments Stellaris CPU Support Package.

Open the hzp file. To do this you can right click on the solution node in the project explorer and select "Edit Solution As Text".

2) replace all occurences of Luminary_LM3S with LM3S
This is because Rowley have changed the installation directory of the support package

3) remove c_user_include_directories="$(SamplesDir)/Luminary_Stellaris_Driver_Library" linker_additional_files="$(SamplesDir)/Luminary_Stellaris_Driver_Library/lib/libdriver.a"

4) Ensure that the correct target is selected in target properties - Crossworks 2.0 includes support for the newer Tempest devices, such as LM3S9B90

Can you please explain what line 2) achieves I know it works but I'm not sure why its removed and what replaces it

We have also found that an additional step is necessary, when we were compiling the project it was not linking correctly. I mentioned this to you Mark and that we were getting the following error messages.

I get the following error message
Code: [Select]
1> C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 3.5/gcc/arm-none-eabi/bin/ld: error: .vectors is too large to fit in FLASH memory segment
1> C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 3.5/gcc/arm-none-eabi/bin/ld: error: .init is too large to fit in FLASH memory segment
Build failed

You mentioned that these were due to ASSERTS in the utasker supplied loader files see the lines below, and I had to comment out these lines. I'm still not sure what the problem is here but at least its compiling and linking.

Code: [Select]
  . = ASSERT(__vectors_end__ >= __FLASH_segment_start__ && __vectors_end__ <= (__FLASH_segment_start__ + 0x00040000) , "error: .vectors is too large to fit in FLASH memory segment");

  . = ASSERT(__init_end__ >= __FLASH_segment_start__ && __init_end__ <= (__FLASH_segment_start__ + 0x00040000) , "error: .init is too large to fit in FLASH memory segment");

I'll update this post with other comments as I get the projects ported

µTasker general / Thought for a debugging interface "uProbe"
« on: June 19, 2012, 04:02:36 PM »
Just a thought about a feature to add to utasker, a debug probe that worked in a similar way to the following products


This could connect to the target using any of the following interfaces

serial Uart
SPI or I2c using an FTDI cable (
Comms channel over JTAG (This might be more difficult as it would require hooking into the compiler IDE)

This debug link could be the default way that debug information is reported from uTasker.

I have used a similar UDP only solution for the Rabbit processors, see this link for more details and source maybe the same UDP protocol could be used.

NXPTM M522XX, KINETIS and i.MX RT / Locking up a K60 tower board
« on: June 19, 2012, 03:01:31 PM »
Hi Mark,

We have just bought a couple of Tower systems with K60 processor boards, we were initially able to connect to the systems using Rowley crossworks and the built in OSJTAG port. After trying to flash uTasker we seem to have bricked both K60 processor boards. Neither can be detected by rowley any more.

I'm wondering if something in the setup has configured the cards to disable the JTAG ports?

Do you know if there is any recovery procedures available?

We have access to Rowley Crossworks and an eval copy of Keil with the uLink

Any help or thoughts gratefully recieved


MODBUS / Possible issue with multiple Modbus Masters
« on: December 01, 2011, 04:00:19 PM »
Hi Mark,

We are using the Modbus module V1.19 and have a situation where we have two independent Modbus masters communicating out via different Modbus ports.

If MasterA sends a request via Port1 (Uart0), then MasterB sends a request via Port2 (Uart1). The first reply received always goes to MasterA irrelevant of which Port it is received from. It seems like the Modbus engine can't cope with multiple masters transmitting at the same time, especially if replies are delayed.

Does the above make sense to you?



Hi Mark,

I'm currently looking at two OLED displays for a new project one uses a SSD1322 controller and the other uses a SSD1326 controller. I would probably interface either via SPI.

I am trying to build a definitive list of what is currently supported. Looking at the uTaskerLCD manual it covers

1. Text based displays using the HD44780 type chip

2. T6963C - Toshiba

2. KS0108B - Samsung

3. SSD1329 - used on Luminary OLED displays

4. NXP LPC2478 built in TFT controller

5. ??? - used on Atmel AVR32 EVK1105 board

6. ??? - Used on Nokia 6100 displays is this an Epson S1D15G00 or NXP PCF8833 (Leadis LDS176 is compatible with PCF8833) info about the Nokia6100 display was found here

Have I covered all the options above? I've created this list because I thought it would be helpful to see which chips were supported, as these are used on may different types of display. The underlying Chip type is the common factor.

I'm hoping the SSD1322 and SSD1326 are not too different from the SSD1329 that you already support. But its early days, not even sure if we are using OLED displays yet.

The displays we are looking at are wide and not very high 256 x 32 pixels, what I would like to do is put 2 displays side by side (512 x 32). To do this I would need 2 controller chips, would the logic of the uTasker display support a display made up of two controllers? To the main application it would look like one display space.



Hi Mark,

I'm looking at incorporating a micro SD card into a board revision. I've looked at the schematics for the Luminary Eval boards and

1. The LM3S6965 board has pullups on pins 1 and 8 (which are DAT2 and DAT1) this makes sense as they are unused in SPI mode
2. Also the Micro SD card on the IDM_L35_RDK kit has a pull-up on the /CS line
3. You say in this post that you also needed to ad a pull up to the MISO line.

So in all I need 4 pull ups does that make sense to you?



Hi Mark,

I want to change the "period" of a task depending on particular conditions. This period is defined in ctTaskTable and as its defined as a Const it can't be changed. Is there a simple way to achieve this.

I could remove the "const" definition of ctTaskTable which would mean it would then reside in RAM, entries could then be modified. Would this be your suggested way of doing this.

I suppose the Task state could also start a monstable timer for my new period and change the task state to UTASKER_SUSPENDED. But this does seem a bit clumsy.



Hi Mark,

Due to my ongoing problems with the I2C interface in these chips I have decided to use the SSI interface on my next board, I'm stuck with the luminary chips at the moment as I've no time to change.

I notice that you don't use a driver interface as such to the SSI port in uTasker, would you suggest that I just modify the functions in the spi_sc16IS7xx.h file you sent me to provide SPI access to the second SSI port on this chip.



Luminary Micro TM LM3SXXXX / Using the second IIC interface
« on: October 19, 2010, 06:22:20 PM »
Hi Mark,

We need to use the second IIC interface on a LM3S1968 chip, as well as the first. Is this as simple as changing the channel number in the configuration routine, and generating a new handle using fnOpen?

static void fnConfigIIC_Interface(void)
    IICTABLE tIICParameters;

    tIICParameters.usSpeed = 400;                                        // 400k
    tIICParameters.Rx_tx_sizes.TxQueueSize = 256;                         // transmit queue size
    tIICParameters.Rx_tx_sizes.RxQueueSize = 256;                         // receive queue size
    tIICParameters.Task_to_wake = OWN_TASK;                                     // no wake on transmission
    tIICParameters.Channel = 0;
    IICPortID = fnOpen( TYPE_IIC, FOR_I_O, &tIICParameters); // open the channel with defined configurations

Will the simulator support two IIC networks, or will the same simulator code be called for both ports?



µTasker general / Responding to multiple IP addresses
« on: October 12, 2010, 10:35:04 AM »
Hi Mark,

I am thinking of using the uTasker simulator to help me build an application that will simulate a number of modbus TCPIP slaves, on one ethernet connection. I need to support about 30 modbus slaves. To do this I need to modify the stack to repond to multiple IP addresses, this could easily be done on a block basis so utasker would respond to any IP in the range to for instance.

How difficult would this be to do? I'm envisioning this just being a simulator project it would never run on real hardware.

I could just run 30 instances of an application all configured to run with different IP addresses but this seems a bit heavy.

I found this post which gives me some clues,  I think I need to do the following things

1. Handle ARP requests from external devices for any IP in the range, I presume it would be ok to respond with the same MAC address

2. If a UDP or TCP request came through for an IP request in the range then respond to it, accordingly. I.e. respond to a Ping or Http request etc. In most cases I don't care that the uTasker simulator will not know to which IP destination address the request was directed, just that it replies to the request from the same IP address. Thinking about it I may have to duplicate the structures for each IP address as different IP addresses may be in different states

3. In the case of ModbusTCP I will want the higher level application to Know which IP address the request was sent to as I will want to respond with different information. The Modbus stack can already handle multiple TCPIP connections on different ports, its just a case of extending this mechanism to support multiple IP addresses.

Is it worth me trying to do this or is uTasker quite tightly tied into working with single IP addresses?




Luminary Micro TM LM3SXXXX / uTbot
« on: October 06, 2010, 09:50:00 AM »
Now there is an interesting bit of hardware

Shame I missed out on the offer



MODBUS / What are the Hardware Timer Requirements for the Modbus Module
« on: August 18, 2010, 05:33:16 PM »
Hi Mark,

What are the Hardware timer requirements for the Modbus module? I'm using Luminary Micro LM3S1968 chips with Modus RTU half duplex RS485 running at 115200 baud.

I think I've pretty much answered my own question, I've just found the section on Hardware timers in the modbus manual

I need to support 4 x Modbus serial channels, 3 using the the LM3S1968 built-in UARTS and one using an external SPI uart, probably the SC16IS7xx mentioned here

From my reading of the Modbus source code each Modbus serial channel requires a hardware timer, for RTS timing? The chip contains 4 x Timers with one I presume being used for the timer tick, so theoretically I have 3 timers left which should be enough. Is my understanding correct. The SC16IS7xx as you know handles RTS control automatically. It maybe that I still need timers 4 timers as I need 1.5 and 3.5 character timers for all 4 channels.

I was also wondering if it was possible to do everything with just one hardware timer, that could be set to just interrupt for the shortest period required? It would make the timer interupt handler more complex but more flexible



µTasker general / How to use NUMBER_EXTERNAL_SERIAL
« on: August 16, 2010, 03:28:21 PM »
Hi Mark,

I have an application where I need more Uarts that are on my chip, I'm using an LM3S1968 processor which has 3 Uarts and I need 4.

I notice that you may have dealt with this same problem youself because the Simulator has the define NUMBER_EXTERNAL_SERIAL which seems to allow the simulator to handle another 4 Com channels. I notice that these is no target code presumably because there are many ways of adding extra Uarts.

I have two options,

1. To bitbang a UART using GPIO and a couple of timers, possibly basing code on AN01270-01 from

2. To use an external SPI or IIC uart like the MAX3107

Which ever solution I use I want to hook in to uTasker so the application interface is the same, I presume I would need to do the following.

1. Extend fnConfigSCI to handle configuring my extra Uarts
2. Handle filling up RX buffers from my own, interupt routines.
3. Handle emptying TX buffers, and transmitting characters.

Am I correct im my assumptions and do you have any pointers?



Luminary Micro TM LM3SXXXX / Code hitting irq_hard_fault(void)
« on: August 05, 2010, 06:07:07 PM »
Hi Mark,

Just after a bit of advice, I'm using Rowley crossworks V1.7b22 and have an application, that seems to have problems running with the JTAG.

If I build the code as "Bare minimum bootloader" it works fine with the bootloader.
If I build it using the Rowley command "Build and Debug" in either "THUMB Flash Debug" or "THUMB Flash Release" modes it hits irq_hard_fault and thats it.
If I build it using the Rowley command "Build and Run" it builds but does not run (maybe it locks up as above) but if you press the reset switch it runs.

I can get arround this by building then resetting the board then attaching the debugger, but this operation is different to all the other projects I've created.

When I hit the irq_hard_fault loop the call stack does not show anything helpful, just irq_hard_fault.

Any pointers that might help me?



Pages: [1] 2 3