Rx unique byte to turn on specific LED patterns

Have Uno on way, chomping at bit for some knowledge!

Would like to receive a unique byte (ex. 11000000) that controls a preset of outputs(for leds, or relays.)
For example, 11000000 would turn on 3 of 4 available leds. I would like to program this to EEPROM. Different bytes would have different patterns of leds etc. with up to 128 "patches"
So every time the serial input rx 11000000, those same leds would come on etc.
Every time the input saw a different byte, a different pre programmed pattern would show.

Obviously a total noob, I apologize. Ive worked through some tuts, but am not grasping it fast enough. Thanks for any and all help!

Andrew

edit:sorry all, put my first post in wrong section. very good and fast moderation here! thanks

A good way to learn, it to use an example and try modifying the example.

This is very simple. Use to value for the light intensity of the led.
You can ignore the 'processing' part.

This is where it happens:

if (Serial.available()) {
    // read the most recent byte (which will be from 0 to 255):
    brightness = Serial.read();
    // set the brightness of the LED:
    analogWrite(ledPin, brightness);

This one reads a string from the serial, and uses a multicolor led

I think you want three things: EEPROM and Serial communication and Leds.
You can try them one by one, an after that try to combine them.

If you have only 4 LEDs then there are only 16 LED patterns that can be displayed (see below)
You need to decide what LEDs particular characters will display.

OOOO
OOOX
OOXO
OOXX
OXOO
OXOX
OXXO
OXXX
XOOO
XOOX
XOXO
XOXX
XXOO
XXOX
XXXO
XXXX

Look at the bitread function. You can arbitrarily assign a bit of the byte to one of your LEDs. If the bit is 1, turn on the associated LED; otherwise, turn it off. No need to store any patterns in EEPROM.

If the number of LEDs you're controlling is eight or less, you could just control them directly by associating each bit in the incoming data byte with a single LED. That removes the need to do any mapping or lookup from the incoming data byte to the LED states - the incoming data gives you the state directly. Then it's just a matter of testing whether there is serial data available, reading the incoming serial byte, using a for loop to process each bit in the byte, using bitRead() to extract the bit value from the byte and digitalWrite to write that bit value to the corresponding LED output pin. If you hold your LED pin numbers in an array and use the bit number as the array index, the whole thing would only need half a dozen lines of code.

Thanks so much for the ideas! Stellar!

I've redefined my end project to be:

  • a unit that can receive bytes 0-100
  • each byte to control a unique set pattern of digital out puts(say..6 leds on, 3 off, 1 relay on, 2 relays off) ]
  • patterns to be programed by end user be stored in eeprom, and recalled when same byte is sent

Using the input byte and pulling out the the bits for a 8x control is awesome, thanks! However, I think I'd like to go full monty and not be limited by 8.

So, here is the end unit in a few sentences:

Normal mode: Mcu receives byte 0-99(or whatever) and recalls memory for which leds or relays were previously user programmed.
Write mode: Mcu recieves byte 0-99. User picks which leds and or relays he/she wants on off(mom buttons etc.), user pushes a "store/program" button, sends that to memory.
Essentially this creates "patches" stored in memory that can be recalled.
Want that model train drawbridge to go up and that xmas tree to start spinning? Send Patch number 15, which is a preset byte. You previously stored the drawbridge to go up and tree spin in write mode.

Any more input would be great! I cant wait to get into it!

Thanks again. Karma to you all!

Sounds pretty labour-intensive for the poor old end user. Where do these one-byte commands come from?

PeterH:
Sounds pretty labour-intensive for the poor old end user. Where do these one-byte commands come from?

Hi Peter,

The bytes coming in will be miidi program change messages.

avrsinewave:
The bytes coming in will be miidi program change messages.

Oh, OK. I assume that defining the supported commands would be a one-time activity and you aren't too concerned about how much effort it takes.

That being the case, it would be reasonable IMO to store the mapping (from the MIDI input byte to the output states) in EEPROM. If I were you then rather than using input buttons etc to perform the programming, it would be easier to just provide a command line that let you type the byte value and the corresponding output states in via the serial monitor or whatever other serial client you wanted. It would be quite simple to implement a sketch that let you type in 'SET 55 01001010' for example to define the output states corresponding to input value (decimal) 55. If you implement this approach there is no reason to limit the number of output states to eight, and if you think there is any likelihood that you will want to support more than eight outputs I'd start now by holding the output states as a 16-bit or 32-bit int.

PeterH:

avrsinewave:
The bytes coming in will be miidi program change messages.

Oh, OK. I assume that defining the supported commands would be a one-time activity and you aren't too concerned about how much effort it takes.

That being the case, it would be reasonable IMO to store the mapping (from the MIDI input byte to the output states) in EEPROM. If I were you then rather than using input buttons etc to perform the programming, it would be easier to just provide a command line that let you type the byte value and the corresponding output states in via the serial monitor or whatever other serial client you wanted. It would be quite simple to implement a sketch that let you type in 'SET 55 01001010' for example to define the output states corresponding to input value (decimal) 55. If you implement this approach there is no reason to limit the number of output states to eight, and if you think there is any likelihood that you will want to support more than eight outputs I'd start now by holding the output states as a 16-bit or 32-bit int.

Hi Peter,

Thanks for that! I think it the idea is starting to form . I'll try to start looking at how to code this through examples and tutorials.