If Broadcom WiFi chipsets and their other consumer product lines are going away, it's really bad news for several key Maker community and OSS platforms. And decent alternatives are dropping off as well. Now, Broadcom was famous for being nearly impossible to work with, for smaller companies - no documentation, no support, no parts availability. And this was by design, that they would only work with 'tier one' customers. Raspberry Pi happened because it was developed by Broadcom folks in UK in their spare time, using a Broadcom set-top-box chipset. The talented Pi team just designed into the latest model 3 a BCM4343(43438), which looks good on paper and even includes BT. But will it, and the main CPU BCM2837, be around in two years? The Electric Imp and spark.io (now Particle) Photon WiFi modules are based on the Broadcom WICED environment. The WRT community grew around Atheros and Ralink chipsets, sporting Linux on MIPS32. Atheros now belongs to Qualcomm, which has been struggling and had layoffs. Ralink was bought by Mediatek, and WiFi is far from their core business. Atmel (think Arduino) came out with an interesting WiFi module, ATSAMW25 that includes a programmable ARM. And now Microchip, the purveyor of the kludgy PIC processor, is buying Atmel.
TI WiFi product line is indeed directed at the Embedded and IoT market, with low power modes that chipsets designed to go into APs or laptops cannot touch. The transceiver product line goes up in functionality all the way to 802.11abgn 2X2MIMO, and with Bluetooth 4.1 / BLE. Indeed the interface choices are SDIO (4 wire, up to 50MHz) and UART (up to 4Mbits).. For the laptop crowd, used to PCIe data rates, these may seem like not a lot, but it does work fine for many use cases.
TI also has a CC3x00 series, adding to an ASIC a dedicated ARM protocol microprocessor. The latest one, CC3200 has pretty nice specs, though pricing and availability has been my concern for design-ins.
I do NOT work for TI or own their stock:)
First, let me say that I find the idea intriguing. But, the methods as described simply lack any scientific rigor.
Read the fine print on the site http://noosphere.princeton.edu/gcpdata.html. They actually describe these RNG boxes as using 'quantum-indeterminate electronic noise'. Which is a fancy way of saying that it's using transistor electronics fluctuating in unpredictable ways. These are not detecting individual electron quantum transitions.
What's bothering me even more, is that these RNG sources are described as 'high quality random event generators that produce nearly ideal random numbers'. Sounds like typical sales pitch with no supporting documentation. And then they go on for pages describing all the ways that they have to fix-up this 'nearly ideal' data. The 'Normalization' process is there to hide the fact that even at 0-th order the data is biased.
I really loved the line 'All statistics are well-behaved', without giving any indication as to which tests were actually applied and with what results. This is like 'Trust us, we have it under control BS' which does not belong in scientific discourse. They should not be afraid of overwhelming us the technical details, if they are really there.
In my mind, if there are observable effects, why would the researchers dive into the metaphysical 'Toltec View' discussions. Instead, why not investigate which of the three types of devices they have, at which geographical locations show correlations with which types of events. Factor analysis anyone?
I have my doubts about merits of Pair Programming as described in the freely available chapter of the reviewed book.
However, I would strongly advocate 'Pair Debugging', once the code builds and passes unit tests but does not work when integrated into the system.
First, there is an issue of tools, say, debugging an FPGA on a board in a system. Quite few people can individually operate and effectively evaluate results of source code debuggers, Verilog simulators, ICE, logic state analyzers and scopes. So, this necessitates the obvious and often unavoidable pairing of a software and hardware engineer.
More frequently, though, for any system that's large and old enough, one person can hardly span interaction of various components under diverse inputs, and having two or more people observing and analyzing steps leading to a failure is very productive.
So, in conclusion, I think using 'Pair' methods is justified if knowledge and skills of the two engineers are complimentary.
Slashdot Mirror
If Broadcom WiFi chipsets and their other consumer product lines are going away, it's really bad news for several key Maker community and OSS platforms. And decent alternatives are dropping off as well. Now, Broadcom was famous for being nearly impossible to work with, for smaller companies - no documentation, no support, no parts availability. And this was by design, that they would only work with 'tier one' customers. Raspberry Pi happened because it was developed by Broadcom folks in UK in their spare time, using a Broadcom set-top-box chipset. The talented Pi team just designed into the latest model 3 a BCM4343(43438), which looks good on paper and even includes BT. But will it, and the main CPU BCM2837, be around in two years? The Electric Imp and spark.io (now Particle) Photon WiFi modules are based on the Broadcom WICED environment. The WRT community grew around Atheros and Ralink chipsets, sporting Linux on MIPS32. Atheros now belongs to Qualcomm, which has been struggling and had layoffs. Ralink was bought by Mediatek, and WiFi is far from their core business. Atmel (think Arduino) came out with an interesting WiFi module, ATSAMW25 that includes a programmable ARM. And now Microchip, the purveyor of the kludgy PIC processor, is buying Atmel.
TI WiFi product line is indeed directed at the Embedded and IoT market, with low power modes that chipsets designed to go into APs or laptops cannot touch. The transceiver product line goes up in functionality all the way to 802.11abgn 2X2MIMO, and with Bluetooth 4.1 / BLE. Indeed the interface choices are SDIO (4 wire, up to 50MHz) and UART (up to 4Mbits).. For the laptop crowd, used to PCIe data rates, these may seem like not a lot, but it does work fine for many use cases. TI also has a CC3x00 series, adding to an ASIC a dedicated ARM protocol microprocessor. The latest one, CC3200 has pretty nice specs, though pricing and availability has been my concern for design-ins. I do NOT work for TI or own their stock :)
First, let me say that I find the idea intriguing. But, the methods as described simply lack any scientific rigor.
Read the fine print on the site http://noosphere.princeton.edu/gcpdata.html. They actually describe these RNG boxes as using 'quantum-indeterminate electronic noise'. Which is a fancy way of saying that it's using transistor electronics fluctuating in unpredictable ways. These are not detecting individual electron quantum transitions.
What's bothering me even more, is that these RNG sources are described as 'high quality random event generators that produce nearly ideal random numbers'. Sounds like typical sales pitch with no supporting documentation. And then they go on for pages describing all the ways that they have to fix-up this 'nearly ideal' data. The 'Normalization' process is there to hide the fact that even at 0-th order the data is biased.
I really loved the line 'All statistics are well-behaved', without giving any indication as to which tests were actually applied and with what results. This is like 'Trust us, we have it under control BS' which does not belong in scientific discourse. They should not be afraid of overwhelming us the technical details, if they are really there.
In my mind, if there are observable effects, why would the researchers dive into the metaphysical 'Toltec View' discussions. Instead, why not investigate which of the three types of devices they have, at which geographical locations show correlations with which types of events. Factor analysis anyone?
I have my doubts about merits of Pair Programming as described in the freely available chapter of the reviewed book.
However, I would strongly advocate 'Pair Debugging', once the code builds and passes unit tests but does not work when integrated into the system.
First, there is an issue of tools, say, debugging an FPGA on a board in a system. Quite few people can individually operate and effectively evaluate results of source code debuggers, Verilog simulators, ICE, logic state analyzers and scopes. So, this necessitates the obvious and often unavoidable pairing of a software and hardware engineer.
More frequently, though, for any system that's large and old enough, one person can hardly span interaction of various components under diverse inputs, and having two or more people observing and analyzing steps leading to a failure is very productive.
So, in conclusion, I think using 'Pair' methods is justified if knowledge and skills of the two engineers are complimentary.