Wow, what a mess.
Watchdog problem rminds me of a line from Dr Strangelove:
“I think the auto destruct mechanism got hit and blew itself up”
From: Forrest Christian (List Account)
Sent: Wednesday, May 25, 2016 7:03 PM
To: af
Subject: Re: [AFMUG] WTB: Packetflux Generator Controller
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)
Sent: Tuesday, May 24, 2016 7:37 PM
To: af
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
--
Forrest Christian CEO, PacketFlux Technologies, Inc.
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forre...@imach.com | http://www.packetflux.com
