IDE Bug List: Atom v5.3.0.0 [Nov 28, 2006]

The atompro still is not able to properly send commands to the speakjet. The basic stamp II can do it with no problems at all. If I set seial comunications to 9600 baud, it causes garbled results and hardware flow control simply will not work. It burns through all lines of code regardless if the buffer is full. When the buffer is full, it causes the flow control pin to go high, and when this happens my yellow LED light turns on so I know it is sending a bussy signal to the BAP.

My guess is that the speed is all wrong regardless my settings of N9600.

The stamp uses $0054 as the baud. What would this be for the BAP?

SN96, that would be because I have not tried to fix the hardware flow control problem with the serin/out comands on the AtomPro, yet. It is on my list and I will be addressing this but it isn’t fixed in the new beta.

Any idea when it will be addressed? It’s a pretty important function and it is causing customers trouble. :open_mouth:

It was previously discussed back in June. lynxmotion.net/viewtopic.php?p=23813#23813

I’ve “fixed” it in 8013 but I need confirmation because I may have the levels wrong(eg low level on flow stops serout i9600, high lets it send data).

P.S. I had no reports of problems with serin flowcontrol so I did not do anything with that. If there is a problem with it as well please let me know.

Also, ADin is fixed. The pin argument should now be the pin number(or name, eg P16).

Hservo outputs were being trashed by serout in the previous beta as well. That has been fixed.

The way the Speakjet works; when the buffer is full, or half full, it makes the flowpin “HIGH” indicating it can no longer recieve any more data, so it should stop on high and resume on low.

Thanks for the effort! I’m very excited to see progress made on this! Good work!

hy

I’ve avoid the problem speaking with the H bridge card by serial communication.
All works well now.

I’ve ordered some other Rover with the same hardware configuration, so I’ll can test if it was a material bug or a wiring error.

I will keep abreast

thx

Gaëtan

Thanks, a BAUDMODE would help me put that into context.

The Basic Atom IDE clears half the page of the terminal windows. This should not be done. The output to any of the terminal windows needs to be continuous so it can be watched. It’s impossible to get an idea of what is happening inside a robot when half the terminal window keeps getting cleared.

8-Dale

Could you be a littl emore specific. How fast are you sending data to the terminal window? Also make sure you send valid characters. Some ASCII values will clear the window. Some will cause the cursor to move. Some will clear a line etc… The terminal windows are setup to start removing top lines once the amount of data getes to a certain size(I don’t remember off the top of my head but it is several pages of text).

9600

It’s just ASCII printable text with variables using various output modifiers (DEC, HEX, SDEC, BIN). I know about characters that clear screen, etc. I am not sending any of those.

One half the terminal window is getting cleared and replaced with new output. I don’t know any other way to explain the behavior I am seeing.

8-Dale