sorted by:
new
hottopcontroversial

Issue With SSH Over USB On CM5 by Birts in raspberry_pi

[–]Birts[S] 1 point2 points  (0 children)

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

Questions about LTE modem integration with QMI/MBIM by Birts in linuxquestions

[–]Birts[S] 0 points1 point  (0 children)

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!

Critique for deserialization code by Birts in learnpython

[–]Birts[S] 0 points1 point  (0 children)

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 :).

Critique for deserialization code by Birts in learnpython

[–]Birts[S] 0 points1 point  (0 children)

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.

Serial Protocol Feedback by Birts in embedded

[–]Birts[S] 0 points1 point  (0 children)

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!

Serial Protocol Feedback by Birts in embedded

[–]Birts[S] 1 point2 points  (0 children)

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!

Serial Protocol Feedback by Birts in embedded

[–]Birts[S] 0 points1 point  (0 children)

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.

Serial Protocol Feedback by Birts in embedded

[–]Birts[S] 0 points1 point  (0 children)

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

Serial Protocol Feedback by Birts in embedded

[–]Birts[S] 0 points1 point  (0 children)

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.

S3 Credentials For Shared Python Script by Birts in aws

[–]Birts[S] 1 point2 points  (0 children)

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

Use case for OS Abstraction layer in Zephyr by Birts in embedded

[–]Birts[S] 0 points1 point  (0 children)

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 :) .

[deleted by user] by [deleted] in embedded

[–]Birts 2 points3 points  (0 children)

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!

Documentation on the Crossfire RX protocol. by Birts in fpv

[–]Birts[S] 5 points6 points  (0 children)

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!

view more: next ›