Software comm errors

[sturgessb]

Hi guys.

Im connecting with a Wifly GSX module with a 328n and getting strange com problems when using software com port (9600 baud)

Odd characters here and there.

Should I have any pullup or down resistors on the com lines?

Cheers

Ben

[dkinzer]

Should I have any pullup or down resistors on the com lines?

Pullups (on non-inverted) and pulldowns (on inverted) may or may not be required but, assuming they're a reasonable size (say 10K), they never hurt. That said, it is possible that something in your program is causing the timing to be thrown off. For example, using an Atomic block that takes longer to execute than a quarter of the bit time of the fastest software UART channel will cause problems. So, too, will any of the System Library routines that say they disable interrupts if that time exceeds a quarter of the bit time of the fastest channel. An example of this is PulseIn() or PulseOut().

Something that might confirm that this is the problem is to use a lower baud rate (if using a single channel) or specifying a lower maximum in the ComChannels() call if you're using multiple channels.

If the problem is being caused by your code, a strategy for determining the culprit is to start with the minimum amount of code necessary to communicate with the Wifly module and then add elements to your program incrementally until you begin seeing the problem. You can also accomplish the same goal using a "binary search" strategy. First add about half of the additional elements. If the problem is present, take out about half of those and repeat adding in or taking out half of the remaining until you locate the offending item.

[sturgessb]

Thanks Don

There is no other code running, so I think it's a hardware issue. I tried the same setup with a zx24 on com2 and all worked nicely.

Now, I'm naughty and tend to run my zx devices at 3.3v to do away with any LL conversion, whilst I've never run into any other problems, could this affect the software serial functionality?

Device I'm communicating with is 3.3v also

Cheers

Ben

[spamiam]

Now, I'm naughty and tend to run my zx devices at 3.3v to do away with any LL conversion,

Ben,

The crystal of the ZX328 is 14.7MHz. Clock speeds of greater than 10MHz require at least 4.5v according to Atmel for the ATMega328p.

Often the failure of the microcontroller to function properly is not an all-or-nothing phenomenon. Certain subsystems may fail before another. They may fail only under certain conditions. It is certainly possible that there is a software problem, but a hardware problem is not excluded due to operating the 328 out of spec.

One test would be to run the ZX at 5v, and install some simple level conversion temporarily and see if the problem persists. If so, then it is not the voltage....

-Tony

[sturgessb]

somewhat a case of RTFM then. I will try with 5v on another 328 and see if that makes a difference.

Can i simply change the crystal to that of the 328l or does it require different firmware? Is this updateable over serial or does it require ISP?

Cheers

Ben

[dkinzer]

Can i simply change the crystal to that of the 328l or does it require different firmware? Is this updateable over serial or does it require ISP?

The crystal frequency cannot be changed because many elements of the code are based on the frequency. To turn a ZX-328n into a ZX-328l requires that it be re-flashed via ISP.

The minimum operating voltage is not quite as high as Tom indicated. Using the attached speed-voltage curve you can calculate a minimum operating voltage of about 3.55V at 14.7456MHz.