• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

Which is right for my project - CFA735, CFA835, something else?

rootwyrm

New member
So I've run into a rather.. difficult problem. I'm looking to put LCDs on my new servers, which are pretty significantly complex even before you get into the software on them.

Problem one: I need to drive four LEDs. Well, okay, that's easy enough, right? Not so much so. These LEDs need to be driven from 1.95/3.3V two-wire LED outputs. So that's four pairs, 8 wires. Plus another pair for fan control alarm. Plus a 3.3V/GND for fault status. Plus there's a switch to emulate (not ATX - NMI!) So that's 14 pins. Whoops!
Problem two: that doesn't get me the host data. The host data needs to get fed from USB as it sits, and gets pretty fancy. It's not just IP address and such - it's planned to cycle through a variety of data and status, and regularly update. Oh, and it isn't running Windows. So no, can't just use CC2.
Oh, and I also can't just use CFA-FBSCAB. All the fans are PWM.

I was planning to feed the GPIO into a Teensy 2.0++ and then feed data to the Crystalfontz. The LEDs for the curious are network interfaces plus the fan alarm LED and general fault, so it needs to be pretty fast response. (And yes, they're link+act feed.) For fan status (on/off) it would flash the LEDs in red and flash a 'FAN ERROR' message (hopefully) and for general fault status it would strobe red/orange and a 'HARDWARE FAULT' message.
The host data feed wouldn't touch the LEDs, but would constantly update the LCD to prevent burn-in and also deal with the keypad. The hosts themselves run - you guessed it - ESXi. But host data gets very complex since it also pulls data out of guests and guests-within-guests (jails and lxc.) So yes, things like scrolling which VMs are active on which, what the guest is, etcetera. Eventually the plan would be to set up a keypad interactive menu system on the Crystalfontz so I can do vMotion and jail failovers without having to deal with the awful web UI. At least initially about all I'm expecting to have working with the keypad is 'pause scrolling' and 'manually scroll through hosts (up/down) and data (left/right).'

But it's not clear to me if this is even possible. For example, could I even stop the host data from being displayed when I want to show the fault messages? Secondly, what would be the best module and best way to interface from the Teensy? Or is there a similar option better suited to microcontroller duties? There's no way to feed everything from one point because of having to mix simple hardware source with complex software source, with both working very quickly. Has anyone done something similar and can share their experiences?

Thanks in advance! (Oh and yes I am the RootWyrm. And yes this is BabyDragon related.) :cool:
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

CF Tech

Administrator
Thank you for your interest in our products.

You have quite a list of desires there !

I think you could do everything you want with the 735/835 hardware and a few helpers, but the firmware would have to be customized--perhaps a lot !

The processor on the 735/835 hardware is the fairly beefy STM32F103RC:
http://www.st.com/en/microcontrollers/stm32f103rc.html
The STM32F103xC, STM32F103xD and STM32F103xE performance line family incorporates the high-performance ARM®Cortex®-M3 32-bit RISC core operating at a 72 MHz frequency, high-speed embedded memories (Flash memory up to 512 Kbytes and SRAM up to 64 Kbytes), and an extensive range of enhanced I/Os and peripherals connected to two APB buses. All devices offer three 12-bit ADCs, four general-purpose 16-bit timers plus two PWM timers, as well as standard and advanced communication interfaces: up to two I2Cs, three SPIs, two I2Ss, one SDIO, five USARTs, an USB and a CAN.
We do have a basic firmware shell that you can load onto the 735/835 hardware and modify it to your heart's content:
https://forum.crystalfontz.com/forumdisplay.php/59-CFA-10052-Firmware-Development

The processor is the fairly beefy STM32F103RC:
http://www.st.com/en/microcontrollers/stm32f103rc.html

Reading the LEDs reliably will take an analog/ADC input or a comparator driving a digital input.

One option would be to use a a serial ADC:
http://www.digikey.com/product-detail/en/texas-instruments/TLC541IN/296-1850-5-ND/277495
to read your 8 LED lines, fan, and fault.

Your customized 735/835 firmware could poll the 10 lines plenty fast enough with that ADC and you could then update the 735/835 LEDs to mirror them, or print the status to the LCD.

One benefit is that you would have complete control of both ends of the firmware, so you could make your customized 735/835 firmware have commands that very nicely support what you want to do from the EXSi host.

LCDs do not burn in so that is not a worry.
 

rootwyrm

New member
Thank you for your interest in our products.

You have quite a list of desires there !
I know, I know. Building the ultimate home lab controller recipe to go with the BabyDragon book (coming hopefully soon) so people can really show off. Leaves a lot of T's to cross and I's to dot. :(

I think you could do everything you want with the 735/835 hardware and a few helpers, but the firmware would have to be customized--perhaps a lot !

The processor on the 735/835 hardware is the fairly beefy STM32F103RC:
http://www.st.com/en/microcontrollers/stm32f103rc.html

We do have a basic firmware shell that you can load onto the 735/835 hardware and modify it to your heart's content:
https://forum.crystalfontz.com/forumdisplay.php/59-CFA-10052-Firmware-Development
Hmm, and that's where things take a turn for the bizarre as I'm not really Cortex literate. My "brilliant" plan was to just have the Teensy smack things out of the way when warranted via standard channels, to simplify (and hopefully eliminate) needing to do major work in the Cortex.

Reading the LEDs reliably will take an analog/ADC input or a comparator driving a digital input.
That part, I think I have half figured out. There are enough pins on the Teensy to handle all the inputs (plus extras), so wire those up to the Teensy's analog and drive output digital within fixed range. Basically streamline the everloving crap out of the comparator to only consider "is it X or Y, ok send message." That's where the tricky bit comes in, formatting it into the right protocol and syntactical sugar for the Cortex to like.

One option would be to use a a serial ADC:
http://www.digikey.com/product-detail/en/texas-instruments/TLC541IN/296-1850-5-ND/277495
to read your 8 LED lines, fan, and fault.
And that's where Teensy comes in. It has an ADC available. It can also be rigged for serial output. Or I2C output. Which what I was thinking sounded best, but that may be way off?

Your customized 735/835 firmware could poll the 10 lines plenty fast enough with that ADC and you could then update the 735/835 LEDs to mirror them, or print the status to the LCD.

One benefit is that you would have complete control of both ends of the firmware, so you could make your customized 735/835 firmware have commands that very nicely support what you want to do from the EXSi host.
Yeah, and that's where I'm getting a little tangled up. How am I getting those 10 lines into the 735/835 stack when I only have the 5 GPIO pins? I don't see a way other than serial, which seems like it could slow it down? Especially as 2 pair signalling gigabit or 10GbE traffic and hot-hot so I'd have to do some sort of low-high there best case. That's why I was figuring to land all the simple processing on the Teensy, optimize it there, and send 'native' tongue from the Teensy to the 735/835.

The other problem is that the keypad has to interact back to the OS regardless. It has to tell it to execute the tie-in commands to display current data, execute vmotion, validate it, etceterra. So that part has to be direct to host, or spend way too much time writing to the 735/835 any time the button's pressed. (I'm really obsessing over responsive a bit.) Also because it might send the wrong VM if it isn't. So, yeah, kinda important that. :)

LCDs do not burn in so that is not a worry.
Shhh, don't tell the customers that.. ;)
(C'mon, we all know scrolling makes displays extra awesome.)
 
Top