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.
Great post! Machine learning definitely has a lot of potential to assist in medical diagnostics, and with all the training data coming out, it's a field ripe for innovation.
I work at Innolitics, and we do a lot of work with machine learning in the medical imaging space. We've honed in on a set of tools that works well for us; I thought it might be worth sharing in case anyone else is wanting to explore this space in light of COVID.
The referenced UC San Diego dataset has its images stored as PNGs, but if anyone is interested in doing more ML work with medical images, you'll probably find most of them in the DICOM file format. I can highly recommend using the dicom-numpy library for easy conversion of DICOM files into numpy arrays: https://github.com/innolitics/dicom-numpy. For more general example datasets saved in the DICOM format, The Cancer Imaging Archive is always an excellent resource: https://www.cancerimagingarchive.net/collections/
Another advantage of using DICOM files is that there's lots of metadata you can extract from each file to train on a wider clinical context. The PyDicom library makes that very straightforward: https://github.com/pydicom/pydicom
The Python + PyDicom + Keras or PyTorch stack is really powerful and easy to get started with. We use it at Innolitics frequently and put together some tutorial articles to demonstrate how to get started: https://innolitics.com/articles/ct-slice-localizer/
I'm excited to see more projects like this! More data and improved tools are only going to improve our ability to gain new insights into COVID.
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! Sorry about the lack of material on the blog, I set it up about last week so I haven't had a chance to post too much yet. The code for the project is open source, hosted at https://github.com/ReeceStevens/patient-monitor. Look for a new blog post coming up this week with a lot more background about the project. I also have blogged about my work in developing world hospitals that led up to this project; that info is at http://www.reecestevens.svbtle.com.
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.