CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

migrating from pcw to pcd
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
osu1177



Joined: 10 Feb 2011
Posts: 14

View user's profile Send private message

migrating from pcw to pcd
PostPosted: Mon Feb 27, 2012 3:07 pm     Reply with quote

Hi All,
I have been programming 16f877a chips and below, and am no expert by any means. My latest application requires the use of at least 3 hardware UART's, so I am looking at the 24 series. In order to use these, I would have to transition from my trusty pcw compiler to pcd.

Would it be difficult to port my 16f877a code to a PIC24FJ64GA306, for example? Or would it be rather straight forward?

Any thoughts?

Thanks for your time, as always.
David
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Mon Feb 27, 2012 3:29 pm     Reply with quote

it all depends on your code

basic stuff you have done should be fine
temtronic



Joined: 01 Jul 2010
Posts: 9162
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Feb 27, 2012 3:35 pm     Reply with quote

Lots of thoughts...

Migrating to a different series can be painful! First be sure your programming hardware/software WILL program the chips you select.Apparently the PK3 has 'issues'.
As well, there's the 'learning' curve getting to know the differences the 'new' PIC has that aren't compatible with 'old' PICs.
The 24 and 33 series aren't as popular as the 16 and 18s are.Perhaps a 'high powered' 18 PIC will do the job? You mention 3 UARTS,perhaps an external I2C or SPI device could be used? especially if speed isn't a huge factor?
You might find using a PIC you know(or very similar) and some support chips might make the product 'faster to market'.Also ther's the cost factor, but PICs are cheap it's the R&D(labour) that costys the real $$$$!
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Mon Feb 27, 2012 5:13 pm     Reply with quote

Let me add - there are several 18f46K parts that have DUAL UARTS on board -
and if you have RTS-CTS control over two of your ports - you could multiplex back and forth checking for incoming data release on your falling CTS - over a given time window using just ONE of the dual uarts -

with the right circumstances THAT would be 3 port support.
Very Happy Very Happy
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Mon Feb 27, 2012 6:38 pm     Reply with quote

temtronic wrote:
Lots of thoughts...

The 24 and 33 series aren't as popular as the 16 and 18s are....


I am sure this is cause and effect related. Lots of schools teach the basic PIC16F. Cheap tools (free compilers) drives this behaviour.

Personally I stopped using the PIC16F family in 2004, and stopped using the PIC18F family for new hardware designs in 2007.

My default processor for new hardware designs is the PIC24/dsPIC33 or, for complex networking based applications, the PIC32

The internal architecture of the PIC24, the bus width, Interrupt Vector Tables, larger RAM, and rich peripheral set makes this PIC a great choice for developing application and bringing them to market quicker than on the legacy PIC predecessors.

For non-complex high volume applications where every cent counts, then PIC18s and PIC10s etc definitely have their place.

The good thing about the CCS family of compilers is that code portability between PIC families is relatively straight forward and the bulk of the code can be migrated unchanged unlike the nightmare of doing this with Microchip's compilers each with their compiler specific linker scripts.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!


Last edited by asmallri on Mon Feb 27, 2012 8:12 pm; edited 1 time in total
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Mon Feb 27, 2012 7:15 pm     Reply with quote

osu1177 - let me put it to you like this:

Wise developers make ALL decisions, for every engineering project
based on the functionality you need and the cost to produce that design-
in the intended volume and beyond.

In my case the design is driven by ONLY those factors.
having never been hired to create an MP3 player or pocket video recorder -
I have always been able to satisfy myself and my customers with very low cost pics. A month ago I did a design that was best handled by an 18F4620.
Last week I did an uninterruptable lighting controller with a 16HV616 and this afternoon decided that I would probably use a 10Fas the clever, low $$ way - to do an LED lighting modulator.


If you decide on only ONE family of PICS in advance of fleshing out
your whole project - you run the risk of paying too much to produce it -
at the MINIMUM.
osu1177



Joined: 10 Feb 2011
Posts: 14

View user's profile Send private message

PostPosted: Wed Feb 29, 2012 12:09 pm     Reply with quote

Thank you all for the thoughtful responses. I do appreciate it greatly.

I had migrated from a 16f877a to a 16f1824, without any hiccups. If the process would be similarly easy to the 24 series, I would venture to do so; the 24 series have a lot of features which would come in handy for this project.

However, I do have concerns based on what I have read. And, as temtronic has mentioned, there are alternative venues involving external comm devices.

What I need is 6 channel, full-duplex asynchronous communication. Any comm protocol that involves a buffer (FIFO, shift register, etc) should work fine.

My idea was to use 2 24 series PICS, that have 4 UARTS each (3 for their own purpose, the fourth as comm between the two pics).

As all of you have mentioned at one point or another, cost is of extreme importance, so this seems like the best option so far. All of the external UART chips become rather expensive when you need 6 channels.

Having explained that, perhaps some of you may be able to offer a more attractive solution?
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Wed Feb 29, 2012 12:27 pm     Reply with quote

Yes and No. The CCS compiler make it relatively easy to migrate from PIC16 to PIC18 to PIC24.

Unfortunately there is no CCS PIC32 compiler option. The PIC32 supports 6 UARTS and is a powerful processor. Faced with your same task, I would look at it however if you do then you would need to use the Microchip C32 compiler.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
temtronic



Joined: 01 Jul 2010
Posts: 9162
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Feb 29, 2012 12:59 pm     Reply with quote

6 serial ports is one thing, but at what SPEED ??? Also how they are configured( eg.5 as inputs----> 1 output, 3 in:3 out,anyone to anyone) ?
Is there a 'master' or are they all? Collisions !!!
Also the amount of data that they have to process is important as well as flow. Small chunks of data or streams of hundreds of bytes ?
Others can probably think of 100 or more questions to ask, details to 'iron out' !
osu1177



Joined: 10 Feb 2011
Posts: 14

View user's profile Send private message

PostPosted: Wed Feb 29, 2012 5:19 pm     Reply with quote

9600 baud (though this can be changed), small data chunks

full duplex, asynchronous communication is a must (to answer your master/slave question)

the buffer size required is only 1 to 2 bytes for now...so we are not dealing with large amounts of buffered memory

Right now I am leaning towards 2 24 series PICS, each of which have 4 UARTS, 3 on each one for external comm, and 1 on each one to communicate between PICS....
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Wed Feb 29, 2012 6:22 pm     Reply with quote

DO YOU HAVE CTS -RTS hardware handshaking possible on the remote RS-232 devices?

if you answer YES -
then you can do a LOT of clever stuff with fewer serial ports ports than you think you need now .
osu1177



Joined: 10 Feb 2011
Posts: 14

View user's profile Send private message

PostPosted: Thu Mar 01, 2012 9:50 am     Reply with quote

asmboy- I was able to find a few UART's with 2 channels that contain transmit and receive ready functions built into the hardware, but I do not yet see how I can use these for 6 channels. Are you talking about multiplexing the 2 channels into 6?
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Thu Mar 01, 2012 2:14 pm     Reply with quote

- you CAN share a single serial port with various devices by using

1- hardware handshaking ala RTS-CTS
2- multiplexing the TX - RX line

Thus a single RS-232 port can allocate time windows when it allows
each slave, by turns - one at a time - to exclusively talk and receive ,
- ALL in a time slot that your program chooses.

B U T -- for this to work however - any rs-232 clients must be able to work with CTS-RTS handshaking control.

You can MUX select your master pic RX channel with a set of latches
that let only ONE slave at a time talk to a single shared UART.

if your slaves do are not capable of "holding off" transmit - then you WILL need individual UARTS .

devices that CAN usually work with RTS-CTS :
printers && PCS and modems

devices that CAN'T:

streaming data services (ala stock tickers )
and sattelite delivered Reuters News data


READ about CTS RTS handshaking to get the idea
asmallri



Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Thu Mar 01, 2012 5:00 pm     Reply with quote

osu1177 wrote:
9600 baud (though this can be changed), small data chunks

full duplex, asynchronous communication is a must (to answer your master/slave question)

the buffer size required is only 1 to 2 bytes for now...so we are not dealing with large amounts of buffered memory

Right now I am leaning towards 2 24 series PICS, each of which have 4 UARTS, 3 on each one for external comm, and 1 on each one to communicate between PICS....


9600 baud is very slow. It is easy, especially with a PIC24, to implement multiple 9600 baud, timer interrupt driven, full duplex software UARTs. It could be done with a single timer. Unless you have some other reason for using two PICs, I would use a single PIC24 to handle all 8 UARTs.

Alternatively you could add a pair of MAX3110E or MAX3111E or equivalent. These are dual slave UARTs with RS232 line drivers than connect to the PIC via the SPI bus.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Thu Mar 01, 2012 5:08 pm     Reply with quote

your problem CAN surely be resolved in one of several ways -

BUT
you need to reveal WHAT you rs-232 Clients ARE
if we are going to be able to help you figure that out.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group