.NET implementation

So, this was awesome, thank you for the response! It doesn't, however, actually solve my problem. It's probably the library that I'm using, because here's what's going on:

log.WriteLog("---------------------------------------------------------------------");
byte[] recvBytes = new byte[6];
byte[] sendBytes = new byte[] { 0x99 };
foundDevice.Write(sendBytes);
recvBytes = foundDevice.Read(6);
int raw = ((int)recvBytes[1] << 8) + (int)recvBytes[2];
log.WriteLog("recvBytes[1]: " + recvBytes[1].ToString("X2"));
log.WriteLog("recvBytes[2]: " + recvBytes[2].ToString("X2"));
log.WriteLog("raw         : " + raw.ToString());
log.WriteLog("---------------------------------------------------------------------");

And the problem is, it produces this:

17/03/2021 20:01:13: ---------------------------------------------------------------------
17/03/2021 20:01:13: recvBytes[1]: 99
17/03/2021 20:01:13: recvBytes[2]: 99
17/03/2021 20:01:13: raw         : 39321
17/03/2021 20:01:13: ---------------------------------------------------------------------

The specific library that I'm using is this one:
https://github.com/unosquare/raspberryio

Frustrating as heck, because according to your Python code (assuming you were the one who wrote it) a hit on 0x99 should produce a response of:
0x99/0x15/0x00/0x00/0x00/0x00

But as you can see, it just responds 0x99/0x99/0x99/0x99/0x99/0x99.

I'm still too new to this part of things that I don't know if it's ME, or if it's the library I'm using.

But either way, any help is IMMENSELY appreciated.

Thanks.
-J

Oh, you ROCK! I'll look at this after my work day. Cheers, mate!

Hey. I don't... actually know what to call you other than @piborg.

So I checked out that repo at the link. It's older than dirt, but it "sort of" works. I've got some really, really weird crap going on with it that I can't yet explain, but overall, we've got FORWARD MOTION! LOL And we can stop! LOLer.

I'm getting some strange things happening, though, that I've had to confirm through your Python code. Namely, when setting 0x08 to 0x80, my A side wheels are going forward. Great. The next step - even if I send an all-stop first - is to send 0x11 a 0x80... and BOTH my A and B wheels are now going forward. I don't understand this yet.

Seen it before?

*IF* you're interested (or anyone else here) I'll throw my code up on GitHub along with a fork of the original code.

Let me know.

Thanks!
-J

...was I REALLY that tired?

Dang it, I thought I checked that. Twice. Ugh. I'll try that, thank you for putting up with me, Arron. I'm James.

And I'm good at this, I swear to God....

I mean, I do this as a DAY JOB... *smdh*

-J

Hey:

My repo is here, but it's Mono based, not Dotnet, just yet. I'm building this out and hoping to migrate it over to .Net Core soon.

https://github.com/crazycga/RPi.I2C.Net

It'll have a different name. But so far, I have code that runs motors, gets values, etc. I'm having some problems with setting LED values, but I'm working on them.

Thanks!
-J

...I will have a native .Net Core 3.1 implementation. Stay tuned!

Thanks, man. That's what I'm trying. I've validated that your Python script to wave the LEDs is working. But man, I'm getting some weird results here. I'll try putting in a delay, but what's happening that I just observed is that using a loop to go through colors 10 at a time, the LEDs are flashing... But only intermittently, and only when the LED monitoring is ON!!! Which has me puzzled. When I turn it off - and CONFIRM IT - it simply doesn't want to play fair with me.

I'll try the delay thing and get back to you.

Hey Arron:

I hate to be a PITA, but I can't figure out WTF is going on... This code is the exact same code used to pass values to the wheels, etc., but for whatever reason it is NOT working for the LEDs. Would you mind taking a quick look and see if I've missed something obvious, again? (note that I've collapsed some of the code to make it look right here, with the _ tag.)

public void WaveLEDs(Logger_class log = null)
{
	bool batSetting = false;
	batSetting = this.GetLEDBatteryMonitor(log);

	while (batSetting)
	{
		log.WriteLog("Battery was monitoring; resetting to off.");
		this.SetLEDBatteryMonitor(false, log);
		batSetting = this.GetLEDBatteryMonitor(log);
	}

	log.WriteLog("This routine will run through the colors of the LEDs.  Press any key to stop.");
	while (!Console.KeyAvailable)
	{
		for (int i = 0; i < 255; i = i + 10)
		{
			for (int j = 0; j < 255; j = j + 10)
			{
				for (int k = 0; k < 255; k = k + 10)
				{
					log.WriteLog("Set LED1: 01 " + i.ToString("X2") + " " + j.ToString("X2") + " " + k.ToString("X2") + _
						" 00 00  LED2: 03 " + i.ToString("X2") + " " + j.ToString("X2") + " " + k.ToString("X2") + " 00 00");
					this.SetLEDs(Convert.ToByte(i), Convert.ToByte(j), Convert.ToByte(k), log);
					log.WriteLog("Get LED1: " + this.BytesToString(this.GetLED1()) + " LED2: " + this.BytesToString(this.GetLED2()));
					if (Console.KeyAvailable) break;
				}
				if (Console.KeyAvailable) break;
			}
			if (Console.KeyAvailable) break;
		}
		if (Console.KeyAvailable) break;
	}
	Console.ReadKey(true);
}

And the code for ThunderBorg.SetLEDs:

public void SetLEDs(byte red, byte green, byte blue, Logger_class log = null)
{
	if (!_CheckInit())
	{
		return;
	}

	if (log != null)
	{
		log.WriteLog("Setting LEDs to " + red.ToString() + ", " + green.ToString() + ", " + blue.ToString() + "...");
	}

	using (var bus = I2CBus.Open("/dev/i2c-" + this._bus.ToString()))
	{
		if (log != null) 
		{
			log.WriteLog("Setting LEDs using command: " + this.BytesToString(new byte[] { COMMAND_SET_LEDS, red, green, blue }));
		}

		bus.WriteBytes(_TBorgAddress, new byte[] { COMMAND_SET_LEDS, red, green, blue });
		if (THROTTLE_CODE)
		{
			System.Threading.Thread.Sleep(200);
		}
		byte[] response = bus.ReadBytes(_TBorgAddress, I2C_MAX_LEN);

	}
}

The value for COMMAND_SET_LEDS:

public static readonly byte COMMAND_SET_LEDS            = 0x05;

The rest of the code is in my repo at https://github.com/crazycga/ThunderSharp

What I'm observing happen: the LED value seem to go though being SET, but does not appear to "TAKE":

20/03/2021 13:36:15: Setting LEDs using command: 05 00 00 0A
20/03/2021 13:36:16: Get LED1: 02 19 19 19 00 00  LED2: 04 FF 00 00 00 00
20/03/2021 13:36:16: Set LED1: 01 00 00 14 00 00  LED2: 03 00 00 14 00 00
20/03/2021 13:36:16: Setting LEDs to 0, 0, 20...
20/03/2021 13:36:16: Setting LEDs using command: 05 00 00 14
20/03/2021 13:36:16: Get LED1: 02 19 19 19 00 00  LED2: 04 FF 00 00 00 00
20/03/2021 13:36:16: Set LED1: 01 00 00 1E 00 00  LED2: 03 00 00 1E 00 00
20/03/2021 13:36:16: Setting LEDs to 0, 0, 30...
20/03/2021 13:36:16: Setting LEDs using command: 05 00 00 1E
20/03/2021 13:36:17: Get LED1: 02 19 19 19 00 00  LED2: 04 FF 00 00 00 00
20/03/2021 13:36:17: Set LED1: 01 00 00 28 00 00  LED2: 03 00 00 28 00 00

I kind of hate asking, but I'm running out of inspiration.

Thanks, man!
-J

...and that didn't seem to make a difference, BUT, you've sent skittering off on a different tangent. I observed that the underlying code (C) for this library is accepting

byte* buf

and perhaps when it take that pointer and works on it, it might be losing something? I'm reaching, too, but I might just give it a try and see.

You da man, though! I can't express enough how much I appreciate your input, sir.

Thanks.
-J

I'll be go to hell, but I GOT IT!

You were absolutely (and accidentally) correct!

The I2C library that I farmed was a skootch too fast. It was written as:

if (write (busHandle, buf, len) != len)

So I changed it (because I wanted to enumerate the number of bytes actually written) and expanded it into an if-then clause:

    int rlen = write(busHandle, buf, len);
    if (rlen != len)
    {
        return -2;
    }

And I'll be damned but it started actually working! So you were right the first time, the code was moving too fast for the I2C response. But it was WAY deeper than in my C# code, it was way down in the C library I used. (LOL Told you I knew what I was doing. HAHAHAHA) I'll be updating my repo, testing it, then calling this the first ThunderSharp release. I haven't implemented all of the functions you have in the ThunderBorg.py library yet.

Which leads me to a question. Why - of all things - does that library contain output for the LED strip? (SK9822 / APA102C)

Thank you, thank you, thank you for your help, Arron! You da MAN!
-J

Thanks man. I've got ... two? more functions to implement and I should be "done". I haven't implemented the change address function (scared to, LOL) and ... okay, maybe one. I have to see. Unfortunately my day job interferes with my hobby.... Then I'll clean up the code, make the error handling consistent and then release.

Again, many thanks for the help!
-J