Serial communication with a palm pilot

[corrado33]

I've been bored with programming lately.  I don't have the money to buy the stuff I need to build my robot, and I've already fixed all of the problems I've been having with my recent software projects, so I've decided to start a new one.  

If any of you remember when I first started here, I was debating build a Palm Powered Robot.  Sort of like the PPRK built at CMU.  However, I didn't know much about programming AVRs then, so I had absolutely no idea how to do it.  Now that I know a little more, I don't think it would be that hard.  I just have to learn UART... Here's my plan.

Materials:
Palm Tungsten T2
Hotsync serial cable
AtMega8
Wires? (Ok so there's only a few materials... so what  )

I'm going to use a program called Hotpaw basic.  I decided to start this program now because a lot of Palm programs and resources are going away.  In fact, finding correct documentation for Hotpaw basic was a bit of an excursion.  If Hotpaw basic doesn't work, I'll use PocketC.  

Here's a sample program provided in the hotpaw manual for communicating over serial I/O.

Code: [Select]

# serial port I/O
# emulates a 1 line terminal
# at 19200 baud
open "com1:",19200 as #5
a$=""
k$=inkey$
while asc(k$) <> 12
# use the scroll down button to exit
if len(k$) > 0
  rem # send graffiti out serial port
  print #5,k$;
  if asc(k$) = 10
    print #5, chr$(13);
  endif
endif
# check for serial input
s = fn serial(5)
if s > 0 then
  a$ = a$ + get$(#5,s)
  rem # display input
  draw a$+"   ",10,90
  if len(a$) > 32 then a$=""
endif
k$=inkey$
wend
close #5
end
Graffiti is, if you don't know, the palm's way of deciphering your writing on the screen.  So the graffiti output will probably be ascii (numbers?)  Also, if you don't know # is remark in basic.(Used to comment out things)  rem is also remark (I believe).  #5 is an output buffer I think?  So whenever it says to print to #5, that just means it's using the predefined output made in the 3rd line of the program.  I'm guessing the "len" function is for "length".  And the asc function transforms stuff from letters to uh... ascii codes?  inkey get's the current key pressed.  On a computer this would correspond to the key pressed, but for the palm, it corresponds to the buttons on the front of the device.  It says press the down button to exit the program.  Draw is used to put stuff on the screen.  Everything else is pretty self explanatory.  Basic is a very... easy language, hence the name.  (Great language to start learning programming on too)

UPDATE!!!!!!!!!: I hooked the serial from the palm to my computer, set hyperterminal to use com1, and the program works fine.  Hyperterminal detected everything I sent it.  Although it was very hard, cause my cable is only 1 foot long, and the computer sits behind my desk, I was leaning over my desk trying to write on my Palm with one hand, and holding myself up with the other, simultaneously looking at the computer to see if anything popped up.  So, I know that the serial has the TxD and RxD pins connected, so I don't have to modify anything on the cable.  It works in both directions too.  Things I type on the computer pop up on the palm...  I'm excited. 

Here's the pinout of the hotsync cable from the palm.
http://pinouts.ru/PDA/palm_m125_pinout.shtml

However, my cable is a serial cable, so there are no USB connections.  And I can pretty much wire any pin on that chart to any pin on the serial connection side.  (With a little soldering of course).  The serial side will be connected to my PCB, so the pinout only matters to me, and it doesn't have to be anything the computer can understand.

So, my question is, when I run that program above, what pins are used for input and output?  Is it the RxD and TxD?  That's my first guess.  

Also, the baud rate rate is determined in the program, so I should just set the same baud rate on the MCU?  
Lastly, do I need an adapter for uart?  I don't think I will.  I think if I just hooked the Tx of the MCU to the Rx of the palm and visa versa, it would work?  Please correct me if I'm wrong, I don't want to break either device.
Basically, as of right now, I'm just going to try to make some input from the palm light up a few LEDs connected to the AtMega8.  Maybe I'll make an "up, down, left, and right" LED, then depending on which character I send, a certain one will be lit up.  That stuff is easy though, it's all in programming.  

Also, another idea is to use the palm as a bluetooth module for my robot.  The program above SAYS it supports bluetooth, as indicated by the Revision part of the manual...

   Updated Bluetooth and IRComm client serial I/O support.

So that would be really cool if I could get that working as well.  I could have it output data to my computer.  The program has data logger functionality, but the data is limited to 4k (or K?, I dunno).  If I could output it to my computer over bluetooth, it would be seeming limitless.  

I think this is a really cool idea, as the Palm is a perfect confined package for any robot.  It already has the functions that most people put in their robots anyway, and it has WAY more processing power than most AVRs.  I originally wanted to use it so it could calculate trig functions for my robot to navigate with.  And plot the room/display it graphically on the screen of course!  How cool would that be?

Anyway, if any of you can be of any help, I'd be grateful.  


EDIT:  Oh, guess what, it also has a IR transceiver, so I can use that for something too.  

[dunk]

looking at your link ( http://pinouts.ru/PDA/palm_m125_pinout.shtml ) it appears the Palm serial i/o pins are RS232 rather than UART logic level.
from that link:

Palm Universal connector (Tungsten T1, T2, T3, etc) has RS232 signals at RS-232 compatible levels, no voltage level translator from TTL to RS232 is needed. You can connect signals from your Palm Universal connect directly to PC or other compatible serial device.

this means that the RS232 voltages will be far higher (designed to travel longer distances) than on the UART.
the logic will also be reversed (1 becomes 0. 0 becomes 1) between the RS232 and the UART.

so to connect your Palm to an ATmega you will need a serial buffer chip like the max232 (or similar) between the ATmega and the Palm.
your first step should be getting communication between your ATmega and the PC serial port working.
after that just connect the ATmega and max232 to your Palm instead of your PC.


dunk.

[corrado33]

looking at your link ( http://pinouts.ru/PDA/palm_m125_pinout.shtml ) it appears the Palm serial i/o pins are RS232 rather than UART logic level.
from that link:

Palm Universal connector (Tungsten T1, T2, T3, etc) has RS232 signals at RS-232 compatible levels, no voltage level translator from TTL to RS232 is needed. You can connect signals from your Palm Universal connect directly to PC or other compatible serial device.

this means that the RS232 voltages will be far higher (designed to travel longer distances) than on the UART.
the logic will also be reversed (1 becomes 0. 0 becomes 1) between the RS232 and the UART.

so to connect your Palm to an ATmega you will need a serial buffer chip like the max232 (or similar) between the ATmega and the Palm.
your first step should be getting communication between your ATmega and the PC serial port working.
after that just connect the ATmega and max232 to your Palm instead of your PC.


dunk.

Wow, I had absolutely no idea that the signals themselves weren't compatible.  So I guess the Palm actually acts like a computer.  Which would make sense because it can communicate with the computer with no adapters. 

[corrado33]

UPDATE:  I actually got it working using bluetooth as well!  I was very excited as the bluetooth support in Hotpaw basic was only meant for palm OS 5, and I think I have 4.5.

I also got the palm to sync over bluetooth, but that was easy. 

The funny thing is, I only had to add one word to the program to make it work over bluetooth... lol.  I had to add ,"bluetooth", 

EDIT: I also got my MCU UART working with a closed loop, AND i ordered a TTL to RS-232 using a max232 chip.  I know you said the max232 or similar, but this one just happened to be the cheapest one I could buy, so I was happy.

[Webbot]

What would be really cool would be if you found a way to write to the Palm screen pixel by pixel.

Just thinking: a roving robot that draws the map of the world (as it bumps into it) onto the Palm screen and responds to 'gestures' made via the pen.

[corrado33]

What would be really cool would be if you found a way to write to the Palm screen pixel by pixel.

Just thinking: a roving robot that draws the map of the world (as it bumps into it) onto the Palm screen and responds to 'gestures' made via the pen.

That was my plan!  I was also maybe planning to do it via bluetooth (eventually), so you could sit somewhere (within range of course) and watch the robot plot the map on the PDA, then you could click, and the watch the robot go to wherever you clicked.  That'd be cool!  It'd incorporate UART, PWM, some kind of navigation (wavefront programming maybe), bluetooth, PALM, and much more.  It'd be awesome.

[Penth]

I have an old treo 650 I'd love to hack. Anyone have any experience with it?

[corrado33]

I have an old treo 650 I'd love to hack. Anyone have any experience with it?

Here's the pinout for it

http://pinouts.ru/PDA/palm_treo650_pinout.shtml

You should be able to do everything I'm doing with it, as I think it runs palm os 5 or higher.  It's actually not as hard as you would think.

[corrado33]

Guess what came today!!  My RS232 to TTL converter.  Ordered form alldav.com.  Very fast shipping.  They have free shipping available, but I chose the $1.39 shipping instead.  I ordered it monday morning, it shipped monday afternoon from Texas, and I got it all of the way up in PA today.  I'll say that's good for $1.39 shipping.    I'll post a vid when I get the Palm and AtMega talking.  One question though, on the converter, it has Pwr, Gnd, then "->Rx"  and "<-Tx" without the quotes, but with the arrows.  Which pin gets the Tx and Rx from the atmega?  I'll probably just pull out the multimeter and make sure the Tx from the atmega is connected to the Rx of the palm, etc...

Yeah I'm afraid to hook it up without knowing this first...

EDIT:  I guess I should link the product...

http://alldav.com/index.php?main_page=product_info&cPath=9&products_id=28

[corrado33]

UPDATE:  Ok, so I have the AtMega communicating with the computer via hyper terminal.  I modified the photovore program, used AVRLib, and followed the 'Add UART to the $50 robot tutorial'  After watching the atmega output "1" to the computer a bunch of times, I can unplug the AtMega, and plug in the Palm, and I can communicate via the SAME CONNECTION in hyper terminal. This means that both the AtMega and Palm are using the same protocols... RIGHT?  So, in the DB9 connector, pins 2 and 3 are Rx and Tx.  So, I should be able to hook pin 2 from the palm to pin 3 of the adapter, and pin 3 from the palm to pin 2 of the adapter, right?  I tried to do with two wires (as I don't have a serial cable to do it), but it didn't work, why?
UPDATE2:  Ok so I... stepped through the program that I used AVRLib (which is a PITA BTW).  Apparently it only uses a 5 bit character size, cause UCSRC=0x00, and the only thing I used that register for was to set it to an 8 bit character size...  The other couple registers were the same as what I had... But I'm done for the night, I'm freaking tired/annoyed that I can't figure this out...



Geeze I know I'm triple posting, but I'm havin some troubles.  

First off, both the cable from my Palm is male, and the Rs232 to TTL converter has a male connector on it.  So I should just get a female to female serial cable?

Secondly, I have a serial cable, it's male on one end, and female on the other.  Both have things that screw on it.  I tried to hook up my palm through this cable, to the computer, and connect with hyperterminal.  It didn't work, but when I eliminated the cord, it did.  What's up with that?  The cord isn't old, it still had the twisty tie around it. (Not that that is an indication of age, but I've NEVER seen a cord go bad...)

Third, I tried to hook up the adapter I bought, linked above, straight to the computer.  The adapter had four wires coming out of it, Gnd, Pwr, Tx and Rx.  I hooked up the Pwr to 5V, the Gnd to a common ground with the AtMega8.  I hooked up the Tx and Rx with 2 1000 Ohm resistors in series to soak up "bad ju ju" as I have no idea which wires go where.  I haven't burnt the UART of anything yet.  (Everything still works with a closed loop).  So, as I hooked it up, I got this in hyperterminal, and bunch of stuff on the AtMega side (I had a couple LEDs blink when it received stuff).

Code: [Select]


Büþô        Ðü
ü
üþ
   ø


ì   ü
     ô       ü
üü
ø       þ
ü
üAý

ô
ü
ü
ü ý
üü
ý
ý
ôüü   ý
þõ
üýW
üüBô
üBô
ü
üõ
ü
ü
ü
ü
üü     õõ
ý
üü
üüü
ü
ýø
ü
õ  üMõ
ü
þ
üü
ü
õ
þ
ü
ý
üôþ
ô

øþ üø

ý
þþ



ý

þ
ü
õCý
õ
üüø
ü
õô
þ ü
ü
øô
ü


ü
õ
ü
üþ
üþ
ýþ
üCþü üõ
ú Büü
ü
ü

ü
üü
ü Sõþ      õ
Ok yeah so firefox hates the stuff I pasted.  Basically it's all hearts and smiles.  I shouldn't have been receiving anything, as I wasn't sending anything from either device.  What's going on?  I'll post the code in a few minutes, after I add comments.

Code: [Select]

#include <avr/io.h>
#include <avr/interrupt.h>
#include "C:\My_Robots\Reaper.h"


int ct=2;


int main()
{

unsigned int i=1;
int checker=0;
PORT_on(DDRC,5); //Turns on status LED
SREG |= 0x80; //Enables global Inturrupts
UCSRB = 0b10010000; //Turns on Recieve Complete Inturrupt, and Rx pin, I left Tx off for debugging
UCSRC = 0x86;                               //Asynchronous mode, 1-bit stop bit, 8-bit character size
PORT_off(UCSRC,7);                     //Lets me access UBRRH, which shares registers with UCSRB (I think this works, but I don't know for sure because I think simulator1 in AVR studio messes this up)
UBRRH = 0x0C; //Sets first four bits of Baud Rate, 1100
UBRRL = 0x80; //Sets last 8 bits of Baud Rate 10000000 for a baud rate of 19.2k at 8Mhz (Did I do this right?) Look at table below

while (i==1)
{
if (ct==106)
{
ct = 0;                     //This was from another program, but essentially it's an infinite loop
}
}

}



ISR(USART_RXC_vect)
{
ct++;
int recieved;
recieved = UDR;
display(shread(recieved,100),400);
recieved = recieved % 100; //This takes the number received and puts it into recieved, then displays the digits individually
display(shread(recieved,10),400);
recieved = recieved % 10;
display(recieved,400);
}


Here you can see that for a baud rate of 19.2k, at 8Mhz, I have to set UBRR to 25, or 0x19, or 0b00011001.  So the four most significant would be1100?  Then the next digit would be 1?  I think I did this wrong, maybe...

[dunk]

so you are doing the right sort of thing.
TX at one end goes to RX at the other (and vice versa).
you have to remember to connect Ground on both devices as well so they both have the same reference voltage.

the fact both your AVR and Palm are working when you connect them to your PC suggests everything should work.

serial cables come in 2 generic types: Modem (also known as a Straight) and NullModem.
at the risk of turning this into a history lesson, the names stem from early computing when everything used RS232 for communications and all devices had a serial port. computers would typically have a standard serial port. modems (and other devices) would have pins 2&3 reversed.
this way you would connect a computer to a modem with a Modem cable which is a straight pin to pin cable.
if you wanted to connect 2 computers you would need a NullModem cable because that cable has pins 2&3 crossed.

enough of the history.
in short, before you use any serial cable it is worth testing where the pins go with your multimeter. there are several different variants out there and they all look the same on the outside.
*generally* if the cable is black it will have pins 2&3 crossed. if it is grey it will be straight.
still test the cable though as not all manufacturers follow this.


when you see random characters appear at the end of your serial link the things i would be checking are
1. common ground. do you have ground connected on both devices.
2. baud rate. is the baud rate the same at both ends?

if you are worried about different character size at both ends, see if you can find a terminal program that displays the ASCII character number rather than the character it's self. this way you will be able to see any pattern in the text received.
i don't think it's an issue though as both devices can communicate with hyper terminal using the same settings there.


anyway, i'm out of ideas.
good luck, sounds like you are nearly there.


dunk.

[corrado33]

the fact both your AVR and Palm are working when you connect them to your PC suggests everything should work.

I know... that's why I'm frustrated...

serial cables come in 2 generic types: Modem (also known as a Straight) and NullModem.

Wrong, apparently I found a serial cable that's NOT a serial cable.   
http://www.amazon.com/940-0024C-Smart-Signaling-Cables-Units/dp/B000V8PS6M

My rents bought a UPS and they thought I would like a serial cable...  That's my luck right?

when you see random characters appear at the end of your serial link the things i would be checking are
1. common ground. do you have ground connected on both devices.
2. baud rate. is the baud rate the same at both ends?

I fixed the random characters.  If you can believe it, I had the wrong wire hooked up from the adapter to the AtMega, I had the Rx hooked up instead of the Tx,(or something like that) and it produced random characters, AND (at the time) it was also outputting "Hello world", so I was getting both, so I was REALLY confused. 

if you are worried about different character size at both ends, see if you can find a terminal program that displays the ASCII character number rather than the character it's self. this way you will be able to see any pattern in the text received.
i don't think it's an issue though as both devices can communicate with hyper terminal using the same settings there.

If I still have problems, I'll try this. 

Wait a second... my Palm is a computer.  It is connected to my desktop computer via the cord that hooks into the bottom of the Palm (a serial cord).  Doesn't that mean that that cord has to be a NullModem cable?  So I'll need a Modem cable? 

Ok I tested that cable from the palm a little bit.  The RxD of the Palm is connected to pin 3 on the serial end.(Middle of the top(longer) row on the DB9 connector)  The TxD of the Palm is connected to pin 2 on the serial end.  Who knew cables would be so confusing?

EDIT:  Wait... no... both the serial cable from the palm, and the adapter have to act like a NullModem cable, since they both can be plugged into the computer and work fine.  Because of this, I need ANOTHER NullModem cable to switch the Rx and Tx again?  So confused, I'll just try both if I can find them.

[dunk]

does your Palm work with hardware flow control switched off?
if it does then the only pins you have to worry about are RX, TX and Ground.

forget the names for a moment, just use your multimeter to map the pins on your cables and
pick a cable that connects TX at one end goes to RX at the other (and vice versa).

Because of this, I need ANOTHER NullModem cable to switch the Rx and Tx again?

2 NullModem cables actually works out the same as a Straight. (you are crossing the pins twice.)


dunk.

[corrado33]

does your Palm work with hardware flow control switched off?

Uh, I used the default settings in  hyperterminal, basically I copied the settings that were used in the UART step by step tutorial.  I believe that no hardware control was used, so I think I'm all set.  But I just finished with finals, and I'm moving back home today and tomorrow, so I'll get back to you guys a bit later.