[HN Gopher] ESP32-C6, a Wi-Fi 6 and Bluetooth 5 (LE) SoC
___________________________________________________________________
ESP32-C6, a Wi-Fi 6 and Bluetooth 5 (LE) SoC
Author : thedday
Score : 168 points
Date : 2021-04-10 01:12 UTC (21 hours ago)
(HTM) web link (www.espressif.com)
(TXT) w3m dump (www.espressif.com)
| stevenhuang wrote:
| Just checked and seems not available on the usual suspects yet
| (AliExpress, etc).
|
| Would be fun to experiment on the RISC-V stack.
| tym0 wrote:
| Glad to see Espressif making RISC-V products, I love what they
| put out but the xtensa architecture made it hard to work with
| languages that targets LLVM like Rust and Zig.
| wyldfire wrote:
| They're working on an LLVM backend for xtensa [1].
|
| [1] https://groups.google.com/g/llvm-dev/c/sUY_uL_do5M
| conradludgate wrote:
| I was recently looking into using some ESP32s to use on a BLE
| hardware project I am working on at the moment.
|
| Although I do wonder whether wifi would be a better technology to
| use sometimes. The only thing I remember seeing is that wifi
| technology uses much more power.
|
| From TFA it looks like WiFi 6 uses less power, is this true?
|
| Anyone experienced have any suggestions whether BLE or WiFi would
| be better for streaming serial data from a device onto many
| platforms? (I currently have a BLE demo working, but working with
| Bluetooth stacks on mobile and desktop are a royal pain, network
| requests are very straightforward at this point)
| sam_bristow wrote:
| One downside of using wifi if that devices like phones _really_
| don 't like network connections that don't route to the
| internet. You sometimes have to fight them to stop the phone
| "helpfully" falling back to 4G or popping up all sorts of
| warnings about degraded networking to the user.
|
| [edit]: This is assuming you are connecting directly to the
| device of course. Connecting the ESP32 to your existing wifi is
| well supported and much more reliable.
| lostlogin wrote:
| Any idea how this works? Are they trying to connect to a
| particular address?
| numpad0 wrote:
| Sometimes as straightforward as pinging a server, sometimes
| elaborate as trying lists of random domains that some must
| respond and some must not resolve.
| g_p wrote:
| Yes, phones request a particular (plain http) URL from
| Google or Apple, which returns a 204 response. If they
| don't get a response, the network is assumed to have a
| connectivity issue. If they get redirected due to captive
| portal, they detect that and can prompt the user to log in.
|
| https://github.com/leoleozhu/android-captive-portal
| pfyra wrote:
| I have tried fighting this a couple of times but lost every
| time. Do you know a solution to make my Android phone keep
| the connection to a wifi without internet connection?
| meltedcapacitor wrote:
| What about setting up some honeypot open-with-no-IP wifi
| hotspots near google HQ and near places where googlers are
| known to congregate (or in residential areas with high
| density of googlers working from home). Once it's their
| problem, they'll fix it pronto.
| Leherenn wrote:
| In my experience, I had no network until I answered "no
| internet connection, disconnect?" dialog that pops up in
| that case. Maybe you could also say "don't ask again". Then
| it was working fine.
|
| What is not working fine though, is that I cannot access
| the internet through the mobile network at the same time.
| But this seems to really depend on the phone: it works on
| iPhones and on my previous Android phone, but not on a
| Pixel 5. I would like to download updates for the esp32
| firmware through the mobile network, but this prevents it.
| AgentME wrote:
| Chromecasts get initially configured by connecting your
| phone to a wifi network hosted by the device, so I wonder
| how Google makes that work.
| sekh60 wrote:
| I lack a solution but would like to commiserate. We had
| some config errors on one of our VLANs, where DNS want
| reachable. The phones helpfully would just say no internet
| access and then bounce to 4g without any other sorry of
| error. What I would give to be able to just SSH into all
| these consumer services and just grep through the logs.
| g_p wrote:
| See https://github.com/leoleozhu/android-captive-portal
| and https://success.tanaza.com/s/article/How-Automatic-
| Detection...
|
| If you could return valid internal DNS entries for these
| domains, and serve up a 204 to the right requests, you
| should be able to stay online.
|
| You need to ensure you don't do it for every possible
| domain - I believe Chrome also tests random non-existent
| domains too, to ensure it gets back the expected error.
| pfyra wrote:
| I have a "captive" or "promiscuous" dns server (it
| responds with its own IP for all requests) for my esp
| projects so this info is exactly what I need. Thanks a
| lot!
| ducktective wrote:
| For equal target transfer rate and range, I don't think there
| would be a mode that any WiFi tech beats BLE in terms of using
| less power.
|
| If power is your concern, have you considered nRF5 devices?
| Nordic has a proprietary profile for sending serial data over
| BLE (NUART) but AFAIK, you could only connect to one device at
| a time (not many).
| conradludgate wrote:
| Power isn't a huge concern, although it's a battery powered
| device, so having a longer battery life is a plus without
| needing to include a larger capacity battery.
|
| I'll look into the nRF5. I've been using some of Nordic's
| code to test and build my prototypes already, although I feel
| like adding a proprietary profile on top will just make it
| harder to interface. Once I make the connection currently,
| all I need to do is enable notify on the specific
| characteristic which isn't too complicated (just a lot of
| code to actually get the characteristic)
| coupdejarnac wrote:
| This nrf52 demo might be salient:
|
| https://youtu.be/tbl6Dui-_w4
|
| https://github.com/NordicPlayground/nrf52-ble-multi-link-
| mul...
| chabes wrote:
| ESP-NOW might be suitable, as it requires less power than
| regular wifi.
|
| From the docs:
|
| "ESP-NOW is a kind of connectionless Wi-Fi communication
| protocol that is defined by Espressif. In ESP-NOW, application
| data is encapsulated in a vendor-specific action frame and then
| transmitted from one Wi-Fi device to another without
| connection."
|
| https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
|
| Edit: this video discusses power consumption of esp now:
| https://youtu.be/6NsBN42B80Q
| chrisco255 wrote:
| Sounds like a security nightmare.
| chabes wrote:
| What makes you say that?
| azubinski wrote:
| Ideally useless piece of hardware. 100500+ ESP2866 useless
| designs are the best confirmation of this harsh statement. You
| can turn on a LED with it. Nobody knows for what, but everybody
| knows how, because it's simple - just use the MQTT and ... (list
| of protocols). RISC V will be the beautiful addon to it cause the
| True Way To True Uselessness should be hard. ^_^
| tasty_freeze wrote:
| Does the packet processing for WiFi and bluetooth take cycles
| from the CPU, or is the CPU 100% available to the application
| code? I read the blurb but it didn't address this question.
| notum wrote:
| It looks like it does take cycles from the CPU but the
| expensive cryptographic processing is still offloaded to a
| dedicated chip.
|
| Old ESP32 has a dedicated protocol CPU:
| https://www.exploreembedded.com/wiki/Overview_of_ESP32_featu...
| exabrial wrote:
| Not mentioned in the title: It's a 160mhz RISC-V chip
| tyingq wrote:
| Kind of interesting that the only thing in the part number that
| denotes that is the "C6" part. Apparently "C3" is another ESP32
| with a RISC-V cpu. I'd have gone with "ESPR" since it fits
| "EspressIf" but denotes RISC-V clearly.
| qalmakka wrote:
| Why didn't they pack more ram on this? 400K is a bit tight, we
| often hit the ceiling with the ESP32's 512K of internal RAM. Does
| anyone know if they support SPI-connected external RAM on this?
| It has been a lifesaver on the ESP32, especially since WROVER-E
| fixed most of the long standing bugs that were plaguing the
| earlier revisions. It is slow as hell, but having 4MB (+4MB high
| memory) of connected RAM on a microcontroller has been a real
| game changer.
| baybal2 wrote:
| > Why didn't they pack more ram on this? 400K is a bit tight,
| we often hit the ceiling with the ESP32's 512K of internal RAM.
|
| 512k is already monstrously high for a microcontroller.
| Kliment wrote:
| Have you seen the die images of the ESP32? Basically the entire
| die area is SRAM. SRAM eats a ton of space, and with a bigger
| die area you have a much higher likelihood per part that you
| will have a defect and have to scrap the entire chip.
| PixelOfDeath wrote:
| Isn't memory the easiest part to remap to use build in
| redundancies during the factory testing of the chip?
| Kliment wrote:
| Sure, if you add extra remapping hardware, nonvolatile
| storage, and eat the performance penalties. Makes sense for
| massive quantities of crappy cheap flash, not so much for
| this.
| PixelOfDeath wrote:
| > Sure, if you add extra remapping hardware, nonvolatile
| storage, and eat the performance penalties.
|
| Nothing a few fuses can't solve.
|
| > Makes sense for massive quantities of crappy cheap
| flash, not so much for this.
|
| Coming from the x86 world, they use plenty of fuses for
| everything. I can't imagine a reason why they would not
| absorb production variation with this for esp32 dies.
| robert_foss wrote:
| More SRAM will increase the price both in terms of die area
| and in terms of defects.
| lioeters wrote:
| Thanks for mentioning the possibility to extend RAM on an
| ESP32.
|
| Found the official documention about it:
|
| https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
|
| > ESP32 has the ability to also use up to 4 MB of external SPI
| RAM memory.
|
| > The external memory is incorporated in the memory map and,
| with certain restrictions, is usable in the same way as
| internal data RAM.
|
| > While ESP32 is capable of supporting several types of RAM
| chips, ESP-IDF currently only supports Espressif branded PSRAM
| chips (ESP-PSRAM32, ESP-PSRAM64, etc).
| AlpineG wrote:
| There are esp32 available with 8MB psram
| MrBuddyCasino wrote:
| Especially since the multi-thread OS means wasting space for
| multiple stacks. 400k is a lot for an MCU, but for the ESP32
| its really not that much. A 1MB Sram version would be great,
| with two cores.
| pjmlp wrote:
| Why use the OS then? Just do bare metal runtime like we used
| to do on MS-DOS days.
| meltedcapacitor wrote:
| What about botnet operators? This would give them a hard
| time if they have to hack each device specifically instead
| of recycling old linux vulnerabilities wholesale. The whole
| IoT industry is strongly committed to make devices
| available to botnet operators, indeed this looks like the
| main function, the function on the packaging usually works
| poorly and is likely just there to convince punters to
| install the botnet relays and pay for the hardware and
| power.
|
| :-)
| dls2016 wrote:
| The ESP-IDF environment is based off of FreeRTOS, not
| Linux. It's essentially a threading library, not so much
| an OS.
| MrBuddyCasino wrote:
| Well the ESP-IDF is freeRTOS based, so: threads. But have
| fun re-inventing the SDK I guess?
| dls2016 wrote:
| Exactly, FreeRTOS makes it trivial to spin up 20
| threads... who was doing that with MS-DOS?
| pjmlp wrote:
| You wouldn't, because the whole point of bare metal is to
| ignore the OS and use directly the BIOS and hardware.
|
| And regarding threads, we would use cooperative
| concurrency, and also take ownership of the timer
| interrupt.
|
| Anything is easy when there is an abstraction implemented
| as library.
|
| Games and demoscene tricks.
| pjmlp wrote:
| From my MS-DOS/Speccy programming days 400KB is a lot, no need
| to make use of the OS, if one can avoid it.
| dingosity wrote:
| lol. yes. i was going to recommend writing a 6502 or Z80
| emulator and then write the application in Tiny Basic or
| FORTH.
| lostlogin wrote:
| If you happy to answer - what are you doing with them?
| hungryforcodes wrote:
| Well unlike the Atmel chips, it is -- like it's predecessor
| the ESP8266 -- a totally internet focused MCU. So with TLS
| and HTTP requests, and receiving streams and WebSockets and
| whatever else, it's not hard to imagine what to do with it.
| More is better. For example I have one ESP32 setup with 8
| megs of PSRAM that does a full scan of a currency exchange
| every 15 seconds. Loads all the data into RAM, which I can
| subsequently process. Run LED displays on after, trigger
| other events etc. It's pretty cool!
|
| It's certainly alot more direct to implement than booting up
| Armbian on a PI, and then starting Node, and then....
| Havoc wrote:
| >For example I have one ESP32 setup with 8 megs of PSRAM
| that does a full scan of a currency exchange every 15
| seconds.
|
| May I ask why you're doing that on a ESP? Very cool...just
| surprised at the choice.
| hungryforcodes wrote:
| Well I wanted to have the exchange info on my watch,
| which is the simplest answer. :P
|
| https://www.banggood.com/LILYGO-TTGO-T-
| Watch-2020-ESP32-Main...
|
| (I get no money if you click that btw -- it's just for
| reference)
|
| The watch has some "trading features" even. If I see an
| interesting trade I can let it take the trade and finish
| it to "take profit", while I go and do something else. It
| has a touch UI and a 240x240 16bit colour screen -- so
| lots of possibilities there.
| elcritch wrote:
| You should checkout Nerves sometime. Flashing an rpi0 and
| booting directly into a programmable environment is great.
| rjeli wrote:
| Still no 5ghz wifi :(
| tomjuggler wrote:
| Yeah also waiting on that. They did mention 40mhz support,
| maybe that will help? In wifi congested spaces at the moment
| the AP mode is unusable..
| raminf wrote:
| Realtek RTL8720DN and RTL8721DM claim 5GHz wifi as well as
| 2.4GHz and BLE 5. Finding a decent dev-board for them is not
| easy. Seeedstudio's Wio Terminal is one of the few.
|
| The ESP32 ecosystem, though, is much larger.
| pranaysharma wrote:
| WiFi 6 supports 5ghz
| ctz wrote:
| It also supports 6GHz, but that doesn't mean a specific radio
| supports all bands. This is a 2.4GHz-only part.
| dal wrote:
| That is WiFi 6E
| bestham wrote:
| Yes, but 5GHz is not mandatory for WiFi 6.
| Tepix wrote:
| When i looked at previous Espressif chips, their mesh networking
| implementation for Bluetooth was proprietary. The Bluetooth
| standard contains a mesh networking standard. Is there any
| affordable SoC that lets me build a standard Bluetooth mesh
| application without having to start from scratch?
| eaurouge wrote:
| Mesh networks are relatively new to the Standard. True LE 5
| SoCs should have what you need to get started.
| yarcob wrote:
| When I played around with ESP32 when it just came out, the
| problem was that the toolchains and software just weren't
| done yet. There were a lot of features that existed on
| hardware, but without toolchain support, docs, or sample code
| it was close to impossible to use them.
|
| I'm not sure how it works now, but especially for newer stuff
| I wouldn't rely on the fact that the hardware claims to
| support something -- if the software isn't there, it just
| doesn't really mean much.
| dls2016 wrote:
| I'm not familiar with other microcontrollers, but ESP-IDF
| seems to be very actively developed. I bought a wESP32 a
| few months ago and initially couldn't figure out how to
| enable ethernet... came back after some ESP-IDF updates and
| had it working in 10 minutes.
|
| But you are probably correct about the latest chips.
| gh02t wrote:
| ESP-IDF is super friendly, I was amazed how easy it was
| to get it set up and configured compared to my experience
| with some other embedded toolchains I've used before.
| SwaraLink wrote:
| The Bluetooth Mesh standard actually is based on a Bluetooth
| 4.0 feature set (basic advertising and scanning), so really
| any BLE device can support it. The problem is that the
| software is complicated, so typically only newer devices have
| software support.
|
| Many chip vendors have BT mesh implementations, including
| Nordic, TI, SiLabs, Cypress, Dialog, and ST.
| IshKebab wrote:
| As I recall it's not a particular good mesh networking
| standard either. I think all the nodes just blindly
| rebroadcast all packets.
|
| I can't remember the exact details but I remember being
| disappointed when it was announced and I looked into it.
| SwaraLink wrote:
| It's a little bit better than that, in that only some
| nodes rebroadcast everything while you can have lower-
| power nodes be primarily in transmit mode. But yes, I
| think the spec could use a lot of improvement.
|
| It does seem like there's a lot of momentum in the BT-SIG
| to grow the standard over a long period of time, and
| there also are a lot of active contributors, so I do
| expect it to mature in the future.
| mahrain wrote:
| I wonder what Risc-V would bring them, other than some de-risking
| vs potential trade blockages for ARM as Huawei experienced. Would
| not having to pay royalties to ARM give this chip a cost
| advantage? By how much?
| stickac wrote:
| They were not using ARM, but Tensilica chips with Xtensa
| instruction set -
| https://en.wikipedia.org/wiki/Tensilica#Xtensa_instruction_s...
| weitzj wrote:
| The -C3, -C6 line is RISC V
| lights0123 wrote:
| > were
| vk6flab wrote:
| For a new project we've been looking at the ESP32 range - great
| functionality - but we're more than a little concerned about
| being reliant on a single company (Expressif) and manufacturer
| (TSMC).
|
| Are there other SoC solutions with multiple companies and
| manufacturers with similar functionality?
| londons_explore wrote:
| Just write your code with a decent seperation between your
| logic and vendor specific things.
|
| Then _if_ expressif can 't deliver, it won't be too much work
| to switch platforms, especially if you're switching to a more
| capable platform.
|
| Sure, you'll probably have to respin the PCB and spend a week
| of late nights porting software, but that's probably still
| comes out cheaper considering the low probability of expressif
| chips being unavailable.
| eaurouge wrote:
| Cortex-M. Lots of Bluetooth LE solutions. WiFi getting there -
| Nordic is working on a solution here as well.
| topbanana wrote:
| I had a look a Nordic nrf5340 recently and second the
| recommendation, it's an impressive platform with Zephyr OS
| ksec wrote:
| Are the tools and software from Nordic better?
| floatboth wrote:
| They're good, but you don't have to use them at all. You
| can use Rust instead! :)
| audunw wrote:
| Nordics tools and documentation are generally considered
| relatively high quality. Not perfect, but the competition
| is usually worse. That's one of the main reasons they are
| dominating the Bluetooth LE peripheral market.
| robert_foss wrote:
| The Nordic SDKs are my favorite embedded ones by far. It's
| so good relative to the competition, that I will go out of
| my way to use their chips.
| mrlambchop wrote:
| Realtek RTL872X - it has 5Ghz!
| neltnerb wrote:
| From what I've seen the Qualcomm chips are really great but
| impossible to buy if you're a normal human, the ST chips are
| pretty solid and have a configuration tool that works well in
| Linux and their -WB versions support wireless and bluetooth but
| use more power than the Qualcomm chips. Then there's microchip
| (owner of atmel) which has a wifi integrated chip, but it was
| really hard to get to work.
|
| ESP32 was also super easy to get to work, and I prefer it to
| the microchip series, see it as a budget version of the ST
| chips (uses a lot more power but that's fine if it's not on a
| power limit), and much easier to source than the chips that are
| meaningfully better.
|
| So yeah, plenty of vendors of equivalent functionality, just
| different ecosystems for the firmware, of course RISC-V isn't
| the same as ARM (which the older ESP32 used) so that introduces
| some quirks into the toolchain, and of course the vendors chips
| aren't pin-compatible.
|
| You're definitely making a new board if you swap the
| microcontroller because it's out of stock, that's nearly
| impossible to avoid -- your best hope is to pick a vendor with
| a good track record or just buy all your inventory up front,
| and if you're super lucky the vendor will sell different
| versions with the same footprint and basic design with
| different amounts of RAM and such with different availability
| so that you can swap chips based on supply chain stuff for
| short term issues.
|
| But a lot of these chips are still made by TSMC I'm sure, so
| I'm not sure it really addresses the root of how few companies
| are at the root of the supply chain.
| numpad0 wrote:
| I don't understand why this is downvoted gray. "We'd like to
| dual source a Wi-Fi SoC product" -- fine, just build two
| completely different hardware and software to go with, with
| matching aesthetics and features.
|
| There's no way around it, there's usually no pin-compatible
| alternatives in embedded like there are for Core i7 and Core
| i3. That only works in consumer PC.
| pta2002 wrote:
| AFAIK the older ESP chips used Xtensa, not ARM.
| neltnerb wrote:
| Thanks for the correction, when I was reading the
| datasheets to implement it somehow this distinction never
| came up.
|
| Compilers are pretty great! I hope it continues to not
| matter with RISC-V cores =)
| snovv_crash wrote:
| Any idea if the BT5 stack now supports long range mode?
| simcop2387 wrote:
| The linked article says that it does
| snovv_crash wrote:
| Ah thanks, missed that somehow. The old ones had BT5 support,
| but somehow got the certification without LR support...
| skybrian wrote:
| Somewhat off-topic, but I wonder what sort of networking would be
| best to build a wireless game controller, where latency is
| everything?
| audunw wrote:
| I really wish Thread mesh networking would become standard on new
| Wi-Fi routers. Google Nest has hardware support for it, but not
| sure if it's enabled yet.
|
| I think Thread is a much better fit for IP connectivity for IoT
| devices. Nordic Semiconductor nRF SoCs can do Bluetooth LE and
| Thread on the same radio at the same time, so should be very cost
| effective.
|
| I'd gladly replace all my Zigbee devices with Thread ones if they
| were available. It'd be really nice with something that's easier
| to troubleshoot with standard IP tools, and to not have to have a
| separate hub for that network.
|
| Nordic Semiconductor recently bought Imagination Technologies
| WiFi assets, so there should be some nice SoCs from them in the
| near future too.
| fy20 wrote:
| Is Thread still happening? Last time I checked the only hub
| available was Nest, although Apple hardware has support but
| it's not enabled in software. Other than a couple of niche home
| automation products, nothing supports it. When will I be able
| to buy smart light bulbs for $10 that use Thread?
| JustFinishedBSG wrote:
| You can buy Nanoleaf Essential LED bulbs right now and they
| mesh with thread and the Homepod Mini
| kps wrote:
| Thread is one of the initially supported wireless layers
| (alongside wifi) for https://github.com/project-
| chip/connectedhomeip
| djrogers wrote:
| > although Apple hardware has support but it's not enabled in
| software.
|
| Nope - HomePod mini has thread enabled. That's the only
| thread device I've seen from apple so far, but I expect that
| all future 'home hub' capable device would support it as
| well.
| kenmacd wrote:
| I couldn't agree more. I picked up a dozen Particle Xenon board
| (nRF52840) for around the house and as a mesh they work
| amazingly. I was very sad when Particle dropped support for
| them to focus on cell boards.
|
| Where the mesh is IP-based it was straightforward to have nodes
| anywhere in the mesh send data out to my influxdb.
| jdc wrote:
| If Wi-Fi routers implemented 802.15.4 we should be able to run
| 6LoWPAN + Thread/CHIP etc or Zigbee on the same hardware.
| spacemanmatt wrote:
| The prospect of having a _good_ wifi AP that supports the
| low-power bands /protocols is _really exciting_ to me!
| baybal2 wrote:
| > I really wish Thread mesh networking would become standard on
| new Wi-Fi routers.
|
| Unfortunately the very fact that Google's label is on it
| assures zero adoption.
| ilaksh wrote:
| Would like to see a Wifi benchmark with latency and bandwidth.
| ece wrote:
| Super great to see new designs with RISC-V keeping up with tech,
| the BL602 and ESP32-C3 are currently available though, and I've
| been working with the Pinenut for a side project. I hope more
| RPi-like BL702 boards become more widely available for RISC-V
| too.
| rektide wrote:
| I got some esp32-c3 engineering sample devkits.
|
| I'm wondering if there's any point at all in Espressif going to
| production with these chips- going from wifi4 to wifi6 seems to
| be the main change, and it should make a huge difference for
| how well behaved a network citizen the chip is.
|
| like you I was elated to see some iot wifi hardware with modern
| connectivity standards. fantastic to see iot not have to lag by
| multiple years. very important upgrades, having ofdma, allowing
| multiple devices to share the ap.
| Taniwha wrote:
| RISC-V (no MMU)
___________________________________________________________________
(page generated 2021-04-10 23:02 UTC)