I don't know my problem, there's two of them.

[tsmspace]

Firstly, maybe my easy problem, I set up a controller with 29 channels. channel 28 and 29 don't seem to work, although vjoyserialfeeder reports 29 channels. maybe is there some limit somewhere in ibus that I don't know about? I want to add two more channels already, so not sure what to make of it.

edit:::: I added another joystick to total 8, , and it's the same two buttons that still don't work, , they go to analog a6 and a7 on an arduino nano. But,, there was never a problem when those pins handled joysticks, and a5 works fine,,, I don't see how there can be a max number of channels when adding more works. so weird to me dunno.

edit:::: I solved the problem with the buttons not working. the arduino nano won't allow digital read on a6 and a7. I can probably just read them as analog and have vjoyserialfeeder use them as buttons. now there is only the odd problem where the profile whacks out over time. so far all of my newly created profiles are working, but the ones that failed all had a feature I really want to use, which is mapping joysticks to be buttons, so I'm not sure if that's where the problem is, because that feature is critical! (windows only accepts 8 axis, and I'm counting on using axis to make buttons)

edit4::::: well,, I've been playing with it for a short while, and operation does seem much more stable than before right away, although it took a week or so to manifest the heavy duty failsafe behavior. I will give it some time.

secondly, in vjoyserialfeeder there appears to be some kind of bug. For a while I thought my controller build was the problem, as it is a bungle of wires, but I'm really confident by now in my soldering, and when I went to hook up a breadboarded version, I had the problem again, but then switched to an older test profile and walla , it worked normally. So,, somehow my profiles got bungled up so that they just read failsafe and wait for data. . I haven't run it for long on the other profile to see if it does it again, but my plan is to just build a whole new profile and see what happens,, but without a doubt the two buttons from above never worked in either case.

attached is the sketch for 7 joysticks, the sketch for 4 joysticks, the profile for 4joysticks (8joy), and the first test for 7 which still works, and the profile that doesn't work anymore, and reads failsafe only. gamepadtest2.zip

any guidance is appreciated, I really have no knowledge, it's really a hackjob. gamepadtest4.zip profiles.zip

[Cleric-K]

Hi, can you look at https://github.com/Cleric-K/vJoySerialFeeder/issues/24#issuecomment-504308045

Some dump of the serial communication will be valuable. We'll know whether the problem comes from the arduino or something else happens in vjsf. Also, did you activate 'use 16-bit channels' in the IBUS setup button?

[tsmspace]

well,, normally all I do is select ibus. I did try hitting the ia6b selection box a few times once it had the problem, but nothing changed, and when it works I never do that and it works. Technically I've been using it on a new profile I've created, and there's another weird thing that happens sometimes when making a profile where one of the buttons has a red x on the field. It might be that when I see that red x, delete the button or axis, and then add one again,, this is the profile that also then doesn't work in the long run. Also I wonder if I tried to copy one profile to another by simply renaming it and then saving as ,, I wonder if there's a correlation there. ---- Well I don't know how to use that program to dump data, so have no idea if this is what you were looking for. I will attach a screenshot of the settings and data field, and then paste some of the data below. actually the program is not responding a lot, maybe you can just see what data is in the screensnip. terminal data field.txt

edit::::: I just want to make the additional comment that this vjoyserialfeeder has made all of my most favorite things possible! I have some genuinely amazing accomplishments with my game controllers (I mean that they are huge for me,, simple things but for me otherwise unimaginable) and I do want to make sure and say my thanks.

[Cleric-K]

Thanks for your appreciation and generous donation! I'm not sure what could be going on. The data dump looks correct. It has 29 channels and the checksums are right. At this point I don't see how anything in the profile can cause timeouts. What I meant about the IBUS setup was this:

Can you make a screenshot of the red X ?

Do you use the channel monitor? (Program / Channel Monitor menu) do things look normal there?

[tsmspace]

edit:::: update::::: so the controller seems to run wildly at first, every time I plug it in, getting updates at wildly varying times,, before stabilizing to 10ms per update as the sketch should dictate. Then, it runs smoothly for a while, but several times this morning did failsafe to a halt. I am now using the latest version of vjoyserialfeeder (1.7.1) and do have 16bit arduino ibus selected. when it failsafes,, hitting the reset button on the arduino always has no effect, and what solves it consistently is hitting disconnect in vjoyserialfeeder, then hitting connect again. While running smoothly, if I reset the arduino, it do 3profiles.zip es failsafe for a moment while the arduino boots, but then sets back to normal in a few seconds. Once it does the failsafe of death (as i will call it), the only thing that seems to work is reconnecting. I usually don't have to pull the usb, but that has been necessary be gamepadtest6.zip fore, but not recently so not sure if there's any relationship between those faults,, that could have been the board having voltage instability from sloppy soldering. ((it still could be, I know,, but it seems that restarting the arduino would then have an effect on the failsafe,, and restarting the arduino isn't necessary to get back to normal operation, because clicking disconnect and then connect again has no effect on the arduino, which just sends serial data and asking forgiveness rather than asking first. end edit::::

so perhaps my version is older because I don't have the 16-bt channels option. I will investigate downloading an updated version.

I thought it doesn't make sense that my soldering could be needing to be reworked, because creating a new profile made it go back to normal operation,, but using a new profile that showed heavy changes in update millis (often below 10 ms), I reworked a bunch of the solder and it seemed to stabilize a lot,, so perhaps my soldering is the problem after all. It's not THAT sloppy, but I did change out one potentiometer that was hacked out of a toy controller with one that I didn't need to hamburger the pcb to access , and cleaned everything a lot better with alchohol, and although I did still experience a failsafe, overall the stability improved a lot. ((this is probably pretty important info)) .

the red x doesn't appear much but it's in the calibration field where the graph is displayed. The area where the potentiometer graph would normally be changes to a red border and x inside of the field, and then an "unhandled exception" warning pops up, and then basically I have to close the program and basically start over creating a profile. I don't know about all of the other times, but last night I got a red x from accidentally clicking something, I don't recall what but one of the buttons out of order was my impression.

at the moment I don't experience different millis,, , it remains at stable 10ms,, but I did experience the one failsafe, where i had to disconnect and reconnect.

I do have another issue, but I didn't bring it up because I didn't think of it as relevant, but you might be interested to know that I am using budget arduinos which means they use the ch341 usb protocol chip, and the ch341 driver causes my computer to crash occasionally. arduinos can ship with at least two different usb chips on them,, and I think 3 have existed, , an ftdi variant, the very common ch341 variant, and another one by atmel which is the "genuine arduino" version. The ch341 driver was never a problem until I updated to windows 11. it's a bsod crash that lists the ch341 driver which is how I know it's the crash.

I am going to see if I should update my vjoyserialfeeder, but for now I'm going to see how it holds up after the things I listed above.

edit:: : here's a pictures of my controller present state ,, here's the sketch present state, here's the feederprofiles present state, which I did change up

[tsmspace]

Hello.

I have been in the arduino forum, and someone there told me that if my arduino tried to write data outside of an array, it would lead to random processor restarts. They pointed out that I am using the bit-mapped buttons array with no information in the sketch. I think I tried to take that part out before, but went back to having it in because I wasn't sure about something.

Would you know about this , or why the arduino might possibly try to write data outside of the array? I don't know if this relates to my problem or not, but a random arduino restart might make sense. Periodically it failsafes, and there is no data, and by disconnecting and reconnecting I can go back to using it. Sometimes it happens often in a short period of time, and then for a long time it does not happen at all.

[Cleric-K]

Hi, in the way it is originally written, the sketch shouldn't allow for writing outside the array boundaries. You may share your code to take a look.

One way to have some idea about what's going on is to add some code that makes the Arduino LED blink quickly. If the board locks up this should disrupt the regular pattern.

[tsmspace]

well,, even restarting the arduino doesn't change the failsafe in that case, I have to disconnect and reconnect. It actually happens sometimes that I still see that the arduino is connected, but it doesn't work in the game. Mostly, though, it goes to failsafe, and if I (use the button) to disconnect and reconnect, it works. It has rarely happened that I need to restart the app to see it work in game, even though it works in vjoyserialfeeder.

So if it was going to disrupt the blinking, though, it would only be for that one quick moment, because then it goes back to running normally. What sort of led timing would you use ? 10millis seems too fast for me to see.

#include <CD74HC4067.h>

#include "ibus.h"

// //////////////////
// Edit here to customize

// How often to send data?
#define UPDATE_INTERVAL 10 // milliseconds

// 1. Analog channels. Data can be read with the Arduino's 10-bit ADC.
// This gives values from 0 to 1023.
// Specify below the analog pin numbers (as for analogRead) you would like
to use.
// Every analog input is sent as a single channel.
#define NUM_ANALOG_INPUTS 16
byte analogPins[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,12,13,14,15}; //
element count MUST be == NUM_ANALOG_INPUTS

#define NUM_OTHER_ANALOG 2

// 2. Digital channels. Data can be read from Arduino's digital pins.
// They could be either LOW or HIGH.
// Specify below the digital pin numbers (as for digitalRead) you would
like to use.
// Every pin is sent as a single channel. LOW is encoded as 0, HIGH - as
1023
#define NUM_DIGITAL_INPUTS 13
byte digitalPins[] = {2,3,4,5,6, 7,8,9,10,11,12,13,A5}; // element count
MUST be == NUM_DIGITAL_INPUTS

// 3. Digital bit-mapped channels. Sending a single binary state as a 16-bit
// channel is pretty wasteful. Instead, we can encode one digital input
// in each of the 16 channel bits.
// Specify below the digital pins (as for digitalRead) you would like to
send as
// bitmapped channel data. Data will be automatically organized in channels.
// The first 16 pins will go in one channel (the first pin goes into the
LSB of the channel).
// The next 16 pins go in another channel and so on
// LOW pins are encoded as 0 bit, HIGH - as 1.
#define NUM_DIGITAL_BITMAPPED_INPUTS 0
byte digitalBitmappedPins[] = {}; // element count MUST be ==
NUM_DIGITAL_BITMAPPED_INPUTS

// Define the appropriate analog reference source. See
//
https://www.arduino.cc/reference/en/language/functions/analog-io/analogreference/
#define ANALOG_REFERENCE DEFAULT

// Define the baud rate
#define BAUD_RATE 115200

// /////////////////

#define NUM_CHANNELS ( (NUM_ANALOG_INPUTS) + (NUM_DIGITAL_INPUTS) + (
NUM_OTHER_ANALOG) + (15 + (NUM_DIGITAL_BITMAPPED_INPUTS))/16 )

CD74HC4067 my_mux(A0, A1, A2, A3);
const int signal_pin = A4; // Pin A4 - Connected to Sig pin of CD74HC4067
IBus ibus(NUM_CHANNELS);

void setup()
{
  analogReference(ANALOG_REFERENCE); // use the defined ADC reference
voltage source
  Serial.begin(BAUD_RATE);           // setup serial
  pinMode(A0, OUTPUT);
  pinMode(A1, OUTPUT);
  pinMode(A2, OUTPUT);
  pinMode(A3, OUTPUT);
}

void loop()
{
  int i, bm_ch = 0;
  unsigned long time = millis();

  ibus.begin();

  // read analog pins - one per channel
  for(i=0; i < NUM_ANALOG_INPUTS; i++) {
    //my_mux.channel(6);
    //Serial.println("-" + String(i));
    my_mux.channel(analogPins[i]);
    //int val = analogRead(signal_pin);
    //Serial.println("Channel "+String(i)+": "+String(val));
    ibus.write(analogRead(signal_pin));
   // Serial.println(String(analogPins[i]) + " - " +
String(analogRead(signal_pin)));
   // Serial.println(analogPins[i]);
  // read digital pins - one per channel
  }
  ibus.write(analogRead(A6));
  ibus.write(analogRead(A7));
  for(i=0; i < NUM_DIGITAL_INPUTS; i++)
    ibus.write(digitalRead(digitalPins[i]) == HIGH ? 1023 : 0);
    //Serial.println("--" + String(i));
  // read digital bit-mapped pins - 16 pins go in one channel
  for(i=0; i < NUM_DIGITAL_BITMAPPED_INPUTS; i++) {
    int bit = i%16;
    if(digitalRead(digitalBitmappedPins[i]) == HIGH)
      bm_ch |= 1 << bit;

    if(bit == 15 || i == NUM_DIGITAL_BITMAPPED_INPUTS-1) {
      // data for one channel ready
      ibus.write(bm_ch);
      //Serial.println("--");
      bm_ch = 0;
    }
  }

  ibus.end();
  //Serial.println("end");
  time = millis() - time; // time elapsed in reading the inputs
  if(time < UPDATE_INTERVAL)
    // sleep till it is time for the next update
    delay(UPDATE_INTERVAL  - time);
}

On Tue, Jan 24, 2023 at 1:10 AM Cleric-K @.***> wrote:

Hi, in the way it is originally written, the sketch shouldn't allow for writing outside the array boundaries. You may share your code to take a look.

One way to have some idea about what's going on is to add some code that makes the Arduino LED blink quickly. If the board locks up this should disrupt the regular pattern.

— Reply to this email directly, view it on GitHub https://github.com/Cleric-K/vJoySerialFeeder/issues/65#issuecomment-1401752094, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKZAT5PX2WQP327L7N43WMLWT62DJANCNFSM6AAAAAASFTWW3E . You are receiving this because you authored the thread.Message ID: @.***>

[Cleric-K]

You don't seem to be using bitmapped inputs at all, so I guess that's not the issue.

For the LED you may try to replace the code after ibus.end() with something like:

do {
  digitalWrite(LED_BUILTIN, (millis() >> 8) & 1);
while(millis() - time < UPDATE_INTERVAL);

Don't forget to set pinMode(LED_BUILTIN, OUTPUT) in setup().

You can adjust the blink rate by changing the number in millis() >> 8. This method allows for rates that are powers of two - 32ms, 64ms, 128ms, 256ms, 512ms and so on.

Another possibility might be that there could be issues with the USB host, drivers, OS. You may try using another USB port if possible.