Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lukas Schmierer
    @lschmierer
    I am thinking about rewriting the library using async IO using tokio.
    @robomancer-or while tokio relies on std, I think I can make the packet parsing stuff no_std.
    So at least that part can then be used in bare metal embedded projects.
    robomancer-or
    @robomancer-or
    that'd be pretty sweet, I imagine a lot of sACN users are using microcontrollers/arm chips
    Lukas Schmierer
    @lschmierer
    @robomancer-or liballoc cannot be used on Cortex M, right?
    robomancer-or
    @robomancer-or
    right, dynamic memory allocation in general is a no no
    Rick Russell
    @macoss
    I plan on using this library on Raspberry PI 3. It works currently and the performance seems to be pretty good. I have been looking at using Tokio with sysfs-gpio for integration of button controls. I still have not gotten my head around Tokio over all.
    Rick Russell
    @macoss
    Has there been any thought to adding a send loop in a thread to the library? I know that most sACN gateways have a time out and they require a that packets be resent every so often. I have seen anywhere from 3 packets per second to 100. Or should this be handled by the calling program?
    Lukas Schmierer
    @lschmierer
    I think that this is something that can be handled in the application using the crate easily. When sACN is using tokio at some point, that wouldn't even require a new a thread.
    As sysfs-gpio is also built on tokio, that would actually play pretty well together for your use case, I guess.
    Lukas Schmierer
    @lschmierer
    @macoss Since the last time I worked on this lib (2 years ago), some things were added to the E1.31 standard. Among other things, some kind of synchronization packets and universe discovery packages which should be sent on a fixed interval. So, a send loop as you have suggested might indeed be in scope of this library. The standard even gives advice on reasonable transmission rates.
    @robomancer-or I have started working on no std packets on branch no_std_packets.
    https://github.com/lschmierer/sacn/blob/no_std_packets/src/packet.rs
    Lukas Schmierer
    @lschmierer
    Corresponding pull request lschmierer/sacn#13.
    Rick Russell
    @macoss
    I’m going to have to read through that spec. I do think it will be cleaner have loop in the library.
    Rick Russell
    @macoss
    We should also look at add unicast support for the library. I have a few instances where it would be nice to have the controler on a different network then the gateway.
    Lukas Schmierer
    @lschmierer
    You can multicast to different subnets. The TTL tells how many hops the packet should be forwarded. However, unicast is part of the standard, too.
    Lukas Schmierer
    @lschmierer
    @macoss @robomancer-or I have reimplemented the packing of Data packets.
    Maybe you can have look and tell what you think.
    I ran into some issue with the PDU lengths. For the test (at the bottom of the file), I used a sample packet, which is given at the end of the E1-31-2016 specification. However, the length fields in the sample packets seem to be wrong (or there is an error with my implementation).
    It would probably help if another person would have a look at it.
    robomancer-or
    @robomancer-or
    I wish I could help, but I'm still at the "hello world" aka "blink an led" stage of learning rust
    Rick Russell
    @macoss
    @lschmierer I’m pretty much at the same stage as @robomancer-or, but I’m going to dig into this today and at least ask some dumb questions 😁
    Lukas Schmierer
    @lschmierer
    Okay sounds great 😁
    You can find the standard here by the way: http://tsp.esta.org/tsp/documents/published_docs.php
    robomancer-or
    @robomancer-or
    awesome, thanks!!
    Rick Russell
    @macoss
    @lschmierer I was looking through the specification and compairing it to the example packet and I think you have implemented it correctly. Seems like the sample packet has some errors in the length calculations based on how I’m reading the specification. Over all I think the code make since to me. Only thing that doesn’t feel right to me is the hard coded values in the len() functions. I don’t think it will cause issues, just not sure it is clear as to why those values are there.
    Lukas Schmierer
    @lschmierer
    Hmm okay thanks, I might add some documentation there so it is clear how the values are calculated.
    I've just implemented parsing of data packets btw.
    Lukas Schmierer
    @lschmierer
    @macoss I've added some documentation on how the lengths are calculated. https://github.com/lschmierer/sacn/pull/13/commits/9d03504527279247c69e97c31fa4abf723fb9486
    Lukas Schmierer
    @lschmierer
    @macoss @robomancer-or Packing and parsing of all packet types is implemented now.
    It is a little annoying that parsing a packet will always take about 1kB stack space. But without dynamic memory allocation, I see no way to avoid that.
    Lukas Schmierer
    @lschmierer
    I changed it so that heap allocation is used if std is available
    Lukas Schmierer
    @lschmierer
    @/all maybe somebody can have a look again lschmierer/sacn#13
    If its fine, I can merge and publish a new version to crates.io.
    Next step is probably reimplementing the DmxSource part (which is not in such a nice shape atm.).
    robomancer-or
    @robomancer-or
    I spent the weekend diving headlong into rust, I'm a lot better now, I'll check that out tonight
    Lukas Schmierer
    @lschmierer
    @robomancer-or cool, tanks :)
    robomancer-or
    @robomancer-or
    so, last night turned into girlfriend time, but I remain hopeful for looking at your thing, hopefully tonight X-)
    Lukas Schmierer
    @lschmierer
    no stress
    Lukas Schmierer
    @lschmierer
    finally merged and publisher to crates as 0.3.0