jamesmunns

I think they actually ended up hiring a couple folks (2-3?) from the open source project. Pretty awesome to see them supporting existing work!

Just wanted to +1 this, I did fill out the survey, but was a little disappointed to end up at a payment screen. Totally understand this is a service worth paying for, but being able to try it out for a bit before entering payment details would be nice.

I know I could hit cancel, but I am often bad at doing that on time, which leads me to avoid trying out things that require payment details up-front.

Thanks for sharing!

This is a very good article, but it should probably have (2017) in the title.

It also reminds me of techniques that I've seen for inserting coverage instrumentation.

Use nops (or other placeholders to insert "counter increment" fills) on instrumented runs, e.g. in test, that way you don't have to modify the "production" code to measure test coverage.

At least in rust, the fixed crate[0] is probably the standard for this. Personally I chose not to use it because integer generics in rust are not quite powerful enough to express this without falling to type system hacks, at least in the stable version of the compiler.

However in C++, you might be able to mimic the API more clearly, as templating is able to do integer things that Rust can't yet easily today.

[0]: https://docs.rs/fixed/latest/fixed/

Thanks! That's cool to know.

I did my error calculations by brute forcing the whole 16-bit range, basically:

    for i in (i16::MIN..=i16::MAX) {
        let a = (i as f32).sin() as i16;
        let b = lut_sin(i);
        let diff = abs_diff(a, b);
    }

Which found the largest difference to be 4, and I got 0.012% from (4/32768).

That's totally fair! In fact, this device DOES have a floating point unit, but for some reason, even lossy approximations of trig functions were much slower than I wanted.

Since the LUT was constant, doing it quickly on my PC made sense, but for a more dynamic approach, that would make sense too.

Likely! But as mentioned in my top level comment, performance was the key metric I was going for here :)

I sort of disagree that this isn't clear, but maybe Rust has warped my brain! I did try and comment my intent along the way, but if anything was unclear, I'd be happy to explain.

Thanks! I appreciate the kind words.

Mentioned more details about this in a top level comment - but the total LUT is small (256 * 2 = 512 bytes), so I didn't 1/4 it because that would introduce more per-cycle cost (to do the rotation), to save a few hundred bytes. This was an okay tradeoff for me, but this might be a bigger deal for larger LUTs, or more precise values than 16-bit PCM samples.

Additionally my error max was already enough, where adding 4x the LUT precision would be diminishing returns for my application.

Oh hey! Author of the blog post here.

So, in this case (on a tiny microcontroller, not precision equipment), my main optimization factor was speed over everything else. I don't think this is a universal answer, and as other commenters have mentioned, there are other ways to approach this problem!

As to a couple of common questions:

    * Why didn't I just use a 1/4 sine LUT? - Because the full sine lut was only 512 bytes, and I had that to spare, which saves me some math per-cycle. I would also hit diminishing returns on a more precise LUT.
    * Why didn't I use (some other method)? This one was "good enough", only took 22 CPU cycles per iteration, and linear interpolation was only 5 or so of those 22. Alternatively: I am bad at complex math! But I have worked with fixed point algos before, so I wrote what I knew.

Happy to answer any other questions!

The last time his "I want off" article was reposted[0], the comments were pretty rough, ranging from ad-hom attacks to (at best) misunderstandings of the arguments he was making.

I see this article being an address to these criticisms (which are not limited to this forum, I've seen similar arguments on twitter, etc.).

Pointing out shortcomings isn't really impolite or unfair. The author specifically mentioned shortcomings of Rust as well.

[0]: https://news.ycombinator.com/item?id=31191700

Fairphone’s entire line

Since the article hid it way down at the end: He was allergic to a certain chemical that is commonly found in lots of scents and cleaners and things, specifically a chemical found in the air freshener at his office.

Asked work to change it, they did, no more reaction.

Edit: the chemical was "Methylisothiazolinone"

Unifi routers do this, for sure.

This is just a really clearly written introduction of a lot of rocket engine concepts.

It was a super good read.

Hooooooly cow. Those on-screen hints are amazing. I've never learned tmux commands, and this reminds me of everything I liked about `nano`.

I might rebind my i3 keys to match these bindings somehow.

Hey! James from Ferrous here. I'm super excited to see the work Fabien has done here wrt the bbqueue algorithm, and pretty excited to see Rust + Ada/Spark working together to build more reliable libraries and tools for both ecosystems :).

I definitely want to give credit to Andrea Lattuada [1] from the Systems group at ETH Zurich, who I worked with to design the algorithm behind bbqueue, as well as Simon Cooke [2], the original author of the bip-buffer algorithm we based bbqueue on (with some thread-safe changes).

Happy to answer any questions (though my knowledge of Ada/Spark is limited), especially on the algorithm or the Rust implementation. I use it super often for embedded systems, and it also allows for ridiculous performance even on PC/Desktop/Server systems.

[1]: https://twitter.com/utaal [2]: https://twitter.com/FleetingShadow

Hey! I got to chat with Bryan Cantrill of Oxide Computer to discuss the more recent explosion of open source hardware, Ferrous Systems' and Oxide Computer's experience with Embedded Rust, the importance of a culture of sharing knowledge, and the joy of fixing hard-to-diagnose systems problems.

Let me know if you have any questions!

I actually really like DO spaces, I use it for hosting a small audio podcast. One downside is they give you NO way to see your bandwidth usage, other than seeing whether you got a bill overage or not. It was pretty surprising to me that they HAVE the information for billing, but don't expose it to the user of spaces in any way.

As a note, you can click on the time stamp of the child post, and respond directly there.

> since I can't reply to the child I'll just say this: I don't like the math you used, I feel like it's making a point that shouldn't be made in a place where it doesn't need to be made. Of course it's going to be dog slow if you're busy waiting. Wtf? I guess I will just leave it at that.

The entire post is about reducing the CPU time necessary to receive data from an external interface, like a serial port. The following paragraph states:

> Instead of making our CPU waste all of this time waiting around, we allow the hardware to manage the simple sending and receiving process, allowing our CPU to either process other important tasks, or go into sleep mode, saving power or battery life.

The intent for this example was to illustrate the difference between busy waiting and DMA. It is not uncommon on microcontrollers to only have a FIFO depth of one byte, which means if you aren't using interrupts, DMA, or threading, you will lose that data.

The comparison that I was aiming to make was comparing a "busy wait blocking" implementation, e.g. sending one byte at a time, until the byte has been sent, which is typical for bare metal embedded systems (that don't use some kind of DMA or concurrency like threads or tasks).

In this case, your CPU would be left spinning for an equivalent amount of time to the line rate of the serial port, if you were busy waiting for data.

Hello, I am also the author of that post and implementor of bbqueue. I agree, I'd be interested in what you think I have misunderstood.

Feel free to reply here (preferred), or send me an email at james.munns [at] ferrous-systems.com.

Interesting! Is this work public somewhere perhaps?

I'm currently working on a similar technique (though with smaller blocks, currently ranging 64-1024 bytes - basically any 5 power-of-twos) for a lock-free allocator intended for real time embedded systems. I use a 32-bit word for each 1024 byte "page", and have a tree structure inside of the word (it takes 31 bits to cover 5 power-of-two ranges).

My code (which only allocs and never frees at the moment) is here:

https://github.com/jamesmunns/bitpool/

Yup! In Rust specifically, I've written bbqueue, which is a bipbuffer-inspired lock-free ring buffer, intended for embedded systems and DMA usage.

https://github.com/jamesmunns/bbqueue

It uses atomics (and Rust's borrow checker) heavily to safely guarantee lock free behavior, and works pretty darn quick.

So, there's language support for it, but it'll still be necessary to have driver support, ideally a whole support library in Rust.

Most BLE or WiFi enabled microcontrollers have a binary blob for driving connectivity, or deeply C based code that can be a challenge to integrate idiomatically in Rust.

I've also seen a number of people following along in this book in other languages, including Rust. It really is a well written guide, even if you're not fluent in Ruby.

Just a turn of phrase. I suppose non-goal is more accurate, but as my day job is building embedded systems in Rust, sometimes it's good to strongly remind myself to keep hobby and work time separate.

Hey, author here! I definitely think the communication protocol is the special sauce here :).

I am to focus on this in a couple different ways, largely based on either a pub/sub style format for smaller periodic messages, or on a mailbox style format for larger messages (display frames, etc).

I'm still pretty early in the brainstorming process, and this is intended as a hobby/teaching project, but I'd love to have things be useful for everyone using it, and having compatibility APIs are a big way of achieving that.