Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91178 > unrolled thread
| Started by | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-27 22:36 +0200 |
| Last post | 2016-08-01 07:20 -0700 |
| Articles | 20 on this page of 193 — 30 participants |
Back to article view | Back to comp.lang.c
IEEE: C is the first programming language jacob navia <jacob@jacob.remcomp.fr> - 2016-07-27 22:36 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-27 16:42 -0700
Re: IEEE: C is the first programming language jacob navia <jacob@jacob.remcomp.fr> - 2016-07-28 01:47 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-27 17:20 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-27 18:03 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 00:43 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 05:12 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 05:41 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 06:02 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 06:26 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 06:45 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 09:11 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 09:30 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-28 14:03 +0200
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 05:24 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 01:14 +0200
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 18:27 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 12:08 +0200
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-29 11:37 +0100
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 12:51 +0200
Re: IEEE: C is the first programming language Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-29 08:36 -0600
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 05:32 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 14:42 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 06:59 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 16:08 +0100
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-29 09:16 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 09:21 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 17:55 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 11:00 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 11:48 -0700
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-07-29 21:12 +0100
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-29 19:39 -0700
Re: IEEE: C is the first programming language luser droog <luser.droog@gmail.com> - 2016-07-29 14:56 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 08:54 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-01 10:30 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 08:13 -0700
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:18 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 07:34 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 14:10 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-29 23:36 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 16:04 -0700
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-07-30 11:22 +1200
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-30 01:09 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 08:08 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 21:16 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 22:13 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-02 13:33 +0100
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 08:11 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:36 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 07:51 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 08:19 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 10:18 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 11:16 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 11:49 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 12:37 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 13:15 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 14:05 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 15:53 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-28 18:03 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-29 10:50 -0700
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-07-28 10:50 +0200
Re: IEEE: C is the first programming language "Osmium" <r124c4u102@comcast.net> - 2016-07-28 08:11 -0500
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:46 -0700
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 16:50 +0200
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-01 11:18 +0200
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 05:37 -0700
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 14:02 +0100
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 07:05 -0700
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 16:04 +0100
Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-01 09:26 -0700
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 10:12 -0700
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-01 10:21 -0700
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-01 11:01 -0700
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-01 11:44 -0700
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-02 12:05 +0200
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 15:48 +0000
Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-02 20:09 -0400
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 06:42 +0000
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:02 +0100
Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-03 03:15 -0700
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 11:53 +0000
Re: Setting architectural features in stone supercat@casperkitty.com - 2016-08-03 08:57 -0700
Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-03 10:52 +0200
Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:09 +0100
Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-03 08:51 -0700
Re: IEEE: C is the first programming language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 10:51 +0100
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-08-01 13:13 +0200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 05:27 -0700
Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-01 10:00 -0700
Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 10:29 +0000
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-01 16:29 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 15:53 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 16:37 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-04 16:07 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-04 20:38 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:52 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:00 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 03:12 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 21:48 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 20:07 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:03 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-05 13:09 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:38 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 11:24 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 15:28 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 08:25 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 16:36 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 08:41 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 16:45 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 09:41 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 19:45 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-06 09:47 +1200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-06 16:11 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 21:50 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 19:12 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-06 22:38 -0400
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 14:06 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:04 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:27 +0200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 20:24 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:30 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:03 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:36 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:11 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:02 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 07:35 +1200
Re: IEEE: C is the first programming language "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-08 16:00 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 08:07 +1200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-08 21:22 +0100
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:08 +0200
Re: IEEE: C is the first programming language jameskuyper@verizon.net - 2016-08-08 13:39 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:54 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:50 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 15:19 +0200
Re: IEEE: C is the first programming language already5chosen@yahoo.com - 2016-08-09 09:14 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 19:22 +0200
Re: IEEE: C is the first programming language James Kuyper <jameskuyper@verizon.net> - 2016-08-09 11:12 -0400
Re: IEEE: C is the first programming language cross@spitfire.i.gajendra.net (Dan Cross) - 2016-08-09 15:25 +0000
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 19:50 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 16:44 -0400
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-09 17:38 +1200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:51 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 20:06 +0200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-09 11:57 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-09 08:51 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 12:15 +0200
Re: IEEE: C is the first programming language BartC <bc@freeuk.com> - 2016-08-08 11:57 +0100
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-08 23:04 +1200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 15:20 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:27 -0400
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 09:21 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 17:33 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-08 14:35 -0400
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-08-05 14:06 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 14:37 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 13:53 +0200
Re: IEEE: C is the first programming language Gareth Owen <gwowen@gmail.com> - 2016-08-07 14:09 +0100
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 10:08 -0400
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-07 17:34 +0200
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-07 21:37 -0400
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-07 19:18 -0700
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-08-08 12:31 +0200
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 03:55 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-08 08:28 -0700
Re: IEEE: C is the first programming language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 09:44 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-08 10:13 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 07:51 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:39 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 11:27 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 15:29 -0400
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-05 08:38 -0700
Re: IEEE: C is the first programming language Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-05 13:40 -0400
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-28 21:27 +0200
Re: IEEE: C is the first programming language David Brown <david.brown@hesbynett.no> - 2016-07-29 00:19 +0200
Re: IEEE: C is the first programming language Noob <root@127.0.0.1> - 2016-08-01 11:49 +0200
Re: IEEE: C is the first programming language raltbos@xs4all.nl (Richard Bos) - 2016-07-28 10:01 +0000
Re: IEEE: C is the first programming language Les Cargill <lcargill99@comcast.com> - 2016-07-28 01:57 -0500
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 07:27 -0700
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-07-28 09:06 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-07-28 09:39 -0700
Re: IEEE: C is the first programming language Keith Thompson <kst-u@mib.org> - 2016-07-28 11:56 -0700
Re: IEEE: C is the first programming language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-07-28 15:19 -0400
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:15 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 05:25 -0700
Re: IEEE: C is the first programming language Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:37 -0700
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 08:21 -0700
Re: IEEE: C is the first programming language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-27 17:17 -0700
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 14:17 +0200
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-28 18:43 +0200
Re: IEEE: C is the first programming language Melzzzzz <mel@zzzzz.com> - 2016-07-28 18:58 +0200
Re: IEEE: C is the first programming language jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 21:46 +0200
Re: IEEE: C is the first programming language Ian Collins <ian-news@hotmail.com> - 2016-08-01 16:37 +1200
Re: IEEE: C is the first programming language supercat@casperkitty.com - 2016-08-01 07:20 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-09 17:38 +1200 |
| Message-ID | <e0t8j7Fr7hnU4@mid.individual.net> |
| In reply to | #91994 |
On 08/ 9/16 08:44 AM, Jerry Stuckle wrote: > > BTW - how's that 10GB fiber network to your office coming? ROFLMAO! 10G Copper and ticking along nicely, the 100G fibre is waiting on part availability. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-09 08:51 -0400 |
| Message-ID | <nocjjl$82v$3@jstuckle.eternal-september.org> |
| In reply to | #92003 |
On 8/9/2016 1:38 AM, Ian Collins wrote: > On 08/ 9/16 08:44 AM, Jerry Stuckle wrote: >> >> BTW - how's that 10GB fiber network to your office coming? ROFLMAO! > > 10G Copper and ticking along nicely, the 100G fibre is waiting on part > availability. > ROFLMAO! That's a good one, troll. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-09 20:06 +0200 |
| Message-ID | <nod63r$b9a$1@dont-email.me> |
| In reply to | #92012 |
On 09/08/16 14:51, Jerry Stuckle wrote: > On 8/9/2016 1:38 AM, Ian Collins wrote: >> On 08/ 9/16 08:44 AM, Jerry Stuckle wrote: >>> >>> BTW - how's that 10GB fiber network to your office coming? ROFLMAO! >> >> 10G Copper and ticking along nicely, the 100G fibre is waiting on part >> availability. >> > > ROFLMAO! That's a good one, troll. > A dual 10G copper Ethernet card is about $500. Switches are perhaps $700 upwards. Distances are 100m. These are no longer particularly rare in server systems, though it is more than most people want to pay. 100 Gb (fibre or copper) is still a bit exotic - it's no wonder there is lead time on the parts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-09 11:57 +0200 |
| Message-ID | <noc9f2$67t$1@dont-email.me> |
| In reply to | #91994 |
On 08/08/16 22:44, Jerry Stuckle wrote: > On 8/8/2016 3:35 PM, Ian Collins wrote: >> On 08/ 9/16 01:02 AM, Jerry Stuckle wrote: >>> On 8/7/2016 11:11 PM, Ian Collins wrote: >>>> On 08/ 8/16 01:36 PM, Jerry Stuckle wrote: >>>>> >>>>> What 32 bit microcontroller doesn't require at least 4 layers? Some >>>>> examples? There are just too many pins coming out of the chip set >>>>> to do >>>>> it with less. >>>> >>>> You really don't have a clue, do you? I already pointed you at the >>>> STM32 family, but I guess you need more help. See >>>> >>>> http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f3-series/stm32f303/stm32f303k6.html >>>> >>>> >>> >>> I have more of a clue than you do, troll. >> >> If you use the wee gadget under you hand called a mouse and click on the >> link above, you will see the datasheet for a 32 bit microcontroller that >> doesn't require at least a 4 layer board. That answers your question >> above. If you have trouble reading it, consult one of your legion of >> experts. >> > > Your microcontroller doesn't. But it multiplexes the signals on the > pins, requiring more for support chips. That's where the 4 layer boards > come in. You are confused. Try asking one of your "expert" colleagues to explain about pin multiplexing on microcontrollers. > > But if you understood ANYTHING about hardware design, I wouldn't have to > tell you that. > > BTW - how's that 10GB fiber network to your office coming? ROFLMAO! >
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-09 08:51 -0400 |
| Message-ID | <nocjl1$82v$4@jstuckle.eternal-september.org> |
| In reply to | #92008 |
On 8/9/2016 5:57 AM, David Brown wrote: > On 08/08/16 22:44, Jerry Stuckle wrote: >> On 8/8/2016 3:35 PM, Ian Collins wrote: >>> On 08/ 9/16 01:02 AM, Jerry Stuckle wrote: >>>> On 8/7/2016 11:11 PM, Ian Collins wrote: >>>>> On 08/ 8/16 01:36 PM, Jerry Stuckle wrote: >>>>>> >>>>>> What 32 bit microcontroller doesn't require at least 4 layers? Some >>>>>> examples? There are just too many pins coming out of the chip set >>>>>> to do >>>>>> it with less. >>>>> >>>>> You really don't have a clue, do you? I already pointed you at the >>>>> STM32 family, but I guess you need more help. See >>>>> >>>>> http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f3-series/stm32f303/stm32f303k6.html >>>>> >>>>> >>>> >>>> I have more of a clue than you do, troll. >>> >>> If you use the wee gadget under you hand called a mouse and click on the >>> link above, you will see the datasheet for a 32 bit microcontroller that >>> doesn't require at least a 4 layer board. That answers your question >>> above. If you have trouble reading it, consult one of your legion of >>> experts. >>> >> >> Your microcontroller doesn't. But it multiplexes the signals on the >> pins, requiring more for support chips. That's where the 4 layer boards >> come in. > > You are confused. Try asking one of your "expert" colleagues to explain > about pin multiplexing on microcontrollers. > Not confused at all. But you obviously have no clue - as you once again prove. >> >> But if you understood ANYTHING about hardware design, I wouldn't have to >> tell you that. >> >> BTW - how's that 10GB fiber network to your office coming? ROFLMAO! >> > -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-08 12:15 +0200 |
| Message-ID | <no9m3k$3fq$1@dont-email.me> |
| In reply to | #91905 |
Note: I know Jerry will respond by swearing, insulting, denying, etc. I was genuinely interested to hear if he knew something about CHAR_BIT != 8 microcontrollers or DSPs that I didn't know, but it seems not to be the case. (I do know that such devices exist, and that there are new ones developed all the time - I know someone who writes C compilers for that sort of thing. But they don't make up 90% of the devices around us.) But it is possible that there are others here who are curious about embedded systems, which is why I bother responding. On 08/08/16 03:36, Jerry Stuckle wrote: > On 8/7/2016 11:03 AM, David Brown wrote: >> On 05/08/16 21:28, Jerry Stuckle wrote: >>> On 8/5/2016 2:24 PM, supercat@casperkitty.com wrote: >>>> On Friday, August 5, 2016 at 12:38:22 PM UTC-5, Jerry Stuckle wrote: >>>>> I'm not sure which DSP chips you're working with, but more and more >>>>> consumer electronics are using CHAR_BIT of 10, 12 and even 14 or more. >>>>> People are wanting better audio quality than is available in 8 bit >>>>> chips, even in automobile electronics. And not only that, but places >>>>> where audio quality is not so much of a concern are using wider chips >>>>> because they can do more signal processing. >>>> >>>> Can you name even one remotely-popular chip which has CHAR_BIT value of >>>> anything other than 8 or 16? I'd be interested in seeing the data sheet >>>> for such a thing if you can give me a link. I recall a DSP some years >>>> back that used 24-bit words, but going to 32 bits offers so many >>>> advantages >>>> for a small increase in cost I'd be surprised if anyone is making any >>>> new >>>> 24-bit designs. >>>> >>> >>> It's not something I work on, so I don't know exact chip numbers. But I >>> do know of engineers which do. And I think they know what they're >>> talking about. >>> >>> One product I know of is the Toshiba IK-6410A camera. I don't know >>> which chip it uses, but it does use a 10 bit DSP. >>> >>> And going to a 32 bit processor requires at least a 4 layer, and often 5 >>> or six layer board. That is a significant increase in cost over a two >>> layer (top/bottom) board which can be used in many 10 and 12 bit DSPs. >>> The extra cost adds up and is unnecessary when all you need is 10 or 12 >>> bits. Additionally, it adds size to the board, which can also be >>> important (and more costly). Finally, power consumption is higher. >>> >> >> That sounds to me like you have only the vaguest general idea what you >> are talking about. >> > > A hell of a lot more than you do, as has been proven before. But then > you have already shown you will never admit you are wrong. > >> Yes, larger and more complex chips often require more layers on the >> board. Yes, extra layers usually (but certainly not always) means >> slightly higher costs. >> > > More than slightly higher costs. Management will look at any > possibility of saving even $0.02 per board. Because that is pure profit. Management may look at a saving of $0.02 per board - /if/ the quantities are high enough. And for many products, especially such price sensitive ones, the time to market is critical. Development costs, and especially development time, also play a part in such decisions. Squeezing a design to as few layers as possible can save money in the PCB, but add other costs. It can mean more components needed in order to fulfil EMC (emitted electromagnetic radiation, and susceptibility to incoming electromagnetic interference) requirements. It can mean more noise on the board, and thus lower performance - or more expensive components to compensate. It can mean smaller tracks and via holes - the tighter tolerances increase manufacturing costs, and may reduce reliability. It can mean poorer cooling on the board (a nice solid ground plane is a very useful heat spreader - you rarely get this with 2 layer boards). And so on. > >> No, 32-bit does not always mean 4 or more layers. No, using narrow >> width microcontrollers or DSPs does not always mean 2 layers. And >> certainly no, nobody uses "10-bit DSP's" in order to use 2 layer boards >> instead of 4 layer boards. >> > > What 32 bit microcontroller doesn't require at least 4 layers? Some > examples? There are just too many pins coming out of the chip set to do > it with less. I don't know if this link will work: <http://www.digikey.com/product-search/en/integrated-circuits-ics/embedded-microcontrollers/2556109?k=&pkeyword=&pv16=6547&pv16=6548&pv16=6511&pv16=13248&pv16=6514&pv16=13035&pv16=6526&pv16=13129&pv16=1582&pv16=7221&pv16=6533&pv16=12429&pv16=6534&pv16=67&pv16=13073&pv16=13036&pv16=713&pv16=11423&pv16=13440&pv16=80&pv16=1225&pv16=1773&pv16=11427&pv16=9701&pv16=1005&pv16=11886&FV=fff40027%2Cfff800cd%2Cac40007&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25> Basically it is a search on Digikey (an electronics supplier) for 32-bit microcontrollers, limited to packages that could be practically mounted on a 2 layer board without real challenges. There are some 1500 devices listed. This will include many duplicates with the same device in different packaging, temperatures, etc. But it is not hard to find devices from Atmel, Freescale/NXP, Infineon, Microchip, STM, TI, as well as smaller manufacturers, with 32-bit cores including AVR32, ARM (especially M0/M0+, but also M3/M4), Coldfire, and MIPS. At the most extreme, there is this: <http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m0-plus-m0/lpc800-low-cost-cortex-m0-plus/low-cost-32-bit-microcontroller-mcu-based-on-arm-cortex-m0-plus-core:LPC810M021FN8?fsrch=1&sr=1&pageNum=1> That is a 32-bit microcontroller in an 8-pin DIP package. You can use this by soldering a small 3V button battery between the power supply legs - no PCB is needed at all. In the real world of embedded electronics, the number of layers required for a microcontroller will depend on the number of pins coming out of it, the density of the package (BGA's need more layers than chips with legs), the type of signals, requirements for special voltages or low-noise analogue signals, etc. There are plenty of 8-bit devices that need at least 4 layer boards, and plenty of 32-bit devices that are fine on 2 layer boards. > >> Oh, and no, 32-bit does not necessarily mean higher power consumption, >> and again, nobody uses 10-bit DSPs to reduce power consumption. >> > > Once again you show you have no idea what you are talking about. The > more bits, the more active gates - and the higher power consumption, > everything else being more or less equal. For microcontrollers, the number of bits in the core is usually a tiny factor for power consumption. When the core is idle, the peripherals dominate the power consumption rather than the core. And faster cores spend more of their time in idle, compared to slower cores when doing the same work - thus ARM Cortex cores are often preferred over 8-bit or 16-bit cores when power consumption is a factor. > >>> Companies use what they need. And it is not a "small increase in cost" >>> - especially when you are talking millions of units. >>> >> >> Small increases in cost per device are certainly relevant when the >> quantities are high enough - no one will argue with that. Nor will >> anyone disagree that in some applications, it is important to use 2 >> layer or even single layer boards rather than 4 or 6 layers ones (5 >> layer boards do not exist). All we disagree with is your ideas about >> 10-bit DSPs and other such devices being 90% of the devices we have >> around us. >> >> >> > > Actually, 5 layer boards do exist; I've had to deal with a few of them. It is true that it is /possible/ to make a 5 layer board, but it is almost totally pointless. For those that don't know, multi-layer PCB boards are made up of stacks. Each element in the stack is either a double-sided PCB (basically a fibreglass board with a copper layer on each side, which is etched away to leave tracks, pads, polygons, etc.), or it is a filler (a fibreglass board without copper layers). You make a 4 layer PCB with two double-sided PCBs, and a filler in between. A 6 layer PCB takes three double-sided PCBs and two fillers, and so on. (Yes, I know there are many more variations involved - but that's the basics.) A 5 layer board would require a double-sided PCB, a filler, and then a single-sided board. Since single-sided PCBs are not much cheaper than a double-sided one in the multi-layer PCB process, there is little to save in using 5 layers instead of 6. And there are great problems with manufacturing and using such a board - you aim to keep board layers symmetrical to get a more accurate board, and better stability and reliability during manufacturing and when dealing with temperature changes. Thus 5 layer boards are rarely offered by PCB manufacturers, and rarely used. > But you've already shown you have your head so far up your ass that you > can see your tonsils, so that's no surprise. > > So piss off, asshole. > >
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 11:57 +0100 |
| Message-ID | <no9ohs$akb$1@dont-email.me> |
| In reply to | #91938 |
On 08/08/2016 11:15, David Brown wrote: > It is true that it is /possible/ to make a 5 layer board, but it is > almost totally pointless. For those that don't know, multi-layer PCB > boards are made up of stacks. Each element in the stack is either a > double-sided PCB (basically a fibreglass board with a copper layer on > each side, which is etched away to leave tracks, pads, polygons, etc.), > or it is a filler (a fibreglass board without copper layers). You make > a 4 layer PCB with two double-sided PCBs, and a filler in between. A 6 > layer PCB takes three double-sided PCBs and two fillers, and so on. I never knew that... > (Yes, I know there are many more variations involved - but that's the > basics.) > > A 5 layer board would require a double-sided PCB, a filler, and then a > single-sided board. You mean two double-sided PCBs with a filler between, then another filler followed by a single-sided PCB? Since single-sided PCBs are not much cheaper than a > double-sided one in the multi-layer PCB process, there is little to save > in using 5 layers instead of 6. Well you probably don't need that last filler if the single-sided board has its copper side away from the others. So you'd save one fibre-glass board and one layer of copper. (BTW do plated-through-holes go across all layers? I suppose they must do.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 23:04 +1200 |
| Message-ID | <e0r79iFj0t1U2@mid.individual.net> |
| In reply to | #91943 |
On 08/ 8/16 10:57 PM, BartC wrote: > On 08/08/2016 11:15, David Brown wrote: > >> It is true that it is /possible/ to make a 5 layer board, but it is >> almost totally pointless. For those that don't know, multi-layer PCB >> boards are made up of stacks. Each element in the stack is either a >> double-sided PCB (basically a fibreglass board with a copper layer on >> each side, which is etched away to leave tracks, pads, polygons, etc.), >> or it is a filler (a fibreglass board without copper layers). You make >> a 4 layer PCB with two double-sided PCBs, and a filler in between. A 6 >> layer PCB takes three double-sided PCBs and two fillers, and so on. > > I never knew that... > >> (Yes, I know there are many more variations involved - but that's the >> basics.) >> >> A 5 layer board would require a double-sided PCB, a filler, and then a >> single-sided board. > > You mean two double-sided PCBs with a filler between, then another > filler followed by a single-sided PCB? We probably does. > (BTW do plated-through-holes go across all layers? I suppose they must do.) Usually (because it costs less), but very dense boards will have buried vias to save space. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-08 15:20 +0200 |
| Message-ID | <noa0vk$5fe$1@dont-email.me> |
| In reply to | #91943 |
On 08/08/16 12:57, BartC wrote: > On 08/08/2016 11:15, David Brown wrote: > >> It is true that it is /possible/ to make a 5 layer board, but it is >> almost totally pointless. For those that don't know, multi-layer PCB >> boards are made up of stacks. Each element in the stack is either a >> double-sided PCB (basically a fibreglass board with a copper layer on >> each side, which is etched away to leave tracks, pads, polygons, etc.), >> or it is a filler (a fibreglass board without copper layers). You make >> a 4 layer PCB with two double-sided PCBs, and a filler in between. A 6 >> layer PCB takes three double-sided PCBs and two fillers, and so on. > > I never knew that... > >> (Yes, I know there are many more variations involved - but that's the >> basics.) >> >> A 5 layer board would require a double-sided PCB, a filler, and then a >> single-sided board. > > You mean two double-sided PCBs with a filler between, then another > filler followed by a single-sided PCB? Yes, of course. Electronics design is quite easy if you can count :-) > > Since single-sided PCBs are not much cheaper than a >> double-sided one in the multi-layer PCB process, there is little to save >> in using 5 layers instead of 6. > > Well you probably don't need that last filler if the single-sided board > has its copper side away from the others. So you'd save one fibre-glass > board and one layer of copper. > It could be done that way too. But you still have the same problems from lack of symmetry. Some pcb manufacturers will make 3 or 5 layer boards if you ask nicely, but they are so unusual that they are not standard options. > (BTW do plated-through-holes go across all layers? I suppose they must do.) > Yes. Through-holes (for component legs, or vias) are usually drilled and plated after the laminates are glued together. In multi-layer (i.e., more than 2 layers) boards you can also have "blind" and "buried" vias which don't go straight through - these are drilled (often by laser rather than mechanical drill) before the laminates are glued, or when only some of them are glued. They are particularly useful for very high density boards, BGA packages, etc. Of course, that sort of thing raises the cost of the PCB - but sometimes a smaller PCB will give you a cheaper product even if the cost per mm² of the PCB is higher.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-08 09:27 -0400 |
| Message-ID | <noa1bu$6ja$1@jstuckle.eternal-september.org> |
| In reply to | #91943 |
On 8/8/2016 6:57 AM, BartC wrote: > On 08/08/2016 11:15, David Brown wrote: > >> It is true that it is /possible/ to make a 5 layer board, but it is >> almost totally pointless. For those that don't know, multi-layer PCB >> boards are made up of stacks. Each element in the stack is either a >> double-sided PCB (basically a fibreglass board with a copper layer on >> each side, which is etched away to leave tracks, pads, polygons, etc.), >> or it is a filler (a fibreglass board without copper layers). You make >> a 4 layer PCB with two double-sided PCBs, and a filler in between. A 6 >> layer PCB takes three double-sided PCBs and two fillers, and so on. > > I never knew that... > >> (Yes, I know there are many more variations involved - but that's the >> basics.) >> >> A 5 layer board would require a double-sided PCB, a filler, and then a >> single-sided board. > > You mean two double-sided PCBs with a filler between, then another > filler followed by a single-sided PCB? > No, five layer boards are normally a two sided board and three one-sided boards, or, more likely, two two-sided boards with a one-sided board and filler in the middle. Among other things, they are thinner, lighter and less expensive than 6 layer boards. > Since single-sided PCBs are not much cheaper than a >> double-sided one in the multi-layer PCB process, there is little to save >> in using 5 layers instead of 6. > > Well you probably don't need that last filler if the single-sided board > has its copper side away from the others. So you'd save one fibre-glass > board and one layer of copper. > > (BTW do plated-through-holes go across all layers? I suppose they must do.) > Pretty much, yes. Theoretically you can get holes only between inner layers, but in practice it's almost impossible. It's much easier to go through the entire board, even if the top and bottom layers don't need to be connected. But engineers try to design boards to minimize number of plated through holes where possible. If not done properly, they can be a failure point, especially with the inner layers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-08 09:21 -0400 |
| Message-ID | <noa106$5h5$1@jstuckle.eternal-september.org> |
| In reply to | #91938 |
On 8/8/2016 6:15 AM, David Brown wrote: > Note: > > I know Jerry will respond by swearing, insulting, denying, etc. I was > genuinely interested to hear if he knew something about CHAR_BIT != 8 > microcontrollers or DSPs that I didn't know, but it seems not to be the > case. (I do know that such devices exist, and that there are new ones > developed all the time - I know someone who writes C compilers for that > sort of thing. But they don't make up 90% of the devices around us.) > > But it is possible that there are others here who are curious about > embedded systems, which is why I bother responding. > No, the only thing you are interested in is arguing and contradicting - as you have proven so many times before. > On 08/08/16 03:36, Jerry Stuckle wrote: >> On 8/7/2016 11:03 AM, David Brown wrote: >>> On 05/08/16 21:28, Jerry Stuckle wrote: >>>> On 8/5/2016 2:24 PM, supercat@casperkitty.com wrote: >>>>> On Friday, August 5, 2016 at 12:38:22 PM UTC-5, Jerry Stuckle wrote: >>>>>> I'm not sure which DSP chips you're working with, but more and more >>>>>> consumer electronics are using CHAR_BIT of 10, 12 and even 14 or more. >>>>>> People are wanting better audio quality than is available in 8 bit >>>>>> chips, even in automobile electronics. And not only that, but places >>>>>> where audio quality is not so much of a concern are using wider chips >>>>>> because they can do more signal processing. >>>>> >>>>> Can you name even one remotely-popular chip which has CHAR_BIT value of >>>>> anything other than 8 or 16? I'd be interested in seeing the data sheet >>>>> for such a thing if you can give me a link. I recall a DSP some years >>>>> back that used 24-bit words, but going to 32 bits offers so many >>>>> advantages >>>>> for a small increase in cost I'd be surprised if anyone is making any >>>>> new >>>>> 24-bit designs. >>>>> >>>> >>>> It's not something I work on, so I don't know exact chip numbers. But I >>>> do know of engineers which do. And I think they know what they're >>>> talking about. >>>> >>>> One product I know of is the Toshiba IK-6410A camera. I don't know >>>> which chip it uses, but it does use a 10 bit DSP. >>>> >>>> And going to a 32 bit processor requires at least a 4 layer, and often 5 >>>> or six layer board. That is a significant increase in cost over a two >>>> layer (top/bottom) board which can be used in many 10 and 12 bit DSPs. >>>> The extra cost adds up and is unnecessary when all you need is 10 or 12 >>>> bits. Additionally, it adds size to the board, which can also be >>>> important (and more costly). Finally, power consumption is higher. >>>> >>> >>> That sounds to me like you have only the vaguest general idea what you >>> are talking about. >>> >> >> A hell of a lot more than you do, as has been proven before. But then >> you have already shown you will never admit you are wrong. >> >>> Yes, larger and more complex chips often require more layers on the >>> board. Yes, extra layers usually (but certainly not always) means >>> slightly higher costs. >>> >> >> More than slightly higher costs. Management will look at any >> possibility of saving even $0.02 per board. Because that is pure profit. > > Management may look at a saving of $0.02 per board - /if/ the quantities > are high enough. And for many products, especially such price sensitive > ones, the time to market is critical. Development costs, and especially > development time, also play a part in such decisions. > When you're talking millions of boards, which many manufacturers are, it is very significant. It is significant even with 10's of thousands of board because saving $0.02 here and $0.03 there quickly adds up. > Squeezing a design to as few layers as possible can save money in the > PCB, but add other costs. It can mean more components needed in order > to fulfil EMC (emitted electromagnetic radiation, and susceptibility to > incoming electromagnetic interference) requirements. It can mean more > noise on the board, and thus lower performance - or more expensive > components to compensate. It can mean smaller tracks and via holes - > the tighter tolerances increase manufacturing costs, and may reduce > reliability. It can mean poorer cooling on the board (a nice solid > ground plane is a very useful heat spreader - you rarely get this with 2 > layer boards). And so on. > Another fallacy. You're assuming the same chips and squeezing the board into fewer layers. That isn't what they do. But it's not surprising that you're once again showing your ignorance. >> >>> No, 32-bit does not always mean 4 or more layers. No, using narrow >>> width microcontrollers or DSPs does not always mean 2 layers. And >>> certainly no, nobody uses "10-bit DSP's" in order to use 2 layer boards >>> instead of 4 layer boards. >>> >> >> What 32 bit microcontroller doesn't require at least 4 layers? Some >> examples? There are just too many pins coming out of the chip set to do >> it with less. > > I don't know if this link will work: > > <http://www.digikey.com/product-search/en/integrated-circuits-ics/embedded-microcontrollers/2556109?k=&pkeyword=&pv16=6547&pv16=6548&pv16=6511&pv16=13248&pv16=6514&pv16=13035&pv16=6526&pv16=13129&pv16=1582&pv16=7221&pv16=6533&pv16=12429&pv16=6534&pv16=67&pv16=13073&pv16=13036&pv16=713&pv16=11423&pv16=13440&pv16=80&pv16=1225&pv16=1773&pv16=11427&pv16=9701&pv16=1005&pv16=11886&FV=fff40027%2Cfff800cd%2Cac40007&mnonly=0&newproducts=0&ColumnSort=0&page=1&quantity=0&ptm=0&fid=0&pageSize=25> > > Basically it is a search on Digikey (an electronics supplier) for 32-bit > microcontrollers, limited to packages that could be practically mounted > on a 2 layer board without real challenges. There are some 1500 devices > listed. This will include many duplicates with the same device in > different packaging, temperatures, etc. But it is not hard to find > devices from Atmel, Freescale/NXP, Infineon, Microchip, STM, TI, as well > as smaller manufacturers, with 32-bit cores including AVR32, ARM > (especially M0/M0+, but also M3/M4), Coldfire, and MIPS. > Yes, it is a microcontroller, not a microprocessor. But where do you get the idea it can be used on a two layer board? Just because it has a few pins coming out the side? Chips like this require more support chips, and the result will be a 4 layer board. > At the most extreme, there is this: > > <http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc-cortex-m0-plus-m0/lpc800-low-cost-cortex-m0-plus/low-cost-32-bit-microcontroller-mcu-based-on-arm-cortex-m0-plus-core:LPC810M021FN8?fsrch=1&sr=1&pageNum=1> > > That is a 32-bit microcontroller in an 8-pin DIP package. You can use > this by soldering a small 3V button battery between the power supply > legs - no PCB is needed at all. > And do nothing practical with it. So what? > > In the real world of embedded electronics, the number of layers required > for a microcontroller will depend on the number of pins coming out of > it, the density of the package (BGA's need more layers than chips with > legs), the type of signals, requirements for special voltages or > low-noise analogue signals, etc. There are plenty of 8-bit devices that > need at least 4 layer boards, and plenty of 32-bit devices that are fine > on 2 layer boards. > Those are some of the things. But it's not only the microprocessor that counts - it's also the peripheral chips. It's not just one thing - it's the entire design. >> >>> Oh, and no, 32-bit does not necessarily mean higher power consumption, >>> and again, nobody uses 10-bit DSPs to reduce power consumption. >>> >> >> Once again you show you have no idea what you are talking about. The >> more bits, the more active gates - and the higher power consumption, >> everything else being more or less equal. > > For microcontrollers, the number of bits in the core is usually a tiny > factor for power consumption. When the core is idle, the peripherals > dominate the power consumption rather than the core. And faster cores > spend more of their time in idle, compared to slower cores when doing > the same work - thus ARM Cortex cores are often preferred over 8-bit or > 16-bit cores when power consumption is a factor. > Once again you show you don't know the difference between a microcontroller and a microprocessor. I guess you just picked up on the term from your googling. And faster cores do NOT necessarily spend more time in idle - because the are not doing the same work. Engineers pick processors according to their needs, not their desire to have the fastest thing around. And when they are operating, faster processors take more energy to do the same work as slower ones. But ARM Cortex cores have lower power consumption for other reasons. >> >>>> Companies use what they need. And it is not a "small increase in cost" >>>> - especially when you are talking millions of units. >>>> >>> >>> Small increases in cost per device are certainly relevant when the >>> quantities are high enough - no one will argue with that. Nor will >>> anyone disagree that in some applications, it is important to use 2 >>> layer or even single layer boards rather than 4 or 6 layers ones (5 >>> layer boards do not exist). All we disagree with is your ideas about >>> 10-bit DSPs and other such devices being 90% of the devices we have >>> around us. >>> >>> >>> >> >> Actually, 5 layer boards do exist; I've had to deal with a few of them. > > It is true that it is /possible/ to make a 5 layer board, but it is > almost totally pointless. For those that don't know, multi-layer PCB > boards are made up of stacks. Each element in the stack is either a > double-sided PCB (basically a fibreglass board with a copper layer on > each side, which is etched away to leave tracks, pads, polygons, etc.), > or it is a filler (a fibreglass board without copper layers). You make > a 4 layer PCB with two double-sided PCBs, and a filler in between. A 6 > layer PCB takes three double-sided PCBs and two fillers, and so on. > That's one way of making multi-layer boards. Not the only way. But I guess that's the only way you've seen. > (Yes, I know there are many more variations involved - but that's the > basics.) > > A 5 layer board would require a double-sided PCB, a filler, and then a > single-sided board. Since single-sided PCBs are not much cheaper than a > double-sided one in the multi-layer PCB process, there is little to save > in using 5 layers instead of 6. And there are great problems with > manufacturing and using such a board - you aim to keep board layers > symmetrical to get a more accurate board, and better stability and > reliability during manufacturing and when dealing with temperature > changes. Thus 5 layer boards are rarely offered by PCB manufacturers, > and rarely used. > In your opinion. The engineers needing this have a different opinion. And I think they know more than you do. > >> But you've already shown you have your head so far up your ass that you >> can see your tonsils, so that's no surprise. >> >> So piss off, asshole. >> >> > Once again you've proven your head is so far up your ass you can see your tonsils. You can google. But you don't understand even what you google. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-08 17:33 +0200 |
| Message-ID | <noa8p6$22j$1@dont-email.me> |
| In reply to | #91955 |
On 08/08/16 15:21, Jerry Stuckle wrote: > > Once again you've proven your head is so far up your ass you can see > your tonsils. You can google. But you don't understand even what you > google. > So you have come up with a brilliant new phrase that you can use again and again, as an alternative to answering questions or following the thread. I guess even you felt the "teaching pigs to sing" idea was a little worn after the first 50 or so uses. If Bart or anyone else is interested, I'm happy to talk about electronics, pcb design, microcontrollers, microprocessors (and the differences between them), or other related topics. (I know Ian is interested, but he doesn't need me to teach him about them!) But since this is off topic for c.l.c., and provoking more rants from our resident ex IBM consultant is /definitely/ off topic, I will leave it there unless there are specific questions.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-08 14:35 -0400 |
| Message-ID | <noajdt$6ev$3@jstuckle.eternal-september.org> |
| In reply to | #91962 |
On 8/8/2016 11:33 AM, David Brown wrote: > On 08/08/16 15:21, Jerry Stuckle wrote: > >> >> Once again you've proven your head is so far up your ass you can see >> your tonsils. You can google. But you don't understand even what you >> google. >> > > So you have come up with a brilliant new phrase that you can use again > and again, as an alternative to answering questions or following the > thread. I guess even you felt the "teaching pigs to sing" idea was a > little worn after the first 50 or so uses. > > If Bart or anyone else is interested, I'm happy to talk about > electronics, pcb design, microcontrollers, microprocessors (and the > differences between them), or other related topics. (I know Ian is > interested, but he doesn't need me to teach him about them!) But since > this is off topic for c.l.c., and provoking more rants from our resident > ex IBM consultant is /definitely/ off topic, I will leave it there > unless there are specific questions. Yes, you will be happy to try to snow them with your bullshit. Some are not so naive, though. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 14:06 -0700 |
| Message-ID | <lnoa57x6wm.fsf@kst-u.example.com> |
| In reply to | #91754 |
supercat@casperkitty.com writes:
[...]
> Can you name even one remotely-popular chip which has CHAR_BIT value of
> anything other than 8 or 16? I'd be interested in seeing the data sheet
> for such a thing if you can give me a link. I recall a DSP some years
> back that used 24-bit words, but going to 32 bits offers so many advantages
> for a small increase in cost I'd be surprised if anyone is making any new
> 24-bit designs.
In an article posted in comp.lang.c in 2005, Jack Klein wrote:
I used an Analog Devices 32-bit SHARC DSP a few years ago,
I forget the exact model, where CHAR_BIT was 32 and all the
integer types (this was before long long) were 32 bits.
I currently do a lot of work with a Texas Instruments DSP in
the TMS32F28xx family where CHAR_BIT is 16 and the char, short,
and int types all share the same representation and size.
I imagine other DSPs from these and other manufacturers are
similar, although Freescale (was Motorola) has a 16 bit DSP
that they say supports CHAR_BIT 8, although I haven't used it.
According to http://stackoverflow.com/a/2215694/827263 from 2010,
there's a gcc-3.2 for the PDP-10 with CHAR_BIT==9.
http://pdp10.nocrew.org/gcc/download/gcc-pdp10-20020611.tar.bz2
(Presumably the PDP-10 no longer counts as "remotely-popular".)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-05 14:37 -0700 |
| Message-ID | <9efa2f6e-03a2-46fd-a433-2159e50da48c@googlegroups.com> |
| In reply to | #91772 |
On Friday, August 5, 2016 at 4:06:26 PM UTC-5, Keith Thompson wrote: > I used an Analog Devices 32-bit SHARC DSP a few years ago, > I forget the exact model, where CHAR_BIT was 32 and all the > integer types (this was before long long) were 32 bits. Fair enough. Many DSPs are only used to run code that doesn't really need to work with 8- and 16-bit quantities, and while I've never used a 32-bit DSP that lacked smaller subdivisions, I'm not surprised that they exist. On the other hand, I wouldn't expect something like a typical TCP stack to work very well on such a platform without so much rework that it would be more practical to write a stack from scratch (which is what I did on the 16-bit TMS DSP). > According to http://stackoverflow.com/a/2215694/827263 from 2010, > there's a gcc-3.2 for the PDP-10 with CHAR_BIT==9. > http://pdp10.nocrew.org/gcc/download/gcc-pdp10-20020611.tar.bz2 > (Presumably the PDP-10 no longer counts as "remotely-popular".) It may be popular in some "retro-computing" circles, so perhaps I should have said "remotely popular for practical production work".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-07 13:53 +0200 |
| Message-ID | <no77ff$v2g$1@dont-email.me> |
| In reply to | #91748 |
On 05/08/16 19:38, Jerry Stuckle wrote: > On 8/5/2016 7:09 AM, David Brown wrote: >> On 05/08/16 02:38, Jerry Stuckle wrote: >>> On 8/4/2016 7:07 PM, supercat@casperkitty.com wrote: >>>> On Thursday, August 4, 2016 at 3:37:44 PM UTC-5, Jerry Stuckle wrote: >> >>>>> There are more of those platforms out there than those which meet the >>>>> limitations you would put on C. You would be limiting C to maybe 10% of >>>>> the MPUs and MCUs in use today (if not even fewer). >>>> >>>> Do you mean physical machines or architectures? Can you identify some of >>>> the supposed 90% of the marketplace that I'm ignoring? >>>> >>> >>> Both. DSPs are a start. So are most of the MCUs and many of the CPUs >>> used in embedded systems - such as the computers controlling the various >>> systems in your automobile. >>> >> >> I am curious as to which architectures you are thinking of that are so >> commonplace, and which do not have CHAR_BIT == 8. (Or are you thinking >> of other limitations of Supercat's "commonplace C"?) >> > > Most DSPs use 10-14 bits, for instance. Some even more. The DSP chips I am familiar with use either 8 bit, 16 bit or 32 bit char's (though some have had other sizes internally, such as accumulator registers that are 40 or 48 bits). Such devices are easy to find on the websites of TI, Analog Devices, Freescale/NXP, etc. I know of a few DSP's with 24-bit "char" (which is still a multiple of 8, even if not a power of 2), but these are rare now. And such devices were often programmed in assembly rather than C. But I have not heard of any DSPs that have between 10 and 14 bit chars. Can you name some, or give some links? There are certainly plenty of CPU and DSP cores around that I have not heard of - but I think I have at least some familiarity with most of the microcontroller cores that are easily available to "normal" customers. I know there are many that are not available outside a limited customer base - some of the big car and electronics companies make there own cores that are not used elsewhere, for example. But I would like to hear specific names, links, references, or technical details of at least a few of such devices - the ones that you say make up roughly 90% of the market. Note that to be applicable here, they must be programmed in C - but I am still interested if they are programmed in assembly or other languages. > >> I have not worked on car electronics, but I have used (or am at least >> familiar with) a good many microcontrollers that /are/ used in cars - as >> well as in many other places around the home, industry, in gadgets, etc. >> >> Cars usually have a number of powerful processors handling things like >> engine control. Typical cpus for this would be 32-bit PowerPC or other >> 32-bit RISC architectures. Peripheral processors might be 8-bit or >> 16-bit devices, with 32-bit (especially ARM) becoming more prevalent. >> Entertainment systems, maps, etc., will be 32-bit or 64-bit, again >> usually ARM but possibly another RISC architecture. There may still be >> a few 4-bit devices in use for things like tire pressure monitors, but >> these are not programmed in C. >> > > Actually, automobile manufactures are getting away from those powerful > processors and going with smaller dedicated MCUs - mainly due to cost - > not only of the processor, but of manufacturing the electronics. I have not heard of such a trend. I have not followed the car industry closely enough to know that there is no such trend, but I am sceptical. Certainly I know that major Western manufacturers of auto parts (such as Freescale/NXP, Infineon, TI) have a steady supply of new high-end processors and microcontrollers for the auto industry, using mainly PPC and ARM cores. There is no visible signs of that changing - but I am aware that there is typically about a 2 year span between folks such as Ford or General Motors getting new chips and them being available for general industry. And I can't answer at all for the far eastern auto electronics suppliers. > >> The only devices that have CHAR_BIT != 8 that you are likely to find >> would be specialised coprocessors such as the eTPU that often use >> pre-generated software from the manufacturer, and perhaps a DSP or two >> in the music system. >> > > That was true several years ago, but less now. And there is no such > thing as "pre-generated software". Software must be written by someone. By "pre-generated", I mean supplied by the manufacturer or its close partners, rather than written by the systems designer. Someone making an audio device might, for example, use a DSP for handling the audio decoding for a range of formats, encryptions, etc., and for digital audio effects, along with a "normal" microcontroller for the user interface, the networking, and so on. They get the DSP code directly from the DSP manufacturer or its close partners - thus avoiding dealing with difficult specialist programming, patent and licensing complications, etc. But they program the microcontroller themselves. > >> Even in the DSP world, it is becoming rarer to see people working on >> systems with CHAR_BIT > 8. There are three reasons for this. One is >> that DSPs with CHAR_BIT == 8, such as the Blackfin, are getting >> proportionally more popular - people pick these with the intention of >> also doing non-DSP tasks on the same device, and that's easier with >> support for more conventional development. Secondly, people using the >> more powerful DSP's like SHARC's or TI's DSPs are using pre-made >> programs rather than writing their own software - development costs are >> too high, it is very difficult to get the highest throughput on such >> devices, and licensing and patent bureaucracy makes it far simpler and >> cheaper to buy ready-made software. Thirdly, conventional processors >> with SIMD or DSP extensions are fast enough for many traditional DSP >> tasks, while being cheaper and easier to work with. >> > > I'm not sure which DSP chips you're working with, but more and more > consumer electronics are using CHAR_BIT of 10, 12 and even 14 or more. Again, I would like to see information about concrete examples. > People are wanting better audio quality than is available in 8 bit > chips, even in automobile electronics. And not only that, but places > where audio quality is not so much of a concern are using wider chips > because they can do more signal processing. No one is claiming that people use 8-bit devices for audio processing (at least, not in modern systems). But devices with CHAR_BIT == 8 are often used, such as ARM cores. And when DSPs are used, which is common for audio processing, the popular ones I know have CHAR_BIT that is a multiple of 8 - mostly 16 or 32, but also some 24 bit. What we want to know are examples of this other 90% you claim have CHAR_BIT that is not a multiple of 8. > > Also, if development costs were "too high", no one would be writing > software any more. Any manufacturer of decent equipment wants software > written to their own specs on the chips, and when spread across hundreds > of thousands or millions of units, one-time development costs are small > when compared to manufacturing costs. No one - not even a company making millions of units - is going to think it is worth the cost in making all their audio codec software in-house from scratch. There are far too few people in the world who understand the stuff well enough to write such code, and writing it simply takes too long - no one can afford the time-to-market costs. > >> >> I am well aware that there is an extraordinary number of >> microcontrollers around us in all sorts of places, and these greatly >> outnumber the x86 or other "visible" processors. But apart from 4-bit >> devices (which were once dominant in absolute numbers, but are far from >> that now), I don't see any significant (more than a few percent) number >> of CHAR_BIT > 8 devices around. >> > > They are there - in embedded systems that you don't see unless you're > working with them. Again, examples please - with information about the cores in question. You see, the reality of embedded systems, especially high quantity systems, is that it is all about costs. This includes manufacturing costs, development costs, licensing costs, and time costs. Having CHAR_BIT == 8 (or at least, a multiple of 8) typically makes development costs and - in particular - development time, noticeably lower than having a "weird" architecture with an odd size of byte. Most licensable cores, hardware, and software is also heavily biased towards such sizes - so having a 10-bit or 14-bit char means you can't make your SoC from plug-and-play parts, and you can't use off-the-shelf software and tools. So the /only/ reason for using something other than CHAR_BIT == 8 would be manufacturing costs. There was a time when a chip designer could save a good deal of silicon (leading also to lower power and higher clock speeds) by having 24 bits rather than 32 bits in the ALU, and in particular in the multiplier circuits. So for high-end audio, making your DSP's use 24 bits rather than 16-bits (slower) or 32-bits (more expensive) made sense. With more modern designs and manufacturing processes, that difference is negligible in most cases. There simply is no reason to make a device with CHAR_BIT != 8 in the vast majority of use-cases. There will always be some specialised niche uses, of course - but as specialised niche uses, they are not particularly common. > >> >> But if I am wrong, and you have examples of common CHAR_BIT > 8 >> architectures or links to statistics, I'd be very interested to hear >> about them. And if the "90%" figure was about microcontrollers that >> break a different one of Supercat's "commonplace C" rules, then please >> say which rules. >> >> >> > > > But then I know you'll contradict anything I say. That's how you are. > And you NEVER admit you are wrong - even you are proven so. So none of > your tripe surprises me. It just proves how out of touch you are with > the embedded world. > You haven't /proven/ anything - repeating a claim is not proof. Give me links, references, examples, names - give me something /concrete/ to suggest that 90% of the devices we see around us have CHAR_BIT that is not a multiple of 8 (or that disobey some other rule of Supercat's "commonplace C").
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-07 14:09 +0100 |
| Message-ID | <87vazcn2tc.fsf@gmail.com> |
| In reply to | #91848 |
David Brown <david.brown@hesbynett.no> writes: > I know of a few DSP's with 24-bit "char" (which is still a multiple of > 8, even if not a power of 2), but these are rare now. And such > devices were often programmed in assembly rather than C. > > But I have not heard of any DSPs that have between 10 and 14 bit > chars. Can you name some, or give some links? No, he can't. >> I'm not sure which DSP chips you're working with, but more and more >> consumer electronics are using CHAR_BIT of 10, 12 and even 14 or more. > > Again, I would like to see information about concrete examples. He can't. > What we want to know are examples of this other 90% you claim have > CHAR_BIT that is not a multiple of 8. He doesn't know any. >> They are there - in embedded systems that you don't see unless you're >> working with them. > > Again, examples please - with information about the cores in question. He doesn't know.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-07 10:08 -0400 |
| Message-ID | <no7fdh$o9g$1@jstuckle.eternal-september.org> |
| In reply to | #91848 |
On 8/7/2016 7:53 AM, David Brown wrote: > On 05/08/16 19:38, Jerry Stuckle wrote: >> On 8/5/2016 7:09 AM, David Brown wrote: >>> On 05/08/16 02:38, Jerry Stuckle wrote: >>>> On 8/4/2016 7:07 PM, supercat@casperkitty.com wrote: >>>>> On Thursday, August 4, 2016 at 3:37:44 PM UTC-5, Jerry Stuckle wrote: >>> >>>>>> There are more of those platforms out there than those which meet the >>>>>> limitations you would put on C. You would be limiting C to maybe >>>>>> 10% of >>>>>> the MPUs and MCUs in use today (if not even fewer). >>>>> >>>>> Do you mean physical machines or architectures? Can you identify >>>>> some of >>>>> the supposed 90% of the marketplace that I'm ignoring? >>>>> >>>> >>>> Both. DSPs are a start. So are most of the MCUs and many of the CPUs >>>> used in embedded systems - such as the computers controlling the >>>> various >>>> systems in your automobile. >>>> >>> >>> I am curious as to which architectures you are thinking of that are so >>> commonplace, and which do not have CHAR_BIT == 8. (Or are you thinking >>> of other limitations of Supercat's "commonplace C"?) >>> >> >> Most DSPs use 10-14 bits, for instance. Some even more. > > The DSP chips I am familiar with use either 8 bit, 16 bit or 32 bit > char's (though some have had other sizes internally, such as accumulator > registers that are 40 or 48 bits). Such devices are easy to find on the > websites of TI, Analog Devices, Freescale/NXP, etc. > > I know of a few DSP's with 24-bit "char" (which is still a multiple of > 8, even if not a power of 2), but these are rare now. And such devices > were often programmed in assembly rather than C. > > But I have not heard of any DSPs that have between 10 and 14 bit chars. > Can you name some, or give some links? There are certainly plenty of > CPU and DSP cores around that I have not heard of - but I think I have > at least some familiarity with most of the microcontroller cores that > are easily available to "normal" customers. I know there are many that > are not available outside a limited customer base - some of the big car > and electronics companies make there own cores that are not used > elsewhere, for example. But I would like to hear specific names, links, > references, or technical details of at least a few of such devices - the > ones that you say make up roughly 90% of the market. > > Note that to be applicable here, they must be programmed in C - but I am > still interested if they are programmed in assembly or other languages. > >> >>> I have not worked on car electronics, but I have used (or am at least >>> familiar with) a good many microcontrollers that /are/ used in cars - as >>> well as in many other places around the home, industry, in gadgets, etc. >>> >>> Cars usually have a number of powerful processors handling things like >>> engine control. Typical cpus for this would be 32-bit PowerPC or other >>> 32-bit RISC architectures. Peripheral processors might be 8-bit or >>> 16-bit devices, with 32-bit (especially ARM) becoming more prevalent. >>> Entertainment systems, maps, etc., will be 32-bit or 64-bit, again >>> usually ARM but possibly another RISC architecture. There may still be >>> a few 4-bit devices in use for things like tire pressure monitors, but >>> these are not programmed in C. >>> >> >> Actually, automobile manufactures are getting away from those powerful >> processors and going with smaller dedicated MCUs - mainly due to cost - >> not only of the processor, but of manufacturing the electronics. > > I have not heard of such a trend. I have not followed the car industry > closely enough to know that there is no such trend, but I am sceptical. > Certainly I know that major Western manufacturers of auto parts (such > as Freescale/NXP, Infineon, TI) have a steady supply of new high-end > processors and microcontrollers for the auto industry, using mainly PPC > and ARM cores. There is no visible signs of that changing - but I am > aware that there is typically about a 2 year span between folks such as > Ford or General Motors getting new chips and them being available for > general industry. And I can't answer at all for the far eastern auto > electronics suppliers. > >> >>> The only devices that have CHAR_BIT != 8 that you are likely to find >>> would be specialised coprocessors such as the eTPU that often use >>> pre-generated software from the manufacturer, and perhaps a DSP or two >>> in the music system. >>> >> >> That was true several years ago, but less now. And there is no such >> thing as "pre-generated software". Software must be written by someone. > > By "pre-generated", I mean supplied by the manufacturer or its close > partners, rather than written by the systems designer. Someone making > an audio device might, for example, use a DSP for handling the audio > decoding for a range of formats, encryptions, etc., and for digital > audio effects, along with a "normal" microcontroller for the user > interface, the networking, and so on. They get the DSP code directly > from the DSP manufacturer or its close partners - thus avoiding dealing > with difficult specialist programming, patent and licensing > complications, etc. But they program the microcontroller themselves. > >> >>> Even in the DSP world, it is becoming rarer to see people working on >>> systems with CHAR_BIT > 8. There are three reasons for this. One is >>> that DSPs with CHAR_BIT == 8, such as the Blackfin, are getting >>> proportionally more popular - people pick these with the intention of >>> also doing non-DSP tasks on the same device, and that's easier with >>> support for more conventional development. Secondly, people using the >>> more powerful DSP's like SHARC's or TI's DSPs are using pre-made >>> programs rather than writing their own software - development costs are >>> too high, it is very difficult to get the highest throughput on such >>> devices, and licensing and patent bureaucracy makes it far simpler and >>> cheaper to buy ready-made software. Thirdly, conventional processors >>> with SIMD or DSP extensions are fast enough for many traditional DSP >>> tasks, while being cheaper and easier to work with. >>> >> >> I'm not sure which DSP chips you're working with, but more and more >> consumer electronics are using CHAR_BIT of 10, 12 and even 14 or more. > > Again, I would like to see information about concrete examples. > >> People are wanting better audio quality than is available in 8 bit >> chips, even in automobile electronics. And not only that, but places >> where audio quality is not so much of a concern are using wider chips >> because they can do more signal processing. > > No one is claiming that people use 8-bit devices for audio processing > (at least, not in modern systems). But devices with CHAR_BIT == 8 are > often used, such as ARM cores. And when DSPs are used, which is common > for audio processing, the popular ones I know have CHAR_BIT that is a > multiple of 8 - mostly 16 or 32, but also some 24 bit. > > What we want to know are examples of this other 90% you claim have > CHAR_BIT that is not a multiple of 8. > >> >> Also, if development costs were "too high", no one would be writing >> software any more. Any manufacturer of decent equipment wants software >> written to their own specs on the chips, and when spread across hundreds >> of thousands or millions of units, one-time development costs are small >> when compared to manufacturing costs. > > No one - not even a company making millions of units - is going to think > it is worth the cost in making all their audio codec software in-house > from scratch. There are far too few people in the world who understand > the stuff well enough to write such code, and writing it simply takes > too long - no one can afford the time-to-market costs. > >> >>> >>> I am well aware that there is an extraordinary number of >>> microcontrollers around us in all sorts of places, and these greatly >>> outnumber the x86 or other "visible" processors. But apart from 4-bit >>> devices (which were once dominant in absolute numbers, but are far from >>> that now), I don't see any significant (more than a few percent) number >>> of CHAR_BIT > 8 devices around. >>> >> >> They are there - in embedded systems that you don't see unless you're >> working with them. > > Again, examples please - with information about the cores in question. > > You see, the reality of embedded systems, especially high quantity > systems, is that it is all about costs. This includes manufacturing > costs, development costs, licensing costs, and time costs. Having > CHAR_BIT == 8 (or at least, a multiple of 8) typically makes development > costs and - in particular - development time, noticeably lower than > having a "weird" architecture with an odd size of byte. Most licensable > cores, hardware, and software is also heavily biased towards such sizes > - so having a 10-bit or 14-bit char means you can't make your SoC from > plug-and-play parts, and you can't use off-the-shelf software and tools. > > So the /only/ reason for using something other than CHAR_BIT == 8 would > be manufacturing costs. There was a time when a chip designer could > save a good deal of silicon (leading also to lower power and higher > clock speeds) by having 24 bits rather than 32 bits in the ALU, and in > particular in the multiplier circuits. So for high-end audio, making > your DSP's use 24 bits rather than 16-bits (slower) or 32-bits (more > expensive) made sense. With more modern designs and manufacturing > processes, that difference is negligible in most cases. > > There simply is no reason to make a device with CHAR_BIT != 8 in the > vast majority of use-cases. > > There will always be some specialised niche uses, of course - but as > specialised niche uses, they are not particularly common. > >> >>> >>> But if I am wrong, and you have examples of common CHAR_BIT > 8 >>> architectures or links to statistics, I'd be very interested to hear >>> about them. And if the "90%" figure was about microcontrollers that >>> break a different one of Supercat's "commonplace C" rules, then please >>> say which rules. >>> >>> >>> >> >> >> But then I know you'll contradict anything I say. That's how you are. >> And you NEVER admit you are wrong - even you are proven so. So none of >> your tripe surprises me. It just proves how out of touch you are with >> the embedded world. >> > > You haven't /proven/ anything - repeating a claim is not proof. Give me > links, references, examples, names - give me something /concrete/ to > suggest that 90% of the devices we see around us have CHAR_BIT that is > not a multiple of 8 (or that disobey some other rule of Supercat's > "commonplace C"). > > David, as I've said, I don't work with these directly. But I have worked with engineers who do, and programmers who write code for it. Just because I can't name specific chip numbers means nothing. Can you name chip numbers used in the I/O drivers of IBM OS/X mainframes? If you can't, then I guess they don't exist. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-07 17:34 +0200 |
| Message-ID | <no7ke2$8kh$1@dont-email.me> |
| In reply to | #91859 |
On 07/08/16 16:08, Jerry Stuckle wrote: > On 8/7/2016 7:53 AM, David Brown wrote: >> >> You haven't /proven/ anything - repeating a claim is not proof. Give me >> links, references, examples, names - give me something /concrete/ to >> suggest that 90% of the devices we see around us have CHAR_BIT that is >> not a multiple of 8 (or that disobey some other rule of Supercat's >> "commonplace C"). >> >> > > David, as I've said, I don't work with these directly. But I have > worked with engineers who do, and programmers who write code for it. > > Just because I can't name specific chip numbers means nothing. Can you > name chip numbers used in the I/O drivers of IBM OS/X mainframes? If > you can't, then I guess they don't exist. > I can't name chip numbers used in the I/O drivers of IBM mainframes - but I don't claim to know anything about them. /You/ made specific and very surprising claims about DSPs and embedded devices, and you have claimed to be an expert in such systems. And I am not asking for specific chip numbers - I am asking for /anything/ that could provide the slightest evidence for your claims.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-07 21:37 -0400 |
| Message-ID | <no8noc$od5$2@jstuckle.eternal-september.org> |
| In reply to | #91863 |
On 8/7/2016 11:34 AM, David Brown wrote: > On 07/08/16 16:08, Jerry Stuckle wrote: >> On 8/7/2016 7:53 AM, David Brown wrote: > >>> >>> You haven't /proven/ anything - repeating a claim is not proof. Give me >>> links, references, examples, names - give me something /concrete/ to >>> suggest that 90% of the devices we see around us have CHAR_BIT that is >>> not a multiple of 8 (or that disobey some other rule of Supercat's >>> "commonplace C"). >>> >>> >> >> David, as I've said, I don't work with these directly. But I have >> worked with engineers who do, and programmers who write code for it. >> >> Just because I can't name specific chip numbers means nothing. Can you >> name chip numbers used in the I/O drivers of IBM OS/X mainframes? If >> you can't, then I guess they don't exist. >> > > I can't name chip numbers used in the I/O drivers of IBM mainframes - > but I don't claim to know anything about them. > > /You/ made specific and very surprising claims about DSPs and embedded > devices, and you have claimed to be an expert in such systems. > > And I am not asking for specific chip numbers - I am asking for > /anything/ that could provide the slightest evidence for your claims. > Gee, so you can't name them, so I guess they don't exist. And I didn't name any specific devices, nor have I claimed to be an expert in such systems. Just that I am aware of them. But you've already proven you are unable to admit you are wrong about anything. So piss off, asshole. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web