Messages

76

µTasker general / Re: Port simulation

« on: June 20, 2010, 09:42:15 PM »

Great, The port simulation works well to set-up my hardware in a particular configuration.

Its a shame about the the Serial port problem, my application is a Modbus client and this causes the simulation file selection dialogue to fail as you described.

I did some investigation and found a couple of things that might help in finding what the problem is.

If run my simulation and talk to it via my Modbus master (i.e. use the serial port) then when I try to open a simulation file it locks up.

But if I run up my simulation, ensuring my Modbus master is not transmitting. Then I go to PortSim to select a file, but just hit the cancel button. Then I start my Modbus master. Now I can correctly select Port simulation files. So if you execute the file selection dialogue once before any serial comms occurs. It seems to work.

Also a couple of comments I add, for the benefits of others relating to simulating port bits, (Note I'm using the PORT designations for the LM3Sxxxx chips)

// You can put comment lines at the start of a line
+100 PORT-B-3 0   // this line sets port B bit 3 to 0  
+0 PORT-A 0c       // set all bits of port A to 0x0c  This line will execute directly after the line above because the time is +0
+0 PORT-B-1 1      // this line sets port B bit 1 to 1, with no delay from the line above again because of the +0 time delay

The default sim file to be run is stored in userfiles.ini which can be edited to allow other simulation files to be run. Note this file is only read on start-up of the simulator.

Just a thought, it might be worth adding an "autostart.sim" file that if it exists would run whenever a simulation was started to allow it to get into a default state.

Cheers

Martin

77

µTasker general / Re: How to use the UART to get data and send data!

« on: June 16, 2010, 08:31:59 AM »

Hi Kevin,

To remove the need for hardware serial ports take a look at com0com http://com0com.sourceforge.net/ which will create any number of virtual serial port pairs on your PC which are linked with a virtual null modem cable. For example I have the following pairs set-up on my computer

com100 <--> com110
com101 <--> com111
com102 <--> com112

All my utasker projects connect to Uart0 to Com100, Uart1 to Com101 ... etc I then connect my terminal applications or test programs, or other utasker projects (If I'm simulating to utasker boards talking to each other) to the other port i.e. com110, com111 ... etc.

Com0com is very easy to use and in my experience just works :-). Note when it installs it creates a serial port pair with the names CNCA1 and CNCB1 just use the configuration tool to rename these to Comxxx etc.

I use high com port numbers to ensure I don't clash with other bits of hardware / Usb adapters I use.

Note: if you use com ports creater than com9 you will need to define SIM_COM_EXTENDED in the hardware header file for the hardware I'm simulating this is app_hw_lm3sxxxx.h

You might want to look at these other posts
http://www.utasker.com/forum/index.php?topic=343.msg1447#msg1447
http://www.utasker.com/forum/index.php?topic=673.msg2922#msg2922
http://www.utasker.com/forum/index.php?topic=663.msg2856#msg2856

Cheers

Martin

78

NXP^TM LPC2XXX and LPC17XX / Re: USB for LPCXXXX

« on: June 15, 2010, 01:55:36 PM »

Hi Araon,

I've never done any USB development but I am aware of a driver stack built for the AVR called LUFA see http://www.fourwalledcubicle.com/LUFA.php I mentioned it before in this post http://www.utasker.com/forum/index.php?topic=880.msg3870#msg3870 I mention it again, incase you hadn't seen the other post. There seems to be a lot of support for devices and classes that exist on PC's like HID and joystick etc. You might be able to glean some info from the code.

Cheers

Martin

79

Luminary Micro ^TM LM3SXXXX / Re: Timer Based Operation of the ADC

« on: June 13, 2010, 05:54:11 PM »

Thanks for the heads up about the Errata, looks like there are some nasty gotcha's there

Regards

Martin

80

Luminary Micro ^TM LM3SXXXX / Timer Based Operation of the ADC

« on: June 12, 2010, 06:54:24 PM »

Hi Mark,

I want the ADC in my LM3S1968 based project to just run in the background continuously just reading the 8 ADC inputs. In fact in my application I'm just using the ADC inputs as another 8 logic input lines. I've setup a 1ms hardware timer that I'm using to sample some input lines (3 lines used to sample a 3phase mains supply so I can work out the mains sequence).

By a bit of trial and error I've got something that works in the simulator (I've no access to the hardware until Monday).

I couldn't find much info on ADC configuration on the forum or in the documentation so I'm posting here describing what I've done. So that it will be of help to other users and you can also tell me if I've done something wrong.

Firstly I setup the hardware Timer as shown below

Code: [Select]

unsigned long MSTimerTick = 0;

static void timer_int(void)
{
    MSTimerTick++;
    PhaseMap();
}

static void fnConfigure_Timer(void)
{
    static TIMER_INTERRUPT_SETUP timer_setup = {0};                      // interrupt configuration parameters

    timer_setup.timer_reference = 2;                                     // timer channel 2
    timer_setup.int_type = TIMER_INTERRUPT;
    timer_setup.int_priority = PRIORITY_TIMERS;
    timer_setup.int_handler = timer_int;                                // set to 0 for no handler
    timer_setup.timer_mode = (TIMER_TRIGGER_ADC | TIMER_PERIODIC | TIMER_MS_VALUE); // period timer
    timer_setup.timer_value = 1;                                        // ms delay
    fnConfigureInterrupt((void *)&timer_setup);                          // enter interrupt for timer test
}

Am I correct in using TIMER_TRIGGER_ADC in the timer_mode setting?

Next I set-up the ADC as shown below

Code: [Select]


static void fnConfigureADC(void)
{
    ADC_SETUP adc_setup;                                                 // interrupt configuration parameters
    adc_setup.int_type = ADC_INTERRUPT;                                  // identifier when configuring
    adc_setup.int_handler = 0;                                          // handling function
    adc_setup.int_priority = PRIORITY_ADC;                               // ADC interrupt priority
    adc_setup.int_adc_single_ended_inputs = (ADC_CHANNEL_0 | ADC_CHANNEL_1 | ADC_CHANNEL_2 | ADC_CHANNEL_3 | ADC_CHANNEL_4 | ADC_CHANNEL_5 | ADC_CHANNEL_6 | ADC_CHANNEL_7); // ADC channels 0..3 as single ended inputs
    adc_setup.int_adc_differential_inputs = 0; // No ADC channels as differential inputs
    adc_setup.int_adc_mode = (ADC_CONFIGURE_ADC | ADC_TRIGGER_TIMER);  // start under timer control
    adc_setup.int_adc_averaging = HW_AVERAGING_64;                       // basic sampling speed is 1MHz but can be averaged to improve accuracy or reduce speed
    adc_setup.int_adc_result = usADC_samples;                            // location to save the samples to
    adc_setup.int_sequence_count = ADC_SEQUENCES;
    fnConfigureInterrupt((void *)&adc_setup);                            // configure and start sequence
}

I presume this is the correct way to set the ADC mode?
 
adc_setup.int_adc_mode = (ADC_CONFIGURE_ADC | ADC_TRIGGER_TIMER);

Next it is all started off in my application startup with the following lines

        fnConfigureADC();                                                //
        fnConfigure_Timer();                                            // Hardware timer used for Phase detection and ADC trigger

As I say this seems to work in the Simulator I just wanted to ensure I was doing the right thing.

Cheers

Martin

81

µTasker general / Re: fnDebugMsg and debug.c

« on: June 11, 2010, 11:22:21 AM »

Hi Paul,

I'd asked Mark a similar question in a personal email, below is my original email and Marks reply. It might be of help to you.


Hi Mark,

I'm adding a telnet interface to my project, using debug.c as a starting point. This all works fine.

What I would also like to do is to add a debug interface, which would be on a different TCPIP port than the standard Telnet port. Currently If I start using fnDebugMsg it will mess up my Telnet interface.

My thoughts are as follows.

1. Create fnTelnetMsg, fnTelnetDec, fnTelnetHex which are similar to the fnDebug... equivalents but use the Tenet Port.

2. Create a #define in debug.c that changes fnDebug... to fnTelnet... It may be better to do a replace the string "fnDebug" with "fnTelnet" in the code but I want to have minimal changes in the code.

3. I've just looked at the definitions of fnDebugMsg and it prints to the Network Queue rather than the a queue associated with the Telnet Port, so It may be a bit more complex than I first thought.

4. What would you suggest would be the best way to create Telnet functionality on two separate TCPIP ports, one for a Telnet interface and one for a Debug interface? would I need to duplicate the telnet.c code or could I re-use it on multiple ports?

5. If another TCPIP port is not required for debug comms I would like to be able to #define fnDebug.. as fnTelnet.. so I would have the same functionality as currently exists (both functions outputting to the same port).

6. I guess my question really relates to how to setup multiple Telnet sessions on Multiple TCPIP ports.

Cheers

Martin


Hi Martin

If the second TCP connection is on a different port it is necessary to have a second socket handler. This can of course be very similar to the present one in debug.c.

To have multiple TELNET sessions on the same TCP port the same code can be used but needs to be adapter to support multiple sessions (like in HTTP), meaning that any local variables have to be changed to arrays so that each session has its own set.

 
Assuming that you have 2 TCP TELNET (or TELNET like) connections open I would try to use the existing fnNetworkTx() method.
 

// We support the network transmit routine here
//
extern QUEUE_TRANSFER fnNetworkTx(unsigned char *output_buffer, QUEUE_TRANSFER nr_of_bytes)
{
    return (fnSendBufTCP(Telnet_socket, output_buffer, nr_of_bytes, (TCP_BUF_SEND | TCP_BUF_SEND_REPORT_COPY)));
}


All debug type outputs will be sent here if the debug handle is a -1 (the default value).
But this is user code and can be modified to send to multiple outputs (for example), like UART, USB and Telnet, or multiple Telnet type sessions.

// We support the network transmit routine here
//
extern QUEUE_TRANSFER fnNetworkTx(unsigned char *output_buffer, QUEUE_TRANSFER nr_of_bytes)
{
    fnPrint(serial_handle, output_buffer, nr_of_bytes);               // send to serial output
    return (fnSendBufTCP(Telnet_socket, output_buffer, nr_of_bytes, (TCP_BUF_SEND | TCP_BUF_SEND_REPORT_COPY))); // and TELNET
}


Since all output will pass this way it may be easiest to put a case in it:

// We support the network transmit routine here
//
extern QUEUE_TRANSFER fnNetworkTx(unsigned char *output_buffer, QUEUE_TRANSFER nr_of_bytes)
{
    switch (DebugOutput) {
    case STANDARD_OUTPUT:
    return (fnSendBufTCP(Telnet_socket, output_buffer, nr_of_bytes, (TCP_BUF_SEND | TCP_BUF_SEND_REPORT_COPY)));
    case SECOND_OUTPUT:
    return (fnSendBufTCP(Second_Telnet_socket, output_buffer, nr_of_bytes, (TCP_BUF_SEND | TCP_BUF_SEND_REPORT_COPY)));
    }
}

 
The new global variable DebugOutput  can be used to select the output for individual messages.

DebugOutput = SECOND_OUTPUT;
fnDebugMsg(“Test”);
DebugOutput = STANDARD_OUTPUT;

Possibly a macro or cover function would help too. All output which is for the standard one doesn’t need to do anything special.

Regards

Mark

82

µTasker general / Re: Free 6LowPan stack on CC2530?

« on: June 09, 2010, 10:50:17 PM »

Hi Aleksandar,

The CC2530 is an 8051 derivative chip and there is currently no uTasker port for this chip family, and a port is something that would need a fair bit of work.

If you are not tied to this chip you could always look at the jennic chips http://www.jennic.com/ a number of application notes and a 16 bit chip with a free Eclipse based compiler. Still no uTasker port but lots of source on the Jennic site

Cheers

Martin

83

Luminary Micro ^TM LM3SXXXX / Re: Getting GCC to use uMemset instead of memset

« on: June 08, 2010, 10:33:14 PM »

Thanks Mark,

Sorry I should have been clearer, what you have suggested is what I'm doing. I was just wondering where GCC was trying to pick up memset and memcpy from.

Thinking about it obviously a #define would not work but a re-definition of memset and memcpy might, just was thinking defining constant arrays might be cleaner than manually filling them.

Cheers

Martin

84

Luminary Micro ^TM LM3SXXXX / Getting GCC to use uMemset instead of memset

« on: June 08, 2010, 06:40:09 PM »

Hi Mark,

I've come across the problem mentioned here http://www.utasker.com/forum/index.php?topic=249.msg1011#msg1011 where GCC is complaining about an undefined reference to in my case memset.

I was just wondering if it was possible to #define memset to uMemset and memcpy to uMemcpy somewhere to allow GCC to use the routines defined in uTasker, rather than looking in its own libraries

Its not a big problem but just a thought.

The line that caused my problem was

    unsigned char IIC_WrByte[18] = {0xc0, 0x20};            // {address, register, data x 16}

Cheers

Martin

85

MODBUS / Re: Changing the address of a Modbus Slave device

« on: June 06, 2010, 10:44:12 PM »

Thanks Mark,

I'm happy with living with the possibility that a slave reply might get lost, as I am also controlling the master and can handle retries etc myself.

Didn't get a chance to try switching from Master to Slave today, but its good to hear that there is a good chance that it will work. I'm only working with serial interfaces so TCP is not an issue for me.

Thanks for the reply I'll keep this topic updated with my results

Cheers

Martin

86

MODBUS / Re: Changing the address of a Modbus Slave device

« on: June 06, 2010, 02:00:51 PM »

Thanks Mark,

I was worried that changing the address might break something inside the Modbus Engine, but that's not the case :-). I'll also do some testing it might be that the Modbus module does takes its reply address from the transmitted message rather than from the ptrMODBUS_pars table (or can be modified to). This way the message that wrote a register changing the Modbus address would reply with its old address, before then changing the Modbus engine to use the new address.

UPDATE - I can confirm that the Modbus engine, does take its reply address from the transmitted message so, by putting a line of code  in fnMODBUSPostFunction I can safely update the Modbus slave address :-)

One other question, my transmitting device (Master) will normally be in Master mode all the time but I want to be able to switch it to slave mode so that I can do a firmware upgrade, from another Master device. It looks like when reading the Modbus Documentation that a Modbus port might be able to be configured as a Master and a Slave at the same time in the ptrMODBUS_pars table.

        (MODBUS_MODE_RTU | MODBUS_SERIAL_SLAVE | MODBUS_SERIAL_MASTER | MODBUS_RS485_POSITIVE),         // default to RTU mode as master - serial port 0

It could then respond to slave requests directed at it. Is this a correct assumption? Obviously if my device was in firmware upgrade mode it would stop master transmissions. Alternatively if Master and Slave mode are mutually exclusive I presume just changing the port mode in the parameter table would work.  

UPDATE - Initial tests seem to show that you cannot have Master and Slave modes enabled at the same time on the same port, enabling Master mode stops the port responding in slave mode

Another question is if the above were true, and I could have a port in both Master and Slave modes. Then if a slave transaction to my device was in progress and it then started a modbus master send using fnMODBUS_Master_send would this send be queued until after the Slave transmission had finished.

I know this is a bit of a weird way of using the module, but I was just after an idea of how it might react.

Cheers

Martin

87

MODBUS / Changing the address of a Modbus Slave device

« on: June 05, 2010, 03:10:16 PM »

Hi Mark,

I have a simple Modbus serial slave device that will have a Modbus address of 250 on start-up, a Modbus master will communicate with it at address 255 and then assign it another Modbus address that it should use until it is power cycled. (When it will return to using an address of 250).

The slave address is defined within the structure ptrMODBUS_pars and is used in the call fnInitialiseMODBUS_port which sets up a Modbus port.

What is the best way to cleanly change a devices address, note this need to happen after the device had replied to the modbus message that caused the change of address, from memory. fnMODBUSPostFunction is not the correct place to handle this as this is called before the reply is sent back.

I could use a gateway as in this post http://www.utasker.com/forum/index.php?topic=670.msg2882#msg2882 but I would like to make use of all the utasker routines to handle different messages, also my slave will only ever have one address its just that it will change.

Cheers

Martin 

 

88

µTasker general / Port simulation

« on: May 19, 2010, 08:32:34 PM »

Hi Mark,

Do you have any information on how the port sim feature works in the simulator, I've found this post in the forum http://www.utasker.com/forum/index.php?topic=738.msg3213#msg3213 but I'd like to know if there is any more info available. Specifically what script commands are supported and can this be used to simulate UART activity as well as GPIO. I'm using the LM3Sxxxx targets but I guess its pretty generic.

Cheers

Martin

89

Luminary Micro ^TM LM3SXXXX / Re: Flash Protection

« on: May 19, 2010, 09:17:32 AM »

The luminary Micro LM Flash Programmer will do this for you. Look under the "Other utilities" Tab at the "Debug Port Unlock" section. The following is from the help file.

Cheers

Martin

Debug Port Unlock Utility
The Debug Port Unlock utility allows the JTAG/SWD debug pins to be unlocked if you configure the pins as GPIOs or there is some other issue that causes the device to lock up, such as configuring to system clock out of specification.  This utility has some restrictions for the Sandstorm class of microcontrollers. There are three options for the Debug Port Unlock utility:

·         Sandstorm Class Revision C

·         Fury and DustDevil Classes

·         Tempest Class

Sandstorm Class Revision C
When you select this option, the SWD pins are used to communicate to the microcontroller and perform a mass erase of the internal flash. Since the SWD pins are used, the utility with this option does not work if pins PC0 or PC1 are configured as GPIOs.

Fury and DustDevil Classes
When you select this option, the utility unlocks the JTAG/SWD debug pins for all revisions of the Fury and DustDevil classes of microcontrollers by performing a mass erase of the internal flash using the JTAG/SWD recovery sequence.  This utility works regardless of which pins are configured as GPIOs.

Tempest Class
When you select this option, the utility unlocks the JTAG/SWD debug pins for all revisions of the Tempest classes of microcontrollers by performing a mass erase of the internal flash using the JTAG/SWD recovery sequence.  This utility works regardless of which pins are configured as GPIOs.

90

Luminary Micro ^TM LM3SXXXX / Re: Erase internal Flash

« on: May 11, 2010, 02:13:48 PM »

If you are talking about the simulator just delete the file "FLASH_LM3SXXXX.ini" and this will erase the simulators copy of the chips Flash memory.

Hope this helps

Martin