PIC microcontroller

[paul30003]

Hi

I want to get more into micro controllers, I dont want to do assembly, some sort of c compiler would be nice,  Ive got some hours on Atmel's atmega328p but have hit some limitations in terms of speed, Ive been thinking about pic's and am concidering a pic development board.  I have not got a clue what type of board to go for, or IDE.  Any advice would be apreciated

Thanks

[tyblu]

the AVR8's run around 1MIPS/MHz, which is really good. You'll have to move into the dsPIC, Xmega or faster to get more performance. Personally, I'd recommend jumping straight into ARM Cortex-M3 or -M0. The LPCXpresso kit is nice. What is your speed requirements?

[scrat]

Even if a development board can be a good starting point, if you aren't really new to MCUs I'd start buying a programmer/debugger, instead, of course with a pair of MCU ICs, crystal oscillators, passives, and a breadboard. If you want to spend a little more, add a character LCD display...
This allows you to program every board, not only the one you bought.

[Mechatrommer]

Ive got some hours on Atmel's atmega328p but have hit some limitations in terms of speed

sounds funny with the sorting turned out the PIC to be the first in the list. you need something else, not PIC not C, the things that you dont want!

[Hypernova]

I recommend moving on to xmegas, it's a great all-in-one chip to learn DMA, multi level interrupts, DES/AES encryption etc. A break out board from sparkfun is only about ~$20.

At 32MIPS on the internal crystal that good enough for 921600 baud uart it would also present a decent speed upgrade.

[Psi]

Ive got some hours on Atmel's atmega328p but have hit some limitations in terms of speed

Have you turned off the CKDIV8 mode in the fuse bits?

It comes enabled by default (bit value of 0) and that means your mcu runs at 1/8 the speed of whatever clock your using.

It's a bit of a trap for new avr programmers.

[allanw]

I recommend moving on to xmegas, it's a great all-in-one chip to learn DMA, multi level interrupts, DES/AES encryption etc. A break out board from sparkfun is only about ~$20.

At 32MIPS on the internal crystal that good enough for 921600 baud uart it would also present a decent speed upgrade.

Is there any advantage of the Xmega over any of the ARM's? The availability isn't great and it's not like it's much cheaper.

[Hypernova]

I recommend moving on to xmegas, it's a great all-in-one chip to learn DMA, multi level interrupts, DES/AES encryption etc. A break out board from sparkfun is only about ~$20.

At 32MIPS on the internal crystal that good enough for 921600 baud uart it would also present a decent speed upgrade.

Is there any advantage of the Xmega over any of the ARM's? The availability isn't great and it's not like it's much cheaper.

A shit load of peripherals:
http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=2229&Direction=DESC#1965
The only thing it doesn't have are USB and CAN, but with 8x SPI it's not like you can't spare a port for external ones.

I challenge you to find another MCU that can match it on that front, the only ones that comes close are PSoC5's which aren't yet available and FPGA's, even then 128MHz PWM at 10bit resolution don't exactly grow on trees. While it won't be great with DSP stuff Cortex-M3's don't have FPU's either. And you can hook up a 16MB external ram.

[TopherTheME]

A shit load of peripherals:

How in the hell does AVR fit all that stuff into 1 chip?

[paul30003]

Hi

I want to get more into micro controllers, I dont want to do assembly, some sort of c compiler would be nice,  Ive got some hours on Atmel's atmega328p but have hit some limitations in terms of speed, Ive been thinking about pic's and am concidering a pic development board.  I have not got a clue what type of board to go for, or IDE.  Any advice would be apreciated

Thanks

Maybe the speed is not the issue with the mega328 but my programming, what i'm trying to achive is a oscillating output on one of the pins, with the arduino booloader I am using the command, digitalWrite (pin, TRUE); digitalWrite(pin, FALSE);

using a delay inbetween to set the frequency, if I want to check for inputs such as key presses, for example, then this uses clock cycles and prevents me from getting the desired frequency, maybe the problem is with my programing method rather than the micro.  I'm at work right now, so when I get home ill post up the arduino sketch and maybe so of you guys could offer me a solution.

Thanks

[scrat]

You can just use the PWM peripheral to obtain a precise oscillation, without bothering for other code delaying or anything similar. Alternatively, you can use a timer and interrupt, where you change the pin's state.

[joelby]

Arduino's digitalWrite is known to be about twenty times slower than manipulating the port directly.

There's some information and the alternative method available at http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1230286016 .

[migsantiago]

Here are some MIPS maximum speeds for each PIC family...

PIC10 1MIPS 8bit
PIC12 5MIPS 8bit
PIC16 5MIPS 8bit
PIC12/16 8MIPS 8bit (enhanced families)
PIC18 16MIPS 8bit
PIC24F 16MIPS 16bit
PIC24H 40MIPS 16bit
dsPIC30 30MIPS 16bit-dsp
dsPIC33 40MIPS 16bit-dsp
PIC32 80MIPS 32bit

On PIC32, the actual performance depends on the ROM cache implementation.

[Hypernova]

You can just use the PWM peripheral to obtain a precise oscillation, without bothering for other code delaying or anything similar. Alternatively, you can use a timer and interrupt, where you change the pin's state.

This, I got a fan controller where I read the rpm signal edges using interrupts, on every interrupt you just check the CNT register of you timer to get the elapsed time. With a 16bit timer I was sampling at 31.250KHz. Takes no more than 2us for every reading.

Code: [Select]

uint8_t RPM_zero_count[8];

void RPM_int_handler(uint8_t fan_num)
{
//PORTK.OUTTGL = PIN5_bm;
uint16_t temp = TCF0.CNT;
uint16_t time_count;
static uint16_t prev_count[8];

if(temp < prev_count[fan_num])
time_count = 0xFFFF - prev_count[fan_num] + temp;
else
time_count = temp - prev_count[fan_num];

prev_count[fan_num] = temp;
fan[fan_num].RPM_time = time_count;
RPM_zero_count[fan_num] = 0;
//PORTK.OUTTGL = PIN5_bm;
}


ISR(TCF0_OVF_vect)
{
//PORTK.OUTTGL = PIN6_bm;
for(uint8_t i=0; i<8; i++)
{
if(RPM_zero_count[i])
fan[i].RPM_time = 0;
RPM_zero_count[i] = 1;
}
//PORTK.OUTTGL = PIN6_bm;
}

ISR(PORTD_INT0_vect)
{
RPM_int_handler(2);
}

[scrat]

PIC18 12MIPS

Some PIC18 versions go to max 16 MIPS (ex. PIC18F26K20), by means of a PLL.

@Hypernova:
In interrupt routines, even if they take some time to execute, time distance between successive executions remains the same, provided that you don't use jumps to different length code branches. This is especially important for control purposes, where different sampling/refresh periods can be an issue.

[Hypernova]

PIC18 12MIPS

Some PIC18 versions go to max 16 MIPS (ex. PIC18F26K20), by means of a PLL.

@Hypernova:
In interrupt routines, even if they take some time to execute, time distance between successive executions remains the same, provided that you don't use jumps to different length code branches. This is especially important for control purposes, where different sampling/refresh periods can be an issue.

You are still going to get some jitter since the cpu needs to finish it's current instruction before jumping to ISR, if you happen to be on a two cycle instruction when the INT tripped you get a one instruction cycle jitter, I recall a thread on avrfreaks where a guy had to roll a asm routine to ensure that the ISR code deliberately delay itself a bit before starting the main section depending on how quick the ISR was reached. He was ouputing TV signals and the tiny jitter was enough to introduce noise.It's all about the amount of clock jitter you are willing to live with.

another source of jitter even when you 'enter' at constant interval is if you got higher level ISR that introduce delays as well as ISR at the same level as your current ISR. If you normally enter at time 0s and produce output at time 1s, if a 1s higher level ISR interrupt you your output get's delayed to time=3s. Your worst case jitter is the ISR time of all the ISR's at a higher level than you and any other ISR that may sit at your level too.

[jahonen]

This, I got a fan controller where I read the rpm signal edges using interrupts, on every interrupt you just check the CNT register of you timer to get the elapsed time. With a 16bit timer I was sampling at 31.250KHz. Takes no more than 2us for every reading.

Why not use the timer capture function (exact value of the timer is stored when edge is detected on capture input), that avoids the variable latency issues (although not very significant here)?

Regards,
Janne

[migsantiago]

Some PIC18 versions go to max 16 MIPS (ex. PIC18F26K20), by means of a PLL.

That's great, I didn't know there were faster PIC18s. I'm editing the post. Thanks.

[FreeThinker]

PIC18 12MIPS

Some PIC18 versions go to max 16 MIPS (ex. PIC18F26K20), by means of a PLL.

@Hypernova:
In interrupt routines, even if they take some time to execute, time distance between successive executions remains the same, provided that you don't use jumps to different length code branches. This is especially important for control purposes, where different sampling/refresh periods can be an issue.

The LENGTH of time the interrupt takes is also crucial. If it takes 10ms to service your ISR and the interrupt interval is 8ms then you either REstart your Interrupt (endless loop) or more likley IGnore the interrupt until the 1st one finishes, time till next interrupt is then twice the 8ms expected

[scrat]

@Hypernova:
In interrupt routines, even if they take some time to execute, time distance between successive executions remains the same, provided that you don't use jumps to different length code branches. This is especially important for control purposes, where different sampling/refresh periods can be an issue.

The LENGTH of time the interrupt takes is also crucial. If it takes 10ms to service your ISR and the interrupt interval is 8ms then you either REstart your Interrupt (endless loop) or more likley IGnore the interrupt until the 1st one finishes, time till next interrupt is then twice the 8ms expected

I was assuming one would not demand a processor to do in 8ms a 10ms task, of course. Although sometimes it is quite difficult to say how much a particular process will take to execute, while the timing constraint may be already known.

[tyblu]

he just needs to learn to use interrupts or hardware peripherals. No uC swap required

[Hypernova]

This, I got a fan controller where I read the rpm signal edges using interrupts, on every interrupt you just check the CNT register of you timer to get the elapsed time. With a 16bit timer I was sampling at 31.250KHz. Takes no more than 2us for every reading.

Why not use the timer capture function (exact value of the timer is stored when edge is detected on capture input), that avoids the variable latency issues (although not very significant here)?

Regards,
Janne

Ran out of peripherals (even for a xmegaA1!)

I'm doing 8 fans that can either be pwm(4pin) controlled or voltage controlled through smps
So I got:
16 pwm channels (timer C0/1, D0/1, E0)
and I also wanted a buzzzer so E1 is taken
and then there's two uart, one to pc and one to lcd panel so I can't use timers F0/1. Right now as you can see F0 is used for rpm time count. F1 is used to generate 1KHz timer that keeps the time in the system. There's a high level  int 1KHz task that ticks and enable a mid level 100Hz and low level 10Hz tasks.

You can see that if I wanted to I could have bit banged the two uarts and use all 24pwm channels but IMO too much pain, and I would have lost the buzzer pwm in hardware. I got less than 5 RPM noise with averaging on readings which is good enough.

I guess I could still have used E1, F0, F1 to do interrupt based toggles redirected to other pins but I would lose the buzzer in hardware, if I'm going to annoy ppl with it I want it implemented in a way that won't annoy ME!

[Hypernova]

@Hypernova:
In interrupt routines, even if they take some time to execute, time distance between successive executions remains the same, provided that you don't use jumps to different length code branches. This is especially important for control purposes, where different sampling/refresh periods can be an issue.

The LENGTH of time the interrupt takes is also crucial. If it takes 10ms to service your ISR and the interrupt interval is 8ms then you either REstart your Interrupt (endless loop) or more likley IGnore the interrupt until the 1st one finishes, time till next interrupt is then twice the 8ms expected

I was assuming one would not demand a processor to do in 8ms a 10ms task, of course. Although sometimes it is quite difficult to say how much a particular process will take to execute, while the timing constraint may be already known.

If it's too much work load you should package the work and throw it to a lower level and reduce you loop speed to longer than 10ms, so you don't hog the cpu. Otherwise you need to find a time machine. 

[paul30003]

he just needs to learn to use interrupts or hardware peripherals. No uC swap required

The project that I am trying to further develop is, a Laser Projector.

I think your right in saying, "I need to learn to use interrupts.

I'm just putting together details of my project, photos schematics, the Arduino sketch that I'm currently running, which I will post in the projects section.

but just to give an idea of what I'm trying to achieve.

At the moment, features I have managed to achieve.

- Pre programmed sequences stored in eeprom.
- Random sequence selection.
- fairly stable patterns.
- Modulation of the laser, to create multi beam and burst effects.


Features I would like to add.

- Sound activated pattern changes.
- Sweeping the modulation frequency up and down by a few hundred Hz.
- Being able to fall out of the modulation loop on an event happening, (Sound, random or user activated event)
- User programmable patterns.


I am struggling to add the last features because I cant monitor for things like analog inputs or key presses, without using clock cycle, which effects and limits the modulation frequency I can achieve.

Maybe I am looking for a faster Micro because I am trying to tackle the problem the wrong way.

Here is a video of what I have built.



Since this video was taken, I have improve the Arduino sketch somewhat, etched a PCB and mounted everything into an enclosure improved the optics and added safety interlocks to comply with the regulations for the class of laser in use.

All comments and suggestion appreciated.

[tyblu]

I am struggling to add the last features because I cant monitor for things like analog inputs or key presses, without using clock cycle...

No need to eat up clock cycles -- you can use interrupts to debounce key presses, too:
http://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/
I've used danni's code: http://goo.gl/rNxtt (similar to Mike Szczys' on hackaday)

[scrat]

@Hypernova:
In interrupt routines, even if they take some time to execute, time distance between successive executions remains the same, provided that you don't use jumps to different length code branches. This is especially important for control purposes, where different sampling/refresh periods can be an issue.

The LENGTH of time the interrupt takes is also crucial. If it takes 10ms to service your ISR and the interrupt interval is 8ms then you either REstart your Interrupt (endless loop) or more likley IGnore the interrupt until the 1st one finishes, time till next interrupt is then twice the 8ms expected

I was assuming one would not demand a processor to do in 8ms a 10ms task, of course. Although sometimes it is quite difficult to say how much a particular process will take to execute, while the timing constraint may be already known.

If it's too much work load you should package the work and throw it to a lower level and reduce you loop speed to longer than 10ms, so you don't hog the cpu. Otherwise you need to find a time machine. 

A time machine! I wander why I've never thought to use one!