Questions about Library Usage
AlexLandherr opened this issue · 13 comments
- Is this the correct imports for any project of my own using the compatible display in another separate project directory?:
// Libraries
#include <bcm2835.h>
#include <stdio.h>
#include <MAX7219_7SEG_RPI.hpp>
- Can I still daisy-chain several of these displays together like with the Python library? If so i want to try the idea floated in this issue.
I know some characters will have to be replaced and remove the " UTC" bit of the resulting string.
-
Stdio.h is just for "printf" statements so its optional , the other two yes. You will also need to make sure that the linker can see them, so you have to include LDFLAGS in your build process, If you use Makefile as a build process see LDFLAGS in the Makefile in examples folder.
-
There is no support for cascaded displays in library as I only had one display and did not
want to release untested code, See "notes" in readme. If you have multiple displays I could write some code and you could test it.
Stdio.h is just for "printf" statements so its optional , the other two yes. You will also need to make sure that the linker can see them, so you have to include LDFLAGS in your build process, If you use Makefile as a build process see LDFLAGS in the Makefile in examples folder.
There is no support for cascaded displays in library as I only had one display and did not
want to release untested code, See "notes" in readme. If you have multiple displays I could write some code and you could test it.
Thanks for offering to add it. I would very much like that addition. And I can test it on the setup shown below.
I have two such displays daisy-chained together presently connected to a RPi Zero W. There it is connected to what I think is the HW SPI pins on the Pi which is what Python uses.
Hi
I have new version of software 1.2 with cascaded display support (UNTESTED
There is basic example and a clock example for cascaded two displays.
List No | Example file name | Description | SPI type |
---|---|---|---|
1 | src/CLOCK_DEMO/main.cpp | Clock demo , Shows use of cascaded displays | hardware |
2 | src/CASCADE_DEMO/main.cpp | simple Demo showing use of cascaded displays | hardware |
Can you try them out and see if they work?
Hi
I have new version of software 1.2 with cascaded display support (UNTESTED
There is basic example and a clock example for cascaded two displays.
| List No | Example file name | Description | SPI type |
| ------ | ------ | ------ | ----- |
| 1 | src/CLOCK_DEMO/main.cpp | Clock demo , Shows use of cascaded displays | hardware |
| 2 | src/CASCADE_DEMO/main.cpp | simple Demo showing use of cascaded displays | hardware |
Can you try them out and see if they work?
I will try to do it on 2023-05-27 if my schedule permits.
UPDATE 2023-05-26: I tried it now and the library builds and installs correctly. I built and ran the example "CASCADE_DEMO" and got this on the display:
And this terminal output over my SSH connection:
pi@raspberrypi:~/MAX7219_7SEG_RPI-1.2/examples $ make run
sudo ./bin/test
Test Begin :: MAX7219_7SEG_RPI
Display 1
Display 2
Display 1 again
Clear the displays
Test End
I think this looks mostly correct when comparing with the source code for the particular example. What do you think?
Hi
No
The 2nd display should have "Display2" on it. I seem to be missing a digit.
Can you try the first example the src/CLOCK_DEMO/main.cpp example?
Also you can adjust brightness if you want with SetBrightness() , pass 0x00 to 0x0F to it . 0x0F being max. default brightness is 0x08.
I'll try today.
Tried it and it sort of works; the hour-minute-second part is fine. The top part with year.month.day "glitches" or blinks on the start of each second very briefly.
It doesn't seem to be because of a poor physical connection since I checked that and tried again.
If you want I can try to film it and send a short clip over if GitHub allows that.
Hi
It maybe a timing or SPI bus speed issue.
Things to try if you have time.
- Try running at Software SPI this runs much slower than HW SPI and uses different code.
- Try running the HW SPI at different speeds faster and slower in the example it is set to 5000 KHz(SPI_SCLK_FREQ ), You could set it to 1000 and 10000 and see what happens.
- Removing the delay from example or putting it in different positions , A small delay between writes to displays may be needed to give chance for Chip select line to go low again.
- You could just update the date on start-up and midnight for you application as a workaround.
Can you show me your python code , Do you know what SPI speed you are running at there?
If this does not work I will just get a another display.
regards
I'll try next Friday or Saturday. Good ideas to test though.
Hi
It maybe a timing or SPI bus speed issue.
Things to try if you have time.
- Try running at Software SPI this runs much slower than HW SPI and uses different code.
- Try running the HW SPI at different speeds faster and slower in the example it is set to 5000 KHz(SPI_SCLK_FREQ ), You could set it to 1000 and 10000 and see what happens.
- Removing the delay from example or putting it in different positions , A small delay between writes to displays may be needed to give chance for Chip select line to go low again.
- You could just update the date on start-up and midnight for you application as a workaround.
Can you show me your python code , Do you know what SPI speed you are running at there?
If this does not work I will just get a another display.
regards
- How do I run
at Software SPI
with the clock example? - I tried those two values with little effect.
- Tried removing it by commenting it out and placing a delay between the two different write operations.
- I might try this later; I want to check out the bus speed thing together. From what I can tell the SPI bus speed is fixed. I don't know how to change it myself via the OS.
Here's my Python code:
from luma.led_matrix.device import max7219
from luma.core.interface.serial import spi, noop
from luma.core.virtual import sevensegment
from datetime import datetime, timezone
from time import sleep
serial = spi(port=0, device=0, gpio=noop())
device = max7219(serial, cascaded=2)
seg = sevensegment(device)
#Sets the contrast (range is 0-255).
seg.device.contrast(32)
try:
while True:
now = datetime.now(timezone.utc).strftime("%Y.%m.%d%H-%M-%S")
seg.text = now
sleep(1)
except:
print()
I'm not sure how to determine the exact SPI bus speed I'm using here unfortunately.
How do I run at Software SPI with the clock example?
The example src/TESTS/main.cpp is set up for software SPI.
Software SPI uses a different constructor
// GPIO I/O pins on the raspberry pi ,pick on any I/O you want.
#define CLK 25 // clock GPIO, connected to clock line of module
#define CS 24 // Chip Select GPIO, connected to CS line of module
#define DIN 23 // data in GPIO, connected to DIN line of module
// Constructor object
MAX7219_SS_RPI myMAX(CLK, CS ,DIN);
The Python Library you are using defaults to "SPI bus speed, defaults to 8MHz."
I think.
https://luma-core.readthedocs.io/en/latest/interface.html#luma.core.interface.serial.spi
How do I run at Software SPI with the clock example?
The example src/TESTS/main.cpp is set up for software SPI.
Software SPI uses a different constructor
// GPIO I/O pins on the raspberry pi ,pick on any I/O you want. #define CLK 25 // clock GPIO, connected to clock line of module #define CS 24 // Chip Select GPIO, connected to CS line of module #define DIN 23 // data in GPIO, connected to DIN line of module // Constructor object MAX7219_SS_RPI myMAX(CLK, CS ,DIN);
The Python Library you are using defaults to "SPI bus speed, defaults to 8MHz." I think.
https://luma-core.readthedocs.io/en/latest/interface.html#luma.core.interface.serial.spi
So replace the setup code in src/CLOCK_DEMO/main.cpp
with the example you showed me above?