Cheers.
And there's a genuine reason why I and others ask for
location:
It's about providing information about accessible
local resources and hardware.
e
Serial Controller for KS0108B GLCD
- Thread starter nick12ab
- Start date
And there's a genuine reason why I and others ask for
location:
It's about providing information about accessible
local resources and hardware.
e
Now seriously, does the moon have any effect whatsoever on serial comms, as the PICAXE download circuit might use a slow download speed and is not affected.Cheers.
And there's a genuine reason why I and others ask for
location:
It's about providing information about accessible
local resources and hardware.
e
Hmmm?
I'm no Physicist,
but the electrons used for serial communication
may be diverted by Gravitons:
http://en.wikipedia.org/wiki/Graviton
It's not too long after the Midsummer Solstice,
so an erudite
hippy might help more?
e
Added
I suppose another way of thinking about it is
to consider the different forms of Energy.
Moon distance is related to Gravity. (Newton's laws).
It may affect potential energy?
Consider the case of a Grandfather clock.
How does the owner renew its energy?
Last edited:
I think it's by simply pushing the pendulum. Is that right?
Whatever turns you on.
)
Last edited:
The test is complete and on the computer there is no corruption so it is definately something to do with the driver, probably the resonator. I would upload the results but the terminal (AiTerm) automatically clears out a load of characters regularly with the amount of data being sent so I can't. The experimenter also showed how the EEPROM tester doesn't end the experiment properly and will end with ERROR: 255 <> 161 for byte 65535.
What's that supposed to mean?Whatever turns you on.
Me being silly.
e
Going through my crystal collection, the integer values I have are 8MHz, 12MHz, 24MHz, 32MHz. Not much of a collection. 12MHz would require calculation of a hsersetup value using the formula but that's not hard. 24Mhz - don't bother. 8MHz would need only a simple code change but would half the processing speed. 32MHz would be good if I could make a crystal oscillator so that I could feed the pulses into a binary counter to bring it down to 16MHz, but the capacitive and resistive properties of a breadboard would probably eliminate the accuracy gains this has over the resonator, but I can't guarantee that. For now, I will use the 12MHz. It gives a nice round figure of 624 from the formula so it should be the most accurate.
This isn't about the terminal. I'm talking about how many bytes of EEPROM the checker gets to before the data going to the GLCD gets corrupted.
Well I'm completely confused. With what sending what to what?
You can see exactly what you've got in terms of EEPROMs, 18M2, 28X2, 40X2, resonators, crystals (and their capacitors?) and GLCDs - we only get snippets and it's too hard to guess what exactly you mean
Simplify it all down. Show some simple reproducible code that other people can run (so don't test an EEPROM as a means of testing serial comms, just PICAXE to something) to prove that PICAXEs are fundamentally unreliable (which seems to be the subtext of your posts IMHO).
If you can't (show some simple reproducible code that shows the problem) then it's highly likely it's something you are doing that we can't see...
Well that's nice to know (now) - I suspect your patient audience were all thinking it was the number of bytes being transmitted
So with a simple test program (just a looping PICAXE program - no EEPROM), can you send infinite amounts of bytes to the GLCD?
I have produced some test code - see after the stuff below.Well I'm completely confused. With what sending what to what?
You can see exactly what you've got in terms of EEPROMs, 18M2, 28X2, 40X2, resonators, crystals (and their capacitors?) and GLCDs - we only get snippets and it's too hard to guess what exactly you mean
Simplify it all down. Show some simple reproducible code that other people can run (so don't test an EEPROM as a means of testing serial comms, just PICAXE to something) to prove that PICAXEs are fundamentally unreliable (which seems to be the subtext of your posts IMHO).
If you can't (show some simple reproducible code that shows the problem) then it's highly likely it's something you are doing that we can't see...
For now, I'll explain exactly what I've got:
The 40X2 is running off a 12MHz CRYSTAL, using 33pF capacitors. The 'EEPROM Tester' was simply a 'case study' for the GLCD driver as in the real world whatever is controlling the serial GLCD driver won't be dedicated to the task of sending data to the GLCD.
The EEPROM Tester gets to around 10,000 bytes of EEPROM tested before the corruption starts on a 16MHz resonator, but on a 12MHz crystal with the hsersetup value (the one which would normally use a name such as B19200_64) is changed accordingly, the EEPROM tester gets to around only 2,000 bytes before the corruption starts. The EEPROM Tester uses the 'Serial In', 'Busy' and 'Execute Now' lines of the Serial GLCD controller to interface with it and the EEPROM Tester runs on either a 20X2 or an 18M2.
The 7805 regulator has a decoupling capacitor, the GLCD has one built-in and the 40X2 has one as well.
NEW TEST CODE
This new code simply increments a word variable and displays it on the GLCD as large characters. It is designed so that there is no possibility of conflicting serial signals. Corruption sets in by the time the counter gets to 90 on the 12MHz crystal. I have uploaded it so you can have a look at it if you want.
Not looking at the datasheet at present but from what I remember the baud rate generator within the PICmicro increments 0 to N which is N+1 'steps' and that +1 becomes -1 when the equations are rearranged. Or something like that.
As to the corruption issues I'm not sure what's going on but then I'm not clear on what your test configuration is or the software being used. I'm not even clear which PICAXE you are using as receiver and sender. Perhaps a recap of what your setup is will help.
Having a resonator or crystal on long lengths of wire can create problems so that's not a good idea.
None the less, I've not run into any real problems of serial interfacing and corruption in general with internal oscillators. I'm much more optimistic than others may be on using internal oscillators with serial as long as not using very high baud rates where other issues as well as clock speed can come into the equation for bit-banged interfacing. For hardware serial there should be even fewer problems.
I'll acknowledge there will always be circumstances where things won't work, but serial should haves a tolerance of around +/-6% before corruption sets in, and in most circumstances an internal oscillator will be well within that and any rounding error with baud rate generators will be pretty insignificant. External resonators are even further well within that tolerance so it shouldn't be necessary to move to crystals nor lash-up oscillators and dividers.
Unless things are borderline to start with, any slight drift of internal oscillator or external resonator should not be enough to change things to corrupt serial. Though I'm aware others having reported some baud rate issues I've never encountered them, and there has been confusion between sending too fast ( not enough gap between bytes ) and baud rate errors which are not the same thing.
I've tested my own Nokia GLCD setup on a 20X2 at 64MHz with 115200 baud serial and HSPI in play and I've not seen any corruption caused by serial issues; it seemingly handles everything thrown at it.
It may be worth posting a new thread to cover the serial issues as after this many pages it's easy to lose track of where one is, with what. With all the sub-topics and tangents that naturally occur it's easy to lose focus on what posting relates to what.
I'd suggest starting with a circuit diagram, details of which PICAXE you are using and an explanation of how they communicate ( SERTXD, SEROUT, HSEROUT etc ), maybe listing your test programs if they are short enough.
Added :Crossed with a couple of posts above. I'm still not sure what we have or what the test regime really is.
Last edited:
I will make a full circuit diagram for the test setup tomorrow.
inglewoodpete
Senior Member
Just an observation. I notice that you have High ExecuteNow in the loop, which is obviously refreshed each loop. However, there is no equivalent Low ExecuteNow.
I'm not about to bury myself into the datasheet but does the GLCD need an edge or can it work continuously with the ExecuteNow line high?
I'm not about to bury myself into the datasheet but does the GLCD need an edge or can it work continuously with the ExecuteNow line high?
Probably worth asking Microchip why there is a +1 adder in the USART Baud Rate Generator - Fig 15.1 of the 18F14K22 (20X2) datasheet which leads to all the Baud Rate Generator equations in Section 15.3...and which are the basis for the Rev Ed equations in Manual 2.
Also worth noting is that using a crystal does not actually guarantee perfect serial baud rates
- look at the underlying PIC datasheets again (Table 15-5 for the 20X2 PICAXE). A 12MHz crystal is not a "baud-friendly" value for 19200 comms, showing a 2.34% error value. HOWEVER, I don't know if the 40X2 firmware uses BRGH=1 which would suggest only a 0.16% error.So the final advice on accurate baud rates is to use a "baud-friendly" crystal - 3.6864, 11.0592, 18.432 etc - and then suffer the additional complexity that some of the PICAXE commands (wait, pause etc) take different times than the simple ratios of 2/4/8 that you get with the nMHz (n = an integer) crystals/resonators.
And finally, "12MHz crystal with 33pF caps". Have you verified that 33pF is the right value from the crystal datasheet. Sounds a bit high to me and might be pulling the Fosc frequency off a bit.
But this is all getting far too complicated - I'd put 10p on there being something simple wrong, unrelated to this baud rate diversion...
Last edited:
I'll go along with all that Martin.
I'm totally confused what is doing to what where now so I'll leave you to it.
Just one final note about Asynch serial; timing errors are cumulative. i.e. a few bytes might get read OK, but if you send in a long stream/string then the timing errors build up and the string gradually corrupts until it conks completely.
I don't know the code for PICAXE soft serial or the BRG calcs used, but I have had problems with 18X to crystal+PIC. 'scope timing checks showed PIC+crystal (and my PC serial port) to be bang-on but a significant drift-potential with soft18X serial. Others on this Forum have also noticed this and have had to adjust OSCTUNE or whatever we call it here. And I have also seen errors with PIC INTOSC with compiled code, so it can happen everywhere.
I really don't know how people develop things without a good 'scope.
Anyway, I'm sure you'll get to the cause.
All I will say is that if you use a crystal or ext resonator then that is ONE variable removed from the equation.
I'm totally confused what is doing to what where now so I'll leave you to it.
Just one final note about Asynch serial; timing errors are cumulative. i.e. a few bytes might get read OK, but if you send in a long stream/string then the timing errors build up and the string gradually corrupts until it conks completely.
I don't know the code for PICAXE soft serial or the BRG calcs used, but I have had problems with 18X to crystal+PIC. 'scope timing checks showed PIC+crystal (and my PC serial port) to be bang-on but a significant drift-potential with soft18X serial. Others on this Forum have also noticed this and have had to adjust OSCTUNE or whatever we call it here. And I have also seen errors with PIC INTOSC with compiled code, so it can happen everywhere.
I really don't know how people develop things without a good 'scope.
Anyway, I'm sure you'll get to the cause.
All I will say is that if you use a crystal or ext resonator then that is ONE variable removed from the equation.
I was meant to put a low command after the first loop waiting for busy to go high. I've done that now but it hasn't fixed the corruption.
That was already quite obvious.Dippy said:
I have a 3.6864 crystal I could try.MartinM57 said:
Added: The 33pF capacitors were just above the range specified in the datasheet so I got a second pair of 33pFs and wired each one in parallel with one already there.
Last edited:
Caps in parallel? http://www.play-hookey.com/dc_theory/parallel_capacitors.html. In series would be a lot better....
"...Asynch serial; timing errors are cumulative..." I thought the start bit for each character, and the way it's interpreted by the receiver meant that it's not cumulative?
Looking at it afresh:
- if you get a corruption at 90 characters, reset everything and try again, does it go wrong at 90 again? I can't believe any comms link drifts reliably enough to not work after just 90 characters
- you are declaring comms link problems by seeing corruption on the GLCD using a home made driver. Hmmmm...
- slightly more complex experiment - on the 40X2 side, copy all the hserin'ed characters straight out to sertxd attached to a PC. See if the PC shows any corruption and if so, it's one of the comms links (but which one). Something like (will need a bit of editing):
"...Asynch serial; timing errors are cumulative..." I thought the start bit for each character, and the way it's interpreted by the receiver meant that it's not cumulative?
Looking at it afresh:
- if you get a corruption at 90 characters, reset everything and try again, does it go wrong at 90 again? I can't believe any comms link drifts reliably enough to not work after just 90 characters
- you are declaring comms link problems by seeing corruption on the GLCD using a home made driver. Hmmmm...
- slightly more complex experiment - on the 40X2 side, copy all the hserin'ed characters straight out to sertxd attached to a PC. See if the PC shows any corruption and if so, it's one of the comms links (but which one
). Something like (will need a bit of editing):
Code:
#picaxe 40x2
#no_data
#no_table
setfreq m32
hsersetup B4800_32, %001
do
do : loop until ptr <> hSerPtr
sertxd (@ptrinc)
loopOops! I was thinking too much about resistors. There's still corruption even after correcting it.
It isn't always 90. It varies each time it is run but it is within around 25 of 90.
Actually I meant today. Here's the full schematic for the recent test application - attached as a pdf.nick12ab said:
ADDED:
Well digital signals only have two voltage levels: high and low, so the stop bit has to be either of the two and what's stopping it from being interpreted as a data bit and the next or previous bit being used as the stop bit?MartinM57 said:
MORE ADDED: I tried the 3.6864MHz crystal and that also causes corruption.
Last edited:
But if the data bit is also a mark then it could mistake that for the stop bit. As it corrupts and then temporarily corrects itself (for a small number of bytes) over and over again when it is corrupting that must be what's happening - data gets corrupted because the UART sees the wrong bit as the stop bit, and then the 'Frame Error' occurs when the bit it mistakes for the stop bit is not a mark.
What speed, and was it on a breadboard or PCB?
Ok. I'll try reducing the speed of mine down to that and see if the corruption goes away.
I'd agree. Maybe what's wrong isn't so "simple" but certainly there's more to it than baud rate and oscillator accuracy.
Below are my 'stress tests' for serial comms. The 18M2 uses HSEROUT to blast out an incrementing byte value at 200000 baud (2Mbps) every 1ms or so, and a 28X2 captures them with high-speed background receive and reports "FAIL" on the Terminal display when the latest is not one greater than the previous, and prints "-" repeatedly when everything is tickity-boo. Every consecutive "-" without "FAIL" indicates 256 bytes received without error. Both PICAXE run from internal oscillators, 16MHz.
No prizes for guessing what results I see
Code:
#Picaxe 18M2
Symbol B2000000_16 = 1
SetFreq M16
HSerSetup B2000000_16, %010
Do
b0 = b0 + 1
HSerOut 0,( b0 )
Pause 2
Loop
Code:
#Picaxe 28X2
#Terminal 19200
Symbol B2000000_16 = 1
SetFreq M16
HSerSetup B2000000_16, %111
Do : Loop While ptr = hSerPtr
b1 = @ptrInc
Do
b0 = b1 + 1
Do : Loop While ptr = hSerPtr
b1 = @ptrInc
If b0 <> b1 Then : SerTxd( "FAIL" ) : End If
If b0 = 0 Then : SerTxd( "-") : End If
LoopIf b0 = 128 Then : b0 = b0 + 1 : End If
The receiver can have the "FAIL" put in a DO-LOOP so it stops and prints "FAIL" if it ever does so can be left for extended periods of time. Note that one fail may cause subsequent cascade fails but should catch up and be okay from then on.
Other baud rates and operating frequencies can be used. The only thing to watch for is that you don't send things ( put them in the receive buffer ) faster than the receiver test program is pulling them out; that will cause lots of fails but nothing to do with baud rate or crystals.
A few dashes will appear in the terminal then it will just be FAIL constantly. I think I should re-build the circuit on stripboard in case there is a problem with the breadboard I'm using.I'd agree. Maybe what's wrong isn't so "simple" but certainly there's more to it than baud rate and oscillator accuracy.
Below are my 'stress tests' for serial comms. The 18M2 uses HSEROUT to blast out an incrementing byte value at 200000 baud (2Mbps) every 1ms or so, and a 28X2 captures them with high-speed background receive and reports "FAIL" on the Terminal display when the latest is not one greater than the previous, and prints "-" repeatedly when everything is tickity-boo. Every consecutive "-" without "FAIL" indicates 256 bytes received without error. Both PICAXE run from internal oscillators, 16MHz.
No prizes for guessing what results I see
Perhaps wind down the baud rates and even the operating frequencies. Any should do as long as they are matched at both ends and receiver pulls from the background receive buffer quicker than the sender puts.
The stress tests when working prove the frequency stability and the signal path so it could be the later which you are having problems with. If there's slewing, slow rise or fall times on the bus then that can be seen as corruption, and worse so at higher baud rates. Putting a scope on the signal should show that.
The stress tests when working prove the frequency stability and the signal path so it could be the later which you are having problems with. If there's slewing, slow rise or fall times on the bus then that can be seen as corruption, and worse so at higher baud rates. Putting a scope on the signal should show that.
Isn't a dev board just a breadboard stuck in the middle of a few components like AXE091?
I don't have an oscilloscope. Would using a power MOSFET pair make it better though.hippy said:
Just for today's testing,
http://www.picaxeforum.co.uk/showthread.php?t=992&highlight=oscillo*+soundcard
Then, depending on cash,
a real one next week?
e
??? - I'll have to assume that's humor or admit I'm completely confused.
Sort of. In theory having more current will make the wire go from high to low and low to high faster but I know that power transistors for a signal line are a massive overkil.
Power MOSFETs? What, as a push-pull driver for transmitting 6 inches? Have you been out in the sun? It's a lovely day.
For short lengths direct (or via e.g. 1K) is fine. Transistor buffering should not be needed (and if you do it wrong then how will you know you've improved it ....without a 'scope?)
Slewing problems would mean serious wiring problems/layout in such a short distance.
Don't get diverted on to a tangent now - tidy your layout and wiring and then double check it before sticking devices in.
If your circuit is more complicated than it appears then it is time to post a schematic.
It's a lovely day.For short lengths direct (or via e.g. 1K) is fine. Transistor buffering should not be needed (and if you do it wrong then how will you know you've improved it ....without a 'scope?)
Slewing problems would mean serious wiring problems/layout in such a short distance.
Don't get diverted on to a tangent now - tidy your layout and wiring and then double check it before sticking devices in.
If your circuit is more complicated than it appears then it is time to post a schematic.
I wasn't really going to stick in the power MOSFETs! I'm currently assembling a stripboard version which should remove the breadboard issues.Power MOSFETs? What, as a push-pull driver for transmitting 6 inches? Have you been out in the sun?
For short lengths direct (or via e.g. 1K) is fine. Transistor buffering should not be needed (and if you do it wrong then how will you know you've improved it ....without a 'scope?)
Slewing problems would mean serious wiring problems/layout in such a short distance.
Don't get diverted on to a tangent now - tidy your layout and wiring and then double check it before sticking devices in.
If your circuit is more complicated than it appears then it is time to post a schematic.
I don't even have P-channel power MOSFETs so I couldn't do it anyway.
Last edited:
OK, I'll do that now.