Need help to choose MCU

Hi,

I'm not new to circuit design, but I have limited experience with MCUs. And I'm overwhelmed by the wide variety of products available, so I'm hoping somebody can weigh in on this.

I'm intending to build a three-phase EV-charger with two plugs. I've been looking into AVR MCUs first and I briefly considered using a raspberry pi. Maybe someone can help. These are my requirements:

Communications:
    (low bandwidth) wifi - external IC? What do I need for good range?
    SPI for communication with HV-side ADC. The HV-side ADC measures voltages and is connected via digital isolator
ADC:
    6 differential inputs, 10 kSps per input (2x3 currents, currents are sensed using hall sensors and thus need no additional isolation).
    2 single-ended inputs, 1 kSps per input (2x control pilot)
    1 temp sensor (internal)
Display:
    small colour touch LCD using lvgl - what capabilities are helpful? I see some MCUs with touch support. what does that mean? I initially planned to just use a monochrome LCD and a few buttons because I thought it might be easier to talk to, but LCD touch screens are cheap and nice to have. Would there be any significant advantage to the simpler option?
additional GPIO:
    8x I/O for breakers (via driver, of course), possible buttons, LEDs,
Speed:
    Most demanding task is probably running the display. Also needs to process measurements ADC (max 60k multiplications per second).
Software:
    Fully Open Source toolchain appreciated. I know that an open source compiler is no problem, what about vendor-specific libraries?
Memory:
    Some ROM for storing settings so they won't be lost when power is lost
    I'm not sure about the footprint of lvgl, otherwise I don't expect much memory use.

Cheers,

Malte

Parents
  • small colour touch LCD using lvgl  ...  I'm not sure about the footprint of lvgl

    IMO, any GUI implementation puts you beyond what would be comfortable on most AVRs (or any 8bit microcontroller.)  Graphics elements just use up storage and program space remarkably quickly (even a substantial uart/text-based UI tends to bloat quickly.)

    The lvgl home page says:

    64 kB flash and 8 kB RAM is enough for a simple user inteface.

    64k is more than most AVRs have, and 8bit architectures can get "unpleasant" once you exceed 64k.

    You should be OK with a relatively modest ARM chip, though (128k flash, 16k-32k RAM is common.)

    You didn't say anything about the voltage nodes of your peripherals.  Most ARMs are 3.3V chips - needing to interface to a 5V SPI connecion for your isolated HC ADC will complicate your circuitry, or reduce your set of choices.

    6 differential ADC (12 pins?) may also be a limiting factor. 60k samples/sec is pretty significant, if each one requires interrupt-based processing.  (ADCs go that fast, but you have ISR overhead, channel-switching overhead, etc...)

    Most ARM toolchains use a variety of Newlib for their libc implementation, which is probably fine from an OSSW PoV.

    Vendor Libraries ...  I don't know; I haven't seen one I liked yet, and I avoid them.  If you need a driver of some complexity (USB and Networking are the ones that "ding" most often), you may want to use a vendor library regardless of license issues.   Most are "free to use on OUR chips", but there may be restrictions to distributing them as part of an OSSW project.  The web is full of examples of "here is all our OSSW, but you'll also need to download XXX from VENDOR, because their license doesn't allow us to include that code in our distribution.")  I don't think any vendors have viral licenses on their libraries; after all, they WANT you to have lots of profits to spend buying more of their chips.

Reply
  • small colour touch LCD using lvgl  ...  I'm not sure about the footprint of lvgl

    IMO, any GUI implementation puts you beyond what would be comfortable on most AVRs (or any 8bit microcontroller.)  Graphics elements just use up storage and program space remarkably quickly (even a substantial uart/text-based UI tends to bloat quickly.)

    The lvgl home page says:

    64 kB flash and 8 kB RAM is enough for a simple user inteface.

    64k is more than most AVRs have, and 8bit architectures can get "unpleasant" once you exceed 64k.

    You should be OK with a relatively modest ARM chip, though (128k flash, 16k-32k RAM is common.)

    You didn't say anything about the voltage nodes of your peripherals.  Most ARMs are 3.3V chips - needing to interface to a 5V SPI connecion for your isolated HC ADC will complicate your circuitry, or reduce your set of choices.

    6 differential ADC (12 pins?) may also be a limiting factor. 60k samples/sec is pretty significant, if each one requires interrupt-based processing.  (ADCs go that fast, but you have ISR overhead, channel-switching overhead, etc...)

    Most ARM toolchains use a variety of Newlib for their libc implementation, which is probably fine from an OSSW PoV.

    Vendor Libraries ...  I don't know; I haven't seen one I liked yet, and I avoid them.  If you need a driver of some complexity (USB and Networking are the ones that "ding" most often), you may want to use a vendor library regardless of license issues.   Most are "free to use on OUR chips", but there may be restrictions to distributing them as part of an OSSW project.  The web is full of examples of "here is all our OSSW, but you'll also need to download XXX from VENDOR, because their license doesn't allow us to include that code in our distribution.")  I don't think any vendors have viral licenses on their libraries; after all, they WANT you to have lots of profits to spend buying more of their chips.

Children