V0.77 slow upload issue

[ngkdc]

Good evening all,

I have an interesting problem with my ServoPods and V0.77 firmware. After I flash the firmware, I can upload my program without using the pacing character enabled with NMITerm (V0.84), the first time only. After that, it appears that the ServoPod is missing the first three or four characters after the carriage return, and won't even allow comments to load!

If I set the pacing character on, things work MOST of the time, but occasionally I'll have to help things along. By that, I mean that after the word EXPECT, the first character of the string is echoed, but everything stops at the second character. If I type the second character (and it HAS to be the correct character AND case), uploading continues ... otherwise nothing.

I'm assuming either I'm corrupting the kernel somehow in my program, or that there is an issue with V0.77. I have verified this on two different ServoPods, one has been in service for several months, the second one was just removed from it's pink antistatic bag for this test.

My listing is quite long and I'd rather not share it with the world (well, it's my bosses desire!). If you need me to send the code to you, please let me know what address you'd like me to use.

If there is a newer firmware for the ServoPod (and the IsoPod ... I still have one of those installed), I'd appreciate getting updated. Also, my usual request ... any documentation above V0.60/61 showing the new features available yet?

Thanks,


Rick

[nmitech]

Everytime your application program is running on the back ground, it requires pacing character on. That is the reason why it worked without pacing character set when you download your application program from fresh. The fact is, any terminal program that works with IsoMax or Max-FORTH in general is required the pacing character in order for the download process to work correclty. Also that is why NMITerm has the pacing character turns on by default.

The 'Pod download Page has the latest documents. It should cover up to V0.82. The last modified dates are May 2005.

[ngkdc]

Good afternoon,

V0.82 did help with the upload ... went from 20 minutes to about 4. I guess I'll have to start writing shorter applications!

I think the problem with the "EXPECT" word may actually be related to my Belken USB to Serial adapter; I had no problems with my desktop computer (Win2K), but still have to add the one character everytime I use EXPECT. Since that occurs only three times in my application, and is at the front of the program, it's not that big of a deal right now.

Thanks for the quick response.


Regards

Rick

[RMDumse]

Do you use the interrupt driven buffering mode? Might help quite a bit.

My programs usually start out adding the buffering in the first few lines, then the rest of the download goes faster, because while the board is translating the next line, the new line can be streaming in.

Here's a snippet out of a program I happen to have open just now:

SCRUB



DECIMAL
0 RAM !

HERE 80 4 + ALLOT CONSTANT RBUFF EEWORD
RBUFF 80 4 + SCI0 RXBUFFER

HERE 80 4 + ALLOT CONSTANT TBUFF EEWORD
TBUFF 80 4 + SCI0 TXBUFFER

[ngkdc]

Hi Randy,

Not on this program ... I didn't have the code accessible with me on the customer's site ... no internet access, almost no phone access!

I'll add this to my bag of tools ... you going to put this on the download section?


Thanks again,


Rick

[nmitech]

Rick, It's there in the IO Programming appnote on the download page .

[ngkdc]

Thanks Randy,

With the pacing character off and the SCI0 RX and TX buffers created immediately, it took less than a minute to load the code and run. This beats the 20 or so minutes ... and even the 5 or so that it had been taking.


BIG sigh of relief.

It also appears to have resolved my issues with EXPECT that I was having.


***

I'm sure glad you weren't there when I hit my forehead with the palm of my hand and went "A-duh"! Of course buffering the console will help things. I USED to have buffers, but for the life of me can't remember why I removed them.

Thanks again,


Rick