2x16 Serial LCD (Backlit) with Speaker+ RCFast?

Tymkrs

Hi all,

I've been trying to get a board working which acts as a pulse/sound simulator for my HeartMe board (led heart simulator). The biggest issue I'm having is that my LCD is having issues displaying what my heart board is sending to it. It's getting enough voltage/current, and it works on a breadboard. It also works with my code on the Propeller Activity Board, although sometimes it has a few funky spacing glitches before it settles out.

Someone helping me troubleshoot this mentioned that it could be because I'm sending it asynchronous serial as I'm using RCFAST because I don't have a crystal on my HeartMe board, which is what's driving the LCD. But then I noticed that on the learn.parallax.com that the baudrates are considered "asynchronous baud rates".

So my essentially question is, has anyone had issues before with getting a LCD to receive the appropriate information when they're using RCFast?

I've checked the code, the power, whether it works on another board or not. My schematic/board is correct, and currently all it does is chirps randomly and shows a cursor randomly.

Pub Display
  
  LCD.start(TxPin, TxPin, %1000, 2400)
  WaitCnt(ClkFreq + Cnt)                'Pause to initialize
  
  LCD.tx(128)
  
  Repeat
    If (Rhythm <> Last_rhythm)
      LCD.tx(12)
      case Rhythm
        1:
          LCD.tx(17) 
          LCD.Str(String("Normal Sinus    "))
        2: 
          LCD.Str(String("Sinus Brady     "))
        3: 
          LCD.Str(String("Sinus Tachy     "))  
        4:                                
          LCD.Str(String("Atrial Fib      "))
        5: 
          LCD.Str(String("Atrial Flutter  "))
        6: 
          LCD.Str(String("Supravent Tachy "))
        7: 
          LCD.Str(String("Ventricular Fib "))
        8: 
          LCD.Str(String("Ventricular Tach"))
        9:
          LCD.Str(String("Sinus w/1AVBlock"))
        10: 
          LCD.Str(String("SR 2AVBlock T1  "))
        11: 
          LCD.Str(String("SR 2AVBlock T2  "))               
        12:  
          LCD.Str(String("3AVBlock        "))        
        13:  
          LCD.Str(String("SR BB Block     "))
        14: 
          LCD.Str(String("Junctional      "))
        15: 
          LCD.Str(String("Idioventricular "))
        16: 
          LCD.Str(String("NSR w PACs      "))
        17: 
          LCD.Str(String("NSR w PVCs      "))
        18: 
          LCD.Str(String("Self Test       "))
        19:
          LCD.tx(12)
          LCD.tx(18)
          
      Last_rhythm := Rhythm
    
      waitcnt((clkfreq / 100) + cnt)

I'd appreciate any help I can get - thank you!
Addie

mindrobots

If I recall past discussions, RCFast doesn't have the clock stability to generate async bit framing consistently which makes it very difficult to genrate bits the receiver can lock on to or determine the bit length of any incoming bits. The prop really needs a crystal to use async serial.

I'm sure smarter boffins will chime in soon!

Duane Degn

It might be possible to adjust the baud the Prop is using to better match what the LCD is expecting.

Do you have a scope of logic analyzer to see what the baud really is? If not you could use a second Prop to detect the baud of your RCFAST board.

You could just try 50 bps higher and lower until you find a setting that works better. The effective baud may change with temperature though.

Tymkrs

I think that's the biggest problem is while I may be able to adjust my own lcd for the baud rate, I won't be able to adjust the baudrate in the code for all of the other lcds that this board may attach to (as i'm trying to make a kit out of it)

But the general consensus is that RCFAST + Parallax's 16x2 LCD probably won't work easily?

Duane Degn

What about using a parallel version of the display?

The displays are a lot less expensive when they don't include the serial to parallel circuitry. It means more wires between the Prop and the display but the displays would cost a lot less.

I haven't seen your HeartMe board recently so I'm not sure if this would be an option or not.

I'd avoid using a the serial LCD in a final product unless there's a really strong need for one. Even if you're running short on I/O pins, a parallel LCD plus shift register might be more cost effective than using a serial LCD.

Another possibility would be add a small 10MHz crystal to your HeartMe board. There's a bit of discussion about small crystals in this thread.

A crystal on your HeartMe board could provide benefits beyond the ability to use serial LCDs (XBees, terminal window, other UART devices).

Tymkrs

I have extra pins, and have been playing around with the idea of making my own backpack for the LCD. And if I had known this was an issue, I would have totally added the crystal . It was just a space hogger, as you guys have mentioned. That said I have nearly 200 boards made up already. So any changes to the board (including adding of a crystal) would probably have to wait until then

Genetix

Addie, will your kit be for hobbyists or medical professionals?
I can understand your reluctance to want rework your PCBs since it's a lot of work and there is the risk of causing another problem.
On the other hand, calibrating all your PCBs takes time but it only involves software.

You might want to try this your sample unit:
Allow the board to reach operating temperature by running a program that flashes your LEDs.
Use a Prop with crystal to send a square and have your board measure the pulse width several times.
Start with 1000 Hz and take 5 or 10 measurements. Then try 2500, 5000, and 10000 Hz.
Then try your LCD at 2400 baud using your 2500 Hz value, 4800 baud with the 5000 Hz value, and 9600 baud with the 10000 Hz value.
If that works then try sending a very long sequence to the LCD such as programming the 8 special characters and then displaying them on the screen.
If all this testing works then you can try this on your other boards otherwise just add a crystal.

Welcome to the world of engineering.

I don't know why I didn't think of this earlier.
You could also have your board output pulses and use an oscilloscope or a Prop with a crystal to measure the actual pulse width.

Tymkrs

Both hobbyists and professionals I'm hoping.

I actually found another method of displaying the information (hopefully cooler to the end user) so I'll be using that instead of the LCD, but it's a good lesson learned!

Thanks for the suggestion Genetix I'm more scared of the time I'd need to put into each unit before sending it out than I am of the R and D required to get it to plug-and-play status now

Duane Degn

If you're still considering what kind of display to use, you might want to check out some of the inexpensive OLEDs. ITead Studio has a good price on a SPI version. Using RCFAST with a SPI connection shouldn't be a problem.

There's code in the OBEX to control the OLED over SPI. You might want to check out this LMR page discussing these displays.

kwinn

I wonder if there is any way to share a clock signal between the LCD and the propeller board. That is, either have the propeller provide a clock to the LCD so both drift at the same rate, or the LCD provides a stable clock signal to the propeller. Would only require one more signal connection if it was possible.

kwinn

If the frequencies available were different enough to make the previous suggestion impractical then perhaps the propeller could use a signal from the LCD to adjust the timing of it's serial data.

Genetix

Addie, I asked who your target customer is because I know that medical professionals are very hard to deal with. A hobbyist is a totally different animal.
You might want to make a kit option available to hobbyists and an assembled and tested version for the medical community.

MrBi11

How about using a I2C interface to your LCD display all the timing would be via the Processor
ie. http://www.ebay.com/itm/IIC-I2C-TWI-1602-Serial-Blue-Backlight-LCD-Display-For-Arduino-/171058695325?pt=LH_DefaultDomain_0&hash=item27d3e48c9d

Tymkrs

Yeah, after talking to some other folks, they suggested a parallax 4bit lcd or SPI instead of my new option (LED array) . I haven't taken the opportunity to work with parallel 4bit lcds and the objs available, but it looks like maybe I should start to familiarize myself. I've worked with some i2c items before, but when Whisker and I tried to get another i2c module working, it was a literal nightmare just to get the ID. So I'm hesitant to do i2c lcds (though it's a good idea that I've thought about)

And the kit, Genetix, is pretty much done, since the majority of the project needs to be SMT soldered. I wouldn't ask folks to do the smt soldering themselves hehe... kwinn, sounds like SPI or I2C is the only way to do just what you're asking with the prop. AFAIK anyway..

kwinn

SPI is easier to work with than I2C since it is generally a 1:1 connection and no device addressing to worry about, but I was not suggesting that you switch to either one of them.

The difficulty you are having is due to the RC oscillator of the propeller not being accurate or stable enough to provide the precise timing needed for serial data. My suggesting was to use a signal from the LCD board to do one of two things.
The simplest would be to use the LCD signal as a clock signal for the propeller so their timing is synchronized. That would require a signal with a frequency in the range the propeller could use.
The other way was to use a signal whose frequency could be measured by the propeller and used to adjust the timing for the serial data. That would require writing software to measure the frequency and modifying the serial data object, which is not a trivial task.
Hard to say if either way is possible without having a schematic of the LCD board. The simplest would probably be to switch to an SPI or 4 bit parallel display.

Tymkrs wrote: »

...............................

I've worked with some i2c items before, but when Whisker and I tried to get another i2c module working, it was a literal nightmare just to get the ID. So I'm hesitant to do i2c lcds (though it's a good idea that I've thought about)

And the kit, Genetix, is pretty much done, since the majority of the project needs to be SMT soldered. I wouldn't ask folks to do the smt soldering themselves hehe... kwinn, sounds like SPI or I2C is the only way to do just what you're asking with the prop. AFAIK anyway..

Tymkrs

Thanks for the suggestions Kwinn. I didn't know you could use any signals from the LCD board (voodoo magic!). I have, as you may suspect, never done that, but sounds like a good learning experience.

I currently have an spi and 4bit parallel display on my desk, but again haven't worked with those thanks to parallax's serial backpack. So I'm looking in the forums now to see if anyone has dead simple code to make them work

Duane Degn

There's several 4-bit LCB objects available. I'm pretty sure there one by JonnyMac in the OBEX.

Since I suggested the ITead Studio OLED earlier, I've had a chance to try one. I really like it. The object in the OBEX works great and it can display several different sizes of fonts.

Post #15 shows the display using the 32-pixel high Parallax font and a small graphic. Post #22 shows the display using a small font allowing up to 8 lines of text. I thought the OBEX object very well done.

It would take a bit of extra programming but I bet you could display graphics of each of the heart rhythms on the display.

I'm very excited to find such a nice display for $5.

Tymkrs

Yeah that does look like a really nice oled! Sorry to be a pest, but which oled driver did you use?

Duane Degn

Tymkrs wrote: »

Yeah that does look like a really nice oled! Sorry to be a pest, but which oled driver did you use?

I used this one.

It's a SPI driver. The ITead OLED comes setup in I2C mode. I followed the directions to convert the display to SPI mode. The conversion is pretty easy but I plan to change the driver so it will also support I2C mode. SPI is faster but requires five I/O pins. In I2C mode, the display can be controlled with just two I/O pins.

Tymkrs

Interesting - the appeal of only having to use 2 pins is....well tempting (even if I hate i2c) Thanks Duane!