What needs to go in a PIC24 development board?

[John Lawton]

Hi John,
Looks great, is the mini USB a type C as they seem to be more popular these days.
My other thought is to have jumper pins for the bootloader reset?

It's the older mini USB which is simpler to implement than USB C, but twist my arm... what do others think?

I might be able to squeeze in a pin header for the bootloader link, I had thought it was unlikely to be changed much, so put in a solderable link.

boards made

What about a 3D preview?

Sadly my CAD package (largely using my created library parts) doesn't produce at all realistic components so you gain little over 2D, sorry about that.

John

[RGV250]

It's the older mini USB which is simpler to implement than USB C, but twist my arm.

Good point, I hadn't thought about that, don't bother changing it.

Bob

[John Lawton]

I've changed the bootloader /DTR link to a handbag link.

John

[John Lawton]

I'm now looking at the Amicus 16B board which will be for 28pin dsPIC33CH and CK devices - or are there any other 28pin devices with their pinout?

The UART and SPI peripheral lines are available only on remappable pins, but the I2C ports have dedicated pins. There are three ICSP pin pairs, two of which clash with those I2C pins which isn't ideal.

John

[RGV250]

Hi John,
I have some PIC24HJ128GP502 as they have CAN which I am still hoping to get working on a PIC24 device. I cannot find a datasheet for the devices you mentioned, only 44pin and larger so can't check if they are likely to be compatible with your board or the new ones have CAN.

Or were PIC24 for the 16A board?

Bob

[John Lawton]

Hi Bob,

sorry I should have given some example full part numbers for 28pin CH and CK devices compatible with the Amicus 16B board.

CH devices:
dsPIC33CH64MP202 (no CAN)
dsPIC33CH128MP502 (with CAN)
Note, CH devices are not currently supported by the Positron compiler

CK devices:
dsPIC33CK256MP502 (with CAN)
dsPIC33CK256MP202 (no CAN)

Yes, the PIC24HJ128GP502 would fit in the Amicus 16A board.

John

[AlbertoFS]

Hi all,
I am looking for some PIC24 DIL28 compatible with the Amicus18 board. It's possible?
I woulkd like to buy the Amicus24 board.
Thank you
Alberto

[John Lawton]

Hi Alberto,

here is my provisional list of devices that will work in the Amicus16 boards.

Devices that are supported by ICSP on board.
All are 28pin SPDIP and 3V devices except as indicated

Amicus 16A board:

EPxxxGP
PIC24EPxxxGP202
dsPIC33EPxxxGP502  + CAN

EPxxxMC
PIC24EPxxxMC202  G.P.
dsPIC33EPxxxMC202  + PWM
dsPIC33EPxxxMC502  + CAN

EPxxxGS
dsPIC33EPxxGS502 (with SOIC - DIP adaptor)

24HJ
PIC24HJxxxGP202
PIC24HJxxxGP502  +CAN

33FJ
dsPIC33FJxxGP302
PIC24FJxxGA002

24HJ
PIC24HJxxGPx02

33EV
dsPIC33EVxxGM002
dsPIC33EVxxGM102  +CAN

24KM
PIC24FVxxKMx02   5V
PIC24FxxKMx02


Amicus 16B board:

33CK
dsPIC33CKxxxMP502  + CAN
dsPIC33CKxxxMP202  8 x PWM pairs

33CH
Dual core devices (not currently supported by Positron)
dsPIC33CH128MP502  +CAN
dsPIC33CH128MP502  G.P.

E&OE

I'm pleased to hear that you are interested in buying a board, I am completing the designs this week and they will then go to pcb manufacturing and assembly.

John

[AlbertoFS]

John, Thank you very much.

[John Lawton]

I've posted a fuller compatibility list and preliminary specification here

Please let me know if you spot any errors or omissions and I'll make corrections to this document.

[John Lawton]

Today I ordered prototype quantities of the Amicus 16A and Amicus 16B pcbs.

I also ordered some of my own design SOIC-18 to 28pin SDIP adaptor boards because  currently the (really fast) dsPIC33CK device isn't available in a SDIP package.  An adaptor like this is currently required for these parts in the Amicus 16B board.

John

[John Lawton]

The prototype Amicus16 pcbs are now on their way from China so while I wait for these and then build them up, I've been thinking about completing the Amicus family by reproducing the old Amicus18 board as a new Amicus8 design.

My thinking is that this would be basically the original design but with the addition of some new adaptor boards (to the 28pin DIP socket) to allow the fitting of some more modern parts such as these:
PIC18F04Q40, 18F05Q40, 18F06Q40 - all 14 pin SOIC devices
PIC18F14Q40, 18F15Q40, 18F16Q40 - all 20 pin SOIC/DIP devices

I can't think of any other requirements?

John

[John Drew]

Hi John,
The development sounds great.
Did you ever consider putting wifi onto a board?
I realise it's probably too late but IOT is becoming a big deal and having control from a phone adds to the usefulness.
Cheers from Oz,
John

[John Lawton]

Hi John,

good idea but I decided to keep the Amicus range as simple and affordable as possible so I have only put basic hardware on the base boards.

However the Arduino physical format with power and all the PIC ports being available on the connector strips means that 'shields' or 'HAT' boards with extra hardware can be plugged in as required. There are many of these already available and I have a box of old Crownhill 'shield' designs that have fallen by the wayside but could possibly be resurrected in future.

A few ideas for HAT boards:
WiFi module
GSM/GPRS module
Bluetooth module
Rechargeable battery

Any thoughts / suggestions?

JohnL

[top204]

It's good to see my old Amicus platform resurrected. I designed the Amicus board about a year after the Arduino platform was presented because I could see that people wanted to use PIC microcontrollers as well. However, it was never marketed so it died a death, and others just copied the idea and made their own to market, and I can guarantee that they made more money from them than I did. i.e. £0.00. :-(

What I also found was that PIC microcontroller users are never content with a single device type, even when that device can do most everything others can do, but have a slightly different amount of RAM or flash or a peripherals that could have been created in software etc... So the Amicus18 board could never be brought to full fruition anyway, where the small details of a specific device are manipulated to the n^th degree to get the very best out of it, as happened with the Arduino UNO board and its lower capability 328A microcontroller.

However, now the 'Arduino' name is meaningless because it covers a vast amount of different microcontrollers, and even some microcprocessors, and a lot of Arduino users actually think that the C++ language is named Arduino!

So good luck with it John, and I will create programs for them whenever I can.

A good 8-bit device shield, IMO, would be an audio record/play using a micro or standard SD card and two PWM channels to give, upto, 16-bits audio output via two resistor. The simple method works well and I have code that performs the job extremely well of combining the lower resolution/higher frequency PWM peripherals for good quality audio output. Serial RAM chips could also be added for digital effects such as pitch shifing and reverse and real echo and reverb and flanging and chorus etc...

[RGV250]

Hi Les,
Is this the sort of thing you mentioned.

A good 8-bit device shield, IMO, would be an audio record/play using a micro or standard SD card and two PWM channels to give, upto, 16-bits audio output via two resistor. The simple method works well and I have code that performs the job extremely well of combining the lower resolution/higher frequency PWM peripherals for good quality audio output. Serial RAM chips could also be added for digital effects such as pitch shifing and reverse and real echo and reverb and flanging and chorus etc...

https://coolcomponents.co.uk/products/music-maker-mp3-shield-for-arduino-w-3w-stereo-amp?currency=GBP&variant=45223124238&utm_source=google&utm_medium=cpc&utm_campaign=Google%20Shopping&stkn=ab4ba3a5261a

Bob

[John Drew]

G'day John,
Les's idea is a good one. I'd suggest no amp for speakers.
Features could include:
1) Facility for control of levels in and out e.g. -15dBm to 0dBm. Impedance 600 ohms?

2) Choice of single or multiple  segments of recordings to provide messages.

3) Controllable by SPI or I2C for minimal pin usage.

4) Any hat provides feedthrough of all the pins for hat on hat (I guess this is standard)

5) Through hole if possible so I could see the  parts :-)

There are boards available that do this kind of thing to a degree but usually have only microphone input and drive speakers. The quality is quite noisy, and record times are  usually limited to 60 secs total or less if better quality is required. The recorder chips are also obsolete. ISD1760 getting expensive and require cut tracks etc.

Just something to think about for the future.
John D

[top204]

Not exactly that type Bob.

With the MP3 decoders etc, you have very little control of them and you just send commands to them and they do their thing. Where's the fun or learning in that? :-)

With an SD card or a large flash memory chip, the microcontroller has direct access to it and it can either use FATXX files or use the flash memory as raw flash memory to store audio data. A simple interface can be implemented to record sections of the SD card's raw flash or create FATxx files and record in them, then play back sections or files via a simple interface.

Very straightforward coding and will actually teach users how to manipulate flash memory and many other things along with it, and give fun in the learning and using, and it does not rely on a third party chip. In fact no fancy chips are required for a flash record/play, just the 8-bit microcontroller itself and a couple of op-amps for in/out low pass filters, and maybe a good old TDA2822 amplifier, which are about 10p each now and work extremely well at low voltages.

For the RAM access, they can be an optional add-on and the microchip SPI RAM chips are easy to use and not very expensive.

The 12-bit ADC peripheral on the newer devices is quite good, and more than enough for audio. It can also be scaled up to 14-bit easily. Playback is also very good quality using two combined PWM channels, and the 12-bit or 14-bit recorded audio scaling up for 16-bit output is very easy and excellent quality.

[John Lawton]

Thanks for all the ideas!

It wasn't hard to design the Amicus8 as I just had to hack away a lot of the configuration links from the Amicus 16A design and re-route all the port tracks, the power circuitry stays the same.

Here we go:

[John Lawton]

A bit more design work is needed as I noticed that the 18F2xQ24 devices use pin 18 for Vddio2 instead of RC7 and the UART RXD is on RC5 instead.

PIC series	TX1	RX1	TX2	RX2	Comment
18F25K20	RC6	RC7	-	-	Standard device
18F25K22	RC6	RC7	RB6	RB7	Compatible device
18F24Q24	PPS	RC5/PPS	PPS	RB7/PPS	Pin 18 was RC7 now Vddio2. Use RC5 or RB7 for RXD

So with a bit of linking I can accommodate the following 28 pin device families
18F25K20
18F2xK22
18F2xQ71
18F27Q84
18F2xQ24

Any others I should look at?

John