To use a USB peripheral controller instead of a USB-UART chip such as FT232
yisiguro
Posts: 52
It might be a silly idea but I'm planning to make a FLiPPropStick-like Propeller board just for fun.
If using some kind of USB peripheral controller as a USB-UART interface, instead of FT232R for example, it is only needed less components, i.e. 1 Propeller, 1 UART, 1 LDO, and rest of some resisters and caps. It looks very simple to me.
USB peripheral controller can emulate not only UART interfaces but also I2C EEPROMs, I/O expanders, clock pulse generators, and so on.
In my current plan I'm going to use Cypress enCoRe III CY7C64215 as those 'virtual' components.
Unfortunately CY7C64215 has only 16Ki bytes of internal flash ROM, so it can only hold rather small code for Propeller.
If using some kind of USB peripheral controller as a USB-UART interface, instead of FT232R for example, it is only needed less components, i.e. 1 Propeller, 1 UART, 1 LDO, and rest of some resisters and caps. It looks very simple to me.
USB peripheral controller can emulate not only UART interfaces but also I2C EEPROMs, I/O expanders, clock pulse generators, and so on.
In my current plan I'm going to use Cypress enCoRe III CY7C64215 as those 'virtual' components.
Unfortunately CY7C64215 has only 16Ki bytes of internal flash ROM, so it can only hold rather small code for Propeller.
Comments
You probably need a larger MCU
The P2D2 uses EFM8UB3 (40k), 3x3mm QFN20, and the code size for that is currently
Program Size: data=165.4 xdata=2032 code=10209
That also manages reset pulsing, saving a few more parts.
On a 40k part, that is almost enough spare for a full P1, but note that's without EEPROM emulation code added.
Possible issues :
Emulating an EEPROM would take some care, as the P1 does not pause for slaves, it expects a silicon always ready behaviour.
EEPROM have granular writes and very high endurance counts.
Flash MCUs have larger pages needing erase, and lower endurance.
That means not all P1 library code will work, so you are probably better to stick with an EEPROM.
EEPROMs are from ~ 10c/100 per 32k, at lcsc
If size really matters, you can get EEPROM in 2x3 DFN8, but you will pay for that privilege.
Usually I need only a small code to check the Propeller is 'alive' on boot time, for example, an LED blinker, and almost all codes I use are downloaded each time now.
..and another reason of choosing CY7C64215 is availability of SSOP which I can solder with my skill of soldering. Others are QFN.
There is EFM8UB31F40G-A-QSOP24 ?
If you just want to load a POST (Power On Self Test) type block, that would be fine, you would dump a small stable flash block out the serial, after first power up.
It's probably a good ideal to include an EEPROM footprint on the board, even if you initially do not intend to use EEPROM.
If you want to avoid DFN8 there are TSSOP8 (up to 128k Bytes) and SOT25 EEPROM (up to 16k Bytes)
EFM8UB31F40G-A-QSOP24 (SiliconLabs UniversalBee)
ATmega16/32U4-AUR (Atmel AVR)
PIC16LF145x (Microchip PIC 16LF ( not 16F because of lack of 3V3 I/O ) )
VNC2-32L1C (FTDI Vinculum II)
CY7C64215-28PVX (Cypress enCoRe III)
S6E1C32B0AGP20000 (Cypress FM0+)
R5F51114ADFL (Renesas RX111)
STM32F042F6P/F072C8T (STMicroelectronics STM32F0)
Z8F6481AN024XK2247 (Zilog eZ8 Encore! XP F6482 series)
I have a programming environment for PSoC1/M8C now, so I prefer to use Cypress's MCU.
I see that using EFM8UB is one of the most inexpensive and powerful solutions, and no special hardware is needed for programming it. So probably I'll start with this. Thanks for good suggestion.
Last three, RX111, STM32F0x2, and Z8Fxx8x, have almost perfect spec for my plan.