|
|
View previous topic :: View next topic |
Author |
Message |
John P
Joined: 17 Sep 2003 Posts: 331
|
Support for PIC16F1454/5/9? |
Posted: Fri May 31, 2013 7:08 am |
|
|
I'm getting interested in the above named chips. As the PIC16F1459, it has the same pinout as the PIC16F690 which I already use, but it has all kinds of improved features, including USB, and the chip can adjust its internal oscillator to match the incoming USB signal, so it can be accurate enough for USB without needing a crystal. Then it is fast, up to 48MHz, and has two memory pointers and a much larger RAM space and several new instructions. And it costs less than $2.
I'm wondering if anyone has used these chips, and what the support from the CCS compiler is like. Does it make use of the recent additions? And is the PIC16F1459, even if it's loaded with good features, basically a dead end because everyone has moved to the PIC18F's or better? I'm way overdue for a new compiler, but I was thinking it might be time to leave the PIC16F behind, and I'm wavering.
Edited to say, I could buy a few of the chips and take CCS up on its generous offer of a full-featured compiler good for 45 days (but without most of the code examples) and then I could see for myself how it works. Maybe I'll do that. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Fri May 31, 2013 9:10 am |
|
|
The big problem is the small amount of ROM.
USB is bulky. Even on the 18F4550, many people find the stack uses more ROM than is really comfortable. It works much better on chips like the 18F26J50. I'd suspect the code would be fine for a simple HID device, so ideal for a basic keyboard/joystick type setup, but if you want to do very much more, then it's a lot easier with the larger chips.
The fact you are talking about the number of available peripherals, suggests this might apply.
Some of the 18F chips also have the USB clock PLL (where you can use the internal oscillator, and lock onto the USB clock). The 18F25K50 for example.
You are going to lose pins for the USB, and have to layout new boards to make these connections anyway. Pricing is basically the same.
I really would suspect these chips are aimed at things like building mice/keyboards etc..
Best Wishes |
|
|
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Sat Jun 01, 2013 8:03 am |
|
|
Now that you point the memory issue out, I'm realizing that my projects are typically small ones. That must be true if I haven't outgrown the PIC16 series!
As for USB, if I'm able to get that feature of the chip working, it would be with someone else's code, not mine. I've used the FTDI interface ICs and they do work well, but if I could eliminate a chip, it's a fine thing to do.
One other feature of the PIC16F1459 is that it does automatic context saving during interrupts, for the key registers that you always have to save. Then inspection of your code would tell you which other registers need to be saved; maybe none. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Sat Jun 01, 2013 8:29 am |
|
|
Quote: | I could eliminate a chip, |
while losing a chip is certainly cost effective,
depending on the level of performance you after
in a given design, the FTDI USB chip can be worth
every extra $ you spend.
I have never fielded a USB design using PIC native support.
100% FTDI connected and never regretted. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
Re: Support for PIC16F1454/5/9? |
Posted: Sat Jun 01, 2013 9:09 am |
|
|
John P wrote: | And is the PIC16F1459, even if it's loaded with good features, basically a dead end because everyone has moved to the PIC18F's or better? | I prefer the PIC18s over the PIC16s because the PIC18 usually has:
- Larger RAM
- Larger ROM
- Linear addressing mode on the RAM (no RAM bank switching)
- an 8x8 hardware multiplier
- A latch register on the I/O ports avoiding the infamous read-modify-write problems of the PIC16
- more (16-bit) timers
- More assembly instructions, allowing for faster code execution in some situations.
- Higher clock frequencies (PIC18 used to go up to 40MHz and PIC16 to 20/25MHz. Newer PIC18s go up to 64MHz and PIC16 to 48MHz).
- Automatic save of 3 registers on entering interrupt routine.
- Some other reasons I just can't remember right now.
So, I always asked myself the reversed question: why are people using the PIC16s? Price difference is often minimal so that can't be the main reason. The only reason I could think of is size; the PIC16 has a larger range of products in the 20- and lower pin counts than the PIC18 series.
I have to say that the new PIC16 products are reducing the differences between the two product lines. Your referenced PIC16F1459 has 1024 bytes of linear RAM, that is very different from the classic PIC16 with maximum 384 bytes (or something like that) of banked RAM. The new PIC16s also have the Latch register to fix the read-modify-write problem also have an extended instruction set removing many of the old limitations.
The main differences to PIC18 now seem to be that the PIC18 is more high performance targeted with an even more powerful instruction set, hardware 8x8 multiplier and more resources. But the gap between the two families is getting smaller.
I would say, choose two or three powerful chips to be used in all your products. This means you'll be using a chip that's overrated for the task at hand but it has many advantages to limit yourself to a few chip types.
I never used USB in my products, but from other posts in this forum I've learned that the FTDI chips are much quicker in getting you a working product than trying to use a PIC with internal USB. So consider for yourself what is more important: saving two dollars on components or a few weeks debugging to get the USB bus working reliable. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Sat Jun 01, 2013 9:23 am |
|
|
The automatic context saving, is a feature that has been on the PIC18 for ages. Only about 1/10th the registers needed....
Since USB itself uses interrupts, and does things like accessing memory arrays, the registers needing to be saved, goes up rather than down.
You are underestimating just how large even the smallest USB code is. A simple HID compiled for these chips, uses over 90% of the ROM....
Something like the PIC18 I mentioned, is much more likely to give a successful project. Or even better go for something like the 26J50, and gain second serial port, second I2C, CTMU, RTCC, with many of the peripherals re-locatable as well.
Best Wishes |
|
|
guy
Joined: 21 Oct 2005 Posts: 297
|
...and probably buggy |
Posted: Sun Jan 04, 2015 3:01 pm |
|
|
I'm always a wise guy - I tried to implement MD5 encryption on the 16F1454 and 16F1459 . It fits in memory (!) but when I use MPLAB simulator I see that the math routines have bugs. I recompile it for PIC18F24K20 and it works well.
Although I can't be sure if it's the simulator's fault or the compiler's I have my hunch but I don't plan to base my design on the PIC16F145x so I'll never know for sure.
Treat those parts with caution (and the dev. tools). |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9244 Location: Greensville,Ontario
|
|
Posted: Sun Jan 04, 2015 4:08 pm |
|
|
re: internal vs external USB
Since you can now buy USB<>TTL modules for $2, <10 qty, I went that route. Heck you need the connector,couple resistors,maybe an LED so from a hardware cost it's not that much more(and D+D- are wired correctly(don't ask...)) Also USB code on a PIC can be large. On a 4550 project it consumed 1/3 of memory! 'Offloading' USB to a module freed up that space for more 'real code'. And some I/O pins are USB function ONLY,gotta read the data sheet twice to see that!!
Just something to think about
That being said I did order some samples of some 20pin USBed PIC the other day just to play with....
Jay |
|
|
|
|
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
|