After all this time, Microchip doesn't satisfy me!

Hi everybody.

I've come to EDA Board after quite some time and the reason was I had more pressing needs to satisfy than the craving for embedded electronics. ;-)

I recently started work on a data acquisition system for interfacing a custom made satellite ground station to the PC. The scenario is like this: the ground station hardware is pretty sophisticated. It does everything from receiving to decoding to conditioning, up to the point where the data is variably bit-rate TTL level serial with clock. Right now, we have a tiny DAQ built around a PIC16 core µC, which takes the clock signal at external interrupt and on every rising-edge triggers interrupt. The ISR reads the corresponding bit and when eight of them are accounted for, the byte is transmitted on UART which is connected with a terminal on PC...

This works to some extent, but the ground station unit can transmit up to (variable bit-rate) 1Mbps. Up to about 110 kbps, it's fine, after that a bloody mess!

A new DAQ is needed which can acquire data at a rate higher than 1Mbps. PIC16 is way too primitive. PIC18 works at 64MHz max. And going by 0.25 DMIPS/MHz, we get only 16MIPS which barely fits the instruction cycle criteria for data acquisition @ 1Mbps. Solution is simple to say, a µC with a higher max. operation frequency. As simple as that sounds, I have not had ay exposure with architectures other than Microchip PIC16 and PIC18. I was reading about PIC32, and it looks pretty. But I'm not sure if I should stick to PIC.

I was thinking about going Cortexy. Stellaris by TI or SAM* by Atmel look like nice enough ARM-based solutions. But then again, I have worked only with PIC16 and 18 so far. The thing I like the most about PIC16/18 architectures is that the DMIPS/MHz are pretty much consistent. Apart from a few odd instructions, every instruction takes 4 clock cycles and that is very good if the application is time-critical. If I choose ARM and then find out that it has a very low DMIPS/MHz like our beloved 8051, it would be a demon born again and the development will have to start anew.

I want the experienced members of the forum to reflect and express their views.

There's something more. Deep down inside me, I want to get rid of Microchip addiction and although I still like Microchip, I want to see what ARM looks like. However, I'm also afraid of the cost of this adventure as ARM based solutions, and those with high operation frequency, do not quite care about my light pocket. Cheers

This could easily be solved in assembler on just about any PIC.

However, I think you should switch to Cortex-M0 or Cortex-M3. They are excellent processors with very cheap tools:
http://search.digikey.com/scripts/dksearch/dksus.dll?vendor=0&keywords=stm32vldiscovery
http://search.digikey.com/us/en/cat...d-kits-mcu-dsp-fpga-cpld/2621773?k=lpcxpresso

Yes, a Cortex-Mx is a complete overkill for your application, so what? You get a modern processor from a lot of manufacturers at a price similar to a PIC.

I didn't get it.

Firstly, how can this be solved with just about any PIC? I do agree that assembler provides a better control over instruction cycles and I do program in assembly when the application is relatively simpler to implement. But as far as I know, the problem I mentioned isn't solvable through ordinary PIC16s and 18s. That is because, as I mentioned, the maximum operation frequency of PIC16 is 20MHz, or 5MIPS (5 million instructions per second). That is pretty neat if I want to interface an LCD, but my application requires fetching and aligning a bit at the rate of 1 million per second and transmitting the register on USB every 8th cycle. 5 million instructions per second just doesn't cut it because much more than 5 instructions will be needed to fetch and align a bit. So we move over to PIC18. PIC18 can support up to a dazzling 64MHz or 16MIPS. Still, it's not enough. I need to wait for the interrupt at the port where I provided the clock signal. When the interrupt is triggered, I need to read the bit at data pin, which isn't a single instruction job in PIC18. Then I need to move the bit to C in status register and rotate left through carry. Then wait for the next instruction. I don't think 16 instructions can do that with enough time left to perform other tasks such as monitor the temperature of processor and manage an active cooling mechanism etc.

However, as I was studying about PIC32, it does seem to be a pretty nice option from Microchip arsenal. 80MHz and 1DMIPS/MHz making it 80MIPS, so I get 80 instructions to handle one bit and perform tasks and then wait for the next one. That might do it. But I'm still not sure about PIC32 because it isn't as popular as I thought it should be. ARM, on the other hand, provides just what PIC32 does and is much more popular in the industry.

Still, I am not sure and that is exactly why I honor and value your opinions so much.

Also, I don't get what you mean by Cortex-M being overkill of my application. And please list a couple of examples of the manufacturers and the processors that I can have a price similar to a PIC.

Thank you very much for the reply. I'm grateful that you cared to comment.

Oh, I thought the job was to sample the pin and after every eight bits send the data to a UART. And that was all.

It's a long time since I did any PIC programming but we used to do something like the code below for sampling quickly. I agree that it's not good enough for a 1MHz signal on a 20MHz PIC, but close. There seem to be 32MHz PICs around and with one of them it should be no problem. How about using SPI for input?

I reread your original post and I got the rotation of the bits wrong, sorry.

Links in my previous post. (Sorry those were to tools.) Search digikey.com for Cortex M and you will find chips.

Overkill if all it had to do was to sample the input and send bytes to the UART.