problem with SXB serial communication & VB2005 GUI

Fry'n ICs

Greetings!
I have been experiencing a lot of trouble with the SERIN command in SXb and am hoping that someone can offer some insight.

__________________
The problem:
__________________
I am attempting to send a byte from Visual Basic 2005 to an SX chip. The SX is attached to 8 LEDs which display the byte value in binary. If this sounds familiar, it's because it's from the SX help file. Everything seems to work fine for bytes 0 thru 127. But as soon as I hit 128 and higher, I start getting unpredictable output on the LEDs.

__________________
The circuit:
__________________
1) SX chip on a parallax professional development board plugged into the designated SX socket.
2) 8 LEDs attached to pins RC.0 thru RC.7
3) RA.1 attached to pin 3 (SIN) on my computers serial port. (see attached schematic showing serial connection.)

__________________
SX Code:
__________________

'

---

' Device Settings
'

---

DEVICE SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ 4_000_000
'

---

' IO Pins
'

---

RX PIN RA.1 INPUT 'This pin recieves the byte from the computer
LEDs VAR RC 'Prepare the LEDs to output the byte
TRIS_LEDs VAR TRIS_C
'

---

' Variables
'

---

sData var byte 'This variable stores the byte sent from the computer
' =========================================================================
PROGRAM Start

Start:
TRIS_LEDs = %00000000 ' make LEDs outputs
sData = 0 'start with all LEDs off
Main:
SERIN RX, N38400, sData 'get the byte from the computer. The help file says 38400 is the fastest rate available at 4mhz
'Yet even slower rates such as 2400 won't work
LEDs = sData 'output the byte to the LEDs
Goto Main 'rinse and repeat

__________________
The VB2005 code:
__________________
1) Create a new project.
2) drag a serial port control from the tool box to the window
3) Keep all the properties set to default, except change the baud to match the SX code (38400) and set the comport to the right value
4) Drag a button and a textbox control to the window.
5) Double click the button and enter this code:

SerialPort1.Write(Chr(TextBox1.Text))

__________________
Theory of operation:
__________________
Run the VB2005 program, enter a number (zero to 255) in the text box, and click the button. VB converts the number to the corresponding ANSII character and sends it to the SX chip. The sx recieves the character in the form of a byte and outputs the numerical value to the LEDs. Once you get to 128 (and all numbers greater), however, all you get is "63" output to the LEDs (well... the binary equivalent to 63, that is)

I have created extravagant workarounds to resolve this problem... but those solutions are exceeding complicated, slow, and eat up all the memory in the SX that I would rather use for other code. If anyone could tell me what I'm doing wrong, it would be greatly appreciated [noparse]:)[/noparse] If what I am trying to do isn't possible, a less complicated solution would also be appreciated. The SX needs to be able to count from zero to 255 (all LEDs off, to all LEDs on).

Thanks!

JonnyMac

You cannot use the OSC4MHZ setting as it is not stable enough for serial comms; switch to a resonator and you'll be fine.

[noparse][[/noparse]Edit] I've attached a demo program that works. I had to use HyperTerminal to test it as I don't have VB2005.

Post Edited (JonnyMac) : 1/1/2009 1:06:36 AM GMT

Unsoundcode

Hi, your VB code for the Button_Click event·might be better written

Dim sdata(1) As Byte

sdata(0)=(Val(TextBox1.Text))

SerialPort1.Write(sdata,0,1)

If you don't yet have any resonators handy the above may still work well enough at internal 4MHz so you can do a little testing until you get one.

Jeff T.

Fry'n ICs

Thanks guys! Johnny... I'm a newbie and I'm afraid most of your code went over my head. But simply changing up the VB code as suggested by unsoundcode made everything work just fine! even without the resonator. Thank you so much guys.... You don't know how long I have been trying to figure this out!! You guys rock! [noparse]:)[/noparse] [noparse]:D[/noparse]

JonnyMac

If it's working without a resonator you're getting lucky; be careful counting on luck... it can run out at the most inopportune times. If you want reliable serial communications with the SX you really should use a resonator.

Unsoundcode

I wanted to add a little insight on what was happening with the VB side of things and what the difference is with the code that works to that which does not. The instruction Chr(Textbox1.Text) returns the Unicode character of a two byte value not an ASCII character, Unicode characters 0 to 127 are the same as the ASCII characters the remaining characters can range from 128 to 65535 and depend on the current character set. That explains why beyond 127 your results were not as expected and the SX did not recognize the values as ASCII character codes.

Write,WriteLine and Read,ReadLine in·VB·will easily transmit and receive an ASCII string , to transmit and receive single or multiple byte values in the range 0-255 you need to format Read or Write as we did and set up a byte·array (in our case it was an array with one byte element) and reference the array by an offset and number of bytes to read/write. Not only is this easier to deal with at the SX it greatly improves the data exchange speed.

good luck with the gui

Jeff T.

Unsoundcode

Fry'n ICs, you might be interested in this little sample, it is just a plain and simple test program so it is no way perfect but the principal of operation works great. The VB code uses the data transmitted by the SX as synchronization, it looks for a header then receives and transmits in one sub routine. For the example the SX is transmitting back what it receives but the data can be whatever you wish. Using this method allows the SX to execute it's program cycle pausing briefly for the serial communication.

The attachment has both the VB and the SX code, in VB all that is needed is a Windows Form with two text boxes and two track bars set to a maximum of 255. The program was run on an SX 28 with 50 MHz resonator, adjust to suit.

Jeff T.

JonnyMac

Unsoundcode: All those SEROUT and SERIN statements will burn through your program space in a big hurry. It's a good idea, with an SX/B instruction that generates a lot of code, to fold it into a custom subroutine or function. This means that the "big" instruction is compiled just one time and saves space, and as you can control the behavior of the subroutines and functions you can actually make them easier to use. You can see this at work in the demo I posted earlier in this thread.

Unsoundcode

Thanks for the advice JonnyMac,·I guess·my example·wasn't very well structured and although I havn't looked at your example yet I ·certainly will.

The Visual Basic to SX was similar to something I would use with a BS2, I was really pleased with the way in which the two programs interacted, very fast very smooth. The VB code also was not well structured but served for the example.

My next shot will be much improved.

Thanks

Jeff T.

JonnyMac

We (EFX-TEK) have several products that use the Parallax AppMod protocol so I, too, am comfortable using a command header to sync communications. Ultimately, though, you may want a device that can do serial and something else at the same time (e.g., PWM leds, motors, etc.). I've attached the framework that I use when starting a new EFX-TEK accessory; it uses interrupt-driven serial over one wire (open true baud mode) and takes care of receiving the header from the host which starts with "!", is followed by two alphas, an board address (%00 to %11), and then a command character.

The program may be a little advanced from your point-of-view now, but as you study it (I always try to code cleanly and use good comments) it should start to come together.

BTW... most of the assembly segments that are in the program I learned from exploring the code generated by the SX/B compiler. One final note: the framework is intended for the SX20 and SX28 -- it would require updates to the transmit UART for the SX48.

Fry'n ICs

Thanks unsoundcode and johnnymac. Unsound: sending information back and fourth was my next step... so you save me some time. Johnny: I will create a subrouteine to store all of the serin and out as you suggested to keep the memory use low. For example purposes, it does make the code a little easier to read by simply listing everything out without using a sub. Johnny, your latest example does once again go over my head.... but i really want to know how it works. I spend some time with it this week and see if I can figure it out. Ultimately putting the serial communication on an interrupt is exactly what I need to do... but I haven't been able to figure out how the interrupt functions work yet. Thanks again guys!

Unsoundcode

Hi Fry'n ICs, I too have difficulty with JonnyMac's example , the examples good it's my understanding that isn't, I think it's something you need to devote time to, which I don't have a lot of right now. I downloaded a document from this link http://www.parallax.com/tabid/460/Default.aspx called Begginnig Assembly Language for the SX Microcontroller, it has some really good ASM tutorials and as you get into the deeper chapters explains how to create your own virtual peripherals akin to JonnyMac's example. It was also mentioned if you press Ctl + L in the SX IDE you can view the ASM listing of your SXB program, if you havn't tried that yet then do, it may help.

Jeff T

JonnyMac

@Fry: While I think it's a good idea to understand the code, you can, of course, use examples that others posted here without worry (well, most of the time <grin -- we're all human>). Think of it this way: Do you know how SEROUT works (internally, that is) or just that it does? In my programs, interrupt driven or otherwise, I wrap the functionality of SEROUT in a routine called TX_BYTE. The core program doesn't care if I'm using an interrupt or not, it just wants to send a byte with TX_BYTE. Make sense?

Feel free to ask any specific questions you have about my demos -- I try to include useful comments but I know that sometimes comments aren't quite enough.

Fry'n ICs

That's an excellent point, Johnny... As far as the schematic side of things... is there anything special I need to do to make the serial pin an interrupt... or do I simply hook it up as I normally would and let the code take it from there?

JonnyMac

There's no magic in the connections unless you're using an "Open" mode; if using Open True then you need a pull-up on the serial line, if using "Open Inverted" then you need a pull-down on the line.