Additions to I2CtoFastLeds code

Squatnet commented

2019-03-06 12:03:23 +00:00

(Migrated from github.com)

I2CtoFastLEDS code requires some additions to facilitate sending the number of connected strips back to I2C master... The PJON Master code has been updated already.
We will use Wire.requestEvent() to request 1 byte from slave num 1

I2CtoFastLEDs.ino

in setup() add
Wire.onRequest(requestEvent);

just before void receiveEvent(int howMany) function add

// Function to reply to master when master requests data 
// In this case master will want to know how many strips are connected
void requestEvent() {
  Wire.write(NUM_STRIPS); // respond with NUM_STRIPS
}

this will allow I2CtoFastLEDS to respond to a request with NUM_STRIPS

pjonToI2C.ino

in setup() remove the line DPRINTLN("Done!!!"); from below Wire.begin()
and then add

  DPRINT(". ");
  Wire.requestFrom(1, 1); // request 1 byte from Wire(1)
  DPRINT(". ");
  delay(100); // To make sure request is handled
  DPRINTLN("Done!!!");
  DPRINT("Slave has ");
  String attchSt = ",";
  while (Wire.available()) { // slave may send less than requested
    char c = Wire.read(); // receive a byte as character
    attchSt.concat(c);         // print the character
  }
  DPRINT(attchSt);
  DPRINTLN(" strips attached.");
  regString.concat(attchSt);

this will allow pjonToI2C to request NUM_STRIPS from slave 1 and append the value to regString before reporting to PJON master (we assume all slaves have the same number of strips attached. differing numbers of strips per i2c slave is just overcomplicating the overcomplicated)

I2CtoFastLEDS code requires some additions to facilitate sending the number of connected strips back to I2C master... The PJON Master code has been updated already. We will use `Wire.requestEvent()` to request 1 byte from slave num `1` ### I2CtoFastLEDs.ino in `setup()` add `Wire.onRequest(requestEvent);` just before `void receiveEvent(int howMany)` function add ``` // Function to reply to master when master requests data // In this case master will want to know how many strips are connected void requestEvent() { Wire.write(NUM_STRIPS); // respond with NUM_STRIPS } ``` this will allow I2CtoFastLEDS to respond to a request with NUM_STRIPS ### pjonToI2C.ino in `setup()` remove the line `DPRINTLN("Done!!!");` from below `Wire.begin()` and then add ``` DPRINT(". "); Wire.requestFrom(1, 1); // request 1 byte from Wire(1) DPRINT(". "); delay(100); // To make sure request is handled DPRINTLN("Done!!!"); DPRINT("Slave has "); String attchSt = ","; while (Wire.available()) { // slave may send less than requested char c = Wire.read(); // receive a byte as character attchSt.concat(c); // print the character } DPRINT(attchSt); DPRINTLN(" strips attached."); regString.concat(attchSt); ``` this will allow pjonToI2C to request NUM_STRIPS from slave 1 and append the value to regString before reporting to PJON master (we assume all slaves have the same number of strips attached. differing numbers of strips per i2c slave is just overcomplicating the overcomplicated)

kieran-boyle commented

2019-03-06 12:25:49 +00:00

(Migrated from github.com)

Ok lovely. Presuming all will have the same number of strips does however go against brief. Some further thought on how to implement allowing different numbers of strips per device would be ideal. Could master hold an array with the number of strips for each device (for example).

Squatnet commented

2019-03-06 13:03:58 +00:00

(Migrated from github.com)

Why does it go against the brief that all i2c slaves on a pjonToI2C device
have the same number of strips?
I thought we spoke about this the other night and decided that it would be
fine to ask Wire(1) how many strips it had and safely assume that all other
I2C slaves attached to that device would have the same number attached.
Pretty sure we said if we were going to have different numbers of strips we
would have them on seperate PJON slaves with the same name.
Really, think about us sending a command to a Strip device. We try and tell
it to address a strip that doesnt exist. MCU crashes.
This was discussed and we all agreed that having different numbers of
strips for different i2c slaves on the same pjon device was not feasible at
the moment but would be something investigated for DV3. It wont work with
structs without using an array to hold the attached strips inside the
struct. If we use an array to hold the amount of attached strips then how
big is that going to need to be (It would need to hold an int for each i2c
slave, how many max? What a waste of precious dynamic memory if we have an
array with space to hold 10 ints, but regularly are only using 2.. We then
have to send all that info to the bluetooth app? Dynamically generate a
page with the right number of strips per device when only one device type
has this parameter?
Keep it simple. . .
Want a device with a different number of strips attached? Put it on a
different PJON slave. I really need you to see that I am trying to stop
this becoming any more complicated than is absolutely necessary. Sure it
would be lovely to know every single thing about every single device and
its status but it is just not feasible using PJON (network throughput and
packet loss due to multiple devices sending at same time) or BlueTooth
(software serial has a max buffer of 64 bytes) without making master ignore
devices while it is trying to collect or send information that now needs to
be chunked. It's not as easy as adding a new variable.
Currently a single device sent to the bt app will look like
{"Dev":["Type","Name",ID]}
After these changes it will look like
{"Dev":["Type","Name",ID]} for everything except strips
{"Dev":["Str","Name",ID,attachedStr]} for strips
What you are proposing is more like
`{"Dev":["Str","Name",ID,numSlaves,[slave1
strips,slave2strips,slave3strips,slave4strips,etc,etc,etc]]}
Which is great provided the combined length of the entire string is less
than 63 bytes. Otherwise it overflows softserial buffer.

Please understand I'm not saying this because "I dont want to write the
code" I'm saying it because it's already far too complicated and involves
major changes to the core code for pjonToI2c, 2560ProPjonMaster and the
fundamental functionality of the app.

On Wed, 6 Mar 2019, 12:25 kieran-boyle, notifications@github.com wrote:

Ok lovely. Presuming all will have the same number of strips does however
go against brief. Some further thought on how to implement allowing
different numbers of strips per device would be ideal. Could master hold an
array with the number of strips for each device (for example).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Squatnet/ArduinoStuff/issues/65#issuecomment-470088595,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZCEGmV6SAODxIEiLH0Dih5K9qxUKOrlks5vT7PNgaJpZM4bguZ8
.

Why does it go against the brief that all i2c slaves on a pjonToI2C device have the same number of strips? I thought we spoke about this the other night and decided that it would be fine to ask Wire(1) how many strips it had and safely assume that all other I2C slaves attached to that device would have the same number attached. Pretty sure we said if we were going to have different numbers of strips we would have them on seperate PJON slaves with the same name. Really, think about us sending a command to a Strip device. We try and tell it to address a strip that doesnt exist. MCU crashes. This was discussed and we all agreed that having different numbers of strips for different i2c slaves on the same pjon device was not feasible at the moment but would be something investigated for DV3. It wont work with structs without using an array to hold the attached strips inside the struct. If we use an array to hold the amount of attached strips then how big is that going to need to be (It would need to hold an int for each i2c slave, how many max? What a waste of precious dynamic memory if we have an array with space to hold 10 ints, but regularly are only using 2.. We then have to send all that info to the bluetooth app? Dynamically generate a page with the right number of strips per device when only one device type has this parameter? Keep it simple. . . Want a device with a different number of strips attached? Put it on a different PJON slave. I really need you to see that I am trying to stop this becoming any more complicated than is absolutely necessary. Sure it would be lovely to know every single thing about every single device and its status but it is just not feasible using PJON (network throughput and packet loss due to multiple devices sending at same time) or BlueTooth (software serial has a max buffer of 64 bytes) without making master ignore devices while it is trying to collect or send information that now needs to be chunked. It's not as easy as adding a new variable. Currently a single device sent to the bt app will look like `{"Dev":["Type","Name",ID]}` After these changes it will look like `{"Dev":["Type","Name",ID]}` for everything except strips `{"Dev":["Str","Name",ID,attachedStr]}` for strips What you are proposing is more like `{"Dev":["Str","Name",ID,numSlaves,[slave1 strips,slave2strips,slave3strips,slave4strips,etc,etc,etc]]} Which is great provided the combined length of the entire string is less than 63 bytes. Otherwise it overflows softserial buffer. Please understand I'm not saying this because "I dont want to write the code" I'm saying it because it's already far too complicated and involves major changes to the core code for pjonToI2c, 2560ProPjonMaster and the fundamental functionality of the app. On Wed, 6 Mar 2019, 12:25 kieran-boyle, <notifications@github.com> wrote: > Ok lovely. Presuming all will have the same number of strips does however > go against brief. Some further thought on how to implement allowing > different numbers of strips per device would be ideal. Could master hold an > array with the number of strips for each device (for example). > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/Squatnet/ArduinoStuff/issues/65#issuecomment-470088595>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AZCEGmV6SAODxIEiLH0Dih5K9qxUKOrlks5vT7PNgaJpZM4bguZ8> > . >

Squatnet commented

2019-03-27 15:57:05 +00:00

(Migrated from github.com)

This is closed

Rows
Columns

Additions to I2CtoFastLeds code #65

I2CtoFastLEDs.ino

pjonToI2C.ino