More in the range of the arduino than the pi, you could get a Colorlight 5A-75b for ~$15 on AliExpress and reprogram its FPGA to run an OpenPOWER core. It's a board meant for driving LED panels, but it has a Lattice ECP5-25F FPGA with a JTAG header easily accessible plus dual gigabit ethernet MACs and 4MB of SDRAM. The downside is all the rest of the IO is stuck behind one-way buffers since it's only designed to push data out to 5V LED panels. But it's been well reverse-engineered by the chubby75 project, the FPGA is well-supported by the open-source yosys+nextpnr FPGA toolchain, it's supported by the litex SoC builder (which also includes microwatt core support, though maybe not colorlight+microwatt?), and it looks like some have had success getting OpenPOWER cores to boot on it: https://twitter.com/antonblanchard/status/123177893988802969...
It hadn't occurred to me that PATA/IDE could be so simple to speak. Now I'm excited about the possibility of being able to dump a 25 or 30-year-old IDE drive I have that my USB adapter doesn't want to talk to (via another SATA-to-IDE adapter).
The README says this option relies on the kernel's "ATA framework" (presumably for the protocol/non-interfacing logic?). Is that part of the "talking to a drive" stack very much to have to implement? Or do you know of any existing code for microcontrollers?
Depends on what you want to do :)
If you just want to read/write sectors of 512 bytes at a time, it's pretty easy to implement even on a simple MCU.
There's a couple of registers which need to be set:
https://wiki.osdev.org/ATA_PIO_Mode
and you can then just read/write the data from the parallel lines.
Here's a similar project using an ATmega32:
https://github.com/zwostein/idetrol
(i used this code, ported to ARM to check my hardware before I wrote the kerneldriver)
Are they? I only see PDFs of schematics on their website, and no claims of being open. Of course with a breakout board like that there isn't really any secret sauce in the "source", just the expertise, trials and errors, and grunt work of layout.
At that same level of "schematics available" dev boards, another option for a XC7A35T and 256MB DDR3 are the ones on aliexpress for $50, https://github.com/ChinaQMTECH/QM_XC7A35T_DDR3, though I don't think they have the transceiver pins exposed and are bring-your-own-jtag-programmer. All the IO is via 0.1" headers, which are going to be lower integrity but a LOT easier and cheaper to use.
It sounds like the solution was always left as an exercise for the reader in the day-to-day dealings of the group even among the members: "Each participating country was supposed to perform its own decryptions. This is common practice in the intelligence community in order to prevent being fed cooked-up information."
and
"The cryptanalytical part of the cooperation involved exchanges of algorithms used in various (deliberately weakened) cryptographic devices used by target countries. It was then left up to the Maximator participants themselves to find out how to exploit weaknesses in the algorithms of these devices. Such exploitations are also called ‘solutions’."
Anyone getting an air quality monitor specifically because of an interest in CO2 needs to be a bit wary, a lot of them claim to have a CO2 sensor but are actually just predicting CO2 levels based on other sensors designed to measure human occupancy. CO2 sensors are/were very popular for HVAC systems to use as a proxy reading of human occupancy levels and general air quality to meet air quality requirements. Now more modern (cheaper) air quality sensors are available which measure a mix of VOCs exhaled by people instead of CO2 but have an output mode that emulates the reading from a CO2 sensor at a similar occupancy level so that HVAC systems wouldn't have to redesign their control systems / formulas, usually marketed as "equivalent CO2" (or eCO2) readings.
Because they're called eCO2 sensors while being cheaper and lower power than real CO2 sensors, many air quality monitors have been using them and then surfacing their readings as "CO2 levels" under the mistaken belief that they can use the sensor to measure CO2. But it won't measure environmental CO2 at all, just predict the amount of CO2 the humans in a room would typically generate. Which is all you need for air quality monitoring, but just be aware you're not actually measuring CO2 if that's what you're curious about.
There are monitors with real CO2 sensors, but you'll want to look for a teardown to see what sensor is actually being used before you purchase. The Awair 2 seems to have a real NDIR CO2 sensor (Telaire T6703), for example: https://wiki.liutyi.info/display/CO2/Awair+2+inside#Awair2in...
Seems like there's a bit of room for confusion in the stuff surrounding the two. Would you guess "PYNQ - Python Productivity for ZYNQ" is a set of python bindings for this Zynq's API or for the FPGA? Especially seems like it could be related to this startup with its site being at pynq.io, at least until you see the photos of the pink PCBs :)
Yeah, a 16K Spartan 6, 64MBytes of DDR3 RAM, and an FX2LP USB High-Speed controller is a pretty terrific repurposed FPGA dev board in the vein of the chubby75 or panologic, even if the high-speed ADC turns out to have too many limitations / too weird signal conditioning (i.e. is too VGA-focused) to be very useful (but VGA probably at least means a pair of I2C pins is exposed on the DSUB-15, right?). Considering the FX2LP is already wired up to load the bitstream to the FPGA, and expects to on every power-up, that's a huge bonus for a dev board. Even if the binary blob of FX2LP firmware provided in the manufacturer's drivers does checksums, signature checks, etc. to make changing the bitstream data difficult, it would be pretty simple to write a new firmware to allow uploading of any custom bitstream (see: fx2lib), since it's such a well-known and widely-hacked chip -- maybe you can even manage to trick Xilin's ISE into believing it's a real Xilinx "USB Platform Cable" (FPGA JTAG programmer) since at least some of them use an FX2 for their USB interface. With a generic bitstream uploader utility for the FX2 you wouldn't even need to deal with any hardware modifications or even need to buy and connect a JTAG programmer if you were just starting out. And with everything being uploaded on every reset of the devboard, you don't have to worry about bricking anything either, since you just power-cycle the devboard to bring the programmer AND FPGA back to their default waiting-for-firmware/"rescue" mode.
But while the article says he got a lot of them (at least 3 from the photo) for $25 total, it looks like they're more typically ~$50+S/H each on ebay, which is less exciting.
The same company seems to have moved on to 'av.io'-branded USB3 devices now, which from a quick glance/binwalk of the downloadable firmware package (inspired by this article) appears to have FX3 USB Super-Speed controllers, and Spartan FPGAs. But it's designed to store the FX3 firmware and FPGA bitstream on the device itself (to allow it to boot up as a UVC webcam with no drivers required on the host, like this article was hoping would be the case for the older device), so it would require a bit more reverse engineering to figure out how to kick the FX3 into firmware update mode to replace the FX3 firmware with a custom bitstream uploader. But it's a ton more expensive, and who knows what generation and size of FPGA or how much and what sort of memory it would have.
There's not a lot of reason to stick with micro USB even for hobbyist projects. You can get USB-C "charging" receptacles that only breakout 6 contacts in any combination of SMD/PTH on the contacts and the mounting pins. Even in tiny quantities they're less than $0.10/ea on aliexpress. If you just want 5V you don't need to deal with PD, just stick 5K1 resistors to GND on each of the CC1 and CC2 pins (don't cheap out like the Raspberry Pi4 did and tie the CC pins together to save on a second resistor, or you'll end up with the same problems as they did).
They should be just as easy to route and hand-solder and the footprint should be just as compatible with low-end pcb services as any micro-usb connector, and it will allow you to use a better USB-C cable as your power connector.
If you also want the USB2 D+/D- lines broken out you can get USB-C connectors with 16-contact pinouts (everything but the SS pins).
I know the concern is about parcels specifically, but doesn't this agreement also cover all international mail?
Is the US going to be essentially cut off from international mail delivery until the USPS can negotiate pricing and a contract with each individual country's postal service (i.e., not in place over Christmas)?
More in the range of the arduino than the pi, you could get a Colorlight 5A-75b for ~$15 on AliExpress and reprogram its FPGA to run an OpenPOWER core. It's a board meant for driving LED panels, but it has a Lattice ECP5-25F FPGA with a JTAG header easily accessible plus dual gigabit ethernet MACs and 4MB of SDRAM. The downside is all the rest of the IO is stuck behind one-way buffers since it's only designed to push data out to 5V LED panels. But it's been well reverse-engineered by the chubby75 project, the FPGA is well-supported by the open-source yosys+nextpnr FPGA toolchain, it's supported by the litex SoC builder (which also includes microwatt core support, though maybe not colorlight+microwatt?), and it looks like some have had success getting OpenPOWER cores to boot on it: https://twitter.com/antonblanchard/status/123177893988802969...