Roadmap

[simonbyrne]

LED

• [ ] Rotation: create views into rotated/flipped matrices
• [ ] Message scrolling
  • Need an 8 pixel font

Sensors

Kind of complex:

• The Python library uses https://github.com/RPi-Distro/RTIMULib
• some C code here https://github.com/davebm1/c-sense-hat

Should make use of Rotations.jl:

• gyroscope would return a RodriguesVec
  • should add a Base.^(::RodriguesVec, ::Real) method to make it easy.

[Ellipse0934]

I want to start working on the pixel font. How exactly will we store it ? Each character needs to be mapped to an 8x8 RGB565 Matrix. We'll easily get 100+ characters. What is the correct way to store data like this in a package ? Each mapping will look like JULIA_LOGO in src/led_extra.jl. I can do the entire printable ASCII set by 10th.

[aviks]

I'd say we should store the images as FixedPointNumber arrays. And then store these images into a Dict.

[simonbyrne]

If there is no antialiasing, it might be easiest to store each character as a BitMatrix, so the whole thing would be a Dict{Char, BitMatrix}.

[Ellipse0934]

Right now if we have a 8x8 matrix of RGB which we want to display on the SenseHat led screen we must transpose it to view correctly. Why should a user be responsible for doing this every time ? Instead how about using led_display(x::Array{RGB565}(8,8)) as the main display function which will transpose x then display it.

[simonbyrne]

Yeah, I agree it's not ideal. Unfortunately it's due to how the buffer is laid out in memory. But this is a problem for all images.

We could have led_matrix() return a PermuteDimsArray?

[Ellipse0934]

We could have led_matrix() return a PermuteDimsArray?

I don't understand what you mean by that.

[simonbyrne]

e.g. it would give what PermuteDimsArray(led_matrix(), (2,1)) currently does.

[Ellipse0934]

Yes, that makes sense. Or we could hide the implementation details altogether and simply provide two functions: setDisplay() and getDisplay(). The simpler the library is the better due to the intended audience. I'll see what Python does tomorrow. In the meantime I would really appreciate if you could take the time to review PR #4.

[simonbyrne]

I personally really, really like being able to just assign pixels and have it change immediately.

[Ellipse0934]

PermutedDimsArray makes perfect sense. However I would still like set_pixel() and set_display() functions. That way let these functions manage the flipping and rotation views. Let the led_matrix() stay for advanced users. led_matrix() = PermutedDimsArray(Mmap.mmap(....), (2,1)) seems to work fine.

[simonbyrne]

One idea I was thinking of was to allow optional arguments to led_matrix specifying the rotation/flipping. The downside is this would be type unstable, but with the constant propagation in 0.7 hopefully this won't be an issue.

[Ellipse0934]

We can do that. Has there been any progress with the IMU sensor?

[simonbyrne]

No

[simonbyrne]

I should perhaps expand on that.

If you are interested in reading from the IMU, then perhaps the easiest option is to wrap https://github.com/RPi-Distro/RTIMULib (which I think is what Python uses).

Alternatively, you should be able to use the smbus interface, but this would require writing your own calibration and state tracker (RTIMULib uses a Kalman filter).

[Ellipse0934]

Along with the PermutedDimsArray we need a rotation/flipping. How can one create a rotated reference for a 2-D array ? Essentially PermutedDimsArray but for rotr90. If A = [1 2; 3 4] then B = [3 1; 4 2], A and B need to be linked memory wise. The reason for this is that everyone has their own sense-hat orientation. I would bet that most people use it upside down as it is away from the hdmi connector that way.

[simonbyrne]

You can flip by creating a view with a reverse range, e.g.

@view LED[8:-1:1, :]

If I have my group theory right, I think all we need is flipping and permute dims, as we can get rotations from those: e.g. rotate 90 left would be:

LEDPC = @view PermutedDimsArray(LED, (2,1))[8:-1:1, :]

[simonbyrne]

It would be even better if we could use ImageAxes.jl somehow, as that has this sort of handling built in (though not this particular use case...)

[Ellipse0934]

I only added orientation in PR #8. I didn't see any usefulness in flipping. Should I add it ?