PIC24HJ128xxx and RS232 help !!!!!!!

[smkul13]

Guys,

I need your help desperately. I am trying to read and write back to hyperterminal from pic24. But it's not happening. I am not sure what the problem is. Here is the code.

[asmallri]

[Guest]

putc puts a character on the xmit pin, so you have to receive something even if its garbage. Check your connections, if you are using a max232 chip with your pic it is possible that you must manually change pin 2 (receive) on your xmit pin and pin 3 (transmit) on your rcv pin, and then have common ground. I also recommend using Terminal 1.9b for testing.

[smkul13]

[PCM programmer]

Post the #include statement for your PIC. You should always put that in
the posted code. Also post your compiler version.

[smkul13]

[PCM programmer]

You still have not told us what PIC you are using.

[smkul13]

[PCM programmer]

I don't have the compiler for your PIC. But, I suggest that you
make a simple test program as shown in this thread. Get rid of
the interrupts, and get rid of kbhit(). Make it simple, like this:
http://www.ccsinfo.com/forum/viewtopic.php?t=37010&start=14

[smkul13]

I followed the link and just copy pasted. I have just changed the pin names. It did not work . I am attaching the gif file for u.

WHY THE HELL TRISC IS CHANGING WHEN I WANT CHANGES TO HAPPEN AT TRISB

http://picasaweb.google.com/smkul13/Pcd#5277667067843455762

[FvM]

If I understand your post right, the wrong TRIS register access is with built-in function UART pin setup? It's not surprising to me, cause there have been various bugs of this kind with PCD, at least regarding PIC24FJ. It's generally advisable to check the code and perform an optional register setup in user code.

By the way, I suggest to use a PIC24 keyword in the title, otherwise the post may be overlooked among the usual "hello world" problems.

[smkul13]

[FvM]

That sounds unlikely, it may be a problem of wrong register display in debugger as well.

I just realized, that your chip is using peripheral pin select registers as the PIC24FJ chips, I'm used too. But I can't see any code configuring peripheral select for the UART pins. I doubt, if it's set from #use rs232 correctly, I'm not even sure, if this action is said to be performed by PCD automaticly.

There are no 6xx SFR addresses implied with the shown RS232 initialization, thus the UART isn't yet connected to any pin. The TRIS registers in contrast are unused with pins routed through peripheral pin select, they are only valid for general IO port accesses.

I suggest to read the PIC24HJ manual thoroughly to understand the concept of peripheral pin select and related register programming.

[karthik]

I have been thru lots of such problems. I am using PIC24FJ128GA010 with PCD.

I would strongly suggest using direct registers to configure the peripherals instead of using the in-built functions. I don't use any in-built function and always rely on user defined register configuration.

For instance u can directly configure the uart mode register instead of using the #rs232 directive. This way u can be sure about the code underneath.

[FvM]

I understood now, that the present #use rs232 cmd instantiates a software UART. So the things I said regarding peripheral chip select aren't applicable in this case. I think, a software UART doesn't make sense, and it obviously can't work with an interrupt, as intended.

By omitting the pin statements in #use rs232, a hardware UART is instantiated instead. But it needs setting of peripheral pin selects, to connect it to the pins. A high performance UART with FIFO is waiting to serve you then.

I didn't yet try to understand, why the software UART doesn't work for you, but it seems less interesting to me.

P.S.: I'm not able to force the compiler to use a hardware UART by modifying the present code. I know, that it generally works, but the compiler behaviour seems strange in this regard. O.K., I see, that an UART1 is missing.