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.


Messages - mhoneywill

Pages: [1] 2 3 ... 12
1
µTasker general / Re: Tools that might be of interest to uTasker users
« on: September 01, 2019, 06:26:46 PM »
Com0Com signed drivers for Windows10 can be downloaded here
https://code.google.com/archive/p/powersdr-iq/downloads

2
FYI was just re-reading this topic and realised old source was long gone but look here http://dunkels.com/adam/uvnc/

Source on Git hub https://github.com/contiki-os/contiki/releases

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 http://com0com.sourceforge.net/
Signed drivers https://sourceforge.net/projects/signed-drivers/files/com0com/v3.0/com0com-3.0.0.0-i386-and-x64-signed.zip/download
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

Usage:
  [options] <command>

Options:
  --output <file>              - file for output, default is console
  --wait
  • <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

Commands:
  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
                                 parameters
  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>

Parameters:
  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.

Examples:
  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=-
  list
  uninstall
  busynames COM?*


File Comparison
https://www.scootersoftware.com/

Standalone DHCP server for windows
http://www.dhcpserver.de/cms/

CURL windows file transfer
(Useful for downloading files to utasker projects)
https://curl.haxx.se/

4
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


5
µTasker general / Re: Simulating custom peripherals?
« on: October 21, 2013, 08:45:36 AM »
Just to let people know a signed version of the COM0COM V3.0 driver is avaliable here https://code.google.com/p/powersdr-iq/downloads/detail?name=setup_com0com_W7_x64_signed.exe&can=2&q=

Regards

Martin Honeywill

6
NXPTM M522XX, KINETIS and i.MX RT / Re: Locking up a K60 tower board
« on: June 21, 2012, 02:38:19 PM »
Yep I've got a REV D pcb with this unfortunate wiring issue, I think it would be a good idea to mention this in your PDF starters guide as I can imagine it catching a few people out, especially presuming new boards will all be RevD.

We either left the SD card in with its WP link set (And disabled WP detect code in uTasker) or put a piece of paper between the switch contacts (bit fiddly)

On another tack we're just tweaking the FTP server to work natively with windows explorer (In windows 7 at the moment, but will also test in XP), we'll post the code mods when we've finished.

Cheers

7
NXPTM M522XX, KINETIS and i.MX RT / Re: Locking up a K60 tower board
« on: June 20, 2012, 03:45:58 PM »
Have found the problem, The SDCARD WP pin is tied to PTB1 which is in turn tied to the RSTOUT line on the primary tower connector. This is in turn connected to the RESET line of the Ethernet chip.

What this means is that to use the SD card you have to either disconnect the WP switch (Best option), or set the WP switch so that the RSTOUT line is not pulled low when an SD card is present.
The best solution is to remove isolate the switch, as it will be operated as the SD card is inserted. Maybe this is a change with my revision of processor card, but its a real gotchya that should be mentioned somewhere

8
NXPTM M522XX, KINETIS and i.MX RT / Re: Locking up a K60 tower board
« on: June 20, 2012, 02:00:25 PM »
Hi Mark,

Yes the Rowley upgrade to the OSJTAG does work faster, Its nice to know it will still work with other Tools too (thanks for that info). Is it any faster with the other tools in your experience?

The next weird thing I'm struggling with is whenever I plug in an SD card, I loose Ethernet connectivity, I've narrowed it down to the SDCARD WPswitch which goes into the processor pin PE27.

Even if I hold the processor in a reset state by pressing the reset switch, if I operate the SDCARD detect switch the ethernet lights will go out on the jack. All very weird unless there is a short on the PCB. The circuit diagrams show no connection to PE28 on the Ethernet board.

I've even tried downloading the binary image avaliable from the uTasker website http://www.utasker.com/Demos/Kinetis/uTaskerSerialBoot_V1.01.zip and still as soon as the SD card is plugged in the Ethernet lights go out. This fault occurs on both of our Kinesys K60 tower systems.

The joy's of working with a new chip / dev board

Cheers

Martin

9
NXPTM M522XX, KINETIS and i.MX RT / Re: Locking up a K60 tower board
« on: June 19, 2012, 05:06:28 PM »
Hi Mark,

Thanks for the quick reply, after a lot of googling we managed to find a way to wipe the flash in the chip using the Demo version of the Keil compiler and the Keil uLink Jtag (needed some settings changing first though).

I have also been told by Rowley that you can do it through their tools as follows

You need to load the target script file into the script console.
>load("targets/Kinetis/Kinetis_Target.js")
>MassErase()
You'll need to updated OSJTAG to do this.
Regards
Michael


--- Additional comment from Rowley as yet untested
Clear the target property "Identify On Connect" - remember to enable it after that MassErase()

You will also need to have the Rowley specific OSJTAG firmware loaded too for this to work


Whilst delving into the Rowley documentation for the Kinetis CPU support package I came across a reference to updated firmware for the OSJTAG programmer see below

The package contains an update to the firmware that can be loaded on to the OSJTAG hardware of the TWR CPU modules. The updated firmware improves the download and debug performance of the CrossWorks 'Kinetis OSJTAG' target interface. You'll need to use the firmware update procedure available from PE micro and point the updater program at the supplied file osbdm-jm60_kinetis_rowley_101_0.s19. You can click on the above link to get a copy of the firmware into the editor and then right click on the editor tab and select 'Copy Full Path' to get the path to the filename of the firmware into the paste buffer.

Will update this posting with more info on Rowley when I get it

10
µ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

Freemaster http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FREEMASTER
uC/Probe http://micrium.com/page/products/tools/probe

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

serial Uart
UDP
SPI or I2c using an FTDI cable (http://www.ftdichip.com/Products/Cables/USBMPSSE.htm)
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 http://shdesigns.org/rabbit/udpdebug.shtml maybe the same UDP protocol could be used.

11
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

Martin

12
µTasker general / Re: Simulating custom peripherals?
« on: December 13, 2011, 11:37:29 AM »
I Just thought I'd let people know that there is a Signed 64bit version of Com0Com available for those of you running windows7(64bit)

See http://sourceforge.net/projects/com0com/files/com0com/2.2.2.0/

Cheers

Martin

13
MODBUS / Re: Possible issue with multiple Modbus Masters
« on: December 01, 2011, 05:03:57 PM »
Hi Mark,

We are indeed using RTU and I will investigate the issue in more detail to find more information. Thanks as always for the quick response

Cheers

Martin

14
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?

Cheers

Martin 

15
STTM STM32 and STR91XF / Re: STM32 F4 Cortex M4 devices
« on: November 16, 2011, 07:08:20 PM »
Hi Mark,

These STM F407 devices look very interesting, 6 x Uart with RS485 support (At least an interrupt that tells you when the transmit buffer is empty), USB Device, Ethernet.

The Eval board looks a good price to £10ish from Farnell

One question you might know the answer to mark as you have been looking at these chips in detail. The timer/conters seem to support a quadrature encoders as far as I can tell you can read up to 6 quadrature encoders on TMR1,2,3,4,5,8 do you think that is correct? Shame as we wanted to read 8 encoders.

These chips look as good as the Kinetis K60

Cheers

Martin

Pages: [1] 2 3 ... 12