BasicStamp and 633

boohickey11

New member
For an EE Senior Design project we are using a basicstamp to control a widget. We decided to use the 633 as the interface. The only example code (for BasicStamps) involves 632 units, which use a different control scheme. I was looking for example code that might show how to print HelloWorld to the display. I don't really know how that works with the CRC though.

Would every command given to the 633 have to call a subroutine to calculate CRC?

For example, the example code (for 632 and 634) provided by the website shows

SEROUT 9,BAUD,["Hello World!"]

I dont really know what this would look like with a 633.

Thanks for any help
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

CF Tech

Administrator
Please give a quick search here for "crc visual basic" and there are a bunch of hits. I think if you look trough a few of those you will find some good examples.
 
Would every command given to the 633 have to call a subroutine to calculate CRC?
Yes.

I am not intimately familiar with the Stamp Basic; I tried helping a user with a Stamp/LCD project a couple years ago, and it was a disaster (but not for reasons directly related to your usage). You may have a difficult time writing the CRC calculation function. Maybe Parallax has a user forum, and just maybe someone has already done this. Have you checked there?

As for an example of the CRC and a "Hello World" packet, you might get some ideas of what's involved in this recent thread (around post #8):
https://forum.crystalfontz.com/showthread.php?t=6228

along with the CRC samples in the 633 datasheet.
 

boohickey11

New member
I think what confused me was that I was thinking mostly of using the code to calulate the crc every time it sends a command instead of calculating it before-hand and sticking the CRC number right into the code.

I want to be able to connect the LCD to the Basic Stamps I/O ports. I think this means I have to use inverted rs232. I've seen posts in this forum where closing JPB and JPE fixed someones problem but it says in the manual not to close them as they are "factory settings". Can anyone explain further?
 

CF Tech

Administrator
To put different strings onto the display, you will need different CRCs.

The JPB and JPE are for a CFA-634.

To make a CFA-633 into logic level is a bit more involved. You have to remove a SMT IC, then close two jumpers under it. We can walk you through it, but typically that is a factory operation.
 
I think what confused me was that I was thinking mostly of using the code to calulate the crc every time it sends a command instead of calculating it before-hand and sticking the CRC number right into the code.
If your messages and commands to the display are predetermined, then hard coding the crc into the string in your source code would be a good idea. But if your command/message content is variable/dynamic then you will have to use a crc calculation routine.
I think this means I have to use inverted rs232.
It looks to me like the Stamp has inverters onboard to make SIN and SOUT compatible with real normal RS232. You should try sending a hard coded string from the Stamp to the display (you can get the packet from the other thread I mentioned, or use the 633 packet debugger to make one). I think it will work "as-is", RS232-wise.
 

boohickey11

New member
Darn. The goal was to use the main serial comm on the stamp to connect to the pc then use some i/o pins so that we don't have to swich the stamp between the pc and 633 while testing code.
 
I'd think it was much easier to switch between PC and 633 on the SIN/SOUT, than to write a bit-bang routine to emulate serial async on an I/O pin. But if you did decide to use an I/O pin, you could program it with inverted logic, so the polarity matches rs232, instead of messing with the 633's invert configuration.
 
USB LCD Displays - Graphic and Character LCDs with a Keypad

boohickey11

New member
Let this forever be known as the first example code for using the CFA-633 with a Basic Stamp :cool:
-insert Hallelujah-

Code:
' {$STAMP BS2}
' {$PBASIC 2.5}

'Notes; Any change in commands to Display means CRC must be recalculated

BAUD  CON $4020                     'Set Baud rate to 19200 inverted
packetstring  VAR Byte(10)

Main:

begin:
SEROUT 16,BAUD,[7,16,"Ready to Start? ",$B7,$8E]     ' waits for user to press GO button.
SEROUT 16,BAUD,[8,16,"                ",$59,$E7]
SERIN 16,BAUD,[WAIT($80),STR packetstring\3]
PAUSE 20
SEROUT 16,BAUD,[7,16,"Packet Received ",$C6,$16]
PAUSE 1000
IF packetstring(0)=$0 THEN
GOSUB buttonpressed
ELSEIF packetstring(0)=$1 THEN
GOSUB pressedup
ELSEIF packetstring(0)=$2 THEN
GOSUB presseddown
ELSEIF packetstring(0)=$3 THEN
GOSUB pressedleft
ELSEIF packetstring(0)=$4 THEN
GOSUB pressedright
ELSEIF packetstring(0)=$5 THEN
GOSUB pressedenter
ELSEIF packetstring(0)=$6 THEN
GOSUB pressedcancel
ENDIF



GOTO Main

buttonpressed:
SEROUT 16,BAUD,[7,16,"Pressed a Button",$01,$3D]
PAUSE 2500
RETURN
pressedup:
SEROUT 16,BAUD,[7,16,"Up              ",$2E,$01]
PAUSE 2500
RETURN
presseddown:
SEROUT 16,BAUD,[7,16,"Down            ",$0F,$9B]
PAUSE 2500
RETURN
pressedleft:
SEROUT 16,BAUD,[7,16,"Left            ",$32,$DE]
PAUSE 2500
RETURN
pressedright:
SEROUT 16,BAUD,[7,16,"Right           ",$CE,$32]
PAUSE 2500
RETURN
pressedenter:
SEROUT 16,BAUD,[7,16,"Enter           ",$97,$BD]
PAUSE 2500
RETURN
pressedcancel:
SEROUT 16,BAUD,[7,16,"Cancel          ",$45,$41]
PAUSE 2500
RETURN

END
 

Loki008

New member
Let this forever be known as the first example code for using the CFA-633 with a Basic Stamp :cool:
-insert Hallelujah-

Code:
' {$STAMP BS2}
' {$PBASIC 2.5}

CODE WENT HERE 

END
I hate to dig up an ancient thread, but i am trying to use this display with a BS2, and i am having a bit of issue with this code. When i press the button, it registers the press and displays packet recieved. However only about 1/4 to 1/2 the time is displaying what key is pressed. I added a debug DEC packetstring to the code to see what was being returned, and when it worked, i get the correct value (obviously) but when it doesnt work i am getting "64" returned. any idea what is going wrong here?
 
It would be interesting to see what the BS2 is receiving at all times. You could accomplish this by feeding the 633's output to both the Stamp and a PC serial port, and then use the Hyperterm program to watch the data (or capture it to a file).

In any case, I think that Stamp program is basically flawed, because it doesn't keep track of all incoming packets. There could be a lot of incoming traffic, depending on how the 633 is configured for automatic reporting. The program only waits for a $80, and has no clue whether that $80 is the start of a key activity packet, or the data payload (or even a CRC byte) of a different report packet. The Stamp is not really capable of that level of performance (packet parsing).

So, if you can capture a bit of traffic from the 633, while you press buttons, and view it with a hex viewer, you can answer your question.
 

Loki008

New member
It would be interesting to see what the BS2 is receiving at all times. You could accomplish this by feeding the 633's output to both the Stamp and a PC serial port, and then use the Hyperterm program to watch the data (or capture it to a file).

In any case, I think that Stamp program is basically flawed, because it doesn't keep track of all incoming packets. There could be a lot of incoming traffic, depending on how the 633 is configured for automatic reporting. The program only waits for a $80, and has no clue whether that $80 is the start of a key activity packet, or the data payload (or even a CRC byte) of a different report packet. The Stamp is not really capable of that level of performance (packet parsing).

So, if you can capture a bit of traffic from the 633, while you press buttons, and view it with a hex viewer, you can answer your question.

Thanks, i will give that a shot. I just find it strange that i only get "Packet Recieved" when i press the button, so it doesnt appear to be triggered by spontainious traffic, and when it doesnt work it always equals "64"
 

Loki008

New member
Ok, Now i am not so sure the issue is with the code. Has anyone been sucessful in using the 633 with a basic stamp?

I want to make sure i dont have a defective unit, or homework board.

The reason i am saying this is i am now having issues with even displaying text. I can display text on line 1, however line 2 does not seem to be responding to any commands..
 
... line 2 does not seem to be responding to any commands..
There is only one command for line 2 in that program (a blank line). If you are trying to send a different string to line 2, you would have to have a different CRC.
 

Loki008

New member
There is only one command for line 2 in that program (a blank line). If you are trying to send a different string to line 2, you would have to have a different CRC.
Yeah, the blank line wont send, i ever tried other strings using the CRC from the WinTest application. When the program runs i get

Ready to start?
HW: 1.5a FW:k1.9
 
The blank line string works fine on my 633.

Maybe you have the wrong number of spaces in the string? If the first line works ok, then the display should be good.

Have you tried sending from WinTest directly to the display?
 

Loki008

New member
The blank line string works fine on my 633.

Maybe you have the wrong number of spaces in the string? If the first line works ok, then the display should be good.

Have you tried sending from WinTest directly to the display?
WinTest seems to work fine. And i am just getting very strange behaviors with this setup. The button presses will work for a bit, then start returning "64" the display will work, then it will stop accepting the blank line, or which button was pressed... I am really at a loss here. I am going to try another homework board tonight to see if there is an issue with the stamp.
 

CF Tech

Administrator
It pretty much has to be that you are losing sync on the packets.

To make it reliable, you should port CheckForPacket()

You should be able to "listen" to the CFA-633 with 633_WinTest's packet debugger at the same time the BS2 is listening. It might take some special cabling and level translators.
 
Its easy to lose sync with the receive packets, but why should the display ever fail to react correctly to a known good sent packet?
 
Top