miratrix

I'm assuming you're talking about Platform / BSP side of the ugliness.

You have to look at the lineage of how things evolved to the current state - on the PC ecosystem, everything is already on enumerable buses (PCI, USB, etc) with standards (PCI, UEFI, etc) describing how it's all supposed to find what device is connected where and have it all work together. The incremental cost of opening that up to the public is thus fairly small since you need to build your platform to adhere to the standards that are already there anyway. That's how you get to being able to boot a kernel image on a random system or insmod a random driver you found and expect it to (mostly) work.

In the SBC/Embedded ecosystem, there really aren't any standards. Since internal topology of each SoC is different and the pace of new SoC releases is so high, there's no time for standardization - you throw in random IPs from bunch of different vendors, figure out how to connect it all together, and get it to the market. In this scenario, having something documented is actually a negative thing - once something is documented, people expect it to work the same way going forward. You can hide a lot of hardware deficiencies in binary blobs, something that's very difficult to give up. Thus, there's a huge disincentive to provide full hardware documentation. I'd imagine that in some cases, for licensed IPs, the SoC vendors may not even be allowed to do so even if they wanted to.

Things like DeviceTree is trying to nibble around the edges of this problem, but given the current state of things, it'll be a while yet as a lot of the building pieces doesn't even seem like it's in the picture yet.

On the grid tied solar inverter front - the spec sheet says the battery voltage is 350~450 V, so we're looking at 108 lithium ion cells (25 x 18650 cells?) at 400 VDC nominal. This is quite different from typical lead acid battery pack voltage of 12, 24, or 48VDC that's used for battery backup storage, so a lot of existing solar battery storage infrastructure may not even work... this means that people may need to buy a whole new set of supporting hardware to integrate this into the existing solar systems instead of being able to update the software on existing hardware.

Lithium Ion also has quite a different (and much less forgiving!) charging cycle that requires much more monitoring of things like temperature, though I'd imagine a lot of that would be built-in as a safety mechanism directly into the Powerwall.

What I've heard is that National Electrical Code becomes much more stringent on battery systems greater than 48V, with the line drawn at 48V due to it being used widely in the phone landline system. I'm not sure how true that story is, but I'd imagine extra care is probably warranted. 10kWh is about 9kg of TNT. :-)

Wifi scanning is also pretty terrible for power consumption as you found out.

If you are on Android, my guess is that your phone was set to be connected to Wifi during sleep. You can control it by going to Wifi networks section -> menu -> Advanced -> Keep Wi-Fi on during sleep, then setting it to "Only when plugged in" or "Never".

If you're driving around with the phone set to leave the Wifi on during sleep, it'll be constantly going in and out of range of various Wifi connections. If the Wifi part is set for passive scan, then the processor needs to be kept up as the Wifi chip attempts to collect the BSSID of all the network it see and processor tries to figure out whether these networks have been seen or not. If it's set for active scan, then the Wifi needs to power up the radios to transmit beacons. Pretty bad news in either case, unfortunately.

The difference between DCH (the full-on high power state) and PCH (the lowest power, waiting-for-paging state) is about 2-orders of magnitude. Last time I measured, it was about ~100mA vs ~1mA (at ~3.7V) used by the radio. So, it's not couple of minutes of battery life, but rather _many_ hours of standby life instead. People usually aren't very happy when a fully charged phone dies overnight.

I've seen apps do some crazy things and it really has a significant effect in over-all battery life. A popular Android weather clock widget woke the phone up every minute to update the minute number on the graphics and updated the weather information every ~15 minutes (gps + radio!) which single handily crushed the standby battery life from multiple days to less than 8 hours.

Yes, I don't think _every_ decision should be based on minimizing the wake ups... but on the other hand, all developers should at least try to have as much understanding of the platforms that they're working on so that they know what trade-offs they're making with each feature they're adding.

I'm glad that Google has these videos available and that they're being picked up in places like HN.

The problem with $30k Tesla in 2018 that doesn't differ too much from Nissan Leaf... is that we already have the 2013 Nissan Leaf. :-)

I think there will be performance gains to be had, especially in applications where concurrency has been 'bolted on' (akin to the Big Kernel Lock).

However, I think what makes this interesting is not the raw performance it provides, but the functionality that it exposes. As far as I can tell, TSX will allow sets of operations to be executed, then "rolled back" in case of conflicts. This could greatly improve performance of Java code within synchronized blocks, for instance, or provide much faster hardware implementation of the software transaction memory model in Clojure.

I believe the biggest benefit of this will be making multi-threaded programming easier to get right, and get decent performance to boot. And if these constructs are supported natively in languages and frameworks, everyone will benefit from having 4- 8- or 16- cores.