Ever since people figured out that the Raspberry Pi 4 has a PCIe bus, the race was on to be the first to connect a regular PCIe expansion card to a Raspberry Pi 4 SBC. Now [Zak Kemble] has created a new approach, using a bridge PCB that replaces the VL805 USB 3 controller IC. This was also how the original modification by [Tomasz Mloduchowski] worked, only now it comes in a handy (OSHPark) PCB format.
After removing the VL805 QFN package and soldering in the bridge PCB, [Zak] confirmed that everything was hooked up properly and attempted to use the Raspberry Pi 4 with a PCIe extender. This showed that the Raspberry Pi would happily talk with a VL805-based USB 3.0 PCIe expansion card, as well as a Realtek RTL8111-based Ethernet card, but not a number of other PCIe cards. Exactly why this is is still unclear at this point.
As a bonus, [Zak] also found that despite the removal of the VL805 IC from the Raspberry Pi rendering its USB 3 ports useless, one can still use the USB-C ‘power input’ on the SBC as a host controller. This way one can have both PCIe x1 and USB on a Raspberry Pi 4.
This is the third iteration we’ve seen for using PCIe with the Pi. If you’re building on the work of [Thomasz Mloduchowski], which inspired [Colin Riley] to add expanders, and now this excellent hack by [Zak], we want to hear about it!
Big news today from Tim Ansell of Google along with eFabless and Skywater Foundry. FOSSi Foundation has a new post with the details:
Today, in a FOSSi Dial-Up talk, Tim Ansell of Google announced SkyWater PDK, the first manufacturable, open source process design kit. What differentiates this PDK from previous attempts is the fact that it is manufacturable: with this PDK, you can actually produce chips with the SkyWater foundry in the 130nm node.
That leaves you as chip designer only with one road block: money. Manufacturing chips is expensive – even for more than a decade old nodes like the 130nm node, you need to spend at least a couple thousand dollars.
You know what? Don’t worry – Google and efabless have got you covered! They are providing completely free of cost chip manufacturing runs: one in November this year, and multiple more in 2021. All open source chip designs qualify, no further strings attached!
The Open Source Hardware Association (OSHWA) has just posted:
We, the undersigned, encourage educators, engineers, designers, and community members to discontinue the use of the terms MOSI/MISO/SS and in their place use SDO/SDI/CS.
- New signal names:
- SDO – Serial Data Out. An output signal on a device where data is sent out to another SPI device.
- SDI – Serial Data In. An input signal on a device where data is received from another SPI device.
- CS – Chip Select. Activated by the controller to initiate communication with a given peripheral.
- COPI (controller out / peripheral in). For devices that can be either a controller or a peripheral; the signal on which the device sends output when acting as the controller, and receives input when acting as the peripheral.
- CIPO (controller in / peripheral out). For devices that can be either a controller or a peripheral; the signal on which the device receives input when acting as the controller, and sends output when acting as the peripheral.
SDIO – Serial Data In/Out. A bi-directional serial signal.
- Deprecated signal names:
- MOSI – Master Out Slave In
- MISO – Master In Slave Out
- SS – Slave Select
- MOMI – Master Out Master In
- SOSI – Slave Out Slave In
- Signal names unchanged:
- SCK – Serial Clock. The clock for the bus generated by the controller.
Designers should avoid signal names MOSI/MISO and instead use SDO/SDI. The SDI signal is defined by the perspective of the device. For example, the SDI signal on a sensor is the pin that receives data from the controller. Similarly, the SDO pin on a controller is the output pin that sends data to a peripheral.
It is best practice to use SDO/SDI and Controller/Peripheral. Change the way you write tutorials, create schematics, and diagrams. This is the best way to educate the next generation of users and engineers.
Tom Fleet writes on Hackster:
Anyone of us can build something.
Fewer of us, myself included, excel at building a great number of something, and when it comes to scaling a design to any level of volume production, it quickly becomes obvious that in order to save your sanity, the only sensible option is to outsource the onerous process of production to an OEM, or similar set of subcontracted companies, that can handle the production of your products.
Some of them make designing the board seem like the easy bit. You’ll need a clear and concise build pack, not only with the PCB data supplied in the preferred format of your fab house, but also preferably with clear supporting documents to illustrate any quirks of the design that might need explaining.
The BoM must be complete and well sourced, backup suppliers and all. And providing you can get a well assembled set of PCBA out the end of your subcontracted process, you then have the not insignificant task of verifying the work that has been done — you need to test, and program if required — this box of boards that you have been delivered.
The type of testng that you might apply to these boards is going to be dictated by what they do. For something such as a simple SAO, that might mean poking a bit of pin header, attached to a coin cell battery, into the required pins.
For a more complex board, such as the OrangeCrab FPGA development board, things can quickly start to get a bit more involved… There is a whole suite of functionality to validate — from the basics of bringing up the power supplies,to ascertaining the analog inputs, and finally booting a bit-stream, there’s a fair amount of functionality that needs that “final test” check mark.
Adam Vadala-Roth has posted on Hackaday.io about a connected control system for all agriculture applications based on RS485 control nodes and multiple wireless sensor networks:
Agricoltura is the culmination of multiple projects I’ve worked on in the past related to the sensing and control of agriculture systems, notably HydroPWNics and SunLeaf. Agricoltura aims to unite all the concepts of those past projects into a new system based primarily on RS485 nodes for control of pumps, sensor sampling, and light control.
The base system will be a gateway controller linked to daisy chainable RS485 nodes designed for specific functions. These nodes are built around a board called Vine.
Vine allows interfacing of QWIIC connect sensros and devices as well as relay control. Coming in as two varients Vine can be used to setup and control complete hydroponic farming systems or any other agriculture system.
A process design kit (PDK) is a by now fairly standard part of any transformation of a new chip design into silicon. A PDK describes how a design maps to a foundry’s tools, which itself are described by a DRM, or design rule manual. The FOSSi foundation now reports on a new, open PDK project launched by Google and SkyWater Technology. Although the OpenPDK project has been around for a while, it is a closed and highly proprietary system, aimed at manufacturers and foundries.
The SkyWater Open Source PDK on Github is listed as a collaboration between Google and SkyWater Technology Foundry to provide a fully open source PDK and related sources. This so that one can create manufacturable designs at the SkyWater foundry, that target the 130 nm node. Open tools here should mean a far lower cost of entry than is usually the case.
ToorCamp 2020 was originally scheduled for June 23rd-28th, 2020 but due to the COVID-19 Pandemic, it’s been postponed until July 14-18th 2021. Instead, we’ve decided to host VirtualToor the weekend of June 27-28th as a self-organized event with talks, village hangouts, contests, and project collaborations to help ToorCampers build up momentum on research and projects for the event next year.
If you have ideas for talks, projects, contests, or other virtual events, please go ahead and post to this wiki. We’ll follow up if there’s any conflicts or issues with the self-organized content.
Exciting news about an FPGA company embracing open source tools:
The Benefits of Open Source…
Fast forward to 2020 – I believe we are at a similar moment in our industry. The Programmable Logic (FPGA/eFPGA) market is multi-billion dollars in size and expected to grow at a moderate pace of >7% per year over the coming five years. Another subset of the semiconductor market is the open source RISC-V IP, software and tools market – predicted to grow at nearly 7X that of the FPGA Market. That begs the question… “Why is an open source standard creating such a large market so quickly?”
We believe one key reason is that open source hardware and software enable flexibility and freedom. We should not mistake freedom for free, there are proven business models built on open source that benefit the user, the community and the companies that actively participate (e.g. Red Hat with Linux).
Open source FPGA tools have been around for a long time, being used primarily by hobbyists and in academia. Over the past few years, this situation has evolved, with an increasing number of new developers with software backgrounds gravitating towards open source FPGA development tools, including design teams at some of the largest companies in the electronics industry.
With companies like Google and Antmicro, as well as several universities, making significant contributions to them, these tools are only going to keep getting better. This active participation has improved the quality of results, user experience, and encouraged broader adoption. To see what the open source community has done without direct and active Programmable Logic company participation is nothing short of remarkable. And it makes one wonder what could be possible if Programmable Logic companies participated more actively. Building a sports car is so much more efficient and effective when the engine specifications are shared with the design teams.
To place a satellite in orbit satisfactorily it is necessary not only to hitch a ride on a rocket, but also to put it in the right orbit for its task, and once it is there, to keep it there. With billions of dollars or roubles of investment over six decades of engineering behind them the national space agencies and commercial satellite builders solved these problems long since, but replicating those successes for open source microsatellites still represents a significant engineering challenge. One person working in this field is [Michael Bretti], who is doing sterling work with a shoestring budget on open source electric thrusters for the smallest of satellites, and he needs your help in crowdfunding a piece of equipment.
As part of his testing he has a vacuum chamber, and when he places a thruster inside it he has to create a space-grade vacuum . This is no easy task, and to achieve it he has two pumps. The first of these, a roughing pump, is a clapped-out example that has clearly reached the end of its days, and it is this that he needs your help to replace. His GoFundMe page has a modest target of only $4,200 which should be well within the capabilities of our community in reaching, and in supporting it you will help the much wider small satellite community produce craft that will keep giving us interesting things from space for years to come.
Exciting news for those that want open source chips!
The SkyWater Open Source Process Design Kit (PDK) is a joint project of Google and SkyWater Technology Foundry to provide a fully open source PDK.
In this event, Tim Ansell will outline the collaboration and the goals of the project. He will get into the technical details of the PDK and outline the roadmap of the project.
Date: Tuesday, June 30, 2020
Time: 16:00 GMT