Author Topic: Newbie's firsttime with uTasker  (Read 55383 times)

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Newbie's firsttime with uTasker
« on: February 26, 2009, 08:34:30 PM »
Having a hard time with this uTasker and stripping out the unwanted demo apps.

What I'm trying to accomplish is seperating all serial and ethernet code from application.c to there own files such as serial.c and network.c and then bridge them together so data that comes in from uart1 goes out via ethernet to a server app running on my pc then takes the data from the server app in via ethernet and echo's it back out via uart1.

Sounds simple but so far it's becoming rather problematic.

Any idea's or already done source code for me to work with would be appreciated....

Thanks.
« Last Edit: February 26, 2009, 08:38:09 PM by echel0n »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #1 on: February 26, 2009, 09:36:58 PM »
Hi

The uTasker project is a demo project which contains pretty much everything required as base for most general projects. It is however still just an example and in some cases it may be required to start with a fresh sheet. In this case it is advisable to add a fresh project and start there rather than weeding out the bits from the demo which are not required. How to start a fresh project is explained in http://www.utasker.com/docs/uTasker/uTaskerV1.3_user_guide.PDF (from page 2) and you may like to take this root.

What you want to do is make an Ethernet<->RS232 converter. This is not included as part of the demo project. The main reason was due to the fact that it is not as simple as it first seems and there would be a risk of the uTasker project migrating to an Ethernet<->RS232 project rather than remaining a general tool.

The following shows an example of a product which was realised using the uTasker: http://www.xmodus.ch/sm_lan.html

In fact the difficulty is not in the basic operation, such as transferring Ethernet received frames to UART and the reverse - this is very easy. But, the complications start when flow control is considered. That is, what to do when the remote side's UART is blocked due to flow control (assuming UART - but other interfaces or internal processing can lead to the same effect)? This then causes the remote side to have to store the received data until its buffers fill. Then this progresses through the TCP/IP part (windowing) back to the local part, so the flow control finally works its way back to the local UART too, which can't clear input data since the remote TCP socket has closed its window.

All of the support to do this is however present in the package but it does require a bit more work than originally expected before it all works correctly under all circumstances. In fact the result can however still be very efficient, using very small amounts of memory (FLASH and SRAM). The 32k SRAM based SAM7X128 used in the example managed to achieve better file transfer throughput than another product on the market based on an ARM9 with 16Meg SDRAM...

So how to start?

Well I would in fact first stay with the demo project - at least for the first steps - and do a quick tests as follows:

1) Establish a TELNET connection (since the Telnet socket type is the one to use) - ensure USE_TELNET is enabled in the demo project.

2) In application.c add the following line (ensure SERIAL_INTERFACE is enabled):
...
        while ((Length = fnRead( SerialPortID, ucInputMessage, MEDIUM_MESSAGE)) != 0) {
            fnWrite(NETWORK_HANDLE, ucInputMessage, Length); // <--- send all UART input to TCP (TELNET connection)
...


This will already achieve UART -> Ethernet

3) In fnTELNETListener() in debug.c add the following line
...
    case TCP_EVENT_DATA:
        fnWrite(SerialPortID, ucIp_Data, usPortLen); // <----- send all TCP/IP input to the UART
...


This will then achieve Ethernet -> UART

However, as mentioned earlier, there is quite a lot involved to make this into a complete project for a real product. But once the data starts flowing it does make it more fun to work on;-)

Good luck.

Regards

Mark


Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #2 on: February 26, 2009, 10:56:45 PM »
This project will not require any sort of flow control, just rx and tx.
Data comes into arm7 from another device and then I process the data and depending on what it is I either send it out via ethernet or send it back out via uart1.

Also the data that comes into the arm7 via uart1 is formated in such a way that I can tell exactly how many bytes I'm to expect so I can do a forever loop till X number of bytes arrive and then exit the loop and continue with processing.

Anyways you've shed some light on what I was wondering about.

Now my next question is:
Do I even need application.c file at all ?
Do I need fnApplication function ?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #3 on: February 26, 2009, 11:30:45 PM »
Hi

Basically you don't need any of the files in the utaskerV1.3 application directory. However it is handy to have the application task (application.c) even if stripped out since it is coordinating the start up of most of the system:

1) It is reading user parameters (and also subroutines controlling the reading of the network parameters for the Ethernet task). See uParameterSystem details in http://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF

2) It is starting some other tasks, like the debug task which is configuring Telnet.

3) It is starting HTTP and FTP servers.

4) It is configuring ports.

5) It is configuring the UART and it is also handling UART reception.

Since you will be using the UART, whos configuration is also a user parameter from the parameter block in FLASH, you may like to keep this part. You can simply add your reception in the read loop:
while ((Length = fnRead( SerialPortID, ucInputMessage, MEDIUM_MESSAGE)) != 0) {
....
}


See the following for using the serial interface(s): http://www.utasker.com/forum/index.php?topic=54.msg220#msg220


Generally the application (every project will have a central management part which could be designated the "application") will be realised as a task similar to the one in application.c. Other tasks can perform more dedicated jobs to keep everything modular. Depending on the project itself, the application can be a high level overviewing function or it may also do lots of nitty-gritty work (too). Therefore I would suggest keeping this file/task because it helps coordinate a project centrally.


Regards

Mark



Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #4 on: February 26, 2009, 11:45:07 PM »
Then I suppose what I'll do then is move serial into serial.c and ethernet into network.c and strip that code away from application.c but leave anything that would be used to say initiate those 2

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #5 on: February 27, 2009, 01:03:33 AM »
Any reason why I can't set hardware breakpoints in crossworks with this ?
I go set a breakpoint but after I build + debug it puts a question mark in the breakpoint saying no code present ????

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #6 on: February 27, 2009, 01:18:25 AM »
Hi

I think that you are using the LPC23XX. Generally this works well with Crossworks - just check that you have chosen a target with debug information (not a release one).

Also it is advisable to disable the watchdog (it is enabled in the uTasker project by default) since the watchdog can cause big problems when debugging. See http://www.utasker.com/forum/index.php?topic=521.msg2223#msg2223
Note that, if the watchdog has been enabled, only a power down cycle will disable it - so even after building with no watchdog (or using the input disable method) don't forget to cycle the power to really stop it.

Regards

Mark

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #7 on: February 27, 2009, 01:27:41 AM »
Where would I define this WATCHDOG_DISABLE ???

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #8 on: February 27, 2009, 01:40:57 AM »
Hi

See the link http://www.utasker.com/forum/index.php?topic=521.msg2223#msg2223
WATCHDOG_DISABLE() is in app_hw_lpc23xx.h
Set it to
WATCHDOG_DISABLE() 1
to completely disable it.

Or else by pull the defined port input to '0' to disable it during a debug session.
The exact input depends on the board being used. I think that you use the Olimex (#define OLIMEX_LPC2378_STK should be set in config.h) and this means that it is port0 bit 18 (Button 2). You can keep the button pressed when the board starts and then the watchdog will not be enabled.

Regards

Mark

PS Signing off for tonight. Good luck...

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #9 on: February 27, 2009, 01:50:44 AM »
Ok that didn't resolve the issue.

My problem is those blue arrows where you normally would set hardware breakpoints via clicking with your mouse are NOT present in my serial.c but are present in application.c thus I'm unable to set breakpoints hardware-wise to do any debugging.

Why would this be ?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #10 on: February 27, 2009, 02:18:20 AM »
Hi

This sounds as though you have no code in the file. Check the map to see whether you find your routines. Maybe they are not being called as you expect and the linker is thus not binding the code into the target file.

Is serial.c content defined as a task? It it in the task list? If not there will be no code calling it and so it will be dumped by the linker.

Also try testing with VisualStudio (you can also test UARTs and Ethernet) since there are no target-level debugging difficulties involved. When it works there you can generally load to the board and run...

Regards

Mark

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #11 on: February 27, 2009, 02:45:42 AM »
Yup it's defined as a task perfectly along with code in the serial.c file is present.
Not sure whats gone wrong with it.

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #12 on: February 27, 2009, 02:44:24 PM »
Ok from what I can tell this is ONLY happening when creating new files.

I created test.c and copied some code from applicaiton.c into test.c then started debugging to find I was unable to set breakpoints with this new code in test.c yet the very same code in application.c was able to have breakpoints applied to it.

whats the reason for this ?

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Newbie's firsttime with uTasker
« Reply #13 on: February 27, 2009, 02:58:19 PM »
Hi

Have you correctly added your new file to the Rowley project? Check that its attributes are not set to 'exclude from build'.
Also are you sure that it is really being compiled? Type some extra things in the file so that it is invalid code and check that the compiler really gives an error due to this.

Regards

Mark

Offline echel0n

  • Newbie
  • *
  • Posts: 37
    • View Profile
Re: Newbie's firsttime with uTasker
« Reply #14 on: February 27, 2009, 03:06:27 PM »
It's not being excluded from build and I added something to it that I know would throw a compile error and it did throw the error so I'm slightly confused as to whats wrong.