Skip to content

Conversation

@JonasFocke01
Copy link

Hello,

this PR addresses issue #4 by implementing a print_chars() function.
This uses your techniques. Please let me know, if i did something wrong.
I have tested this on multiple display-pico combinations with great success.
As the display is sort of limited in its capabilities, some letters look a bit wrong, but i tried my best to follow this picture (with some assumptions involved).
The function increases the footprint of this library, by adding a mapping-helper-function that stores all A-z chars if used.

Cheers!

@igelbox
Copy link
Owner

igelbox commented Dec 7, 2023

Well, I kinda intentionally avoided adding any alphabets here coz the device doesn't natively support letters so displaying any is an approximation/imagination.
Also, I do believe it's not that complicated to implement any additional methods like print_chars as part of additional trait for the pub struct TM1637. So I believe (but not sure though) you could implement your own library that would extend this one with the additional trait with the print_chars method.

@igelbox
Copy link
Owner

igelbox commented Dec 7, 2023

I do believe it's not that complicated

It definitely is =)

diff --git a/examples/main.rs b/examples/main.rs
index 94e0064..bb01ca8 100644
--- a/examples/main.rs
+++ b/examples/main.rs
@@ -5,8 +5,10 @@
 extern crate panic_halt;
 
 extern crate stm32f103xx_hal as hal;
+extern crate embedded_hal as ehal;
 
 use hal::delay::Delay;
+use ehal::digital::v2::{InputPin, OutputPin};
 use hal::prelude::*;
 use hal::stm32f103xx::Peripherals;
 use embedded_hal::blocking::delay::DelayUs;
@@ -14,13 +16,37 @@ use embedded_hal::blocking::delay::DelayUs;
 use cortex_m_rt::entry;
 
 extern crate tm1637;
-use tm1637::{ TM1637 };
+use tm1637::{ TM1637, Error };
 
 struct NoDelay {}
 impl DelayUs<u16> for NoDelay {
     fn delay_us(&mut self, us: u16) {}
 }
 
+trait PrintChars<E> {
+    fn print_chars(&mut self, address: u8, chars: &[char])->Result<(), Error<E>>;
+}
+
+// I wish Rust has some way to extend generic traits without explicit bounds re-definition
+// so all the types may be infered from those are used in TM1637
+impl<'a, CLK, DIO, D, E> PrintChars<E> for TM1637<'a, CLK, DIO, D>
+where
+    CLK: OutputPin<Error = E>,
+    DIO: InputPin<Error = E> + OutputPin<Error = E>,
+    D: DelayUs<u16>,
+{
+    fn print_chars(&mut self, address: u8, chars: &[char])->Result<(), Error<E>> {
+        self.print_raw_iter(address, chars.iter().map(|b| char_to_raw(*b)))
+    }
+}
+
+fn char_to_raw(c: char) -> u8 {
+    match c {
+        'a' | 'A' => 0x77,
+        _ => 0x00,
+    }
+}
+
 #[entry]
 fn main() -> ! {
     let dp = Peripherals::take().unwrap();
@@ -49,6 +75,8 @@ fn main() -> ! {
             tm.print_raw(3, &[i]);
 
             tm.set_brightness(i >> 5);
+
+            tm.print_chars(0, &['A', 'a']);
         }
     }
 }

it compiles but I have no device to check how it works.
So it seems the approach with a separate library is kinda (generic-type mess hurts) viable.

@igelbox
Copy link
Owner

igelbox commented Dec 7, 2023

It would be great if Rust allow write just:

impl for TM1637 /*please, do it for all TM1637 specialisations*/ {
    fn print_chars(&mut self, address: u8, chars: &[char]) /*please, infer the result type for me =)*/ {
        self.print_raw_iter(address, chars.iter().map(|b| char_to_raw(*b)))
    }
}

just to decouple this function implementation from the library implementation details.
But I have no experience/idea to make it work this way.

@JonasFocke01
Copy link
Author

But that would require the user to write this trait out with all its generic types.
We could hide this print_chars() behind a feature flag and do it for them, so we could sidestep a whole trait.
And/or create an example, how one could utilize the print_raw_iter() function, to print custom chars, so he would not have to figure that out.

I introduced a chars feature, that is NOT enabled by default.
Your opinions?

@JonasFocke01
Copy link
Author

I also think about adding a hex feature to be in line with my prev. comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants