What needs to go in a PIC24 development board?

[John Lawton]

I'd be interested to know what should go in a PIC24 development board.

I have some time to design one or more boards.

As I have said in another thread https://protoncompiler.com/index.php/topic,15
I'm usually a bit of a minimalist, but there is an ecosystem around the Arduino boards that might be useful to some as well.

John

[RGV250]

Hi John,
I have just had a thought that is probably going to be a load of crap but don't have datasheets to check. What would be amazing is if it could have either 8 or 16 bit device fitted. A Amicus1824 so to speak.

Bob

[top204]

I tried that with the Amicus18 John, but quite a few things got in the way of it becoming more popular. One was the person I gave the Amicus too for selling and advertising (WHAT ADVERTISING and WHAT SELLING!). I never saw a single penny for the months of work I put into it, in my own time. :-(

The other was that the arduino used a single device type. So the libary system for it was relativaly straightforward, and so was writing for it. Because a single device can have all of its peripherals used and known about and all of its querks and pro's can be used. However, for some reason, microchip users are never happier unless using the "very latest" device, or "this device" or "that device" etc... :-)

So the library system becomes out of control because even the different families of the same microcontroller use different methods of control of the peripherals, or RAM and flash or EEPROM etc...

It also means a boat load of bootloaders need to constantly designed because, again, microchip can never make their mind up on the ways a microcontroller manipulates its flash memory. i.e. Different SFRs, same SFRs, different bits within them, different write and erase block sizes.... The list goes on....

But now, the "buzz" word "Arduino" is being used for virtually everything that uses the C++ language! A lot of people do not actually know the term "C++", and actually think arduino is a valid language! And I am not joking on that!

I tried that type of thing with the Amicus18 board Bob, with a seperate PCB that took a 28-pin dsPIC or PIC24 chip and it plugged into the Amicus18 device socket. It worked quite well for testing the 16-bit devices when I was creating the compiler for them, but the 8-bit and 16-bit devices do have a lot of differences in their pinouts and pin uses, so it was easier to build a board for dsPIC and PIC24 devices, but even they have differences, so I had to add 2.54mm jumpers on the board for the programming differences on them and the need for some to have a capacitor fitted to their voltage reference pin and some not, and it worked nicely for the different ranges of them.

[John Lawton]

Yes, I agree rather too many differences to make a universal board.

If the dev board were basic, then designing two versions for 28pin PIC 8 bit and 28pin PIC 16bit would be easier and less confusing to the user than providing the all links required for a dual purpose board.

To my mind this thing should be KISS.

But I also not averse to updating the Amicus24 design (should it still be called that?) as well.

John

[kcsl]

Well, throwing things into the mix....

I've no idea what you are thinking of putting on the dev board or it's intended use.

The image in my head has a PSU of some type (external volts and/or USB etc), USB interface for boot loader, ICSP programming header maybe, and some peripheral's; LEDs, switches, serial port etc...

Assuming the above, a dev board with an 80 pin (for example) connector in the middle made up of 4 sets of 20 pins in a square.
The CPU is soldered to a carrier board that plugs into the dev board by this connector.
If the CPU get's damaged you can either have a go at replacing the CPU on the carrier board yourself with no risk of damaging the dev board, order a new carrier board with the replacement CPU already mounted, or swap the carrier board for a completely different CPU.

Since you have control over the carrier board design, you can also make sure that power is always on pins 1 and 2, USB input on 3 and 4 etc etc.
This means that you have complete control over which CPU pins are presented to which pins on the dev board.

Now the dev board can support any type of PIC, ATMEL pretty much anything. You just need the correct plug in CPU carrier board.
You always know that pin 10 on the dev board socket goes to the blue LED, it's up to you on the carrier board design how you connect it to the CPU.

You can support SOIC parts, DIP parts, those horrible parts where the pins are underneath etc.
And the end user can, if they wish, pull the carrier board from the dev board and drop it straight into their project.
It's like having the CPU plugged into an IC socket, that can accommodate any CPU of any package design. [

Maybe you can have a universal dev board

Just a thought.

Joe

[John Lawton]

Very interesting, thank you.

OFC, Microchip did something similar with their Explorer boards and a 100pin connector arrangement for the carrier boards:

https://uk.farnell.com/search?st=microchip%20developer%20explorer%2016&gs=true

But a little pricey just for a carrier board such as this:
https://uk.farnell.com/microchip/ma330035/plug-in-module-dspic33-100pin/dp/2392507?ost=2392507

And then you need the dev board itself:
https://uk.farnell.com/microchip/dm240001-3/dev-board-16bit-microcontroller/dp/2664518?ost=2664518

Which is fine until you break it accidentally.

I still like your carrier system, KISS.

John

[RGV250]

Hi,
The problem I see with Joes suggestion is you are getting into a EasyPIC board style which is stupidly expensive. I have one and hardly ever use it as it is over complicated.

The Amicus24 would be my choice as I have several Amicus18 and find them indispensable and used mostly out of the boards I have.

Bob

[John Lawton]

Stupidly expensive is obviously not good

As I see it, a limitation with the Amicus24 is the 28pin DIL socket, but then SMT to adaptor boards can be used with it to extend the range of devices that can be used. They are also easy to design & manufacture at the same time as the main board but are readily obtainable on their own anyway.

John

[trastikata]

OFC, Microchip did something similar with their Explorer boards and a 100pin connector arrangement for the carrier boards:

https://uk.farnell.com/search?st=microchip%20developer%20explorer%2016&gs=true

This is a ridiculously expensive.

As I mentioned already Microchip has bugs in their samples program. Another MCU which you can get in large quantities from, is the dsPIC33EP512GM310 - a 100 pin TQFP chip. So I designed a TQFP100 - DIP adapter with some passives on it to test the chip in a breadboard. These PCBs cost about 50 cents when ordered from JLCPCB.

[John Lawton]

Excellent, just like Joe's carrier board.

John

[top204]

The original name for the Amicus18 came about because the word "Amicus" is a latin type word for "Friend", and the 18 came about because the only 18F device available back them, that would operate at 64MHz, was the PIC18F25K20. Hence the name "Amicus18". Now, the standard operating frequency for all 18F devices is 64MHz.

The name Amicus24 came about because the only devices that were in a DIL package when I conceived of the board, were the PIC24 types, and the internal workings of the 16-bit devices is 24-bits. The dsPIC33 types were all SMD types, but now their are lots of them that come in DIL packages.

If you are keeping the friendly name of Amicus, it would be more appropriate to use the names "Amicus8" and "Amicus16" for the 8-bit devices and the 16-bit devices. The circuit for the Amicus18 is in the detailed document I created for it all of those years ago.

The SMD devices are great, but what if it breaks, or another device is required for a project? That means a new board, or some soldering skills to remove an SMD device and replace it. Whereas a DIL chip is "plug and play" :-) For development and testing, I have found a 28-pin device to be more than sufficient for 99% of projects, and now I am using the smaller 14Qxx and 15Qxx type devices with only 14-pins as much as I can, because they are inexpensive and have lots of innards for their size and price. :-) The more expanse of SPI and I2C peripherals has also helped reduce the need for multiple pins on the microcontroller, whereas at one time, SPI peripherals only came in a few peripheral types, and I2C in even less peripheral types..

[John Lawton]

Hi Les,

thank you for the background on the Amicus boards. I think it would be nice to at least have the option to continue the name and your suggested renumbering makes sense.

So what, if any, dev. board do you use for the 14 pin devices you mentioned, do we need yet another Amicus board for 14 pin devices, or do you use an adaptor board with your Amicus 8?



John

[John Lawton]

Well I've assembled my Amicus24 board and it looks good and has all the right voltages present.



However this is the first 16 bit PIC I've tried to use and I've just discovered that my trusty Melabs U2 programmer won't program it - their justification is that PBPro is only for 8 bit PICs and so is their programmer

Any suggestions please for an inexpensive ICSP programmer that doesn't need the awful Microchip IDE to be installed?

John
[EDIT] I searched the forum and it looks like I need to choose between Northern Software's NSDSP-2-X and Asix tech's Presto devices.

[top204]

I've just looked in my U2 device list, and it does support the dsPIC33EP128GP502. Make sure you are running version 4.67 of the software. It does lack a lot of newer devices, and that is such a shame because it is a very good programmer. In fact, IMO, it is the best device programmer out there.

I was once contemplating creating a U2 type interface in Delphi that talked to a command line version for the PICkitX programmers, but time does not allow it. I made a similar interface many years ago for a programmer I was going to design, but, as normal, I got no support and the logistics were too much with the plethora of devices being brought out by microchip, on top of the one-man support for the compiler. It would have been a one-man struggle to get each new device supported.

Now there is a good idea Johnb! With your wizardry with Delphi, an interface that looks and feels like the EPIC (U2), but talks to a PICkit through its command line app. You could even charge for it, because it would make the PICkit programmers actually operate and feel like professional tools. :-)

For your earlier question, the 14-pin and 20-pin devices can be fitted to a 28-pin Amicus board with a simple PCB adapter, so the smaller device fits on it upside down, and it plugs into the 28-pin socket. Upside down, so it does not raise too high and shield boards can still be fitted on it. I made a couple of them, but with the house move I do not know where they are now.

[John Lawton]

Hi Les,

My device is running the latest meProg firmware & software, but doesn't list any PIC24 or dsPIC devices in it's dropdown list, so it seems to be a no-goer, rather odd.

Here is the list of supported devices: https://melabs.com/includes/compatibility/meprog.pics.htm and the 33EP isn't on it.

John

[John Lawton]

Ah, in the README file it says how to get PIC24 & dsPIC supported. I'll try that.

Looks like their list of supported devices is out of date.

John

[tumbleweed]

If you have a PICkit2 or PICkit3 there's always PICkitPlus (from evan venn, who I think has been on this forum) or PICkitminus (free, http://kair.us/projects/pickitminus/index.html).

Both are kept pretty much up-to-date.

Northern Software's NSDSP are good programmers. He's very active on the Microchip forum (NorthGuy).

[John Lawton]

Thanks for the pointers Tumbleweed.

Subsequent to my earlier post I found that MeLabs had separated off their 16bit device support files in MeProg and when I read the README file it told me how to add them to the programmer.

The reason they had separated them is because they have decided they will no longer support 16 bit devices which is a great shame. The company has become moribund, so I may have to look elsewhere for a programmer, but not yet, I'm good to go with the dsPIC33EP128GP502 that I have.

John

[RGV250]

Hi John,
You have certainly done better than me and I have had most parts for ages. I will have to have a look at the flux you mentioned. I also have a problem with the really tiny parts clinging to the iron when I remove it. I have just found out I am using solder paste rather than just flux?

I have got a few of these to have a play on. https://www.ebay.co.uk/itm/135002561135?chn=ps&_ul=GB&_trkparms=ispr%3D1&amdata=enc%3A1ldUL7EnuShyVlLsittMYoA65&norover=1&mkevt=1&mkrid=710-134428-41853-0&mkcid=2&mkscid=101&itemid=135002561135&targetid=1647205088560&device=c&mktype=pla&googleloc=1006907&poi=&campaignid=17206177401&mkgroupid=136851690655&rlsatarget=pla-1647205088560&abcId=9300866&merchantid=730584675&gad_source=1&gclid=EAIaIQobChMIscDO6Mi-hQMV05ZQBh2KhwgDEAQYAiABEgKbU_D_BwE

Bob

[John Lawton]

Thank you, I'm pleased with the result. I've never got on with trying to use solder paste.

I discovered by accident a better SMT assembly method than I had used previously.

I had put some of my thick flux in a small dish to make it handy and it dried a bit overnight, becoming even thicker, almost set.

I applied this to the pads I wanted to solder and then placed the components onto the pads. The thick flux held them in place which is a big improvement on before.

Then I broke a lifetime's habit and loaded the soldering iron bit with a little solder, and while gently holding down the component by pressing in the middle using my tweezers, I applied the iron to each leg/pin in turn.

As required I then resoldered each pin by applying more cored solder from a reel of very fine (0.23mm) solder to finish off the joints.

The same technique worked for the FT232, flood the pads with thick flux, load the iron bit with solder and wipe it along the row of pins. Surface tension does the rest and it worked a treat.

John