Sci0 Rx

[ddlawrence]

Hi I am new and going thru your IOProgramming.pdf examples on my minipod.
I am doing your example WATCHSCI1 with the exception that I am using SCI0.
The program she no work!
I think the command interpreter is capturing the characters I type in NMITerm instead
of WATCHSCI0.
The SCI0 TX command works as expected with NMITerm, but not SCI0 RX.
How do I get around this dilemma? Is there some doc that describes this?


thanks..............don
:o

[RMDumse]

SCI0 and the Users serial port at the same thing. Thus, if you go "KEY" or "SCI0 RX" you get the same incoming serial character, or, "EMIT" or "SCI0 TX" you send the same outgoing character.

So you're trying to do double duty on SCI0, to talk, listen, and run your code, all at once.

If you want to use the SCI0 for your WATCHSCI0 code, you have to tie up the system, so it doesn't look for your incoming characters being typed. The dreaded PCC (Program Counter Capture Loop) will do the job. Define a word HANG.

: HANG BEGIN ( some test, PA7 OFF?, for instance ) UNTIL ;

Then when you start your WATCHSCI0 follow it by HANG, and your program will be operated by WATCHSCI0, while for foreground is hung waiting for whatever boolean test you insalled to happen.

[ddlawrence]

Hey, that PCC thing suspended the interpreter and I could talk to my prog WATCHSCI0!
It seems to be the wrong way to gain software control of the serial com port on the minipod.
Is there no other way? When in service, the interpreter should be turned off if it isn't
used? This is not a problem for me, I will be upgrading to a plugapod soon anyway and
I will have more com ports.

thanks............don

[RMDumse]

Well, using the foreground or not is your choice. It is where all the waste cycles not using in the backgroud are collected. It's a place where the waste cycles can be used to communicate with the operator.

However, if you're going to use the SCI0 for something other than communicating with the operator, you need to keep the system away from SCI0. So you give it a useful task, or you give it a meaning less task. Again, your choice to fit your design.

Another approach is a back door. For instance you could spin on some variable the background controls. If you want to open the foreground, then stop the background use of SCI0, and change the variable to allow system communications. After you finish using the foreground communications, enter a word that resets the communications variable, and then spin on it again until the background changes it.

[ddlawrence]

Hi. I'm implementing an application where there is a master plugapod
sending commands to a slave plugapod and the slave replies with feedback. All via xbeepro. To my dismay, there is only one serial port on the plugapod
and the xbeepro is using it!

The application does not require a dedicated serial port for the operator,
but I was hoping to have a serial port for debugging and field service.

I understand that using the dreaded program counter capture loop
will tie up the command interpreter, freeing SCI0 for xbee communication
between the master and slave. I should be able to program this PCC
loop and turn the command interpreter off/on as you describe.
My question is this:

Is this the best method?

I will need to design this feature into the whole master/slave control loop
and I would hate to run into a roadblock and jeopardize the whole project.
Can I use jtag or CAN as a second pipe into the plugapod?

thanks.........don

[RMDumse]

Well, it is certainly a method I have used, if that helps you. There are alternatives. We now have software serial channels. So you could move the XBee's to the PE lines and use them for your communications and leave the main channels open.

Let me tell you how I handled this on a project, though. You might like it as an idea. I had two robots and two control stations. Each had a XBee. I also had two XBee dongles on my PC. So one robot, controller, and dongle were on one XBee channel. The other set were on a different XBee channel.

Now I did development on either robot, controller or let them run and talk to each other.

When I wanted to talk to a robot, I'd turn off power to the controller, and hit the key that let me escape the PCC loop. Then I could load the program. Or I could turn off the robot, and have the controller powered, escape its PCC loop and download to it. Since this was on a separate channel, I didn't effect the other sets operation at all.

Likewise, I could switch to my other dongle, and develop on that robot or controller (by choosing which one was powered) or let them run, and watch what they said to each other.

It was a sweet set up.

Key here is in the background routine I looked for a special character, in this case, 2B which is the ESC key. When the background say that key, it would stop the background (MSTOP) and change a flag. The foreground would see the changed flag, and stop the loop.

Does that give you a better idea of how to handle the problem?

[ddlawrence]

Yes, cool, that will do the trick! Sounds very clean.

Another problem I've encountered programming SCI0:
When I kill NMITerm that is wired to a pod, but not actively talking,
the pod machine stops.
Will this problem go away if I load the machine chain into EEPROM?

thanks..............don

[RMDumse]

When I kill NMITerm that is wired to a pod, but not actively talking, the pod machine stops.
Will this problem go away if I load the machine chain into EEPROM?

Suppose that depends on the meaning of "kill".

If you close NMITerm, it probably lets go the RTS line that causes a reset. If you unplug the serial port carefully, you might not cause a reset (although I'm not sure on that).

Anyway I think what you are saying is disrupting serial your board appears to stop working. Actually, it is probably reset and goes back to the beginning with everything terminated. Putting in Flash (not EEPROM) will not help for that, per sa. Your program is still there after a reset, just not running. Unless you power down. Then your program really isn't there when the power comes up. That's what you put the program in Flash to prevent.

Autostarting the code will solve the run again even if you get a reset problem. So even if you get a reset, it goes right back to running. I think autostart is the concept you are looking for.

[ddlawrence]

Yes, Flash & Autostart. I'm on my way.........Thanks............don