PIC16F648A Works!

I ordered a bunch of these chips to test with, since someone mentioned on the forums here that they are identical to the 16F628A's that we are currently using on the universal boards. I programmed them with the firmware from sourceforge (no recompiling) then plugged the x axis firmware into the board, wired it all up, and turned it on.

Bingo! It worked like a charm. It talked with the host controller, moved the motor, and everything worked great. Its good to know we have room to grow w/ regards to the firmware size.

Yup. Now you've got some memory elbow room, something that the 16F628A was chronically short of. That's great!

Can someone give me a sanity check here? It just didn't sound right that a fairly simple bit of firmware could eat up all of the RAM on one of these PICs. The three comm buffers take up 48, and I don't see how the rest of the variables scattered around could eat up the remaining space, even if the compiler didn't overlay them.

I looked at the map file and it seems it puts all the normal variables in bank 0 (0x20 to 0x7f) and the three big buffers in bank 2 (0x120 to 0x14f), but there's nothing in bank 1 (0xa0 to 0xef). I think we've still got 80 bytes of memory sitting there unused. If that's the case, the real problem is the compiler/linker doesn't know how to access memory in other banks properly. I'm not sure why the buffers work, maybe it always uses indirect memory access for arrays?

I'm completely new to SDCC, am I misreading the map files?

Can't answer your question emf, but I can drop statistics on the two chips:

(Basically the PIC16F648A has twice the program memory, twice the EEPROM, and approx 14% more RAM).


PIC16F628A (existing):

Volume Price: $1.29
Architecture: 8bit
Program Memory Type: Standard Flash
KBytes: 3.5
KWords: 2
Self-write: --
Data EEPROM: 128 bytes
RAM: 224 bytes
IO: 16
ADC channels: 0
Comparators: 2
Timers/WDT: 2 8-bit, 1 16-bit, Yes
HW RTCC: No
Interface: AUSART
Max Speed (Mhz): 20
Int Oscillator (Mhz): 4
ISCP: Yes
BOR: BOR
LVD: None
CCP/EECP: 1/0
Nanowatt: Yes
Vdd Min: 2
Vdd Max: 5.5
Pin Count: 18

Packages:
18/PDIP
18/SOIC 300mil
20/SSOP 208mil
28/QFN



PIC16F648A (very nice !!)


Volume Price: $1.47
Architecture: 8-bit
Program Memory Type: Standard Flash
KBytes: 7
KWords: 4
Self-write: --
Data EEPROM: 256 bytes
RAM: 256 bytes
IO: 16
ADC channels: 0
ADC bit: 10-bit
Comparators: 2
Timers/WDT: 2 8-bit, 1 16-bit, Yes
HW RTCC: No
Interface: AUSART
Max Speed (Mhz): 20
Int Oscillator (Mhz): 4
ISCP: Yes
BOR: BOR
LVD: None
CCP/EECP: 1/0
Nanowatt: Yes
Vdd Min: 2
Vdd Max: 5.5
Pin Count: 18

Packages:
18/PDIP
18/SOIC 300mil
20/SSOP 208mil
28/QFN



[www.microchip.com]〈=en&pageId=74

Edited 1 time(s). Last edit at 07/05/2007 05:01PM by savecore.

Don't get me wrong, I'm don't have any problem with making the '684 a recommended or even required update. I just want to make sure it helps. Some of the messages make it sound like we've used every byte of RAM and we'll be forced to upgrade to add any more features. From my read of the map file, we've used 2/3 of the RAM and about 3/4 of the program memory (I only looked at the stepper firmware). Just trying to make sure we really need the space, and that we're not being limited by a compiler bug or something like that.

i wish i knew enough to comment on the memory issue, but we should definitely move up to the 16F648A regardless. its obviously superior, pin-identical, and only costs $0.20 more. even if we dont use the extra space, its nice to have it there for future growth in v1.0

also, i changed the BOM to suggest it =)

The 16F Pic's really cheese pare with you on RAM. They also have a very short interrupt stack with no diagnostic bits that let you know when you have an overflow. That's just incredibly dangerous. I think you need to think about shifting up to the 18F family when you do Darwin 1.1 or 2.0 and save yourself a lot of grief both immediately and down the line. Some of the 18F chips are running around the same price as the 16F628A and 16F648 chips.

I agree with everything here. Almost all of the PICs seem remarkably stingy on RAM for all of the other features they provide (although this one seems to have a lot more EEPROM than I would have expected). If there were a pin-compatible 18 series chip I'd say it's a no-brainer, especially since we're programming in C. Even the small dsPICs are in the $3 range -- they could be worth considering for their gcc support alone. The few 18Fs and dsPIC30s I checked didn't match up.

I'm glad you made the 648 the default. If we end up upgrading, it'll save a lot of people a lot of trouble.

I looked at it a little more last night, and I'm becoming more convinced that there's a lot of room left on the 628, we just need to jump through some hoops to get at it (split up files & change declarations, hope the linker places things intelligently). I don't actually need the space myself, so I'm going to leave it at that.

It seems to me to make sense to upgrade the BOM to PIC16F648A since it is a drop-in replacement, and is only slightly more expensive. Plus it doubles memory, a precious commodity in any embedded system.

----

As for v1.x or 2nd gen technology , I personally prefer the dsPIC, depending on how system requirements begin to manifest themselves in practice. As a counterargument, it may turn out the dsPIC is not justified by system requirements (ie overkill). Time will tell. But if future development suggest the advantages outweigh the costs, the dsPIC is clearly a superior chip.

What I mean is this: If the project outgrows the PIC16Fxxxx architecture, instead of migrating to PIC18Fxxxx, I suggest moving directly to the dsPIC30 family of microcontrollers.

[www.microchip.com]〈=en&pageId=75


dsPIC overview

Advantages:
-16-bit architecture
-dsPIC offers more flexible bus interface capability via UART, SPI, I2C, and CAN.
-built in multi channel PWM capability (can directly control one or more stepper motors with minimal code, via pulse width modulation pins)
-much more memory and I/O (up to 8192 bytes RAM, 4096 bytes EEPROM, 144kb program memory)
-30mhz CPU speed instead of 20mhz
-wayy more internal timers!

Disadvantages:
-price is $3 - $7, instead of $1 - $3
-requires resdesign of existing electronics (ie not a drop in replacement)
-might be overkill depending on developments over the next 18-24months.


The dsPIC is a nice platform. The question is basically will it be necessary?


The existing system is working, is stable, and no hard limit has yet been encountered.

So the real question becomes... What limits (regarding microcontroller hardware) are we expecting to encounter within the next 18-24 months?

Those dsPIC's look pretty good. Given my experience with the 16F877A I'd want to se a dual channel PWM arrangement on a PIC actually working before I bought it this time around.

For me, two issues come up. First, the question of a 16 bit compiler that can be had at something less than a bankrupting price and second, the question of packaging. Relatively few of these chips are available in PDIP cans.

The base compiler is GNU actually, downloadable for free from their support tools web site.

[www.microchip.com]∂=SW006012

Few ARE in PDIP format, yes. Well, at least the more capable chips. There's about 20 variants that come in a DIP package and run at 5V. Most are thankfully motor control varieties. This generally means that you will have 3 PWM pin pairs that are specific to motor control (same time base). If you need a simple PWM set (you're probably already using one on your 18F's) there's another two to four PWM/output compare pins available. A good target is the 3010. 28 pins and all the features you could want (specifically flash space) without some of the extras that you don't need (quad encoder interface, CAN).

My personal preference in DIP format is the 4011, but that's a much larger chip (DIP 40/600mil).

Edited 1 time(s). Last edit at 07/06/2007 04:40PM by SOI Sentinel.

"If you need a simple PWM set (you're probably already using one on your 18F's)"

Nope.

8-bit PICs:

PIC16F628A: no PWM channels
PIC16F648A: no PWM channels
PIC16F877A: 2 PWM channels, 10 PWM bits
PIC18xxxxx: depends


16-bit dsPICs

dsPIC30: can be 0, 4, 6, or 8 motor control channels
dsPIC33: either 0, 6, or 8 motor control channels

The current GNU sources for the dsPIC GCC variant (microchip doesn't seem to want people to know "their" C compiler is really GCC, so they can charge $$$ for it) are downloadable from [ww1.microchip.com] . I have not (yet?) tried to compile them.

See [www.rpc-engineering.de] for a (very Windows-specific) description of the process.

Jonathan

I have a friend at work who has extensive experience with dsPIC and has used a *nix platform and gcc to compile code for dsPIC. I will post more when I find out details.

Okay, I have confirmed the C30 is basically a hacked GCC . You can download C30 compiler for free, but it will only compile at high optimization for 60 days. After 60 days , you may see your code grow as the compiler defaults back to a lower optimization level.

You can download and recompile the compiler (C30) to get around the 60 day limitation, and then you will have a fully functioning high optimization compiler forever and ever, amen. You could also buy the compiler for approx $900, but that would mean you lose the respect of your friends, family, and dog.

Programming and debugging can be done via the ICD2, which is a hockey puck shaped thing which uses a couple of pins on the dsPIC to allow you to set breakpoints and debug from the MPLAB IDE.

savecore

I do not know if you can serially program the dsPICs like you can the 16Fs and 18Fs. Check your favorite package.

I personally have an ICD2 from Sparkfun electronics. It's cheaper than the official and does not need that annoying phone jack hardware.

They also have a "light" version, see here:

[www.sparkfun.com]

savecore Wrote:
-------------------------------------------------------
> 8-bit PICs:
>
> PIC16F628A: no PWM channels
> PIC16F648A: no PWM channels
> PIC16F877A: 2 PWM channels, 10 PWM bits
> PIC18xxxxx: depends
>
>
> 16-bit dsPICs
>
> dsPIC30: can be 0, 4, 6, or 8 motor control
> channels
> dsPIC33: either 0, 6, or 8 motor control channels

Hi Everybody;

I have a problem with a PIC16LF648A, I cant read it, I m using a chipmax
device programmer, when I "read" the pic, in the hex/bin editor just is
displayed 0s no true data, How I can get the code from pic because i need
to check the code.

Thanks in advance.


Forrest Higgs Wrote:
-------------------------------------------------------
> The 16F Pic's really cheese pare with you on RAM.
> They also have a very short interrupt stack with
> no diagnostic bits that let you know when you have
> an overflow. That's just incredibly dangerous. I
> think you need to think about shifting up to the
> 18F family when you do Darwin 1.1 or 2.0 and save
> yourself a lot of grief both immediately and down
> the line. Some of the 18F chips are running
> around the same price as the 16F628A and 16F648
> chips.

If the security fuse is blown then you cant read it.

---

[www.hydraraptor.blogspot.com]

Hey. A smiling face is half the meal.
I am from Sweden and learning to read in English, tell me right I wrote the following sentence: "Directory of airport services and frequent flyer programs."

Thank you very much . Velika.