Author Topic: Pic Controllers  (Read 7590 times)

0 Members and 1 Guest are viewing this topic.

Offline CameronHanson20Topic starter

  • Contributor
  • Posts: 11
Pic Controllers
« on: February 25, 2015, 05:59:37 pm »
Hello everyone,
I have a pic16f690 microcontroller. I am looking to see if it has multiple cores? I have looked through the entire data sheet and it doesnt realy say anything about multiple cores. It only says it has the pic core architecture.
 

Offline katzohki

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: Pic Controllers
« Reply #1 on: February 25, 2015, 06:07:06 pm »
Nope. Single "core," but really that's not a way to look at the PIC. It's not meant to be used like a computer CPU.

Edit: See page 15 of the datasheet (PIC16F690 Block Diagram) to get an idea of what is really inside the PIC and its architecture.
« Last Edit: February 25, 2015, 06:08:41 pm by katzohki »
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2254
  • Country: ca
Re: Pic Controllers
« Reply #2 on: February 25, 2015, 08:18:17 pm »
Nope, the PIC is a pretty standard microcontroller; one processing core and a bunch of special purpose peripherals to do all kinds of I/O tasks.

If you want a true multi-core microcontroller, look at the Parallax Propeller. That's the only one that I know of. It is eight, 32-bit cores running at 20 MIPS for 160 MIPS of total processing power. It's drawback is the lack of peripherals; they need to be implemented in software.
 

Offline picandmix

  • Frequent Contributor
  • **
  • Posts: 395
  • Country: gb
Re: Pic Controllers
« Reply #3 on: February 25, 2015, 09:02:06 pm »
Not a true 'micro',  but user programmable in the same manner, the new Raspberry Pi Quad core.
 

Offline jlmoon

  • Supporter
  • ****
  • Posts: 609
  • Country: us
  • If you fail the first time, keep trying!
Re: Pic Controllers
« Reply #4 on: February 25, 2015, 09:22:49 pm »
Why would anyone want multiple cores in a uController?  I would think multiple cores would just add layers of complexity to what was originally intended to do simple task.  What happen to the days of good oldschool bit banging with one step above machine code... Assembly language? 
Recharged Volt-Nut
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: Pic Controllers
« Reply #5 on: February 25, 2015, 09:51:18 pm »
multi processor PIC  :o forget about it , i looked once for a µC with double core , freescale have some of that
 

Offline CameronHanson20Topic starter

  • Contributor
  • Posts: 11
Re: Pic Controllers
« Reply #6 on: February 26, 2015, 12:47:16 am »
The reason is that im trying to make a motor controller that accepts a 0-2ms pulse. The problem is, is that the out put would be ignored when the pulse is being measured. I dont know how to hyperthread and I figured a multicore micro would make it easier because one core would accept and convert the pulse and another core would handle the output. I looked at propeller and that was my first thought, but its too large to fit in the space I have. I only have enough space for a 20 pin chip.
 

Offline Hideki

  • Frequent Contributor
  • **
  • Posts: 256
  • Country: no
Re: Pic Controllers
« Reply #7 on: February 26, 2015, 01:23:32 am »
You are talking about a microcontroller as if it was a big powerful intel processor. It's not and the difference is rather extreme.

Hyperthreading? It doesn't have that. It doesn't have threads either, unless you run some kind of RTOS that implements a thread-like system in software.

You can do the timing measurement by generating an interrupt when the pulse input changes, then read out the values of a hardware timer. Depending on the chip, it might even be able to gate the timer for you, so that it resets at the beginning of the pulse and stops counting at the end. In the mean time you can do whatever you like in the main loop of your program while the hardware handles the measurement part.
 

Offline CameronHanson20Topic starter

  • Contributor
  • Posts: 11
Re: Pic Controllers
« Reply #8 on: February 26, 2015, 01:50:08 am »
I didnt think about using the harware timers, thank you. Making this work should be much easier now
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: au
Re: Pic Controllers
« Reply #9 on: February 26, 2015, 03:24:06 am »
I looked at propeller and that was my first thought, but its too large to fit in the space I have.

The Propeller is *cool*, but after spending 4 years on it I quickly discovered that almost anything I could do on that I could do on a PIC for ~15% of the price. That and Parallax would not provide nor assist in non-windows based tools leading me to reverse engineer their compiler and write my own, I gave up and went back to products from real semiconductor companies that support their users.

PIC's are easy, versatile and best of all *cheap*. If you can't do it with a pic then you are either working on an extraordinarily complex task, or you are doing it wrong.
 

Offline BlueBill

  • Regular Contributor
  • *
  • Posts: 169
  • Country: ca
Re: Pic Controllers
« Reply #10 on: February 26, 2015, 04:03:47 am »
PIC's are easy, versatile and best of all *cheap*. If you can't do it with a pic then you are either working on an extraordinarily complex task, or you are doing it wrong.

From tiny 6pin devices to powerful MIPS32 based units.
 

Offline jlmoon

  • Supporter
  • ****
  • Posts: 609
  • Country: us
  • If you fail the first time, keep trying!
Re: Pic Controllers
« Reply #11 on: February 26, 2015, 04:06:30 am »
A micro controller is nothing more than a state machine with some decent I/O and pretty good interrupt & timer system.
Recharged Volt-Nut
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 3442
  • Country: us
Re: Pic Controllers
« Reply #12 on: February 26, 2015, 04:48:51 am »
There is always the alternative of implementing it with two MCUs and let them talk to each other via GPIO.
 

Offline lapm

  • Frequent Contributor
  • **
  • Posts: 564
  • Country: fi
Re: Pic Controllers
« Reply #13 on: February 26, 2015, 10:45:16 am »
To get multicore PIC you would have to go route of ardusat . In other words, several chips in same board...
Electronics, Linux, Programming, Science... im interested all of it...
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2254
  • Country: ca
Re: Pic Controllers
« Reply #14 on: February 26, 2015, 02:59:44 pm »
There is always the alternative of implementing it with two MCUs and let them talk to each other via GPIO.
Alternative to what? To doing the right way, with a hardware timer?
PICs are full of timers because they are useful for... you know, timing stuff, like making or measuring pulses.
 

Offline jlmoon

  • Supporter
  • ****
  • Posts: 609
  • Country: us
  • If you fail the first time, keep trying!
Re: Pic Controllers
« Reply #15 on: February 26, 2015, 03:28:43 pm »
Thinking a bit on this Cameron,
All you need to do is use a pin to detect that pulse, enable a timer based on the edge event of that pulse and set up a PWM function to output the result.  (Input Capture or Interrupts, Time the event, then act on said event)  Pic micros are really good at doing this type of function, personally I wouldn't suggest a series 12, 16 or 18 part due to design obsolescence.  If you want to get really fancy pick up a data sheet on a 24F part or if you should desire to employ DSP in the future.. take a look at the dsPic33F series.  The 24FJ parts might be overkill but they are cheap and the 16bit structure provides ample Input Capture functionality along with 5 timers of various form providing true 32 bit timing.  If these parts appeal to you, order one of the Explorer 16 boards which comes with a 24FJ part and lots of I/O pins and start with that. 
Recharged Volt-Nut
 

Offline glatocha

  • Regular Contributor
  • *
  • Posts: 114
Re: Pic Controllers
« Reply #16 on: February 26, 2015, 04:15:23 pm »
I didn't really understand what you want to do with the output, but your PIC has a timer1 with a gate, that allows very precise pulse length measurement. The same input has Interrupt-on-change capability so just set the interrupt, set the timer and when pulse is finished the measurement result is waiting in a timer and you get an interrupt to deal with it. All done automatically.

Additionally you got the CPU core, which is not used till now. You can process the results and set the output.
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: Pic Controllers
« Reply #17 on: February 26, 2015, 05:00:51 pm »
I looked at propeller and that was my first thought, but its too large to fit in the space I have.

The Propeller is *cool*, but after spending 4 years on it I quickly discovered that almost anything I could do on that I could do on a PIC for ~15% of the price. That and Parallax would not provide nor assist in non-windows based tools leading me to reverse engineer their compiler and write my own, I gave up and went back to products from real semiconductor companies that support their users.

PIC's are easy, versatile and best of all *cheap*. If you can't do it with a pic then you are either working on an extraordinarily complex task, or you are doing it wrong.

propgcc works fine these days, i love using the prop, but yes it is price restrictive!
-- Aussie living in the USA --
 

Offline rdl

  • Super Contributor
  • ***
  • Posts: 3667
  • Country: us
Re: Pic Controllers
« Reply #18 on: February 26, 2015, 05:04:59 pm »
These days Parallax is very open source and C programming focused. It's really too bad there's not a Prop/2 coming instead of the Propeller 2, but I'm sure there's technical reasons they haven't done that.
 

Offline katzohki

  • Frequent Contributor
  • **
  • Posts: 378
  • Country: us
    • My Blog
Re: Pic Controllers
« Reply #19 on: February 26, 2015, 06:17:05 pm »
You don't need to ignore the output while input is being measured. A/D converter will measure the input and then let you know (through an interrupt) when it is done. You can use 1 instruction to start the A/D and then interrupt and process when it's done. You can also use an interrupt to handle inputs (interrupt on change, for example).

Edit: I did not word that well at all, but I think you get the drift.

Let us know if you need more help, this sounds like the kind of thing that a lot of people have experience doing. Myself included, more or less lol.
« Last Edit: February 26, 2015, 07:48:34 pm by katzohki »
 

Offline Rick Law

  • Super Contributor
  • ***
  • Posts: 3442
  • Country: us
Re: Pic Controllers
« Reply #20 on: February 26, 2015, 06:40:10 pm »
There is always the alternative of implementing it with two MCUs and let them talk to each other via GPIO.
Alternative to what? To doing the right way, with a hardware timer?
PICs are full of timers because they are useful for... you know, timing stuff, like making or measuring pulses.

Say for example:
Option 1, I paid an extra 1 day worth of contractor to learn the right way so I have the two related application coexist on the same PC;
or
Option 2, I buy another PC for the department.

Option 2 may well be the more cost effective way.  Elegance in solution may not always be the target.  Whether the customer is the OP himself or 1 user or a bunch of users, question is: What does the customer want?  Most elegant or most "right" or most cost effective?  The OP didn't say.

So, ease in implementation using his/her existing knowledge may well be easiest/best for the OP.

Hardware is just about the cheapest solution to throw at a problem these days, it would be a shame not to evaluate that.
 

Offline BradC

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: au
Re: Pic Controllers
« Reply #21 on: February 27, 2015, 12:49:12 am »
propgcc works fine these days, i love using the prop, but yes it is price restrictive!

PropGCC? Funny, last I checked they were still using my compiler to compiler the asm stub..
 

Online hans

  • Super Contributor
  • ***
  • Posts: 1639
  • Country: nl
Re: Pic Controllers
« Reply #22 on: February 27, 2015, 09:24:49 am »
Next to the propellers you also have the LPC4300 series that have a Cortex m4 + Cortex m0 integrated.
However, those are "Application Proccesors", thus more designed for the m4 doing DSP or heavy lifting + the m0 running a protocol stack (serial, ethernet, USB, etc.) to accept commands.

If the goal is to complete multiple operations at once, you can look at interrupts obviously. They are probably the most important concept of any microcontroller, so it's important to understand them well.
A step further could be CoRoutines; where a blocking event in a coroutine will jump out , and the next time the function is called resumes operation.
This has some limitations (like you can only do the blocking-escape inside the coroutine function) nor will it make your program very debugable (IMHO), so for bigger controllers you often find RTOS installed. RTOS have a pretty severe memory burden and some performance impact, but is an "easy way" to multitask on a microcontroller.
However, I wouldn't recommended installing a RTOS on any 8-bit controller.. they are too small for it to be of any use.
 

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
Re: Pic Controllers
« Reply #23 on: February 27, 2015, 02:08:22 pm »
propgcc works fine these days, i love using the prop, but yes it is price restrictive!

PropGCC? Funny, last I checked they were still using my compiler to compiler the asm stub..

I dunno if it is or not, but if it is, next time I'm home in Melbourne I'l buy you a beer or cuppa, sounds like I owe you one for your work! ;) (unless you dont live in Melbourne). I just rarely make it home now :( wife does not want to move from usa back to aus. sigh.

-- Aussie living in the USA --
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf