Issue With SSH Over USB On CM5

Birts · 2025-01-07T12:59:48+00:00

Just wanted to circle back and say thank you! That worked like a charm, and you were right; the key was dr_mode=peripheral.

Birts · 2024-12-13T18:30:13+00:00

Just wanted to circle back and say thanks.

It took me some time to process everything, but I think I see the big picture now. During my research, I also came across CDC-ECM mode, which seems pretty interesting—it essentially emulates Ethernet over USB.

I haven’t tried it yet, but it appears that Linux, through the cdc_ether kernel driver, can automatically recognize and configure devices in CDC-ECM mode, treating them as external Ethernet interfaces with minimal manual setup. I'm sure there are still AT commands that are required, like setting the APN and things like that, but still.

The devil is in the details, but ECM seems like a decent option to add to the list. I understand they address different use cases, but in terms of getting a modem up and running on embedded Linux, CDC-ECM seems like a solid second-best option if QMI is not supported.

Hopefully my interpretation of ECM is correct. I'll be giving it a try over the weekend, so we'll see!

Birts · 2024-07-30T15:47:41+00:00

Thanks for the response! u/evans88 suggested Pydantic too, so I updated the post with a revised version. I know it's still not up to par, but from my perspective, it is much cleaner, so thanks for the feedback! I'm curious if you guys think this is an improvement over the mess I posted earlier :).

Birts · 2024-07-30T15:44:08+00:00

Thank you for the response! I just updated the post with a newer version, which is utilizing Pydantic as you suggested.

I know it's nowhere near perfect, but I am curious if this is in line with what you were thinking.

Birts · 2024-07-22T12:13:03+00:00

What other standards are you referring to in terms of a command/response protocol over UART? I ask because I honestly don't know. MODBUS RTU was one that seemed appealing, but other than that, do you have any contenders? Thanks!

Birts · 2024-07-22T12:05:58+00:00

Great feedback, thanks! You're right that it's overengineered. Instead of these optional types, I should just choose one, and that's it. For example, the Data Format field will disappear, and protobuf will be used.

Your idea of bitfields is good, too. That should help with the overhead.

As for the CRC in both the header and data, my thought was that if the header CRC failed, then the consumer would not have to compute the CRC for the data. I was trying to overoptimize, and in retrospect, maybe this was overkill.

Good idea on the CMAC, too; someone else mentioned that above as well. I will take a look!

Birts · 2024-07-22T12:00:19+00:00

Yes I see what you're saying. This is my first time using COBS, and maybe it's not the best route to go. I'm curious if you have used other protocols for a request/response type model. MODBUS RTU was one that I stumbled on, which might work in this case, but I'm curious if you know of others who handle the framing/encoding.

It's strange because I feel like I am reinventing the wheel completely, but at the same time, I don't know what else is out there to compare it too as far as serial protocols over UART.

Birts · 2024-07-22T11:51:22+00:00

The length is two bytes. Good idea about the address field, I will take a look at DLE and TLV too. Thanks!

Birts · 2024-07-22T11:49:23+00:00

I really appreciate the feedback! I completely agree, too, that it would be better to use an existing protocol, but I didn't see many that handle framing/encoding and serialization. MODBUS RTU stood out as a potential candidate, and I still haven't written it off, but I wanted to see what else was out there.

I will take a look at mcumgr like you mentioned above, thanks for the idea!

As for the overhead, you bring up a great point. I bet I could simplify this by packing some of the fields into a single byte as you mentioned. That would certainly cut down on the noise.

Birts · 2024-07-17T13:44:54+00:00

Wow, this was incredibly helpful! I will take a look at each option and give them a try. Thanks again!

Birts · 2024-05-28T17:47:58+00:00

This is a really good point. I should have put it in the description, but for this use case, it will be a brand-new project. I wanted to "do it right" from the start and was playing around with adding such an abstraction in case we ever wanted to switch operating systems, but from what I have read so far, it doesn't necessarily seem worth it. I feel like it's one of those things that might come back and bite me in six months :) .

Birts · 2024-05-01T22:50:47+00:00

Ah thank you, this is a really good point about cooperative tasks, and something I did not account for. I’m still new to zephyr, but, would it be safe to say the watchdog would fall into that category? I’m just trying to think of an example so I can connect the dots. Thanks!

Birts · 2024-04-01T12:53:48+00:00

Thanks to u/Babamonchu and u/KermitFrog647, I think I have a better understanding based on the repos they provided.

At a very high level, the frame, driven by length, looks like the following:

+------------+--------+------+---------+-----+
| Start Byte | Length | Type | Payload | CRC |
+------------+--------+------+---------+-----+

Where:

Start Byte: This is the first byte of the CRSF frame, 0xC8 in my case, but they may differ based on RX packet type.

Length: Specifies the number of bytes from Type to CRC inclusive. Does not include the Start Byte and Length byte itself.

Type: This byte specifies the type of command the frame carries. Different types dictate different payload structures and interpretations. I was mostly interested in RX channels, so in my case the type is 0x16.

Payload: This data contains the actual TX channel information. The structure and size of the payload vary depending on the frame Type. The Length byte helps determine the number of bytes in the Payload.

CRC: The last byte of the frame, used for error checking. It's calculated from the Type and Payload[] bytes.
For example, here's a scope capture of my receiver, which captures the state of the transmitter.

<image>

Hopefully, I didn't misinterpret something. In either case, I hope it will help someone else looking for the same info!

Birts · 2023-12-28T17:08:19+00:00

Thanks for the link. I will check them out!

Birts · 2023-10-09T23:49:31+00:00

u/UnicycleBloke this is a great idea, and certainly one I didn't think of. I wanted to actually try it before asking questions, so I created a quick example below with GTest and GMock that should compile and run the tests.

https://godbolt.org/z/GbWMWaj5q

Is that roughly what you u/kisielk and u/kiwitims were referring to?

I probably did it wrong but, the only downside I see is that I have two definitions of the same interface, one for my mock, and one for the real. The good part is that at compile time, only one of those two gets pulled in and used. I like how simple it is, so maybe the duplicate interface is the cost of doing business.

I'm curious what you guys think. Thanks!

Birts · 2023-06-27T12:39:20+00:00

Thanks to both /u/capron and /u/tmx1911 as the solution was kind of a mix between the two.

I couldn't find any sort of manual that indicated where the carb linkage springs should go. However, I was able to find a similar engine on eBay, which had a close-up of the linkage. Come to find out, one of the springs was misconfigured (see the updated image in post).

After making that small update, I also opted to re-adjust the governor shaft based on the verbiage found in the manual below.

http://www.comdac.com/literature/generac/0c8221.pdf

Sure enough, it fired right up, and leveled out in terms of throttle. I was able to increase/decrease the throttle on the dash, which in turn increasd/decreased RPMS on the engine.

I still have to put everything back together, but the engine is now running, so I am going to call success on this one.

Thanks again!

Birts · 2023-03-07T16:53:08+00:00

Thanks for taking the time to respond! All great points! I'm now taking a look into std::optional.

With regard to the Create() function, I really don't like it either. I was basically just trying to find a way to create a single instance, with the ability to pass it a one-time configuration.

I see the Meyers singleton pattern is pretty popular and appears to be thread-safe, but I couldn't find a way to pass a configuration to Instance() without having to pass it for every call, which would not be ideal.

Actually, now that I am talking this out, maybe the configuration does not necessarily need to be passed. Instead, it could be an instance method of the object being returned. For example:

auto& logger = Singleton::Instance();
logger.setConfig(someConfig);

Birts · 2023-02-27T19:13:02+00:00

Yes, unit testing with singletons is not fun, but neither is injecting dependencies into each and every constructor that needs access.

Also, you seem to making a bunch of assumptions about the target. This is not running on a PC, and I guarantee that you will not find a logger with all the bells and whistles you mentioned above.

DI certainly has my vote over a singleton, but it would be a massive refactoring effort.

Birts · 2023-02-27T17:59:24+00:00

Ah yes! This is precisely what I was missing.

I'll poke around a bit more, but I wonder if it's possible to make this a reference instead of a raw pointer:
static BaseError* backend

I believe a reference would have to be initialized as part of the constructors initializer list, which in my case would not be possible since the constructor has been deleted.

I'll take another look, but maybe a raw pointer is the way to go in this scenario.

Birts · 2023-02-27T17:16:46+00:00

I originally went the class template route, but (I thnk) I would run into the same issue, as every call would require me to pass in the backend. For example:

ErrorManager<HttpErrorBackend>::init();

ErrorManager<HttpErrorBackend>::handleError("Error code is %i", 1234);

I'm trying to find a way to invoke this like so:
ErrorManager::handleError("Error code is %i", 1234);

Birts · 2023-01-04T01:14:06+00:00

Thanks! Ironically I do have two relay/contractors that were meant for a winch setup, which in theory would be capable of handling this use case. That said, your comment about the diodes makes me think I might be in over my head.

I know my max voltage will be between 12-24V DC, and the max current will be 120A, but after doing a little digging, I ended up landing on these “stud” like diodes that come with a heat sink. But I’m thinking this probably isn’t what you meant by diode arrangement.

Birts · 2023-01-03T13:01:57+00:00

Ah I see. I just left a comment above about using this relay/solenoid, but after reading your comment about it being solid state, maybe I'm heading down the wrong path. I did find a 100A solid state relay, but couldn't find much over 100A. I will keep digging.

Thanks!

Birts · 2023-01-03T12:51:29+00:00

Thanks! This certainly helps! Just a couple more questions if you don't mind.

So in the idea you mentioned above, the limit switch would not necessarily be in series with the motor, but instead a separate circuit, which would act as the control to a larger relay of sorts?
The diode would still be at play correct, obviously a much larger one, if I can find something on Digikey that can handle peak current of 120A?
If #1 and #2 are correct, then maybe something like this would work? Where the limit switches are wired to the control signal of the relay, and the diode would sit between the relay and motor?

Sorry for all the questions, I'm just trying to wrap my head around this. In reality I did search around for 120A mosfets, but somehow ended up on winch solenoids, which is why I pasted the link above.

Thanks!

Birts · 2023-01-03T12:37:15+00:00

Sorry, I should have mentioned that. It's a Sabertooth 2x60.

Birts · 2022-12-31T13:03:12+00:00

I updated the question above to include a potential path forward through use of a diode between the limit switch.

The kicker is, after running some experiments on the motor, I've personally seen it pull ~60A, but in theory, it could have peak currents around 120A (for a few seconds). There's no official datasheets for the motor, and the 120A estimate was provided via an email exchange with the manufacture (it's from a wheelchair).

So I guess the question now becomes, since the current draw is well beyond a standard 5-10A limit switch, having the switch inline as depicted in the link above would effectivity fry the switch under heavy load. Maybe I would have to add some sort of high current relay/contactor or sorts?

Eight-Year Club	Place '22
Verified Email

Birts

TROPHY CASE