From owner-freebsd-embedded@freebsd.org Mon Mar 14 23:00:28 2016 Return-Path: Delivered-To: freebsd-embedded@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1931ACF4E1 for ; Mon, 14 Mar 2016 23:00:28 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 870369CB; Mon, 14 Mar 2016 23:00:28 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 32BCE153416; Tue, 15 Mar 2016 00:00:24 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_qStgFY36GR; Mon, 14 Mar 2016 23:59:53 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id B80551534C8; Mon, 14 Mar 2016 23:59:53 +0100 (CET) Subject: Re: ? about kernel size.. To: Brad Walker , John Clark References: <1457473674.1406.46.camel@freebsd.org> Cc: Adrian Chadd , "freebsd-embedded@freebsd.org" , Ian Lepore From: Willem Jan Withagen X-Enigmail-Draft-Status: N1110 Message-ID: <56E74269.9020201@digiware.nl> Date: Mon, 14 Mar 2016 23:59:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 23:00:28 -0000 On 9-3-2016 02:55, Brad Walker wrote: > By God John, you have pretty much summed up the current state of my > engineering life! > > I encountered these problems when I worked at a company called Xetawave. > They install these RF modems all over the place. A big market is the > oil/gas industry. If something breaks, they have to send out a technician > and that costs $100s of dollars. Managers start to get really anxious when > that happens. > > My current embedded client is about the same thing. Once the device is > installed getting it fixed/changed can be a real hassle. Don't even get me > started on the TCP/IP or memory issues dealing with uTasker. I can't > believe companies actually fall for this stuff, but they do. They make real > products out of them. But, it can be such a hassle. > > -brad w. > > > > On Tue, Mar 8, 2016 at 6:42 PM, John Clark wrote: > >> >> On Mar 8, 2016, at 5:20 PM, Brad Walker wrote: >> >> For example, we have a requirement to implement SSL/TLS, BTLE, and ftp on a >> microkernel. By the time this is done, it will be worthwhile to look at >> alternatives. Not to mention, the needs just keep coming. >> >> -brad w. >> >> >> At which point I become very vociferous in arguing against using a process >> so limited that it can’t run a BSD/Linux derivative. >> >> This sort of happened with the recent brush with the 8051… The Boss wanted >> to have the 8051 do some TCP/IP with some sort of >> Ethernet interface that was available from the company that made the 8051… >> >> At which point I found a $15 AP based on MIPS/Atheros SoC, and provided >> not only TCP/IP but also a local hotspot for control/monitoring, ethernet >> hub, mini http server, etc. >> >> If someone wanted to reduce cost from $15 they could have gotten the Eval >> package and gotten the design to a manufacturing house for much less as >> well… >> Of course they would talking about volumes many times greater than 100s… >> >> The 8051 controller was still in there, but the ‘fancy’ stuff was on a >> board that could handle ‘fancy’ stuff without making the project 2-3 years >> worth of development on a minimal >> processor platform. >> >> Another aspect of the ‘minimal system’ that is required to do ‘fancy’ >> stuff, is that often the TCP/IP implementation is sort of ‘half-baked’ and >> can introduce problems which go >> far beyond just not accessing the device… it could cause problems for the >> entire network, and require much debugging to solve… or even understand >> what’s going on… >> >> This may be ok if the devices are located in conveniently accessible >> locations… but if one has to go to a remote location via helicopter or pack >> in equipment with mules… >> such issues become bigger than the cost savings of some minimal solution. Hi, I've done some recent consulting for a company that build a gateway to a different wireless environment on a superblown 8051. So no MMU, nothing, with a poor and unprotected stack of software. They ended up with a 40+ people in software engineering, of which an odd 20 people where chasing bugs due to the fact that they had such a poor platform... The basic analysis we did proved that it would have been more than rewarding to have spent the extra $0,75 cts in the BOM to get a MMU able SoC and not having to run such a serious bug chasing team. And we were talking large!! numbers of platform. So anything below a few thousand items would certainly fall in the case of "use a few more cents" on the platform. Next to the thing that going after these kinds of bugs is really no fun. There are few people that have these skills, and they are scarce and can be put to better use. But then again this is the typical pitfall of the division of building hardware and software with two different organizational units that have their own budget responsibility. Both profit and quality go down the drain. My 2 cts in all this is that I'd take the MMU with 2 hands. Without this, it is just food for masochists. --WjW