Skip to content
Closed
Show file tree
Hide file tree
Changes from 9 commits
Commits
Show all changes
31 commits
Select commit Hold shift + click to select a range
7d80cce
Start work on on Inky Impression
lawik Oct 10, 2021
8ee2dda
More work on setup and update for Inky Impression
lawik Oct 27, 2021
6e11741
Add all of the Impression code but not working, added cs0 but that wo…
lawik Oct 27, 2021
c56c9be
Kinda working!
axelson Nov 8, 2021
e415e0e
Kind of like a flag
axelson Nov 8, 2021
fc37b1f
Cleaning
axelson Nov 9, 2021
cc82eda
Clean up cs pin calls
axelson Nov 9, 2021
99d2cd5
clean
axelson Nov 9, 2021
7a636df
Merge pull request #42 from axelson/jax/inky-impression
lawik Nov 9, 2021
753d5a8
Fix log typo
Jul 3, 2022
3f46d9a
Adds comments to byte commands defined for Impression in hal
Jul 3, 2022
3142798
Fix typo in comment
Jul 3, 2022
ae2e48f
Update mix deps for development on jasonmj
Jul 3, 2022
07f75e6
Update display definition for impression
Jul 3, 2022
63cdb4f
Add handling for impression in packed_width and packed_height
Jul 3, 2022
13793cd
Fix usage of state in log function
Jul 3, 2022
853021b
Add set_dimensions to do_update for impression
Jul 3, 2022
46a3b40
Replace buffer generation with PixelUtil.pixels_to_bits
Jul 3, 2022
9dfa181
Add a color_map for the impression
Jul 3, 2022
5bfb57f
Add notes about WIP toward impression support
Jul 3, 2022
4689834
Reverting dev changes to mix.exs
Jul 3, 2022
3bcf4f1
Cleaning up unused code
Jul 8, 2022
590c25f
Adding bit_size option to PixelUtil.pixels_to_bits
Jul 8, 2022
d5bca11
Merge pull request #46 from jasonmj/impression
lawik Jul 11, 2022
9abc79f
Cleans up code for PR
Jul 12, 2022
80bdee8
Adds painter test
Jul 12, 2022
f86d1b8
Support circuits_gpio 1.0
axelson Jul 13, 2022
b30be19
Merge pull request #47 from axelson/impression
Jul 13, 2022
a68e31a
Add support for buttons on Inky Impression
Jul 23, 2022
40cda84
Support sending button messages to a process by registered atom name
Aug 1, 2022
6a6cd42
Merge pull request #48 from jasonmj/impression
lawik Aug 1, 2022
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 43 additions & 2 deletions lib/display/display.ex
Original file line number Diff line number Diff line change
Expand Up @@ -4,18 +4,31 @@ defmodule Inky.Display do
"""

alias Inky.LookupTables

@type t() :: %__MODULE__{}

@enforce_keys [:type, :width, :height, :packed_dimensions, :rotation, :accent, :luts]

Copy link
Copy Markdown
Collaborator

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.

Copy link
Copy Markdown
Collaborator

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.

Copy link
Copy Markdown
Collaborator

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?

Copy link
Copy Markdown
Collaborator

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.

@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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some observations...

(2*255 + 88) = 600-2 = 598
(1*255 + 192) = 488-1 = 447

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)

Expand Down Expand Up @@ -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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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.

Comment thread
jasonmj marked this conversation as resolved.
Outdated
end
2 changes: 1 addition & 1 deletion lib/hal/hal.ex
Original file line number Diff line number Diff line change
Expand Up @@ -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}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not cool, hehe... why leak any() from here?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, reverting in cleanup.

end
319 changes: 319 additions & 0 deletions lib/hal/impression/rpihal.ex
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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably be named clear

}

@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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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)}")

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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
Comment thread
jasonmj marked this conversation as resolved.
])

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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, use Bitwise and the ||| operator.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went for pipes instead of |||. Seems to accommodate the comments nicely.


# 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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is why we don't copy-paste stuff 😅

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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
Loading