UART / Serial and the simulator problem

[ZeroOne]

Hi

I have a problem with the UART/serial interface and the simulator.

I have the forlowing code in a file called MyUart.c:

Code: [Select]

//includes
#include "config.h"

//Prototypes
void setUart(unsigned char mode);

// Global variables
static QUEUE_HANDLE SerialPortID; // quehandler for serialport 0

//call functions
void fnSerialTest(TTASKTABLE *ptrTaskTable)         // my task task in polling mode (at the moment)
{
static int iState = 0;

        if (iState== 0)
{   
setUart(FOR_I_O); //Rx & Tx
iState = 1;
        }
fnWrite(SerialPortID, (unsigned char *)"Hello world", uStrlen("Hello world"));
}

void setUart(unsigned char mode)
{
TTYTABLE tInterfaceParameters;       //table for passing information to driver

tInterfaceParameters.Channel = 0;  // serial 0, 1, 2, 3, 4, etc.
  tInterfaceParameters.ucSpeed =  SERIAL_BAUD_19200; // baud rate
  tInterfaceParameters.Rx_tx_sizes.RxQueueSize = RX_BUFFER_SIZE;       // input buffer size
tInterfaceParameters.Rx_tx_sizes.TxQueueSize = TX_BUFFER_SIZE; // outpu buffer size
    tInterfaceParameters.Task_to_wake = TASK_MYUART;
tInterfaceParameters.usConfig = (CHAR_8 | NO_PARITY | ONE_STOP | NO_HANDSHAKE | CHAR_MODE);    

if ( (SerialPortID = fnOpen(TYPE_TTY, mode, &tInterfaceParameters)) != 0 )  // open or change the channel with defined configurations (initially inactive)
fnDriver( SerialPortID, (RX_ON | TX_ON), 0 );        // enable RX & TX

}

In TaskConfig.h I have the forlowing entrys:

Code: [Select]

#define TASK_MYUART 'u'
...
extern void fnSerialTest(TTASKTABLE *ptrTaskTable);
...
TASK_MYUART,   //ctNodes
...
{ "uart", fnSerialTest,    NO_QUE,      0, 0, UTASKER_GO}, //ctTaskTable

and in app_hw_m5223x.h:

Code: [Select]

#define SERIAL_PORT_0   '1'
This is correct since I use channel zero and com1 for communication.

The problem is that nothing is written to com1 using the simulator.

When i debug in MyUart.c at:

Code: [Select]

if ( (SerialPortID = fnOpen(TYPE_TTY, mode, &tInterfaceParameters)) != 0 )
fnOpen() doesn't return to this line. Instad it returns to

Code: [Select]

if ((SerialPortID = fnOpen( TYPE_TTY, ucDriverMode, &tInterfaceParameters )) != 0)
in application.c.

I am using uTasker sp6.

ZeroOne

[mark]

Hi ZeroOne

Very strange - I don't understand how a function can be called from one place and return to another. Are you sure you are not using a break point in the function to stop it and finding that it is being called from somewhere else? Are you also sure that your task is being scheduled? (breakpoint at beginning of task)

I would make 2 changes and then try it again:

1. Remove the serial code from application.c so ensure that the port s not being opened twice (set #undef USER_SERIAL at the beginning of the file - after #include config.h).

2. Put the write in the initialisation (otherwise it will be called at the polling rate and send continues data) - or switch the task's characteristics to UTASKER_ACTIVATE so that it runs just one for the moment.

If you don't get further, send me your new files and any modified files so that I can check it out in more detail in my project environment.

Regards

Mark

[ZeroOne]

Hi again

It seems to work and I have no idea why! I haven't changed anything, so my best bet is that windows didn't do what is was supposed to do.

Anyway thank you

ZeroOne

[ZeroOne]

Hi

Just a note. I figured out what the problem was:
Turns out hyperterminal didn't close down properly. It was running in the background keeping com1 open.  . (Had to close it under proceses using ctrl+alt+del)

Sorry for the inconvience.

ZeroOne

[mark]

Hi

No problem. There is however a point worth noting.

When using the UARTs with the simulator, the simulator will try to open any mapped COM ports but it will only do so if the port really exists and is free.

If a COM port doesn't exist (or the USB COM interface has been removed) or if another application is already using it, the uTasker simulator will accept it and otherwise continue running normally (without the port mapping actually in operation). It doesn't make a fuss about it because this would probably be more annoying then convenient when it just happens that a UART is mapped to a COM port but it is not actually of any interest to the user. If it were to always flag an error it would probably make the user go mad with time.

The down side is that you need to check that all is set up and the resources are really available. If you are actively working with the UART it will normally be quite easy to check this and correct it if necessary (especially after it has caught you out once...).

Regards

Mark