profile
viewpoint

embedded-graphics/embedded-graphics 263

A no_std graphics library for embedded applications

jamwaffles/anim8 5

A no_std compatible low-level animation library written in Rust.

jamwaffles/blue-pill-rtfm-demo 4

Blue Pill quickstart with the Rust RTFM library

jamwaffles/esp8266-at 3

AT command set driver for the ESP8266

jamwaffles/FusionToolTranslator 3

Fusion360 to LinuxCNC tool table translator

jamwaffles/blue-pill-logic-analyser 2

I need to debug some WS2812 LEDs. Oscilloscopes cost too much. Now this.

jamwaffles/event-sauce 2

Rust implementation of the event sourcing paradigm

jamwaffles/asshole-dog 1

My neighbour's dog won't stop barking, therefore it is an asshole. This is an app for tracking precisely when it was an asshole as some weird form of catharsis.

jamwaffles/arduino-m0-pro-rust 0

Rust on your Arduino M0 Pro

issue commentjonas-schievink/rubble

Writeable attributes & attribute permissions

What's the best way to go about testing this? I don't see any existing tests for the att/gatt modules (I imagine because the API surface is still changing) or any mention in CONTRIBUTING.md. I can put together a demo of writeable attributes (which would double as both a test and an example), but I don't have a UART/USB adapter to test with logging (the hardware I have access to does have a JTAG connection so I can use RTT).

Also, is it all right to leave PrepareWriteReq/ExecuteWriteReq unimplemented for now? My understanding is that prepare write puts a chunk of a write into a queue to then be atomically executed upon seeing an execute command; since ReadBlob/ReadMultiple aren't yet implemented either it makes sense to me to hold off on the grouped writes as well.

Sorry for all the questions! I'm still fairly new to BLE, and I'd like to make sure I'm doing things right.

daboross

comment created time in an hour

issue commentjamwaffles/ssd1306

wrong part of the screen is updated for Rotate180 and <128 wide screens

It would help if someone who has a 72x40 could figure out the offsets necessary for a fix.

martin2250

comment created time in 6 hours

pull request commentembedded-graphics/embedded-graphics

Text alignment

The docs aren't great and some of this implementation might change when I implement BDF support. But if you find anything that needs additional documentation please add a note to #480 or #511.

rfuest

comment created time in 6 hours

issue openedembedded-graphics/embedded-graphics

Tracking issue for text rendering changes

  • [ ] Add FrameText #483
  • [ ] Imprt BDF code into embedded-bdf repo
  • [ ] Fix text examples The changes in PR #510 will break the examples
  • [ ] Add text alignment example
  • [ ] Use FrameText in analog clock example
  • [ ] Update builtin monospaced fonts or add additional fonts as separate repo
  • [ ] Try to distribute BDF fonts as crates
  • [ ] Add simple external font renderer example to e-g docs

created time in 6 hours

PR opened embedded-graphics/embedded-graphics

Text alignment

Thank you for helping out with embedded-graphics development! Please:

  • [ ] Check that you've added passing tests and documentation
  • [ ] Add a CHANGELOG.md entry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public API
  • [ ] Run rustfmt on the project
  • [ ] Run just build (Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.

PR description

This PR adds vertical and horizontal text alignment settings to MonoTextStyle. The default vertical alignment is now Baseline instead of Top and all builtin fonts now set the baseline.

I've also changed the implementation of MonoTextStyleBuilder to be more similar to the PrimitiveStyleBuilder. All settings can now be changed using setters and it's no longer required to pass the font to the new constructor.

+523 -92

0 comment

14 changed files

pr created time in 6 hours

created repositoryVOID404/aoc2020

created time in 9 hours

PR opened jonas-schievink/rubble

support nrf52811
+23 -3

0 comment

10 changed files

pr created time in 10 hours

push eventjonas-schievink/rubble

jonas-schievink

commit sha 685632aa7d5f06d47d1fa501d8a38ea62ffa2044

deploy: 329f3ff1afaa4c0c751bbd7a1d4daa39f51f0183

view details

push time in 13 hours

push eventjonas-schievink/rubble

Ulf Lilleengen

commit sha ac6551db5cd51ea9c00f7a48c5060173f798065b

Use public API in example GATT services

view details

Jonas Schievink

commit sha 329f3ff1afaa4c0c751bbd7a1d4daa39f51f0183

Merge pull request #163 from lulf/use-new-apis Use public API in example GATT services

view details

push time in 13 hours

PR merged jonas-schievink/rubble

Use public API in example GATT services

@jonas-schievink A follow-up from #162 so that others copying the example gatt services will have an easier time.

+39 -39

1 comment

1 changed file

lulf

pr closed time in 13 hours

pull request commentjonas-schievink/rubble

Use public API in example GATT services

Nice, thanks!

lulf

comment created time in 13 hours

push eventembedded-graphics/embedded-graphics

Ralf Fuest

commit sha c3992bf23c56994138c9b95d6d6f314d773a0904

Multiline text (#509) * Add additional text benches * Move handling of multiline text into Text * Add changelog entry * Address review comments

view details

push time in 14 hours

PR merged embedded-graphics/embedded-graphics

Multiline text

Thank you for helping out with embedded-graphics development! Please:

  • [ ] Check that you've added passing tests and documentation
  • [ ] Add a CHANGELOG.md entry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public API
  • [ ] Run rustfmt on the project
  • [ ] Run just build (Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.

PR description

This PR changes the way multiline text is handled. By moving the multiline code from MonoTextStyle to Text the multiline support can be shared by all text renderers.

I decided to remove TextStylePixels to make the refactor easier. We can add pixel iterators later, if we decide that they are necessary.

The removal of the pixel iterators made it possible to optimize Drawable and the benches are now 10%-30% faster. The drawing code now also uses fill_contiguous if both text_color and background_color are set, which could lead to even greater improvements in drawing performance for drivers without a framebuffer.

+350 -322

0 comment

16 changed files

rfuest

pr closed time in 14 hours

issue commentmvirkkunen/usb-device

Difficulty writing descriptors of unknown size

Figured I'd ping this

Any thoughts or feelings on it or the PR?

electroCutie

comment created time in 15 hours

PR opened jonas-schievink/rubble

Use public API in example GATT services

@jonas-schievink A follow-up from #162 so that others copying the example gatt services will have an easier time.

+39 -39

0 comment

1 changed file

pr created time in 17 hours

issue commentjonas-schievink/rubble

Writeable attributes & attribute permissions

Thanks. That sounds good to me!

If it seems relatively complete, maybe the only thing left was to actually test it, and submit the PR :sweat_smile:

daboross

comment created time in a day

issue commentjonas-schievink/rubble

Writeable attributes & attribute permissions

Sure, I'd be happy to do some work on this if I can find the time. Honestly, I'm not sure what more beyond your WIP would need to be added either (maybe just messing around with it to see usability), but I'll see what I can do.

Hope everything's ok with you!

daboross

comment created time in a day

Pull request review commentjamwaffles/event-sauce

[WIP] Synchronization

 impl<D> UpdateEventBuilder<D> where     D: EventData, {+    /// Get EventData+    pub fn get_payload(&self) -> &D {+        &self.payload

Or should we make it outright pub?

mareq

comment created time in a day

Pull request review commentjamwaffles/event-sauce

[WIP] Synchronization

 where     /// place of `EDC`, describing the conflict otherwise.     ///     /// This function will be called during [`UpdateEntityBuilder::try_update`](trait.UpdateEntityBuilder.html#method.try_update).-    fn conflicts_with(self, applied_event: Event<EDA>) -> Result<Self, ConflictData<EDA, Self>>;+    fn conflicts_with(&self, applied_event: Event<EDA>) -> Result<(), ConflictData<EDA, Self>>;

It was a nice idealistic goal... :/

mareq

comment created time in a day

Pull request review commentjamwaffles/event-sauce

[WIP] Synchronization

 where     /// place of `EDC`, describing the conflict otherwise.     ///     /// This function will be called during [`UpdateEntityBuilder::try_update`](trait.UpdateEntityBuilder.html#method.try_update).-    fn conflicts_with(self, applied_event: Event<EDA>) -> Result<Self, ConflictData<EDA, Self>>;

It was a nice idealistic goal... :/

mareq

comment created time in a day

Pull request review commentjamwaffles/event-sauce

[WIP] Synchronization

 where     } } +/// A wrapper trait around [`AggregateUpdate`] to handle event-sauce integration boilerplate+pub trait UpdateSyncEntityBuilder<ED, EDA>: UpdateEntityBuilder<ED>+where+    ED: ConflictCheck<EDA>,+    EDA: EventData,+{+    /// Update the entity with an event+    fn try_sync_update<B, I>(self, event_builder: B, applied_events: I) -> Result<StorageBuilder<Self, ED>, Self::Error>+    where+        B: Into<UpdateEventBuilder<ED>> + Entity,+        I: std::iter::Iterator<Item=Event<EDA>>,+    {+        let event_builder = event_builder.into();++        let event_data = event_builder.get_payload();+        for ae in applied_events {+           if let Err(conflict_event_data) = event_data.conflicts_with(ae) {+               let conflict_event_builder = conflict_event_data.into_builder();+               return self.try_update(conflict_event_builder);

XXX: This will find only the first conflicting events, but there potentially may be many more of them, which we ignore (and will process one by one, only as they are resolved?).

mareq

comment created time in a day

Pull request review commentembedded-graphics/embedded-graphics

Multiline text

 where     S: TextStyle<Color = C>, {     fn bounding_box(&self) -> Rectangle {-        self.style.bounding_box(&self.primitive)+        let mut position = self.primitive.position;++        let mut min_max: Option<(Point, Point)> = None;++        for line in self.primitive.text.lines() {+            let (bounding_box, position_delta) = self.style.bounding_box(line, position);++            if let Some(bottom_right) = bounding_box.bottom_right() {+                if let Some((min, max)) = &mut min_max {+                    min.x = min.x.min(bounding_box.top_left.x);

I wanted to keep it as generic as possible. And I think this will be required if we add horizontal alignment support, even without RTL.

rfuest

comment created time in a day

Pull request review commentembedded-graphics/embedded-graphics

Multiline text

 where     S: TextStyle<Color = C>, {     fn bounding_box(&self) -> Rectangle {-        self.style.bounding_box(&self.primitive)+        let mut position = self.primitive.position;++        let mut min_max: Option<(Point, Point)> = None;++        for line in self.primitive.text.lines() {+            let (bounding_box, position_delta) = self.style.bounding_box(line, position);++            if let Some(bottom_right) = bounding_box.bottom_right() {+                if let Some((min, max)) = &mut min_max {+                    min.x = min.x.min(bounding_box.top_left.x);

Preparing for RTL and bottom-to-top text? :) I would assume min == position otherwise, is there something I don't see?

rfuest

comment created time in a day

Pull request review commentembedded-graphics/embedded-graphics

Multiline text

 pub trait TextStyle {     /// Color type.     type Color: PixelColor; -    /// Render a text object using this style.-    fn render_text<D>(&self, text: &Text<'_>, target: &mut D) -> Result<(), D::Error>+    /// Renders a single line of text using this style.+    ///+    /// Returns the offset from the current position to the start of the next line.+    fn render_text<D>(+        &self,+        text: &str,+        position: Point,+        target: &mut D,+    ) -> Result<Point, D::Error>     where         D: DrawTarget<Color = Self::Color>; -    /// Returns the bounding box of a text object rendered using this style.-    fn bounding_box(&self, text: &Text<'_>) -> Rectangle;-}--/// Pixels iterator.-pub trait TextStylePixels<'a>: TextStyle {-    /// Iterator type.-    type Iter: Iterator<Item = Pixel<Self::Color>> + 'a;--    /// Returns an iterator over the drawn pixels.-    fn pixels(&self, text: &Text<'a>) -> Self::Iter;+    /// Returns the bounding box of a single line of text rendered using this style.+    fn bounding_box(&self, text: &str, position: Point) -> (Rectangle, Point);

Should we perhaps name this first_line_bounding_box or something like that to be more specific?

I've renamed it to line_bounding_box.

I'm also not sure what the Point being returned does, so explaining that would help me and others.

This might change in future PR and I've only added a TODO to remember to document this later.

Presumably an impl should only test the first line of any given text?

It will only be called with single line strings.

rfuest

comment created time in a day

Pull request review commentembedded-graphics/embedded-graphics

Multiline text

 where {     type Color = C; -    fn render_text<D>(&self, text: &Text<'_>, target: &mut D) -> Result<(), D::Error>+    fn render_text<D>(+        &self,+        text: &str,+        mut position: Point,+        target: &mut D,+    ) -> Result<Point, D::Error>     where         D: DrawTarget<Color = Self::Color>,     {-        target.draw_iter(MonoPixels::new(text, *self))+        let mut first = true;++        for c in text.chars() {+            if first {+                first = false;+            } else if F::CHARACTER_SPACING > 0 {+                // File space between characters if background color is set.

:grimacing: Another stupid typo, I shouldn't write comments at the moment.

rfuest

comment created time in a day

Pull request review commentembedded-graphics/embedded-graphics

Multiline text

 pub trait TextStyle {     /// Color type.     type Color: PixelColor; -    /// Render a text object using this style.-    fn render_text<D>(&self, text: &Text<'_>, target: &mut D) -> Result<(), D::Error>+    /// Renders a single line of text using this style.+    ///+    /// Returns the offset from the current position to the start of the next line.

There will be some changes to the trait in future PR to add additional formatting options, like horizontal and vertical alignment.

  • For the first line, what's the starting position?

It only renders a single line. The meaning of position will change in the future, so I decided not to docment it right now.

  • For subsequent lines, isn't the position just position + Point::new(0, <line_y_height>)?

Yes, it should. The method returns the offset, because Text doesn't known the line height.

  • Does the position within a line matter? E.g. should it be the top left corner of the line, the baseline, etc?

This will be added later.

After writing the other comment, should this be renamed to render_first_line

It's used for all lines, so render_first_line wouldn't be a good name. But I'll rename it to render_line.

rfuest

comment created time in a day

issue commentembedded-graphics/embedded-graphics

Finish crate split

#509 removes the TextStylePixels trait and replaces the Text arguments in the TextStyle methods, so that Text can stay in embedded-graphics.

rfuest

comment created time in a day

PR opened embedded-graphics/embedded-graphics

Multiline text

Thank you for helping out with embedded-graphics development! Please:

  • [ ] Check that you've added passing tests and documentation
  • [ ] Add a CHANGELOG.md entry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public API
  • [ ] Run rustfmt on the project
  • [ ] Run just build (Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.

PR description

This PR changes the way multiline text is handled. By moving the multiline code from MonoTextStyle to Text the multiline support can be shared by all text renderers.

I decided to remove TextStylePixels to make the refactor easier. We can add pixel iterators later, if we decide that they are necessary.

The removal of the pixel iterators made it possible to optimize Drawable and the benches are now 10%-30% faster. The drawing code now also uses fill_contiguous if both text_color and background_color are set, which could lead to even greater improvements in drawing performance for drivers without a framebuffer.

+345 -322

0 comment

15 changed files

pr created time in a day

issue commentstm32-rs/stm32f1xx-hal

Examples overflowing flash

Yea, for large projects you'll almost always want to run in release mode, we should probably add a note about that to the example

fmauNeko

comment created time in a day

pull request commentjamwaffles/ssd1306

Clarify usage of display size

@jamwaffles sorry for the noise, CI told me I'm a dummy.

bugadani

comment created time in a day

more