chore: remove redundant H1s
This commit is contained in:
parent
cc8a6f8ec9
commit
52f4420b73
39 changed files with 102 additions and 146 deletions
|
|
@ -3,8 +3,6 @@ tags: [fleeting, computer-history, ARPA]
|
|||
created: Monday, October 14, 2024
|
||||
---
|
||||
|
||||
# 861cc26e_ARPA_origins
|
||||
|
||||
After Sputnik, Eisenhower wanted a dedicated, cross-departmental division within
|
||||
the US government to focus on advanced technological research so that they would
|
||||
not be caught out again. ARPA was the result.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [AWS]
|
||||
---
|
||||
|
||||
# AWS CloudWatch
|
||||
|
||||
AWS CloudWatch is a monitoring and observability service offered by Amazon Web
|
||||
Services (AWS). It is designed to help users collect, track, and analyze various
|
||||
metrics, logs, and events related to their AWS resources and applications
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- databases
|
||||
---
|
||||
|
||||
# Accessing metadata about SQL database
|
||||
|
||||
```sql
|
||||
SHOW DATABASES
|
||||
|
||||
|
|
|
|||
|
|
@ -2,16 +2,13 @@
|
|||
tags: [graphql]
|
||||
---
|
||||
|
||||
# Apollo Client
|
||||
|
||||
Apollo Client is the client-side counterpart to
|
||||
[Apollo Server](Apollo_Server.md). We use it for
|
||||
managing queries and mutations from the frontend to our Apollo GraphQL server.
|
||||
It is specifically designed to work with React.
|
||||
[Apollo Server](Apollo_Server.md). We use it for managing queries and mutations
|
||||
from the frontend to our Apollo GraphQL server. It is specifically designed to
|
||||
work with React.
|
||||
|
||||
> We will be working with the
|
||||
> [schema](Apollo_Server.md#example-schema) we defined
|
||||
> when working on the server
|
||||
> We will be working with the [schema](Apollo_Server.md#example-schema) we
|
||||
> defined when working on the server
|
||||
|
||||
## Initializing the client
|
||||
|
||||
|
|
@ -39,7 +36,7 @@ ReactDOM.render(
|
|||
<GlobalStyles />
|
||||
<Pages />
|
||||
</ApolloProvider>,
|
||||
document.getElementById("root")
|
||||
document.getElementById("root"),
|
||||
);
|
||||
```
|
||||
|
||||
|
|
@ -54,9 +51,8 @@ between the frontend and the backend, it is not itself executable code.
|
|||
|
||||
Therefore, for each query in the schema we must write a frontend implementation.
|
||||
We do this with **query constants**. The frontend implementation has a backend
|
||||
analogue: the
|
||||
[resolver](Apollo_Server.md#implementing-resolvers)
|
||||
that is invoked when the frontend issues a query. The schema standardises this
|
||||
analogue: the [resolver](Apollo_Server.md#implementing-resolvers) that is
|
||||
invoked when the frontend issues a query. The schema standardises this
|
||||
relationship so that every query on the client must have a corresponding
|
||||
resolver on the backend.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- operating-systems
|
||||
---
|
||||
|
||||
# Boot process
|
||||
|
||||
The primary or boot
|
||||
[partition](Disks.md#primary-extended-and-logical-partitions) of a harddisk
|
||||
contains a bootloader. It is the job of the bootloader to locate the
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags:
|
|||
- shell
|
||||
---
|
||||
|
||||
# Capturing user input in Bash
|
||||
|
||||
We use [read](/zk/Read_command__in_Bash.md) to gather user input.
|
||||
|
||||
## Capturing raw inputs
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [shell]
|
|||
created: Wednesday, February 19, 2025
|
||||
---
|
||||
|
||||
# Check if value is null in Bash
|
||||
|
||||
```sh
|
||||
if [ -z $var ]; then
|
||||
# Value is null
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [literature]
|
|||
created: Tuesday, March 25, 2025
|
||||
---
|
||||
|
||||
# _Code Craft: The Practice Of Writing Excellent Code_
|
||||
|
||||
## Clarity not brevity
|
||||
|
||||
> Readability is the best single criterion of program quality: If a program is
|
||||
|
|
@ -83,7 +81,6 @@ doesn't necessarily require automated tools or excessive commentary.
|
|||
- Try to throw errors close enough to the source to prevent obscure and
|
||||
out-of-context error handling _while_ being far enough away not to cloud
|
||||
normal code with roundabout paths.
|
||||
|
||||
- _This is something I struggle with. The error is caught later than when it
|
||||
occurs and then all I have is a generic catch-all error that is hard to make
|
||||
sense of._
|
||||
|
|
|
|||
|
|
@ -7,8 +7,6 @@ tags:
|
|||
- databases
|
||||
---
|
||||
|
||||
# Creating a RESTful API: Integrating the database
|
||||
|
||||
So far we have set up the application and an `/api/courses` route which handles
|
||||
requests for RESTful API operations on a local array of course objects. We now
|
||||
want to have the endpoints operate on a MongoDB `courses` collection rather than
|
||||
|
|
@ -17,10 +15,10 @@ the array.
|
|||
## Set-up
|
||||
|
||||
We will follow the routine for establishing a MongoDB instance as detailed in
|
||||
[my notes](Connect_to_Mongo_database.md) on Mongo:
|
||||
[my notes](/zk/Connect_to_Mongo_database.md) on Mongo:
|
||||
|
||||
- [Create MongoDB database](Create_Mongo_database.md)
|
||||
- [Connect to MongoDB database](Connect_to_Mongo_database.md)
|
||||
- [Create MongoDB database](/zk/Create_Mongo_database.md)
|
||||
- [Connect to MongoDB database](/zk/Connect_to_Mongo_database.md)
|
||||
|
||||
Our `index.js` now looks like the following:
|
||||
|
||||
|
|
@ -111,7 +109,7 @@ const Course = mongoose.model(
|
|||
tags: [String],
|
||||
data: { type: Date, default: Date.now }, // if unspecified, entry will default to current date
|
||||
isPublished: Boolean,
|
||||
})
|
||||
}),
|
||||
);
|
||||
```
|
||||
|
||||
|
|
@ -124,8 +122,8 @@ const Course = mongoose.model(
|
|||
|
||||
Now we need to rewrite our RESTful request handlers so that the data is sourced
|
||||
from and added to the database. We will mainly be using the Mongo syntax defined
|
||||
at [Querying a collection](Querying_a_Mongo_collection.md) and
|
||||
[Adding documents to a collection](Adding_documents_to_a_Mongo_collection.md).
|
||||
at [Querying a collection](/zk/Querying_a_Mongo_collection.md) and
|
||||
[Adding documents to a collection](/zk/Adding_documents_to_a_Mongo_collection.md).
|
||||
We will also keep API validation within the `/model/` file.
|
||||
|
||||
### GET
|
||||
|
|
@ -176,8 +174,8 @@ router.post("/", async (req, res) => {
|
|||
### PUT
|
||||
|
||||
When updating a value in the database we are going to use the
|
||||
[query-first](Update_a_Mongo_document.md#query-first-document-update)
|
||||
approach to updating a Mongo document.
|
||||
[query-first](Update_a_Mongo_document.md#query-first-document-update) approach
|
||||
to updating a Mongo document.
|
||||
|
||||
```jsconst courseSchema = new mongoose.Schema({
|
||||
name: {type: String, required: true, minlength: 5, maxlength: 255},
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags:
|
|||
- theory-of-computation
|
||||
---
|
||||
|
||||
# Defining a computer
|
||||
|
||||
> A general-purpose computer is one that, given the appropriate instructions and
|
||||
> required time, should be able to perform most common computing tasks.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- prealgebra
|
||||
---
|
||||
|
||||
# The Distributive Property of Multiplication
|
||||
|
||||
**Let $a$, $b$ represent members of $\mathbb{W}$ or $\mathbb{Z}$ then:**
|
||||
|
||||
$$ a \cdot (b + c) = a \cdot b + a \cdot c $$
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@ tags:
|
|||
created: Saturday, March 30, 2024
|
||||
---
|
||||
|
||||
# Docker CLI
|
||||
|
||||
```sh
|
||||
# List images
|
||||
docker image ls
|
||||
|
|
|
|||
|
|
@ -2,15 +2,13 @@
|
|||
tags: [docker, containerization]
|
||||
---
|
||||
|
||||
# Docker architecture
|
||||
|
||||
## Overview
|
||||
|
||||

|
||||
|
||||
- The Docker Client is a thin API for making
|
||||
[REST API](RESTful_APIs.md) to the Docker Server. Any CLI
|
||||
command beginning `docker...` is an API request to the server.
|
||||
- The Docker Client is a thin API for making [REST API](RESTful_APIs.md) to the
|
||||
Docker Server. Any CLI command beginning `docker...` is an API request to the
|
||||
server.
|
||||
- The internal process name for the server is `dockerd`.
|
||||
- On `docker run...`, `dockerd` calls `containerd`. This process starts the
|
||||
container runtimes and configures container-level storage and networking.
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [world-wide-web]
|
|||
created: Friday, December 20, 2024
|
||||
---
|
||||
|
||||
# Dynamic and static websites
|
||||
|
||||
When we talk about dynamic and static websites we are talking about the role of
|
||||
the server, not anything to do with how the website behaves for the user.
|
||||
|
||||
|
|
|
|||
42
zk/ESP32_project_structure.md
Normal file
42
zk/ESP32_project_structure.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
tags:
|
||||
- C
|
||||
- ESP32
|
||||
- ESP-IDF
|
||||
---
|
||||
|
||||
For a project named `example-project`.
|
||||
|
||||
```
|
||||
example-project/
|
||||
CMakeLists.txt
|
||||
main/
|
||||
main.c
|
||||
CMakeList.txt
|
||||
|
||||
```
|
||||
|
||||
The parent `CMakeLists.txt`:
|
||||
|
||||
```
|
||||
cmake_minimum_required(VERSION 3.16)
|
||||
# This env var is sourced from:
|
||||
# . /opt/esp-idf/export.sh
|
||||
# when the compilation terminal session starts
|
||||
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
|
||||
project(example-project)
|
||||
|
||||
```
|
||||
|
||||
The `CMakeLists.txt` in `main/`:
|
||||
|
||||
```
|
||||
idf_component_register(SRCS "main.c"
|
||||
INCLUDE_DIRS ".")
|
||||
```
|
||||
|
||||
Both must exist before you run `idf.py build`.
|
||||
|
||||
The `build/` directory and `sdkconfig` files will be created either when you run
|
||||
`idf.py set target` or the first build (not sure of sequence, but anyway they
|
||||
are autogenerated).
|
||||
|
|
@ -4,10 +4,7 @@ tags:
|
|||
- databases
|
||||
---
|
||||
|
||||
# Creating views with foreign keys
|
||||
|
||||
We utilise **foreign** and
|
||||
[primary keys](Primary_key.md) to create
|
||||
We utilise **foreign** and [primary keys](Primary_key.md) to create
|
||||
relationships between tables in SQL. Foreign keys link data in one table to the
|
||||
data in another table and are how we cross-reference data in SQL.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [ARPANET, networks, computer-history]
|
|||
created: Friday, October 18, 2024
|
||||
---
|
||||
|
||||
# e470bf3d_IMPs_in_the_ARPANET
|
||||
|
||||
Within the #ARPANET, IMPs (Information Message Processors) were nodes
|
||||
distinguished from [hosts](Network_hosts.md). They were computers designed to
|
||||
receive and route the the packets from one host to another, described as
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [networks, internet]
|
|||
created: Friday, August 16, 2024
|
||||
---
|
||||
|
||||
# IP addresses
|
||||
|
||||
## IPv4 vs IPv6
|
||||
|
||||
IP addresses come in two formats and bit-lengths depending on which version of
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [git]
|
||||
---
|
||||
|
||||
# Interactive staging
|
||||
|
||||
With interactive staging we can stage sub-portions of files rather than the
|
||||
whole file. This makes commits much more targetted and atomic.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [javascript]
|
|||
created: Sunday, November 24, 2024
|
||||
---
|
||||
|
||||
# JavaScript module types
|
||||
|
||||
The following info is useful when you wish to use modern JavaScript tooling
|
||||
outside of a build system.
|
||||
|
||||
|
|
@ -17,15 +15,12 @@ Great account by
|
|||
In essence there are three main module formats:
|
||||
|
||||
- CommonJS
|
||||
|
||||
- Native Node JS module system using `require()` and `module.exports()`
|
||||
|
||||
- ESModules
|
||||
|
||||
- The defacto standard that works in both the browser and Node.js
|
||||
|
||||
- AMD
|
||||
|
||||
- A browser-friendly version of CommonJS since superseded by ESModules
|
||||
|
||||
Then there is UMD, _Universal Module Definition_. This is a wrapper that
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- LoRa
|
||||
---
|
||||
|
||||
# LoRa radio
|
||||
|
||||
LoRa (which stands for "long range") is a proprietary method of radio
|
||||
communication.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [logic-gates, binary]
|
||||
---
|
||||
|
||||
# Logic gates
|
||||
|
||||
> [A logic gate consists in] three connections where there may or may not be
|
||||
> some electricity. Two of those connections are places where electricity may be
|
||||
> put into the device, and the third connection is a place where electricity may
|
||||
|
|
@ -15,21 +13,18 @@ tags: [logic-gates, binary]
|
|||
Logic gates are the basic building blocks of digital computing. **A logic gate
|
||||
is an electrical circuit that has one or more than one input and only one
|
||||
output.** The input and output points of the gate are
|
||||
[pins](Integrated_circuits.md) The
|
||||
input controls the output and the logic determining which types of input
|
||||
(on/off) lead to specific outputs (on/off) is isomorphic with the
|
||||
truth-conditions of the
|
||||
[Boolean connectives](Truth-functional_connectives.md) specifiable in
|
||||
terms of [truth tables](Truth-tables.md).
|
||||
[pins](Integrated_circuits.md) The input controls the output and the logic
|
||||
determining which types of input (on/off) lead to specific outputs (on/off) is
|
||||
isomorphic with the truth-conditions of the
|
||||
[Boolean connectives](Truth-functional_connectives.md) specifiable in terms of
|
||||
[truth tables](Truth-tables.md).
|
||||
|
||||
Physically, what 'travels through' the gates is electrical current and what
|
||||
constitutes the 'gate' is a
|
||||
[transistor](Transistors.md)
|
||||
responding to the current. Going up a level of abstraction, the current/ charge
|
||||
is identified with a
|
||||
[bit](Binary_units_of_measurement.md#binary-units-of-measurement).
|
||||
It is bits that go into the gate and bits which come out: binary information
|
||||
that may be either 1 or 0.
|
||||
constitutes the 'gate' is a [transistor](Transistors.md) responding to the
|
||||
current. Going up a level of abstraction, the current/ charge is identified with
|
||||
a [bit](Binary_units_of_measurement.md#binary-units-of-measurement). It is bits
|
||||
that go into the gate and bits which come out: binary information that may be
|
||||
either 1 or 0.
|
||||
|
||||
## Elementary and composite gates
|
||||
|
||||
|
|
@ -41,11 +36,9 @@ one elemen>tary gate and/or other composite gates.
|
|||
An example of a composite gate would be a three-way AND. An AND with three
|
||||
inputs rather than the standard two that furnish the elementary AND gate. This
|
||||
gate would output 1 when all three gates have the value 1 and 0 otherwise.
|
||||
[Adders](Half_adder_and_full_adder.md)
|
||||
and [latche>s](Latches.md) whilst
|
||||
being
|
||||
[integrated circuits](Integrated_circuits.md)
|
||||
are also, technically speaking, composite gates.
|
||||
[Adders](Half_adder_and_full_adder.md) and [latche>s](Latches.md) whilst being
|
||||
[integrated circuits](Integrated_circuits.md) are also, technically speaking,
|
||||
composite gates.
|
||||
|
||||
## Gate interface / gate implementation
|
||||
|
||||
|
|
@ -68,8 +61,7 @@ represented in the interface diagram.
|
|||
> Importantly, a single interface may be implemented in a variety of ways. There
|
||||
> is a one-to-many relationship at work here. From the point of view of the user
|
||||
> interface these differences should not be detectable. This is another example
|
||||
> of
|
||||
> [hardware abstraction](Hardware_abstraction_and_modularity.md)
|
||||
> of [hardware abstraction](Hardware_abstraction_and_modularity.md)
|
||||
|
||||
## NOT gate
|
||||
|
||||
|
|
@ -134,8 +126,8 @@ NANDs alone.
|
|||
## OR gate
|
||||
|
||||
> The OR gate represents the truth conditions of the
|
||||
> [disjunction](Truth-functional_connectives### Truth
|
||||
> conditions.md#disjunction) truth functional connective
|
||||
> [disjunction](Truth-functional_connectives### Truth conditions.md#disjunction)
|
||||
> truth functional connective
|
||||
|
||||
### Symbol
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- logic
|
||||
---
|
||||
|
||||
## Logical possibility
|
||||
|
||||
In distinguishing the properties of
|
||||
[logical consistency](Logical_consistency.md) and
|
||||
[validity](Validity_and_entailment.md) we make tacit use of the notion of
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [python]
|
||||
---
|
||||
|
||||
# Match statements in Python
|
||||
|
||||
> A `match` statement is the equivalent of a switch or case statement in Python
|
||||
|
||||
```python
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [python]
|
||||
---
|
||||
|
||||
# Python naming conventions
|
||||
|
||||
## Underscores
|
||||
|
||||
To name a variable or method with multiple words we use underscores to separate
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [python, data-types]
|
||||
---
|
||||
|
||||
# None in Python
|
||||
|
||||
`None` is not `null`, it is closer to `undefined` in JS. If you define a
|
||||
variable as `None`, the variable exists, it is just not yet defined.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,8 +5,6 @@ tags:
|
|||
- arch-linux
|
||||
---
|
||||
|
||||
# Pacman
|
||||
|
||||
## List all installed packages
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- data-types
|
||||
---
|
||||
|
||||
# Primitive types
|
||||
|
||||
The most basic type level is the one already present in JavaScript itself: the
|
||||
primitive data types: `boolean`, `string` and `number` . These are the types
|
||||
that would be returned from a `typeof` expression in ordinary JavaScript
|
||||
|
|
@ -38,8 +36,8 @@ const store: string[] = []; // Empty array
|
|||
## Object
|
||||
|
||||
`Object` is a valid type declaration in TS but it is not particularly helpful
|
||||
since it becomes similar to using [any](Any.md) given that most primitive
|
||||
types in JavaScripts prototypically inherit from an Object.
|
||||
since it becomes similar to using [any](Any.md) given that most primitive types
|
||||
in JavaScripts prototypically inherit from an Object.
|
||||
|
||||
Generally, when you use objects in TypeScript you type them as
|
||||
[custom types](Custom_types_in_TypeScript.md).
|
||||
|
|
|
|||
|
|
@ -5,8 +5,6 @@ tags:
|
|||
created: Thursday, February 29, 2024 | 17:33
|
||||
---
|
||||
|
||||
# Printing values in C
|
||||
|
||||
## To print a literal
|
||||
|
||||
```c
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ idf.py build
|
|||
### Flash to the device
|
||||
|
||||
```sh
|
||||
idf.py -p /dev/ttyUSB0 monitor
|
||||
idf.py flash
|
||||
```
|
||||
|
||||
Example output:
|
||||
|
|
@ -158,3 +158,9 @@ This is esp32 chip with 2 CPU core(s), WiFi/BTBLE, silicon revision v3.1, 2MB ex
|
|||
Minimum free heap size: 306072 bytes
|
||||
Restarting in 10 seconds...
|
||||
```
|
||||
|
||||
### Clean the build cache
|
||||
|
||||
```sh
|
||||
idf.py fullclean
|
||||
```
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
tags: [git, procedural]
|
||||
---
|
||||
|
||||
# Rename a branch
|
||||
|
||||
### In local development
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [ecopolsoc, internet]
|
|||
created: Thursday, November 07, 2024
|
||||
---
|
||||
|
||||
# 0716531c_rewilding_the_internet
|
||||
|
||||
The following
|
||||
[analogy](https://www.noemamag.com/we-need-to-rewild-the-internet/) can be
|
||||
useful in understanding how the internet has become such a negative environment.
|
||||
|
|
|
|||
2
zk/S3.md
2
zk/S3.md
|
|
@ -2,8 +2,6 @@
|
|||
tags: [AWS]
|
||||
---
|
||||
|
||||
# S3
|
||||
|
||||
You can think of S3 as an external mounted harddrive for storing raw binary data
|
||||
(images, soundfiles, documents etc).
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,6 @@ tags:
|
|||
- data-types
|
||||
---
|
||||
|
||||
# Strings in bash
|
||||
|
||||
## Return a substring by index
|
||||
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -3,11 +3,9 @@ tags:
|
|||
- shell
|
||||
---
|
||||
|
||||
# The `$PATH`
|
||||
|
||||
We know that `$PATH` is an
|
||||
[environment variable](Environmental_and_shell_variables.md).
|
||||
This variable keeps track of directories **where executables are found**.
|
||||
[environment variable](Environmental_and_shell_variables.md). This variable
|
||||
keeps track of directories **where executables are found**.
|
||||
|
||||
Whenever any command is run, the shell looks up the directories contained in the
|
||||
`PATH` for the target executable file and runs it. We can see this is the case
|
||||
|
|
|
|||
|
|
@ -4,13 +4,11 @@ tags:
|
|||
- logic
|
||||
---
|
||||
|
||||
# Theorems and empty sets
|
||||
|
||||
We know that when we construct a
|
||||
[derivation](Formal_proofs_in_propositional_logic.md#derivation-rules) we start
|
||||
from a set of assumptions and then attempt to reach a proposition that is a
|
||||
consequence of the starting assumptions. However it does not always have to be
|
||||
the case that the starting set contains members. The set can in fact be empty.
|
||||
[derivation](/zk/Formal_proofs_in_propositional_logic.md) we start from a set of
|
||||
assumptions and then attempt to reach a proposition that is a consequence of the
|
||||
starting assumptions. However it does not always have to be the case that the
|
||||
starting set contains members. The set can in fact be empty.
|
||||
|
||||
_Demonstration_
|
||||
|
||||
|
|
|
|||
|
|
@ -5,12 +5,9 @@ tags:
|
|||
- memory
|
||||
---
|
||||
|
||||
# 3-bit Counter
|
||||
|
||||
To demonstrate the use of
|
||||
[Flip-Flops](Flip_flops.md) we will
|
||||
create the circuit for a 3-bit counter. This simply counts up from 0 to 7
|
||||
because 7 is the maximum decimal number we can create with three bits ($2^3$):
|
||||
To demonstrate the use of [Flip-Flops](Flip_flops.md) we will create the circuit
|
||||
for a 3-bit counter. This simply counts up from 0 to 7 because 7 is the maximum
|
||||
decimal number we can create with three bits ($2^3$):
|
||||
|
||||
| Binary | Decimal |
|
||||
| ------ | ------- |
|
||||
|
|
@ -24,12 +21,10 @@ because 7 is the maximum decimal number we can create with three bits ($2^3$):
|
|||
| 111 | 7 |
|
||||
|
||||
The circuit will have three memory components, each representing one bit of the
|
||||
3-bit number. When the
|
||||
[clock pulses](Clock_signals.md), the
|
||||
3-bit number increments by one. We need to synchronise the operation with a
|
||||
clock because each bit by itself is meaningless, it only gains meaning by the
|
||||
relation it sustains to the other two bits hence it must be kept in sync with
|
||||
them.
|
||||
3-bit number. When the [clock pulses](Clock_signals.md), the 3-bit number
|
||||
increments by one. We need to synchronise the operation with a clock because
|
||||
each bit by itself is meaningless, it only gains meaning by the relation it
|
||||
sustains to the other two bits hence it must be kept in sync with them.
|
||||
|
||||
We can derive the circuit arrangement by analysing the outputs of a flipflop at
|
||||
each pulse:
|
||||
|
|
@ -52,10 +47,8 @@ If we look at the pattern of each flip-flops' output we notice the following:
|
|||
- _Q2_ toggles when both _Q1_ and _Q0_ were previously 1
|
||||
|
||||
This means that to construct a circuit that displays this behaviour we just have
|
||||
to use a
|
||||
[T flip-flop](Flip_flops.md#t-flip-flops)
|
||||
since the only state change we need is a single bit toggle three times that
|
||||
retains its value.
|
||||
to use a [T flip-flop](Flip_flops.md#t-flip-flops) since the only state change
|
||||
we need is a single bit toggle three times that retains its value.
|
||||
|
||||
Using these pulse patterns we can construct a circuit as follows:
|
||||

|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [python, JSON]
|
|||
created: Tuesday, June 25, 2024
|
||||
---
|
||||
|
||||
# Working with JSON in Python
|
||||
|
||||
## `json.loads()`
|
||||
|
||||
Convert a string containing JSON data into the native Python dictionary object.
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@ tags: [permissions, Linux]
|
|||
created: Friday, April 11, 2025
|
||||
---
|
||||
|
||||
# chmod
|
||||
|
||||
Modify file permissions.
|
||||
|
||||
We can use symbols or numbers.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue