Uavcan.rs v1 progress tracking

Here is the definition for the map and here is where a memory allocation is happening on the first time a transfer id is stored in the _tx_transfer_map. :bowing_man:

1 Like

Ok, thanks for pointing out. But when I use the private function enqeueTransfer() (made it public:)), I supply the transfer_id myself. So, I don’t use the heap allocated std::map.

1 Like

Approved some PRs, I’m still not sure about the the StreamIterator one, but I think most of my hesitancy there is just because I’m a bit tired and I don’t like having to go back to while (it reminds me of C :stuck_out_tongue:). I’ll probably like it more tomorrow (or maybe we just implement both Iterator and StreamingIterator?).

I also properly learned why rebasing your dev branch is a bad idea - I thought I could get away with that but I guess I didn’t, @alexander_huebener please double check the PRs, I may have messed something up and not noticed it.

Sorry all, I’ve been completely AWOL for the last month. I have a pretty tame finals season this year so I should be able to actually spend a bit of time over the next little while.

I went through, updated all the PRs (turns out unstable features are unstable and may have to be properly tracked, huh) and merged everything except for the CAN-FD PR. Still won’t merge that until it gets some proper testing (preferably on some real hardware) and also gets updated to the embedded-hal types.

Speaking of embedded-hal, looks like it’s going to release 1.0 soon, which also nicely includes the CAN types, which should mean we can update to them and use (hopefully) ecosystem-standard types for CAN.

1 Like

Oh, I forgot. @pavel.kirienko can you remove uavcan.rs from TravisCI? AFAICT I’ve taken out all of the files but it’s still registering as a check step in github and making it impossible for anyone without admin to merge a PR.

Done (I think). Travis-CI was still listed as a required status check in GitHub branch protection rules, so I removed it from there.

1 Like

May I suggest that we close all v0-related issues to clear the backlog?

That would be a good idea. I keep avoiding it because I keep thinking someone might go back to the v0 implementation some day but that’s definitely not happening at this point.

1 Like