Let's Make Robots!

Help with Picaxe and serial LCD

Ok Picaxe Basic Gurus... I think I need some code snippits...

My new serial enabled LCD just arrived and I can't seem to get it up and running. I am using what I think is the standard picaxe basic commands but I am only getting white blocks, x's and some other random symbols. To be honest, I am confused with a lot of the serial commands in general, the whole ASCII thing and anything written as 0x7C or 0x14 or whatever.

Here is the display.

Here is the PDF

For instance, I first need to change the baud rate. The instructions tell me to send 124 followed by "<control>k" . Now it seems the picaxe standard is 2400 baud. What is the actual command? Do I send the "change baud" command at 2400 baud when the display is at a default of 9600? and then the command number is 124 and also 0x7C so what do I do?

In my mind (and to show I have no idea what I am doing) here are all the options I can see:

serout 7,N2400, (124, "<control>K")


serout 7,N2400,(124)

pause 5

serout 7,N2400,("<control>K")


serout 7,N2400,($7c, "<control>k")

I could go on and on with my guessing but nothing is working.

In general, I assume my major problem is with the baud rate, I hope and assume that after I get that fixed I should be able to return to the standard serout 7,N2400,("Hello") sorta commands.

Would anyone be so kind as to give me a crash course on what you think I should know?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

There's the odd numbers (binary ends in 1).

There's the even numbers (binary ends in 10).

And now I am starting to see a third range, dividable by 4 (binary ends in 100). Let's call them fourables.

Looking at the graph, you would expect these to form a set of plots under the even numbers. Starting at result 27 lowering towards result 17. Those are "The Unprintables" (Chris, you wrote those as "white squares", or just left them empty).

I now start wondering if there is a range of eightables, sixteenables and even thirtytwoables as well.ctc_ascii_27642_image001.gif

The Grand Unified Bug has been found! I think...

The clue was indeed in the "eightables, sixteenables, thirtytwoables". There's even a "sixtyfourable"!

The odd numbers, or oneables (binary always ends in 1) get divided by 2.
The even numbers, or twoables (binary always ends in 10) get divided by 4.
The fourables (binary always ends in 100) get divided by 8.
The eightables (binary always ends in 1000) get divided by 16.
The sixteenables (binary always ends in 1000) get divided by 32.
The thirtytwoables (binary always ends in 10000) get divided by 64.
The sixtyfourable (binary 1000000) gets divided by 128.

Now count the binary digits between the parentheses and shift the number by that amount to the right. That's the same thing as dividing by the divisor mentioned. Once more in a table:

bin ends in (LSB)
divide by
or rather,
shift how many positions?

The new theory now is that the numbers get pushed from the picaxe to the serlcd LSB first (the least significant bit goes in first). But the receiver does not see any start bit, because the polarity is wrong. So it ignores all zeroes until it receives a one. That one is interpreted as a start bit and then thrown away. Then it finally starts to read whatever is left over. In the case of an odd number, that would be the remaining six bits. The even numbers (that are not in any of the other ranges) leave five bits of actual data, resulting in the lower, but still printable range.

All the others exist only in my imagination, but they fit the theory.

There are still two bugs, but the second derives from the first.

A) signals get inverted, zeroes become ones and ones become zeroes (this is probably an electrical issue!)
B) start bit fails because of the inversion, the first available one (which is now inverted) becomes the new start bit. Effectively shifting the data to the right. Pad with zeroes (real zeroes as far as lcd is concerned) on the left.

Call for review: I do not trust this analysis off hand. There is just too much room for errors and misinterpretations. Would someone with real knowledge of RS232 please check my exalted claims!





Nice detective work!

You don't mention wheterh you are using the internal oscillator or a crystal. The timing of the internal oscillator can vary and has caused problems in recognizing the first legitimate character with other commercial serial devices. RevEd includes a Cailbfreq command to tweak the timing. This only is needed when using the internal oscillator, 

Happy New Year!

Myc Holmes 

The manuals do mention that the default baud rate is 2400 for this reason.

Ok, so Chris tried the polarity both ways up near the start without luck, and you seem to have gone to a lot of effort to prove the lack of a start bit which I said was the most likely problem at the start, but!

This is not an "I told you so" as Voodoo found some code by someone who has had the thing working from a picaxe. So is the unit faulty or is it another problem?

You got so wrapped up in playing "find the pattern" that you have not told us what you believe your results imply. (I'm willing to accept your code cracking efforts as accurate). If it is an "electrical issue" then what? That the serial backpack is faulty?

Hmm... I did also say something about exchanging the unit as it was possibly faulty.

Oh well, back to auditioning Orion slave girls, it's a tough job but someones got to do it!  :]

These are all valid points.

And I LOVED the pattern finding. Just chalk it up to drainbamage. I were intentionally being vague about the electrical problem, so you guys could take it from here. And I could return to cutting cardboard prototypes.

Plus, what the heck do I know about electrons...

:]  Happy new year Rik  [:
Good job Rik. Did you use your Little Orphan Annie secret decoder ring?

I have an entire room filled up with a cardboard enigma machine here!

Plus a little MS Office Excel filling up an entire hard drive....

Cracked the odd range:

To get from a given value to observed output, shift your bits one position to the right, then invert bitwise. No more than seven bits per character!

33 (dec) = 010 0001 (bin) would result in 111 (dec) = 110 1111 (bin)
010 0001
  shift right (move a zero in on the left, lose the right most bit)
001 0000
  invert (ones become zeroes, zeroes become ones)
110 1111

The decimal conversion (from which I derived the bitwise conversion) goes: result = - (given / 2) + 128 .

In picaxe basic this would be:

symbol given = 33
symbol result = b1

let result = given >> 1 ' >> works only for X1 or X2 parts
let result = INV result

This does not work for the even numbers.