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 [4] 5 6 ... 12
46
µTasker general / Re: How to use NUMBER_EXTERNAL_SERIAL
« on: October 27, 2010, 07:47:38 AM »
Hi Peter,

Couple of recommendations, I'm using the SC16IS750, and communicating using MODBUS RTU at 115200 baud. (Mark may have already included these changes)

1) Run the SPI as fast as you can, 4Mbs for SC16IS750 15mbs for SC16IS760.

2) Disbale the FIFO's in the UART as this messed up the timing and detection of the Modbus RTU end of massage gap. (3.5 message periods)

Good Luck

Martin

47
MODBUS / Re: MODBUS simulation/testing on PC
« on: October 27, 2010, 07:42:45 AM »
Does this mean you also have Modbus Constructor? I use the mbaxp.ocx control from here http://www.modbustools.com/modbus_activex.asp and have made my own tools in VB6.

For a free tool I use http://omniflow.com/Products/SoftwareDownloads/ModbusTester_install_v2.11.zip

Cheers

Martin

48
NXPTM LPC2XXX and LPC17XX / Re: LPC1768 flash programming software for Linux
« on: October 25, 2010, 02:02:48 PM »
See the LPC ISP project here

http://tech.groups.yahoo.com/group/lpc21isp/
http://lpc21isp.sourceforge.net/

This may help you

Cheers

Martin

49
Luminary Micro TM LM3SXXXX / Re: Using the second IIC interface
« on: October 24, 2010, 06:18:23 PM »
That was my plan too Mark, to create arrays.

I'd just forgotten that the IIC simulator currently only worked for one channel so it was causing problems when I was using two.

When you say "chip selects" do you mean the chip selects of the IIC chips

50
Luminary Micro TM LM3SXXXX / Re: Using the second IIC interface
« on: October 22, 2010, 04:39:25 PM »
After some investigation I've realised that the simulator does not support more than one IIC interface in its current setup. In fact it can cause weird problems as different busses trample over each other.

A quick look, and I think I should be able to pass the "Channel" to fnSimIIC_devices and then use this to differentiate different busses. I'll look at this in more detail later. I just wanted to post here to ensure that other people were aware of this limitation.

What I've done is to change all calls to fnSimIIC_devices to pass the channel.

unsigned char fnSimIIC_devices(QUEUE_HANDLE Channel, unsigned char ucType, unsigned char ucData)

Then I've added the line
    if(Channel) return 0;
As the first line in  fnSimIIC_devices, so that processing is aborted for any other channel than channel 0. This seems to work as a quick fix.

unsigned char fnSimIIC_devices(QUEUE_HANDLE Channel, unsigned char ucType, unsigned char ucData)
{
    if(Channel) return 0;

51
NXPTM M522XX, KINETIS and i.MX RT / Re: Simulator and SD card
« on: October 22, 2010, 01:02:08 PM »
Although I've not used it before I believe you can use ufat and the SD card in the simulator.

I did a quick search of the forum and found

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

Martin

52
µTasker general / Re: I2C in slave mode
« on: October 20, 2010, 01:44:25 PM »
Hi Steen,

Yes we have been working with Mark to provide a SC16IS7xx driver for the LM3Sxxxx chips, its pretty generic. So should be portable to the M5225X. We use the SPI interface to communicate to the SC16IS760 chip in our case (we only needed on extra UART). I'm running Modbus RTU at 115200 baud through a SC16IS760, I'm also using the nice auto gating feature of the SC16IS760 to turn the RS485 half duplex driver on and off.

Best to talk to Mark about porting the driver to the M5225X, should be just the SPI routines I would think. May require more work if you wanted to interface to this chip via I2C.

Cheers

Martin

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

Regards

Martin

54
µTasker general / Re: I2C in slave mode
« on: October 15, 2010, 11:32:57 AM »
Hi Steen,

We use I2C to access (in Master mode) quite a lot, and generally it has proved a good interface. We primarily use the Luminary Micro LM3Sxxxx range of chips.

We have found that under harsh conditions (external EMI) you can get into "lock-up" conditions on the bus where the SDA line is being held low by the external slave device (Clock extension). Currently we have switch the GPIO lines assigned to the I2C to GPIO mode and manually clock the SCL line to get out of this mode. This may be a limitation with the LM3S chips.

Of course EMI might not be an issue for you.

Have you thought of connecting an external UART(s) via the SPI or I2C interfaces, I understand this works well in uTasker. In fact we are working on a project where a philips SC16IS750 uart will be interfaced with our chip via SPI. These chips are quite good as you can get single and dual versions. Maxim also do a slightly different version that does not need an external baudrate crystal.

I'm a bit cunfused by your point (2) if you want to connect an external IO expansion board then you need to run uTasker in I2C master mode, which it already supports.

Regards

Martin
 

55
µTasker general / Re: two IPs
« on: October 12, 2010, 10:35:47 AM »
Hi Carlos,

Did you every get anywhere with this?

Regards

Martin

56
µ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 192.168.1.1 to 192.168.1.32 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 http://www.utasker.com/forum/index.php?topic=261.0 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?

Cheers

Martin

 

57
Luminary Micro TM LM3SXXXX / uTbot
« on: October 06, 2010, 09:50:00 AM »
Now there is an interesting bit of hardware http://www.luminarymicro.com/products/stellaris_evalbot.html

Shame I missed out on the offer http://hackaday.com/2010/10/04/125-off-the-evalbot-is-a-steal/

Cheers

Martin


58
Luminary Micro TM LM3SXXXX / Re: Responding to TI's Finder utility
« on: September 30, 2010, 04:51:43 PM »
Hi Peter, And anyone else who might be interested.

I quickly knocked up the code to do this for you. The code's rough and I've kept it as similar to the TI example as possible. I've tested it in the simulator and it works.

Just make the following changes to application.c

1. Ensure that  #define DEMO_UDP is uncommented about line 110

2. Change the definition of  MY_UDP_PORT  to 23 about line 214

3. If necessary change your default MAC address and IP address about line 307

4. Replace the function fnUDPListner with the new version in the attached file.

Cheers

Martin
 

59
µTasker general / Re: handle tcp data until a task is ready
« on: August 31, 2010, 06:55:38 PM »
Is it worth making the define something like ETHERNET_PROCESS_EVERY_FRAME and then doing

#ifndef ETHERNET_PROCESS_EVERY_FRAME                                // {6}
                uTaskerStateChange(OWN_TASK, UTASKER_ACTIVATE);          // schedule the task to check the input once more after allowing other tasks to run
                return;                                                  // quit for the moment
#endif

Then the change is added by default and you don't need to modify config.h

Regards

Martin

60
µTasker general / Re: handle tcp data until a task is ready
« on: August 31, 2010, 12:39:16 PM »
Hi Mark,

Just processing one reception Frame seems like a sensible addition to the stack, is this something that you are building into the stack as standard?

Are there any issues you can see with leaving ETHERNET_RELEASE_AFTER_EVERY_FRAME defined by default?

Cheers

Martin

Pages: 1 2 3 [4] 5 6 ... 12