mirror of
https://github.com/isometimes/rpi4-osdev
synced 2024-11-22 02:00:40 +00:00
Fix SI units
This commit is contained in:
parent
504a05560c
commit
2b9e41259b
3 changed files with 5 additions and 5 deletions
|
@ -50,7 +50,7 @@ mov w1, 0x80000000
|
|||
str w1, [x0, #(LOCAL_PRESCALER - LOCAL_CONTROL)]
|
||||
```
|
||||
|
||||
You should remember the expected oscillator frequency of 54Mhz from part9. We set this with the following lines:
|
||||
You should remember the expected oscillator frequency of 54 MHz from part9. We set this with the following lines:
|
||||
|
||||
```c
|
||||
ldr x0, =OSC_FREQ
|
||||
|
|
|
@ -49,7 +49,7 @@ Configuring the UART
|
|||
|
||||
The second section of _io.c_ (marked with `// UART`) implements a few functions to help us talk to the UART. Thankfully, this device also uses MMIO, and you'll see the registers set up in the first `enum` just like you saw before. Look in the [BCM2711 ARM Peripherals document](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0.pdf) for a more detailed explanation of these registers.
|
||||
|
||||
I do just want to call out the `AUX_UART_CLOCK` parameter, which we set to `500000000`. Remember how I said that UART communication is all about timing? Well, this is exactly the same clock speed (500Mhz) that we set in _config.txt_ when we added the `core_freq_min=500` line. This is no coincidence!
|
||||
I do just want to call out the `AUX_UART_CLOCK` parameter, which we set to `500000000`. Remember how I said that UART communication is all about timing? Well, this is exactly the same clock speed (500 MHz) that we set in _config.txt_ when we added the `core_freq_min=500` line. This is no coincidence!
|
||||
|
||||
You'll also note some other familiar numbers in the `uart_init()` function, which we call directly from our `main()` routine in _kernel.c_. We set the baud rate to `115200`, and the number of bits to `8`.
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Notes to self
|
|||
Here are a few things I learned on this journey, which helped me along significantly:
|
||||
|
||||
* The Raspberry Pi 4 uses PWM1 for output on the audio jack when GPIO 40 and 41 are mapped to Alternate Function 0
|
||||
* The Raspberry Pi 4's clock oscillator frequency is 54Mhz
|
||||
* The Raspberry Pi 4's clock oscillator frequency is 54 MHz
|
||||
* PWM1 DMA is mapped to DMA channel 1
|
||||
* PWM1 is mapped to DREQ 1
|
||||
* We must use Legacy Master (starting `0x7E`, not `0xFE`) addresses for DMA transfers to peripherals
|
||||
|
@ -32,7 +32,7 @@ And always, always have a browser tab open on the [BCM2711 ARM Peripherals docum
|
|||
|
||||
Audio sample format
|
||||
-------------------
|
||||
_audio.bin_ is the audio file we'll be playing. Technically speaking, it's 8-bit, unsigned PCM data at 44.1Khz. This is an unusual format in this modern day and age, but it's easily converted using a tool like [ffmpeg](https://ffmpeg.org/).
|
||||
_audio.bin_ is the audio file we'll be playing. Technically speaking, it's 8-bit, unsigned PCM data at 44.1 KHz. This is an unusual format in this modern day and age, but it's easily converted using a tool like [ffmpeg](https://ffmpeg.org/).
|
||||
|
||||
To convert from our _.bin_ file to a _.wav_ file that any laptop can play natively, do this:
|
||||
|
||||
|
@ -50,7 +50,7 @@ I knew DMA transfers might be a tricky beast, so I began by just proving I could
|
|||
|
||||
Looking at `main()`, you'll see that we first call `audio_init()`. This function ensures that PWM1 is correctly mapped. PWM is a technique used to control analogue devices using digital signals. Whilst digital signals are either on (1 - full power) or off (0 - no power), analogue signals may be an infinite number of values between 1 and 0. PWM fakes an analogue signal by applying power in quick pulses/bursts of regulated voltage. The resultant average voltage will end up looking roughly like an analogue signal, despite not being one. Clever, eh?
|
||||
|
||||
These pulses/bursts do need to be highly accurate for this trick to work, and so we need a reliable clock source. Just like your kitchen clock ticks every second, so the oscillator on the Raspberry Pi 4 has a regular 'tick' - in this case, 54,000,000 times per second (54Mhz)! Our audio sample is at 44.1Khz though, so we need to 'slow it down'. We do this by first stopping the clock, then setting a clock divisor, setting the PWM range, and enabling the clock again. In my code, I use 2 as the clock divisor (so we're down to 27Mhz) and set the range to 612 (0x264). Essentially, this means that our PWM module will move to a new sample every 27,000,000/612 times per second - roughly equivalent to 44.1Khz, which just happens to be the sample rate of the included audio sample _audio.bin_ (I've included _audio.wav_ so you can listen normally on your laptop too!).
|
||||
These pulses/bursts do need to be highly accurate for this trick to work, and so we need a reliable clock source. Just like your kitchen clock ticks every second, so the oscillator on the Raspberry Pi 4 has a regular 'tick' - in this case, 54,000,000 times per second (54 MHz)! Our audio sample is at 44.1 KHz though, so we need to 'slow it down'. We do this by first stopping the clock, then setting a clock divisor, setting the PWM range, and enabling the clock again. In my code, I use 2 as the clock divisor (so we're down to 27 MHz) and set the range to 612 (0x264). Essentially, this means that our PWM module will move to a new sample every 27,000,000/612 times per second - roughly equivalent to 44.1 KHz, which just happens to be the sample rate of the included audio sample _audio.bin_ (I've included _audio.wav_ so you can listen normally on your laptop too!).
|
||||
|
||||
We then enable the PWM module, telling it to wait for sample data on its FIFO input, and we're good to go. Until we start filling the buffer, no audio will play.
|
||||
|
||||
|
|
Loading…
Reference in a new issue