2*Quad/Octal I2C (IIC)?

[latigid on]

Previously:

I'm wondering about a new design, likely as a separate board(s) wired to 8 DIN5 sockets.

PIC16F88 is still available, and I have the programmer so can flash them. But is this the best way? There are other MCUs with 2/4 UARTs, also dedicated chips for the purpose (fine pitch soldering). Or, is it the simplest way just to dedicate one PIC for every port?

Any thoughts or ideas?

[latigid on]

Keeping it in the family, the following are 8-bit PICs with >2 UARTs

 

PIC16F15354
PIC16F15355
PIC18F23K22
PIC18F24J11 okay
PIC18F24J50 okay
PIC18F24K22
PIC18F25J11 EoL(?)
PIC18F25J50 okay
PIC18F25K22 okay
PIC18F25K80 SOIC
PIC18F26J11 okay
PIC18F26J13
PIC18F26J50 low availability(?)
PIC18F26J53
PIC18F26K22 SOIC
PIC18F26K40
PIC18F26K80 SOIC
PIC18F27J13 SOIC
PIC18F27J53 SOIC
PIC18F27K40

Basic specs:

		PIC16F88 / PIC18F25K22 / PIC18F24J11 / PIC18F24J50 / PIC18F25J11 / PIC18F26J11 / PIC18F26J50
Data RAM Size:	368 B	1.5 kB	3.72 kB	3.72 kB	3.72 kB	3.72 kB	3.72 kB
Program  Size:	7 kB	32 kB	16 kB	16 kB	32 kB	64 kB	64 kB
CPU Frequency:	20 MHz	64 MHz	48 MHz	48 MHz	48 MHz	48 MHz	48 MHz
Supply Vmax:	5.5 V	5.5 V	3.6 V	3.6 V	3.6 V	3.6 V	3.6 V

 

Accordingly PIC18F25K22 looks the best as it's 5V and available in good quantities.

Heh. Probably needs a PICkit 3 programmer though...

 

Edited November 28, 2016 by latigid on

[TK.]

I remember that I ordered this chip some time ago to work on a Dual-MBHP_IIC_MIDI board, but I'm still unsure if it's worth to work on this. Implementation, documentation and support effort is higher than the benefit (at least at my side)

Actually it would be nice if somebody else could implement an alternative solution, do all the required testing and give long-term support.

Best Regards, Thorsten.

[yogi]

Not to dissuade you, as more options are always good. Especially if you added full duplex into the mix. But just my minor user's viewpoint: the 'f88 design is attractive because of it' scalability and the fact that hacking the firmware can be done somewhat easily, for custom apps like the Speakjet. At some point would like to have a 57,600 com port for another project.

Currently using a single IIC midi Tx to support a Waveblaster GM board. I could have used one of the UART's on the core32, but I tend to view them as 'precious' and the IIC bus is underused. 

Regardless if a new design is developed, the 'F88 based one will still be viable. But if the goal is more of a GM5 like solution (maybe on the SPI bus), that too would be a great addition for complex midi routing.

Interested, Yogi

 

[latigid on]

23 hours ago, TK. said:

I remember that I ordered this chip some time ago to work on a Dual-MBHP_IIC_MIDI board, but I'm still unsure if it's worth to work on this. Implementation, documentation and support effort is higher than the benefit (at least at my side)

Actually it would be nice if somebody else could implement an alternative solution, do all the required testing and give long-term support.

Best Regards, Thorsten.

 

Exactly, it's a question of whether the effort of testing a new layout and code is worth it to save a few bucks in 16F chips and a bit of board space. I can certainly look into it, but I would likely need a bit of help with the firmware.

Well, I checked the assembler -- it's nicely annotated but still a bit beyond me. I.e. I can easily set the baudrate to match the faster CPU but there's lots more going on :). Would you keep the I2C addresses the same but fill separate buffers, or run different ports completely in parallel (presumably the former to maintain compatibility)? If you could suggest a basic direction I can see if it's manageable from my side.

@yogi, I was considering the out-only version to keep things simple. SPI would be an interesting solution (fast enough?), if space/cost wasn't an issue you could interface to another dev board -- even STM32 :).

Best,
Andy

[latigid on]

Of course, migrating from 16F to 18F would be a lot of work, although an interesting challenge :).

I'm actually in three minds about this.

First is to simply redo 4* I2C in a smaller form factor. Easiest but not very creative. Second is to use the PIC18F25K22 with code edits. Swapping 4*DIP18 for 2*DIP28 doesn't make that much difference to PCB area:

 

Third is to dive in and look at an extended I2C/UART system. Teensy 3.5 springs to mind, as it has 6 UARTs available and 5V compatible IO for $25 in a small package. Could be useful as it seems there's a lot of nice peripherals to be implemented these days.

 

 

[yogi]

The Teensy idea sounds very interesting. It could be something much more than a UART extension, more of a smart peripheral.

Thinking again of the GM5 design, couldn't a dsPIC or PIC32 (DIP packages if need be) implement multi soft uarts also? IIC could still be used for the core interface but with a slight extension to MIOS32 for an interrupt or a polled input. Or maybe the CAN bus?

Yogi