| View previous topic :: View next topic |
| Author |
Message |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| UART2 while debugging PIC18F24K22 |
 Posted: Wed Aug 20, 2014 6:11 am |
 |
|
Is there anyway to use UART2 (RB7,RB6) while debugging PIC18F24K22 with ICDU64 ?
I don't want UART2 for debugging output.
I have a design that requires two hardware UARTs and a small footprint chip.
The PIC18F24K22 looks good but I do need to be able to debug the code, and RB6,7 are used for the debugger.
Any suggestions for how to do this ?
Thanks |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9229
Location: Greensville,Ontario
|
|
| Posted: Wed Aug 20, 2014 6:48 am |
|
|
Well to me, the obvious way is to just use UART1 for debugging.Since both UARTs are the same.I'm assuming you have some kind of connectors to the serial 'devices' you are communicating to/from.
Without knowing exactly your setup I see no real reason why this won't work for you.
hth
jay |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Wed Aug 20, 2014 7:17 am |
|
|
| temtronic wrote: | Well to me, the obvious way is to just use UART1 for debugging.Since both UARTs are the same.I'm assuming you have some kind of connectors to the serial 'devices' you are communicating to/from.
Without knowing exactly your setup I see no real reason why this won't work for you.
hth
jay |
Both UART1 and UART2 are needed for the application.
Thanks |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Aug 20, 2014 8:13 am |
|
|
I don't have the CCS IDE, but I believe this is how you should do it:
| Code: |
#include <18F24K22.h>
#fuses INTRC_IO, BROWNOUT, PUT, NOWDT
#use delay(clock=4M)
#use rs232(baud=9600, UART1, ERRORS, stream=COM1)
#use rs232(baud=9600, UART2, ERRORS, stream=COM2)
#use rs232(debugger, stream=MONITOR, baud=2400, xmit=PIN_B3, rcv=PIN_B3)
//===================================
void main()
{
fputc('1', COM1);
fputc('2', COM2);
// This line will send debug information to the CCS IDE, which
// will pop up a window to display it.
fputc('D', MONITOR);
while(1);
}
|
This method uses a software UART on pin B3 to transmit debug info
through the ICD-U64 to the CCS IDE.
You can also use fprintf() with the stream names. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Wed Aug 20, 2014 8:14 am |
|
|
Use a debugging header.
Cheapest one, is to simply use a 46K22, with a cable connecting the 26K22 pins across to a 28pin plug.
There are also special ones available from MicroChip, with a 'debug version' of the chip (that still appears to the software as a 26K22), but adds pins to bring out the ICD separately. These are much more expensive than the simple approach...
The 46K22, has the debugging pins on different pins from the UART. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Wed Aug 20, 2014 6:00 pm |
|
|
| Ttelmah wrote: | Use a debugging header.
Cheapest one, is to simply use a 46K22, with a cable connecting the 26K22 pins across to a 28pin plug.
There are also special ones available from MicroChip, with a 'debug version' of the chip (that still appears to the software as a 26K22), but adds pins to bring out the ICD separately. These are much more expensive than the simple approach...
The 46K22, has the debugging pins on different pins from the UART. |
Thanks for the idea. It would work if I used a 28pin DIP on board, cobbling up a 28 to 40 pin adapter is possible, but does require either a hand wired version or an expensive pcb !
I made a bad choice in the SSOP package but had so little space.
Currently I'm doing the chip to chip communication with IC2 Master to Slave, and the one UART for the device that must use a UART. When the I2C Slave wants to communicate with the Master it gets clunky.
It all works but is not as easy as RS232. Doing chip to chip with two hardware UARTs has many advantages, either side can interrupt and start a conversation.
Is there a small MicroChip uP with similar specs to the above mentioned uP, and that has two UARTs which are accessible and does NOT put the second UART on the ICSP pins ?
I thought I'd checked it all out perhaps I missed one.
Thanks for everyone that replied. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Wed Aug 20, 2014 6:08 pm |
|
|
| PCM programmer wrote: | | I don't have the CCS IDE, but I believe this is how you should do it: |
Thanks I can confirm from other projects that your example works (PIC18F67K22).
But for this project the issue is that Second UART is on the ICSP pins and of course that stops me using the UART while debugging.
Thanks for your reply. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9229
Location: Greensville,Ontario
|
|
| Posted: Wed Aug 20, 2014 6:33 pm |
|
|
re: I made a bad choice in the SSOP package but had so little space.
Have to admit I'm an 'old school' guy and never liked the itty bitty SMD devices! Also never understood WHY anyone makes anything so tiny! I prefer to use 40 pin devices like the 18F46K22 for 99% of my projects. LOTS of pins,memory, peripherals. It always seems the customer wants an extra feature, you need just ONE more I/O pin ,another LED !
Overall it's still cheaper(unless you're making 10,000 units) to use a bigger PIC than the R&D time to engineer a 'work around' solution for a 'tiny PIC'.
just something to consider.
jay |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Wed Aug 20, 2014 10:06 pm |
|
|
Unfortunately, these days, there are getting to be a number of useful chips that are only available in SMD packages. I ran into that a while ago with one of my projects.
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Thu Aug 21, 2014 12:41 am |
|
|
I have the problem only worse....
Years ago, I started making things with SMD. Produced some stuff that 'at the time' was 'state of the art;, with padless via's, and really dense SMD use. The kit itself worked fine, but showed a problem that has come back to haunt again in recent years. A lot of the kit I design, ends up in 'rugged' environments. Places like small sites out in the middle of jungle/desert etc., where there are limited supplies of spares, and stuff has to be 'serviced' on site. This makes it necessary to go 'back' to conventional DIL for complex parts. Problem is that a lot of these parts (especially for things like analog), 'disappeared' with the switch to Rohs.
On a couple of things we ended up having to buy uncut core dies, and have these packaged for us, and the problem is getting worse...
I have to say, that in your situation, given how small the 40pin SMD package is, I'd have probably laid the board out to use this, with a debug header, to make it easier...
Strikes a little of 'shooting in foot', to not think about the debugging when laying out the prototype.
Best Wishes |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Sat Aug 23, 2014 8:57 pm |
|
|
| Ttelmah wrote: | I have the problem only worse....
Strikes a little of 'shooting in foot', to not think about the debugging when laying out the prototype.
Best Wishes |
Yes plenty of holes in my feet! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Sun Aug 24, 2014 12:52 am |
|
|
Join the club... 
Everyone here who has been involved with electronics for a while, will have developed 'religious feet'. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
