Add SSD1306 example #18
Conversation
| @@ -0,0 +1,39 @@ | |||
| name: hardware-examples | |||
There was a problem hiding this comment.
The nightly compiler seems to be required to use an allocator in no_std programs, so I split this into a separate CI script.
| const BLOCK_SIZE_INCREMENT: u32 = 2; | ||
|
|
||
| #[global_allocator] | ||
| static ALLOCATOR: CortexMHeap = CortexMHeap::empty(); |
There was a problem hiding this comment.
Configuring an allocator so we can use a heap.
| ALLOCATOR.init( | ||
| &mut HEAP as *const u8 as usize, | ||
| core::mem::size_of_val(&HEAP), | ||
| ) |
There was a problem hiding this comment.
As I understand it, this allocates a chunk of free space in the stack, and then using that space as the heap. That avoids the issue where the stack and heap can collide, and since the allocator I'm using has a fixed size anyway, I don't think there's really a downside to this. See details here: knurling-rs/flip-link#62
| &mut rcc.apb1, | ||
| ); | ||
|
|
||
| let interface = I2CDisplayInterface::new(i2c); |
There was a problem hiding this comment.
The SSD1306 I'm using communicates over I2C, so this is just a bunch of boilerplate setting that up with the pins being used.
| let mut block_size: u32 = MIN_BLOCK_SIZE; | ||
|
|
||
| loop { | ||
| display.clear(); |
There was a problem hiding this comment.
Without this, any parts of the display that are untouched by the drawing code (because they are transparent, I guess) aren't reset back to black.
There was a problem hiding this comment.
@peterstuart I'm not following much of the embedded stuff but I see how the animation loop is working, nice to see it running on a physical display!
peterstuart
force-pushed
the
hardware-example
branch
from
7d3d093 to
5507d8d
Compare
There's some tearing (although it looks much worse in the video than real life).