I'm not saying the PSOC 4 is not a good line of parts. I'm saying they are more like conventional MCUs than PSOCs. ADC and DAC are not really "programmable" analog. Even opamps and comparators show up in a lot of MCUs like the MSP430 and many PICs.
Compare this to how the PSOC 1 works and you will understand what I'm saying. Of course the PSOC 1 won't do what a PSOC 4 will do, there's nearly an order of magnitude speed difference and memory size.
-- Rick
I believe that it will be fixed in next release (A6?). We have to use the PIC32MZ with 512K SRAM, despite the errata list. No other micro has enough on-chip SRAM.
I have about 50,000 P1 in a couple of products. They were applied about
14 years ago starting with the CY8C26000 series then moved to the 27000 and 29000 series when the 26000 became obsolete. I know the differences and the P4 is a clear winner. I can do at least as much with a P4 as I ever did with a P1.As I have done, you have to decide what is right for you. If it doesn't do what you want, that doesn't mean it is not right for others.
Maybe we're not reading the same manual, I'm looking at the PIC24F online reference manual oscillator section. The very first operaton is to disable interrupts regardless.
There's a reference to disabling interrupts to prevent an interrupt from interfering with the unlock sequence for writing to OSCCON.
DOZE/DOZEN are not part of OSCCON, and no unlock sequence is involved in setting them.
Sylvia.
If they're not part of OSCCON then the directive does not apply, now does it.
You were the one saying that interrupts needed to be disabled.
Sylvia.
They do need to be disabled when switching clock sources.
Are you saying the USB /still/ doesn't support 480 Mbps? It was many years ago that the chip came out - I had assumed that it would be working fine by now. I agree that it is nice with lots of on-chip RAM, and that many (most?) micros have less than I'd like - but I'd rather have a chip that works the way it is supposed to work.
Unfortunately, yes. Still doesn't work in A5. The errata disappears in A6. But no one outside microchip have the chip to confirm it yet. But in our case, 512K sram is more important than 480 Mbps.
It sounds to me like uP (and FPGA) manufacturers buy IP blocks (like Ethernet, PCIe, ADCs) and dump them into their chips. They don't know much about the internals, so they can't provide much support.
If anyone at Altera understands their PCIe stuff, we haven't found them. Ditto the analog stuff in NXP ARMs.
-- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
If you are not using a feature, then it doesn't matter too much if it doesn't work!
But I worry about using a microcontroller with a long, serious errata and major issues that don't get fixed - it stinks of poor quality control and poor development processes. I have to wonder what other problems it has.
Unfortunately, yes. Still doesn't work in A5. The errata disappears in A6. But no one outside microchip have the chip to confirm it yet. But in our case,
512K sram is more important than 480 Mbps.--- SoupGate-Win32 v1.05 * Origin: (1:249/999)
--- Synchronet 3.15b-Win32 NewsLink 1.92 SpaceSST BBS Usenet Fidonet Gateway
It sounds to me like uP (and FPGA) manufacturers buy IP blocks (like Ethernet, PCIe, ADCs) and dump them into their chips. They don't know much about the internals, so they can't provide much support.
If anyone at Altera understands their PCIe stuff, we haven't found them. Ditto the analog stuff in NXP ARMs.
-- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.com --- SoupGate-Win32 v1.05 * Origin: (1:249/999) --- Synchronet 3.15b-Win32 NewsLink 1.92 SpaceSST BBS Usenet Fidonet Gateway
But you have to give them credit for even trying. 480 Mbps is no easy task. Having 2M flash and 512K sram on the same chip are bleeding edge technologies. So, problems are expected.
By all means give them credit for trying. But since they failed, they shouldn't have put it on the market.
And although it's true that issues arise with advanced technology, at least some of the errata look as if they derive from simple gate-level mistakes.
Sylvia.
No, they get no credit for trying - they would get credit for /succeeding/. They'd have got some credit for working on this as a development project towards more powerful microcontrollers in the future, but they should never have put it on the market as it stood. It would have been /far/ better to release it as a 12 Mbps USB device that works, and aim for a 480 Mbps version later on.
As it stands, the mess of the release of the Pic32 practically destroyed MIPS' chances in the microcontroller market, which is a terrible shame.
True, though it is not /that/ hard. But as said, a working 12 Mbps USB device would have been far better than a broken 480 Mbps - making a broken 480 Mbps interface is not a great challenge.
technologies.
No, memory sizes are not "bleeding edge" - they are copy-and-paste. Assuming your cpu can address the memory sizes (which is not an issue for the MIPS32 core), simply adding more memory to the chip is a task that could be given to the tea boy in the chip development lab. There is only /one/ reason why we don't see 16 MB flash and 4 MB sram on all our MIPS/Cortex microcontrollers - it takes die space, which means higher cost (and bigger packages for the smallest CSP packages). The additional design effort, such as extra address bus lines or wider crossbars is very minor, and mostly a matter of increasing a number or two in the VHDL or Verilog design files.
Certainly problems are to be expected for a new microcontroller family, especially with a new cpu core. That's what development and testing is for, followed by engineering samples and more testing. That's why sales and marketing work with roadmaps, not guarantees - and engineering can put the breaks on the release or change the specs if there are unexpected issues. And that's why you do not let the marketing department mass-release a new device before it works!
Ain't that the truth. Every time I try to use the on die(sp?) BOR, it's always more trouble than it is worth. Primarily, false resets. Add all the decoupleing caps on the face of the Earth (that's what they always blame) and it still doesn't matter. Had one PIC that would BOR every time you used the I2C at any frequency higher than the 100K slow speed. Didn't matter the quantity or quality of the decouple caps.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.