Just the 32 bit PIC. They released a new PIC32MZ family with 2MB of program space and 512K of ram. The original release was a disaster. What worked, worked really good. What didn't, well let's just say there was 21 pages of errata, 56 items. And 5 datasheet 'clarifications' which basically gutted the specs for all of the interesting peripherals.
One of the first fun things I dealt with was the fact that they have a second set of pins to connect to the Ethernet phy, which is laid out much better for the phy I'm using. So I used them. Well evidently "The Alternate Ethernet pins, AERXDV and AERXCLK, are not available on 100-pin devices.", even though the datasheet says they are. So, 12 bodge wires later... And it just went downhill from there. Some fun quotes from the errata that I bumped into during dealing with the part: The watchdog timer resets even when it's not supposed to: "When the Watchdog Timer is used in Window mode, the module may issue a Reset even if the user tries to clear the module within the allowed window." The XTAL oscillator doesn't: "Depending on the revision of silicon, a crystal oscillator cannot be used as the input to the Primary Oscillator (OSC1/OSC2 pins)" -Thank you microchip for making me discover the wonderful world of cheap and small MEMS oscillators. The UART can't gracefully handle overflows: "During a RX FIFO overflow condition, the shift register stops receiving data. This causes the UART to lose synchronization with the serial data stream. The only way to recover from this is to turn the UART OFF and ON until it synchronizes. This could require several OFF/ON sequences." -This is just annoying, but the workaround isn't as bad as it sounds. Especially if you can keep the UART serviced so it never overflows. The ADC, well using it is like a puzzle (then you end up with a horribly nonlinear 8 bit (instead of 12 bit high linearity) ADC): Unsupported ADC operating modes: • Software polling of ADC status bits • Manual software ADC triggering • ADC interrupt modes (use DMA Interrupt mode) • ADC SFR accesses by the CPU while ADC is operating • ADC Boost or low-power mode. • Individual ADC Input Conversion Requests (i.e., RQCNVRT bit in the ADCCON3 register) • Use of ADC S&H Channels 0-4 except for calibration • Any ADC references other than external VREF+ and VREF- pins • ADC Differential mode - it may have just been easier to list what IS working It goes on and on. They a few months back they released the 'EF' version. The F is supposedly floating point since it includes a hardware floating point coprocessor. I think it means 'Fixed'. And the 'C' in the original's 'EC' version means crap. The EF has only 10 relatively minor issues, although a couple which bit me amazingly are still present - but they aren't a big issue. Because I have a large codebase already in a mostly-compatible compiler (using the same underlying libraries), it just made sense for me to move the PIC32MZ. At some point, there will probably be an ARM processor on here, but I sure didn't find any which I felt was worth the hassle of the integration. On Wed, May 25, 2016 at 8:32 AM, Chuck McCown <ch...@wbmfg.com> wrote: > Sad, but I have many products in the same category. Some of them were > very costly development projects. > Good that good will come from it. Many people don’t understand that you > have to fail your way to success with things like this at times. > > Which processor did you switch to? > > *From:* Forrest Christian (List Account) <li...@packetflux.com> > *Sent:* Tuesday, May 24, 2016 7:37 PM > *To:* af <af@afmug.com> > *Subject:* Re: [AFMUG] WTB: Packetflux Generator Controller > > Sort of. > > We sold a total of around 80 (over a few years). There were some > manufacturability issues which needed to be dealt with (why there's 80 > instead of 100 - not a good yield). Fixing those with the current design > isn't really practical. Reordering and making just a few more of the > existing design is also prohibitive due to some minimum orders for parts > I'm no longer using other than on that board. Or summarized: We really > can't cost effectively make any more of the existing design, especially at > the volumes we're moving (1-2/month if we're lucky). > > The good news is that the next iteration of the sitemonitor base units > will actually be able to do everything that standby power controller did, > and a whole lot more. The intent is to circle around and build a new > standby power controller board which runs the new sitemonitor firmware. > This was supposed to be done by now, but the processor switch for the new > base units was anything but the smooth transition we had hoped. > > On Tue, May 24, 2016 at 6:23 PM, George Skorup <geo...@cbcast.com> wrote: > >> Did Forrest discontinue it!? >> >> On 5/24/2016 6:57 PM, Gino Villarini wrote: >> >>> Anyone has units for sale? >>> >> >> > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > forre...@imach.com | http://www.packetflux.com > <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> > <http://twitter.com/@packetflux> > > -- *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 forre...@imach.com | http://www.packetflux.com <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux> <http://twitter.com/@packetflux>
