NetBurner Community Forum

Hi there,

I am currently transferring a Netburner project developed under Dev-C++ 1.14 to the newest NEclipse release. The project compiles flawlessly. After flashing the
generated image onto the Netburner, the application starts. The only problem is the lack of performance.
It seems like the microcontroller is running only with half of his performance (I'm watching the application's processing with mttty). There is no debug
mode running. Also the system files have been rebuilt. The source code does not differ from the one in the Dev-C++ environment (except of a
few edited externs). Does anyone have an idea what the problem could be?

Thanks in advance!

Hector

Did you make any system file changes in your earlier install, such as ticks per second?

Hello rnixon,

no I didn't make any changes at all. The only changes were compiler-related (since the gcc-version included in the
current release is newer than the one included with Dev-C++ 1.14 release). Weird...

That is strange. As a speed test, maybe try a very simple program instead of your own custom program.

Exactly what are you looking at on mttty to determine the performance numbers?

Did you do a clean install, or install over the top of your old installation?

That is strange. As a speed test, maybe try a very simple program instead of your own custom program.

I already ran some tests with other applications (Netburner FlashForm Example,...). They run without any problems.

Exactly what are you looking at on mttty to determine the performance numbers?

The application uses the serial port to output debug messages and debug sounds (via beeper). The console output is really really slow (also the sounds played through the beeper). The access to the webserver via browser is not possible during the bootup procedure of the application (under NEclipse environment).

Did you do a clean install, or install over the top of your old installation?

I set up a new Windows XP Professional VM with VMWare, which contains a fresh installation of the current Netburner development kit. The VM is used only for the development under NEclipse.

The access to the webserver via browser is not possible during the bootup procedure of the application (under NEclipse environment).

I'm not sure I understand this. How could you hit the web-server via the browser while the NB is booting? The web-server isn't running (at least until it gets past that part of the startup process.) Are you just saying it takes a lot longer for the WebServer to boot than it used to?

Also I don't think you should focus too intently on NBEclipse. You did a complete reinstall so if on the old system you modified the system files (e.g. you optimized for fast TCP transfer) then those modifications are now gone. That also means a LONG LONG TIME AGO you might have redefined TICKS_PER_SEC in your system build. Now with a clean install it is back to the default and it just LOOKS like it's running slower because the routines fire much less frequently.

If you want to exonerate (or blame) NBEclipse then you need to build your app with your current setup with Dev C++ (or by running the Make files). If that works fine then I would look at the compiler optimization settings in Eclipse. It's been a long time since I used Dev-C++ but I thought it used the same tool-chain to build the executable as Eclipse does. Eclipse gives you GUI control over everything the compiler does so you should be able to exactly duplicate your build settings from Dev-C++ in Eclipse.

If none of that works, then you are just going to have go out and buy some faster electrons.

Hello tod,

tod wrote: I'm not sure I understand this. How could you hit the web-server via the browser while the NB is booting? The web-server isn't running (at least until it gets past that part of the startup process.) Are you just saying it takes a lot longer for the WebServer to boot than it used to?

The bootup procedure I am referring to is the one of the application itself (not the Netburner one). The application initializes different paramters during the startup and calls some webservices. All these steps are displayed via serial debug. Using the new NNDK (with NBEclipse) this procedure takes a long time (~ 2 minutes). During this time the Netburner web server is not available. If I use the old NNDK I don't have this problem. The startup procedure is done within 20 seconds and the web server is instantly available.

tod wrote:If none of that works, then you are just going to have go out and buy some faster electrons.

Maybe I should consider that one. You know some fast ones?

Are you using DHCP? If so, does this occur if you use a static IP?

Is you initialization code before the StartHTTP() function?

hector,
If you're willing to try an experiment and are using a 5270/72/82 family of boards. I have an example program up on the Wiki for Ajax. Grab the newer sample for AjaxII it is the link at the bottom without the folder icon. Unzip and then File->Import that into a new project. Build and load it. (I also have to go to the project properties, click on the NetBurner options, (you get an error), click on some other line, click back on the NetBurner options and set the Target platoform to your platform - this is just a quirk in the project import). Then Open a web browser and enter your board's IP address. I just did all the above steps (just to be sure) and it takes no more than 10 seconds for the web server to come up and then you should see screen updates every .5 seconds. The program also writes out a "." to MTTY every .5 seconds. If yours takes 2 minutes and the the screen updates are slower then we know something is awry in your NNDK installation and at least we have a common code base to experiment with. One of the demos may also work if one of them has a constant MTTY or web update.

Just an idea.

Tod

Take a look at this thread (http://forum.embeddedethernet.com/viewt ... ?f=5&t=711). I would try using the time slice profiler or the stopwatch examples that are posted there. The time slice profile will log the program counter at a constant interval, every few uS, and show you where your application is spending most of its time. The stopwatch application uses a hardware timer to show you the time elapsed between two places in your code. You can use the stop watch to zero in on section of code that is causing the delay.

-Larry