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 CCS Technical Support

Dual-core dsPIC just released - dsPIC33CH
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
rjenkinsgb



Joined: 03 Apr 2018
Posts: 4

View user's profile Send private message

Dual-core dsPIC just released - dsPIC33CH
PostPosted: Fri Jul 13, 2018 4:58 am     Reply with quote

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.
newguy



Joined: 24 Jun 2004
Posts: 1908

View user's profile Send private message

PostPosted: Sun Jul 15, 2018 1:34 pm     Reply with quote

I'd love to play with one too, but I cringe to think of the errata.
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Sun Jul 15, 2018 11:01 pm     Reply with quote

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...
temtronic



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

View user's profile Send private message

PostPosted: Mon Jul 16, 2018 5:13 am     Reply with quote

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
drolleman



Joined: 03 Feb 2011
Posts: 116

View user's profile Send private message

PostPosted: Fri Jul 20, 2018 9:35 pm     Reply with quote

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
rjenkinsgb



Joined: 03 Apr 2018
Posts: 4

View user's profile Send private message

PostPosted: Sat Jul 21, 2018 1:23 am     Reply with quote

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.
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Sat Jul 21, 2018 3:25 am     Reply with quote

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
newguy



Joined: 24 Jun 2004
Posts: 1908

View user's profile Send private message

PostPosted: Sat Jul 21, 2018 9:19 am     Reply with quote

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


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.
temtronic



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

View user's profile Send private message

PostPosted: Sat Jul 21, 2018 9:44 am     Reply with quote

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.
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Thu Mar 07, 2019 4:00 pm     Reply with quote

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
temtronic



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

View user's profile Send private message

PostPosted: Fri Mar 08, 2019 7:03 am     Reply with quote

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....
Ttelmah



Joined: 11 Mar 2010
Posts: 19536

View user's profile Send private message

PostPosted: Fri Mar 08, 2019 8:12 am     Reply with quote

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.).
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Fri Mar 08, 2019 8:51 am     Reply with quote

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! Very Happy Very Happy

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
jeremiah



Joined: 20 Jul 2010
Posts: 1353

View user's profile Send private message

PostPosted: Sun Mar 10, 2019 9:12 pm     Reply with quote

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.
bkamen



Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Mon Mar 11, 2019 12:32 am     Reply with quote

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
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