7-segment display MAX72XX SPI Hardware

Agge

First of all thanks for a very solid firmware. I have build a CoreXY printer and the goal is to print ABS and nylon with good results. I have the printer connected to a computer overtime so no need for a SD card but would like to have some easy feedback on what's going on with the printer. The common LCD UI is not the best way to get the basic feedback from a distance. 

My approach is to use 7-segment displays to show just the different temperatures to start with. There are nice 8 digit 7-segment SPI displays on ebay and by using just two of them I would like to show temp for dual extruders, heat bed and the heated cabinet. 

One big goal is to not mess around to much with the firmware. As I see it there are two ways to do this.

1. Write a new UI in the firmware

2. Just sniff the coms and use a second microprocessor to do the 7-segment part

After taking a walk in the firmware code I would not go for writing new UI. Even if a lot of the code is there. It is nested around a lot and for me to make it decent compatible with all of the different configurations would take a while for even a basic codewriter. I'm not :-)

That leaves me with sniffing the TX/RX and by doing that I would gain a higher compatibility for different firmwares and protocols.

If I can add a second microprocessor that sniffs TX/RX it easy to implement some RGB leds for feedback on different states on the printer later on

Is this approach the best one ?

And if so  I need help with to start with is a good entry point. Repetier uses a bin protocol. Where to get the more deep info on that ?

// Agge

Repetier

Ok, ui needs lcd displays with 20x4 chars ideally so you can not use that for such a reduced solution.

So as you already found out a custom solution is required. Best entry point is the vent system in 0.92 version. That lets you separate the code from firmware development. I think I would use one of the timer events to update the display. 8 digits can not cause much traffik and you omit lcd so I'd implement it inside firmware event timer and update it directly from there with SPI. You have direct access to all variables making the programming moch more trivial then if you send data to a second baord.

Agge

Thanks for a fast reply, I did a serial "sniffer" some time ago so got some basic code already done. If I look at the gcode.cpp and the "same" in Reptier-Host it would be easy to just sniff it and get the right data with ease without messing with the SPI on the mega.

And you are right about UI. I'm just slightly loosing some hair just looking in to that part. User input and the User output is wraped around like a snake pit.

To drive the 7-segments at 1 Hz I don't even need to use hardware SPI just 3 GPIO's 

But it would be nice to give something back to the community and implement it to the firmware as an option to the common LCD. Where to start looking into that event timer ?

 

Is the status reply to Repetier-Host ascii or bin ?

Is the status invoked by by a "M105" 

Repetier

For event system check in github/work092 branch the SampleEvenSystems. The felix due uses a timer event so it is easy to understand and adapt. These files simple get copied into the firmware folder. A event is simply a empty macro that gets called at different events. If you replace the macros with calls to your function it is like they were embedded.

Replies are always ascii regardless if the request was ascii (which also works) or binary. Firmware detects from first byte if it is a ascii or bin request (bin has highest bit in first byte set).

Agge

Thanks alot.. Now I have something to start with