RS232 get between PIC18F2580 and Telegisis Zigbee module

[TokTok]

HI ttelmah,

Thanks for the reply. I've cross checked the polarities of the capacitors (I went through this guide http://www.wjoe.com/capacitorinfo.htm just to make sure I was cross checking the polarities in the right manner) and I can confirm the polarities are correct.

I've got all the five capacitors as expected.

Apologies for not giving the marking on the marking on the MAX232 IC the marking is an A - http://datasheets.maximintegrated.com/en/ds/MAX220-MAX249.pdf

I've also got another line driver/receiver chip from EXAR i e. http://www.farnell.com/datasheets/1562947.pdf which I'm thinking I give a try.

As per the datasheet it can perform the role of a MAX232. Do you think it is worth a try?

Thanks,
Alex.

[alan]

The MAX232A use a 100nF capacitor it does not work with a 1uF, or did not in my application.

Regards

[temtronic]

question: Why do you have a 2nd MAX232 ? A single MAX232 can be used for both serial ports as it has 2 xmt and 2 rcv sections.

jay

[TokTok]

Hi ezflyr,

I'm trying the

[TokTok]

Hi ezflyr,


If it were me, the next step would be to get the serial interrupt routine working correctly. I would not bother to use the LEDs for this stage of my troubleshooting as you'll get much more information by sending diagnostic messages to your 2nd serial port. I'd still be sending the PIC a single character at a time to see how the code recognizes it, and processes it inside the ISR. Remember, the goal should be to recognize the 'Start' character, and then start buffering all incoming data until the 'Stop' character is received.


I've applied the

[ezflyr]

Hi TokTok,

I'm a little bit confused. You wrote:

[TokTok]

Hi ezflyr,

Thanks for the reply. I'm definitely not showing you my interpretation of which characters are being sent back by the PIC but showing you exactly what the PIC is giving back through the software UART.

I mention the above as I can confirm the printf() statement I've placed after the switch statement in the ISR is the statement printing out the A..B..C...Z... and this happens after I send across the single characters 'A' 'B' 'C' 'Z'.

Regarding a potential hardware issue I've utilised the 5 capacitors that ttelmah proposed hence I'm finding it difficult to see as to why there would be a hardware issue. In terms of eliminating a potential hardware error I'm thinking of purchasing and utilising an RS232 converter board such as the Mikro Elektornika board here http://www.mikroe.com/add-on-boards/communication/max232/

I believe this might help in eliminating any hardware issue that might be causing any occurrence of spurious characters.

Sorry if this approach or my question sound trivial but based on your experiences would this be of assistance in that sense?

I'm going to have a look at the code once again and the functioning of the fprintf() statement.

Regards,
Alex.

[Ttelmah]

Lets step to certain things:

1) The point about the MAX232, is that the original 'standard' MAX232, Specifies 8v out of the charge pump at 15mA load, rising to 10v at no load. That your chip is giving much less than this, says 'something wrong', and may be a hint to the core problem.
2) Many of the later low power chips have drivers with lower drops, and generate less from the charge pumps. The Atmel 'near equivalent' chip you pointed to, only generates about +/-7v, but it's drivers can still give +/-5v out from this lower voltage.
3) Now, data 'between' bytes, really says that the line is not being held low properly when in the 'idle' state. Obvious reasons would be things like the grounds not being properly connected between kit, and obviously if the ground you were using for your test point, when checking the voltages on the MAX232, was not actually the ground of the MAX232, this could explain everything. A simple poor connection somewhere between the PC ground (on the RS232 plug), the Maxim ground, and the PIC ground, could explain everything. Beware also of 'through' grounds. It is electrically bad practice to have grounds running 'through' kit. Much better practice to have a 'master' ground point, and run grounds radially from this. This particularly becomes important when currents increase.
4) As a separate comment, you talk about two MAX232's. You do realise that each of these chips has two drivers and two receivers?.

[ezflyr]

Hi TokTok,

[TokTok]

Hi Ttelmah,

Thanks for the reply.


2) Many of the later low power chips have drivers with lower drops, and generate less from the charge pumps. The Atmel 'near equivalent' chip you pointed to, only generates about +/-7v, but it's drivers can still give +/-5v out from this lower voltage.


I've attempted utilising the other chip I've got i.e. the EXAR SP232AEP which you correctly point out since it is a low power chip generates around +/-7v (specifically the EXAR SP232AEP generates +/-6.5v). One of its output drivers i.e. pin 7 delivers around +/-6.5v with no load and the other output driver (i.e. pin 14 which is connected to the DB9 connector) delivers +/-6.5v with no load and around +/-5.0v with load.

I've tested this by only sending single characters as seen in the code below and I can note there's a drop with regards to the voltage level. Regarding the connection of the 4 capacitors to the EXAR SP232AEP and the connection between the EXAR SP232AEP to the PIC, I connected them in similar fashion to the MAX232 including the capacitors I used with the MAX232.

[TokTok]

Hi ezflyr,

As you mentioned in your post I'm also expecting a response in the following manner

[TokTok]

Hi all,

I was able to overcome my RS232 hardware issues by purchasing the following add on board from Mikro Elektronika - http://www.mikroe.com/downloads/get/1276/max232_manual_v100.pdf.

I can confirm I'm not receiving spurious characters on my terminal program like earlier either using fputc() or fprintf().

I've conducted various tests i.e. sending single character when using both the hardware and software UARTs see in the code below bits labelled Test 1 and Test 2.

In mentioning this I have a small issue with regards to the uncommented fprintf() statement in my ISR i.e. what I labelled test 3 in my code below which is when I send a string with three characters e.g. 'ASZ' I get the following response which is correct:

[ezflyr]

TokTok,

I don't see an obvious reason for this behavior, so I assume that it's related to the fprintf causing 'blocking' of the incoming characters when you send them in rapid succession. Basically, the UART buffer is full, and no additional characters can be received while the fprintf statement is executing. Remember I said that the fprintf was a temporary troubleshooting tool for use when debugging the reception of individual characters? Well, now you know why!

At this point, remove the fprintf from the ISR, and put a loop in Main() that tests 'bkbhit', and then goes out and fetches characters from your receive buffer using bgetc(). Now, you should see all the characters that are being sent!

Also, your terminology might get you in trouble. You say you are transmitting a 'string', and what you mean is a collection of characters sent in quick succession. The term 'string' in most programming languages has a specific definition, and your useage is likely to cause confusion.

John

[TokTok]

Hi ezflyr,

Thanks for the reply. Sorry for my incorrect use of string. I'm used to saying string as I also write Java code.

I've added your suggestions in my code as seen below and when I send the characters individually e.g. 'A' 'Q' 'W' 'E' 'Z' I can see all of them being printed i.e.

[TokTok]

HI Guys,

Any ideas regarding my last post as seen above?

Thanks.