View previous topic :: View next topic |
Author |
Message |
hmmpic
Joined: 09 Mar 2010 Posts: 314 Location: Denmark
|
Migrate from PIC18F26K22 to PIC18F26Q10? |
Posted: Mon May 18, 2020 2:28 am |
|
|
Migrate from PIC18F26K22 to PIC18F26Q10?
A working project is going to be updated, and then the 26K22 is to be updated to the new 26Q10. Microchip suggest the 26Q10.
I see the Errata look not so nice...?
Is there anything there go against to use the Q10 chip?
-I normally use PICKIT2 to do my programming, but the Q10 is not supported. Can it be used with some tweaks? (I use the PICKIT because it is standalone and simple to work with.)
Have anyone used the new 26Qxx without problem?
Anyone? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Mon May 18, 2020 3:25 am |
|
|
Buy the PicKit+ software. This allows the PicKit2 to program the
PIC18F26Q10.
<http://www.pickitplus.co.uk/Typesetter/>
It is only software that is needed, and this is cheap.
There is also a command line only version that is about half the
price. However the GUI is nicer.
The chip doesn't actually have many 'bad' errata (compared to a lot of
the newer chips!...). Provided you are not wanting to work as an
SPI slave.
Why change the chip?. The K22 is still very much a 'current' chip. The
advantages of the Q10, are:
Faster maximum clock (64M versus 40M).
The CLC (do you intend to use this?).
Slightly lower power consumption.
A little more peripheral flexibility (some interfaces have PPS).
The CVD (again do you intend to use this).
Otherwise it seems a waste of time and effort to change... |
|
![](templates/subSilver/images/spacer.gif) |
hmmpic
Joined: 09 Mar 2010 Posts: 314 Location: Denmark
|
|
Posted: Mon May 18, 2020 4:46 am |
|
|
Thanks for the nice information about the software, http://www.pickitplus.co.uk/Typesetter
Never understand why Microchip made the switch from the PK2 software, it was light and stable, still using it...
-About the chip, my only reason is i cant find EOL for the 26K22 it is about 10 years old, and how long will Microchip support it is? The Q10 is the new replacement for the K22 according to Microchip. But if the K22 have +5 years EOL i won't switch.
Again thanks for the link and the nice information. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Mon May 18, 2020 4:51 am |
|
|
I'm with Mr. T on this... WHY change ?? Unless you have a specific NEEDED demand for a new feature, stay with what you KNOW works.
All too often the 'new and better' PIC will have a quirk or bug that doesn't show up for months. Then is the compiler 100% reliable ? Again, an unknown 'bug' can pop up when a certain combination of features is used in a specific way.
Then there's the 'bottom line'. You've spent months if not years of R&D time and money getting the 26K22 'up and running'. While the new PIC might be a few pennies cheaper, those savings are LOST with R&D on the new PIC. I know a lot of people who don't consider R&D costs..just want the new PIC. Those costs include time to research the PIC, reading about it, ordering samples, prototype PCB, revised PCBs( oopsy...), setting up PC folders,new programmer( a hard cost), hours debugging a weird' it works on the other PIC' problems.......
You've probably got a personal folder of soild functions and drivers for your current PIC and while most ( some ?) will run on the new PIC, you'll have to try each and everyone, more time, and more money spent.
Only you KNOW what's needed for the new PIC but if 'good old reliable' works 100%, there's no need to 'upgrade'. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Mon May 18, 2020 9:19 am |
|
|
It's worth being aware that there are PIC's that are well over 20 years old,
and you can still buy them....
For example the 16F84!... Over 27 years old.
Ones that were launched five or six years before the 26K22, are in some
cases 'not recommended for new designs'.
The 'newer device available' flag is one that MicroChip raises to try to
boost the sales of the newer device, not one you need to worry about.... |
|
![](templates/subSilver/images/spacer.gif) |
AESPOSITO
Joined: 28 Jul 2020 Posts: 4 Location: Arizona
|
Q series issues? |
Posted: Tue Jul 28, 2020 1:33 pm |
|
|
any reports of Q family problems? _________________ A Esposito, CEO
Avatar Engineering Corp.
Last edited by AESPOSITO on Tue Aug 11, 2020 9:29 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Tue Jul 28, 2020 2:20 pm |
|
|
Not too sure HOW the 'Q10 serious issues' got added to the original post...
anyway..
I see a lot of us like the 46k22/26k22 and I don't see it going 'the way of the dinosaurs' in the near future. If, IF, Microchip does post the EOL for it, consider your real future demand for PICs and simple buy them now. 100, 1,000, 10,000 pieces ? Honestly it'd be money in the bank ! Designing new products using a KNOWN, RELIABLE PIC is important. Any 'new' PIC will have a few quirks and even one of them could cost you $1,000s in wasted R&D time. A small portion of that money could have been spent on buying 26K22s allowing product out the door and happy clients !
yeesh 27 years for the 16F84, been longer for the 16C71 and 16C84 then.
great now I feel even OLDER...sigh
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Thu Jul 30, 2020 6:54 am |
|
|
I've been using the 18F47Q43...not Q10, But close enough... the errata (at the time of choosing pics) was one key point... it looked quite nice IMO.
I have nothing but praise for the chip so far, and I'm making it my one size fits all PIC.
I had the same problem with the Pickit, compiler, and MPLAB. I had a Pickit 3, but hacking it vs just buying a Pickit 4 seemed economically stupid.... 30 bucks for software to fix old hardware or 54 bucks to get a Pickit 4....
HATED mplabX..... kinda love it now... weird. _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
![](templates/subSilver/images/spacer.gif) |
dluu13
Joined: 28 Sep 2018 Posts: 395 Location: Toronto, ON
|
|
Posted: Thu Jul 30, 2020 9:33 am |
|
|
I guess I'm new to the game compared to a lot of you. I've been using MPLAB X since day 1, and it has been working well for me. I wouldn't mind if it was more quick on startup though... |
|
![](templates/subSilver/images/spacer.gif) |
gaugeguy
Joined: 05 Apr 2011 Posts: 296
|
|
Posted: Thu Jul 30, 2020 11:03 am |
|
|
on the PIC18F47Q43, how are you dealing with the SRAM errata?
Quote: |
SRAM Readback
Following a device power up sequence, there is a possibility that some SRAM locations will not return the expected
written value but will read back '00' instead.
Work around
None. The device can only recover by power cycling.
|
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19358
|
|
Posted: Thu Jul 30, 2020 12:06 pm |
|
|
That is an absolutely hellish one. No recovery except POR.
How they can market the chip with that fault is inexplicable.
If a software restart of some sort would fix it, this would be easy to
handle, but as it stands, it means you would have to add hardware to
power down reset the chip. |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Fri Jul 31, 2020 6:42 am |
|
|
Well my parade seems to be ruined!
I designed, fabbed, etc my boards in april during quarentine.
Points D & E where added on June.... so the errata at the time was "clean". I cant say im happy with this surprise.
I have not encountered this issue though... or maybe i have but my application hasnt suffered from in?
So as i understand it the SRAM fault is that i may have a variable declared as:
Int foo_bar=0x0F;
At power up, it does not get properly initialized but instead it reads 00, and i cant rewrite to the proper value unless i POR?
Ugh..... please correct me if my understanding is incorrect. _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9168 Location: Greensville,Ontario
|
|
Posted: Fri Jul 31, 2020 6:49 am |
|
|
Ok, silly question/idea...
if you add the #zero_ram, does the problem go away ?
I'm at a loss to explain the 'bad RAM' problem and man that kinda scares me. I create enough 'bad numbers' without the PIC making them randomly ! |
|
![](templates/subSilver/images/spacer.gif) |
Gabriel
Joined: 03 Aug 2009 Posts: 1067 Location: Panama
|
|
Posted: Fri Jul 31, 2020 6:52 am |
|
|
I see the errata provides a test/check code but it only writes one sram address... does this mean that the entire SRAM fails to init or is it just a few random bytes and the provided code should be executed on all 8k worth of ram adresses? _________________ CCS PCM 5.078 & CCS PCH 5.093 |
|
![](templates/subSilver/images/spacer.gif) |
gaugeguy
Joined: 05 Apr 2011 Posts: 296
|
|
Posted: Fri Jul 31, 2020 8:04 am |
|
|
I only know what is in the errata sheet. The test of that one location is supposed to be done immediately on power up. If that test fails then no other code should be executed and a forever loop entered until power is removed.
I can't see how anyone can use this chip until a new revision is released with that errata fixed. No information is provided that might give a clue to the cause or extent of it. |
|
![](templates/subSilver/images/spacer.gif) |
|