-
Notifications
You must be signed in to change notification settings - Fork 12
Start work on on Inky Impression #37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 9 commits
7d80cce
8ee2dda
6e11741
c56c9be
e415e0e
fc37b1f
cc82eda
99d2cd5
7a636df
753d5a8
3f46d9a
3142798
ae2e48f
07f75e6
63cdb4f
13793cd
853021b
46a3b40
9dfa181
5bfb57f
4689834
3bcf4f1
590c25f
d5bca11
9abc79f
80bdee8
f86d1b8
b30be19
a68e31a
40cda84
6a6cd42
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,18 +4,31 @@ defmodule Inky.Display do | |
| """ | ||
|
|
||
| alias Inky.LookupTables | ||
|
|
||
| @type t() :: %__MODULE__{} | ||
|
|
||
| @enforce_keys [:type, :width, :height, :packed_dimensions, :rotation, :accent, :luts] | ||
| @enforce_keys [:type, :width, :height, :rotation, :accent] | ||
| defstruct type: nil, | ||
| width: 0, | ||
| height: 0, | ||
| packed_dimensions: %{}, | ||
| packed_resolution: nil, | ||
| rotation: 0, | ||
| accent: :black, | ||
| luts: <<>> | ||
|
|
||
| @spec spec_for(:impression) :: Inky.Display.t() | ||
| def spec_for(type = :impression) do | ||
| %__MODULE__{ | ||
| type: type, | ||
| width: 600, | ||
| height: 448, | ||
| packed_resolution: <<2, 88, 1, 192>>, # I used the struct.pack in Python to generate this | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Some observations...
How do these numbers relate to whatever input you put into python? Also, if we're not going to do this properly in elixir, we should at the very least have the actual code here, not just a mention of "it was done in python". The dimensions for the Inky were kept in a struct, why not do the same thing here and convert it to a binary when it's required? |
||
| rotation: 0, | ||
| accent: nil, | ||
| } | ||
| end | ||
|
|
||
| @spec spec_for(:phat | :what, :black | :red | :yellow) :: Inky.Display.t() | ||
| def spec_for(type, accent \\ :black) | ||
|
|
||
|
|
@@ -83,4 +96,32 @@ defmodule Inky.Display do | |
| # Little endian, unsigned short | ||
| <<rows::unsigned-little-integer-16>> | ||
| end | ||
|
|
||
| # colorsets from pimoroni library | ||
| # https://github.com/pimoroni/inky/blob/54684464b2f35bfd52208cdfb922c09685644181/library/inky/inky_uc8159.py#L26-L46 | ||
| defp get_colorset(:desaturated) do | ||
| [ | ||
| [0, 0, 0], | ||
| [255, 255, 255], | ||
| [0, 255, 0], | ||
| [0, 0, 255], | ||
| [255, 0, 0], | ||
| [255, 255, 0], | ||
| [255, 140, 0], | ||
| [255, 255, 255] | ||
| ] | ||
| end | ||
|
|
||
| defp get_colorset(:saturated) do | ||
| [ | ||
| [57, 48, 57], | ||
| [255, 255, 255], | ||
| [58, 91, 70], | ||
| [61, 59, 94], | ||
| [156, 72, 75], | ||
| [208, 190, 71], | ||
| [177, 106, 73], | ||
| [255, 255, 255] | ||
| ] | ||
| end | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Feels like things are getting muddled in display.ex... we might want to consider how things could be split up. Not sure if it should be by amount of colours or "base type" of display. The what/phat share things, but I'm seeing quite a few things that aren't really compatible with the impression.
jasonmj marked this conversation as resolved.
Outdated
|
||
| end | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,5 +12,5 @@ defmodule Inky.HAL do | |
| policy :: :await | :once, | ||
| state :: Inky.IOCommands.State.t() | ||
| ) :: | ||
| :ok | {:error, :device_busy} | ||
| io_state() | :ok | {:error, :device_busy} | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not cool, hehe... why leak
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good call, reverting in cleanup. |
||
| end | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,319 @@ | ||
| defmodule Inky.Impression.RpiHAL do | ||
| @default_io_mod Inky.Impression.RpiIO | ||
|
|
||
| @moduledoc """ | ||
| An `Inky.HAL` implementation responsible for sending commands to the Inky | ||
| screen. It delegates to whatever IO module its user provides at init, but | ||
| defaults to #{inspect(@default_io_mod)} | ||
| """ | ||
|
|
||
| @behaviour Inky.HAL | ||
|
|
||
| @colors %{ | ||
| :black => 0, | ||
| :white => 1, | ||
| :green => 2, | ||
| :blue => 3, | ||
| :red => 4, | ||
| :yellow => 5, | ||
| :orange => 6, | ||
| # Not a color, but is used to clear the display | ||
| :clean => 7 | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should probably be named |
||
| } | ||
|
|
||
| @psr 0x00 | ||
| @pwr 0x01 | ||
| @pof 0x02 | ||
| @pfs 0x03 | ||
| @pon 0x04 | ||
| @btst 0x06 | ||
| @dslp 0x07 | ||
| @dtm1 0x10 | ||
| @dsp 0x11 | ||
| @drf 0x12 | ||
| @ipc 0x13 | ||
| @pll 0x30 | ||
| @tsc 0x40 | ||
| @tse 0x41 | ||
| @tws 0x42 | ||
| @tsr 0x43 | ||
| @cdi 0x50 | ||
| @lpd 0x51 | ||
| @tcon 0x60 | ||
| @tres 0x61 | ||
| @dam 0x65 | ||
| @rev 0x70 | ||
| @flg 0x71 | ||
| @amv 0x80 | ||
| @vv 0x81 | ||
| @vdcs 0x82 | ||
| @pws 0xE3 | ||
| @tsset 0xE5 | ||
|
|
||
| require Logger | ||
|
|
||
| alias Inky.Display | ||
| alias Inky.HAL | ||
| alias Inky.PixelUtil | ||
|
|
||
| defmodule State do | ||
| @moduledoc false | ||
|
|
||
| @state_fields [:display, :io_mod, :io_state, :setup?] | ||
|
|
||
| @enforce_keys @state_fields | ||
| defstruct @state_fields | ||
| end | ||
|
|
||
| # | ||
| # API | ||
| # | ||
|
|
||
| @impl HAL | ||
| def init(args) do | ||
| display = args[:display] || raise(ArgumentError, message: ":display missing in args") | ||
| io_mod = args[:io_mod] || @default_io_mod | ||
|
|
||
| io_args = args[:io_args] || [] | ||
| io_args = if :gpio_mod in io_args, do: io_args, else: [gpio_mod: Circuits.GPIO] ++ io_args | ||
| io_args = if :spi_mod in io_args, do: io_args, else: [spi_mod: Circuits.SPI] ++ io_args | ||
|
|
||
| %State{ | ||
| display: display, | ||
| io_mod: io_mod, | ||
| io_state: io_mod.init(io_args), | ||
| setup?: false | ||
| } | ||
| end | ||
|
|
||
| @impl HAL | ||
| def handle_update(pixels, border, push_policy, state = %State{}) do | ||
| display = %Display{width: w, height: h, rotation: r} = state.display | ||
| Logger.info("display: #{inspect(display)}") | ||
| IO.puts("Generating buffer...") | ||
|
|
||
| buffer = | ||
| for y <- 0..(h - 1), x <- 0..(w - 1), into: <<>> do | ||
| cond do | ||
| x > 150 && y > 200 -> <<@colors[:orange]>> | ||
| x > 100 -> <<@colors[:blue]>> | ||
| y > 100 -> <<@colors[:green]>> | ||
| true -> <<rem(y, @colors[:orange] + 1)>> | ||
| end | ||
| # color = floor(0 / w * 7) | ||
| end | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what. is this a dev-demo function? |
||
|
|
||
| log("Generated buffer of size: #{byte_size(buffer)}") | ||
| log("buffer: #{inspect(buffer)}") | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. might not want to do this... |
||
|
|
||
| log("Resetting device") | ||
| reset(state) | ||
|
|
||
| case pre_update(state, push_policy) do | ||
| :cont -> do_update(state, display, border, buffer) | ||
| :halt -> {:error, :device_busy} | ||
| end | ||
| end | ||
|
|
||
| # | ||
| # procedures | ||
| # | ||
|
|
||
| defp pre_update(state, :await) do | ||
| await_device(state) | ||
| :cont | ||
| end | ||
|
|
||
| defp pre_update(state, :once) do | ||
| case read_busy(state) do | ||
| 1 -> :cont | ||
| 0 -> :halt | ||
| end | ||
| end | ||
|
|
||
| defp log(msg) when is_binary(msg) do | ||
| IO.puts(msg) | ||
| Logger.info(msg) | ||
| end | ||
|
|
||
| defp log(_state, msg) when is_binary(msg) do | ||
| IO.puts(msg) | ||
| Logger.info(msg) | ||
| state | ||
| end | ||
|
|
||
| defp do_update(state, display, border, buffer) do | ||
| IO.inspect(buffer, label: "buffer (rpihal.ex:138)") | ||
| Logger.info("border: #{inspect(border)}") | ||
| border = :red | ||
|
|
||
| state | ||
| |> log("setting resolution") | ||
| |> set_resolution(display.packed_resolution) | ||
| |> log("setting panel") | ||
| |> set_panel() | ||
| |> log("setting power") | ||
| |> set_power() | ||
| |> log("setting pll") | ||
| |> set_pll_clock_frequency() | ||
| |> log("set tse register") | ||
| |> set_tse_register() | ||
| |> log("set vcom") | ||
| |> set_vcom_data_interval_setting(border) | ||
| |> log("set gate") | ||
| |> set_gate_source_non_overlap_period() | ||
| |> log("disable external flash") | ||
| |> disable_external_flash() | ||
| |> log("set pws") | ||
| |> set_pws_whatever_that_means() | ||
| |> log("power off seq") | ||
| |> power_off_sequence() | ||
| |> log("push pixels") | ||
| |> push_pixel_buffer(buffer) | ||
| |> log("await") | ||
| |> await_device() | ||
| |> log("pon") | ||
| |> pon() | ||
| |> log("await") | ||
| |> await_device() | ||
| |> log("drf") | ||
| |> drf() | ||
| |> log("await") | ||
| |> await_device() | ||
| |> log("pof") | ||
| |> pof() | ||
| |> log("await") | ||
| |> await_device() | ||
| |> log("done") | ||
|
|
||
| {:ok, %State{state | setup?: true}} | ||
| end | ||
|
|
||
| # | ||
| # "routines" and serial commands | ||
| # | ||
|
|
||
| defp reset(state) do | ||
| state | ||
| |> set_reset(0) | ||
| |> sleep(100) | ||
| |> set_reset(1) | ||
| |> sleep(100) | ||
| end | ||
|
|
||
| defp soft_reset(state), do: write_command(state, 0x12) | ||
|
|
||
| # >HH struct.pack, so big-endian, unsigned-sort * 2 | ||
| defp set_resolution(state, packed_resolution), | ||
| do: write_command(state, @tres, packed_resolution) | ||
|
|
||
| # Panel Setting | ||
| # 0b11000000 = Resolution select, 0b00 = 640x480, our panel is 0b11 = 600x448 | ||
| # 0b00100000 = LUT selection, 0 = ext flash, 1 = registers, we use ext flash | ||
| # 0b00010000 = Ignore | ||
| # 0b00001000 = Gate scan direction, 0 = down, 1 = up (default) | ||
| # 0b00000100 = Source shift direction, 0 = left, 1 = right (default) | ||
| # 0b00000010 = DC-DC converter, 0 = off, 1 = on | ||
| # 0b00000001 = Soft reset, 0 = Reset, 1 = Normal (Default) | ||
| defp set_panel(state), do: write_command(state, @psr, [0b11101111, 0x08]) | ||
|
|
||
| defp set_power(state), | ||
| do: | ||
| write_command(state, @pwr, [ | ||
| Bitwise.bor( | ||
| Bitwise.bor( | ||
| Bitwise.bor( | ||
| # ??? - not documented in UC8159 datasheet | ||
| Bitwise.<<<(0x06, 3), | ||
| # SOURCE_INTERNAL_DC_DC | ||
| Bitwise.<<<(0x01, 2) | ||
| ), | ||
| # GATE_INTERNAL_DC_DC | ||
| Bitwise.<<<(0x01, 1) | ||
| ), | ||
| # LV_SOURCE_INTERNAL_DC_DC | ||
| 0x01 | ||
| ), | ||
| # VGx_20V | ||
| 0x00, | ||
| # UC8159_7C | ||
| 0x23, | ||
| # UC8159_7C | ||
| 0x23 | ||
|
jasonmj marked this conversation as resolved.
|
||
| ]) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hahaha, omg, what is this :D. This should probably be cleaned up with parens,
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wait a minute... if the shifting/bor hackery is done to build a complex binary by glueing together values, we can do that in a much simpler binary expression.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went for pipes instead of |
||
|
|
||
| # Set the PLL clock frequency to 50Hz | ||
| # 0b11000000 = Ignore | ||
| # 0b00111000 = M | ||
| # 0b00000111 = N | ||
| # PLL = 2MHz * (M / N) | ||
| # PLL = 2MHz * (7 / 4) | ||
| # PLL = 2,800,000 ??? | ||
| defp set_pll_clock_frequency(state), do: write_command(state, 0x3C) | ||
|
|
||
| defp set_tse_register(state), do: write_command(state, 0x00) | ||
|
|
||
| defp set_vcom_data_interval_setting(state, border), | ||
| do: write_command(state, @cdi, [Bitwise.bor(Bitwise.<<<(@colors[border], 5), 0x17)]) | ||
|
|
||
| defp set_gate_source_non_overlap_period(state), do: write_command(state, @tcon, 0x22) | ||
| defp disable_external_flash(state), do: write_command(state, @dam, 0x00) | ||
| defp set_pws_whatever_that_means(state), do: write_command(state, @pws, 0xAA) | ||
| defp power_off_sequence(state), do: write_command(state, @pfs, 0x00) | ||
| defp push_pixel_buffer(state, buffer), do: write_command(state, @dtm1, buffer) | ||
| defp pon(state), do: write_command(state, @pon) | ||
| defp drf(state), do: write_command(state, @drf) | ||
| defp pof(state), do: write_command(state, @pof) | ||
|
|
||
| # | ||
| # waiting | ||
| # | ||
|
|
||
| defp await_device(state) do | ||
| case read_busy(state) do | ||
| 0 -> | ||
| sleep(state, 10) | ||
| await_device(state) | ||
|
|
||
| 1 -> | ||
| state | ||
| end | ||
| end | ||
|
|
||
| # | ||
| # pipe-able wrappers | ||
| # | ||
|
|
||
| defp sleep(state, sleep_time) do | ||
| io_call(state, :handle_sleep, [sleep_time]) | ||
| state | ||
| end | ||
|
|
||
| defp set_reset(state, value) do | ||
| io_call(state, :handle_reset, [value]) | ||
| state | ||
| end | ||
|
|
||
| defp read_busy(state) do | ||
| io_call(state, :handle_read_busy) | ||
| end | ||
|
|
||
| defp write_command(state, command) do | ||
| io_call(state, :handle_command, [command]) | ||
| state | ||
| end | ||
|
|
||
| defp write_command(state, command, data) do | ||
| io_call(state, :handle_command, [command, data]) | ||
| state | ||
| end | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is why we don't copy-paste stuff 😅
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are all being used. Is there an outstanding issue here? |
||
|
|
||
| # | ||
| # Behaviour dispatching | ||
| # | ||
|
|
||
| # Dispatch to the IO callback module that's held in state, using the previously obtained state | ||
| defp io_call(state, op, args \\ []) do | ||
| apply(state.io_mod, op, [state.io_state | args]) | ||
| end | ||
| end | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these are required for one display but not the other, we should consider refactoring things so that we don't force re-usability where it is not required/meaningful (maybe that's exactly what you did here? :D). "False generalisation" only makes things unclear since you don't knew when/if something is required/missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reverted this change too, since these keys can peacefully coexist in the struct the defines the impression display. We're not using packed dimensions because it's redundant/unnecessary, but if someone wants to use them in the future, it'll be possible.
As for luts, it's not used at all for the impression. Not sure we need to define a separate struct+key enforcement just for that though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good food for thought, though... if the devices are diverting, perhaps our configurations should, too.
One way of dealing with it would be to have a protocol common for all types, for the things that are common to all displays and then have the specific drivers check if it is a value of the correct underlying type at runtime during init. But that might be a bit more than what you signed up for at this point and a bit of over-engineering before we have several displays where the fit is off... thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like it might be a worthwhile refactor to open a separate issue for.