Moving to the PIC32

[JimKueneman]

It is hard to justify staying with the 16 bit line other than I know it inside and out and don't spend anytime finding its bugs anymore. I know Rotary Ed has moved to the PIC32 recently. How hard is to move to the PIC32? What were the biggest gotchas and have they all been solved? Would you spend the time again to move to the PIC32? Has anyone use the Ethernet module in the part? How solid is it? The dsPIC33F CAN module was worthless and it took until the dsPIC33E to get it straightened out.

Thanks,
Jim

[Rotary_Ed]

Hi Jim,

Yes, with the help of several folks on the list, I have managed the transition from my 18F chip to the PIC32MX795F512H (small brother of the PIC32MX795F512l -100 pin). Attached are a couple of photos showing my project. You can just make out the 32bit chip behind the ribbon cable socket on the round PCB.

DSC00788s.jpg (67.97 KiB) Viewed 10326 times

Probable the single most frustrating thing was the weeks spent trying to figure out why when using the IC (capture) interrupt, my code would never return to the loop from where it was called. It turned out that the code line I put in to clear the IC buffer (a necessary condition to prevent recurrent interrupt) was optimized out of existence by the compiler. I looked at the List and ASM code for weeks without noticing that one line of code was missing. When pointed out to me by janni, it was easy to fix just make the variable to which you "empty" the buffer as "Volatile" and that took care of the problem.

The other thing which caught me off guard was that the Boolean "TRUE" in the MikroPIC32 compiler is 32 bits long (all bits set of course). When I was still using byte size variables (no reason not to) where possible when I ported the code over. Well, I finally figured out that the reason my "if X = TRUE then..." statements were not working was the X variable was 8 bits (so if TRUE = 255) where as the compilers TRUE was 32 bits or a value of 4294967295. Well needless to say, even if byte X was TRUE its 255 would never = 4294967295. So a quick fix was to replace all occurences with "if x = Lo(TRUE) then" which of course picks the 8 lowest set bits.

The other thing that was new to me (perhaps not to you with 16 bit experience) and cause me time and head scratching was the various speeds you could assign to the Sys bus , Peripheral bus and USB bus. Then that in turn had an impact on all of my prescaler values for timers. With the USB OTG, finally realized that dividing the Osc fre to get it to be in the range of 4-5 Mhz for input to the PLL circuit for the System bus did NOT do it for the USB bus. The Osc Fre had to be divided by the proper value to insure the USB bus input was also in the 4-5mhz range. Since that is absolutely required for the USB to function I would have though it would be accomplished by dividing the input to the PLL. But, not so, must do it separately. The OTG USB took a bit of playing with - but mainly figuring how to implement it on the board rather than the code - turns out you will need some sort of switch to turn the VBUS to 5 volts depending on whether the chip detects itself being used as a Host or Device. Lots of fun.

Then the atomic functions for clearing, setting and inverting bits of a port/register were new to me. But, not that hard to figure out, but have still not used them enough that they are second nature.

Oh, yeah. I guess the first thing I wasted time on was when I attempt to blink and LED with the Port pin ON, delay, Port Pin OFF, delay loop. It simply would NOT blink the LED - would turn it ON but not off. So spent time on trying to understand that problem as I figured If I could not understand that simple bit of code - what chance of the more complex. Well, it appears from what I read, that this code simply does not work if the system bus is much above 24 Mhz . Other techniques such as LATB1 = NOT(LATB1) would work to blink the LED, but not the code I was used to using. A somewhat minor thing, but can shake your confidence that you understand what is going on.

That's about all I can think of. Yes, it was frustrating, but glad I stuck with it. I was up to the Flash Mem limit of 128K with my old chip and now that's only about 34% of the PIC32MX795F512H's Flash capacity.

One other thing, I found that the naming convention in the compiler for the 32 bit PIC chips was just not consistent. In fact, a register might have its bits declared one way and the next register would have it declared a different way. I finally had to go into the Chips Definition file to figure out what declaration would work with which register. Then it was a bit cumbersome to have to declare each bit in a sub range rather than a range of bits (say from DoThis(2,4) rather than Dothis(4),dothis(3)dothis(2). But, once you are aware of some of these things - its really no problem.

The last area I had problems with was trying to us the TFT library functions with my display (uses an ILI9341 display controller chip). I do thank the Mikro team for making the initialization portion of the library source code available - that was enough to turn on my display, but unfortunately, I could never get any of the rest of the Library functions working for me. Not saying anything was wrong with them - they worked fine for the TFT on my EasyPIC Fusion v7 development board. But, for some reason (undoubtedly related to my ignorance), I could not. So I ended up writing my own Graphic draw procedures and scalable font code.

Hope this helps. Now that I have passed over the top of the hill, I find the compiler and chip are working just fine! I suspect with your 16 bit chip experience, you will find the transition easier.

Best Regards and Happy Holidays

[Dany]

Hi JimKeuneman and Rorary_Ed,

I took the liberty to add a link to this webpage on my own website (see http://www.rosseeld.be/DRO/PIC/tips.htm ... cific_tips).
This page contains valuable info for future PIC32 users (of which I am one). I had to add the link...

I hope you don't mind? Thanks for this info!

[Rotary_Ed]

I do not mind at all, Dany. Pleased that you think the info may be useful to others. Appreciate the great info/tools I get off your website.

One other thing I might mention which came as a surprise to me. I got to the point of bootloading my code to the PIC32 chip with the USB-HID tool of the compiler and was stunned to see it load over 128K of code in less than 10 seconds!!! My old 18F chip using Rs232 at 115200 baud would take 8 MINUTES. Not sure why, but sure is nice. In fact, it loads faster using the USB-HID tool that the programming suite. Would never have expected that!

[JimKueneman]

Thanks for the writeup. I just received my Fusion 7 board with the dsPICEP part for now. I will be buying the PIC32 MCU board in the near future to start experimenting with it. Need to get the kids Christmas bill paid off before I will be allowed to buy the PIC32 compiler

Jim

[Rotary_Ed]

Happy New Year, Jim

Welcome, hope they helped. But, be forewarned that with the capability of the PIC32 comes a hunger to exploit it - which in my case led to Visual TFT tool which produces so much better and complex graphical objects (buttons, boxes, labels, etc). The PIC32 can handle it with ease (much easier than me getting my head around it).

Get those bill paid off and get on with the fun things

[JimKueneman]

The newer EP series of dsPICs are very capable, the only thing the P32 has that I "have to have" is the Ethernet module. The dsPICs don't have that (I don't need all the UARTs you did ). I have had Visual TFT since version 1.0 so I already know how things can get out of hand fast with all that power

Jim

[Dany]

Hi, I have also moved to PIC32 recently and I have written an article about my experiences with PIC32 interrupts. I tought this is the right place to mention it.

The article: http://www.libstock.com/projects/view/1 ... ts-article.

It is (very) possible that there are some errors or ommisions in it.
Please give your comments. Thanks in advance!

See also http://www.libstock.com/projects/view/1 ... -for-pic32, wherein a Timer1 interrupt routine is present with ICS set to "OFF", so it has a manually written context saving code.

[Rotary_Ed]

Hi Dany,

Great to see you moving to the PIC32, waiting for some of your fabulous tools for the PIC32.

Great article on interrupts . I might suggest (if I didn't just miss it in the article ) that you add a note about the importance of ensuring that the buffers of some modules (such as the IC capture) must be emptied OR you get the infamous persistent interrupt.

I would not hesitate to also add that it is important that if a dummy variable is used to just empty the buffer of a persistent interrupt, that it be declared "volatile" - OR else you can spend weeks , as I did, trying to determine what the problem was - which turned out to be the compiler eliminating my dummy variable - because it apparently noted that the data loaded to it was never used.

Thanks for the references.

My project is now to the point of adding an engine Knock (detonation) detector and I have it working - at least with a simulated "Knock" signal being injected. The function will detect as few as 6 cycles of a 4.4KHz knock signal in a 3msec listening window.

I now have the cylinder off a Lycoming aircraft engine that I will mount a knock sensor to and then use a hammer solenoid to hit the cylinder. The solenoid will be triggered and in sync with the simulated rpm of the engine (from my function generator)

Just want to thank you again for all the effort and sharing you have done to make it easier for guys like me.

Best Regards

[Dany]

Hi Ed,
Thanks for your comments.

My project is now to the point of adding an engine Knock (detonation) detector and I have it working - at least with a simulated "Knock" signal being injected. The function will detect as few as 6 cycles of a 4.4KHz knock signal in a 3msec listening window.

I now have the cylinder off a Lycoming aircraft engine that I will mount a knock sensor to and then use a hammer solenoid to hit the cylinder. The solenoid will be triggered and in sync with the simulated rpm of the engine (from my function generator)

Seems a very interesting project. Really "real time".

I might suggest (if I didn't just miss it in the article ) that you add a note about the importance of ensuring that the buffers of some modules (such as the IC capture) must be emptied OR you get the infamous persistent interrupt.
I would not hesitate to also add that it is important that if a dummy variable is used to just empty the buffer of a persistent interrupt, that it be declared "volatile" - OR else you can spend weeks , as I did, trying to determine what the problem was - which turned out to be the compiler eliminating my dummy variable - because it apparently noted that the data loaded to it was never used.

Hi Ed, the article has been adapted as you suggested. Could you have a look please? Thanks in advance!
http://www.libstock.com/projects/view/1 ... ts-article

[Jack Flanders]

Dany - your writeup on PIC32 interrupts is fantastic! I used some PIC32 interrupts in the past and relied on an example to get it working but did not understand any of the things you wrote about aside from *ie and *if bits.

Your posting should be set as a "sticky" post in all of the other PIC32 compiler forums!

[Rotary_Ed]

Dany, your interrupt article looks great and is going to save a number of folks a lot of time and angst. Wish I had it when I
started with the PIC32, would have saved me weeks.

Thanks for sharing