On 7/1/2017 1:52 PM, Dimiter_Popoff wrote:>>> Not everyone. I am the proof :-). In fact I have never wasted any time >>> with one of these. If I will design something I will have to design it >>> anyway, why would I waste time toying around with some other board >>> than the one I want to design. >> >> I think you're ignoring the fact that most folks don't design hardware, >> anymore. The thinking seems to be that you can "save lots of time" >> by buying a board that you can glom some I/O's onto. >> >> Of course, now you have to design the I/O board and hope its a clean >> interface to the purchased board -- > > So you see I am not ignoring the fact they don't want to design > hardware; they have to design it anyway. Adapting it to a generic > board will cost at least as much as placing their own MCU on their > board.Exactly. The MCU (even if CPU+memory, etc.) is a no-brainer part of the design. OTOH, some folks might not have SMT manufacturing capabilities and the I/O's can often be designed to be thru-hole (giving them more choices as to how/where they are fabbed).> The latter option would get them much closer to what they want but > they typically "don't know how to open the box" as Dave said in > a post before.Exactly. You slap together COTS stuff and you forfeit a lot of control over cost, reliability, maintenance, form-factor, etc. E.g., my "network speakers" are implemented in a "module" that is composed of several TINY stacked PCB's. Because, in one (common) deployment, it has to fit in a 1.5 x 2.5 x 1" volume. What COTS "assemblies" will give me that composite form factor and support power sourced via PoE, 100Mb network interface, two channel amplifier, microphone (w/preamp), Ir detector, CPU, memory and enough horsepower to do real-time DSP (tone controls, etc.)? And, when I want to use the PoE subsystem on some *other* design (e.g., HVAC thermostat), will I need to find some other COTS assembly that fits THAT form factor and has similar performance characteristics as the "network speakers'" PoE interface? And, will all of these vendors continue to offer these assemblies as long as *I* want/need them? Or, will they decide to make changes that I'll have to accommodate "on the fly"? Or, stop offering something entirely leaving me in dire need of a substitute (with a possible new development effort in front of me)?>> .. and, that the purchased board >> meets *your* specific needs (gee, will it operate *reliably* over the >> full temperature and power supply range? will it be repairable? >> will the vendor keep supplying THAT "component"? etc.) >> >> So, folks are even more willing to buy their prototyping hardware... >> "so they can be writing code (that they've not fully DESIGNED!) sooner"! > > The thing with prototyping is that it only wastes your time if you > know what you are doing. Why do everything TWICE? Typically I design > the boards, the first revision obviously needs some cuts etc but > is quite acceptable, typically a lot more acceptable than first boards > I have seen having been made after months of prototyping etc.I learned to "prototype in foil" more than 30 years ago. Prototyping in any other way inevitably means you'll have to eventually create a "first pass" at your *production* system (which will likely need some hardware/software revision). So, expect yet another pass after that before you can expect to be ready for "production".> The reason why one might want to use some prototyping board is if they want to > sell software to run on it or if they want to write software > for a year or more and thus wait for chips to come out/go extinct > by the date of their end design. I have done neither hence my > point of view. > But these two are quite valid reasons.I've gone back to prototyping on my current project simply because most of the ideas that I am trying are untested -- there are no simmilar products that I can point to and assure myself: "yes, this approach WILL work; this is how much resources SOMEONE ELSE required to tackle a similar problem; etc." It also lets me defer committing to *an* implementation (hardware) until I have *all* of the implementations ready. I.e., why commit to a particular PoE PD controller (chip) for "design #1", today and discover that a better/cheaper PoE PD controller is available when it comes time to finalize design #6? If all of the designs are released at the same time, why not avail yourself of whatever the LATEST technology supports at the time of release? [E.g., my "compute resources" are 1GHz, 2GB SBC PC's. I'm *sure* that's WAY WAY WAY more than each node needs! OTOH, with each new MCU/SoC release, I see how much more I can potentially have available in a released product so I can just increase the (artificial) resource quotas that I've imposed in each design and magically remain "current" with the capabilities afforded by today's technology, today!]> The main reason behind these boards being so popular is the fact > that the design decisions are taken by people who do not know what > they are doing so they don't have the confidence to design the > product and try to make it easier for themselves by using something > "readily available". Well guess what, using a board with an MCU > is _harder_ than using an MCU alone, it just looks easier to > people who can't figure out "how to open the box". And these > people are defining the market trend... as it has been throughout > history, the slowest ones define the pace of the group.No, I think it has to do with the (mistaken) belief that it "saves time". Esp the "lets start writing code TODAY cuz we KNOW we're going to be the longest lead item; having REAL HARDWARE makes that possible!" Instead, they should be focusing on what their ultimate goal (specification) is likely to be so they don't prematurely commit to a particular hardware platform, set of software libraries/subsystems/components, etc. E.g., I develop much of my products in simulators -- just verifying that the algorithms are implemented correctly: - does this code correctly decode this data stream to reconstruct the audio signal that it was intended to carry? let's see what it actually sounds like (by pushing a file of simulated received data through it and capturing the resulting output -- for playback on a PC, AIFF, etc. player) - does this "tone control" implementation do what it's intended to do? Let me push that same raw data through the decoder with different "tone control settings" and compare the resulting files "with my ears". I only need *real* hardware when I want to do things that are difficult to simulate reliably: - if I push the left channel through this device and the right channel through this other device, will the resulting audio outputs remain in proper phase relationship? - if I put lots of competing traffic on the wire, will audio packets get lost? will the recovery algorithms work as intended -- or will their be audible artifacts? - how much resources are *actually* used (vs. PLANNED for use)? But, this requires a different mindset -- and skillset!
FreeRTOS and newlib - comments requested
Started by ●June 27, 2017
Reply by ●July 1, 20172017-07-01