9 ms·
IMO, the biggest problem is software startups unwillingness to hire other types of engineers. It's easy to bridge from Arduino to Atmel AVR IF you know how to
by slackingoff2017 9y ago
IMO, the biggest problem is software startups unwillingness to hire other types of engineers.
It's easy to bridge from Arduino to Atmel AVR IF you know how to do board layout. Startups need to either grow their knowledge of electronics or hire some electrical engineers.
The AVR documentation is excellent, you could easily design your own board if you have anything beyond rudimentary electronics skills.
A lot of IoT startups are dependent on attachment "blades" for interfaces. They get burned because a lot of their value proposition and profit is tied up in some other guy's blade they don't know how to build.
- euyyn 9y agoUnwillingness to hire is related to cost, which is a supply/demand thing. There's many more software engineers around. Layout of high-frequency electronics has many gotchas, and for devices with wireless communication you need to get your design certified too. Getting high-volume discounts as a startup is also hard. I think system-on-module approaches like Samsung's or Android Things' solve those problems, though.
- anonymousDan 9y agoI really don't get the point of Android things. Looking at their website the most constrained device they support is on the order of a raspberry pi. Why wouldn't you just go with Linux/Raspbian in that scenario instead of locking yourself into Google?
- euyyn 9y agoThere are many factors. To start, many companies were already choosing to run a fork of Android in their products, like the Amazon Echo. This gives you access to Android's APIs, developer tools, and knowledge base, which is a significant boost in productivity. By using Android Things specifically, you also get hassle-free OTA updates directly from Google, which is essential for security. Raspbian is pretty much only supported on Raspberry Pis, so I think the worry of lock-in is worse there; and it's significant, taking into account that it's harder to go from prototype to production with a Raspberry Pi than with a SoM-based board. The UserDriver system is another factor: Android already does sensor fusion, so if your product uses, say, a GPS receiver, you can hook it up to the OS with a short amount of user-space Java code, and all existing Android code that uses the location APIs now works with your GPS. No need to modify client code nor compile anything into the OS. And your UserDriver works on any Android Things system. The talks of this year's Google I/O explain these kind of things in more detail.
- wyager 9y agoArduinos powered by AVRs aren't high-frequency. The highest-frequency external component might be a 20mhz crystal, which you can lay out just by following the example design in the data sheet. Most ARMs up to even a few hundred MHz are also pretty easy to lay out. For wireless you're right, but this is more or less solved by the recent proliferation of cheap plug-in wireless modules that are already certified.
- euyyn 9y agoYou're right that Arduinos are slower. I had things like the Raspberry Pi in mind.
- rjsw 9y agoThe Raspberry Pi will be easier to layout than an equivalent ARM SoC that needs external RAM.
- sokoloff 9y agoUsing a module or not, you still have to go through unintentional radiator testing, though, right (if you have a clock signal on the board over some ludicrously low frequency)?
- kbaker 9y agoYes, if you want to sell your device you will need to go through Part 15 testing. I think the limit is in something like low-digit kHz.
- boznz 9y ago>Layout of high-frequency electronics has many gotchas I listened to this mantra for about 15 years but its like anything else that "looks hard" it becomes obvious after doing it. RF design rules are well documented and pretty straightforward once you get past the smoke, mirrors and doom mongering. All the good RF subsystem manufacturers have white papers, dev boards and fully documented layout design guides for their chips and low power ISM sub-systems under 20dBM are more or less bulletproof. I have made several commercial designs, my first ones were just copy/pasting the gerbers off the dev boards (I did not even need to buy the dev boards as the gerbers were downloadable for free) all these worked fine and even several dBM of transmission loss due to bad RF or enclosure design is not actually a game changer in most short distance/low power applications. My first designs I actually understood very little, now I have all the toys to do proper RF design and understand it much better and so long as you read up on the basics there is no reason not to try too. Seriously it costs $15 for a PCB delivered worldwide these days so you can afford to experiment or tell your EE/intern to do it and dont be too surprised when it works.
- dbcurtis 9y agoIt can be very hard to hire good embedded developers (I know, we are trying). Also, until you reach a certain scale, the work load tends to be highly variable. What these places need to do is hire one of the many good design houses that can quickly knock out a production-worthy design from an Arduino prototype and put you in contact with reliable contract manufactures to crank out volume. My employer has an EE/embedded team of 3, and we still rely on a local design house to rev our PCB's, do the generic infrastructure components of the embedded s/w, and design test fixtures. We write specs for electronics and keep the "secret sauce" firmware in house. There are other benefits -- as I write this we have an expensive instrument that we could never justify purchasing sitting on our lab bench because we borrowed it from our design house. We can get a few hours of specialist time here and there for things like FCC compliance testing to augment our in-house expertise. One person who has been around the track enough laps to be able to write good specs and do program management is sufficient in the early days.
- new299 9y agoI can do embedded, but also do other programming and programming related jobs. Thing I've found with embedded, is the pay is generally not as good as other work, and it's generally not as flexible (no remote). If you can do either generic webdev, or other things, those often look like better options.
- Melanie_ 9y agoIm making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do, ========http://www.smartfinancemedia.com/?682 http://www.smartfinancemedia.com/?682
- dbcurtis 9y agoThe remote part is hard because typically for embedded work you need at least a minimal EE workbench. Yes, the pay isn't as good for some reason -- which is odd given how hard it is to find good embedded people. Perhaps embedded developers as a group are poor negotiators. Personally, I couldn't stand doing generic webdev -- I'd rather spend eight hours a day poking myself in the eye with a sharp stick. I've always lived on the EE/software boundary. I suppose staring at logic analyzer traces is some other person's sharp stick, but it works for me.
- user5994461 9y agoIMO hardware manufacturers should get their shit together. It is unbelievable that they are not able to provide a decent hardware development platform that can match Arduino in ease of use & documentation, that use decent production-grade components, that's supported for sale for > 10 years and that has a clear path to switch from dev board to own IC.
- kfihihc 9y agoHow do you think particle.io?
- deelowe 9y agouhh, the atmel stuff is pretty freaking good.
- jasonlaramburu 9y agoI don't think it's a question of the state of a Silicon manufacturer's $hit. Nothing about what you propose is technically complex. It just takes a large, long term investment to build and support a platform like that for >10 years. The manufacturers probably haven't done it because they don't see a big enough market yet. Most big consumer hardware co's can just develop their own solutions internally, and hardware startups are still incredibly niche.
- petra 9y agoThe complexity of developing professional firmware is one the main tools chip companies have against their customers switching chips. So they won't go invest a lot of money explicitly against this goal.
- user5994461 9y agoThe complexity of any embedded software and IC is enough as lock in. It doesn't justify why they make it so hard to set an IO pin or to load a program on their chips.
- mschuster91 9y ago> and that has a clear path to switch from dev board to own IC. The core problem why many startups get stuck with Raspberry Pi, Arduino and friends is exactly the "dev board" problem. When building an MVP and I have the choice between a $20 Pi/Arduino/Pi Compute Board and a $1.000+ dev board, hell I'll choose the Pi option. Lots more support, especially because any combo of I/O and a Pi has been tried by someone else before in contrast to $weird_sensor+$weird_niche_devboard, and especially you will want about 10 or more units so you can afford to blow a couple boards. This will happen inevitably during development, either by "fat fingering" +12V to a 3V3 input or by blowing the wrong eFuse, and better to lose 20$ than 1k$, not to mention you have to raise the 10k first...
- kfihihc 9y ago>>IMO, the biggest problem is software startups unwillingness to hire other types of engineers. >>It's easy to bridge from Arduino to Atmel AVR IF you know how to do board layout. Startups need to either grow their knowledge of electronics or hire some electrical engineers. I agree, hardware can not agile like software is. So you have to re-design your product from prototype(like Arduino). Even more, you should outsource your hardware design to other professional hardware company, such as design house.
- wiremine 9y ago> It's easy to bridge from Arduino to Atmel AVR IF you know how to do board layout. Design is half the battle: the other half is component selection and manufacturing. If you BOM is way off, you're SOL before you even start, and most people don't get this until it's too late.
- nerpderp83 9y agoThis is why you don't design something around an esoteric part, like the only ARM part with 5 Quad SPI ports or a dual time base RTC. If you do, have contingencies for your contingencies, like merging footprints you can have the option to use different IMUs on the same PCB.
- wiremine 9y agoOf course you're right, but lots of startups and "corporate makers" learn this the hard way.
- e12e 9y agoI find the updates for Bunnie's eoma68 fascinating, like how things like a micro-hdmi connector can be a problem: https://www.crowdsupply.com/eoma68/micro-desktop/updates/274-eoma68-a20-cards-arrived https://www.crowdsupply.com/eoma68/micro-desktop/updates/274... (Starting at: "The issue that is of more concern is the JAE DC3 mid-mount Micro-HDMI connector."(...))
- z3t4 9y agoThese maker boards are for prototyping. If you want to go into production you should make your own board. There's a large step between writing software and making your own PCB though. You would be a truly full stack developer.
- ohyes 9y agoThe biggest problem is that hardware is a sucker's game. The minute you have to start creating even moderately specialized PCBs for your product, you incur a ton of extra costs. You have to deal with yields from the fab process, a hardware testing/debugging process that often requires an expensive oscilloscope, an up front outlay of capital just to get the pcbs produced, you have to deal with getting it certified as being 'safe'. It's easy to bridge from Arduino to Atmel AVR IF you know how to do board layout. Startups need to either grow their knowledge of electronics or hire some electrical engineers. The AVR documentation is excellent, you could easily design your own board if you have anything beyond rudimentary electronics skills. If you're doing something very simple, maybe... but If you're doing something very simple, why do you need specialized hardware? Get something prebuilt that runs embedded c or linux, write your software, attach your controllers (build a nice case), and be done with it. If you're doing something more complicated, (multiple layers, pcie, etc.) You'll never get the yields that you need (to be profitable) out of your fab process without either a very skilled/experienced EE, or a team and a bunch of money. Even with a simpler (or no) fab process you still have to worry about defects in production and testing for those defects before you ship the item. But at least without a fab process it can be arranged to be someone else's problem when the widgets don't work. It's not that you're wrong, its just that doing your own manufacturing is either: a.) Adding a lot of expense to something that needn't be as expensive if you can buy something that already pretty much works in bulk. If you reach the state of mass production, it could make sense to do this yourself, but at that point you may be past the startup/proof of concept phase. b.) Necessary but very expensive (more expensive than it appears on the surface) and problematic to both your margins and cash on hand. If you go this route you better have some backers with extremely deep pockets who believe in you and are willing to throw in extra cash when the first run of your board has issues and you get a low yield on them. I agree, however, about the value prop issue. But that's also kind of why I think hardware is a sucker's game. Either you get screwed by having to make your own stuff, or you get screwed by being dependent on a third party who may not be reliable (or in business, or still producing the thing that you need). Or both, because you're likely getting it fabricated by a third party, which will lead to the same issues as purchasing something 'off the shelf,' plus the possibility of having no one to blame but yourself. source: did a hardware startup. edit: I forgot to mention one other factor... If you're doing something high performance, there's a possibility that by the time you're ready to ship the product, it is out of date and there's some faster next-gen hardware out that will do the job better. This is exactly what happened to AMD with Bulldozer (there were some other fuck-ups there too, but for the most part it was superseded by intel's more advanced fab process).
- koffiezet 9y ago> IMO, the biggest problem is software startups unwillingness to hire other types of engineers. As someone who co-started (and later sold) a small privately funded company doing embedded software development about 15 years ago I think I can give some insight. We were a 3-person startup, all with a software background. Most we knew was how to use a multimeter and solder a jtag or DB9 connector, which we also needed on a regular basis - but that was about the extent of our knowledge. One of our very early projects however involved requiring some custom hardware. So we started looking for electrical engineers, and quickly found out we were absolutely clueless about how to interview or evaluate these people. With one guy we interviewed it 'clicked' - and after talking to him, we quickly realized we knew nothing about hardware design, production and everything involved. We would have hired him, but he was very honest about thinking that would be a bad idea and rejected our offer. Looking back, he was absolutely right. You don't just need electrical engineers, you need people with experience in production, hw testing and following up on all those things. We ended up outsourcing the hardware design and production to another company, and actually recommended them the guy we found, who ended doing most of the design for our project. Stick to what you know best, if you're small and need hardware designed, try to find a company that can do this and believes in what you're trying to achieve. It's easy to lose focus when you suddenly have to learn a bunch of new things - which includes failing a lot, something you can't afford in a startup.