X-CTU terminal vc Propeller Tool programming connection
EMHmark7
Posts: 93
Hi,
I am programming a Propeller QuickStart board attached to an XBEE module.
The Spin code has a serial passthrough routine.
It seems my X-TU terminal (New graphical version) application cannot see the Serial from the XBEE.
Maybe it is because when Propeller Tool uploaded the code, it took exclusivity of that serial.
Is there a way to close the link without leaving the Propeller tool? ( and do it automatically every time I upload code)?
Thanks
Marc
I am programming a Propeller QuickStart board attached to an XBEE module.
The Spin code has a serial passthrough routine.
It seems my X-TU terminal (New graphical version) application cannot see the Serial from the XBEE.
Maybe it is because when Propeller Tool uploaded the code, it took exclusivity of that serial.
Is there a way to close the link without leaving the Propeller tool? ( and do it automatically every time I upload code)?
Thanks
Marc
Comments
A bit out of topic, I see I have a ")" missing at compilation. How do we know where it is in the code?
Thanks,
Marc
In order for X-CTU to see the XBee module that module must be connected to a (COM) serial port interface on the PC directly. If your XBee Module is connected to a microcontroller that is connected to the PC that won't work because the microcontroller is now connected to the PC, not the XBee.
One problem I am working on is that I am working on the Quickstart, connected, but as well, while the application is running, I want to receive trace monitoring messages.
In the meantime, I want to be able to send config instructions to the XBEE. (I have already succeeded in receiving and sending data).
The problem is that, I am wondering the best code for sending traces/monitoring messages to the computer while being able to send messages to the XBEE.
More precisely, I am looking at the functions that will allow me to send these messages to the computer, either by a Parallax Serial Terminal or other function, and ideally doing it in the X-CTU application, not the Parallax Serial terminal.
Right now, from the code taken in the XBEE tutorial, the back and forth is done.
But I have problem choosing how from the code I can send text and numbers, with all the functions I defined for Parallax Serial terminal.
This email is not clear but I really need to leave now... and work on that on the weekend.
I will experiment more, comments welcome (If it rings bells in your experience).
Thanks,
Marc
Apparently I am not clear on the details. I have never heard of the X-CTU software working through a pass-through application. Only some features would probably work in this mode since several I/O pins must be passed through for certain things like firmware updates. Even so, if you're sending other information through the serial port that wouldn't work. On the other hand if you're trying to send/receive data from the XBee module while using the pass-through code that won't work either. Again, I am probably not clear on what you're doing or trying to do.
The procedure is in chapter 4 of "Getting Started with XBee RF modules".
I had given up on the XBee when one of the three I bought became non-operational before I had finished with range and battery life testing. I have been around the world and spent a bit of money looking at different options and have finally decided to revisit them. I reran my initial testing and found that error rate keeps creeping up as the batteries get weaker but having things soldered instead of bread boarded should lessen battery drain and reduce error rate.
Any ideas on how to troubleshoot the non-preforming X_CTU as a monitor would be greatly appreciated.
Tim
Life keeps interrupting my projects.
Here is how I finally setup: My Device runs on a Parallax QuickStart. It means we can connect its USB port.
An XBee is on the remote control that is a 4D touch screen display and is performing all the user interface and is sending instructions to the device.
In order to test individual electronic components without involving the remote, I created different CASE loops in a different cog.
One is reading the Parallax serial terminal window. Every instruction I type there are received by the QuickStart, executed as if received from the remote.
One specific char I send means: the next instructions are for the XBEE, so nothing is executed but the char is just sent to the XBEE.
I can program the QuickStart attached XBEE that way or send instructions through it for the remote.
We could even program the remote XBEE by initiating the programming sequence +++ from the code on the remote, triggered with another char than +++.
(but it is tricky here, we need either to buffer instructions we want to program in the XBEE once in programming mode, we cannot have a real direct dialog with that remote)
Chris, when I mean pass through, I was not talking about IOs on the XBEE, I was refering to a simple program that forwards any received char to the XBEE and any XBEE received char to the serial terminal.
So, now, besides the Serial terminal #Includes that maybe run duplex continuous communication, meaning 4 cogs running,
Meanwhile, I have at least 2 cogs running: one for trafic from USB to XBEE (PCtoXB), one from XBEE to USB (fromREMOTEtoPC)
Each instruction is a letter (followed by whatever necessary). Beside charls like @#$%?etc, instructions are capitale letters.
The acknowledgement that the task is finished is the lowercase letter or the same @#$%etc char.
This acknowledgement needs to be sent to the 2 sides: to the ZBEE and (for monitoring) to the PC)
Now, I could connect anytime the USB and see the data stream in the dialog between the remote and the device.
Or have another XBEE conencted to a computer that would sniff the traffic.
About reliability: in the past, I had problems with the XBEE connected communication with the computer.
I found that it has to do with a specific order of plugging things.
I do not find anymore my protocol sheet (Someday I will find it, in the following weeks)
beside that protocol, you can get problems with a specific USB port (radio interference with another plugged device or because it is a USB on your computer casing that is not direct on the motherboard.
Also, if using a USB hub, sometimes, better disconnect the hub and reconnect (if computer does not detect the device)
About battery life, it is maybe related to your power regulator that does not work well at low voltage such as 6V (if it is a switching regulator)
A good way to avoid this is to add more batteries (if using easy available 1.2V rechargeable) or use (a bit thricky NiZn 1.6V batteries)
They can be damaged or have their life reduced if we discharge them billow 1.3V (manufacturer says 1.1v but wikipedia says1.3V. but these batteries have a long lasting curve above 1.5V, so my limit will be 1.5V)
So, we need to monitor the battery voltage, I am designing it now, based on a MAX1242 AD converter with a voltage divider. about 8-9$ but can work on 3.3v logic.
It will display onscreen the voltage.
Later today I could post some code for my 2-way interpreters.
It is better to plug the Quickstart USB first and turn on the terminal.
Then your other device, if USB powered that uses a serial emulator same as Parallax, your other device, it will use another Com port.
But I found that if you plug the QuickStart first, the computer won't see it.
As I am limited in my remote RAM for programs, I do not bother unplugging the XBEE and connecting it on a USB-XBEE programming plateform (ordered at Parallax)
So I can reprogram the XBEE. I reduced its transmitting power to 0.1mw, but not sure it will reduce overall consumption.
Marc
the device, while in sleep, has its CPU, with the loop reading the trafic coming from the remote, looping for let's say 20 seconds and then every 20 Sec, wakes up the XBEE for 1 sec listening to the remote wakeup call.
Of course, every message sent by the remote checks if the device is active.