Serial port question

Projects Programming
1

Not really sure where to post this.

The serial commands are straightforward, and I'm not having an issue with configuration or writing the routine.

I've connected to a multi mode VFD display (graphics, 5x7, and 10 x 14 text modes. (Futaba TGP1118BAA).

Aside from power, there's a single Rx pin which I'm feeding from the UNO's Tx pin (pin 1).

I last used this display with a terminal program on the serial port of a desktop. Worked swimmingly.

The serial input to the display terminates to an input of a 74HC04, the chip's Vcc is 5V .. so it's clearly TTL level.

The display wants to see "op codes" .. 0x00 to reset and clear the display, 0x09 to select mode input, and then 0x01 to enable the 10x14 character set.

This should do that, and display HELLO.

Note, the first delay of 5s was for debugging - a visual indicator (via the Tx LED) that the bootloader had completed, a wait, and then the serial code sent. The others (b) were me just trying to make it work - there is no maximum timing between bytes, so I tried adjusting it.

int b = 5;

void setup() {
  Serial.begin(9600); delay(5000);

  Serial.write(0x00); delay(b);
  Serial.write(0x09); delay(b);
  Serial.write(0x01); delay(b);
  Serial.write(0x48); delay(b);
  Serial.write(0x45); delay(b);
  Serial.write(0x4C); delay(b);
  Serial.write(0x4C); delay(b);
  Serial.write(0x4F); delay(b);


}

void loop() {
}

Now the bootloader (somewhat predictably) sends the display into fits. random modes, text, inversion, graphics, etc. As does just floating the serial input. There is little question that the display is listening.

But nothing I've been able to send on purpose does anything! Not a pip. At the first serial write, the display goes blank and remains so (unless I lift the line and let it accept capacitive coupled garbage).

I can only conclude that the UNO isn't actually sending properly formatted serial data (Should be 9600, 1 start bit, 8 data, no parity, 1 stop) to the Tx pin .. or improper levels. But then why would the display react to the bootloader on the same line? I'm considering lifting one leg of the Tx LED, but I'd rather not - yet.

Anyone have an idea what's going on?

Additional information: The UNO itself is powered USB only, and the display has a separate regulated supply with the ground (0V) tied to UNO GND pin. For chin scratches and shrugs, I've tried both 10K pull up and pull down on the display Rx pin with no change in results.

As well, another reason for the 5s delay was to only connect the display serial after the bootloader had completed - so as just to receive the bytes intended. In this case the display appears to be totally dead.

I also wrote a small routine to send 0-255 to the port just to see if I could get anything.

void setup()
{

  Serial.begin(9600);
}

void loop()
{

  for (int x = 0; x <= 255; x++)
  {
    Serial.write(x); delay (4);

  }


}

Same results.

Jim.

2

By now, you must realize that you need to provide a lot more information than that. It's all detailed in the sticky threads at the top of the forum. This post is big on words and small on workable details. Example, the display itself and its protocol. You attempt to circumvent the need with statements like, "The serial commands are straightforward". That is insufficient.

3

Can you attach or link to the datasheet of the VFD? They have a lot of differing products and I can't find that part to be certain it isn't SPI, I2C, RS232, M6800 etc.

4

Micro-snob:
Now the bootloader (somewhat predictably) sends the display into fits.

At least for testing it would seem to make sense to use SoftwareSerial to create a separate serial connection for your device or, better still, use an Arduino (such as the Mega) which has extra HardwareSerial ports so that you can leave Pins 0 and 1 for communication with your PC and for uploading code.

...R

5

Oh .. Sorry. I meant the serial commands of the UNO language appeared straightforward to me in use, and the supplied code should have revealed if they were in fact not, and with the explanation - if I was somehow not sending what I believe I am.

I was actually attempting to supply clear info .. background, what I've done, etc., proof that the display isn't looking for +/- 12V '232, etc.

The display is a Futaba TGP1118BAA, which as I described, requires a one wire TTL level asynchronous 9600-8-N-1 serial input. The various modes and addressing complexity don't appear to be the issue, as I'm relatively familiar with the display itself and can operate it properly with a terminal program.

Some of the long wording was intended so as not to send people off onto various possibilities such as a malfunctioning display, or incorrect address protocols. I know what I want to send it, and believe that I am sending it.

Suffice, by sending consecutive command bytes (hex) 00-09-01- the display should clear, set character write mode, and select 10 x 14 character size non inverted, then (hex) 48-45-4C-4C-4F should display HELLO in the 10 x 14 text mode.

In effect .. laying out a landscape if you will before the actual question of:

I can only conclude that the UNO isn't actually sending properly formatted serial data (Should be 9600, 1 start bit, 8 data, no parity, 1 stop) to the Tx pin .. or improper levels. But then why would the display react to the bootloader on the same line? I'm considering lifting one leg of the Tx LED, but I'd rather not - yet.
Anyone have an idea what's going on?

Instead of simply saying that the serial isn't writing to the display.

My assumption was, with what I supplied .. and with no data sheet available, just about all that I can - that those more familiar with the UNO board would be able to say, "Yup .. UNO serial is different in this way .. or it's not", "The Tx pin can be problematic because...", "Your code is bad", or something similar to nudge me in a certain direction.

Jim.

6

Perehama,

No, sorry. I downloaded the data 4 years ago but can no longer find it on line. All I bothered to keep was the character set and mode ops as a reference. As mentioned, I had it working on 232 with a terminal program and a desktop serial port.

Admittedly this in itself a head scratcher, as I had always assumed desktop 232 was +/- 12V .. but the input to the display (first chip to see the line) as mentioned is a 74HC04 (hex inverter) referenced to 5V.

There is no timing signal (ie, CTS) to or from the display .. just power, ground, and Rx. I seem to recall having to play around configuring the terminal to blindly send without thinking, but it's been 4 years.

I'm kind of leaning toward lifting the Tx LED on the UNO board to see what happens.

Robin2,

Already above my head.

I'm assuming what you're saying is one of the other I/O lines can be configured as a serial port? I'll read up on the terminology in your reply.

7

“ Admittedly this in itself a head scratcher, as I had always assumed desktop 232 was +/- 12V .. but the input to the display (first chip to see the line) as mentioned is a 74HC04 (hex inverter) referenced to 5V.”

How are you connecting when successful with the terminal program?

Your assertion about the 74HC04 does not rule out rs232 level signaling, it may just mean the designers of the display were being lazy. rs232 can be muscled into TTL logic levels with ease, the levels are still inverted compared to TTL, in fact the hex inverter may be part of the kludge which it would be that turns rs232 into internal TTL inverted logic. For a chip that might expect that as many microprocessors do.

Time for a test instrument of some kind, even a voltmeter would shed some space on this.

a7

8

Sadly that was four years ago and all I have to reference is a crappy facebook picture as to hard wiring. I see some 330 Ohm resistors in there, but recollections of that night I was "testing" multiple display types and form factors, so can't be certain what I was up to now aside from remembering that this particular display was pretty simple once I figured it required three consecutive op-codes to initialize.

I've seen exactly what you're talking about though re laziness. A particular model of Bizhub console printers would crap out a certain buffer chip that drove the print head for exactly that reason. Recall the "What the??" That's a 3.3V chip. Always wondered what they were thinking.

But still .. even if so. I can't think of a good football simile - but whatever evil they (or I) may perhaps have been feeding the '04 .. the gate output would still be 0-5V .. and so a proper TTL input now "shouldn't" result in logical oddness. It's not like the inverter output was swinging minus 12.

FWIW .. At one point in my code .. I inverted all commands "just to see" - ie, 0x04 instead of 0x0B.

Jim.

9

I am failing. What I am trying to point out is that in the long wires between the two devices you don’t know or haven’t made clear to me what the signal voltages OR their inverted/non inverted nature might be.

That it is received by a TTL chip doesn’t tell you enough to assume that the signals are logically rs232 or inverted from that for TTL. And without examining the circuitry, you can’t know what voltage swing is expected.

That the display spews grabage from other activity on the line is no help - wiggle the line fast enough and you are just confusing reception, esp. considering that at that instant the baud rate is probably wrong and the display is doing whatever it can to decode the line.

Maybe you could try to recreate your prior success. It sounds like you have everything you’d need in hand.

a7

10

Try feeding an inverted serial signal to the display.

11

The serial output is probably happening. you can use an oscilloscope to confirm or serial monitor etc.

12

"I am failing."

No you're not .. check signal integrity. Gotcha. See what I can do.

13

Also, it appears that software serial library can be configured to spit out inverted logic, so you could do a quick test that would be avoiding problems with piggyback use of the hardware port as well as afford an opportunity to try inverted and then non-inverted logic.

Thought it might have to be hacked, hardware or software but it is a configuration parameter.

a7

14

Ha!

According to the scope the Tx port is putting out exactly what I'm sending (loaded). A binary zero at 0V, a binary one at 5V. LSB to MSB. The waveform is stable and crisp. This of course is inverted "232" so I've placed a 7404 in line.

No change in results.

Bumped up the Baud rate to 115200 and voila!

15

Cool.

With the TX inverted, I was able as well to work out a bunch of other proprietary displays I have on hand. On a roll today.

It just occurred to me that this little UNO is in fact a potentially quite powerful bit of test kit.

Jim.

16

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.