6 ms·
There’s a Technical Reference Manual[0], and a pinout[1] which show some of the features (multiple analogue inputs, huzzah!) [0]https://espressif.com/sites/def
by dan1234 10y ago
There’s a Technical Reference Manual[0], and a pinout[1] which show some of the features (multiple analogue inputs, huzzah!)
[0]https://espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf https://espressif.com/sites/default/files/documentation/esp3...
[1]http://www.pighixxx.com/test/wp-content/uploads/2015/12/ESP32_Pinout_a1_3.png http://www.pighixxx.com/test/wp-content/uploads/2015/12/ESP3...
- faragon 10y agoWow, so ESP32 has much more ROM/Flash and RAM memory than previous ESP8266 chip: "Embedded Memory – 448 KB Internal ROM – 520 KB Internal SRAM – 8 KB RTC FAST Memory – 8 KB RTC SLOW Memory"
- StavrosK 10y agoYeah, ten times more, which is great, but I didn't practically run into limitations of the ESP8266 either. Then again, I'm not representative, but I'm saying that even 40K is plenty for most things.
- hyperbovine 10y ago40kb is ok if you are just loading compiled byte code, however the Lua / MicroPython runtimes consume nearly all of that leaving little space for your project.
- michaelt 10y agoIt turns out 40K isn't much if you want a TLS stack that supports modern standards and keysizes, and interoperates with most servers out there [1]. Once you have 16K transmit and receive buffers (the default fragment length) and enough space to do the math needed for a 4096-bit RSA key, you're pretty much out of RAM. And that's just the system library for a single TLS connection - the programmer will probably want to use some memory too :) [1] https://github.com/esp8266/Arduino/issues/1375#issuecomment-169519587 https://github.com/esp8266/Arduino/issues/1375#issuecomment-... https://github.com/esp8266/Arduino/issues/43#issuecomment-163535888 https://github.com/esp8266/Arduino/issues/43#issuecomment-16...
- lorenzhs 10y agoWell, 4096 bit keys are wasteful even on non-embedded platforms (Desktop/mobile) at the moment. 2048 bit keys are totally fine if you use a reasonable validity period (Let's Encrypt only issues 3-month certificates, for example). That way, it's highly unlikely that the key can be cracked during the validity of the certificate, and should a more practical attack come along at some point, your exposure is limited and you can quickly switch to a larger key size. See also https://certsimple.com/blog/measuring-ssl-rsa-keys https://certsimple.com/blog/measuring-ssl-rsa-keys - 2048 bits are enough for TLS for now.
- revelation 10y agoYou don't get to choose the key length when connecting to a server.
- lorenzhs 10y agoWell yeah but very few sites have 4096 bit keys in my experience, it's mostly misinformed hackers thinking "more bits, more good". And most likely you'll be running your own endpoint for the ESP, so you can control the key length.
- david-given 10y agoIs it Von Neumann architecture? Can you run code out of RAM? Because if so, you could totally run a real operating system that (I'm thinking of Fuzix, for example).
- antocv 10y agoYes it is von neumann, code runs out of RAM, as far as I understood it, someone please correct if Im wrong.
- faragon 10y agoThe CPUs architecture is Harvard, like in its prececessor. However, that seem to apply just to RAM, separated in the memory map in areas for instructions and data. For the ROM access, flash ROM accessed via SPI, looks like can be accessed from both data and instruction buses, so in that regard would behave like, de facto, von Neumann (?) Anyway, for running a real OS you can use PIC32 microcontrollers: are full MIPS32, including memory protection, and there are many cheap implementations with 512KB of RAM and 2MB of ROM (even more). You can run e.g. LiteBSD on Olimex EMZ64 PIC32 board [1]. [1] https://www.olimex.com/Products/PIC/Development/PIC32-EMZ64/open-source-hardware https://www.olimex.com/Products/PIC/Development/PIC32-EMZ64/... (I'm not related to Olimex, I just love that board)
- teraflop 10y agoThat manual looks great, and probably should have been linked from the Hackaday post. I'm confused by this, on page 12: > The capacity of Internal SRAM 1 is 128 KB. Either CPU can read and write this memory at addresses 0x3FFE_0000 ~ 0x3FFF_FFFF of the data bus, and also at addresses 0x400A_0000 ~ 0x400B_FFFF of the instruction bus. The address range accessed via the instruction bus is in reverse order (word-wise) compared to access via the data bus. That word-reversed mapping seems like a slightly nutty design quirk, but I find it hard to imagine how it could happen by accident. If it's a deliberate feature, is there anything it would actually be useful for?
- PinguTS 10y agoThis seems to be very odd. May be someone wanted to make access easy and fucked it up. Then they left it and defined it as feature. The original feature is may be, that data access is byte wise, but as it is 32-bit CPU the instruction access is double-word wise. As it is also little endian someone may wanted to make the access easy.
- pjc50 10y agoIt's weirder than that: within a word the bytes are in order, it appears that "top" and "bottom" of memory have been exchanged. It's as if one address bus is being fed through an inverter.
- deleted 10y ago[deleted]
- david-given 10y agoI don't think it's an inverter. It looks like a subtraction (which is even weirder). Here's the example they give: 0x3FFE_0000 accesses the least significant byte in the word accessed by 0x400B_FFFC. 0x3FFE_0001 accesses the second least significant byte in the word accessed by 0x400B_FFFC. 0x3FFE_0002 accesses the second most significant byte in the word accessed by 0x400B_FFFC. 0x3FFE_0003 accesses the most significant byte in the word accessed by 0x400B_FFFC. 0x3FFE_0004 accesses the least significant byte in the word accessed by 0x400B_FFF8. 0x3FFE_0005 accesses the second least significant byte in the word accessed by 0x400B_FFF8. 0x3FFE_0006 accesses the second most significant byte in the word accessed by 0x400B_FFF8. 0x3FFE_0007 accesses the most significant byte in the word accessed by 0x400B_FFF8. …… 0x3FFF_FFF8 accesses the least significant byte in the word accessed by 0x400A_0004. 0x3FFF_FFF9 accesses the second least significant byte in the word accessed by 0x400A_0004. 0x3FFF_FFFA accesses the second most significant byte in the word accessed by 0x400A_0004. 0x3FFF_FFFB accesses the most significant byte in the word accessed by 0x400A_0004. 0x3FFF_FFFC accesses the least significant byte in the word accessed by 0x400A_0000. 0x3FFF_FFFD accesses the second most significant byte in the word accessed by 0x400A_0000. 0x3FFF_FFFE accesses the second most significant byte in the word accessed by 0x400A_0000. 0x3FFF_FFFF accesses the most significant byte in the word accessed by 0x400A_0000.
- JshWright 10y ago> (multiple analogue inputs, huzzah!) No, the Huzzah is based on the ESP8266, not the ESP32 ;)
- teraflop 10y agoOh wow, the "Remote Controller Peripheral" is pretty cool too. You can set up buffers containing run-length-encoded pulse trains, and the peripheral will transmit and receive them in the background, on up to 8 channels simultaneously. As the name suggests, it's designed to make it easy to handle IR remote control signals, but it could also be used for precisely-timed control of e.g. servomotors.
- jon-wood 10y agoSounds like it might work for 433Mhz transceivers as well.