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!
Well if you take suggestions, I personally only use vi over slow links (it shines on high latency connections where a normal editor does your head in with the slooow updates).
Since you're mentioning the arm gcc you probably have access to the likes of jed, nano or even the editor built into mc there.
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.
Did the toolchain you were working on support both GCC and Clang? I ask because I was recently trying to work on a ESP32 project in vim and got stuck hard on YouCompleteMe only using a clangd-based completer while the project was only compileable with a GCC-based toolchain, leading to annoying things like headers not being found due to things like `#if GCC...` (or the like), and also not all cli switches matching up.
Any tips on getting completion working in vim for GCC-only CXX projects is highly appreciated...
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!
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.
What advantage does dicom-numpy offer? I've mostly developed with pydicom for my medical imaging pipeline as it allows me to retain important dicom information (pixel spacing, etc). In fact, the 'PixelArray' attribute returns a numpy matrix that I can then use.
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 :)
It's the first time that I hear about Rust on medical devices. Sounds really interesting! I'm glad to hear that my blog was useful to you!
> 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 :)
The custom test framework feature of Rust was silently introduced in https://github.com/rust-lang/rust/pull/53410 and I didn't know that it even existed a month ago. But it works really well and seems like a good solution for your problem.
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
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.
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!)
