Yeah BLE uses about 12 mA while transmitting or receiving. But it does not do that continuously. Its average power consumption can be under 100 uA very easily.
However, there's no way you'd get even 100 uA by harvesting RF energy in a package that small.
Yeah it actually makes sense from a physics point of view. All the fancy reflective angles on the stealth plane won't do anything if the wave is longer than they are. "Small" things all look the same in terms of wave reflections.
The radar-absorbing paint may do something (or at least it could in theory). And long-wave radars are naturally going to bigger and more inconvenient than short-wave.
I've never really thought about it, but I think he might be right!
I think this must be a standard ARM thing. The nRF51822 Cortex M0 (with BLE) from Nordic can do something very similar.
They call it PPI (Programmable Peripheral Interface). All the peripherals (timers, ports, low power comparator, even a quadrature decoder) have "events" and "tasks" and you can wire them up as you please. It's pretty neat. Doesn't have any op-amps or capacitative sensing circuits though.
What your describing is just configurable IO pin routing and peripherals with DMA. That has been common for decades and has nothing to do with ARM, nor is it at all related to Cypress's PSoCs.
The PSoC has an internal switch fabric as well. You aren't just muxxing various blocks to certain pins (e.g. Pin 2.1 is either GPIO, SPI CLK, or UART TX), you can wire blocks to each other internally and then send the output or input to a large choice of pins on the outside.
You don't have to write in low-level C. You can write in high level C++, which is vastly preferable to javascript! Or hell, why not write in Lua! It's what this apparently transpiles to, and is much nicer.
The only reason javascript became popular is because it was the only option on the web. Why does that mean we would want to use it when we have better options?
> You can write in high level C++, which is vastly preferable to javascript!
First, C++ compilers are not available everywhere. Second, C++ compilers do not always implement all corners of the language on embedded systems. Third, C++ is better than Javascript? That's going to take some explanation.
> Or hell, why not write in Lua!
Lua has it's own share of "Wat". 1-based indexing when a non-trivial amount of your stuff needs to interoperate with C is a big one. In addition, Lua is nicely configurable--read, "Every Lua implements a different set of modules."
> The only reason javascript became popular is because it was the only option on the web.
It's popular to hate on Javascript, but Javascript isn't that bad. Go back and take a look at Javascript in the Netscape 2.0 and Netscape 3.0 timeframe. It's a fairly straightforward, minimal language.
Now, all that having been said, this isn't exactly impressive. A 180MHz ARM with 32MB of flash and 32MB of RAM is not a small processor. With that level of power, there are lots of options.
If this were running on an 50MHz M0 with 256K flash and 16K RAM, it would be impressive.
> First, C++ compilers are not available everywhere.
Neither is javascript. If both are available for this micro, then his statement is as valid as yours.
> Second, C++ compilers do not always implement all corners of the language on embedded systems.
I've done a good bit of embedded programming in C and I wouldn't need all of C++ to make life a lot easier.
> Third, C++ is better than Javascript? That's going to take some explanation.
To-may-to/to-mah-to. Whichever way you want to spin it (C++ > javascript or javascript > C++) is going to take some explanation.
> but Javascript isn't that bad
No. But its also not as that great in comparison to how popular it is. Its certainly improved a lot since the early days, but it still has some pretty significant warts. Most languages do, of course, so if this is an issue or not kinda depends on the "third" above.
> Now, all that having been said, this isn't exactly impressive. A 180MHz ARM with 32MB of flash and 32MB of RAM is not a small processor. With that level of power, there are lots of options.
Indeed. I wonder how much overhead this has compared to running C on the same thing. I have nothing to back it up and certainly don't have time to benchmark, but I'm convinced I could write a forth interpreter running on a 60MHz PIC24E that would have competitive performance to this thing. Maybe I wouldn't beat it, but I reckon I could come close enough.
> Neither is javascript. If both are available for this micro, then his statement is as valid as yours.
Hrm, I stand corrected. I thought that at least some of the Javascript implementations were C-only, but it looks like they all require C++.
> I've done a good bit of embedded programming in C and I wouldn't need all of C++ to make life a lot easier.
Templates, exceptions, and memory allocation all interleave and you pretty much can't have one without all of them. And that's a huge amount of overhead on a truly small system (which this is not--my first Linux box wasn't 180MHz with 32MB or RAM). About the only thing you can have standalone is the original "C with classes" subset of C++. And I just don't find that very much more useful over straight C (and certainly not over the latest standard C11)
However, I'm much more interested in Rust on embedded systems than these dynamic languages.
"Turing test proves that 30% of judges are actually computers."
A recent Turing test at Reading University backfired after it was discovered that nearly a third of the apparently human judges were discovered to be less intelligent than a ZX Spectrum. Suspicions were raised when they were unable to carry on sophisticated conversations with the programs being tested and instead nattered on about banal topics such as their job, popular music, and another thing.
This seems like a good place to ask: Does anyone know of a library (preferably C++/Emscripten) that simplifies using WebRTC to create real time network games?
I looked for a library for a similar WebRTC project. All of the libraries I found contained superfluous functionality, as I was only interested in data channels and did not want to be locked in by a particular third party. I ended up rolling my own; the WebRTC API is simple enough [1] and there is some example code from Google that points the right direction [2]. Additionally, Socket.io makes for a convenient signalling server prototype, though it is overkill.
If you want a simpler signaling server for WebRTC, you might check out the "caress" server I developed for Chatphrase: http://github.com/chatphrase/caress
Yeah I saw a card with a screen demoed ages ago which generated one-time-use credit card numbers (or something like that), which is surely the way it should be done. It's so crazy that once I've given someone some numbers they can just take money from me.
You're just much more used to monospace.