4 ms·

You reference a blog post on your Github (regarding the algo description). I believe the author of that blog (someone at Ferrous Systems) has a pretty signific

You reference a blog post on your Github (regarding the algo description). I believe the author of that blog (someone at Ferrous Systems) has a pretty significant misunderstanding of DMA and serial ports, which raises a whole host of other questions on down the chain <additional unnecessary comment removed>. edit: I know it's not cool to complain about downvotes, but this is a legitimate concern to raise for this poster. I am not attempting to denigrate anyone here.

twic 6y ago
I assume you mean this blog post: https://ferrous-systems.com/blog/lock-free-ring-buffer/ https://ferrous-systems.com/blog/lock-free-ring-buffer/ Could you explain what you think the misunderstanding is, and what the consequences of that misunderstanding are?
- deleted 6y ago
  [deleted]
- caspper69 6y ago
  edit3: resolved below.
  - jamesmunns 6y ago
    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.
  - jamesmunns 6y ago
    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.
    - caspper69 6y ago
      Thanks for the heads up on the reply. And this is why I shouldn't critique year old blog posts before 6am, lol. I still don't care for the way that section was phrased, but I have a rather pedantic background in telephony and serial ports. My apologies.
jamesmunns 6y ago
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.
ngcc_hk 6y ago
Some people waiting for your response. Please.

twic 6y ago

I assume you mean this blog post: https://ferrous-systems.com/blog/lock-free-ring-buffer/ https://ferrous-systems.com/blog/lock-free-ring-buffer/ Could you explain what you think the misunderstanding is, and what the consequences of that misunderstanding are?

deleted 6y ago
[deleted]
caspper69 6y ago
edit3: resolved below.
- jamesmunns 6y ago
  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.
- jamesmunns 6y ago
  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.
  - caspper69 6y ago
    Thanks for the heads up on the reply. And this is why I shouldn't critique year old blog posts before 6am, lol. I still don't care for the way that section was phrased, but I have a rather pedantic background in telephony and serial ports. My apologies.

jamesmunns 6y ago

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.

ngcc_hk 6y ago

Some people waiting for your response. Please.