rstevens24

Hey, thanks! I appreciate the post :)

In my case, I don't believe I had any GCC-only restrictions for the STM32F4 chip I was developing on, so I didn't ever run into this issue.

That being said, it's always worth experimenting with flags in YCM or clangd to see if you can get something working well enough for most development needs. I would take a look at the places where those `#ifdef GCC` macros are used and see if you can spoof the flags enough to get something workable. Throwing a `-DGCC` in your YCM flags, worst case scenario, will just raise an error message and you can remove it. Best case scenario, it won't behave quite the same as GCC but you can get basic linting, autocomplete etc. working. Sometimes this stuff requires a bit of exploration to get working the first time, but once you get a working setup it's very satisfying!

haha, indeed I was quite late to the party in discovering the power of these tools :) In a way though, the fact that a college student in 2016 can get excited about the possibilities of vi and make speak volumes to how influential a well-designed software tool can be!

Author here. Wow, I wrote this article back in college and I was really surprised to see it up here on HN! Pretty cool to see so many talented embedded folks reading my "write to learn" piece :)

This blog post was the start of me figuring out the love of diving in deep to embedded development. Since then, I built a patient monitor device using this makefile-driven build approach. Nowadays, I am re-writing this device using embedded Rust. It has been such a great experience watching the embedded Rust space grow and mature over the years; it wasn't the case several years ago, but now I can build a complex embedded system using stable Rust! I've even got on-device unit tests working, and it's still the same terminal-driven, vim-based workflow I've gotten so familiar with.

dicom-numpy's biggest advantage is that it combines individual slices into a single 3D numpy volume. This makes it really easy to immediately jump in to performing operations at the volume level rather than the slice level. It also performs some sanity checks for you, such as checking for missing slices or uneven slice spacing.

For me, I've also found dicom-numpy useful for returning the ijk-to-xyz affine transformation matrix, which describes how the voxels are oriented in patient coordinate space. dicom-numpy builds on top of PyDicom, so they are definitely not mutually exclusive! We use them both extensively.

Just wanted to say thanks so much for your blog posts! I have been working on a medical device in no_std Rust and your articles have been super helpful in setting up a robust unit test suite. I have been trying to hack at the utest crate and get on-device integration tests running again for quite some time... good to know there is movement on the custom test runner front :)

Hey jrnichols! The device measures 3-lead ECG and has semi-automatic NIBP; the user pumps the cuff up to max pressure with a hand pump, but the pressure is measured and released automatically by the device.

Truth. Also, with the way insurance works here, it's actually more cost effective for companies to make a more expensive device. If you're selling for a US market, you lose money by making your prices competitive

Will be making a blog post at reecestevens.me/blog about this very soon (within the week), so check back around Friday and I'll be able to give you a more fleshed-out response (with pictures!)

Hey adrianN, creator of the project here. "For use in developing world environments" means built to perform to hospital specifications but without the cost markup or over-the-top complexity of a developed world piece of equipment. I've spent about four months working in hospitals in Rwanda and Nepal fixing donated "developed world" medical devices, and the fact of the matter is that 35% break within a year of donation and 95% within 5 years. This project is built so that it is easily maintainable, easily repairable, works out-of-the-box, and is at a price point that developing world hospitals can afford to purchase with their budgets (~200-300 USD, according to my sources in Rwanda). Also, most developing world hospitals have a very high nurse turnover rate, making it critical to make the device simple enough to be used by staff who haven't been trained yet.