dsPIC33F! Whoopie!

dknguyen said:

I2C? pshh! Who needs I2C when you got CAN! But yeah, by far the worst thing I find with the 33F is that I need to level convert everything to communicate with 5V. Even worse is reducing 5V analog signals to be accepted by the 33F's 3.3V ADC, particularily when you need very very precise measurements like integrating gyroscope or accelerometers readings. It kind of really blows when you consider the changing offsets for the op-amp buffers and varying resistance of the resistive dividers, it's enough to add tens of mV of error which is ginormous when you are integrating the thing.

Why no 5V 33F?! Why? Why?! WHY?! Either that or 3V everything else which is a bit of a problem for ring gyros right now

Click to expand...

CAN is sucking for me due to the need for an external transceiver- and I'm kinda bummed by the idle current of some of the more "affordable" transceivers. Also the wiring limitations with the terminating resistors is inconvenient.

I believe you are mistaken on this 3.3v vs 5v problem's existance.
The dsPIC33F migration document says that ALL inputs are "+5v tolerant". So you're supposed to be able to put +5v straight into any pin other than Vdd. The +3.3v output voltage should be interpreted as a logical high level by most devices. My understanding of this device is of course in its "early stages" so I hope I didn't jump to any conclusions in this area.

I don't think an analog voltage above Vdd can be read by the ADC though. AFAIK Vref cannot be taken above Vdd but I'll need to read up on it. However, it's unnecessary for most of these devices. For example, the Whetstone Bridge used in most accelerometers and pressure sensors works just dandy on any reduced voltage. You just can't exceed the Vdd-Max in the device spec sheet. Now those devices with a built-in output amp may not work on Vdd<5v but those are in somewhat of a minority.

In fact I've been noticing many of the newer accelerometers are rated for a MAX of 3.3v and can't even be run off a 5v system without reducing the Vdd.

Voltage on any combined analog and digital pin and MCLR, with respect to VSS ... -0.3V to (VDD + 0.3V)
I believe this applies even when the pin is configured as a digital input.

Any digital-only pin:
Voltage on any digital-only pin with respect to VSS....... -0.3V to +5.6V

So these pins take 5v input with no prob.

I believe any pin set to digital mode is 5V tolerant, but digital translation is easy. It's analog translation (which is not 5V tolerant) is the pain in the ass. It would sooo nice if it was 5V tolerant.

In my case, I have almost no use for the 5V tolerance, since I never have stand alone digital inputs- it's always a serial receive line paired up with a transmit line, so I have to translate the transmit line anyways (and might as well do the receive line with the same translation IC). Most of my stand alone inputs are 5V analog, which is a pain since I have to translate every...single...one...

Actually, I should be happy that the dsPIC30F even runs at 5V. It's getting harder and harder to find new uC that run at that...and still plenty of devices that do.

What would be great is for Microchip to go the route of the programmable logic companies and have separate inputs for Vcore and Vio. This way they could have a lower power but high MIPS core with the superior capabilities of a high current 5V tolerant I/O section that could also be fed with 3.3V or lower for compatibility with lots of the newer chips on the market.

dsPIC33F has a separate Vcore, but it's interally generated and is only apparent because it requires an external capacitance on a pin. The Vdd is still limited to 3.3v.

Honestly, I'm sure it's due to the fab process that enabled them to make such a high density, powerful, cheap part in the first place. It may not even be possible to make the core out of 3.3v technology and then the IO pads out of Vdd=5v technology.

Probably a similar situation with why there's no EEPROM on board. Regrettable, but I'm sure there's a reason.

I'm certain an awful lot of consideration when into the decisions to make things the way they came out.

OK, got the Noise Suppression Lib working correctly.
It's neat! I took a fan and stuck a piece of junk mail made from heavy cardstock against the blades to make a racket and wrote the code to alternate between using the nslib and just doing a straight passthrough about every 2 sec. Yeah,the headset's voice component is unchanged but the clatter disappears!

Let me stress that this is not active noise cancellation, it doesn't create antinoise to cancel out noise leaking in around the headphones. It only removes background noise from a microphone signal.

That sounds neat. Do you have a drawing of how you've hooked everything up?

Mike

Oznog said:

Allright, I'm blinking an LED at 40MHz!! Try that with your pathetic PIC16F series! Stand in awe of the breathtaking speed of my pointless accomplishment!

Click to expand...

Do you have the C code for this?

You're kidding right?

dknguyen said:

You're kidding right?

Click to expand...

I don't understand. Why would I be kidding? I can blink an LED as well, but I'm more interested in the proper initialization of a dsPIC33 device.

Oh okay. But what do you mean by "proper" initialization? It's going through the registers that control the oscillator and setting the values.

dknguyen said:

Oh okay. But what do you mean by "proper" initialization? It's going through the registers that control the oscillator and setting the values.

Click to expand...

That's what I mean. I just want a working example of an LED blinker for the dsPIC33. I just started with the dsPIC33 today. I usually use 8 bit devices.

See my code in this thread.

kchriste said:

See my code in this thread.

Click to expand...

Many thanks, human.

hey guys need sum help. is there any difference in programming between the dspic30f and dspic33f? i am well versed with AVR family.recently started with PIC. plz cld sum1 giv me links to C tutorials for dspic33f. urgent....

Not much difference; more to do with different PIC features and peripherals than anything else. I posted some very simple 30F starter code here where as the link above was for a 33F. Are you already familiar with C or not? If not, a generic C tutorial would help also.

i am familiar with C . have done projects on Atmel microcontrollers. m goin to use the dsPIC33FJ128MC804. ya i saw ur code before already. thanks for it. i guess il hav 2 studythe datasheet more thouroughly. jst got confused with some of the header files... i can use MPLAB IDE v8.36 for programming rite..? is there a simulator also available with it...?

thanks much appreciate

Wow, major resurrection of zombie thread.

The way you declare interrupts is different from other PICs. Also the way of declaring the setting for the config "fuse" bits is different.
MPLAB Sim (part of MPLAB) works for 33F just like any other PIC chip.

You need to select the Linker script for your specific part, select the device under MPLAB's Configure tab, and add "#include <p33fxxxx.h>" at the top of the file.