replace jekyll with 11ty

pavel-demin · Nov 2, 2024 · a3367a4 · a3367a4
1 parent f6baea7
commit a3367a4
Show file tree

Hide file tree

Showing 43 changed files with 918 additions and 929 deletions.
diff --git a/.github/workflows/jekyll.yml → .github/workflows/11ty.yml b/.github/workflows/jekyll.yml → .github/workflows/11ty.yml
@@ -1,4 +1,4 @@
-name: Deploy Jekyll site to Pages
+name: Deploy 11ty site to Pages
 
 on:
   push:
@@ -21,18 +21,17 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
-      - name: Setup Ruby
-        uses: ruby/setup-ruby@v1
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
         with:
-          ruby-version: '3.3'
-          bundler-cache: true
+          node-version: 20
+      - name: Install 11ty
+        run: npm install
       - name: Setup Pages
         id: pages
         uses: actions/configure-pages@v5
-      - name: Build with Jekyll
-        run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}"
-        env:
-          JEKYLL_ENV: production
+      - name: Build with 11ty
+        run: npm run build -- --pathprefix ${{ steps.pages.outputs.base_path }}
       - name: Upload artifact
         uses: actions/upload-pages-artifact@v3
 

diff --git a/.prettierignore b/.prettierignore
@@ -0,0 +1,3 @@
+_site
+**/*.html
+**/*.md
diff --git a/Gemfile b/Gemfile
diff --git a/_config.yml b/_config.yml
diff --git a/_data/layout.js b/_data/layout.js
@@ -0,0 +1 @@
+export default "page.html";
diff --git a/_data/site.js b/_data/site.js
@@ -0,0 +1,25 @@
+export default {
+  title: "Red Pitaya Notes",
+
+  description: "Notes on the Red Pitaya Open Source Instrument",
+
+  baseurl: "https://pavel-demin.github.io/red-pitaya-notes",
+
+  source: "https://github.com/pavel-demin/red-pitaya-notes",
+  issues: "https://github.com/pavel-demin/red-pitaya-notes/issues",
+
+  release_image:
+    "https://github.com/pavel-demin/red-pitaya-notes/releases/download/20240204/red-pitaya-alpine-3.18-armv7-20240204.zip",
+
+  scanner_image:
+    "https://github.com/pavel-demin/red-pitaya-notes/releases/download/20240204/red-pitaya-alpine-3.18-armv7-20240204-scanner.zip",
+
+  release_file:
+    "https://github.com/pavel-demin/red-pitaya-notes/releases/download/20240204/red-pitaya-notes-20240204.zip",
+
+  sdr_smem_file:
+    "https://github.com/pavel-demin/sdr-smem/releases/download/20240204/sdr-smem-20240204.zip",
+
+  extio_file:
+    "https://www.dropbox.com/scl/fi/pl8gfjn2ay267or1zkohu/extio_red_pitaya.dll?rlkey=zhmv6qktymfeno8bdap94noq9&dl=1",
+};
diff --git a/_layouts/default.html b/_layouts/default.html
@@ -1,27 +1,26 @@
 <!doctype html>
-<html>
+<html lang="en">
 <head>
 <meta charset="utf-8">
-<meta name="viewport" content="width=device-width initial-scale=1">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
-<title>{% if page.title %}{{ page.title }}{% else %}{{ site.title }}{% endif %}</title>
 <meta name="description" content="{{ site.description }}">
-<link rel="stylesheet" href="{% link css/main.css %}">
-<link rel="stylesheet" href="{% link css/pygments.css %}">
-<link rel="canonical" href="{{ page.url | absolute_url }}">
+<link rel="canonical" href="{% canonical page.url %}">
+<link rel="stylesheet" href="/css/main.css">
+<title>{% if title %}{{ title }}{% else %}{{ site.title }}{% endif %}</title>
 </head>
 <body>
-<div id="header">
-<div id="logo">
-<a href="{{ site.baseurl }}/">{{ site.title }}</a>
+<div class="header">
+<div class="menu">
+<a href="/">{{ site.title }}</a>
 </div>
-<div id="menu">
-<a href="{{ site.source-link }}">Source</a>
-<a href="{{ site.issues-link }}">Issues</a>
+<div class="menu">
+<a href="{{ site.source }}">Source</a>
+<a href="{{ site.issues }}">Issues</a>
 </div>
 </div>
-<div id="content">
-{{ content }}
+<div class="content">
+{{ content -}}
 </div>
 </body>
 </html>
diff --git a/_layouts/identity.liquid b/_layouts/identity.liquid
@@ -0,0 +1 @@
+{{ content -}}
diff --git a/_layouts/page.html b/_layouts/page.html
@@ -1,5 +1,5 @@
 ---
-layout: default
+layout: default.html
 ---
-<h1>{{ page.title }}</h1>
-{{ content }}
+<h1>{{ title }}</h1>
+{{ content -}}
diff --git a/alpine.md b/alpine.md
@@ -1,26 +1,22 @@
 ---
-layout: page
 title: Alpine with pre-built applications
 ---
 
-Introduction
------
+## Introduction
 
 To simplify maintenance and distribution of the pre-built applications described in the Red Pitaya notes, I've put together a bootable SD card image based on the lightweight [Alpine Linux](https://alpinelinux.org) distribution.
 
-Getting started
------
+## Getting started
 
- - Download [SD card image zip file]({{ site.release-image }}).
+ - Download [SD card image zip file]({{ site.release_image }}).
  - Copy the contents of the SD card image zip file to a micro SD card.
  - Optionally, to start one of the applications automatically at boot time, copy its `start.sh` file from `apps/<application>` to the topmost directory on the SD card.
  - Install the micro SD card in the Red Pitaya board and connect the power.
  - Applications can be started from the web interface.
 
 The default password for the `root` account is `changeme`.
 
-Network configuration
------
+## Network configuration
 
 Wi-Fi is by default configured in hotspot mode with the network name (SSID) and password both set to `RedPitaya`. When in hotspot mode, the IP address of Red Pitaya is [192.168.42.1](http://192.168.42.1).
 
@@ -32,13 +28,12 @@ From systems with enabled DNS Service Discovery (DNS-SD), Red Pitaya can be acce
 
 In the local networks with enabled local DNS, Red Pitaya can also be accessed as `rp-f0xxxx`.
 
-Useful commands
------
+## Useful commands
 
 The [Alpine Wiki](https://wiki.alpinelinux.org) contains a lot of information about administrating [Alpine Linux](https://alpinelinux.org). The following is a list of some useful commands.
 
 Switching to client Wi-Fi mode:
-{% highlight bash %}
+```bash
 # configure WPA supplicant
 wpa_passphrase SSID PASSPHRASE > /etc/wpa_supplicant/wpa_supplicant.conf
 
@@ -47,33 +42,33 @@ wpa_passphrase SSID PASSPHRASE > /etc/wpa_supplicant/wpa_supplicant.conf
 
 # save configuration changes to SD card
 lbu commit -d
-{% endhighlight %}
+```
 
 Switching to hotspot Wi-Fi mode:
-{% highlight bash %}
+```bash
 # configure services for hotspot Wi-Fi mode
 ./wifi/hotspot.sh
 
 # save configuration changes to SD card
 lbu commit -d
-{% endhighlight %}
+```
 
 Changing password:
-{% highlight bash %}
+```bash
 passwd
 
 lbu commit -d
-{% endhighlight %}
+```
 
 Installing packages:
-{% highlight bash %}
+```bash
 apk add gcc make
 
 lbu commit -d
-{% endhighlight %}
+```
 
 Editing WSPR configuration:
-{% highlight bash %}
+```bash
 # make SD card writable
 rw
 
@@ -82,10 +77,9 @@ nano apps/sdr_transceiver_wspr/decode-wspr.sh
 
 # make SD card read-only
 ro
-{% endhighlight %}
+```
 
-Troubleshooting
------
+## Troubleshooting
 
 It is normal that there are no blinking LEDs after booting the Red Pitaya board with this SD card image.
 
@@ -94,11 +88,11 @@ The boot process can be checked using the USB/serial console as explained at [th
 The getting started instructions are known to work with a freshly unpacked factory formatted (single partition, FAT32 file system) micro SD card.
 
 If the micro SD card was previously partitioned and formatted for other purposes, then the following commands can be used to format it:
-{% highlight bash %}
+```bash
 parted -s /dev/mmcblk0 mklabel msdos
 parted -s /dev/mmcblk0 mkpart primary fat32 4MiB 100%
 mkfs.vfat -v /dev/mmcblk0p1
-{% endhighlight %}
+```
 where `/dev/mmcblk0` is the name of the device corresponding to the micro SD card.
 
 It is also possible to write an empty SD card image with a single FAT32 partition instead of using partitioning and formatting commands. For example, a repository with several empty SD card images can be found at [this link](https://github.com/procount/fat32images).

diff --git a/axi-hub.md b/axi-hub.md
@@ -1,30 +1,26 @@
 ---
-layout: page
 title: AXI4 hub
 ---
 
-Requirements
------
+## Requirements
 
 All applications in this repository have a structure similar to the one shown in the following diagram:
 
-![Application structure]({% link img/application-structure.png %})
+![Application structure](/img/application-structure.png)
 
 To control, monitor and communicate with all parts of the applications, the following items are required:
 - configuration registers
 - status registers
 - AXI4-Stream interfaces
 - BRAM interfaces
 
-Hub interface
------
+## Hub interface
 
 The hub interface consists of all required registers and interfaces connected to the different parts of the applications and an AXI4 slave interface used to communicate with the CPU.
 
 The corresponding Verilog code can be found in [cores/axi_hub.v](https://github.com/pavel-demin/red-pitaya-notes/blob/master/cores/axi_hub.v).
 
-Addresses
------
+## Addresses
 
 Bits 24-26 of the address are used to select one of the hub ports:
 
@@ -39,11 +35,10 @@ interface 3     | 5
 interface 4     | 6
 interface 5     | 7
 
-Usage examples
------
+## Usage examples
 
 A basic project with the hub interface, ADC interface, and DAC interface is shown in the following diagram:
 
-![Template project]({% link img/template-project.png %})
+![Template project](/img/template-project.png)
 
 This template project can be used as a starting point for projects requiring ADC, DAC and hub interface. The Tcl code of this project can be found in [projects/template](https://github.com/pavel-demin/red-pitaya-notes/tree/master/projects/template).
diff --git a/axi-interface-buffers.md b/axi-interface-buffers.md
@@ -1,45 +1,41 @@
 ---
-layout: page
 title: Buffers for AXI4, AXI4-Lite and AXI4-Stream interfaces
 ---
 
-Interesting links
------
+## Interesting links
 
 Some interesting links on implementation of buffers and AXI4 interfaces:
 
  - [Building a custom yet functional AXI-lite slave](https://zipcpu.com/blog/2019/01/12/demoaxilite.html)
 
  - [Building a Skid Buffer for AXI processing](https://zipcpu.com/blog/2019/05/22/skidbuffer.html)
 
- - [Pipeline Skid Buffer](http://fpgacpu.ca/fpga/Pipeline_Skid_Buffer.html)
+ - [Pipeline Skid Buffer](https://fpgacpu.ca/fpga/Pipeline_Skid_Buffer.html)
 
-Requirements
------
+## Requirements
 
 Since the AXI4 protocol specification requires that there are no combinational paths between input and output signals, it is useful to have reusable modules that would add the registers to the output signals of AXI4 interfaces.
 
 To achieve good performance, these modules should have low resource usage and minimal latency.
 
 Here are the main signals of the read address and read data parts of the AXI4 slave interface:
-{% highlight Verilog %}
+```Verilog
 input  wire [ADDR_WIDTH-1:0] s_axi_araddr,  // AXI4-Lite slave: Read address
 input  wire                  s_axi_arvalid, // AXI4-Lite slave: Read address valid
 output wire                  s_axi_arready, // AXI4-Lite slave: Read address ready
 
 output wire [DATA_WIDTH-1:0] s_axi_rdata,   // AXI4-Lite slave: Read data
 output wire                  s_axi_rvalid,  // AXI4-Lite slave: Read data valid
 input  wire                  s_axi_rready   // AXI4-Lite slave: Read data ready
-{% endhighlight %}
+```
 
 In the read address part of the interface, the `arready` signal should have a register. In the read data part of the interface, the `rdata` and `rvalid` signals should have registers. So, two types of buffers are needed, one with one register on the data input side and one with two registers on the data output side as shown in the diagrams below:
 
-![Two types of interface buffers]({% link img/interface-buffers.png %})
+![Two types of interface buffers](/img/interface-buffers.png)
 
 If an interface buffer with registers on both sides is required, then these two types of buffers can be chained together to create such a buffer.
 
-Input buffer
------
+## Input buffer
 
 The `in_ready` signal of the input buffer should have a register and this buffer should have the following behavior:
  - `in_ready` register is set to high during reset
@@ -48,27 +44,25 @@ The `in_ready` signal of the input buffer should have a register and this buffer
 
 A circuit implementing this behavior is shown in the following diagram:
 
-![Input buffer]({% link img/input-buffer.png %})
+![Input buffer](/img/input-buffer.png)
 
 The corresponding Verilog code can be found in [modules/input_buffer.v](https://github.com/pavel-demin/red-pitaya-notes/tree/master/modules/input_buffer.v).
 
-Output buffer
------
+## Output buffer
 
 The `out_valid` and `out_data` signals of the output buffer should have registers and these registers should be updated while `out_ready` is high or `out_valid` is low.
 
 A circuit implementing this behavior is shown in the following diagram:
 
-![Output buffer]({% link img/output-buffer.png %})
+![Output buffer](/img/output-buffer.png)
 
 The corresponding Verilog code can be found in [modules/output_buffer.v](https://github.com/pavel-demin/red-pitaya-notes/tree/master/modules/output_buffer.v).
 
 Since the `in_ready` signal is used to enable the data register, it can also be used to enable data registers outside the output buffer module. This feature can be useful when controlling a pipeline that provides enable inputs for its internal registers, like for example the internal registers in [DSP48E1](https://docs.xilinx.com/v/u/en-US/ug479_7Series_DSP48E1) as shown in the diagram below:
 
-![Output buffers and DSP48]({% link img/output-buffers-dsp48.png %})
+![Output buffers and DSP48](/img/output-buffers-dsp48.png)
 
-Usage examples
------
+## Usage examples
 
 The Verilog code of the modules that use these input and output buffers can be found at the following links: