Depending on the device in hand and one’s temperament, bringing up a new part can be a frolic through the verdant fields of discovery or an endless slog through the grey marshes of defeat. One of the reasons we find ourselves sticking with tried and true parts we know well is that interminable process of configuration. Once a new display controller is mostly working, writing convenience functions to make it easier to use can be very satisfying, but the very first thing is figuring out how to make it do anything at all. Friend of Hackaday [Dan Hienzsch] put together a post describing how to use a particular LED controller which serves as a nice walkthrough of figuring out the right bitmath to make things work, and includes a neat trick or two.
The bulk of the post is dedicated to describing the way [Dan] went about putting together his libraries for a 7-segment display demo board he makes. At its heart the board uses the IS31FL3728 matrix driver from ISSI. We love these ISSI LED controllers because they give you many channels of control for relatively low cost, but even with their relative simplicity you still need to do some bit twiddling to light the diodes you need. [Dan]’s post talks about some strategies for making this easier like preconfigured lookup tables with convenient offsets and masking bits to control RGB LEDs.
There’s one more trick which we think is the hidden star of the show; a spreadsheet which calculates register values based on “GUI” input! Computing the bit math required to control a display can be an exercise in frustration, especially if the logical display doesn’t fit conveniently in the physical register map of the controller. A spreadsheet like this may not be particularly sexy but it gets the job done; exactly the kind of hack we’re huge fans of here. We’ve mirrored the spreadsheet so you can peek at the formulas inside, and the original Excel document is available on his blog.
I use switch , case for things like 7 seg chr bit maps.
#Define is useful some times. It’s a preprocessor directive and that is why it starts with a # and has no terminating ; or data type.
A Define is passed to the compiler stage as a string.
For example say you want to specify colors as a three element array of byte values.
Function void setpixel(pixel, redvalue, greenvalue, bluevalue)
You can do this
#define RED 0xff,0x00,0x00
Setpixel(20, RED);
thanks
switch() has extra overheads. Sadly AVR compiler is a bit brain dead to access data in program memory and require a bit of work from programmers.
The normal way for other uC is to store the whole thing in an const array and use index to access the char. Array of struct for more complex stuff. Unified memory space and/or better *embedded* compilers an handle this in a nicer way without loading the whole thing in RAM or requiring extra statement to access data in code space.
I don’t know about the Arduino IDE but I do know about AVR (atmega) asm.
If the switch variable is within the bit width of a register and immediate mode addressing then switch case optimizes well.
So if you type the switch variable as byte and then get it to a register then here is your asm.
Atmega has an immediate addressing mode compare CPI and a not equal relative branch BRNE
With your switch variable as type byte in a register, in this case register R3 arbitrarily ..
CPI R3, 0x00
BRNE not0
Code for case 00
:not0
CPI R3, 0x01
BRNE not1
Code for case 01
:not1
Etc.
I love AVRs. I do need to put arrays in the flash for RAM room. I just write a little function to read the selected struct from flash into RAM. Not a big deal.
I also create arrays of bit fields for stuff where the bits are fiddly. Do the work once, document it, then pick up the bits as needed and write them to the device/register as a set.
The problem is that now that define has global scope and ready to create problems along the road. Its better to avoid define where possible. Much easier to do with c++ but also possible in c.
It also messes your hardware debugging as the source level #define symbols aren’t passed down the tool chain.
I had a hard time figuring the compile error the other day because I forgot to remove a place holder #define symbol which happened to have same name as a local variable.
Don’t the style gurus say you should have paragraph long overly descriptive variable names so that you never get them confused..
int Fudge_factor_put_in_by_Scott_when_totals_weren’t_coming_out_right_don’t_rely_on_being_int_might_change_to_double_later_or_completely_deprecate_when_we_fix_the_math
Scott would never do that.
Should at least try to make that out of tongue twisters. :P It would be fun for over the phone debugging sessions.
Define has no scope at all within the C source as it’s a preprocessor directive.
It will however cause problems if there is a clash with variable name space.
For this reason define label names should always use a different naming convention.
Where variables are all lower case or camel case, defines should always be all uppercase.
For compilers that have case sensitivity a define label should be preceded with one or more underscores.
… Don’t have case sensitivity …
I would love to see a board like this as a generic user input output I2C device.
Something with a 1602 display.
A two LED or 3 LED status indicator, perhaps even as the LCD backlight.
With either or
A rotary quadrature encoder switch, along with three buttons , ESC. User1, User2
Or
Switches. Up, down. Left, right, enter in the middle, ESC, user1, user2
And a beeper
Like this? (ebay item #182708600971)
That one is parallel not I2C, the LCD is graphic and lacks buttons.
I don’t building something similar to this for larger projects.
I have more smaller projects that have the same needs and could use a generic I2C 1602 with buttons.
But now for the hard questions. Do you put a hanger on the 7 digit? How about a tail on the 9? I would ask if you put a hat on the 6, but obviously you do.