Good old PIC's

[nigelwright7557]

Been using PIC's since 1985 and was a PIC consultant for 13 years.

I recently started a USB PC based oscilloscope using PIC for a2d's

Seemed to work fine.
Then noticed at higher frequencies getting towards limit of a2d the waveform on my pc screen had small steps in it.
So looked for bugs in my software but couldnt find anything.

So did a data grab and dumped it to the screen and the data goes 2,2,4,4,6,6 etc etc when it should be going 2,3,4,5,6,
So grabbed the PIC errata sheet and found there is a bug in the a2d where faster captures can be incorrect.

So being a good bodger I added a software low pass filter to round off the values.
Almost looks good now.

I wanted a faster usb scope so designed an ATSAME70 pcb.
Got it up and running except for usb wouldnt work.
I had used code from a previous project for usb so should have been fine.
In the end I got in touch with microchip and they said the micro I had picked the usb doesnt work on it.  i had to use 100 pin version for usb.
So found a different micro and usb worked on that.
Then set about clocking the a2d converter using pwm but the pwm doesnt work at all on that micro.
So tried the programmable clock output.
And that only works upto 12MHZ before failing.

Why do  I bother !

[ataradov]

You should read erratas before doing designs with the chips. All MCUs have erratas without exceptions. You just need to pick one that has erratas unrelevant to your projects. Lack of HS USB on a 64-pin SAM E70 is a bummer though.

PWM works fine on that device, I'm not sure what is your problems. But you can't clock ADC with PWM, that's just not the configuration option available. You get a fixed system clock to the ADC with a prescaler inside the ADC. That's it.

I'm not sure what have you tried with PCK and what exactly fails. PCKs don't care, they will output whatever clock is attached to them. If you outputting on a pin, pad bandwidth will start limiting things at some point, but it would be much higher than 12 MHz.

[nigelwright7557]

Usually Microchip are quite good when I raise a ticket.
For the atsame70 problems they have never replied in months.

I have had one reply in regards PIC32mx a2d problems. They never told me about errata bug in a2d.
Just have to be patient  I guess.

[nctnico]

You should read erratas before doing designs with the chips. All MCUs have erratas without exceptions.

But some worse than others. Personally I don't touch anything from Microchip or Atmel. Not worth the trouble. Erratas are one thing but 'clever' specmanship is another.

[nigelwright7557]

You should read erratas before doing designs with the chips. All MCUs have erratas without exceptions.

But some worse than others. Personally I don't touch anything from Microchip or Atmel. Not worth the trouble. Erratas are one thing but 'clever' specmanship is another.

What annoyed me was RS Components (the vendor) still had USB in their description of the 64 pin IC.
So I wasted money not only on the IC but on making a pcb for the job.

[ataradov]

USB FS does work on the 64-pin device. Only USB HS does not. So "USB" spec is valid.

[Bassman59]

USB FS does work on the 64-pin device. Only USB HS does not. So "USB" spec is valid.

What would be nice is if when sorting through available peripherals in a device family vendors' web sites, the distinction between FS and HS was made clear. Too many devices offer "USB 2.0" but never distinguish between FS and HS. As everyone should know, USB 2.0 does not imply High Speed.

[rsjsouza]

USB FS does work on the 64-pin device. Only USB HS does not. So "USB" spec is valid.

What would be nice is if when sorting through available peripherals in a device family vendors' web sites, the distinction between FS and HS was made clear. Too many devices offer "USB 2.0" but never distinguish between FS and HS. As everyone should know, USB 2.0 does not imply High Speed.

I agree. Just a side note: it is impressive how many people and products get this so wrong. Over the years I lost count of so many people and product specifications that state USB 1.1 for FS and USB 2.0 for HS.

Although I concede that usb.org does not make things easy:
USB1.0 and USB1.1 were borged by USB2.0, becoming USB 2.0 LS, USB2.0 FS and USB 2.0 HS
USB3.0 and USB3.1 were borged by USB3.2, becoming USB 3.2 Gen 1, USB 3.2 Gen 2 and USB 3.2 Gen 2x2 

Source: Slide 16 of https://www.usb.org/sites/default/files/D1T2-1%20-%20USB%20Branding%20Session.pdf

[SiliconWizard]

Well, it's not that confusing actually. USB versions are just versions of the protocol, and they all are backwards compatible AFAIK. So obviously you can't get HS with USB 1.1, but you can absolutely get FS and LS with USB 2.0.

True that many people tend to say "USB 2.0" when they mean USB HS, which is wrong.

[tszaboo]

So I've used the DSPIC33 for one project. Never got the ADC working properly, the advertised samplerate is useless, as the chip cannot do any calculation on it fast enough. "Its for control systems, that take one sample quickly, and then processing it. It doesnt support continous sampling"
And btw, we have 6 UARTs, but nobody wrote code for UART3-6 so if you connected that one, good luck, you are on your own, here is a register map.

OK, moving on. PIC32MZ.Datasheet: 18MSPS ADC. Wow, that's awesome.
The errata was basically: "ADC doesn't work, at all"

I will not touch the analogue peripherals of a PIC again, that's for sure. Probably they have Errata for opamps.

[coppice]

So I've used the DSPIC33 for one project. Never got the ADC working properly, the advertised samplerate is useless, as the chip cannot do any calculation on it fast enough.

There are quite a few MCUs with an ADC that's faster than any reasonable amount of processing can be done on the signal in real time, but that still makes them great for a range of high volume applications. Take something like glass break detection. You only need to listen for an abrupt change from the mic in real time. When you see one you can capture a burst of samples into RAM, and take your time analysing them to see if they look like the signature of glass breakage.

[tszaboo]

So I've used the DSPIC33 for one project. Never got the ADC working properly, the advertised samplerate is useless, as the chip cannot do any calculation on it fast enough.

There are quite a few MCUs with an ADC that's faster than any reasonable amount of processing can be done on the signal in real time, but that still makes them great for a range of high volume applications. Take something like glass break detection. You only need to listen for an abrupt change from the mic in real time. When you see one you can capture a burst of samples into RAM, and take your time analysing them to see if they look like the signature of glass breakage.

Should've clarify it, this was 12 years ago. The MCU was targeted to motor control, I wanted to use it for ultrasonics.

[nigelwright7557]

USB FS does work on the 64-pin device. Only USB HS does not. So "USB" spec is valid.

What would be nice is if when sorting through available peripherals in a device family vendors' web sites, the distinction between FS and HS was made clear. Too many devices offer "USB 2.0" but never distinguish between FS and HS. As everyone should know, USB 2.0 does not imply High Speed.

I was told it doesnt work because the 64 pin IC has a usb pin missing.
I tried it in full speed mode and it wouldnt log on to the pc.
This is code that worked on a previous project on a PIC32mx.

[ataradov]

It is missing VBG pin, which sets the reference current for the HS drivers. It is not used in the FS mode at all.

The low level hardware is obviously different in SAM and PIC devices, so a lot of things could have gone wrong.

[Doctorandus_P]

So you start with an uC with a defective ADC and then on top of that you add a layer of obfuscation to hide that and lie to you?

Yuck.

Take it as a learning moment and replace your uC with one that has a working ADC.