Feedback on new developments, thoughts on ESP from standpoint of engineering company
Posted: Fri May 24, 2019 9:15 am
Hello everybody,
This is Paul Ni-Nikulin. Some Espressif employees possibly know me.
First I will put my thought on latest chip, and my previous feedback from working with ESP32 in the wild. I worked with an engineering consulting company NOA Labs for last 2 years, and number of smaller gadget/mobile electronics OEMs before that.
First things that jumped to my attention about S2 is its single coredness and use of LX7.
This is Paul Ni-Nikulin. Some Espressif employees possibly know me.
First I will put my thought on latest chip, and my previous feedback from working with ESP32 in the wild. I worked with an engineering consulting company NOA Labs for last 2 years, and number of smaller gadget/mobile electronics OEMs before that.
First things that jumped to my attention about S2 is its single coredness and use of LX7.
- Would porting of existing code work well?
- WiFi can run on a single core, but the OS/SDK support has to be top notch. WiFi is not such a timing sensitive protocol, but nevertheless there is a lot of use cases using WiFi/BT requiring very consistent timing like audio.
- On the previous point, I knew of many bluetooth chips for speakers, and hand free that can't tolerate jitter despite it being within allowable limits by specs.
- Not many MCU RTOSes ever supported multicoredness anyways. So you may actually gain some market if you pitch their users, but there is a very big BUT: A lot of RTOS users are only using their RTOSes because they are being locked down into them by their chip vendors
- Vice versa, a lot of MCU choice is dictated by its support from SDKs, tooling and development environment. A lot of people I knew jump on Espressif ship just because you managed to make a nice, working development environment with GCC. In comparison a lot of competitors' SDKs, and developer environments are plainly horrible. Think about making some "migration guides" for say IAR users.
- I don't think licensing costs play any much significant part in MCU cost, not these days when Arm makes everybody such a competition with M* family cores being licensed for single digit number of *cents* per chip.
- All people I knew who ever did own tapeouts for MCU like products say that their biggest cost was not even silicon, or IP, but packaging, especially anything advanced like with RF pathways.
- AES/SHA/DH familty is indeed something very handy for running TLS and loading big files.
- Too bad, the "cloud" guys are moving to ChaCha/Poly1305 family of ciphers.
- About use of cryptography on internet really makes you think different these days, and I expect that online APIs will slowly gravitate to increase use of cryptography. For example one big problem in web API for smart devices is having to authenticate a great amount of devices regularly. You will need either an extremely fast database setup with multiple servers, or you will have to use some complicated session token system to reduce the amount of entities you have to lookup, but there is a trick to not to have to do either: you issue a permission to the device with digital signature! Thus you can be wholly reliant on data sent by client, without having to check databases at all!
- More memory will only be nice for running big OS like environments. Was that something that came from same "cloud" guys?
- Other improvements, are well, OK
- Dedicated graphics port with TTL/parallel could've looked awesome a decade ago, but today it is often cheaper to buy a full HD MIPI display with built in digitiser (thanks BOE) than buy a display with direct drive (parallel/ttl) or buying an LVDS/DP converter chip + panel separately. On top of that: 1. more modern display are just looking better, 2. older direct drive panels are harder and more expensive to procure in smaller quantities than megatons of leftover smartphone displays.