Shop OBEX P1 Docs P2 Docs Learn Events
To use a USB peripheral controller instead of a USB-UART chip such as FT232 — Parallax Forums

To use a USB peripheral controller instead of a USB-UART chip such as FT232

yisiguroyisiguro Posts: 52
edited 2020-03-10 14:38 in Propeller 1
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.

Comments

  • jmgjmg Posts: 15,173
    yisiguro wrote: »
    It might be a silly idea but I'm planning to make a FLiP-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.

    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.



  • yisiguroyisiguro Posts: 52
    edited 2020-03-08 09:42
    Thanx jmg,
    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.
    I also thought this issue. So finally, in my plan, it'll be READ-ONLY.
    That means not all P1 library code will work, so you are probably better to stick with an EEPROM.
    I agree, too.
    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.
  • jmgjmg Posts: 15,173
    yisiguro wrote: »
    That means not all P1 library code will work, so you are probably better to stick with an EEPROM.
    I agree, too.
    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)
  • yisiguroyisiguro Posts: 52
    edited 2021-01-28 11:13
    Some USB MCUs I might purchase:

    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.
Sign In or Register to comment.