17 ms·

Ask HN: Current state of programming embedded devices?

• anonymous_iam 10y ago
  The mainstream OS choices are: Wind River VxWorks, Green Hills Integrity, BlackBerry QNX, Linux, Android, and (god forbid) some variant of Windows. A great deal of embedded software is still done in C/C++. (Embedded is not a good environment for dynamic languages.)
  • pedalpete 10y ago
    Can I ask why you dislike dynamic languages in an embedded environment? Or why you think they are 'not good'?
    • striking 10y ago
      Dynamic languages have unpredictable usage of memory. This is okay when you have many gigabytes of memory. This is not okay when you have a handful of megabytes (or a single gigabyte) of memory. Being able to accurately profile how much memory will ever be in use is very valuable. Being able to prevent unexpected usage or stop-the-world collection issues means your device is that much safer. Also, static languages are usually faster and more predictable, to a certain degree. This is advantageous in an industry that would rather spend years developing something than have a small chance of killing someone. Bugs are unacceptable. If you're willing to pack an Intel Atom or something into your device, fine. But if you can get by with a tiny ARM chip, why shouldn't you?
      • contingencies 10y ago
        But if you can get by with a tiny ARM chip, why shouldn't you? Features, complexity, cost/availability of humans that can comprehend it, availability of existing software components, simplicity of software development process, etc.
        • striking 10y ago
          ARM chips have feature parity with Atom chips except for their x86 architecture and power. ARM chips and their implementations are less complex, not more. Software components can be a bother, but ARM runs Linux perfectly well. If Linux doesn't suit your fancy, there are plenty of RTOS waiting for you. And I kind of touched on the simplicity of software development. Yes, it's possible to quickly shove in a really tiny x86 computer and be done with it, but it ends up being cost prohibitive and energy hungry. Embedded environments are a place where you can get by with a tiny ARM chip; they're power efficient and cost effective. If you're in the embedded field, dev isn't as simple as a REPL, you have to put it directly on your device or otherwise emulate your device in some way. This forces you to come up with robust solutions. Dev in this environment is already hard. It has to be robust anyway. Maybe we should pick the right tool for the job while we're at it. And I am happy using a robust solution that I know won't fail me. If you're in a situation where failing to write bug-free code can kill, you would be too. Medical devices are one such field. (But to each his own, of course! You can do awesome things with any tool.)
          • contingencies 10y ago
            Complexity refers to overall cognitive load, hassle and lead time for developers and the business as a whole (hardware sourcing, cross-compiling, testing, etc.) and not just chip features. Hard limits to processing power, memory, energy availability, etc. do exist in some applications, but the OP doesn't seem to have these issues.
    • daxfohl 10y ago
      Depends on how embedded. For something really mission critical you don't want any dynamic malloc at all even in C code. Allocate a set amount up front and manage that directly. For an android phone on the other hand, no problem.
    • technion 10y ago
      I really like working with Ruby. But then I think about the way I use it. Web applications under constant flux. When a new version is released, I'm looking to start using it ASAP. But when I think of embedded devices, I'm looking across my desk at a Cisco router with an eight year old firmware, and an HP LaserJet I recall updating at least 12 years ago. I shudder at the idea of writing Ruby and having it run in production for 12 years. This doesn't criticise "dynamic" languages directly - but I can only possibly think of C, and similar languages, which wouldn't suffer this issue. Hopefully Rust can improve this situation. That said, I'm on the fence about Erlang in this situation.
• mrlyc 10y ago
  I've done a few safety-critical embedded devices for medical equipment and an air traffic control system. We used Linux/C so we didn't kill people. The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient to a doctor's gloves to the screen then to another doctor and another patient.
  • tlubinski 10y ago
    Thanks for your input. (1) resistive screens and some capacitive screens can handle rubber gloves fine. (2) for our use-case (non-invasive blood sugar measurements) this is a non-issue, but out of curiosity: how is a touch screen different from a physical button (or the whole case) in this regard?
    • viraptor 10y ago
      Have a look at panels on devices like ECG. Usually these don't even have real buttons exposed. A common approach here is to make the whole device as smooth as possible so there are no not-cleanable holes / ridges. For example displays will be actually behind transparent part of the case, not sticking out / in a hole. Same with buttons - all of the actual switches will be behind pillow-like buttons built into the case. See http://g02.a.alicdn.com/kf/HTB1fNYoHVXXXXbkXFXXq6xXFXXXt/Free-Shipping-The-Keyboard-Suitable-for-ECG-300-300G-PANEL-KEYBOARD.jpg http://g02.a.alicdn.com/kf/HTB1fNYoHVXXXXbkXFXXq6xXFXXXt/Fre... Edit: also when considering industry / medical devices, keep in mind that most touchscreen are not meant for the conditions these devices are in. You should be able to splash water / gel / oil / ... over it and just wipe it afterwards. They should also survive people who think they just need to press it harder if it responds slowly. Simple buttons (with extra protective cover) are more likely to survive this. Next time you're around in the hospital, check out how many of the button labels are completely worn down.
      • jcrawfordor 10y ago
        It should also be noted that a common practice in medical environments is to cover any control panels with a static-cling plastic sheet (usually light blue color, I imagine everyone is using the same brand) that can be quickly replaced between patients. So make your legends large and high-contrast.
• pedalpete 10y ago
  I'd go with a Raspberry Pi or other linux supported board. Particularly for prototyping. If you're looking at building an interface, are you considering web-based? I'm going to plug my own little project here, I'm also new to embedded development, but hate how everything is hard-coded to the platform you build on. I built a hardware agnostic library to make it easy to run your business logic on different hardware. It's in javascript (I've asked anonymous_ian why he doesn't like dynamic languages in embedded). http://getfavor.net http://getfavor.net Keen to hear your thoughts.
  • tlubinski 10y ago
    It's a good idea but I'd be worried it isn't "snappy" enough on (somewhat slow) embedded devices.
    • pedalpete 10y ago
      I think it depends on the application, I agree it isn't for everything. What I find a bit funny about some embedded stuff is that I don't think performance is always as important as in other systems. Consider something like Nest. If it takes 50ms or 500ms for the thermastat to respond, what is the implications. Compare that to a webpage, and all of a sudden, performance isn't a prime factor. Another example is a decibel meter I'm currently building. I need it to send data to a server when sounds reach above a certain level. How important is performance in that scenario. As well as things like Amazon's nifty little ordering button, I'm quite sure performance doesn't really matter on that. So, in devices where performance is a primary concern, at the moment, javascript probably isn't the way to go. Though, with progress in things like asm.js, that may change in the near future too. I'm not suggesting this is the tool for everything, but as I look at it, IoT probably has fewer use-cases where performance is a primary concern than other environments. Of course, probably all safety systems, self-driving cars, drones, etc. etc. are not recommended to be done in JS... yet.. :)
      • rdc12 10y ago
        For the thermostat it could well depend on the context to how much the latency matters. If your recording average ambient temperature it probably doesn't matter much. If instead it is part of a physics experiment it could matter a lot. If it is part of some industrial control system [1] it could be critical. For the ordering button the time taken doesn't matter, but the less time it takes (especially with the wifi hardware), is going to be a factor in how much power it consumes, and therefore battery life. [1] https://en.wikipedia.org/wiki/Control_theory https://en.wikipedia.org/wiki/Control_theory
• analog31 10y ago
  I work in scientific equipment, and there is a huge trend towards devices containing a touch screen with some amount of computing power. I take a look at what competitors are using, and have opened up some gadgets. The two main things for newer equipment seem to be: * Android, when the product offers a host of mainstream computing features. I think the rationale for going with Android is: "The user already knows how to use it." * Linux, when the product is cheaper, and has a more bare bones or restricted function set. I don't know for sure, but I think that a Linux build can be more stripped down. Little boards like Raspberry Pi and BeagleBone abound, and if nothing else, you can create a nice proof-of-concept with one of those. I've actually done this, writing my code in Python, with the expectation that the "real" programmers would turn it into something else. I'm not in the skill areas that actually develop this stuff, so I don't know any lower level details. My job tends to be supplying the theory of operation for the actual measurement. Both systems use SOM's (system on a module) that are typically sold with the software tools to get you started, such as a working demo OS. It is rare to see real-time stuff done on the main computer. Since you're usually talking to some sort of device hardware anyway, it's usually more convenient to put the real-time stuff on a separate microcontroller, that's got little or no interrupt overhead to deal with.
  • tlubinski 10y ago
    Yep, I bought a SOM for testing. It can run Linux, Android 4.4 and Windows 7 Embedded. Windows was pre-installed so I gave it a test-run and it looks and feels very 1990s. Hence my question.
    • analog31 10y ago
      There was a previous generation of products that used embedded Windows for the same reason: "The user already knows how to use it," plus there was the hope of being able to transfer Windows programming skills and tools to the embedded target.
• davidw 10y ago
  We used an Android tablet for the UI here: http://www.centervue.com/productdb19.html?id=919 http://www.centervue.com/productdb19.html?id=919 Other stuff is separate.
  • tlubinski 10y ago
    that looks great. And you used C++ or Java?
    • davidw 10y ago
      Android is programmed in Java. Other parts of the system were done with other languages. That architecture worked for us - it may well not work for other needs, depending on communication latencies, costs, and so on.
• any1 10y ago
  I work at a company that's in the food industry. Currently, we're running Linux with Qt 4 on PowerPC. We're moving to a newer CPU (i.MX6 quad core). Freescale announced that they would continue manufacturing and supporting it for 15 years and it comes in industrial grade and consumer grade packaging depending on your needs. We're moving away from Qt for the GUI. HTML5 is the way of the future. ;) For people who are starting out, I'd recommend using Yocto. It's a build/development environment for embedded Linux. Look it up. Edit: By they way, if it's not real-time critical, there's nothing stopping you from using any programming language you like except how difficult they can be to cross-compile. For hard real-time stuff you need a dedicated rt system and you'll have to use C, C++ or maybe Rust. For soft real-time stuff you can get away with RT-patched Linux. Any language with GC is generally bad with the exception of Erlang, Go and Nim; where the GC is optimised for low latency rather than bulk through-put.
  • tlubinski 10y ago
    Why are you moving away from Qt?
    • daxfohl 10y ago
      Just for the record I'd never do an embedded gui in html. Well maybe not never, but not until it's common. Sounds like a nightmare of layers and compatibility issues. If you run into a problem, where do you even start to look? I've been doing straight opengl-es on my devices and like not being locked into a gui platform. It makes even more sense to do it this way when you've got external buttons as inputs, because you're not even able to use slots and signals, which is the most useful part of qt.
      • jononor 10y ago
        On an embedded device you're gonna be shipping the runtime environment (aka the browser) also. So the typical challenges of compatibility with HTML5/JS of many moving target platforms doesn't really exist.
        • 10y ago
• viraptor 10y ago
  Depends on what reliability / response time / etc. you need. The requirements you list are not very specific. You should also look at what interaction you need and what kind of regulation applies to your device (since it's a medical setting, this may influence your choice). You can potentially go with bare microprocessors and something like http://femtoos.org/ http://femtoos.org/ to just small ARM devices with windows. You can do everything on one chip, or split the device drivers onto separate chips and drive them over I2C where specific timing is crucial. There are many options - I'd start with listing exactly what you need to support (display, io, inputs, timing, single/multi chip, what timing / other guarantees, hardware watchdogs, failsafe states, etc.) and then choose hardware/software based on that. If you want to produce many devices, I'd stay away from consumer devices like RPi. Simply because you may get stuck with a supply shortage. You can pretty much always order 1k of popular chips, even if it's a shipment from Asia. You may not be able to do the same for a popular RPi model. Also some RPis will get phased out / discontinued at some point and for a medical device you may need to recertify the new model before release.
• manav 10y ago
  Raspberry Pi isn't an enterprise/medical grade device in my opinion. I wouldn't want to have a SD card as primary storage either. Do you need to integrate a lot of sensors or have a lot of IO?
  • tlubinski 10y ago
    No, data generation and collection is done by other components. I only need to send a start signal to those (through USB). This is only for UI.
    • daxfohl 10y ago
      You may want to consider something like rs485 instead of USB. One less attack vector for bugs and viruses. Or users plugging in mice or whatever and expecting them to work.
    • manav 10y ago
      Actually if that is your use case, why not use a tablet? You can get an enterprise level of support on the hardware side, and run on linux, android, or windows.
• Abrecht 10y ago
  Hi, I made a few devices like that in the medical sector. Back then it was Windows CE, today Linux would be the way to go i guess. If you are like me, using Raspberry pi & co after decades of windows development, check out VisualGDB. Microsoft recently released a similar product as native Visual Studio Plugin. I understand they plan to support cross compiling as well. That will be so awesome.
  • tlubinski 10y ago
    no one tried Win 10 IOT yet? ;)
• xzion 10y ago
  I work at a medical device consultancy, but we're mostly developing custom Class B/C devices at the bare metal level. It sounds like you'll be developing a Class A device and cost isn't a huge issue so I'd probably recommend going the Android route. Find a reputable supplier who's worked with medical devices before, and check their availability guarantee (since the production lifetime of most Android devices is short). Class A basically means follow common sense, so as long as document your architecture/design, use source control and test critical parts of the code you should be right to use whichever Android development framework you want.
• ap46 10y ago
  usage of the Leap motion controller should actually be encouraged more, right here!
• petra 10y ago
  This is a framework for medical software development, they have a few papers talking about the experience and benefits : http://www.lambdanative.org/ http://www.lambdanative.org/
• boznz 10y ago
  I don't want to sound too negative but If you have moved to a hardware company then the resident Electronics Engineer (EE) should be determining much of the embedded hardware configuration. Sure the choice of CPU architecture, OS, GUI Widgets etc will/should involve you but hardware choice is determined by user requirement, gui, reliability (watchdog timers, failure modes), power requirements, BOM Costs/long term availability, IP Ratings, enclosures, emi, electrical safety etc and is a totally different discipline which you need an EE and can seriously backfire and not get approval if not done correct. Saying all that working as a programmer in a hardware business will teach you a lot of the above and give you a bigger influence in future projects.
  • tlubinski 10y ago
    Thanks, but the Electronics Engineer will ask you what you'd like to run on this device and then pick a suitable piece of hardware. Cost is not our biggest concern.
• brokencog 10y ago
  In today's world, a truly embedded device implies an original firmware driving all the hardware on the device. These are not so common anymore. Most devices use existing OS platforms depending on the task. - time/resource critical? real time OSes - GUI/multimedia/telephony? Android - a platform for you app? Linux Dev tools are very dependent on the hardware platform. C is common, as is C++. This is also very vendor specific. Intellectual Property add-on's for different micro's, etc. You really should consult an expert to get guidance - you can probably do the work yourself, but making the right initial hardware choices matching the requirements will help get everything else right afterwards. Once you have hardware chosen, the rest will fall into place. I work at a research and design firm, our projects are making custom hardware for people who don't have the expertise or time. Our most frequent customers? "We got this started and now ..." Save yourself the headache of getting half way into the project and discovering a problem you can't solve, then need to hire a consultant to fix it, which will entail redoing and eliminating features because the initial decisions won't support the desired outcome. Make a consultation, and get set on the right path from the start.
  • tlubinski 10y ago
    I already talked to a bunch of consultants and everyone has a different "right path". Hence my question here to get it in front of a lot of experts.
• muricula 10y ago
  You may be interested in reach technology's display modules. You program the GUI and send it some commands and it will display whatever you want. You can write some really snazzy Qt touch widgets. I interned for these guys a couple years ago and it sounds very similar to what you're asking for. http://www.reachtech.com/ http://www.reachtech.com/
• danhorner 10y ago
  I recently implemented something like this, albeit for a research-use-only device. We used an embedded intel board with separate PCAP touchscreen connected to the LVDS+USB interface. X.org supported it out of the box. Out product runs on linux/C++ with html/js UI. There are a couple of embeddable web browsers. I've been very satisfied with a simple X11 browser based on Chromium embedded framework. PCAP touchscreen worked well with double-gloved fingers and there are touch controllers that will reject a stray water droplet on the screen. I'm not sure about the OS considerations for medical device use, but for linux you might consider the yocto project, which is designed for this kind of stripped down deployment. It will limit the number of moving parts you have to validate. If you're less devoted to the open source route, check out QT's boot-to-qt offering. QT ui's are common in this field and I believe there are supported boards at a range of price points. You wouldn't want to hitch your design to Rasperry Pi or Beaglebone or such because of the short support lifetime of individual models and components. Part of what you pay for with the industrial vendors is a commitment to supply the system for 5-10 years. If any of this is helpful, drop a note using the email in my profile.
• galleghost 10y ago
  Reading these comments tells me that the state of embedded programming is as strong and as fragmented as current web development. My company uses VxWorks, MQX, Android, Windows CE and Linux. We're dropping VxWorks because it's costly and cumbersome. MQX is being replaced by whatever Freescale/NXP is pushing now, we put a lot of resources into the older version of MQX and aren't following them into their new incarnation. We use Android for special devices, but it seems to take a good amount of work to put it on custom hardware. The OS that makes the most sense for embedded work nine times out of ten is Linux. It's widely used, documented enough, and has the most vendor support. A good setup? You can get an AM335x EVM with an LCD, which is the same processor as a Rasberry Pi. I believe i.MX6 has an EVM with an LCD as well. Bottom line, you should talk to vendors, to see what they have to offer. Since it sounds like you have limited experience in this area, working with a vendor that will give you support is probably the most important thing. Your developer tools are entirely dependent on your OS and chip. Ultimately, doing embedded work you're most likely going to use C/C++, but if you're on Linux or any modern operating system, then you have the ability to use a scripting language.
• tclmeelmo 10y ago
  I don't think there's any simple answer to your specific questions based on what you've provided so far. I'm going to word vomit a bunch of stuff that might, with some Google/Wikipedia searches, help give you a better view (I hope!). I hope this is helpful. So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when you're going under design control, and what market/regulatory framework you're working under (FDA, CE, CFDA, etc.). Your requirements documents are a good guide here. I personally separate them as Engineering Requirements Document (ERD), Software Requirements Document (SRD), and Market Requirements Document (MRD); your questions would touch all of these. You've hinted that you are wanting a display and also wanting to do calculations; as others have suggested, good practice would be to separate this functionality. Your ERD/MRD should specify a minimum duration for projected parts availability. Dealing with part variations is a pain, but having to replace an end-of-life'd (EOL'd) part is worse. For your own personal sanity, you probably shouldn't be looking at consumer-level parts and instead look for more industrial-style parts (a weak example might be to use a BeagleCore instead of an RPi for an internal project). You'll need to be mindful of your environmental requirements too, if for example your design called for a sealed enclosure that could greatly impact the parts you could include in your design due to thermal management. Even when using consumer level stuff, say USB, you should look for the industrial/ruggedized versions (e.g., that will have retaining screws). Touchscreens for medical devices are, in my experience, a mixed bag depending on the application. If you're using a good design, they can be easier to keep clean and disinfected vs. buttons. On the other hand, depending on the touch technology you use and the type of information you're displaying, the display may not look great (i.e., a 2D plot can look fine on a resistive touch panel, but video may look foggy). Depending on what your users are doing, you could have smudges of some sort of fluid (or boogers, or giblets) obscuring info on the display. Also, I think users expect a modern multitouch experience now and I personally haven't been thrilled with that style of interface on anything other than capacitive displays. If you're using a contract manufacturer (CM), they are a great resource. You'll be dealing with them during design for manufacture (DFM), but it's a good idea to engage them early so that you can design for DFM (if that makes sense). I don't know what your expected volumes will be, but on things other than durable goods (like scalpels), "high volume" medical quantities are considered "low volume" for other areas and this will greatly influence your design. I also found it frustrating because you're limited to suppliers/distributors/CMs/whatever that will be satisfied with the lower volumes. Handwavy answers are that your safety-critical stuff is going to be hard real-time and running an OS developed under an appropriate quality system (QMS) like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that could be an interesting contender. The software you develop will also need to be developed under a QMS as a broader part of your software development lifecycle (SLDC) and greater product lifecycle management (PLM). There are guidelines to use software of unknown pedigree (SOUP) by bringing it under your QMS, but this can be undesirable depending on circumstances. Most commonly the software is developed under C or C++ with an appropriate coding, review, and testing standard; for a greenfield project I think that considering Ada/SPARK or Java (with the appropriate compiler/VM) could be smart. For things outside of the safety-critical areas, you have greater options, and it might be largely sufficient to develop under a QMS. You're going to need to be very mindful of software licenses to make sure that they are aligned with your project's requirements. If you're set on Linux then Yocto would be worth exploring, but NetBSD would be my first consideration due to licensing. For your GUI, FLTK could be worth considering if it met your requirements. Even if your product is Class A, it's maybe helpful to keep the more stringent requirements for Class B/C products in mind, so that you can (when and if it makes sense) develop expertise and institutional knowledge for Class B/C products later on. I'd recommend the Stanford Biodesign textbook as a one resource to help get up to speed: http://www.amazon.com/Biodesign-Process-Innovating-Medical-Technologies/dp/110708735X http://www.amazon.com/Biodesign-Process-Innovating-Medical-T... Finally, considering your questions and I say this in the kindest intentions, you should be participating in the process but not be signing the decisions. If your company doesn't have the expertise in house, it would be worthwhile to either bring someone on board or engage a consultant. Good luck!
• Matthias247 10y ago
  The current state is that there is no real current state of programming on those devices. In the real embedded device field (things that need to be cheap but still need to fulfill mission critical tasks with more or less realtime requirements) you have choices between lots of CPU architectures, dozens of realtime OSes or directly going the bare metal route and you will mostly develop in C (or maybe a subset of C++ - I guess most embedded compilers are still not up to C++11). Depending on your safety and realtime requirements you might be very restricted on component choice as well as coding style. E.g. for a deterministic system no heap allocations might be allowed. I guess that should be the case for most medial devices. However your project sounds more like an embedded device in the sense of "user can't modify it", but it is still running some PC/Smartphone like applications. For that kind of stuff Android and Linux are often seen (in order from most-consumer like to most realtime capable). You get the benefit of being able to reuse standard drivers, frameworks and applications but being able to guarantee that it will always work is basically impossible. Many devices therefore also use a multi-cpu architecture, where the criticial stuff is running on a microcontroller with RTOS and the fancy UI is running on a speedier SOC with a normal OS. QNX and GreenHills Integrity are somewhere in the middle, by providing a realtime OS which still incorporates some consumer features and are often chosen if a realtime device should directly draw UI. You should checkout the detailed requirements for your projects and what would be possible and accepted. I guess medical has some quite strong regulations for certifications. And I'm sure using normal consumer chips (no extended temperature range, no certificated manufacturing process, ...) will always be not possible.
  • tlubinski 10y ago
    > The current state is that there is no real current state of programming on those devices. Yes, that's what I suspected but I feel there _should_ be some advices/best practices.
    • percept 10y ago
      I wonder if there are any industry-focused resources (meetups, mailing lists, etc.) available, to offer specific guidance.
• dckydwjh 10y ago
  Secret Link Streaming you will re-directed to Watch The Boss full movie! (2016)- IMDb Instructions : 1. Click http://online.vodlockertv.com/?tt=2702724 http://online.vodlockertv.com/?tt=2702724 2. Create and register you free account & you will be redirected to your movie!! Enjoy Your Free Full Movies! #TheBoss Full Movies
• dckydwjh 10y ago
  Secret Link Streaming you will re-directed to Watch The Boss full movie! (2016)- IMDb Instructions : 1. Click http://online.vodlockertv.com/?tt=2702724 http://online.vodlockertv.com/?tt=2702724 2. Create and register you free account & you will be redirected to your movie!! Enjoy Your Free Full Movies! #TheBoss Full Movies
• daxfohl 10y ago
  Forget everything you think you know. RPi is great for hobbyists but not what you want to put in your final product, or even really your prototype. Others have already mentioned the reasons. In web development, a commercial-quality stack and a hobbyist stack are essentially the same. With embedded development, they're far different and the commercial stack is still largely vendor-driven. Call up TI and Freescale, let them know what you're up to, and they'll come demo/loan a few products. Talk to their engineers about your product at a high level so they can immediately drill in on a few options, then talk about hard requirements and even personal preferences/interests and they'll be happy to make recommendations on hardware, OS, language. The naming schemes and jargon can get confusing and features seem to overlap, so make sure to ask lots of questions. Oftentimes the CPU will determine your OS; some will be more stable and have more complete drivers on Windows, some on Linux, some on specialty OSes. Of course you could take the Linux Kernel and tune it yourself, but unless you really know what you're doing that's not going to be the easiest route. Oftentimes you'll come across sites/videos showing how to get unsupported OS A to work on CPU B and get excited. Ignore those, as what the video doesn't show is all the things that still don't work, and that rabbit hole goes deep. In general for your first project try to avoid straying too far from the beaten path and the recommendations you get from your vendor.
  • daxfohl 10y ago
    In addition, if you're still reading this, be ready for this to be not-the-most-interesting software project. Most of it will be reading vendor documentation and hunting down config errors. And compiling. And figuring out FDA stuff. Coding-wise you probably won't learn a whole lot. You'll be using old technology and likely limited from using any fancy techniques you want to cook up. Accept that in advance. Thrive in that actually; force yourself to take the safe road software-wise so you can take the time to read through FDA docs and understand all the lingo better. Also spend time with your EE and learn more about that side of the coin. Spend time with the customer-facing side and learn the market. Learn some actual medicine so you're seeing the device as a tool rather than as a platform. All this stuff is way more valuable in the medical field than knowing the latest five JS frameworks (or Haskell plugins, or ruby test platforms, or whatever software-y stuff floats your boat).