|
|
| Author |
Message |
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 01 February 2006, 17:27 PM Post subject: |
 |
|
Your problems are very odd. I can see that they are completely unacceptable. It appears that you have had similar issues with other displays (other than the backlight brightness issue).
I NEVER had the same trouble. While I rarely have high data-rates to the display, I never pace the data except after a reset command, not even after positioning commands. I never get glitching.
I just wonder if there is an electrical problem, like power supply. could you put a cap directly on the power leads to the LCD? COuld there be noise in the serial port wires?
I did get odd glitches in my remote display (~switched power to the backlight, I would glitch the power to the LCD logic. I put a cap right across the power pads at the LCD, and that fixed the problem. Could this be an issue for you? Could the power demands on the PWM backlight cause glitches elsewhere? Remember, I have NO backlight on my Sparkfun 16x4 LCD. I am wondering if this is why you are having trouble?
-Tony |
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 01 February 2006, 17:52 PM Post subject: |
|
|
| Quote: | | What if I was to use SHIFTOUTEX instead of the build-in async I/O routines. |
This should work. To get the timing right for 9600 baud you need to divide by 1536. This can be done with the default Register.TimerSpeed1 value of 1 and using a 'bitTime' value of 1536 or some other equivalent combination.
The character value needs to be shifted out LSB first. It would probably be simpler to "LSB first" mode.
Here is some code that seems to work:
| Code: | Const dataPin as Byte = 20
Const clkPin as Byte = 27
Sub Main()
Call PutPin(dataPin, zxOutputHigh)
Call PutPin(clkPin, zxOutputLow)
Call sendStr("Hello, world!" & Chr(&H0d) & Chr(&h0a), dataPin)
End Sub
Sub send(ByVal c as Byte, ByVal pin as Byte)
Call ShiftOutEx(pin, clkPin, 9, CUInt(c) Or &H0100, &H05, 1536)
End Sub
Sub sendStr(ByVal s as String, ByVal pin as Byte)
Dim cnt as Integer, idx as Integer
cnt = Len(s)
For idx = 1 to cnt
Call send(Asc(s, idx), pin)
Next idx
End Sub |
One thing that looks odd with this code is that it doesn't appear to account for the start bit. It turns out that the shifting routines always make the data pin an output in the low state and then wait for a bit time to expire before commencing the shifting. This strategy prevents the first bit from being slightly shorter at the expense of longer overall shift time. It seems to work out fine for this particular application to rely on that initial low output bit for the start bit of the transmission.
Another alternative, if you have the board space, is to use one of the external UART devices like the MAX3110E. |
|
| Back to top |
|
|
Genesis
Joined: 15 Jan 2006
Posts: 28
|
|
Posted: 01 February 2006, 22:26 PM Post subject: |
|
|
| spamiam wrote: | Your problems are very odd. I can see that they are completely unacceptable. It appears that you have had similar issues with other displays (other than the backlight brightness issue).
I NEVER had the same trouble. While I rarely have high data-rates to the display, I never pace the data except after a reset command, not even after positioning commands. I never get glitching.
I just wonder if there is an electrical problem, like power supply. could you put a cap directly on the power leads to the LCD? COuld there be noise in the serial port wires?
I did get odd glitches in my remote display (~switched power to the backlight, I would glitch the power to the LCD logic. I put a cap right across the power pads at the LCD, and that fixed the problem. Could this be an issue for you? Could the power demands on the PWM backlight cause glitches elsewhere? Remember, I have NO backlight on my Sparkfun 16x4 LCD. I am wondering if this is why you are having trouble?
-Tony |
How hard are you driving the LCD?
I have mine being updated constantly. Why? Because I want the ability to hot-plug it and immediate updates are important.
I could keep a "frame buffer" but its easier to just use a free-running display task which grabs what it needs and goes. Yes, everything's semaphored properly.
At 2400 bps on the Parallax display its ROCK solid, provided I wait for queue drains and use a short delay on positioning commands. With the Sparkfun display I am forced to 9600bps, which glitches incessantly.
I've got a 10uf electrolytic right on the LCD pins - with the PWM modulation I was having trouble with noise from the Sparkfun chip being coupled back into the V+ rail (!) otherwise. No issue with it full on or off, but when set for the "lowest power mode" it was doing some ugly stuff to ADC values by destabilizing the references. Not cool, but easily fixed - it wouldn't normally be much of an issue but the actual input levels being monitored are in the single-digit-millivolt range, instrument-amped up to appropriate levels for a 12-bit serial ADC - which is more than sensitive enough top pick up sub-mv "excursions" that show up on the rails!  Looking at it with a 'scope with the cap on there the rails are solid and I see no evidence of any sort of noise getting coupled into the display - at least not in places where I can get a probe on it.
I think the big difference Tony is that I have a bunch of background tasks running which are doing sync I/O all the time - they have to, as the point of this project is to monitor in real-time analog inputs and then do things with the data (which affect them ) I am thus extensively using SHIFTOUT/SHIFTIN commands as well as I2c for the Dallas 1307 that I use for both RTC and also as a convenient place to stuff NVRAM (onlty 56 bytes, but no rewrite limits like you have with EEPROM.) As an example in certain circumstances I am turning on a solenoid - and then both immediately looking at its current consumption (to detect potential faults such as a shorted or open coil) as well as monitoring other ADC inputs to see if the expected change shows up (and if not, raise an alarm.)
As such I can see where timing can get glitched on serial I/;O out the software channels - it just makes sense since SHIFTIN and SHIFTOUT shut down interrupts during the transmission/reception process. If you hose the bit-time on an async bitstream then you end up "seeing" something you didn't actually send.
I could use an external UART Don, but I'd like to avoid it if I can. If I can't then I can't. It may be the easier way to accomplish this when all is said and done, but I am very limited on board space and am loathe to go full SMT due to cost considerations at the prototype level. In full production (if that happens) I may change my view on that - but that MAX chip is pretty big - 28 pins even in a SO package is quite a bit of real estate and would force me into looking at a fully-SMT board, including buying ZX-24 cpus bare from you guys (the carrier PCB makes the package as a whole too large.)
I'll give the ShiftoutEX method a try - I bet it works, and the easy thing to do there is to implement a task that reads a queue and pumps out the bits. That change is almost completely transparent code-wise to the rest of the application.....
Will advise if that solves it - I bet it does. |
|
| Back to top |
|
|
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 02 February 2006, 2:05 AM Post subject: |
|
|
| Quote: | | How hard are you driving the LCD? |
Well, usually not hard at all, unless you count not pacing the cursor movement commands. But for mosty for my stuff, I probably do not manage to fill the buffer on the serial LCD interface instantly after a position command. Therefore I may not drive it hard enough to glitch.
It would be reasonably easy to design an AVR-based serial adapter. Off the top of my head, an ATMega8535 has all the hardware one would need and more, including PWM for the backlight.
I think it would be quite capable of running at 115Kbaud. With all that SRAM available, it would have pretty deep buffers, and most of this could be the "receive" buffer. Even I could write the code for this one. Maybe I should! Parallel LCD interfaces should be able to keep up with 115Kbaud routinely, except for the reset & home commands which consume 1.53ms.
Sometimes I consider dual-processor designs. Would 2 ZX devices be possible in your design? One for the hardware work, and one for the display? This way you could (probably reliably) talk from one ZX to the other at a high data rate (if you want), and the other can be more or less dedicated to display functions. You probably could even interface in 8-bit parallel mode to an LCD. In 8-bit mode the usual Hitachi-clone LCD controller is capable of the equivalent of over 200K baud. In this way, you would have a buffer a mile deep on the LCD ZX, and a rather high speed way to drain the buffer. What do you think?
Would this fit in your space?
-Tony |
|
| Back to top |
|
|
Genesis
Joined: 15 Jan 2006
Posts: 28
|
|
Posted: 02 February 2006, 3:19 AM Post subject: |
|
|
Probably not.
The logic board on this thing is roughly 3 x 1-3/4". On there I have connectors for power, a DB9, and two molex connectors (one 7 and one 6 pin) to connect to the offboard stuff. Besides discretes there's two +5V regulators on there and a DS1307. The second reg is required with the ZX (but not with the Parallax chip on the same board) due to the dropout characteristics on the reg on-chip - its basically unusable in this app.
The board is intentionally designed to accept the BS2 chipset series as well - I have code (much less capable) running on that chipset as well, and there are other potential users of the logic board who have made inquiries about being able to get the layout - I'm very likely to release it in the near future. Only the code for the ZX is going to be held as proprietary.
I COULD put another processor in the LCD's case (the processor in this application is physically separate from both the ADC/driver board and the LCD) BUT then I run into power issues. This thing runs on 5 2800mah NiMH cells, and I'm already pushing the limit of what I can deal with in terms of current drain with the ZX as it is. It draws about 40ma without material loads on the I/Os - I'm not quite sure why the drain is that high given the ATMEL documentation (which implies that it should be materially lower unless there is significant load on the I/O pins), but it is what it is. My ADC board pulls ~10ma with everything powered up and the LCD is ~5ma backlight off. The huge power pig is the CPU - adding another basically cuts my battery life in half - not good.
So basically if I can get it to work reliably using SHIFTOUTEX, then I'm happy. If I can't then I have to look at other possibilities including a hardware UART. |
|
| Back to top |
|
|
Genesis
Joined: 15 Jan 2006
Posts: 28
|
|
Posted: 02 February 2006, 3:50 AM Post subject: |
|
|
My initial look at this says the SHIFTOUTEX solution is stable.
I put a two-line task together to read characters out of the output queue and send them to the write subroutine. That basically gets rid of the async I/O running in the chip firmware and makes transmission deterministic in terms of the bit-times involved.
With this, of course, higher BPS rates are better (since they suspend other tasks for the shortest amount of time.) It should result in a suspension of other tasks for no more than one character-time - that is acceptable in this circumstance. |
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register