I agree Matt. I also thought the '628s built-in serial port was a considerable luxury (grin).

 

I haven't had the chance to play with a dsPIC33F yet with my ICD2 so I'm not sure why it isn't working for you. They are supported by the ICD2 but consider this: (Ripped from the ICD2 notes in MPLAB)
Beta support devices:

dsPIC33FJ128GP206(4)
dsPIC33FJ256GP510(4)
dsPIC33FJ64GP710(4)

dsPIC33FJ128GP306(4)
dsPIC33FJ256MC510(4)
dsPIC33FJ64MC506(4)

dsPIC33FJ128GP310(4)
dsPIC33FJ64GP206(4)
dsPIC33FJ64MC508(4)

dsPIC33FJ128GP710(4)
dsPIC33FJ64GP306(4)
dsPIC33FJ64MC510(4)

dsPIC33FJ128MC506(4)
dsPIC33FJ64GP310(4)
dsPIC33FJ64MC706(4)

dsPIC33FJ128MC510(4)
dsPIC33FJ64GP706(4)
dsPIC33FJ64MC710(4)

dsPIC33FJ128MC710(4)
dsPIC33FJ64GP708(4)

PIC24HJ128GP206(4)
PIC24HJ128GP510(4)
PIC24HJ64GP506(4)

PIC24HJ128GP210(4)
PIC24HJ256GP210(4)
PIC24HJ64GP510(4)

PIC24HJ128GP306(4)
PIC24HJ64GP206(4)


PIC24HJ128GP310(4)
PIC24HJ64GP210(4)

 

The other thing I don't like about the PIC24 and dsPIC33F is their I/O pins can only sink and source 4mA compared to the 20-25mA of the 5V PIC line (including the dsPIC30F)

 

The low pin current may have an impact on the I2C abilities. I2C spec only requires 3mA which means a very short transmission line. The 18F PICs, like most I2C devices, have a much higher drive current and thus could drive far longer lines. The 33F is only barely above that rather marginal requirement. Oh well, for this system I was thinking I'd need a bus extender anyways due to the 3.3v level needing to talk to a 5v device on the other end (like 6 ft away).

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

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

 

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.

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

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 thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

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.

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

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.

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

 

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

Mike

 

Do you have the C code for this?

 

You're kidding right?

__________________
Tanaka Sensei (avatar) says: Please spell it "ridiculous" correctly! Not "rediculous". ^^

 

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.