Oh 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.
That 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?
This 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.
Yeah, I've seen similar tricks on ARM microcontrollers that have 32-bit address spaces and tiny amounts of memory. e.g. https://spin.atomicobject.com/2013/02/08/bit-banding/ But the reverse ordering has me scratching my head.
I guess you could use it to support rudimentary multi-threading, with two different stacks growing in opposite directions...
It'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.
I 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.
It looks like you can read and write data via the instruction bus --- which you'd have to, as e.g. SRAM0 is only available on the instruction bus. It claims to be Harvard architecture, but both buses access the same memory, so it's really von Neumann architecture. So I'm not really sure what the difference is. Is it just that they took a Harvard architecture processor core and mostly wired both buses to the same memory? (And as you say, the reversed mapping of SRAM1 is just weird.)
Also, if I read this correctly, you can use a non-addressable storage device (like SPI flash) and it'll demand load it via a cache? That's amazing.
In short: I really like it. Sensible processors are so dull.
One wonders if this is a poorly translated explanation for a little-endian architecture. When accessed as data it comes back big-endian but when accessed as instructions it is interpreted as little-endian?
I could imagine a hack like this where the CPU logic came from one vendor that had the opposite byte order than a previous CPU, and yet one wanted to keep some level of compatibility between them.
Yeah, 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.
It 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 :)
Well, 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.
Well 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.
40kb 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.
Is 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).
The 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].
TIL that Espressif (the manufacturer of the ESP8266 and ESP32) hired the guy behind http://spritesmods.com/. That's a very promising sign that they plan to keep their hobbyist/hacker user base in mind.
I'd love to see LLVM support for this so I can run Rust on it, someone wrote that "it's about a month of a part-time work for a single developer" (see https://news.ycombinator.com/item?id=10994577).
Is this realistic? A Kickstarter project might be a way to do this...
It doesn't really have much RAM, I don't know how useful Rust would be for anything but prototyping, I don't think there's been much focus on size optimizations.
I spent 30 mins reading about this chip and I still don't get it. I get why the ESP8266 was awesome ... MCU + wifi for super cheap. Why is this chip so exciting? Is it because it is supposed to be wifi+ARM (an ARM good enough to emulate a sega mastersystem game as per a youtube video)+other goodies? I saw rumors of other goodies being BLE. Is that confirmed or was that hot air :)
The big annoyance for me is lack of a wake on GPIO activity capability. The ESP8266 only has "wake on timer" and "wake on reset".
I'm making a home weather station with a tipping rain gauge which pulses a switch whenever it tips, and an anemometer that pulses a switch once per revolution.
To make those pulses wake an ESP8266, I'd have to make them reset it. That can work, and many people have done it, but it is annoying. For the anemometer I can switch to just checking the speed when I wake up to check and report temperature. I'd miss short variations in wind speed that way, but that could be acceptable.
For the rain gauge, though, I need to be aware of every pulse. I considered adding a dedicated non-microcrontoller based counter for the rain gauge to accumulate counts between periodic wake-ups of the ESP8266, but that turns out to be more expensive than using a microcontroller. An ATTiny85 could monitor the rain gauge and count the pulses, and could provide in I2C interface to the ESP8266 to make it easy for the ESP8266 to get the results, and would only take one small chip and socket.
That led to me to consider the ATTiny84, which is like an 85 put has several more GPIO pins. Current plan is to use an 84, have it run all the weather sensors and do all the math, and use the ESP8266 just for reporting results. The ATTiny processors can wake from deep sleep on GPIO activity so can deal with the rain gauge and anemometer directly. The ESP8266 can spend its time in deep sleep, only waking up every N minutes to send a report.
Try a 1-wire counter, e.g. the DS2423 [0] for the rain gauge. It can be powered either from the ESP or via a coin-cell. You read the counters whenever you need to.
You can talk to 1-wire either via I2C (e.g. the DS2482 [1]), or you can easily bit-bang 1-wire via a GPIO or UART [2].
ESP8266 has ADC. It does not have DAC, however for some purposes (e.g. low quality audio over WiFi) I2S output can be used with DMA as PWM output.
Isn't IPv6 supported for ESP8266 with lwip?
How can a chip support or not support IPv6 in this case? Isn't it a layer below anything which would require direct hardware support? In other words, wouldn't it be implemented in software. I should point out that I know nothing about the ESP chips.
Or do you mean that the ESP8266 has hardware acceleration for IPv4 but not IPv6?
The ARM Cortex-based RTL8710 seems to sit halfway between the ESP8266 and the ESP32, and perhaps has more toolchain promise. Same library/documentation problems, of course.
The code generation, especially on RISCs, has improved pretty dramatically between 4.8 and 6.2. You can expect to get better code size with a newer toolchain.
That said, there's a good chance it's not too hard to forward port the patches; I'm not aware of any major rearchitecting between 4.8 and 6.2, then again maybe there's been one.
If you dont want to mess with gcc flags in all your projects, add the GCC_COLORS env variable to your shell, like just export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'` to your ~/.bashrc or other shell rc.
is based on ESP32 and is running Micropython; I don't know if their port will be fully open source, though. They've said that they want to contribute as much as possible back to the micropython project, I think?
Like what? I've tried to do CAN stuff with cars before, and outside of a few standard measurements it's almost impossible to find any documentation on what commands do what.
What chip would you recommend to do IoT which can run on harvested energy?
What would be the upper limit which harvested energy could deliver? Do you mean solar cells or harvesting microwaves from satellites, I could get about 1.5V or so from about a 60cm in diameter disk, have not measured the current available.
It would be really sweet to run something which speaks wifi even for short durations, if it recieves its energy from ephemeral radio.
Is very interesting but I'm not aware of any SOC that supports it.
> It would be really sweet to run something which speaks wifi even for short durations, if it recieves its energy from ephemeral radio.
One interesting source of power is a simple coil-and-diode to harvest radio waves, do this for a while until you have enough power to boot your device, take a reading and send off a sample.
A few mW for a few seconds every couple of hours or so would be a good target. 100's to 1000's of mWs would take so long to harvest that you'd likely never get there because of leakage.
And 'speaking' is the right term, I don't seen an easy way for such comms to be bi-directional without a lot more power to be consumed.
I wonder how much energy you can harvest from FM broadcast radios stations, those signals are pretty strong.
Edit: I calculated a power flux density of 2.648µW/cm^2 from 3.16mV/m (70 dBµ) which is the 'city-grade contour' in the US.
There seem to exist a patent for that, from a company called Freevolt (http://www.getfreevolt.com/).
Power law, so it's very much dependent on your distance to the transmitter.
In NL some clever person figured out that he could power his fluorescent tubes from the broadcasting tower across the street and promptly got sued for theft...
Why is solar power out of the question? A 2000 mAh 5V solar power bank costs $13 on ebay. You could run an ESP8266 indefinitely on that, assuming you get >8 hours of daylight.
That solar power bank weighs 300g and measures 15x15cm (6"x6"). Should be within the spec for most projects.
What Im using esp8266 for, is to control a strip of those ws2812b led lights, the chip will not need much energy, only sporadically to change light colors or on/off, so if I place that solar pad close to it - the led lights will charge the chip which controls them!
But what is powering the LEDs? Why can't that power source also feed the relatively tiny amount (compared to a bunch of LEDs) needed by the controller?
Right now the same power source, a simple adapter/transformer, is powering both. Thats the easy way, this solar pad way is just because it would be fun.
I'm working on this part and you'll definitely need to implement deep sleep, but also measure voltage. Right now I'm using ESP.getVcc() but im not 100% that is correct. Basically once the battery packs voltage drop below ~2.5v the user should get a warning it needs a recharge (just as a failsafe even when using the solar pack). Also, I haven't tried to see, but also make sure the battery pack allows the esp to draw current when in deep sleep or it wont wake up :$.
I'm not sure you need to measure voltage on one of these power banks; they're made to charge phones over micro USB, so they will have a DC-DC transformer giving 5V all the way down to empty, I believe.
Edit: also, I think the ESP8266 draws about 0.2W on average when it's on. If you have a 10 Wh battery, you can run it for 50 hours in theory. Would you then need deep sleep?
Bear in mind that solar cells are rated for the amount of power they provide in direct sunlight, and will generate much less under other lighting conditions.
The human eye has a huge dynamic range; you might not realize just how well it compensates for differing amounts of illumination. Many indoor environments are 100 or even 1,000 times dimmer than outdoor direct sunlight.
You can get a bigger one, sure, but it will obviously be heavier, bigger and more expensive. I think the 2000mAh ones are the smallest you can live with for this type of setup.
My back-of-the-envelope calculations suggest that solar cells might be usable with something like the ESP32, depending on the environment.
For example, under typical indoor lighting conditions, you ought to be able to get something like a hundred microwatts per square inch. That sounds tiny, but 3 in^2 would be enough for a 0.1% duty cycle, which would let you wake up for a fraction of a second every few minutes and transmit a sensor reading.
Of course, that depends on having a very low sleep current, and on being able to transition between sleep and active WiFi connectivity very, very fast.
I was trying to find something that could send a small message via Wifi when a toilet door was locked/opened; and could be powered by the lock motion or harvested energy.
For that I wouldn't use WiFi. Use Thread or a custom nRF51 protocol. Both allow very long sleep times (infinite with a custom protocol) and can send millions of packets from a single coin cell.
• The size of ESP-3212 Wifi module is 16mm x 24mm x 3m.
• The ESP-3212 deploys 4MB SPI Flash with WSOP－8 package. It also uses 3DBi PCB antenna on board.
Do you have particular terminology you're interested in?
The general subject is Micro Controller Units (MCUs) (and to a lesser extent System On Chip (SOC)s) which are becoming cheap ($5) and abundant enough to fuel the so-called Internet of Things (IoT) . There are various tangential topics such as:
* Computer architecture: e.g., "data bus", "SRAM", "Von Neumann architecture", "SPI flash", "Reduced Instruction Set Computing (RISC)", ARM, etc.
* Electrical engineering: e.g., "pulse trains", "servomotors", "Analog to Digital Converter (ADC) & vice versa (DAC)", "milliwatts (mW)", "milli-amp hours (mAh)", etc.
* Software engineering: "address spaces", "multi-threading", "stack", "Rust", "Low-Level Virtual Machine" (LLVM)", "[software build/compiler] toolchain", "Software Development Kit (SDK)", "GNU C Compiler (gcc)", etc.
* Network/Communication protocols: WiFi, "Bluetooth Low Energy (BLE)", "run-length-encoding", "little-endian", "Internet Protocol Version 6 (IPv6)", "Transport Layer Security (TLS)", etc.
Make magazine (especially their electronics and Arduino YouTube channels--see below) might be a good info gateway for you.
Given the low prices already mentioned, I'd say that if you're interested in learning more, a good way to go would be to order something like an AdaFruit Trinket (link below) (or a fully-fledged Arduino or one of the ESP8266 or ESP32 boards in this article) and seeing what you can accomplish with it. Sparkfun also has some good tutorials if you're already confident on the coding side.
maybe you also like embeddednodejs.com - the book is currently in early release (drop me a note if you like a proof reading version in exchange for a short book review) thanks!
Ive seen these being mentioned from nordic semiconductors, http://www.nordicsemi.com/eng/Products/2.4GHz-RF and specifically http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01
but they're not quite in the same space as esp8266 or esp32 - they all just do WiFi or Blutooth, with much less power required than esp8266, but do not have any processor left over for doing anything else really, and memory is also very little. These are more like components when you want to build more to your wish.
So Id say, no not really, there isnt an alternative still. I think it is due to ARM requiring license costs which are higher than Xtensas so unit cost doenst reach $1.95 yet. Then it is also really difficult to both design a CPU and integrate the radio on it - with good power-management in such a small form-factor.
The Realtek is a competitor, the Nordics you mention are not. The nRF24L01 uses a proprietary radio. Some of the nRF chips are popular for Bluetooth Low Energy especially given that they do have Cortex M processors that can be used to run applications, but it ain't a competitor without WiFi.
* Nordic nRF51/nRF52 - Very good option. Completely documented. You can do custom radio protocols. Very popular.
* TI CC2650 - Looks good. Apparently fully documented. Unlike the Nordic chip it has a separate processor for the BLE stacks so your code doesn't get interrupted during connection events. Also supports IEEE 802.15.4. CC2640 is BLE only.
* Samsung Artik 1 - BLE only; looks expensive
* Intel Curie - I don't know much about this but apparently it isn't well documented.
Wifi and BLE:
* Intel Edison - Powerful but very expensive
* Artik 5 - Again, powerful but expensive
I'm not really aware of any other solutions that have:
You have to choose WiFi, Bluetooth, or GSM, but the Particle line of boards are pretty great, have an included Pub/Sub and event based web service, and are field programable so you can tweak your design after you solder it up and put it in an enclosure. You also get a lot more usable IO than a ESP2866.
On the down side, they cost more that an ESP and I have seen occasionally flakey behavior in some boards that requires a manual reboot every few weeks.
https://particle.io/ has the Photon. $20 and you don't typically have to hook it up to the USB on your computer to flash it with new code. It's cloud updated.
"As far as any new information regarding the ESP32 is concerned, don’t expect much. It’s released, though, and in a month or so the work of documenting this supposed wonderchip will begin."
They are really serious about providing good doc. Here is what sprite_tm (one of their engineers) said:
"Also, keep in mind that documentation is very much a work-in-progress! The techdoc as it is is basically the state of the art with regards to what we’ve finished writing, editing etc. There’s still way more coming up, and the basic idea is to document everything very well this time; apart from some sensitive stuff (mostly the WiFi and BT RF interface) we’re trying to not have any secrets."
Source: http://hackaday.com/2016/09/05/new-part-day-the-esp32-has-be...
My guess is it's because 5ghz WiFi is regulatory hell. I honestly can't think of a good way (off the top of my head) to make this easily usable for international users without making it
a) easy for them to interfere with primary 5ghz users
Or
b) making multiple boards with an extra ROM chip ($$) telling people not to export them to other countries.
At least with 2.4ghz you can just stick to lower numbered channels.
Anyone have a good idea on how it compared to for example the CHIP? (https://getchip.com/pages/chip). I saw the announcement for ESP32 a few days ago but it looks like it's around $7 for one which to me seemed expensive compared to $9 for the CHIP.
From my quick scanning, power peaks seems to be lower but if somebody with better knowledge of these things can chip in that would be appreciated.
Mainly wondering if I should add these ESP32 to my collection or not (as I already have 2 CHIP:s and a few ESP8266) :-)
I assume they mean directly integrated into the camera hardware basically as a wifi modem. So some main processor would be passing it frames over SPI and it'd transmit them, not someone plugging in a webcam and streaming it.
Anyone have any idea on bulk costs. If buying 5-10K of the esp8266 modules, its chhheeeapp. Would love to consider switching over but curious on costs.
I am not 100% sure about this, as I can't read Chinese, but this is likely not 19 Japanese Yen.
> ¥ is a currency sign used by the Chinese yuan (CNY) and the Japanese yen (JPY) currencies. This monetary symbol resembles a Latin letter Y with a double stroke.
It is much more likely that it is 19 Yuan, which is ~$3.
Heh, I guess I shouldn't have believed the unbelievable price after all.
Still, $3 for a chip that does 'everything' isn't bad. From what I've seen everyone else wants 3x-10x more than that for chips (or, admittedly, sometimes modules) that do less.
This thing has I2S, meaning that you can hook up an audio codec to it. I wonder if it could handle stereo audio without underrunning the output stream?
Yes, it has been done with ESP8266, it can produce shitty audio by itself and when the sender is close to the device with no interference - otherwise you need a dedicated DAC and it can be used as a simple webradio with mono audio output device.
With this ESP32, my bet is it can handle stereo without any other dedicated components and fluently.
Yeah I built the ESP8266 version with SRAM and I2S codec, works well. The ESP32 might have enough internal RAM to not need the external SPI RAM, and the hardware pwms might be usable for audio out (or do we have a usable dac now?).
getting started with the esp8266 was mainly for ppl with some background in soldering. also, flashing the esp8266 was not too easy (python script, some system libs needed to be present iirc). for beginners, i found arduino, tessel or espruino to be easier. also, espruino now runs on esp8266 - the ecosystem that will evolve around the esp32 will be interesting to see
You could also buy an NodeMCU (http://nodemcu.com/index_en.html) if you don't like soldering. Personally without a formal electronics background or great soldering skills, I had not a lot of problems with setting up the ESP8266.
But I do agree that out of the box it's less "plug and play" as an Arduino.
The ESP-01 (which I started with) is quite painful to program, though - it uses a bizarre baud rate (78k?) and shares its GPIO with its programming pins.
I'm a software guy and had never picked up a soldering iron in my entire life. I managed to get my first esp8266 (the adafruit huzzah) soldiered to a little temp/humidity sensor on a small permanent breadboard (not sure the exact name) and had it pushing data into my home graphite server. Took me all of 2 days start to finish.
This is obsolete, get a WeMos D1 mini (suggested below) and run it with PlatformIO (my favorite) or the Arduino IDE. Arduino code will need minimal changes, if any, to run on the ESP.
It still has a built in RTOS like the 8266 and no I don't think you can replace it. Not easily anyway, Espressif could probably do it but I don't think users really are able to.
Your stuff is running bare metal though - your code is linked directly into the same binary payload as the RTOS. One of the major selling points of the ESP32 though was that it is dual core, so that you can have one core dedicated to servicing your code and the other to dealing with keeping the radio stack alive and such.
[0]https://espressif.com/sites/default/files/documentation/esp3...
[1]http://www.pighixxx.com/test/wp-content/uploads/2015/12/ESP3...