I think my problem is with the coding and not the wire library, but I am using I2C between an Arduino Uno (master) and Adafruit Macropad (slave). I don't think the master code is particularly relevant, but included at the bottom of this post. The slaves code minus the loop. Let me know if I need to include the loop, but this is already a long post. My question is, Why does the void I2C_Received() function not run the code all the way up to the while loop in the function? The while loop is designed to exit upon the user pressing the enter button which is digitalRead(12). However, the code does not get past Serial.println(bytes) which is above the while loop in the function with several lines of code inbetween.
//THIS IS THE SLAVE
#include <Adafruit_SH110X.h>
#include <Adafruit_NeoPixel.h>
#include <RotaryEncoder.h>
#include <Wire.h>
// Create the neopixel strip with the built in definitions NUM_NEOPIXEL and PIN_NEOPIXEL
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUM_NEOPIXEL, PIN_NEOPIXEL, NEO_GRB + NEO_KHZ800);
// Create the OLED display
Adafruit_SH1106G display = Adafruit_SH1106G(128, 64, &SPI1, OLED_DC, OLED_RST, OLED_CS);
// Create the rotary encoder
RotaryEncoder encoder(PIN_ROTA, PIN_ROTB, RotaryEncoder::LatchMode::FOUR3);
void checkPosition() { encoder.tick(); } // just call tick() to check the state.
// our encoder position state
int encoder_pos = 0;
// Global Variable Boolean
bool superuser = false;
const uint8_t superuser_addr = 33;
bool user = false;
const uint8_t user_addr = 66;
//char string_last_received[] = "";
char string_last_received[21]; //the OLED display can only show 21 full characters. I2C is limited to 32.
char data_to_return[21];
bool i2c_found[128] = {false};
void setup() {
Serial.begin(115200);
//while (!Serial) { delay(10); } // wait till serial port is opened
delay(100); // RP2040 delay is not a bad idea
Serial.println("Adafruit Macropad with RP2040");
// set all mechanical keys to inputs
for (uint8_t i=0; i<=12; i++) {
pinMode(i, INPUT_PULLUP);
}
// Start OLED
display.begin(0, true); // we dont use the i2c address but we will reset!
display.display();
display.setTextSize(1);
display.setTextWrap(false);
display.setTextColor(SH110X_WHITE, SH110X_BLACK); // white text, black background
display.setCursor(0,0);
// Enable speaker
pinMode(PIN_SPEAKER_ENABLE, OUTPUT);
digitalWrite(PIN_SPEAKER_ENABLE, HIGH);
// Play some tones
pinMode(PIN_SPEAKER, OUTPUT);
digitalWrite(PIN_SPEAKER, LOW);
delay(100);
if (!digitalRead(1) && !digitalRead(10) && digitalRead(2) && digitalRead(4) && digitalRead(7) && digitalRead(11)) { // switch 1 and 10 pressed simultaneously enters superuser mode. No fat fingers of adjacent keys.
superuser = true;
Wire.begin(superuser_addr);
display.clearDisplay();
display.drawBitmap(0,0,logo_superuser,128,64,1);
display.display();
delay(1000);
for (byte i=0;i < (sizeof(score_superuser) / (sizeof(score_superuser[0]))); i = i + 2){
tone(PIN_SPEAKER,score_superuser[i],score_superuser[i+1]);
delay(score_superuser[i+1]);
}
}
else{ //user mode
Wire.begin(user_addr);
display.clearDisplay();
display.drawBitmap(0,0,logo_user,128,64,1);
display.display();
delay(1000);
for (byte i=0;i < (sizeof(score_user) / (sizeof(score_user[0]))); i = i + 2){
tone(PIN_SPEAKER,score_user[i],score_user[i+1]);
delay(score_user[i+1]);
}
}
// start pixels!
pixels.begin();
pixels.setBrightness(255);
pixels.show(); // Initialize all pixels to 'off'
// set rotary encoder inputs and interrupts
pinMode(PIN_ROTA, INPUT_PULLUP);
pinMode(PIN_ROTB, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(PIN_ROTA), checkPosition, CHANGE);
attachInterrupt(digitalPinToInterrupt(PIN_ROTB), checkPosition, CHANGE);
Wire.onReceive(I2C_Received);
}
void I2C_Received(int bytes){
//clears prior string
for (int i = 0; i<21; i++){
string_last_received[i] = '\0';
}
Serial.print("Verifying String Clear: ");
Serial.println(string_last_received);
Serial.print("Bytes Received: ");
Serial.println(bytes);
for (int i = 0; i<bytes; i++) {
string_last_received[i] = Wire.read();
}
Serial.print("Received from Master: ");
Serial.println(string_last_received);
display.setCursor(0, 16); //this was moved from the void loop for testing
display.print(string_last_received); //this was moved from the void loop for testing
display.display();
//data_to_return="Hi Back ";
while(digitalRead(12)){ //if this while loop is on, the above code appears to stop at Serial.println(bytes)
Serial.println("in the while loop waiting for enter");
delay(1000);
}
Serial.println("someone pressed enter");
//Wire.write(data_to_return);
}
void loop() {
//omitted
}
If I removed the below portion of the code, the whole void I2C_Received function runs. If I leave it in, it stops at Serial.println(bytes);
while(digitalRead(12)){ //if this while loop is on, the above code appears to stop at Serial.println(bytes)
Serial.println("in the while loop waiting for enter");
delay(1000);
}
Master code:
// THIS IS THE MASTER
// Include the required Wire library for I2C<br>
#include <Wire.h>
//Global Variable declarations
bool superuser = false;
const uint8_t superuser_addr = 33;
bool user = false;
const uint8_t user_addr = 66;
void setup() {
// Start the I2C Bus as Master
Wire.begin();
delay(100);
Wire.setClock(100000); //Normally 100,000
// Start Serial Monitor
Serial.begin(9600);
delay(100);
while (!Serial); // Leonardo: wait for Serial Monitor
delay(100);
Serial.println("***Serial Monitor Started***");
// This is looking for macropads address of 33 (superuser) or 66 (user). If timeout at 1/2 second, moves on to main code.
uint16_t i = 0;
uint16_t delay_timer = 100;
while (!superuser && !user && i<500) {
delay(delay_timer);
i=i+delay_timer;
Wire.beginTransmission(superuser_addr);
byte error1 = Wire.endTransmission();
if (error1 == 0) {
superuser = true;
user = true;
Serial.println("Superuser declared");
}
Wire.beginTransmission(user_addr);
byte error2 = Wire.endTransmission();
if (error2 == 0) {
user = true;
Serial.println("User declared");
}
}
Serial.println("While loop exit");
//This Executes user programming
if(user){
Serial.println("Performing all user related functions:");
Serial.println("What is your Station Number?: ");
Wire.beginTransmission(user_addr);
Wire.write("[0]Station#(1-32)?:"); //Phrase must be 32 characters or less for .write. OLED can only support 21 char on one line.
Wire.endTransmission();
}
}
void loop() {
}
The macropads display can hold 21 characters per line. I2C doesnt like anything above 32. So the answer to your question is that the master will send no more than 21 characters as a string to the slave.
Doh! Its there and I scrubbed it out. Editing original to fix and copying the full here. Please disreguard the bitmaps and audio files as they are not related to the problem:
I'm not quite shure if you understand what Wire.onReceive() does. It only registers I2C_Received, but doesn't call it. It is called later if your slave receives data from the master. And it is called within an ISR . So it should be short, and there should be no Serial prints in it.
[EDIT]Your function I2C_Received() can definitely not be called in an ISR. In the ISR you may only store the received bytes in a suitable array and set a flag that you have received something. The entire evaluation must take place in the loop() function when it recognizes that the flag is set.
This will mean that the neopixel strip and the OLED display will get updated every time loop() runs. This will consume a very large amount of processing time for no benefit, and may cause flickering, because most times, nothing will have changed.
This might also cause other inputs to be missed, contributing to the problems you are having.
So I recommend making your code a bit smarter about whether the led strip needs to be updated and whether the OLED needs to be updated.
Im not sure that I understood what Wire.onReceive() does either! Thanks. How do you recommend monitoring that it is making its way through the code? Blink the LED? Is there a problem with a long ISR? This routine only runs when the macropad is connected for purposes of ultimately programming EEPROM. Once the Master is programmed, it will be rebooted and not detect the macropad and then move on to performing the void loop.
Ultimately I want to send a question, in this case What station are you? ("[0]Station#(1-32)?") and then use the keyboard to return typed in data. This would be an unsigned short byte. Is onReceive not the right strategy to implement?
The parent code for the slave came from the adafruit macropad example and is rather "flashy". I have been dumbing it down. The macropad slave will serve no other purpose than to program eeprom at the master and then it will be disconnected. Understand the looping may be inefficient. Perhaps the use of a change flag would allow to clear and update the display?
I think its in the Adafruit_NeoPixel.h, but my understanding of libraries is limited. I really don't need the LED lighting the keys, but I do appreciate it as confirmation of a key press.
/*!
* @file Adafruit_NeoPixel.h
*
* This is part of Adafruit's NeoPixel library for the Arduino platform,
* allowing a broad range of microcontroller boards (most AVR boards,
* many ARM devices, ESP8266 and ESP32, among others) to control Adafruit
* NeoPixels, FLORA RGB Smart Pixels and compatible devices -- WS2811,
* WS2812, WS2812B, SK6812, etc.
*
* Adafruit invests time and resources providing this open source code,
* please support Adafruit and open-source hardware by purchasing products
* from Adafruit!
*
* Written by Phil "Paint Your Dragon" Burgess for Adafruit Industries,
* with contributions by PJRC, Michael Miller and other members of the
* open source community.
*
* This file is part of the Adafruit_NeoPixel library.
*
* Adafruit_NeoPixel is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation, either version 3 of the
* License, or (at your option) any later version.
*
* Adafruit_NeoPixel is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with NeoPixel. If not, see
* <http://www.gnu.org/licenses/>.
*
*/
#ifndef ADAFRUIT_NEOPIXEL_H
#define ADAFRUIT_NEOPIXEL_H
#ifdef ARDUINO
#if (ARDUINO >= 100)
#include <Arduino.h>
#else
#include <WProgram.h>
#include <pins_arduino.h>
#endif
#ifdef USE_TINYUSB // For Serial when selecting TinyUSB
#include <Adafruit_TinyUSB.h>
#endif
#endif
#ifdef TARGET_LPC1768
#include <Arduino.h>
#endif
#if defined(ARDUINO_ARCH_RP2040)
#include <stdlib.h>
#include "hardware/pio.h"
#include "hardware/clocks.h"
#include "rp2040_pio.h"
#endif
// The order of primary colors in the NeoPixel data stream can vary among
// device types, manufacturers and even different revisions of the same
// item. The third parameter to the Adafruit_NeoPixel constructor encodes
// the per-pixel byte offsets of the red, green and blue primaries (plus
// white, if present) in the data stream -- the following #defines provide
// an easier-to-use named version for each permutation. e.g. NEO_GRB
// indicates a NeoPixel-compatible device expecting three bytes per pixel,
// with the first byte transmitted containing the green value, second
// containing red and third containing blue. The in-memory representation
// of a chain of NeoPixels is the same as the data-stream order; no
// re-ordering of bytes is required when issuing data to the chain.
// Most of these values won't exist in real-world devices, but it's done
// this way so we're ready for it (also, if using the WS2811 driver IC,
// one might have their pixels set up in any weird permutation).
// Bits 5,4 of this value are the offset (0-3) from the first byte of a
// pixel to the location of the red color byte. Bits 3,2 are the green
// offset and 1,0 are the blue offset. If it is an RGBW-type device
// (supporting a white primary in addition to R,G,B), bits 7,6 are the
// offset to the white byte...otherwise, bits 7,6 are set to the same value
// as 5,4 (red) to indicate an RGB (not RGBW) device.
// i.e. binary representation:
// 0bWWRRGGBB for RGBW devices
// 0bRRRRGGBB for RGB
// RGB NeoPixel permutations; white and red offsets are always same
// Offset: W R G B
#define NEO_RGB ((0 << 6) | (0 << 4) | (1 << 2) | (2)) ///< Transmit as R,G,B
#define NEO_RBG ((0 << 6) | (0 << 4) | (2 << 2) | (1)) ///< Transmit as R,B,G
#define NEO_GRB ((1 << 6) | (1 << 4) | (0 << 2) | (2)) ///< Transmit as G,R,B
#define NEO_GBR ((2 << 6) | (2 << 4) | (0 << 2) | (1)) ///< Transmit as G,B,R
#define NEO_BRG ((1 << 6) | (1 << 4) | (2 << 2) | (0)) ///< Transmit as B,R,G
#define NEO_BGR ((2 << 6) | (2 << 4) | (1 << 2) | (0)) ///< Transmit as B,G,R
// RGBW NeoPixel permutations; all 4 offsets are distinct
// Offset: W R G B
#define NEO_WRGB ((0 << 6) | (1 << 4) | (2 << 2) | (3)) ///< Transmit as W,R,G,B
#define NEO_WRBG ((0 << 6) | (1 << 4) | (3 << 2) | (2)) ///< Transmit as W,R,B,G
#define NEO_WGRB ((0 << 6) | (2 << 4) | (1 << 2) | (3)) ///< Transmit as W,G,R,B
#define NEO_WGBR ((0 << 6) | (3 << 4) | (1 << 2) | (2)) ///< Transmit as W,G,B,R
#define NEO_WBRG ((0 << 6) | (2 << 4) | (3 << 2) | (1)) ///< Transmit as W,B,R,G
#define NEO_WBGR ((0 << 6) | (3 << 4) | (2 << 2) | (1)) ///< Transmit as W,B,G,R
#define NEO_RWGB ((1 << 6) | (0 << 4) | (2 << 2) | (3)) ///< Transmit as R,W,G,B
#define NEO_RWBG ((1 << 6) | (0 << 4) | (3 << 2) | (2)) ///< Transmit as R,W,B,G
#define NEO_RGWB ((2 << 6) | (0 << 4) | (1 << 2) | (3)) ///< Transmit as R,G,W,B
#define NEO_RGBW ((3 << 6) | (0 << 4) | (1 << 2) | (2)) ///< Transmit as R,G,B,W
#define NEO_RBWG ((2 << 6) | (0 << 4) | (3 << 2) | (1)) ///< Transmit as R,B,W,G
#define NEO_RBGW ((3 << 6) | (0 << 4) | (2 << 2) | (1)) ///< Transmit as R,B,G,W
#define NEO_GWRB ((1 << 6) | (2 << 4) | (0 << 2) | (3)) ///< Transmit as G,W,R,B
#define NEO_GWBR ((1 << 6) | (3 << 4) | (0 << 2) | (2)) ///< Transmit as G,W,B,R
#define NEO_GRWB ((2 << 6) | (1 << 4) | (0 << 2) | (3)) ///< Transmit as G,R,W,B
#define NEO_GRBW ((3 << 6) | (1 << 4) | (0 << 2) | (2)) ///< Transmit as G,R,B,W
#define NEO_GBWR ((2 << 6) | (3 << 4) | (0 << 2) | (1)) ///< Transmit as G,B,W,R
#define NEO_GBRW ((3 << 6) | (2 << 4) | (0 << 2) | (1)) ///< Transmit as G,B,R,W
#define NEO_BWRG ((1 << 6) | (2 << 4) | (3 << 2) | (0)) ///< Transmit as B,W,R,G
#define NEO_BWGR ((1 << 6) | (3 << 4) | (2 << 2) | (0)) ///< Transmit as B,W,G,R
#define NEO_BRWG ((2 << 6) | (1 << 4) | (3 << 2) | (0)) ///< Transmit as B,R,W,G
#define NEO_BRGW ((3 << 6) | (1 << 4) | (2 << 2) | (0)) ///< Transmit as B,R,G,W
#define NEO_BGWR ((2 << 6) | (3 << 4) | (1 << 2) | (0)) ///< Transmit as B,G,W,R
#define NEO_BGRW ((3 << 6) | (2 << 4) | (1 << 2) | (0)) ///< Transmit as B,G,R,W
// Add NEO_KHZ400 to the color order value to indicate a 400 KHz device.
// All but the earliest v1 NeoPixels expect an 800 KHz data stream, this is
// the default if unspecified. Because flash space is very limited on ATtiny
// devices (e.g. Trinket, Gemma), v1 NeoPixels aren't handled by default on
// those chips, though it can be enabled by removing the ifndef/endif below,
// but code will be bigger. Conversely, can disable the NEO_KHZ400 line on
// other MCUs to remove v1 support and save a little space.
#define NEO_KHZ800 0x0000 ///< 800 KHz data transmission
#ifndef __AVR_ATtiny85__
#define NEO_KHZ400 0x0100 ///< 400 KHz data transmission
#endif
// If 400 KHz support is enabled, the third parameter to the constructor
// requires a 16-bit value (in order to select 400 vs 800 KHz speed).
// If only 800 KHz is enabled (as is default on ATtiny), an 8-bit value
// is sufficient to encode pixel color order, saving some space.
#ifdef NEO_KHZ400
typedef uint16_t neoPixelType; ///< 3rd arg to Adafruit_NeoPixel constructor
#else
typedef uint8_t neoPixelType; ///< 3rd arg to Adafruit_NeoPixel constructor
#endif
// These two tables are declared outside the Adafruit_NeoPixel class
// because some boards may require oldschool compilers that don't
// handle the C++11 constexpr keyword.
/* A PROGMEM (flash mem) table containing 8-bit unsigned sine wave (0-255).
Copy & paste this snippet into a Python REPL to regenerate:
import math
for x in range(256):
print("{:3},".format(int((math.sin(x/128.0*math.pi)+1.0)*127.5+0.5))),
if x&15 == 15: print
*/
static const uint8_t PROGMEM _NeoPixelSineTable[256] = {
128, 131, 134, 137, 140, 143, 146, 149, 152, 155, 158, 162, 165, 167, 170,
173, 176, 179, 182, 185, 188, 190, 193, 196, 198, 201, 203, 206, 208, 211,
213, 215, 218, 220, 222, 224, 226, 228, 230, 232, 234, 235, 237, 238, 240,
241, 243, 244, 245, 246, 248, 249, 250, 250, 251, 252, 253, 253, 254, 254,
254, 255, 255, 255, 255, 255, 255, 255, 254, 254, 254, 253, 253, 252, 251,
250, 250, 249, 248, 246, 245, 244, 243, 241, 240, 238, 237, 235, 234, 232,
230, 228, 226, 224, 222, 220, 218, 215, 213, 211, 208, 206, 203, 201, 198,
196, 193, 190, 188, 185, 182, 179, 176, 173, 170, 167, 165, 162, 158, 155,
152, 149, 146, 143, 140, 137, 134, 131, 128, 124, 121, 118, 115, 112, 109,
106, 103, 100, 97, 93, 90, 88, 85, 82, 79, 76, 73, 70, 67, 65,
62, 59, 57, 54, 52, 49, 47, 44, 42, 40, 37, 35, 33, 31, 29,
27, 25, 23, 21, 20, 18, 17, 15, 14, 12, 11, 10, 9, 7, 6,
5, 5, 4, 3, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0,
0, 1, 1, 1, 2, 2, 3, 4, 5, 5, 6, 7, 9, 10, 11,
12, 14, 15, 17, 18, 20, 21, 23, 25, 27, 29, 31, 33, 35, 37,
40, 42, 44, 47, 49, 52, 54, 57, 59, 62, 65, 67, 70, 73, 76,
79, 82, 85, 88, 90, 93, 97, 100, 103, 106, 109, 112, 115, 118, 121,
124};
/* Similar to above, but for an 8-bit gamma-correction table.
Copy & paste this snippet into a Python REPL to regenerate:
import math
gamma=2.6
for x in range(256):
print("{:3},".format(int(math.pow((x)/255.0,gamma)*255.0+0.5))),
if x&15 == 15: print
*/
static const uint8_t PROGMEM _NeoPixelGammaTable[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 3,
3, 3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 5, 6,
6, 6, 6, 7, 7, 7, 8, 8, 8, 9, 9, 9, 10, 10, 10,
11, 11, 11, 12, 12, 13, 13, 13, 14, 14, 15, 15, 16, 16, 17,
17, 18, 18, 19, 19, 20, 20, 21, 21, 22, 22, 23, 24, 24, 25,
25, 26, 27, 27, 28, 29, 29, 30, 31, 31, 32, 33, 34, 34, 35,
36, 37, 38, 38, 39, 40, 41, 42, 42, 43, 44, 45, 46, 47, 48,
49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
64, 65, 66, 68, 69, 70, 71, 72, 73, 75, 76, 77, 78, 80, 81,
82, 84, 85, 86, 88, 89, 90, 92, 93, 94, 96, 97, 99, 100, 102,
103, 105, 106, 108, 109, 111, 112, 114, 115, 117, 119, 120, 122, 124, 125,
127, 129, 130, 132, 134, 136, 137, 139, 141, 143, 145, 146, 148, 150, 152,
154, 156, 158, 160, 162, 164, 166, 168, 170, 172, 174, 176, 178, 180, 182,
184, 186, 188, 191, 193, 195, 197, 199, 202, 204, 206, 209, 211, 213, 215,
218, 220, 223, 225, 227, 230, 232, 235, 237, 240, 242, 245, 247, 250, 252,
255};
/* Declare external methods required by the Adafruit_NeoPixel implementation
for specific hardware/library versions
*/
#if defined(ESP32)
#if ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(5, 0, 0)
extern "C" void espInit();
#endif
#endif
/*!
@brief Class that stores state and functions for interacting with
Adafruit NeoPixels and compatible devices.
*/
class Adafruit_NeoPixel {
public:
// Constructor: number of LEDs, pin number, LED type
Adafruit_NeoPixel(uint16_t n, int16_t pin = 6,
neoPixelType type = NEO_GRB + NEO_KHZ800);
Adafruit_NeoPixel(void);
~Adafruit_NeoPixel();
void begin(void);
void show(void);
void setPin(int16_t p);
void setPixelColor(uint16_t n, uint8_t r, uint8_t g, uint8_t b);
void setPixelColor(uint16_t n, uint8_t r, uint8_t g, uint8_t b, uint8_t w);
void setPixelColor(uint16_t n, uint32_t c);
void fill(uint32_t c = 0, uint16_t first = 0, uint16_t count = 0);
void setBrightness(uint8_t);
void clear(void);
void updateLength(uint16_t n);
void updateType(neoPixelType t);
/*!
@brief Check whether a call to show() will start sending data
immediately or will 'block' for a required interval. NeoPixels
require a short quiet time (about 300 microseconds) after the
last bit is received before the data 'latches' and new data can
start being received. Usually one's sketch is implicitly using
this time to generate a new frame of animation...but if it
finishes very quickly, this function could be used to see if
there's some idle time available for some low-priority
concurrent task.
@return 1 or true if show() will start sending immediately, 0 or false
if show() would block (meaning some idle time is available).
*/
bool canShow(void) {
// It's normal and possible for endTime to exceed micros() if the
// 32-bit clock counter has rolled over (about every 70 minutes).
// Since both are uint32_t, a negative delta correctly maps back to
// positive space, and it would seem like the subtraction below would
// suffice. But a problem arises if code invokes show() very
// infrequently...the micros() counter may roll over MULTIPLE times in
// that interval, the delta calculation is no longer correct and the
// next update may stall for a very long time. The check below resets
// the latch counter if a rollover has occurred. This can cause an
// extra delay of up to 300 microseconds in the rare case where a
// show() call happens precisely around the rollover, but that's
// neither likely nor especially harmful, vs. other code that might
// stall for 30+ minutes, or having to document and frequently remind
// and/or provide tech support explaining an unintuitive need for
// show() calls at least once an hour.
uint32_t now = micros();
if (endTime > now) {
endTime = now;
}
return (now - endTime) >= 300L;
}
/*!
@brief Get a pointer directly to the NeoPixel data buffer in RAM.
Pixel data is stored in a device-native format (a la the NEO_*
constants) and is not translated here. Applications that access
this buffer will need to be aware of the specific data format
and handle colors appropriately.
@return Pointer to NeoPixel buffer (uint8_t* array).
@note This is for high-performance applications where calling
setPixelColor() on every single pixel would be too slow (e.g.
POV or light-painting projects). There is no bounds checking
on the array, creating tremendous potential for mayhem if one
writes past the ends of the buffer. Great power, great
responsibility and all that.
*/
uint8_t *getPixels(void) const { return pixels; };
uint8_t getBrightness(void) const;
/*!
@brief Retrieve the pin number used for NeoPixel data output.
@return Arduino pin number (-1 if not set).
*/
int16_t getPin(void) const { return pin; };
/*!
@brief Return the number of pixels in an Adafruit_NeoPixel strip object.
@return Pixel count (0 if not set).
*/
uint16_t numPixels(void) const { return numLEDs; }
uint32_t getPixelColor(uint16_t n) const;
/*!
@brief An 8-bit integer sine wave function, not directly compatible
with standard trigonometric units like radians or degrees.
@param x Input angle, 0-255; 256 would loop back to zero, completing
the circle (equivalent to 360 degrees or 2 pi radians).
One can therefore use an unsigned 8-bit variable and simply
add or subtract, allowing it to overflow/underflow and it
still does the expected contiguous thing.
@return Sine result, 0 to 255, or -128 to +127 if type-converted to
a signed int8_t, but you'll most likely want unsigned as this
output is often used for pixel brightness in animation effects.
*/
static uint8_t sine8(uint8_t x) {
return pgm_read_byte(&_NeoPixelSineTable[x]); // 0-255 in, 0-255 out
}
/*!
@brief An 8-bit gamma-correction function for basic pixel brightness
adjustment. Makes color transitions appear more perceptially
correct.
@param x Input brightness, 0 (minimum or off/black) to 255 (maximum).
@return Gamma-adjusted brightness, can then be passed to one of the
setPixelColor() functions. This uses a fixed gamma correction
exponent of 2.6, which seems reasonably okay for average
NeoPixels in average tasks. If you need finer control you'll
need to provide your own gamma-correction function instead.
*/
static uint8_t gamma8(uint8_t x) {
return pgm_read_byte(&_NeoPixelGammaTable[x]); // 0-255 in, 0-255 out
}
/*!
@brief Convert separate red, green and blue values into a single
"packed" 32-bit RGB color.
@param r Red brightness, 0 to 255.
@param g Green brightness, 0 to 255.
@param b Blue brightness, 0 to 255.
@return 32-bit packed RGB value, which can then be assigned to a
variable for later use or passed to the setPixelColor()
function. Packed RGB format is predictable, regardless of
LED strand color order.
*/
static uint32_t Color(uint8_t r, uint8_t g, uint8_t b) {
return ((uint32_t)r << 16) | ((uint32_t)g << 8) | b;
}
/*!
@brief Convert separate red, green, blue and white values into a
single "packed" 32-bit WRGB color.
@param r Red brightness, 0 to 255.
@param g Green brightness, 0 to 255.
@param b Blue brightness, 0 to 255.
@param w White brightness, 0 to 255.
@return 32-bit packed WRGB value, which can then be assigned to a
variable for later use or passed to the setPixelColor()
function. Packed WRGB format is predictable, regardless of
LED strand color order.
*/
static uint32_t Color(uint8_t r, uint8_t g, uint8_t b, uint8_t w) {
return ((uint32_t)w << 24) | ((uint32_t)r << 16) | ((uint32_t)g << 8) | b;
}
static uint32_t ColorHSV(uint16_t hue, uint8_t sat = 255, uint8_t val = 255);
/*!
@brief A gamma-correction function for 32-bit packed RGB or WRGB
colors. Makes color transitions appear more perceptially
correct.
@param x 32-bit packed RGB or WRGB color.
@return Gamma-adjusted packed color, can then be passed in one of the
setPixelColor() functions. Like gamma8(), this uses a fixed
gamma correction exponent of 2.6, which seems reasonably okay
for average NeoPixels in average tasks. If you need finer
control you'll need to provide your own gamma-correction
function instead.
*/
static uint32_t gamma32(uint32_t x);
void rainbow(uint16_t first_hue = 0, int8_t reps = 1,
uint8_t saturation = 255, uint8_t brightness = 255,
bool gammify = true);
static neoPixelType str2order(const char *v);
private:
#if defined(ARDUINO_ARCH_RP2040)
void rp2040Init(uint8_t pin, bool is800KHz);
void rp2040Show(uint8_t pin, uint8_t *pixels, uint32_t numBytes, bool is800KHz);
#endif
protected:
#ifdef NEO_KHZ400 // If 400 KHz NeoPixel support enabled...
bool is800KHz; ///< true if 800 KHz pixels
#endif
bool begun; ///< true if begin() previously called
uint16_t numLEDs; ///< Number of RGB LEDs in strip
uint16_t numBytes; ///< Size of 'pixels' buffer below
int16_t pin; ///< Output pin number (-1 if not yet set)
uint8_t brightness; ///< Strip brightness 0-255 (stored as +1)
uint8_t *pixels; ///< Holds LED color values (3 or 4 bytes each)
uint8_t rOffset; ///< Red index within each 3- or 4-byte pixel
uint8_t gOffset; ///< Index of green byte
uint8_t bOffset; ///< Index of blue byte
uint8_t wOffset; ///< Index of white (==rOffset if no white)
uint32_t endTime; ///< Latch timing reference
#ifdef __AVR__
volatile uint8_t *port; ///< Output PORT register
uint8_t pinMask; ///< Output PORT bitmask
#endif
#if defined(ARDUINO_ARCH_STM32) || defined(ARDUINO_ARCH_ARDUINO_CORE_STM32) || defined(ARDUINO_ARCH_CH32)
GPIO_TypeDef *gpioPort; ///< Output GPIO PORT
uint32_t gpioPin; ///< Output GPIO PIN
#endif
#if defined(ARDUINO_ARCH_RP2040)
PIO pio = pio0;
int sm = 0;
bool init = true;
#endif
};
#endif // ADAFRUIT_NEOPIXEL_H
The library has no idea how many pixels you have or on what pin you've hung them until the constructor is executed, which tells it those details as well as the pixel type and color RBG order…
Yes, it may even completely block your code - especially if you call functions which itself rely on interrupts ( like Serial.print ).
To be honest, I don't really understand what you want to do. You should tell a little bit more about you project. And you should provide links to the used HW.
You cannot return a value to the master with onReceive. Your I2C_Received is called when the master has sent data to the slave. You cannot send back to the master in I2C_Received. To send data back to the master, the master must request this from the slave. That is how I2C works. Every data transfer must be initiated by the master. If the master requests data from the slave, the function which is registered by Wire.onRequest() is called. In this function you can send data to the master.
Yes, that's a little bit difficult within an ISR. Even one reason more to keep the ISR short and do the main work in loop().
So the best implementation is that you need an interrupt in setup (e.g. "Wire.onReceive(I2C_Received)"), to direct to a handler (e.g. "I2C_Received"), to initiate a flag (e.g. master_wants_something = true), so it runs in the loop (e.g. if (master_wants_something)? If this is the case, the only thing you need in the handler is a flag and all array work could (or should) be done inside the loop?
And the concern isn't specifically that an ISR is long, but that an ISR called during another ISR is probably going to crash the code?
When you exit the ISR, where do you resume in the loop? At the top of the loop or where it last made it prior to the ISR?
Not really ...
Master sending data to the slave and master requesting data from slave are two different events, that must be handled separately - on master AND on slave.
First the master sends data to slave to tell the slave which data he wants from slave. After that the master sends a data request to the slave, and according to the previous data from master now the slave knows what to send back.
There is no interrupt in setup(). In setup you only tell the wire library which function to call when an according event is sent from master ( there must be two different callbacks - one for the master sending data, and one for the master requesting data).
When the master sends data, in the according callback you should store the received data in an array for later evaluation.
When the master requests data, this data should already be prepared, and written to the wire buffer in the callback.
Both may lead to problems. But of course 'long' is not a fixed time and it depends on many other conditions what is 'too long'. But the shorter the better.
An IRQ acts at machine code level and can happen at any time as long as the IRQ is enabled. Not only between two C++ statements, but most probably while the statement is executed. After the ISR returns, the machine code is resumed at the point where it was interrupted.
That's not really the problem. Things are more complicated - and its depending on the used MPU. IRQ's happening while another IRQ is handled is nothing special. Depending on the circumstances the second IRQ interrupts the first, or it waits until handling of the first is finished. But if blocking the second interrupt leads to blocking code in the first ISR ( which e.g. can happen with Serial.print() ) your complete code blocks and you are in a trap.
As already stated - interrupts are a complicated matter...
I'm going to live in the pragmatic world that I got the code running all thanks to your help. I can somewhat understand code and transistors and such, but compiling to something that can make decisions is a whole another level. Kinda amazing that a 328 costs 3 bucks.