[HN Gopher] WireGuard for the ESP32
___________________________________________________________________
WireGuard for the ESP32
Author : bishopsmother
Score : 330 points
Date : 2022-12-29 10:52 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| thingyop wrote:
| [flagged]
| thingyop wrote:
| nice.
| dmos62 wrote:
| What are some of the things you can do when you have wireguard in
| your embedded device?
| gh02t wrote:
| The use case that comes to mind for me is transparently and
| securely tunneling back to a central control server/common
| network with other devices it needs to talk to independent of
| the local network. So I could make a sensor for my parents and
| have it automatically tunnel its MQTT traffic back to my home
| network to monitor without them having to host an MQTT server
| locally. There are of course other ways to achieve this, but
| Wireguard is pretty elegant and straightforward to keep secure.
|
| Another thing that comes to mind is if you're building a device
| that jumps wifi networks a lot. WG makes roaming networks
| pretty seamless, though I'm kinda struggling to think what an
| actual use for this might be.
|
| Edit: Thinking about it more, you could use it as the backbone
| of some kind of cross-network mesh system. A bunch of
| distributed devices connected to their respective local wifi
| network but then form a common network over WG and are able to
| route packets. Maybe you could bridge the endpoints to
| Bluetooth or some other RF protocol as a mesh with the Internet
| as the backhaul but not having to think about the local
| network. This sounds pretty wild but would be fun to play with.
| thatcherc wrote:
| One thing I've wanted to do is put a battery charge monitor on
| the escooter I leave at work. I'd like it to report the charge
| back to a computer I have at my house. Running WireGuard on an
| ESP would let me send battery telemetry back to machine I
| control, even if the scooter was on public wifi, and without
| having expose any of my ports to the wider internet (except
| 51820).
| yjftsjthsd-h wrote:
| > except 51820
|
| Even then, it's technically open but it's using UDP so it's
| not like it'll show up in port scans or anything.
| kkielhofner wrote:
| UDP port scans are a thing:
|
| https://nmap.org/book/scan-methods-udp-scan.html
| FredFS456 wrote:
| Wireguard protocol is specifically designed not to show
| up on port scans. See section 5.1 of the white paper:
| https://www.wireguard.com/papers/wireguard.pdf
| kkielhofner wrote:
| Very cool - I didn't know that!
|
| But, speaking generally, it's still good to know that UDP
| port scans are very much possible.
| momothereal wrote:
| You can have devices in different locations linked together (by
| opening ports on the WG interface) without opening holes in
| your network
| lhoff wrote:
| It basically boils down to - you can reach it behind a NAT.
|
| I'm currently planning on installing a second small home-server
| at my parents place as a backup target. I thought about an
| easy, energy efficient way to turn it on and off. My current
| plan was using a raspberry pi but it would have been a bit
| overkill. So this is perfect. I already have a wireguard setup
| between my home server, laptop, smartphone and a cheap rented
| VM that acts a a router. I can just add the ESP to it know and
| use either the serial Interface of just a digital out connected
| to the power pin.
| TechBro8615 wrote:
| I've wanted something like this as a hardware level firewall to
| ensure that _all_ traffic over an outbound interface is
| transiting over a wireguard server.
| sgtnoodle wrote:
| Seems like you could do that with any router hardware that
| supports OpenWRT? An ESP32, although capable of running the
| algorithms, is going to have rather poor performance.
| TechBro8615 wrote:
| Yeah, definitely true. I like the simplicity factor though.
|
| Is there a performant hardware platform which is openwrt
| compatible and has a single pair of input/output ethernet
| ports? I seem to remember an Intel device that worked for
| this, let me see if I can dig up the link
|
| EDIT: I think I was remembering the Intel Compute Stick,
| which was discontinued in 2020:
| https://en.wikipedia.org/wiki/Intel_Compute_Stick
| sgtnoodle wrote:
| Just get a router with a WAN port and N lan ports.
| Internally, they're all a switch and a CPU with two
| independent ports. Sometimes the WAN port goes straight
| into the CPU, but quite often all the external and
| internal ports are switched and the WAN port is just VLAN
| isolated to one of the CPU's internal ports.
|
| I've accumulated half a dozen WRT1200AC and WRT1900AC
| devices from eBay for about $30 each. They have dual core
| 1.2Ghz ARM CPUs and something like 256MB of RAM. I use
| one with wifi disabled as my router (and run wireguard on
| it for my phone), two for APs in the main house, and
| another as a wireless WPS bridge to the garage. I can
| pump 400-500Mbps of TCP traffic over the wireless bridge.
| The router hardly even registers the wireguard traffic
| from my phone, but then my ISP link is only 46Mbps.
|
| I just ordered Netgear r8000p router on eBay for $40 to
| play with, at the recommendation of another HN commenter.
| It has 6 antennas for beam forming, a dual core 1.8Ghz
| ARM CPU, and 512MB of RAM.
| alex_sf wrote:
| There seems to be people in these comments that know, so: is
| there something similar to the ESP32 but for cellular networks? A
| small, cheap microcontroller that I can add a SIM to and get
| connectivity?
|
| The only ones I've messed with before were from Adafruit, but
| they are all 3g which is, afaik, completely decom'd now.
| ohazi wrote:
| Haven't used it, but I've heard good things about Nordic's
| nRF9160 platform.
|
| e.g.: https://www.adafruit.com/product/4753
| elcritch wrote:
| There's lots of cellular modems that only requires a serial
| port / uart connection. I think espressif sdk supports "AT"
| commands for them.
| ErikCorry wrote:
| Toit (platform for the ESP32) has some cellular drivers that
| all use a serial/UART connection.
| https://pkg.toit.io/search?query=cellular. (Disclaimer: I
| work for Toitware.)
| bitwrangler wrote:
| on a similar note, what are people using for 4G/LTE IoT
| providers? I've used freedompop and hologram.io before, but not
| sure what is best for low volume data traffic?
| willemmerson wrote:
| What about https://randomnerdtutorials.com/lilygo-t-
| sim7000g-esp32-lte-...?
| jareklupinski wrote:
| I've been buying cheap combo 4G/wifi routers that contain Sim
| card slots, setting the router up as usual, and then connecting
| the esp32 to the router's wifi network. So far it's been a more
| stable solution than any standalone microcontroller / module
| I've used, and easier to replace with local parts if anything
| happens.
| karmanyaahm wrote:
| Blues Wireless has included data and a robust seeming SDK.
| squarefoot wrote:
| Did anyone test it on the ESP32-CAM? A quick search didn't
| produce much, although I believe that small module could benefit
| a lot from the added layer of security, assuming the hardware
| could withstand the added overhead on streamed video.
|
| https://docs.ai-thinker.com/en/esp32-cam
|
| https://www.youtube.com/watch?v=visj0KE5VtY
| antoniuschan99 wrote:
| It's decent, the newest version is esp s3 eye. Looks like the
| main issue is the psram is fixed to ~8mb? So it has been
| struggling with processing higher res images? Also it lacks
| dcmi so you can't get images from high mp cameras (vs something
| like rasp pi)
| willemmerson wrote:
| It's not completely related but I've been thinking that having a
| router connected via wireguard might be a good way to do IoT
| deployments.
|
| Generally IoT devices make an outbound connection to a server and
| use MQTTS for bi-directional data flow, because of the difficulty
| of inbound connections due to firewalls, NAT etc. But this has
| some downsides in that you have to run an MQTT server, each
| device is doing it's own TLS (which uses a lot of ram and
| increases firmware size on an ESP32), and MQTT doesn't really
| have end-to-end message confirmation.
|
| It seems like a better way would be for each esp32 device to be
| in a wireshark network and to be running it's own HTTP webserver
| (which is easy to do with the SDK). Therefore any device can be
| sent a message from the server using a simple POST request to its
| ip address, and can send messages to the server using the servers
| HTTP api. It's much easier to test HTTP api's than mess about
| with MQTT, and individual devices don't need to do SSL because
| all data between the devices and server is encrypted by
| wireguard.
|
| I suspect there's something I've overlooked, I think addressing
| individual devices could be difficult if you only know their IP
| addresses.
| Zeebrommer wrote:
| That's an interesting idea, you'd probably be able to know ip
| addresses via wireguard. Protocols like CoAP or SenML can be
| used to keep payloads small.
|
| MQTT, aside from being pubsub, has more functionality that is
| especially useful in IoT though: robust sessions with LW&T to
| monitor onlineness, and retained topics to deliver messages as
| devices come online again
| philsnow wrote:
| If your network setup (be it wireguard or whatever) is such
| that you're okay with plain HTTP vs HTTPS, you should also be
| fine to use plain MQTT vs MQTTS, right?
|
| I agree that it's easier to test HTTP but lots of IoT stuff
| plays nicely with mqtt.
| fulafel wrote:
| Are there memory safe language options for programming security
| critical internet facing interfaces like this on ESP32?
| ErikCorry wrote:
| I'm glad you asked: Here's one: https://toitlang.org/
| Zeebrommer wrote:
| Rust is getting there, but I don't think it's production ready
| yet: https://github.com/esp-rs
| atonse wrote:
| A Tailscale IoT mesh would be killer.
| gorgoiler wrote:
| Wow, congratulations. There's something lovely about seeing
| systems being configured in C source code. While I wasn't around
| at the time I imagine this is the way many of machines of the
| 1970s were configured as well (unless you had some kind of fancy
| Unix machine that could host its own compiler.)
| tiagod wrote:
| Check out the qmk keyboard firmware configuration if that's
| your thing :)
| sidpatil wrote:
| > I imagine this is the way many of machines of the 1970s were
| configured as well
|
| Which machines are you referring to?
| tgv wrote:
| I don't get that remark either. First, it's snarky, and
| second, the C handbook is from 1978. Only a small number of
| Unix(TM) systems had C compilers at that point. And third:
| what does configured even mean in this context?
| gorgoiler wrote:
| No snark at all. I'm sorry you read my comment that way.
| What I got from this release announcement was a feeling of
| coming full circle, back to an older time when configuring
| a system meant compiling with different compile-time
| options (possibly with compilation happening on another
| system) as opposed to using something more complex like
| compiling once and reading config options from an rc file.
| (I was reminded if this also by dwm, which too is
| configured at compile rather than runtime.)
| dekhn wrote:
| I use an ESP32 for motor control, and being able to push
| an rc file to the sd card is far better than static C
| configuration- compare GRBL-ESP32 to FluidNC.
| [deleted]
| no_time wrote:
| Is there a significant difference between doing HTTP over TLS vs
| HTTP over WireGuard?
|
| I enjoy WireGuard and it's tooling but in this case TLS seems
| like the better, battle tested option without any significant
| downsides if all you are doing is HTTP anyways...
| adriancr wrote:
| One use case is probably as gateway, I could put IRC on it and
| wireguard and have an emergency entry into a network.
| guestbest wrote:
| How is IRC a gateway?
| adriancr wrote:
| use IRC to give it commands and see logs so vpn is not
| always on (i.e: when you want vpn, you tell it to connect
| to an external IP, perhaps spin up a vm for that). Don't
| expose it directly as it would be easy to flood it into
| submission in addition to it being insecure.
|
| Once connected - use it to tunnel traffic back to network.
|
| Anything else would work though (telegram/cloudflare
| tunnels/...), It's just what I would use.
| okso wrote:
| WireGuard supports TCP and UDP directly, which allows securing
| MQTT or AMQP directly without adding an extra layer of
| HTTP/QUIC.
|
| Certification also works differently: TLS (and OpenVPN) rely on
| Certificate Authorities while WireGuard relies directly on the
| public key of hosts. This has implications in how trust is
| managed in the network.
| svetb wrote:
| > WireGuard supports TCP and UDP directly, which allows
| securing MQTT or AMQP directly without adding an extra layer
| of HTTP/QUIC.
|
| MQTT over TLS is pretty standard, and supported out of the
| box by virtually all clients/brokers. I suspect the same is
| true for AMQP.
|
| Some time ago I did a set of benchmarks of MQTT+TLS vs
| MQTT+WireGuard. Although I was rooting for WireGuard to blow
| TLS out of the water, the overall bandwidth requirements are
| quite similar. Under normal conditions WireGuard overhead is
| a bit higher than TLS, though various network pathologies can
| swing things the other way. The main one being roaming: if
| the client frequently switches networks, WG tends to handle
| this far more gracefully than TLS (not surprising given the
| underlying design and protocols).
|
| In short, TLS can actually be made to work really well in a
| context like this - I jotted some notes on an optimal setup
| here: https://medium.com/p/b880285da526
|
| Beyond this, there are some really interesting efforts to
| unify MQTT and QUIC - from an architectural perspective I
| feel like that's the future for IoT comms.
| (https://www.emqx.com/en/blog/getting-started-with-mqtt-
| over-...)
| tiernano wrote:
| I see this as a handy option for 2 way comms. How much power it
| would use is a different question.
| nicexe wrote:
| The point of WireGuard is to set up a VPN across the services
| you need. You could use it for point-to-point connections but
| it does much more than that.
| adriancr wrote:
| This is awesome, any benchmarks on bandwidth so far?
| keewee7 wrote:
| It's interesting how the ESP32 has become the _de facto_ IoT MCU
| used in almost all new IoT products.
|
| Other companies like TI and STMicro had their own cheap WiFi/BLE
| MCUs but their devkits used to be too expensive for hobbyists and
| students. But the Chinese startup behind the ESPxx chips made
| sure that their devkits were cheap enough for hobbyists and
| students and through that influence they now also dominate the
| professional industry.
| [deleted]
| ilyt wrote:
| It's not just devkits being cheap (there have been plenty of
| knockoff cheap ST boards) its
|
| * integrated WiFi/BT with no/near zero extra engineering needed
|
| * generous amount of RAM/Flash so you can afford to be sloppy
|
| * SDK making it fast to get to the "the wifi is working and I
| can get on with my development"
|
| * momentum from ESP8266 that already (due to same "super cheap
| with wifi") had a chunk of market.
|
| Even now in middle of chipaggedon you can get WIFI/BT breakout
| board for like $3-5. That's not "just" "cheap enough for
| hobbyist breadboard", that's cheap enough to get the whole
| product built around.
|
| I think partly due to how cheap WiFi/BT has become the likes of
| Zigbee didn't got as popular as they probably should, between
| licensing costs it was just cheaper for IoT companies to not
| touch it, even if it would make more sense in places.
| psychphysic wrote:
| Also Arduino IDE programmable fairly early on. Before boards
| manager stuff iirc.
|
| It went from hackaday being lol you can use this WiFi module
| like a MCU. To why would you ever do anything else?
| MisterTea wrote:
| > * generous amount of RAM/Flash so you can afford to be
| sloppy
|
| Actually, the major benefit is the ability to use higher
| level languages or interpreted languages such as python and
| js. It also allows for more complex network stacks and
| protocols.
| phpisthebest wrote:
| in IoT wifi became commerically successful over zigbee for 2
| reasons, the cost was not one of them IMO
|
| 1. Vendors want Cloud control over the product, they want it
| to phone home. Zigbee is built for Local Control
|
| 2. Consumers prefer "hub free" products that just "work",
| They are willing to give up privacy, security and possible
| performance issues for that convenience. They do not think or
| care about what will happen when their shitty comcast service
| breaks for the 100th time this year, or if the IoT vendor is
| hacked, they want to pull out of the box, and have an app
| connect it in 2 seconds via a QR Code so they can blink the
| light quickly and not have a fuss about with a hub.
|
| WiFi is better than Zigbee at both of these things. Zigbee is
| beter for home automation where you want Local Control, and
| security. Local control and security has been losing that
| battle though the tide seems to be turning lately (I hope )
| ClumsyPilot wrote:
| > Consumers prefer "hub free" products that just "work",
| They are willing to give up privacy, security and possible
| performance issues for that convenience.
|
| This is tptally wrong - I need to control Ikea Lights,
| Xiaomi smart vacuum and use Aquara to control blinds and a
| third company for radiator valves - well guess what, you
| are going to need 4 separate hubs and the only way they can
| talk to each other is through the internet.
|
| It doesn't matter how much money you spend, Iot shit is not
| inter-compatiable and no one company makes everything.
| phpisthebest wrote:
| >This is tptally wrong
|
| its not, Ikea Tradfri lights I believe are just Zigbee
| today which can connect to other hubs. Some Aquara
| products are also just zigbee, and will support matter so
| any Matter or Zigbee hub will work with them.
|
| Not sure sure about the Xiaomi
|
| Of course the vendors will try to sell you a hub, but you
| can connect just about any zigbee device to any zigbee
| hub
| tinco wrote:
| I don't see the advantage of Zigbee for local control.
| Implementing local control over wifi is just as easy and
| can even work without a hub. I'm designing a custom
| automation system for the ventilation in my house and I
| failed to discover any reason to use Zigbee.
| phpisthebest wrote:
| Why do you believe WiFi is easier for local control than
| Zigbee. WiFi is more complex to setup and consumes alot
| more power.
|
| WiFi you have all kinds of underlying network issues to
| setup that do not happen or you do not have to account
| for like WiFi, things like IP Address, Routing, vLAN's,
| Firewalls, Ports, etc
|
| None of that is a problem for Zigbee.
|
| >>I'm designing a custom automation system for the
| ventilation in my house and I failed to discover any
| reason to use Zigbee
|
| Then you are not looking very hard or do not value
| Dependability and security.
|
| Matter will likely absorb both Zigbee and WiFi anyway as
| Google, Amazon, and Apple are all backing Matter
| thrashh wrote:
| WiFi may be be complex and power hungry, and I've had the
| displeasure of trying to build low-power IoT devices with
| it, but you can easily put in the time and effort to
| build a rock-solid future-proofed IP network.
|
| My home Zigbee and Z-Wave networks have never come as
| close in reliability or versatility as my home IP
| network. I can always put in money incrementally to
| increase bandwidth or lower latency because the
| commercial off-the-shelf world for IP is so big -- I can
| do point-to-point microwave links or send my IP network
| over 120V. And I know for sure, IP networks will never
| ever be deprecated.
|
| I have some stage lights (just for fun - home light
| shows) -- they speak DMX and not IP, but I just
| encapsulate DMX over IP and bam, a data connection
| anywhere in the house without extra data lines. I can
| send video over IP or make up my own protocol and my IP
| network can handle it no problem (though maybe with some
| upgrades if I were to send a lot of video).
| dragontamer wrote:
| Zigbee solutions seems to be ~10mA, while WiFi / ESP32
| seems to be ~100mA.
|
| The 10x difference in power can be papered away by
| running the radio 1/10th the frequency. Ex: instead of
| updating every minute (Zigbee), you can update every
| 10-minutes (WiFi).
|
| --------
|
| I think a lot of these WiFi internet-of-things are fine
| with the ~15 minute update routine to minimize the use of
| the (relatively power heavy) 100mA+ WiFi radio.
|
| Zigbee is simpler, but not so simple that you can program
| it yourself. It is found in cheaper $5 microcontrollers
| with less oomph than the ESP32... and those
| microcontrollers also use less power since its just
| innately a slower protocol. Though... I guess ESP32 is
| also $5 so cost really isn't a factor anymore.
|
| -------
|
| The absolute limit of 10mA vs 100mA is also pretty
| interesting.
|
| 10mA is just barely what is reasonable to push out of a
| CR2032 coin cell battery. 40-ohms internal resistance at
| 3V, so 10mA is a .4V drop... which can be solved with
| enough capacitors to buffer up the current. A lot of
| these devices still work at 2.3V or so (-.3 volts from
| age, -.4 volts from internal resistance), so you have
| enough headroom for an IoT Zigbee radio with CR2032 coin
| cells.
|
| You ain't getting 100mA out of a coin cell battery (lol
| 4V drop on a 3V cell), unless you're also adding a super-
| capacitor to the circuit or other rather significant
| forms of power-storage. Then again, 100mA is more than
| reasonable out of Li-ion / AA NiMH / etc. etc. So ESP32
| is still a battery-operated device... just a larger one
| than any Zigbee solution.
|
| Mind you, the CR2032 coin cell is designed to average
| ~0.4 mA or less. So you really need to keep the radio
| "sleeping" most of the time. 10mA is really close to the
| "temporary burst" limits of the cell, and you're already
| suffering from significant degradation of the cell's
| lifespan by running it at 10mA, even temporarily. But the
| fact that Zigbee "fits" inside of this means that you can
| design devices around CR2032 cells, rather than AA or Li-
| ion packs.
|
| -------
|
| EDIT: The setup/teardown speed of Zigbee is also much
| faster. IIRC, you can connect, send data, and disconnect
| in ~30 milliseconds on Zigbee. But it requires seconds on
| WiFi (find an Access Point. Call Access Point. Setup
| negotiations, etc. etc. 3-way TCP handshake: Syn, Syn-
| ack, Ack. And then HTTP finally begins...).
|
| A 470uF capacitor can power 5mA across a .4V drop for 36
| milliseconds. (I = C * dv/dt). Assuming half the power
| comes from CR2032 + the other half the power from the
| capacitor (that's not how electronics work but I'm doing
| quickie napkin math), that's 5mA from the CR2032 + 5mA
| from the capacitor. So the 470uF capacitor gives you the
| headroom to run other parts (sensors / uC, etc. etc.)
| within the 10mA limits of the CR2032 cell.
|
| Good luck getting a capacitor to do that kind of work
| across the ~5 seconds needed to setup / teardown a WiFi
| connection.
|
| Since "Energy" == "Power * Time", the 100x time to
| connect + 10x power leads to ~1000x energy usage in
| practice, for WiFi vs Zigbee.
| hamandcheese wrote:
| I was recently playing with an ESP32-C3 and was
| astonished at how fast it could boot and make an http
| request. (Can't remember if it was ssl or not). I was
| measuring just under 1 second. Still an eternity compared
| to Zigbee, but I was quite surprised. I expected it to be
| more like 5-10 seconds.
|
| It makes me wonder why far more powerful devices (iPhone,
| MacBook) take so long to connect to or change WiFi
| networks.
| dragontamer wrote:
| Its probably just the nature of optimizing for your
| customer.
|
| iPhones / MacBooks don't care about battery life, or
| connecting/disconnecting from WiFi all the time.
| Optimizing from 5s connection to 1s connection is
| completely irrelevant. Its not like people normally
| disconnect/reconnect to WiFi. The few times I do it (ie:
| walk into my house / WiFi is back in range), my phone
| reconnects long before I even take it out of my pocket.
| Once connected, it stays connected and active.
|
| ESP32 however, is an IoT chip. Optimizing from 5s to 1s
| connection time is a reduction of 80% of your power usage
| in practice. Because almost every IoT device will
| immediately sleep after the WiFi message is sent.
|
| That is impressive though. Good on them for making this
| process more efficient. It'd never beat a specially
| designed protocol like Zigbee (or any of the 802.15.4
| stuff). But so many people use 802.11 / WiFi these days
| that these kinds of optimizations are hugely relevant.
| KaiserPro wrote:
| Wifi is a massive pain for everyone.
|
| You don't feel it because you've spent the time to make
| it work. But the average person from the street's wifi
| sucks hard.
| pseudosavant wrote:
| If you think the average person's wifi network is bad,
| just wait until they have to buy a second wireless
| network. As bad as wifi can be, you have to have it for a
| million other devices and use cases. If your wifi is bad
| for IOT, it'll be bad everywhere probably.
|
| My wifi is great already, but I decided to try some of
| the Ring lighting products. They use Zigbee/Sidewalk
| which is supposed to be perfect for this kind of use
| case. Guess what? It isn't. Now I just have a second
| wireless network to troubleshoot.
|
| At no point does having a second wireless network just
| for my IOT devices become less work than using the wifi I
| already have. And if I improve my wifi coverage for IOT,
| I improved it for everything else at my house too.
| phpisthebest wrote:
| if your IoT shares the same WiFi network as your normal
| devices you have already failed at security. Home
| Automation, and IoT should be separated at the network
| level from everything else
|
| >>Sidewalk
|
| Is terrible.
|
| >>Ring
|
| Ring is probably the worst HA brand out there, sorry your
| experience with Zigbee was bad because you choose a poor
| implementation of it.
|
| Hell I have zigbee devices I bought of Ebay from failed
| companies that work better than Ring products.
| zeendo wrote:
| As a consumer wanting local control ZigBee is an
| advantage for off the shelf products. Almost every off
| the shelf product that uses WiFi does not offer local
| control (and if it does then it often only offers that in
| conjunction with cloud control).
| mrWiz wrote:
| I think their point was that WiFi devices can be made
| cloud-only (or de-facto so by limiting what can be done
| locally) but that is hard/impossible with ZigBee, so
| companies will tend to standardize on WiFi. This will
| mostly be cloud-based, but this will push non-cloud
| options that direction as well.
| jakewins wrote:
| Yeah. I made the mistake of purchasing a "Wi-Fi
| controllable" mini split from Menards, not realizing
| there is no way to control it without internet access.
| naasking wrote:
| > But the Chinese startup behind the ESPxx chips made sure that
| their devkits were cheap enough for hobbyists and students and
| through that influence they now also dominate the professional
| industry.
|
| The rest of the industry failing to learn from how Microsoft
| came to dominance by basically ignoring piracy among students
| and private individuals.
| Youden wrote:
| ESP32 is dominant for WiFi devices but I'd say Nordic nRF is
| dominant for Bluetooth and BLE. You see it a lot in IoT sensors
| (like Ruuvi tags) and things like BLE keyboards (at least the
| DIY mechanical ones, in the form of the nice!nano).
| float4 wrote:
| > You see it a lot in IoT sensors (like Ruuvi tags)
|
| Even Apple AirTags (nRF52832 to be precise).
|
| https://www.ifixit.com/News/50145/airtag-teardown-part-
| one-y...
| solarkraft wrote:
| I think this may be because they're very good at consuming
| little power. That's not exactly the ESP's domain (though you
| can kind of make it work), with WiFi itself being more power-
| intensive.
|
| Let's remember that when the ESP8266 came out, it was
| basically the _only_ WiFi MCU you could just use. Maybe there
| were others, but they had no community, so Espressif won out
| for the makers. And the makers went on to ... make ... IoT
| devices.
| rektide wrote:
| It's wild how few have stepped up to making wifi, even now,
| while Espressif made it easy & cheap back in 2014. Nordic
| is just getting around to it, for example, with then
| nRF7002 chip announced this summer, but it's notably just a
| companion chip, has no microconyroller available for your
| application, & modules as compared to espessif are pretty
| pricey. It is at least wifi-6 ehich Espressif announced ~18
| months ago but afaik still isnt sampling. There's a Realtek
| part but lacks the documentation/support to be hobbyist
| usablrle.
|
| As for power consumption, yeah, Nordic is pretty good. I
| feel like Silicon Labs is often the primary pick for low
| power.
| zwirbl wrote:
| At a Nordic event this fall it was noted that the nrf54
| line of MCUs is likely to be announced this year, as the
| nrf53 line will not be expanded on. Could be nice for
| power draw, new process node and everything
| m-p-3 wrote:
| There's also the BangleJS2 smartwatch that runs on an
| nRF52840
|
| https://www.espruino.com/Bangle.js2
| [deleted]
| phpisthebest wrote:
| I wonder why Hardware vendors like TI and STMicro did not learn
| the lesson from Software Vendors like Microsoft, Adobe, and to
| a lessor degree Google.
|
| Who have long offered their software free or heavily discounted
| for students because then they would demand that software when
| they entered the workforce and businesses would pay out the
| nose for it.
| mrWiz wrote:
| TI was extremely generous with free IC samples when I was a
| student, so at least _some_ of the company learned that
| lesson.
| ClumsyPilot wrote:
| yeah its just that as a student or hobbyist, an IC without
| a board is of limited use
| dbuder wrote:
| The TI chips were like 16usd in volume it looked like a mess
| from the datasheet anyway
| Rebelgecko wrote:
| Not just price- Espressif has done a really good job making
| their SDK and hardware documentation available to overseas
| hobbyists. Even hiring an English speaking dev to work SDK
| features that people were asking for in English, and doing a
| good job communicating with/engaging with the community.
|
| They're not _great_ if you 're coming from solely-software
| land, but their SDK and dev experience (you can just use the
| Arduino IDE for a gentler learning curve, step up to FreeRTOS,
| esp-idf, or go more bare-metal) is still leaps and bounds ahead
| of competitors, like the STM32CUBE cluster fuck...using their
| Hal was the only time in my life where deleting whitespace in C
| code could break a build. If the developer experience is awful,
| it doesn't matter that the STM32 chips perform better per
| second and per watt than an ESP32.
| TheLoafOfBread wrote:
| Or in my case - if you can not buy the STM32 at all, while
| ESP32 is in stock just fine.
| ostenning wrote:
| I feel like Nordic offerings are more attractive these days
| somrand0 wrote:
| could you post some hyper-links to said offerings?
| bbbbb5 wrote:
| https://www.nordicsemi.com/products
| nickthenerd wrote:
| > de facto IoT MCU
|
| Not at all, at least not professionally. Mostly mocked and
| avoided professionally. But prosumer and hobbyist, it's
| probably the most popular. They are fun to prototype with and
| use around the house but I would never stake my business on
| them.
| jki275 wrote:
| I've never heard of them being mocked or avoided
| professionally. They're not usually the go-to or the most
| popular, but I've got no issue using them in a professional
| device.
| solarkraft wrote:
| Why not? Plenty of businesses like Sonoff do just that. In
| fact it's a selling point for a lot of them.
| gregmac wrote:
| Absolutely.
|
| I've bought several things specifically because they use
| esp32 and I can flash Tasmota or EspHome on them. In fact
| it's a far bigger factor than price.
| sidpatil wrote:
| What are some reasons for that?
| Zagitta wrote:
| Perhaps they're mocked and avoided in your sphere but there's
| certainly plenty of consumer products using them. Both sonoff
| and Tuya produce enormous amounts of products with them.
|
| What exactly is your problem with them? The chips are fairly
| capable and the newest ones have transitioned to RiscV in
| case you're unaware. Sure I wouldn't use them for anything
| serious realtime but that rarely requires wifi/ble anyway so
| not sure why you'd pick an ESP to begin with for that :)
| okso wrote:
| RISC-V might change the game soon with chips such as the
| Boufallo Lab BL616/BL618 RISC-V MCU.
|
| > Boufallo Lab BL616/BL618 is a 32-bit RISC-V wireless
| microcontroller with support for 2.4 GHz WiFi 6, Bluetooth 5.2
| dual-mode, and an 802.15.4 radio for Zigbee, Thread, and Matter
| designed for IoT applications. [1]
|
| Boufallo chips are becoming available on Pine64 products (Ox64,
| Star64, Pinecil) [2].
|
| [1] https://www.cnx-software.com/2022/12/29/boufallo-lab-
| bl616-b... [2] https://www.pine64.org/2022/11/15/november-
| update-tuned-in/
| solarkraft wrote:
| Maybe, but Espressif already has their own RISC-V chip
| (ESP32-C), which is perfectly compatible with their
| development platform (IDF), with a Thread-compatible model
| (ESP32-H2) coming next year.
|
| Both cheap and profiting from the big community.
|
| I'll buy an Ox64 (the ability to run Linux interested me),
| but Espressif isn't giving up easily. A few years ago, when
| Espressif was in more of a niche, it would've been an
| advantage to not have to use their weird Xtensa instruction
| set. But nowadays most toolchains have apparently added
| support and it's not a big problem anymore.
| petre wrote:
| It seems to be a direct competitor to the ESP32-C6 which
| also has WiFi 6, BLE and 802.15.4. It will only be
| supported in v5.1 of the IDF, so not quite there yet.
|
| https://www.espressif.com/en/products/socs
| numpad0 wrote:
| It's not the matter of CPU arch, raw performance or even
| power consumption.
|
| "640KB of RAM" is all you ever need in a great range of use
| cases that isn't currently well explored, and ESP8266/ESP32
| serves that market very well with Arduino IDE integration and
| affordable devkits.
|
| e: added absolutely necessary positivity to languages, sorry!
| ilyt wrote:
| If they hit the price that could be really interesting.
| notpublic wrote:
| Direct links to Pine64 products ...
|
| 128Mb Ox64 SBC - $8 USD https://pine64.com/product/128mb-
| ox64-sbc-available-on-decem...
|
| 16Mb Ox64 SBC - $6 USD https://pine64.com/product/16mb-
| ox64-sbc-available-on-decemb...
|
| Both currently out of stock, schedule restock in January
| 2023.
| PragmaticPulp wrote:
| Price and availability had a lot to do with it.
|
| When you're trying to squeeze every dollar out of a BOM, the
| cheapest chip that gets the job done is going to win. The TI
| and STM parts were more expensive and less available, so they
| did not win.
|
| The landscape is slowly evolving, though. Espressif is getting
| a reputation as the Raspberry Pi of IoT MCUs: Easy to get
| started and everyone knows about it, but too many people are
| trying to use it in places where it's not really the right tool
| for the job.
|
| A few years ago I'd hear "can't you just use a Raspberry Pi..."
| from people who knew just enough to be dangerous. Now it's
| "can't you just use an ESP32..."
| fest wrote:
| Well, since ESP32 is available as chip, you can design a
| product which is just as robust, safe, resistant to ambient
| temperature effects, manufacturable at scale as you could
| with any other TI/ST alternative. With Raspberry Pi, up until
| the introduction of compute module you would still have been
| limited to whatever board-level properties Raspberry Pi
| foundation decided to go (limited temperature range, flakey
| USB sockets that don't tolerate high vibration, requiring
| hand assembly, difficulties sourcing reliable SD cards,
| default OS settings wearing out the SD card, difficulties
| sourcing in large quantities etc)- in addition to the same
| judgement on the side of person implementing the design.
| topbanana wrote:
| > they now also dominate the professional industry.
|
| is that true? it wasn't a couple of years ago.
| mmoskal wrote:
| Espressif seems to be pulling $180m per year [0], so I guess
| on the order of 100m devices. The likes of ST and NXP have
| 10-20x the revenue, but I would venture the majority of what
| they are selling isn't connected. Nordic revenue was $600m,
| most of it BLE likely. So I guess Espressif is somewhat
| significant but definitely not dominant.
|
| [0] https://www.espressif.com/sites/default/files/financial/E
| spr...
| keewee7 wrote:
| I only meant IoT devices. Most embedded systems that don't
| have WiFi/BLE requirements are probably using ARM32, MSP430
| or AVR.
| luma wrote:
| Mostly only IoT devices from Asia. There are a small
| handful of things coming out of the west on ESP32, but
| professional users still stay away as they don't have the
| kind of engineering connections into Wwstern industries
| that Nordic et al do. That includes sales reps, training,
| etc etc. The things that matter to large engineering firms
| aren't really present from Espressif (although I wish them
| well and the ESP32 is an awesome platform).
| antoniuschan99 wrote:
| Yea, I would assume a large percentage of startups that
| use Wi-Fi adopt esp32 since it's much easier and cheaper
| to get up and running compared to the competition.
|
| More established companies don't need to adopt it but I
| assume it will change as time goes on. Kind of like how
| Webview or React Native was scoffed at in the beginning
| but now it's pretty commonplace even at large companies.
| Or like when Twilio IPO'ed it started targeting larger
| firms by building out their sales department because at
| the time it was mainly a hobbyist platform.
|
| Esp8266 doesn't have Flash Encryption, or Secure Boot,
| whereas Esp32 does and Espressifs SDK ESP-IDF is
| maturing. So it's definitely going that direction.
|
| Nordic announced its Espressif Competitor but haven't
| released the cost yet. Espressif seems to be throwing
| things at the wall to see what sticks (S2, S3, C6, H2,
| etc). I think their IPO definitely helped them raise more
| cash to do more things.
|
| They also had a virtual conference with a bunch of talks
| https://www.youtube.com/@EspressifSystems
| antihero wrote:
| Yet again the most frictionless solution wins out. Who'd have
| thought? If only there were examples of this being the case...
| Saris wrote:
| Also easy support by Arduino probably helps a lot of people get
| going, a lot of MCUs can be hard to get started with for people
| new to embedded programming.
| zajio1am wrote:
| Which is sad, considering how bad is ESP32 documentation
| compared to other microcontrollers.
| JoeAltmaier wrote:
| Everybody has their preference. But none of them are well
| documented. And all BSPs are buggy messes.
| mhh__ wrote:
| What documentation? (RTOS source code doesn't count!)
| moffkalast wrote:
| Turns out good documentation doesn't help anyone if they
| can't buy the thing eh?
| fest wrote:
| While I do agree with you, I haven't found the lack of depth
| in register-level documentation too limiting. On the other
| hand, I find esp-idf much easier to use than STM32 HAL
| library and a lot easier to integrate in projects (I do like
| cmake).
| phh wrote:
| Gotta say, I just don't understand STM32's "HAL". ST's
| headers has proper macros (and structs IIRC), and it's so
| much more readable by just using those macros rather than
| the weird indirection library which is still a 1:1 match
| with hardware registers
| kevin_thibedeau wrote:
| HAL is designed to work with their code generator across
| product families. It suffers from design mistakes that
| can't be fixed. Their LL library provides a lower degree
| of abstraction while still affording ease of migration
| and is harder for them to screw up.
| mmoskal wrote:
| Definitely agree on the HAL. I didn't find the ESP32 docs
| too lacking though (for UART etc; for Wifi/BLE docs are
| non-existent of course).
|
| With STM32 they often have 3+ different kinds of timers
| (advanced, basic, sometimes also low-power). Instead of
| having one chapter about all of them and saying this and
| that feature is only available in TIM1, they will
| copy&paste the 100+ pages chapter for every kind of
| timer... They must be auto-generating this stuff somehow.
|
| edit: The NRF52 docs and architecture are much nicer than
| both (the registers seem to be designed by a programmer not
| a hardware person).
| lormayna wrote:
| What about the power consumption? ESP32 is not the best in term
| of energy efficiency, I guess that a series of crypto operations
| like the ones requested by a WG tunnel would have an impact on
| power and this can be a problem for a battery-powered ESP32.
| flaviut wrote:
| WiFi is just not really well suited for battery use. They're
| really power hungry.
|
| It's usually nRF52 series in use there. Maybe the ESP32s with
| Thread or Bluetooth LE, although I'm not familiar with that.
| jvanderbot wrote:
| Well there's another project I can cross off my to-do list.
___________________________________________________________________
(page generated 2022-12-29 23:00 UTC)