nicklasfrahm / mykilio Goto Github PK

We need more and better docs. One way to achieve this would be to have a tool that provides the following features:

• Automatically create documentation based on standardized format
• Take inspiration from Golang's go doc
• Support for C source code
• Support Markdown and / or JSON output format

Currently the ICSP header is too close to the top of the board. On the back of the board the solder connections collide with the heatsink of the Raspberry Pi 4.

The following tasks are required to resolve this issue:

• Modify PCB
• Test PCB in assembly

TWI will be used to control the functionality of the blade server via the management bus. For this all functionality and features should be mapped to register addresses and documented.

• Status: Immutable information about the current state
  • bmc_cpu: char[16]
  • bmc_firmware_name: char[16]
  • bmc_firmware_version: char[16]
  • bmc_state: uint8
  • sbc_state: uint8
  • power_source_psu: bool
  • fan_installed: bool = (speed_duty100 > 0)
  • fan_pwm: bool = (speed_duty100 != speed_duty50)
  • fan_min_speed_hz: uint8
  • fan_max_speed_hz: uint8
• Spec: Mutable information about the desired state
  • bmc_action: uint8
  • sbc_state: uint8
  • fan_duty_cycle: uint8
  • fan_control_mode: uint8
    • manual
    • linear: y = a*x
    • cool: y = a*sqrt(x)
    • silent: y = a*e^x
  • fan_feedback_source: uint8
• Telemetry: time series data
  • bmc_voltage: float
  • bmc_current: float
  • sbc_voltage: float
  • sbc_current: float
  • temperature_psu: float
  • temperature_ambient: float
  • fan_duty_cycle: uint8
  • fan_speed_current: uint8

A first prototype of the webhook authentication server should be deployed.

Currently not all schematics are exported and part of the docs/schematics folder. The two following tasks are to be performed:

• Export schematics from KiCAD
  • Blade ATmega328P
  • Backplane LM2596
  • Backplane TPS54561
  • Backplane TPS54560
  • Backplane DM28
• Add direct link to documentation
  • Blade ATmega328P
  • Backplane LM2596
  • Backplane TPS54561
  • Backplane TPS54560
  • Backplane DM28
• Highlight hardware status in documentation
  • Blade ATmega328P
  • Backplane LM2596
  • Backplane TPS54561
  • Backplane TPS54560
  • Backplane DM28
• Add render to documentation
  • Blade ATmega328P
  • Backplane LM2596
  • Backplane TPS54561
  • Backplane TPS54560
  • Backplane DM28

The second revision of the PCB requires certain DIP switches to be set while flashing the bootloader, because the SPI signals need to be decoupled. This should be part of the section about bootloader flashing in the documentation.

A core component of the Mykilio stack is an MQTT broker. The emqx MQTT broker seems to be a good option.

When using the --atomic flag before the release name it is not respected.

The recommend partitioning scheme for the Raspberry Pi uses an MBR partition table (dos label) with the following partitions:

1. UEFI firmware partition (primary, boot flag)
   • Size: 256MiB
   • Partition type ID: 0x0c
   • Filesystem: mkfs.fat -F32 $DEV
2. UEFI boot partition (primary)
   • Size: 768MiB
   • Partition type ID: 0xef
   • Filesystem: mkfs.fat -F32 $DEV
3. OS root filesystem (primary)
   • Size: max
   • Partition type ID: 0x83
   • Filesystem: mkfs.ext4 $DEV

Let's finally show some logs on the console. To do this, we need an interrupt based solution to send and receive data via USART. Maybe asprintf() and a char[] buffer can be used?

To provide a low-cost backplane for the Raspberry Pi and other boards that don't exceed a power budget of 15W it could be nice to create a backplane variation that uses the cheap and popular LM2596.

• Create schematic
• Select components
• Route PCB
• Export schematic and STEP file
• Set up CI

To interface between the microcontrollers of the Mushroom blade server a common interface is defined that now has to be implemented in the form of a header file.

For the controller and the power supply we need a blade that can provide 220W of power at ideally 24V. A good candidate due to its compact design is an open power supply, such as this.

The backplane power supplies should be verified. The following functionality needs to be tested:

• PWM fan control
• DC fan control
• Fan feedback

The following functionality has to be verified with software:

• SPI bootloader flashing
• TWI
• USART
• LED
• Shared serial port
• Current and voltage sensing
• Power temperature sensing
• Ambient temperature sensing

The blade socket on the backplane should be rotated by 180 degrees while also adjusting the pin assignment, such that the pin numbering between the blade and the backplane align.

Currently we have a lot of different artifacts related to PCB design and manufacturing, but we lack a good strategy for the distribution of these files. The files in question are:

• STEP files for mechanical design and assemblies
• Schematics
• Fabrication files

All these files can essentially be automatically generated, but the question is then how to publish them.

Currently, I have two ideas:

• Publish these outputs to a seperate branch
• Fetch them as part of the docs workflow and deploy them to GitHub pages alongside the documentation

A FreeCAD assembly with a single blade should be created. It should contain the following parts:

• Pi4
• Pi4 heatsink
• ATmega328P blade
• LM2596 backplane

Additionally, the following tasks are required:

• Document the process of how to simplify the FreeCAD part after importing a .step-file

The controller software on the ESP32 should do the following:

1. attempt to write a non-zero value to all TWI address at register address 0x00
2. log the address where a device acknowledges the discovery
3. write a value to the REG_DUTSET register.

A section should be added to the overview page that outlines the principles. It should touch upon:

• Eventual consistency
• Distributed systems
• Declarative API (where possible and within reason)
• Scalability
• Lightweight
• Extensible
• Secure
• Protocol agnostic

Pin 4 and 5 are wrong on the symbol and footprint of the TPS54561. The correct pin numbering according to the datasheet is:

• Pin 4: SS/TR
• Pin 5: RT/CLK

Currently the backpower protection does not work for the blade, because the MOSFET body acts as a diode. To remediate this issue, a MOSFET AND gate with a PMOS and an NMOS should be implemented for either power rail, 5VPSU and 5VEXT. To fix this, the following tasks are required:

• Create simulation of new circuit
• Implement simulation schematic in KiCAD
• Select components
• Place and route
• Rerun simulation with selected components

Rebranding mushroom to cremini, might be useful to enable the possibility to create a wider variety of products that implement Mykilio. Inspiration is taken from here.

The following tasks need to be done:

• Rebrand boards
  • ATmega328p blade
  • LM2596 backplane
  • DM28 backplane
  • TPS54560 backplane
  • TPS54561 backplane
• Replace VIN on backplanes with not connected
  • ATmega328p blade
  • LM2596 backplane
  • DM28 backplane
  • TPS54560 backplane
  • TPS54561 backplane
• Update documentation
  • ATmega328p blade
  • LM2596 backplane
  • DM28 backplane
  • TPS54560 backplane
  • TPS54561 backplane
• Document the usage of the ${KIPRJMOD} variable for relative paths

Data structures and paths should be defined. The core inspiration will come from Redfish, but the different data domains will be mapped via subresources. Relevant resources are:

• Blade server mockup
• Redfish whitepaper

Currently the low-pass filter prevents us from reading the fan speed correctly. I have attached a simulation file, that illustrates a proposal for a new design.