Orientation wrong on 8x32 module
Closed this issue · 8 comments
Hi,
I've got the same problem as is being described over on this arduino forum
This diagram from there neatly illustrates the problem.
The module looks like this.
I guess I could break it apart and re-orientate it but that seems a little drastic.
Is there a simple workaround for this?
If not I'm happy to try and put together a pull request if you could give me some pointers.
By coincidence, I just bought 3 of these 8x8x4 modules two days ago, so should have something to play with in a few weeks.
I think the difference is that some of the LED matrices are common-row anode, others are common-row cathode, and this affects how they are wired up, and consequently the scroll direction. I highly doubt you would be able to break it apart and re-orientate it.
The good news is that we can do that orientation fix in the code... the library has undergone a significant rewrite recently, and there was a block-level rotate8x8.py module that did this previously, which perhaps should be re-introduced (see the code here, and a related issue).
There are probably two different ways to tackle this:
- Looking at https://github.com/rm-hull/luma.led_matrix/blob/master/luma/led_matrix/device.py#L83-L94, you see how it varies y at line 87, maybe swap x and y, so that x varies over
self._wand y is fixed. - Use the rotate8x8.py module (or something similar in Pillow) to pre-process the image to re-orient every 8x8 pixel block - there is already a
preprocess(image)method which could/should be overridden.
[I think I prefer the 2nd option personally]
Either way, the class would be constructed with something like:
serial = spi(port=0, device=0)
device = max7219(serial, cascaded=4, common_row_cathode=True)If common_row_cathode is the wrong name then lets rename it to common_row_anode, but it would be optional and default to False.
Happy for you to either submit a PR, or add you as a collaborator and we can then work on a shared branch.
References
I've added some code in commit d1b65d7 - if you could test it on the block-orientation branch and let me know how it goes
On reflection, not sure calling the parameter common_row_cathode is the best thing to do, on the basis that (a) it might be wrong, (b) someone with 'the other type' of device might not immediately make the connection with the argument name and the behavior they are seeing.
Open to suggestions for a better name, throwing these out there:
- vertical_align
- block_realign
- fix_alignment
- fix_phase_alignment
Any better names?
cc: @thijstriemstra
I think I prefer block_orientation_horizontal=True/False. I know whether it is horizontal or vertical is a bit arbitrary but it's more clear to me what the transformation is.
I was just settling in to have a look at making the change and updating the tests and I see you've done it all :).
Still learned a bit about virtualenv and pip (I don't have a huge amount of experience in Python) so that's a plus.
Anything you want me to do shout.
I will be quite slow though :)
Lets go with block_orientation='vertical' to fix the behaviour you describe in the opening issue description, and this defaults to block_orientation='horizontal' for current behaviour.
Nice. Thanks for your work on this. Can MAX7219 FC-16 1x4 or 8 x32 be referenced horizontal versus vertical?
I'll add some opt-args to the max7219 example for this - expect the documentation to be updated to reflect the flags required when this gets merged into master
can i get the solution to this problem?
can i get the solution to this problem?
Look at the documentation