Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #75341 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-11-08 16:49 +0100 |
| Last post | 2015-11-12 14:39 +0100 |
| Articles | 20 on this page of 181 — 23 participants |
Back to article view | Back to comp.lang.c
Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 16:49 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 19:29 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 11:46 -0800
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-08 20:03 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:18 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 21:14 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:25 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:06 -0800
Re: Right C version for GCC Philip Lantz <prl@canterey.us> - 2015-11-08 14:52 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 15:12 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 09:38 +0100
Re: Right C version for GCC Nick Bowler <nbowler@draconx.ca> - 2015-11-09 19:04 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 11:27 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 00:00 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 16:35 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 12:37 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 12:58 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:19 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-08 21:49 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 14:14 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 01:02 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 02:26 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 12:53 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 15:00 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 08:55 -0800
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 17:07 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 09:51 -0800
Re: Right C version for GCC jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-09 19:01 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:16 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 11:24 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:30 +0100
Re: Right C version for GCC jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-09 20:40 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 08:56 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 09:41 -0800
Re: Right C version for GCC gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-09 17:44 +0000
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 18:53 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 18:00 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 10:27 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:17 -0800
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 22:59 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:15 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-12 16:47 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-12 09:24 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-13 12:54 +0100
Re: Right C version for GCC Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 12:01 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-14 10:47 -0800
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-14 21:32 +0100
Re: Right C version for GCC Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 16:57 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:07 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:18 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 11:27 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 20:41 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:07 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:12 +0100
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-09 23:13 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 19:02 -0500
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:52 +0000
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-10 21:34 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:28 +0000
Re: Right C version for GCC glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 00:51 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-17 22:26 -0500
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-18 11:06 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:37 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 12:54 +1300
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 16:14 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 16:37 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 16:56 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 17:25 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 10:37 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 18:06 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 18:51 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:40 -0800
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:55 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 17:50 +0000
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-12 14:32 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 10:35 +0000
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-08 23:57 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:47 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:01 +0100
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 13:18 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 14:01 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 00:55 +0000
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 10:42 +0000
Re: Right C version for GCC Chad <cdalten@gmail.com> - 2015-11-09 03:03 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 03:27 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 12:28 +0000
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 09:07 +0000
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 07:37 -0500
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 16:57 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 12:39 +0100
Re: Right C version for GCC James Kuyper <jameskuyper@verizon.net> - 2015-11-09 13:18 -0500
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 10:49 +0100
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-10 19:33 -0600
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 13:34 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-11 06:53 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:00 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:37 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-09 13:53 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 21:54 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-09 15:45 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 11:14 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-10 10:53 +0000
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 03:14 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 13:00 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-10 12:39 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 15:11 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-10 16:16 +0100
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 16:35 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:54 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 18:56 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-10 23:27 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:32 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-18 08:44 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:43 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-19 12:29 +0100
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:01 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-21 15:50 +0100
Re: Right C version for GCC Philipp Klaus Krause <pkk@spth.de> - 2015-11-18 11:13 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-10 07:25 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 16:42 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-10 08:48 -0800
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-11 01:08 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 13:43 +0100
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-11 08:27 -0600
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-11 16:27 +0100
Re: Right C version for GCC David Thompson <dave.thompson2@verizon.net> - 2015-12-06 07:57 -0500
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-06 22:34 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 22:41 +0000
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 09:47 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 07:30 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 17:30 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 10:17 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 21:29 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-12-07 13:16 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 23:35 +0100
Re: Right C version for GCC jadill33@gmail.com - 2015-12-07 10:41 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-12-07 21:35 +0100
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-08 20:11 +0000
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 09:57 +1300
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 13:06 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 10:16 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 22:59 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 12:13 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:43 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-09 13:00 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 12:02 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 09:00 -0800
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 07:25 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:35 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 08:55 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:00 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 09:04 +1300
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:11 +0100
Re: Right C version for GCC Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-09 20:18 +0000
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 21:21 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-10 09:30 +1300
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:53 -0800
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-09 12:30 -0800
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 13:02 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 21:35 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 14:41 -0800
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 23:31 +0000
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-09 16:33 -0800
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-10 11:16 +0100
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-11 08:04 +1300
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 18:04 +0000
Re: Right C version for GCC raltbos@xs4all.nl (Richard Bos) - 2015-11-10 18:03 +0000
Re: Right C version for GCC Ian Collins <ian-news@hotmail.com> - 2015-11-11 08:23 +1300
Re: Right C version for GCC David Brown <david.brown@hesbynett.no> - 2015-11-09 13:41 +0100
Re: Right C version for GCC supercat@casperkitty.com - 2015-11-08 13:24 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-08 23:00 +0100
Re: Right C version for GCC Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-08 15:18 -0800
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 00:35 +0100
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:03 -0800
Re: Right C version for GCC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-09 12:42 +0000
Re: Right C version for GCC Keith Thompson <kst-u@mib.org> - 2015-11-08 17:51 -0800
Re: Right C version for GCC Les Cargill <lcargill99@comcast.com> - 2015-11-09 12:20 -0600
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-09 19:36 +0100
Re: Right C version for GCC BartC <bc@freeuk.com> - 2015-11-09 18:47 +0000
Re: Right C version for GCC Stephen Sprunk <stephen@sprunk.org> - 2015-11-11 00:55 -0600
Re: Right C version for GCC "Morten W. Petersen" <morphex@gmail.com> - 2015-11-12 14:39 +0100
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-10 08:48 -0800 |
| Message-ID | <ffc19850-7d3e-4e55-be33-0b21265113f3@googlegroups.com> |
| In reply to | #75584 |
On Tuesday, November 10, 2015 at 9:42:30 AM UTC-6, David Brown wrote: > My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous > devices, IMHO, but surprisingly common. The development tools for them > are TI proprietary, and normally used within the TI Code Composter > Studio IDE, with the actual build process being compile, assemble, link > - probably three programs taking a few seconds to run. I liked the 320C5x, but the 320F2xx seemed like an 320C5x with almost all of the features that allowed efficient code yanked out. The 320C5x had delayed branching instructions, conditional-execute instructions, and a FORTRAN-style DO loop in hardware [so loops that were at least three cycles long could run with zero per-loop overhead]. The 320F2xx offered none of those.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-11 01:08 -0800 |
| Message-ID | <2c2eff02-9da3-4034-aab2-7816e3ff5cf0@googlegroups.com> |
| In reply to | #75584 |
On Tuesday, November 10, 2015 at 3:42:30 PM UTC, David Brown wrote: > On 10/11/15 16:25, Malcolm McLean wrote: > My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous > devices, IMHO, but surprisingly common. The development tools for them > are TI proprietary, and normally used within the TI Code Composter > Studio IDE, with the actual build process being compile, assemble, link > - probably three programs taking a few seconds to run. > You also had to get the program into the flash. So there were actually two programs. You'd set it to one, then it would load the new program into flash, erasing old A. Then you'd switch execution to new A and get A to load new B on top of A. Sometimes things would go wrong and you had to attach a flash writer manually and refresh that way. > > > > The company had its own build system, and it took about two > > hours to build the product from scratch. > > Unless this was a build of the complete system - including the Linux > kernel and all the software for the embedded Linux system, then the > people making this build system have screwed up royally. Building a > complete embedded system certainly takes an enormous amount of bits and > pieces - but building for a 16-bit microcontroller does not. > That was a complete rebuild of everything, including the Linux kernel, from scratch. The Linux kernel included a loader which would load a new TMS flash rom.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-11 13:43 +0100 |
| Message-ID | <n1vd21$9ds$1@dont-email.me> |
| In reply to | #75722 |
On 11/11/15 10:08, Malcolm McLean wrote: > On Tuesday, November 10, 2015 at 3:42:30 PM UTC, David Brown wrote: >> On 10/11/15 16:25, Malcolm McLean wrote: > >> My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous >> devices, IMHO, but surprisingly common. The development tools for them >> are TI proprietary, and normally used within the TI Code Composter >> Studio IDE, with the actual build process being compile, assemble, link >> - probably three programs taking a few seconds to run. >> > You also had to get the program into the flash. > So there were actually two programs. You'd set it to one, then it > would load the new program into flash, erasing old A. Then you'd > switch execution to new A and get A to load new B on top of A. > > Sometimes things would go wrong and you had to attach a flash > writer manually and refresh that way. Yes, you need some way to get the binary into the device, though strictly speaking that is not part of the build process. (However, I often have a "make burn" Makefile target to do the flash burn.) >>> >>> The company had its own build system, and it took about two >>> hours to build the product from scratch. >> >> Unless this was a build of the complete system - including the Linux >> kernel and all the software for the embedded Linux system, then the >> people making this build system have screwed up royally. Building a >> complete embedded system certainly takes an enormous amount of bits and >> pieces - but building for a 16-bit microcontroller does not. >> > That was a complete rebuild of everything, including the Linux kernel, > from scratch. The Linux kernel included a loader which would load a > new TMS flash rom. > And /here/ is the problem. It is nothing to do with the embedded development, or the TMS, or anything else - it is simply a hopelessly badly designed build process.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-11-11 08:27 -0600 |
| Message-ID | <n1vitm$ush$2@dont-email.me> |
| In reply to | #75734 |
David Brown wrote: > On 11/11/15 10:08, Malcolm McLean wrote: >> On Tuesday, November 10, 2015 at 3:42:30 PM UTC, David Brown wrote: >>> On 10/11/15 16:25, Malcolm McLean wrote: >> >>> My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous >>> devices, IMHO, but surprisingly common. The development tools for them >>> are TI proprietary, and normally used within the TI Code Composter >>> Studio IDE, with the actual build process being compile, assemble, link >>> - probably three programs taking a few seconds to run. >>> >> You also had to get the program into the flash. >> So there were actually two programs. You'd set it to one, then it >> would load the new program into flash, erasing old A. Then you'd >> switch execution to new A and get A to load new B on top of A. >> >> Sometimes things would go wrong and you had to attach a flash >> writer manually and refresh that way. > > Yes, you need some way to get the binary into the device, though > strictly speaking that is not part of the build process. (However, I > often have a "make burn" Makefile target to do the flash burn.) > >>>> >>>> The company had its own build system, and it took about two >>>> hours to build the product from scratch. >>> >>> Unless this was a build of the complete system - including the Linux >>> kernel and all the software for the embedded Linux system, then the >>> people making this build system have screwed up royally. Building a >>> complete embedded system certainly takes an enormous amount of bits and >>> pieces - but building for a 16-bit microcontroller does not. >>> >> That was a complete rebuild of everything, including the Linux kernel, >> from scratch. The Linux kernel included a loader which would load a >> new TMS flash rom. >> > > And /here/ is the problem. It is nothing to do with the embedded > development, or the TMS, or anything else - it is simply a hopelessly > badly designed build process. > > I don't think he said they *always* rebuilt the kernel. There would be strong incentives to not do that, so they probably didn't. I have worked on things where a clean rebuild took 14 hours, and did not rebuild a large kernel. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-11 16:27 +0100 |
| Message-ID | <n1vmk7$fi2$1@dont-email.me> |
| In reply to | #75740 |
On 11/11/15 15:27, Les Cargill wrote: > David Brown wrote: >> On 11/11/15 10:08, Malcolm McLean wrote: >>> On Tuesday, November 10, 2015 at 3:42:30 PM UTC, David Brown wrote: >>>> On 10/11/15 16:25, Malcolm McLean wrote: >>> >>>> My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous >>>> devices, IMHO, but surprisingly common. The development tools for them >>>> are TI proprietary, and normally used within the TI Code Composter >>>> Studio IDE, with the actual build process being compile, assemble, link >>>> - probably three programs taking a few seconds to run. >>>> >>> You also had to get the program into the flash. >>> So there were actually two programs. You'd set it to one, then it >>> would load the new program into flash, erasing old A. Then you'd >>> switch execution to new A and get A to load new B on top of A. >>> >>> Sometimes things would go wrong and you had to attach a flash >>> writer manually and refresh that way. >> >> Yes, you need some way to get the binary into the device, though >> strictly speaking that is not part of the build process. (However, I >> often have a "make burn" Makefile target to do the flash burn.) >> >>>>> >>>>> The company had its own build system, and it took about two >>>>> hours to build the product from scratch. >>>> >>>> Unless this was a build of the complete system - including the Linux >>>> kernel and all the software for the embedded Linux system, then the >>>> people making this build system have screwed up royally. Building a >>>> complete embedded system certainly takes an enormous amount of bits and >>>> pieces - but building for a 16-bit microcontroller does not. >>>> >>> That was a complete rebuild of everything, including the Linux kernel, >>> from scratch. The Linux kernel included a loader which would load a >>> new TMS flash rom. >>> >> >> And /here/ is the problem. It is nothing to do with the embedded >> development, or the TMS, or anything else - it is simply a hopelessly >> badly designed build process. >> >> > > I don't think he said they *always* rebuilt the kernel. There would > be strong incentives to not do that, so they probably didn't. > > I have worked on things where a clean rebuild took 14 hours, > and did not rebuild a large kernel. > His original comments were: > The embedded community traditionally uses Linux to host cross- > compilers and other tools - usually a huge number even for a a little > project. > I haven't done much embedded programming, but I have done it. > I was amazed how many components there were in the chain from > my keystrokes specifying C source to a running program on the target. What we have discovered now is that this "amazing chain" and "huge number of tools" had nothing whatsoever to do with embedded development, but was an artefact of a poorly designed build process in one particular project.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-12-06 07:57 -0500 |
| Message-ID | <s4c86bhebtgjcs5udkhrlnc85aqeli6v4v@4ax.com> |
| In reply to | #75584 |
On Tue, 10 Nov 2015 16:42:23 +0100, David Brown <david.brown@hesbynett.no> wrote: > On 10/11/15 16:25, Malcolm McLean wrote: <details of old embedded project> > My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous > devices, IMHO, but surprisingly common. The development tools for them > are TI proprietary, and normally used within the TI Code Composter > Studio IDE, <snip rest> I'm sure that was a typo. But I've seen enough code that *should* be composted I felt a brief flash of hope while reading it. :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-06 22:34 +0100 |
| Message-ID | <n429fq$b5s$1@dont-email.me> |
| In reply to | #77970 |
On 06/12/15 13:57, David Thompson wrote: > On Tue, 10 Nov 2015 16:42:23 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> On 10/11/15 16:25, Malcolm McLean wrote: > <details of old embedded project> > >> My guess is that it was a TMS320F2xxx device - a 16-bit DSP. Hideous >> devices, IMHO, but surprisingly common. The development tools for them >> are TI proprietary, and normally used within the TI Code Composter >> Studio IDE, <snip rest> > > I'm sure that was a typo. But I've seen enough code that *should* be > composted I felt a brief flash of hope while reading it. > > :-) > It was not actually a typo - I have heard the tool referred to as "Code Composter" from a number of different sources. The biggest pain IMHO with the Code Composter compiler toolchain is that the bss is not zeroed out before main(). In standard C, and every other compiler I have used, an unintialised statically allocated variable is zeroed automatically (i.e., "int x;" at file scope starts at 0). But TI have decided that clearing the bss can take too long - for some users with large statically allocated data, microcontroller's watchdogs were triggering before reaching main() and being able to kick the dog. Therefore they don't clear any of it - your data that by C standards is zero initialised, is left uninitialised. This "feature" is documented - as a tiny note in the middle of the manual, where it clearly says that this behaviour is contrary to the C standards. Given the choice, I prefer to use Freescale's Code Worrier :-)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-12-06 22:41 +0000 |
| Message-ID | <slrnn69ed2.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #78001 |
On Sun, 2015-12-06, David Brown wrote: ... > The biggest pain IMHO with the Code Composter compiler toolchain is > that the bss is not zeroed out before main(). It's still that way? That's the only thing I remember about TMS-something development, from back in -97. That's soon 20 years ago ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 09:47 +0100 |
| Message-ID | <n43gv9$1ga$1@dont-email.me> |
| In reply to | #78006 |
On 06/12/15 23:41, Jorgen Grahn wrote: > On Sun, 2015-12-06, David Brown wrote: > ... > >> The biggest pain IMHO with the Code Composter compiler toolchain is >> that the bss is not zeroed out before main(). > > It's still that way? That's the only thing I remember about > TMS-something development, from back in -97. That's soon 20 years > ago ... > The last TI compiler I used was CC for the msp430, and it had that "feature" too. The unofficial msp430-gcc port cleared bss as it should, and I believe that the new official TI/Red Hat msp430 gcc port also clears bss properly. On the other hand, this means that if you have a large bss section, the chip's watchdog can reset the chip before main() has started and you can easily kick the dog (or disable it). I cannot fathom why anyone would make watchdog hardware enabled out of reset - that's a design flaw in the hardware. (Technically, this is not a compiler issue but a library issue - it's the library's C startup code that clears bss. But to most users, it appears as a compiler bug.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-07 07:30 -0800 |
| Message-ID | <ebb1b3a4-359f-4a17-a91e-a6f0470c4041@googlegroups.com> |
| In reply to | #78035 |
On Monday, December 7, 2015 at 2:48:03 AM UTC-6, David Brown wrote: > On the other hand, this means that if you have a large bss section, the > chip's watchdog can reset the chip before main() has started and you can > easily kick the dog (or disable it). I cannot fathom why anyone would > make watchdog hardware enabled out of reset - that's a design flaw in > the hardware. I would have said the opposite--watchdogs should be enabled out of reset unless code explicitly disables them. Otherwise a bodged reset could leave the chip in a random-code-execution state with watchdog disabled, though a good design should provide options of making the watchdog enable state permanent until the next reset, the next power-off, or until the next time code wants to change it, rather than forcing code to commit to one particular pattern. > (Technically, this is not a compiler issue but a library issue - it's > the library's C startup code that clears bss. But to most users, it > appears as a compiler bug.) The compiler and library form an "implementation".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 17:30 +0100 |
| Message-ID | <n44c3c$9lp$1@dont-email.me> |
| In reply to | #78092 |
On 07/12/15 16:30, supercat@casperkitty.com wrote: > On Monday, December 7, 2015 at 2:48:03 AM UTC-6, David Brown wrote: >> On the other hand, this means that if you have a large bss section, the >> chip's watchdog can reset the chip before main() has started and you can >> easily kick the dog (or disable it). I cannot fathom why anyone would >> make watchdog hardware enabled out of reset - that's a design flaw in >> the hardware. > > I would have said the opposite--watchdogs should be enabled out of reset > unless code explicitly disables them. Otherwise a bodged reset could > leave the chip in a random-code-execution state with watchdog disabled, > though a good design should provide options of making the watchdog enable > state permanent until the next reset, the next power-off, or until the > next time code wants to change it, rather than forcing code to commit to > one particular pattern. If there is a chance that your reset (hardware) could be botched, your hardware is broken and the watchdog will not fix it. At best, it will hide the problem. If there is a chance that your reset software handling could be botched, your software is broken and the watchdog will not fix it. At best, it will hide the problem. Watchdogs can be a useful guard against very rare hardware events, such as cosmic rays or unexpected hardware glitches. Even then, they are seldom particularly helpful, because most such glitches will not cause a normal, safely operating system to enter a state where it is still operating safely (noting that "completely stopped" may be considered a safe operating condition) but the watchdog is no longer being regularly kicked. I have heard the description of a watchdog as being akin to hitting a dead man repeatedly over the head with a hammer, in the hope that /this/ time he wakes up. I certainly cannot think of a single occasion in which I know a system has been restarted by a watchdog, in which there was not a serious underlying bug in the hardware or software which should have been fixed. And I can think of a great many occasions in which unexpected watchdog timeouts have caused trouble. If someone wants to use a watchdog on a chip, then they should be free to enable it - but in the majority of my systems the first step of the code is to disable the watchdog. > >> (Technically, this is not a compiler issue but a library issue - it's >> the library's C startup code that clears bss. But to most users, it >> appears as a compiler bug.) > > The compiler and library form an "implementation". > I am not sure that the startup code in the library is considered part of the C implementation, it doesn't matter one way or the other.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-07 10:17 -0800 |
| Message-ID | <f2556db1-440b-42b3-89fb-1050a5713fa2@googlegroups.com> |
| In reply to | #78096 |
On Monday, December 7, 2015 at 10:31:05 AM UTC-6, David Brown wrote: > On 07/12/15 16:30, supercat wrote: > If there is a chance that your reset (hardware) could be botched, your > hardware is broken and the watchdog will not fix it. At best, it will > hide the problem. For resets that are actually triggered by external reset hardware, I could go along with that. Something like an ESD pulse which partially leaks into a signal line, however, may cause a bodged partial reset. Further, if one is using a controller's built-in brown-out detect circuitry and it defaults to being disabled for purposes of allowing operation at lower-than-normal voltages than would be possible with the brown-out enabled, then a supply voltage that goes up and down a few times on start-up (might happen if someone is wiggling a plug while inserting it) could easily cause a bodged reset. > Watchdogs can be a useful guard against very rare hardware events, such > as cosmic rays or unexpected hardware glitches. Even then, they are > seldom particularly helpful, because most such glitches will not cause a > normal, safely operating system to enter a state where it is still > operating safely (noting that "completely stopped" may be considered a > safe operating condition) but the watchdog is no longer being regularly > kicked. Of course, during the time immediately following a reset, such hardware glitches can never occur, notwithstanding the fact that some kinds of glitches (e.g. nearby electrical events) may appear in clusters. > I certainly cannot think of a single occasion in which I know a system > has been restarted by a watchdog, in which there was not a serious > underlying bug in the hardware or software which should have been fixed. > And I can think of a great many occasions in which unexpected watchdog > timeouts have caused trouble. I've seen such restarts a fair number of times on boards which didn't have a brown-out detector with a hard-wired configuration, and also occasionally in cases involving ESD zaps. Generally boards should keep working in the presence of ESD zaps below a certain amount, but that doesn't mean they should be destroyed by anything larger. Often, there's a medium range where it's acceptable for an ESD zap to disrupt operation but not cause permanent damage.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 21:29 +0100 |
| Message-ID | <n44q28$5hl$1@dont-email.me> |
| In reply to | #78113 |
On 07/12/15 19:17, supercat@casperkitty.com wrote: > On Monday, December 7, 2015 at 10:31:05 AM UTC-6, David Brown wrote: >> On 07/12/15 16:30, supercat wrote: >> If there is a chance that your reset (hardware) could be botched, your >> hardware is broken and the watchdog will not fix it. At best, it will >> hide the problem. > > For resets that are actually triggered by external reset hardware, I could > go along with that. Something like an ESD pulse which partially leaks into > a signal line, however, may cause a bodged partial reset. You avoid that by protecting your signal lines from ESD. Pick a level of ESD protection suitable for the type of equipment you are making, design the hardware properly, and test somewhat above and beyond the requirements of the appropriate standard (not /too/ far above the requirements, of course - extra protection is costly). ESD cannot cause a botched or partial reset as long as the equipment is used as designed. > Further, if one > is using a controller's built-in brown-out detect circuitry and it defaults > to being disabled for purposes of allowing operation at lower-than-normal > voltages than would be possible with the brown-out enabled, then a supply > voltage that goes up and down a few times on start-up (might happen if > someone is wiggling a plug while inserting it) could easily cause a bodged > reset. You design the hardware so that this will not happen. It is not hard to make a power supply that does not go up and down a few times on startup - it is even easier to make a decent reset circuit that only releases the microcontroller's reset after the power supply is stable. If the chip has a built-in brown-out protection that is good enough for the job, use it - if not, make an external brown-out circuit. (For the benefit of C programmers here who are not involved in electronics design, this argument is about undefined behaviour in electronics. I am recommending that you make your electronics so that undefined behaviour does not happen, and that your inputs are sanitised before you use them - supercat apparently prefers to allow undefined behaviour to happen in various ways, and pretend that he can safely detect it and recover after it has happened.) > >> Watchdogs can be a useful guard against very rare hardware events, such >> as cosmic rays or unexpected hardware glitches. Even then, they are >> seldom particularly helpful, because most such glitches will not cause a >> normal, safely operating system to enter a state where it is still >> operating safely (noting that "completely stopped" may be considered a >> safe operating condition) but the watchdog is no longer being regularly >> kicked. > > Of course, during the time immediately following a reset, such hardware > glitches can never occur, notwithstanding the fact that some kinds of > glitches (e.g. nearby electrical events) may appear in clusters. If you think your system is going to get a cluster of glitches at startup, that you cannot protect against using suitable hardware, and you think that a watchdog will make the system safe and reliable - please as someone else to design your hardware. > >> I certainly cannot think of a single occasion in which I know a system >> has been restarted by a watchdog, in which there was not a serious >> underlying bug in the hardware or software which should have been fixed. >> And I can think of a great many occasions in which unexpected watchdog >> timeouts have caused trouble. > > I've seen such restarts a fair number of times on boards which didn't have > a brown-out detector with a hard-wired configuration, and also occasionally > in cases involving ESD zaps. Generally boards should keep working in the > presence of ESD zaps below a certain amount, but that doesn't mean they > should be destroyed by anything larger. Often, there's a medium range where > it's acceptable for an ESD zap to disrupt operation but not cause permanent > damage. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-07 13:16 -0800 |
| Message-ID | <b68abf57-8049-4a14-a600-fc8eb210f47c@googlegroups.com> |
| In reply to | #78127 |
On Monday, December 7, 2015 at 2:29:26 PM UTC-6, David Brown wrote: > You avoid that by protecting your signal lines from ESD. Pick a level > of ESD protection suitable for the type of equipment you are making, > design the hardware properly, and test somewhat above and beyond the > requirements of the appropriate standard (not /too/ far above the > requirements, of course - extra protection is costly). ESD cannot cause > a botched or partial reset as long as the equipment is used as designed. If the customer spec indicates that a device must accept transients of some size without behavioral disruption, and transients of some larger size without permanent damage, in what way would a device whose behavior is disrupted by transients between those sizes not be "properly designed"? > You design the hardware so that this will not happen. It is not hard to > make a power supply that does not go up and down a few times on startup > - it is even easier to make a decent reset circuit that only releases > the microcontroller's reset after the power supply is stable. If the > chip has a built-in brown-out protection that is good enough for the > job, use it - if not, make an external brown-out circuit. It's not hard if one is willing to tolerate an increase in quiescent power consumption. If one is trying to design a device which runs off a single lithium cell and has a quiescent current below 10uA, it's much harder. > (For the benefit of C programmers here who are not involved in > electronics design, this argument is about undefined behaviour in > electronics. I am recommending that you make your electronics so that > undefined behaviour does not happen, and that your inputs are sanitised > before you use them - supercat apparently prefers to allow undefined > behaviour to happen in various ways, and pretend that he can safely > detect it and recover after it has happened.) It's interesting to note that on the hardware front, "undefined behavior" can sometimes be murky, though very few hardware vendors push "undefined behavior" quite as far as C compiler writers would like to. Many devices, for example, guarantee that when certain things occur device operation will be *almost* unspecified unless or until certain conditions happen, but the devices will still abide by some constraints. For example, if the setup or hold time of a flip-flop is violated, it may output any continuous or arbitrarily-changing voltage between VOL and VOH until the next valid clock edge, but it won't catch fire output voltages outside that range, or interfere with the operation of other nearby circuitry. If one couldn't guarantee that the consequences of setup/hold violations would be bounded in such a fashion, it would be impossible for computers to safely perform any sort of asynchronous I/O.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 23:35 +0100 |
| Message-ID | <n451e1$3f5$1@dont-email.me> |
| In reply to | #78135 |
On 07/12/15 22:16, supercat@casperkitty.com wrote: > On Monday, December 7, 2015 at 2:29:26 PM UTC-6, David Brown wrote: >> You avoid that by protecting your signal lines from ESD. Pick a level >> of ESD protection suitable for the type of equipment you are making, >> design the hardware properly, and test somewhat above and beyond the >> requirements of the appropriate standard (not /too/ far above the >> requirements, of course - extra protection is costly). ESD cannot cause >> a botched or partial reset as long as the equipment is used as designed. > > If the customer spec indicates that a device must accept transients of some > size without behavioral disruption, and transients of some larger size > without permanent damage, in what way would a device whose behavior is > disrupted by transients between those sizes not be "properly designed"? > I can't figure out what you mean here. But I can certainly tell you that relying on a watchdog to help behaviour on transients is not a good plan. >> You design the hardware so that this will not happen. It is not hard to >> make a power supply that does not go up and down a few times on startup >> - it is even easier to make a decent reset circuit that only releases >> the microcontroller's reset after the power supply is stable. If the >> chip has a built-in brown-out protection that is good enough for the >> job, use it - if not, make an external brown-out circuit. > > It's not hard if one is willing to tolerate an increase in quiescent power > consumption. If one is trying to design a device which runs off a single > lithium cell and has a quiescent current below 10uA, it's much harder. It may be hard, but not necessarily impossible. And again, watchdogs don't help - they also consume valuable current. > >> (For the benefit of C programmers here who are not involved in >> electronics design, this argument is about undefined behaviour in >> electronics. I am recommending that you make your electronics so that >> undefined behaviour does not happen, and that your inputs are sanitised >> before you use them - supercat apparently prefers to allow undefined >> behaviour to happen in various ways, and pretend that he can safely >> detect it and recover after it has happened.) > > It's interesting to note that on the hardware front, "undefined behavior" > can sometimes be murky, though very few hardware vendors push "undefined > behavior" quite as far as C compiler writers would like to. Many devices, > for example, guarantee that when certain things occur device operation > will be *almost* unspecified unless or until certain conditions happen, but > the devices will still abide by some constraints. For example, if the > setup or hold time of a flip-flop is violated, it may output any continuous > or arbitrarily-changing voltage between VOL and VOH until the next valid > clock edge, but it won't catch fire output voltages outside that range, or > interfere with the operation of other nearby circuitry. If one couldn't > guarantee that the consequences of setup/hold violations would be bounded > in such a fashion, it would be impossible for computers to safely perform > any sort of asynchronous I/O. >
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2015-12-07 10:41 -0800 |
| Message-ID | <4b02285b-7dff-4937-a5e3-3a56eb1b330e@googlegroups.com> |
| In reply to | #78096 |
On Monday, December 7, 2015 at 11:31:05 AM UTC-5, David Brown wrote: > On 07/12/15 16:30, s...@casperkitty.com wrote: > > On Monday, December 7, 2015 at 2:48:03 AM UTC-6, David Brown wrote: > >> On the other hand, this means that if you have a large bss section, the > >> chip's watchdog can reset the chip before main() has started and you can > >> easily kick the dog (or disable it). I cannot fathom why anyone would > >> make watchdog hardware enabled out of reset - that's a design flaw in > >> the hardware. > > > > I would have said the opposite--watchdogs should be enabled out of reset > > unless code explicitly disables them. Otherwise a bodged reset could > > leave the chip in a random-code-execution state with watchdog disabled, > > though a good design should provide options of making the watchdog enable > > state permanent until the next reset, the next power-off, or until the > > next time code wants to change it, rather than forcing code to commit to > > one particular pattern. > > If there is a chance that your reset (hardware) could be botched, your > hardware is broken and the watchdog will not fix it. At best, it will > hide the problem. > > If there is a chance that your reset software handling could be botched, > your software is broken and the watchdog will not fix it. At best, it > will hide the problem. > > Watchdogs can be a useful guard against very rare hardware events, such > as cosmic rays or unexpected hardware glitches. Even then, they are > seldom particularly helpful, because most such glitches will not cause a > normal, safely operating system to enter a state where it is still > operating safely (noting that "completely stopped" may be considered a > safe operating condition) but the watchdog is no longer being regularly > kicked. > > I have heard the description of a watchdog as being akin to hitting a > dead man repeatedly over the head with a hammer, in the hope that /this/ > time he wakes up. > > I certainly cannot think of a single occasion in which I know a system > has been restarted by a watchdog, in which there was not a serious > underlying bug in the hardware or software which should have been fixed. > And I can think of a great many occasions in which unexpected watchdog > timeouts have caused trouble. I have run into a VMOS system that used watchdog timers. In this system, a watchdog timer failure would cause a reset and if the number of fatal resets was too high in a short amount of time, it would revert to a "golden" kernel image. I managed to discover this because someone... cough placed a small amount of serial port debugging output in a high rate periodic that caused the watchdog mechanism to time out, repeatedly. And the time it took before the VMOS reset was too short for one to communicate with the device to reload new software. So without this mechanism in place, that someone would have had to send the device back to the vendor for a wipe and reload. It's not quite the same context as what you're referring to, but I'll just chip in that the watchdog mechanism has a place in certain safety critical environments, mostly cause humans are the ones writing software for it. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-07 21:35 +0100 |
| Message-ID | <n44qep$7c2$1@dont-email.me> |
| In reply to | #78116 |
On 07/12/15 19:41, jadill33@gmail.com wrote: > On Monday, December 7, 2015 at 11:31:05 AM UTC-5, David Brown wrote: >> On 07/12/15 16:30, s...@casperkitty.com wrote: >>> On Monday, December 7, 2015 at 2:48:03 AM UTC-6, David Brown wrote: >>>> On the other hand, this means that if you have a large bss section, the >>>> chip's watchdog can reset the chip before main() has started and you can >>>> easily kick the dog (or disable it). I cannot fathom why anyone would >>>> make watchdog hardware enabled out of reset - that's a design flaw in >>>> the hardware. >>> >>> I would have said the opposite--watchdogs should be enabled out of reset >>> unless code explicitly disables them. Otherwise a bodged reset could >>> leave the chip in a random-code-execution state with watchdog disabled, >>> though a good design should provide options of making the watchdog enable >>> state permanent until the next reset, the next power-off, or until the >>> next time code wants to change it, rather than forcing code to commit to >>> one particular pattern. >> >> If there is a chance that your reset (hardware) could be botched, your >> hardware is broken and the watchdog will not fix it. At best, it will >> hide the problem. >> >> If there is a chance that your reset software handling could be botched, >> your software is broken and the watchdog will not fix it. At best, it >> will hide the problem. >> >> Watchdogs can be a useful guard against very rare hardware events, such >> as cosmic rays or unexpected hardware glitches. Even then, they are >> seldom particularly helpful, because most such glitches will not cause a >> normal, safely operating system to enter a state where it is still >> operating safely (noting that "completely stopped" may be considered a >> safe operating condition) but the watchdog is no longer being regularly >> kicked. >> >> I have heard the description of a watchdog as being akin to hitting a >> dead man repeatedly over the head with a hammer, in the hope that /this/ >> time he wakes up. >> >> I certainly cannot think of a single occasion in which I know a system >> has been restarted by a watchdog, in which there was not a serious >> underlying bug in the hardware or software which should have been fixed. >> And I can think of a great many occasions in which unexpected watchdog >> timeouts have caused trouble. > > I have run into a VMOS system that used watchdog timers. In this system, > a watchdog timer failure would cause a reset and if the number of fatal > resets was too high in a short amount of time, it would revert to a > "golden" kernel image. I managed to discover this because someone... cough > placed a small amount of serial port debugging output in a high rate > periodic that caused the watchdog mechanism to time out, repeatedly. And > the time it took before the VMOS reset was too short for one to communicate > with the device to reload new software. So without this mechanism in place, > that someone would have had to send the device back to the vendor for a > wipe and reload. > > It's not quite the same context as what you're referring to, but I'll just > chip in that the watchdog mechanism has a place in certain safety critical > environments, mostly cause humans are the ones writing software for it. > It is true that watchdogs can be useful for some types of software. But if a watchdog is useful, it is because the code has bugs, the system has design flaws, or it is being used in a way that was not intended by the specification and design. If you are aware that this is what you are protecting against, then it may be worth enabling the watchdog. And if you have a watchdog, then you need a sort of mechanism like you describe here - tracking the watchdog restarts and going into a safety or recovery mode rather than blindly restarting the system again and again. In particular, it is vital to learn /why/ the watchdog was triggered - that is what gives you the knowledge to try to fix the flaw. But if the watchdog is being triggered during your startup code from reset, before you have even reached main(), then the code should never have left the development lab. Therefore a watchdog that is enabled by reset is counter-productive - it cannot possibly help, and it can certainly cause problems.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-11-08 20:11 +0000 |
| Message-ID | <slrnn3vb39.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #75341 |
On Sun, 2015-11-08, Morten W. Petersen wrote: > Hi there. :) > > OK, so I'm inching along on my XML parser Smash XML, and thought > I'd give developing on CentOS a go. > > I quickly ran into problems there though, as gcc wouldn't accept > the -std=c90 command line argument. I glanced at the man page and > found that -ansi could be an option. Strange -- gcc here accepts -std=c89, -std=c90, -ansi and another bunch of names which boil down to the same thing. Is your gcc version very old? I have gcc 4.7 here, but it seems a bit unlikely that they would add new aliases for -ansi 25 years too late ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-11-09 09:57 +1300 |
| Message-ID | <da9r91FjinoU3@mid.individual.net> |
| In reply to | #75341 |
Morten W. Petersen wrote: > Hi there. :) > > OK, so I'm inching along on my XML parser Smash XML, and thought > I'd give developing on CentOS a go. > > I quickly ran into problems there though, as gcc wouldn't accept > the -std=c90 command line argument. I glanced at the man page and > found that -ansi could be an option. > > But when using -ansi, the compiler doesn't recognize the nested > struct elements.. the man page says that turning on -ansi shuts > down some GCC extensions that conflict with C90, so GCC has some > non-standard ways of defining structs then I assume. > > How can I handle this? Just stick with contemporary C (C99), there's a very slim chance anyone will want an XML parser on a system without a C99 compiler. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-08 13:06 -0800 |
| Message-ID | <3b4ddbaf-e356-4525-a0bf-318931ec5f24@googlegroups.com> |
| In reply to | #75369 |
On Sunday, November 8, 2015 at 8:57:14 PM UTC, Ian Collins wrote: > > Just stick with contemporary C (C99), there's a very slim chance anyone > will want an XML parser on a system without a C99 compiler. > The chance that someone will want to drop an XML parser into a Microsoft Visual Studio program is pretty high. You can of course obtain an C99 compiler for Windows. But unless the XML parser is a vital core component, a developer will be unwilling to switch compilers just so he can use one XML system.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web