View previous topic :: View next topic |
Author |
Message |
rjenkinsgb
Joined: 03 Apr 2018 Posts: 4
|
Dual-core dsPIC just released - dsPIC33CH |
Posted: Fri Jul 13, 2018 4:58 am |
|
|
Hi all,
just seen the announcement of a new dual-core dsPIC series!
dsPIC33CH
A 90MHz main core and a 100MHz slave core, each with their own peripherals.
They look really nice for designs that need both continuous time-critical actions and slower comms like I2C that can cause timing errors in a single CPU.
http://www.microchip.com/design-centers/16-bit/products/dspic33ch
I will be looking forward to support for these in PCD. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sun Jul 15, 2018 1:34 pm |
|
|
I'd love to play with one too, but I cringe to think of the errata. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Sun Jul 15, 2018 11:01 pm |
|
|
Multi-core programming would require a lot beyond CCS.
C has no native support for multi-threading. There would need to be a platform under the language to support the threading, and this is going to be a lot of work.....
However this is not a multi-core processor in the normal sense, but just dual chips, in one package, with a communication/sync system (a multi-core would be sharing the resources, the description implies these don't).
Key part of description "dual independant cores'. Actually two processors with a communication FIFO, sharing the I/O pins.
There are errata already published for the chips. The UART has a lot of problems. A couple of quite nasty ones with I2C, and the same clock switching one as some of the other PIC33's. It is quite 'odd' actually. I have in the past designed processor cores, and one of the things done it to use 'library' parts. Now you still get occasional issues when the specifics of your system generate an unexpected timing, but in general once there is a working peripheral, this is used throughout the later chips, and works. MicroChip seem to design working peripherals, and then not use these on later chips, or keep using libraries that they know have issues. Strange... |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Mon Jul 16, 2018 5:13 am |
|
|
This seems to be one of those 'looks great on a napkin' ideas, comes to life..and ..oopsy ! Sounds good but the reality is it'd be cheaper to just use two KNOWN PICs on the same PCB. Hate to think of the man YEARS involved in getting it to work, let alone BETTER than 2 PICs on a PCB.
Even if CCS did support it, yeesh just think of the headaches when your code doesn't work. Hmm is it PIC 'A' or PIC 'B' that is the problem ?
OK, I'm old but I'll lay odds a good code cutter can get 2 PICS to work as well as (or better) than this 2-in-1 PIC.
I'll put this in the same catagory as TPMS(Tire Pressure Monitor Sensor) technology, nice but not required.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
drolleman
Joined: 03 Feb 2011 Posts: 116
|
|
Posted: Fri Jul 20, 2018 9:35 pm |
|
|
I haven't ever developed an system that worked out of the gate yet. So give them a chance to get it working. I've had 4 ep processors on one board, after lengthy debugging it worked on two ep's. I regularly do multithreading (love that), I would love two processors on one chip. easier to connect, than two separate chips.
dave |
|
![](templates/subSilver/images/spacer.gif) |
rjenkinsgb
Joined: 03 Apr 2018 Posts: 4
|
|
Posted: Sat Jul 21, 2018 1:23 am |
|
|
Ttelmah wrote: | Multi-core programming would require a lot beyond CCS.
C has no native support for multi-threading. There would need to be a platform under the language to support the threading, and this is going to be a lot of work.....
However this is not a multi-core processor in the normal sense, but just dual chips, in one package, with a communication/sync system (a multi-core would be sharing the resources, the description implies these don't).
Key part of description "dual independant cores'. Actually two processors with a communication FIFO, sharing the I/O pins.
There are errata already published for the chips. The UART has a lot of problems. A couple of quite nasty ones with I2C, and the same clock switching one as some of the other PIC33's. It is quite 'odd' actually. I have in the past designed processor cores, and one of the things done it to use 'library' parts. Now you still get occasional issues when the specifics of your system generate an unexpected timing, but in general once there is a working peripheral, this is used throughout the later chips, and works. MicroChip seem to design working peripherals, and then not use these on later chips, or keep using libraries that they know have issues. Strange... |
It's not a "threading" system - it has two totally independent cores that are programmed completely separately, but on a single chip with inter-core communications.
Each has access to a different selection of peripherals, so one can eg. do time-critical work and the other do communications or user interfacing like display and keyboard.
No undue problems, just the ability to use two CPUs without the hardware complexities of external dual-port RAM etc.
And you can still run a debugger on each core separately (or even two debug systems at the same time) so no problem figuring out which side has the problem when getting something working, any more than with two separate chips.
CCS only need to support the series as two totally separate new devices.
Everything else is down to the system designer, as when using two or more separate CPUs anyway. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Sat Jul 21, 2018 3:25 am |
|
|
Er. That is exactly what I said!.....
Quote: |
However this is not a multi-core processor in the normal sense, but just dual chips, in one package, with a communication/sync system (a multi-core would be sharing the resources, the description implies these don't).
Key part of description "dual independant cores'. Actually two processors with a communication FIFO, sharing the I/O pins.
|
That's a case of not actually reading what you are quoting.
The big question is going to be how reliable it actually proves to be. That they have so many errata already, and some quite major, rather reduces the utility of the chips. MicroChip have got really bad at fixing errata in recent years, with some chips on their fourth revision still having most of the problems from the first prototype release.
![Sad](images/smiles/icon_sad.gif) |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sat Jul 21, 2018 9:19 am |
|
|
Ttelmah wrote: | MicroChip have got really bad at fixing errata in recent years, with some chips on their fourth revision still having most of the problems from the first prototype release.
![Sad](images/smiles/icon_sad.gif) |
Wonder if Microchip has grown to be too big too quickly. Fixing things usually falls to the most experienced people and I have a feeling they're "experience poor" at the moment. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Sat Jul 21, 2018 9:44 am |
|
|
Well if you think about it most of us 'old guys' are retired... PICs came out 1/2 my lifetime ago...sigh
I've never understood WHY a company 'needs' 1000+ 'variations on a theme', better to stick with a few and improve as required. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Thu Mar 07, 2019 4:00 pm |
|
|
I just noticed in the recent CCS update email.
I've been buring off in FPGA/ARM SoC land for the last several years....
Interesting indeed.
So many toys -- so little time... _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Fri Mar 08, 2019 7:03 am |
|
|
I wonder if a lot of these 'new PICs' are custom ones requested by big volume customers ?
I got some samples of the 10F222 as I only needed 2in-2out, go to test and THEN discover NO timer interrupt ! Yeesh, I can't recall any PIC not having T0INT.
Oh well.... |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Fri Mar 08, 2019 8:12 am |
|
|
That is actually the "raison d'etra" of 99% of PIC's.
Microchip offer a service, where if you are buying significant numbers
you basically choose the features you want, and they do a custom
chip for you. I've done it twice. As part of this you get a much lower
price if you agree to the chip being distributed afterwards. Hence most
are. It's also much cheaper if the peripherals are ones they already offer.
This is why so many PIC's have what seem to be quite 'strange'
peripheral mixes. Depending then on the 'core' you choose, some
parts come included in the core (Timers CCP etc.). |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Fri Mar 08, 2019 8:51 am |
|
|
Well sure -- Microchip cranks device after device based on a given set of pluggable IP (I think I heard it was VHDL.)
They're not the only ones.
To offer that library for custom-spin parts to paying customers only makes sense.
It's as easy as making brownies. Just describe the recipe, add the ingredients, send off to the ASIC fab and wait for the timer to go off and the brownies to be delivered!
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
jeremiah
Joined: 20 Jul 2010 Posts: 1329
|
|
Posted: Sun Mar 10, 2019 9:12 pm |
|
|
I'm curious how CCS would handle multicore considering the calling convention they use on functions. Since locals and function parameters are giving specific memory addresses, that prevents different cores from using the same function at the same time (or you would clobber your vars). I mean, we can always work around it with duplicate functions, but that eats up flash. |
|
![](templates/subSilver/images/spacer.gif) |
bkamen
Joined: 07 Jan 2004 Posts: 1611 Location: Central Illinois, USA
|
|
Posted: Mon Mar 11, 2019 12:32 am |
|
|
jeremiah wrote: | I'm curious how CCS would handle multicore considering the calling convention they use on functions. Since locals and function parameters are giving specific memory addresses, that prevents different cores from using the same function at the same time (or you would clobber your vars). I mean, we can always work around it with duplicate functions, but that eats up flash. |
Considering each core is independent of the other... I don't see a problem.
Look at the first page of one of the datasheets:
Code: |
Core: Dual 16-Bit dsPIC33CH CPU
Master/Slave Core Operation
Independent Peripherals for Master Core and
Slave Core
Dual Partition for Slave PRAM LiveUpdate
Configurable Shared Resources for Master Core
and Slave Core
Master Core with 64-128 Kbytes of Program
Flash with ECC and 16K RAM
Slave Core with 24 Kbytes of Program RAM
(PRAM) with ECC and 4K Data Memory RAM
Fast 6-Cycle Divide
Message Boxes and FIFO to Communicate
Between Master and Slave (MSI)
Code Efficient (C and Assembly) Architecture
40-Bit Wide Accumulators
Single-Cycle (MAC/MPY) with Dual Data Fetch
Single-Cycle, Mixed-Sign MUL Plus Hardware
Divide
32-Bit Multiply Support
Five Sets of Interrupt Context Selected Registers
and Accumulators per Core for Fast Interrupt
Response
Zero Overhead Looping
|
_________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
![](templates/subSilver/images/spacer.gif) |
|