Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399792 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-06-08 17:49 +0200 |
| Last post | 2026-06-14 14:44 +0200 |
| Articles | 20 on this page of 194 — 17 participants |
Back to article view | Back to comp.lang.c
this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 17:49 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 18:16 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-08 18:24 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:28 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 08:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 10:26 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 09:10 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 11:34 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-09 12:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 12:31 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 13:43 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 13:53 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:02 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 08:55 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 09:06 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:34 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-10 12:37 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 11:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:01 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 13:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:38 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 02:04 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 04:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Paul <nospam@needed.invalid> - 2026-06-09 06:02 -0400
Re: this guy talks about fopen (and im thinking about fopen for network) fir <profesor.fir@gmail.com> - 2026-06-09 12:18 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:45 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 13:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:52 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 22:05 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:24 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:07 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 16:47 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 02:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 19:52 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:57 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-20 15:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-21 16:30 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 12:23 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-10 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 13:54 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 23:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 21:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:21 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:14 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 00:31 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:15 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 21:08 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:10 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-09 23:01 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 06:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-11 13:27 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 01:35 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:26 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-13 14:32 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:45 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-14 13:55 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:36 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 13:08 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-16 13:11 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 03:11 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 12:13 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-17 23:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-17 20:26 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:30 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 04:36 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-18 04:38 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 13:42 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:40 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 16:40 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 02:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-19 19:53 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-21 16:31 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 00:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-22 14:06 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-22 22:40 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:41 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 02:05 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-24 04:36 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 12:19 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-24 21:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-25 12:44 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-10 12:02 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:16 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-17 18:41 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 07:30 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-18 03:49 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-18 23:06 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 01:20 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 08:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 10:42 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 10:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 15:29 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 16:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 18:07 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:51 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:04 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 19:55 +0000
[OT] Google AI - behavioral analysis (was: [something else]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-20 01:52 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:03 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 13:46 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 15:49 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-19 17:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-21 01:42 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-21 12:18 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-21 23:15 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) antispam@fricas.org (Waldek Hebisch) - 2026-06-22 04:33 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-22 10:01 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-22 14:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 07:25 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-23 15:35 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 18:07 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-23 17:12 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 21:07 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 23:00 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 08:32 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-24 21:54 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 21:09 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 10:48 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 10:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 15:02 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 11:29 +0000
NIC interrupt rates (was UART discussion; previously was Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 15:31 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 19:15 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 18:29 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 20:52 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-26 14:58 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-26 11:46 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 01:57 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-25 22:53 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 01:52 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-27 19:46 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-01 13:16 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-07-03 17:00 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-27 20:49 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-01 13:17 +0000
UARTs (was Re: this guy talks about fopen (and im thinking about fopen for network)) scott@slp53.sl.home (Scott Lurndal) - 2026-06-27 18:50 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-23 17:39 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-23 21:11 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 11:04 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-24 15:27 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 11:56 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-25 21:30 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-27 02:22 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-28 18:59 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-07 23:19 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-07-08 14:52 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-07-08 20:56 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-24 15:51 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-23 14:44 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 22:30 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-23 22:48 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-24 12:18 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-24 22:00 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-24 20:09 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Michael S <already5chosen@yahoo.com> - 2026-06-25 00:25 +0300
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-25 12:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-25 15:37 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) pa@see.signature.invalid (Pierre Asselin) - 2026-06-24 21:21 +0000
Time from official time-services (was Re: ...some arbitrary subject...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-28 00:15 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 16:31 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 17:50 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:54 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 19:58 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:15 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 22:09 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-20 03:00 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-19 10:33 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 19:04 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) scott@slp53.sl.home (Scott Lurndal) - 2026-06-19 18:55 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bart <bc@freeuk.com> - 2026-06-19 21:07 +0100
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-20 13:53 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-20 19:25 -0400
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:49 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 18:06 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 06:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) BGB <cr88192@gmail.com> - 2026-06-19 14:47 -0500
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-19 22:47 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) David Brown <david.brown@hesbynett.no> - 2026-06-20 14:02 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-19 02:21 -0700
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-19 09:59 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:26 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-06-09 21:21 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 12:28 +0000
Re: this guy talks about fopen (and im thinking about fopen for network) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-11 07:24 +0200
Re: this guy talks about fopen (and im thinking about fopen for network) Bonita Montero <Bonita.Montero@gmail.com> - 2026-06-14 14:44 +0200
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-01 13:16 +0000 |
| Message-ID | <11233uv$ofv$1@reader1.panix.com> |
| In reply to | #400259 |
In article <111p2a1$34arg$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>> [snip]
>>>> [snip]
>>>> I just checked and it looks like ST ships PL011's in a bunch of
>>>> Cortex-M class parts.
>>>
>>> Have you a reference for those?
>>> [snip]
>>
>> Actually, I think I was just wrong; the device I was thinking of
>> that used the PL011 off the shelf from ST was the ARM926 based
>> chip you mentioned: it's old, and they don't have them in their
>> Cortex-M offerings.
>
>OK. Those were older chips - in the earlier days of ARM processor SoCs
>(though ST was a little later than many others), designs from the likes
>of NXP and ST were based more on complete packages or reference designs
>from ARM. The types of IP licenses these manufacturers have with ARM
>have varied as they moved from making just a few ARM devices along with
>all their other chips, towards having ARM processor and microcontroller
>cores across a solid proportion of their portfolios. I expect they
>started with whatever was easiest for other ARM users (thus the PL011),
>and now integrate a lot more of their own peripherals in their chips. It
>is also not uncommon that big manufacturers buy smaller manufacturers,
>and so their early devices have whatever the small manufacturers used -
>that will be off-the-shelf peripherals. Then later on, they do more
>integration and use their own peripherals (saving them money). I don't
>know the history of ST's ARM processor SoCs at all - despite being one
>of the biggest in the ARM microcontroller world, they are relative
>newcomers to the processor / embedded Linux side of things.
My guess is that for the embedded market, they favor cost saving
compounded by volume; at scale, a 5c difference in the cost of a
microcontroller can add up. For application-profile cores, it's
less of a consideration on the margins, so they favor
standardization to leverage network effects around software
ecosystems.
>> The RPi2040 and Zynq boards seem to have PL011s, but are much
>> lower volume.
>
>That is perhaps slightly unexpected (for me) - both come from companies
>that can happily make their own UART implementations to avoid additional
>royalties to ARM, and money is always the main motivator. But maybe
>they don't pay much, or maybe they make their own PL011-compatible UARTs
>- ARM license terms are rarely public knowledge!
For RPi, this was one of their first in-house designs, versus
using one of Broadcom's offerings, wasn't it? Perhaps they went
with off-the-shelf IP for the UART to minimize risk. For Zynq,
I suspect the cost of the FPGA dwarfs whatever savings they'd
get from their own UART, so they favor software compatibility.
>>> That is very interesting, and somewhat unexpected. Thanks for the
>>> example. Where is this riscv core from?
>>
>> That is from a JH7110 SoC in a StarFive VisionFive2 SBC. I use
>> those things for little utility machines around the house (DHCP,
>> DNS, etc).
>
>I think it's a good thing if there are more Risc-V devices around - ARM
>is too dominant in many areas, and while standardisation on common
>platforms is convenient, competition is good too.
>
>How does this board compare to the ubiquitous Raspberry Pi's for such
>uses? Neither DHCP nor DNS are particularly challenging applications,
>unless you have a huge network, but your "etc." might cover other things.
I agree, and I'm happy to have RISC-V boards to work with.
However, compared to an RPi, it's not fast; maybe comparable to
an RPi2 or RPi3. However, it has native NVMe and an M.2 slot at
Gen2x4 and a real Ethernet PHY (not a USB bridge), that can
eliminate some of the IO slowness of older RPi hardare.
In terms of competative application cores available at scale,
the RV64 ecosystem has a lot of work to do.
>> [snip]
>> No idea. About eight years ago, on a 192 Xeon core system, with
>> 256GB of RAM and a 200Gbps NIC plus about 16TB of NVMe, I
>> regularly saw ~250k interrupts/sec across the fabric in the
>> steady-state, bursting up to a million or so.
>
>Perhaps we can conclude that Linux systems can handle lots of
>interrupts, but too many become inefficient and have a risk of losing
>some. Careful system tuning and consideration of the pattern of
>interrupts lets you handle more without losses, but smarter hardware the
>reduces the interrupt rate is essential at some point. And attempts at
>putting figures on things is going to be too vague or require far more
>detail of the hardware and applications than appropriate here.
Agreed.
>> [snip]
>> That, frankly, seems kind of hard to believe: the math just does
>> not add up, even assuming no wait states for access to e.g.
>> SRAM and single-cycle memory access times, with an instruction
>> dispatched per cycle; did you just, like, NEVER touch memory or
>> more than 2 or 3 registers in that path? Was the internal CPU
>> frequency 18MHz, or was that a reference oscillator?
>
>No, the chip ran at 18.432 MHz - it was an 8-bit AVR microcontroller.
>Most instructions are single cycle, except for branches (mostly 1 or 2
>cycles), call / return, and load/store to memory (2 cycles). That
>application was all in assembly, and I split the cpu's 32 registers
>between ones used in the software UART timer interrupt, and ones used in
>the main code. Thus no cycles were needed for stacking or restoring
>registers on interrupts, or other context switch stuff other than the PC
>and flag registers.
>
>It would, of course, have made more sense to have had a different
>microcontroller with an additional UART, but sometimes you have to make
>things work with the board you have. (And it was fun :-) )
Huh. Well, ok; sounds challenging!
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-07-03 17:00 +0200 |
| Message-ID | <1128iq9$3f84f$1@dont-email.me> |
| In reply to | #400289 |
On 01/07/2026 15:16, Dan Cross wrote: > In article <111p2a1$34arg$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >>> [snip] >>>>> [snip] >>>>> I just checked and it looks like ST ships PL011's in a bunch of >>>>> Cortex-M class parts. >>>> >>>> Have you a reference for those? >>>> [snip] >>> >>> Actually, I think I was just wrong; the device I was thinking of >>> that used the PL011 off the shelf from ST was the ARM926 based >>> chip you mentioned: it's old, and they don't have them in their >>> Cortex-M offerings. >> >> OK. Those were older chips - in the earlier days of ARM processor SoCs >> (though ST was a little later than many others), designs from the likes >> of NXP and ST were based more on complete packages or reference designs >>from ARM. The types of IP licenses these manufacturers have with ARM >> have varied as they moved from making just a few ARM devices along with >> all their other chips, towards having ARM processor and microcontroller >> cores across a solid proportion of their portfolios. I expect they >> started with whatever was easiest for other ARM users (thus the PL011), >> and now integrate a lot more of their own peripherals in their chips. It >> is also not uncommon that big manufacturers buy smaller manufacturers, >> and so their early devices have whatever the small manufacturers used - >> that will be off-the-shelf peripherals. Then later on, they do more >> integration and use their own peripherals (saving them money). I don't >> know the history of ST's ARM processor SoCs at all - despite being one >> of the biggest in the ARM microcontroller world, they are relative >> newcomers to the processor / embedded Linux side of things. > > My guess is that for the embedded market, they favor cost saving > compounded by volume; at scale, a 5c difference in the cost of a > microcontroller can add up. For application-profile cores, it's > less of a consideration on the margins, so they favor > standardization to leverage network effects around software > ecosystems. > I very much agree. I've seen ARM microcontrollers for less than $0.40, and lower costs are available for those with more serious volumes. So margins are sometimes very tight. There is also the matter of standardisation and familiarity - on a processor SoC, people might be more familiar with 16550 or PL011 uarts, so something approximately like them could be an advantage. (Although I suspect most users don't care - someone else will have written the drivers, and the user space code is mostly independent of the details.) For microcontrollers, people moving to a particular microcontroller might be familiar with peripherals from other microcontrollers by the same manufacturer - it is the same standardisation argument, but from the other direction. >>> The RPi2040 and Zynq boards seem to have PL011s, but are much >>> lower volume. >> >> That is perhaps slightly unexpected (for me) - both come from companies >> that can happily make their own UART implementations to avoid additional >> royalties to ARM, and money is always the main motivator. But maybe >> they don't pay much, or maybe they make their own PL011-compatible UARTs >> - ARM license terms are rarely public knowledge! > > For RPi, this was one of their first in-house designs, versus > using one of Broadcom's offerings, wasn't it? Perhaps they went > with off-the-shelf IP for the UART to minimize risk. For Zynq, > I suspect the cost of the FPGA dwarfs whatever savings they'd > get from their own UART, so they favor software compatibility. > >>>> That is very interesting, and somewhat unexpected. Thanks for the >>>> example. Where is this riscv core from? >>> >>> That is from a JH7110 SoC in a StarFive VisionFive2 SBC. I use >>> those things for little utility machines around the house (DHCP, >>> DNS, etc). >> >> I think it's a good thing if there are more Risc-V devices around - ARM >> is too dominant in many areas, and while standardisation on common >> platforms is convenient, competition is good too. >> >> How does this board compare to the ubiquitous Raspberry Pi's for such >> uses? Neither DHCP nor DNS are particularly challenging applications, >> unless you have a huge network, but your "etc." might cover other things. > > I agree, and I'm happy to have RISC-V boards to work with. > However, compared to an RPi, it's not fast; maybe comparable to > an RPi2 or RPi3. However, it has native NVMe and an M.2 slot at > Gen2x4 and a real Ethernet PHY (not a USB bridge), that can > eliminate some of the IO slowness of older RPi hardare. That's a fair tradeoff for such uses. DNS and DHCP are not particularly demanding on the processor side, and Pi2 and Pi3 are actually quite capable systems (as long as you don't need a gui). > > In terms of competative application cores available at scale, > the RV64 ecosystem has a lot of work to do. > Hopefully it will get there. There are a few RV32 microcontrollers around, but I'd like to see more. (I'd be happy with other alternatives - again, competition is a good thing. MIPS had a chance a number of years ago, but I think Microchip messed it up for them.) >>> [snip] >>> No idea. About eight years ago, on a 192 Xeon core system, with >>> 256GB of RAM and a 200Gbps NIC plus about 16TB of NVMe, I >>> regularly saw ~250k interrupts/sec across the fabric in the >>> steady-state, bursting up to a million or so. >> >> Perhaps we can conclude that Linux systems can handle lots of >> interrupts, but too many become inefficient and have a risk of losing >> some. Careful system tuning and consideration of the pattern of >> interrupts lets you handle more without losses, but smarter hardware the >> reduces the interrupt rate is essential at some point. And attempts at >> putting figures on things is going to be too vague or require far more >> detail of the hardware and applications than appropriate here. > > Agreed. > >>> [snip] >>> That, frankly, seems kind of hard to believe: the math just does >>> not add up, even assuming no wait states for access to e.g. >>> SRAM and single-cycle memory access times, with an instruction >>> dispatched per cycle; did you just, like, NEVER touch memory or >>> more than 2 or 3 registers in that path? Was the internal CPU >>> frequency 18MHz, or was that a reference oscillator? >> >> No, the chip ran at 18.432 MHz - it was an 8-bit AVR microcontroller. >> Most instructions are single cycle, except for branches (mostly 1 or 2 >> cycles), call / return, and load/store to memory (2 cycles). That >> application was all in assembly, and I split the cpu's 32 registers >> between ones used in the software UART timer interrupt, and ones used in >> the main code. Thus no cycles were needed for stacking or restoring >> registers on interrupts, or other context switch stuff other than the PC >> and flag registers. >> >> It would, of course, have made more sense to have had a different >> microcontroller with an additional UART, but sometimes you have to make >> things work with the board you have. (And it was fun :-) ) > > Huh. Well, ok; sounds challenging! > It was indeed challenging. I did a few fun things with AVR microcontrollers many years ago - programming in assembly. (They work well enough for C programming too, but then you are stuck with more conventional C programming models.) They have 32 8-bit registers - enough that you can split things up and dedicate registers to different interrupts, threads, applications, etc. I had one program that did cooperative multitasking between three threads, with a context switch taking only about 10 cycles since only the PC and SP needed to be swapped. Of course you have to be a lot more careful and restricted when writing such code, so you don't stomp on the registers belonging to another thread, and it does not scale well.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-27 20:49 +0300 |
| Message-ID | <20260627204924.00002fef@yahoo.com> |
| In reply to | #400255 |
On Sat, 27 Jun 2026 01:52:24 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <111jnmp$3tni8$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: > >On 25/06/2026 13:29, Dan Cross wrote: > >> In article <111gkgm$2vhih$1@dont-email.me>, > >> David Brown <david.brown@hesbynett.no> wrote: > >>> On 24/06/2026 12:47, Dan Cross wrote: > >>>>[snip] > >> Again, not something I was commenting on. Low(er) volume != > >> obsolete. > > > >OK. I have already accepted that "obsolete" was an exaggeration. > >More appropriate would be "not suitable for new designs". > > Something approximately 16550-shaped will be in essentially > every new x86 SoC, because there's basically no incentive to > change: modern variants support DMA, speeds in the MBAUD, are > not tied to x86 programmed IO, and are fine for consoles, > communication between disparate IPs on a board, and so on. > And why do you call such thing "16550-shaped" ? What exactly is left from 16550?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-01 13:17 +0000 |
| Message-ID | <112340g$871$1@reader1.panix.com> |
| In reply to | #400260 |
In article <20260627204924.00002fef@yahoo.com>,
Michael S <already5chosen@yahoo.com> wrote:
>On Sat, 27 Jun 2026 01:52:24 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> In article <111jnmp$3tni8$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>> >On 25/06/2026 13:29, Dan Cross wrote:
>> >> In article <111gkgm$2vhih$1@dont-email.me>,
>> >> David Brown <david.brown@hesbynett.no> wrote:
>> >>> On 24/06/2026 12:47, Dan Cross wrote:
>> >>>>[snip]
>> >> Again, not something I was commenting on. Low(er) volume !=
>> >> obsolete.
>> >
>> >OK. I have already accepted that "obsolete" was an exaggeration.
>> >More appropriate would be "not suitable for new designs".
>>
>> Something approximately 16550-shaped will be in essentially
>> every new x86 SoC, because there's basically no incentive to
>> change: modern variants support DMA, speeds in the MBAUD, are
>> not tied to x86 programmed IO, and are fine for consoles,
>> communication between disparate IPs on a board, and so on.
>
>And why do you call such thing "16550-shaped" ?
>What exactly is left from 16550?
...the registers and bits in them?
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-27 18:50 +0000 |
| Subject | UARTs (was Re: this guy talks about fopen (and im thinking about fopen for network)) |
| Message-ID | <GXU%R.15941$DyOf.14341@fx24.iad> |
| In reply to | #400255 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <111jnmp$3tni8$1@dont-email.me>, >David Brown <david.brown@hesbynett.no> wrote: <snip> > >I think the DW part I mentioned does, basically, all of those >thngs. I don't know about swapping Rx/Tx pins; I suspect that'd >be a function of the pin mux on the parts I'm most familiar >with. Minor nit, DW (Designware) is synthesizable IP from Synopsys that is included typically in SoC (or BMC) designs. It's not a standalone part per se. https://www.synopsys.com/designware-ip/soc-infrastructure-ip/amba/amba-uart.html
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-23 17:39 +0000 |
| Message-ID | <Zwz_R.2$zNZ2.1@fx16.iad> |
| In reply to | #400206 |
David Brown <david.brown@hesbynett.no> writes: >On 23/06/2026 17:35, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 22/06/2026 16:56, Scott Lurndal wrote: >>>> Michael S <already5chosen@yahoo.com> writes: >>>>> On Sun, 21 Jun 2026 12:18:39 +0200 >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>> > >>> or >>> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. >> >> Which describes several long-obsolete API implementations. >> > >OK. > >But there is still termio stuff needed in the setup of the UART, when >all that is needed in almost all cases this century is picking the baud >rate, possibly enabling the RTS line as an RS-485 driver enable, picking >8,n,1 (other options are rare, but not quite non-existent), and then >reading and writing characters. I would separate those into two distinct operations: - One-time setup. Setting the line characteristics (baud rate, stop-bits, parity) and the UART characteristics (flow control, Rx and Tx FIFOs, Carrier Detect). For which there are standard POSIX interfaces (tcsetattr/tcgetattr) - steady-state operations, such as reading and writing which use the normal file I/O operations (read, write, poll, et alia) > There are other possible features that >can be useful for UARTs, such as getting feedback when everything is >sent (via a semaphore, condition variable, or similar synchronisation >mechanism), That really depends on OS API. STDIO buffers output, and provides a mechanism to flush the buffers. If one bypasses stdio and uses read/write, the programmer can call tcdrain() to ensure the data has been transmitted or set VMIN=1 and VTIME=0 with tcsetattr to avoid any buffering in the kernel driver. > getting feedback when there has been a pause since the last >received character, and other such things. AFAIK these are not >available with standard Linux serial port handling. The poll(2) system call can be used for this purpose, as it can timeout if there is no character received within a specified interval.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-23 21:11 +0200 |
| Message-ID | <111elok$2g1qh$2@dont-email.me> |
| In reply to | #400208 |
On 23/06/2026 19:39, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 23/06/2026 17:35, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 22/06/2026 16:56, Scott Lurndal wrote: >>>>> Michael S <already5chosen@yahoo.com> writes: >>>>>> On Sun, 21 Jun 2026 12:18:39 +0200 >>>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> > >> >>>> or >>>> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. >>> >>> Which describes several long-obsolete API implementations. >>> >> >> OK. >> >> But there is still termio stuff needed in the setup of the UART, when >> all that is needed in almost all cases this century is picking the baud >> rate, possibly enabling the RTS line as an RS-485 driver enable, picking >> 8,n,1 (other options are rare, but not quite non-existent), and then >> reading and writing characters. > > I would separate those into two distinct operations: > Yes. > - One-time setup. Setting the line characteristics (baud rate, > stop-bits, parity) and the UART characteristics (flow > control, Rx and Tx FIFOs, Carrier Detect). For which there > are standard POSIX interfaces (tcsetattr/tcgetattr) > > - steady-state operations, such as reading and writing which > use the normal file I/O operations (read, write, poll, et alia) > Agreed. It's only the setup that is a pain because of legacy terminal support. >> > There are other possible features that >> can be useful for UARTs, such as getting feedback when everything is >> sent (via a semaphore, condition variable, or similar synchronisation >> mechanism), > > That really depends on OS API. STDIO buffers output, and provides > a mechanism to flush the buffers. If one bypasses stdio and uses > read/write, the programmer can call tcdrain() to ensure the data > has been transmitted or set VMIN=1 and VTIME=0 with tcsetattr > to avoid any buffering in the kernel driver. > >> getting feedback when there has been a pause since the last >> received character, and other such things. AFAIK these are not >> available with standard Linux serial port handling. > > The poll(2) system call can be used for this purpose, as it > can timeout if there is no character received within a > specified interval. > I guess I am used to microcontroller programming - things happen far more directly and efficiently there. (Or I use Python, were the source code is simple and easy, and you don't think about the layers in between the code and the hardware!)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-24 11:04 +0000 |
| Message-ID | <111gdk0$1et$1@reader1.panix.com> |
| In reply to | #400211 |
In article <111elok$2g1qh$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 23/06/2026 19:39, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 23/06/2026 17:35, Scott Lurndal wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 22/06/2026 16:56, Scott Lurndal wrote:
>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>>> On Sun, 21 Jun 2026 12:18:39 +0200
>>>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>>>
>>
>>>
>>>>> or
>>>>> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>.
>>>>
>>>> Which describes several long-obsolete API implementations.
>>>>
>>>
>>> OK.
>>>
>>> But there is still termio stuff needed in the setup of the UART, when
>>> all that is needed in almost all cases this century is picking the baud
>>> rate, possibly enabling the RTS line as an RS-485 driver enable, picking
>>> 8,n,1 (other options are rare, but not quite non-existent), and then
>>> reading and writing characters.
>>
>> I would separate those into two distinct operations:
>>
>
>Yes.
>
>> - One-time setup. Setting the line characteristics (baud rate,
>> stop-bits, parity) and the UART characteristics (flow
>> control, Rx and Tx FIFOs, Carrier Detect). For which there
>> are standard POSIX interfaces (tcsetattr/tcgetattr)
>>
>> - steady-state operations, such as reading and writing which
>> use the normal file I/O operations (read, write, poll, et alia)
>>
>
>Agreed.
>
>It's only the setup that is a pain because of legacy terminal support.
Is it really that hard?
struct termios term;
memset(&term, 0, sizeof(term));
cfmakeraw(&term); // BSD extension
cfsetispeed(&term, B38400);
cfsetospeed(&term, B38400);
term.c_cflag |= CS8 | CREAD | CRTSCTS;
tcsetattr(fd, TCSANOW, &term)
Of course, on plan 9, it's even easier:
echo -n b38400 l8 pn s1 >/dev/eia1ctl
>> There are other possible features that
>>> can be useful for UARTs, such as getting feedback when everything is
>>> sent (via a semaphore, condition variable, or similar synchronisation
>>> mechanism),
>>
>> That really depends on OS API. STDIO buffers output, and provides
>> a mechanism to flush the buffers. If one bypasses stdio and uses
>> read/write, the programmer can call tcdrain() to ensure the data
>> has been transmitted or set VMIN=1 and VTIME=0 with tcsetattr
>> to avoid any buffering in the kernel driver.
>>
>>> getting feedback when there has been a pause since the last
>>> received character, and other such things. AFAIK these are not
>>> available with standard Linux serial port handling.
>>
>> The poll(2) system call can be used for this purpose, as it
>> can timeout if there is no character received within a
>> specified interval.
>
>I guess I am used to microcontroller programming - things happen far
>more directly and efficiently there. (Or I use Python, were the source
>code is simple and easy, and you don't think about the layers in between
>the code and the hardware!)
"Efficiently" with respect to what? One could argue that MCUs
waste a lot of CPU cycles because their software is usually
terribly unsophisticated. A blocking system calll like `poll`
allows the operating system to context switch to some other
runnable task while the poll is pending, without the complexity
of directly handling interrupts.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-24 15:27 +0200 |
| Message-ID | <111gm0p$2vhih$2@dont-email.me> |
| In reply to | #400223 |
On 24/06/2026 13:04, Dan Cross wrote: > In article <111elok$2g1qh$2@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 23/06/2026 19:39, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 23/06/2026 17:35, Scott Lurndal wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> On 22/06/2026 16:56, Scott Lurndal wrote: >>>>>>> Michael S <already5chosen@yahoo.com> writes: >>>>>>>> On Sun, 21 Jun 2026 12:18:39 +0200 >>>>>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>>>> >>> >>>> >>>>>> or >>>>>> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. >>>>> >>>>> Which describes several long-obsolete API implementations. >>>>> >>>> >>>> OK. >>>> >>>> But there is still termio stuff needed in the setup of the UART, when >>>> all that is needed in almost all cases this century is picking the baud >>>> rate, possibly enabling the RTS line as an RS-485 driver enable, picking >>>> 8,n,1 (other options are rare, but not quite non-existent), and then >>>> reading and writing characters. >>> >>> I would separate those into two distinct operations: >>> >> >> Yes. >> >>> - One-time setup. Setting the line characteristics (baud rate, >>> stop-bits, parity) and the UART characteristics (flow >>> control, Rx and Tx FIFOs, Carrier Detect). For which there >>> are standard POSIX interfaces (tcsetattr/tcgetattr) >>> >>> - steady-state operations, such as reading and writing which >>> use the normal file I/O operations (read, write, poll, et alia) >>> >> >> Agreed. >> >> It's only the setup that is a pain because of legacy terminal support. > > Is it really that hard? > > struct termios term; > memset(&term, 0, sizeof(term)); > cfmakeraw(&term); // BSD extension > cfsetispeed(&term, B38400); > cfsetospeed(&term, B38400); > term.c_cflag |= CS8 | CREAD | CRTSCTS; > tcsetattr(fd, TCSANOW, &term) > It took a good deal more than that when I did it. But it is certainly possible that my reference sources for the task were not the best available. Note also that it's not just the number of lines of C code - it's knowing what those lines are, what settings you need, which headers to find the declarations, etc. > Of course, on plan 9, it's even easier: > > echo -n b38400 l8 pn s1 >/dev/eia1ctl > >>> There are other possible features that >>>> can be useful for UARTs, such as getting feedback when everything is >>>> sent (via a semaphore, condition variable, or similar synchronisation >>>> mechanism), >>> >>> That really depends on OS API. STDIO buffers output, and provides >>> a mechanism to flush the buffers. If one bypasses stdio and uses >>> read/write, the programmer can call tcdrain() to ensure the data >>> has been transmitted or set VMIN=1 and VTIME=0 with tcsetattr >>> to avoid any buffering in the kernel driver. >>> >>>> getting feedback when there has been a pause since the last >>>> received character, and other such things. AFAIK these are not >>>> available with standard Linux serial port handling. >>> >>> The poll(2) system call can be used for this purpose, as it >>> can timeout if there is no character received within a >>> specified interval. >> >> I guess I am used to microcontroller programming - things happen far >> more directly and efficiently there. (Or I use Python, were the source >> code is simple and easy, and you don't think about the layers in between >> the code and the hardware!) > > "Efficiently" with respect to what? One could argue that MCUs > waste a lot of CPU cycles because their software is usually > terribly unsophisticated. A blocking system calll like `poll` > allows the operating system to context switch to some other > runnable task while the poll is pending, without the complexity > of directly handling interrupts. > No, I don't think you can argue that at all - sophisticated software at the OS level wastes as many cycles as sophisticated software at the application level. In my microcontroller programming, the serial handling is as sophisticated or simple as I need it to be. It could be application code reading and writing hardware registers directly, with busy-waiting loops. More likely data is transferred into or out of DMA based ring buffers that feed the UART. What I don't have is layers of possible translations because the user might be connecting to a VT100, or expecting the driver to handle backspace and XON/XOFF. I don't have to pass data up and down through the VFS and devfs, checking user permissions, or system calls that have to check everything coming from user space. I realise that a lot of this is necessary in Linux (or any other general-purpose OS) - you can't make a system safe for multiple users and multiple programmers without lots of checks, and you can't allow "echo Hello > /dev/ttyUSB0" without lots of abstraction. Directly handling interrupts in a microcontroller is not particularly complex - it's daily work for microcontroller developers. And we too know how to have blocking calls and multiple threads.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-25 11:56 +0000 |
| Message-ID | <111j513$6n4$1@reader1.panix.com> |
| In reply to | #400229 |
In article <111gm0p$2vhih$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 24/06/2026 13:04, Dan Cross wrote:
>> In article <111elok$2g1qh$2@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> [snip]
>>> Agreed.
>>>
>>> It's only the setup that is a pain because of legacy terminal support.
>>
>> Is it really that hard?
>>
>> struct termios term;
>> memset(&term, 0, sizeof(term));
>> cfmakeraw(&term); // BSD extension
>> cfsetispeed(&term, B38400);
>> cfsetospeed(&term, B38400);
>> term.c_cflag |= CS8 | CREAD | CRTSCTS;
>> tcsetattr(fd, TCSANOW, &term)
>>
>
>It took a good deal more than that when I did it. But it is certainly
>possible that my reference sources for the task were not the best
>available. Note also that it's not just the number of lines of C code -
>it's knowing what those lines are, what settings you need, which headers
>to find the declarations, etc.
One presumes that you if you are using, say, the POSIX
interfaces, you'll have some idea of how to write code for POSIX
and have access to a reference. My system's man pages are
reasonable for the latter.
>>> [snip]
>>> I guess I am used to microcontroller programming - things happen far
>>> more directly and efficiently there. (Or I use Python, were the source
>>> code is simple and easy, and you don't think about the layers in between
>>> the code and the hardware!)
>>
>> "Efficiently" with respect to what? One could argue that MCUs
>> waste a lot of CPU cycles because their software is usually
>> terribly unsophisticated. A blocking system calll like `poll`
>> allows the operating system to context switch to some other
>> runnable task while the poll is pending, without the complexity
>> of directly handling interrupts.
>
>No, I don't think you can argue that at all - sophisticated software at
>the OS level wastes as many cycles as sophisticated software at the
>application level.
Again, I ask, "efficiently" with respect to what? Note what I
said: "One could argue that MCUs waste a lot of CPU cycles
because their software _is usually terribly unsophisticated_":
emphasis added.
>In my microcontroller programming, the serial handling is as
>sophisticated or simple as I need it to be. It could be application
>code reading and writing hardware registers directly, with busy-waiting
>loops. More likely data is transferred into or out of DMA based ring
>buffers that feed the UART.
>
>What I don't have is layers of possible translations because the user
>might be connecting to a VT100, or expecting the driver to handle
>backspace and XON/XOFF.
You are conflating the TTY layer in Unix-style systems with the
serial port driver, specifically. I will acknowledge that this
is a problem; a TTY-abstraction might have made sense in the
1970s ("VT100?! Luxury. I'm stuck with an ASR Model 37
teletype...."), but does not make a lot of sense now, but that
does not mean that large systems _need_ to use that metaphor.
See the Plan 9 examples I keep sprinkling around; that system
doesn't have a TTY abstraction at all.
>I don't have to pass data up and down through
>the VFS and devfs, checking user permissions, or system calls that have
>to check everything coming from user space. I realise that a lot of
>this is necessary in Linux (or any other general-purpose OS) - you can't
>make a system safe for multiple users and multiple programmers without
>lots of checks, and you can't allow "echo Hello > /dev/ttyUSB0" without
>lots of abstraction.
The purpose of an operating system is to control hardware,
isolate software principles from one another, and provide useful
programming abstractions. Essentially what you're saying is
that you don't want or need that, for some kinds of programs.
That's fine. But to extrapolate from that to, "and this
category of software is more efficient", as an absolute
statement, is what I take exception to: there's too much
disconfirming evidence to the contrary. Perhaps not in the
programs you personally write, but I took your statement was
general and not restricted to only those programs.
>Directly handling interrupts in a microcontroller is not particularly
>complex - it's daily work for microcontroller developers.
Yes, because if your needs are not as general as those demanded
by general purposes operating systems on general purpose CPUs,
it can be made reasonably simple. As I mentioned, most (not
all) programs that target microcontrollers are not terribly
sophisticated, and have very modest requirements in this regard.
>And we too know how to have blocking calls and multiple threads.
...and there are embedded OSes that have system calls and
privileged modes that restrict access to the hardware, too. :-}
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-25 21:30 +0200 |
| Message-ID | <111jvkg$168d$1@dont-email.me> |
| In reply to | #400242 |
On 25/06/2026 13:56, Dan Cross wrote:
> In article <111gm0p$2vhih$2@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 24/06/2026 13:04, Dan Cross wrote:
>>> In article <111elok$2g1qh$2@dont-email.me>,
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> [snip]
>>>> Agreed.
>>>>
>>>> It's only the setup that is a pain because of legacy terminal support.
>>>
>>> Is it really that hard?
>>>
>>> struct termios term;
>>> memset(&term, 0, sizeof(term));
>>> cfmakeraw(&term); // BSD extension
>>> cfsetispeed(&term, B38400);
>>> cfsetospeed(&term, B38400);
>>> term.c_cflag |= CS8 | CREAD | CRTSCTS;
>>> tcsetattr(fd, TCSANOW, &term)
>>>
>>
>> It took a good deal more than that when I did it. But it is certainly
>> possible that my reference sources for the task were not the best
>> available. Note also that it's not just the number of lines of C code -
>> it's knowing what those lines are, what settings you need, which headers
>> to find the declarations, etc.
>
> One presumes that you if you are using, say, the POSIX
> interfaces, you'll have some idea of how to write code for POSIX
> and have access to a reference. My system's man pages are
> reasonable for the latter.
>
Sure. But not all references are created equal, and I am merely saying
that the references or examples that I used might not have been the
best, or were maybe outdated or overly complex.
>>>> [snip]
>>>> I guess I am used to microcontroller programming - things happen far
>>>> more directly and efficiently there. (Or I use Python, were the source
>>>> code is simple and easy, and you don't think about the layers in between
>>>> the code and the hardware!)
>>>
>>> "Efficiently" with respect to what? One could argue that MCUs
>>> waste a lot of CPU cycles because their software is usually
>>> terribly unsophisticated. A blocking system calll like `poll`
>>> allows the operating system to context switch to some other
>>> runnable task while the poll is pending, without the complexity
>>> of directly handling interrupts.
>>
>> No, I don't think you can argue that at all - sophisticated software at
>> the OS level wastes as many cycles as sophisticated software at the
>> application level.
>
> Again, I ask, "efficiently" with respect to what? Note what I
> said: "One could argue that MCUs waste a lot of CPU cycles
> because their software _is usually terribly unsophisticated_":
> emphasis added.
Let me rephrase - I don't think you can /reasonably/ argue that, without
at a minimum some concrete examples of MCUs wasting lots of CPU cycles
due to terribly unsophisticated software for UART handling, and a
justification for thinking it is common practice. I suppose you could
say that sometimes microcontroller software works by polling UART
hardware status registers in busy-waiting loops, but it is not likely to
be common practice except in special circumstances.
If code on my microcontroller wants to sent data to the UART (i.e., put
it into the software FIFO that feeds the hardware FIFO), the call is
perhaps 30 cycles plus maybe 6 or 8 per byte sent. Entering a "wait for
end of received frame event" is maybe 50 cycles, and the time from the
UART detecting the idle time, triggering the event, and the resulting
context switch starting up the blocked task is perhaps 200 cycles.
Those are all rough guesses out of my head, I have not measured them.
How many cpu cycles does it take for a program on Linux to send out a
dozen bytes on a UART, or between the UART hardware detecting the
receive timeout to the polling process exiting the poll() call?
>
>> In my microcontroller programming, the serial handling is as
>> sophisticated or simple as I need it to be. It could be application
>> code reading and writing hardware registers directly, with busy-waiting
>> loops. More likely data is transferred into or out of DMA based ring
>> buffers that feed the UART.
>>
>> What I don't have is layers of possible translations because the user
>> might be connecting to a VT100, or expecting the driver to handle
>> backspace and XON/XOFF.
>
> You are conflating the TTY layer in Unix-style systems with the
> serial port driver, specifically. I will acknowledge that this
> is a problem; a TTY-abstraction might have made sense in the
> 1970s ("VT100?! Luxury. I'm stuck with an ASR Model 37
> teletype...."), but does not make a lot of sense now, but that
> does not mean that large systems _need_ to use that metaphor.
> See the Plan 9 examples I keep sprinkling around; that system
> doesn't have a TTY abstraction at all.
>
I think we agree here. I have no doubts that you can have a "big"
system, with the features and overheads that implies (like security, and
running multiple programs rather than just multiple threads), without
mixing tty's and serial ports.
>> I don't have to pass data up and down through
>> the VFS and devfs, checking user permissions, or system calls that have
>> to check everything coming from user space. I realise that a lot of
>> this is necessary in Linux (or any other general-purpose OS) - you can't
>> make a system safe for multiple users and multiple programmers without
>> lots of checks, and you can't allow "echo Hello > /dev/ttyUSB0" without
>> lots of abstraction.
>
> The purpose of an operating system is to control hardware,
> isolate software principles from one another, and provide useful
> programming abstractions. Essentially what you're saying is
> that you don't want or need that, for some kinds of programs.
>
There a range of possible OS types, with kernels ranging from micro to
monolithic, widely different ideas of how much separation different
tasks need, and how much hardware control is done in the OS or in other
code. It is certainly the case that the features I want from an RTOS on
a microcontroller differ significantly from what I want in a general
purpose OS on a PC or other "big" system.
> That's fine. But to extrapolate from that to, "and this
> category of software is more efficient", as an absolute
> statement, is what I take exception to: there's too much
> disconfirming evidence to the contrary. Perhaps not in the
> programs you personally write, but I took your statement was
> general and not restricted to only those programs.
>
To be clear - when comparing efficiency, you have to know when you are
comparing apples to apples, and apples to oranges. My point is that for
many tasks, microcontrollers are more efficient but it is an apples to
oranges comparison in the details since the big OS has many other
important considerations.
>> Directly handling interrupts in a microcontroller is not particularly
>> complex - it's daily work for microcontroller developers.
>
> Yes, because if your needs are not as general as those demanded
> by general purposes operating systems on general purpose CPUs,
> it can be made reasonably simple.
Exactly.
Microcontroller code will typically be much more focused and specialised.
> As I mentioned, most (not
> all) programs that target microcontrollers are not terribly
> sophisticated, and have very modest requirements in this regard.
>
I am still not sure what you are saying here. It sounds a bit like you
have been saying the code is not sophisticated and therefore inefficient
and wasteful of cycles, when it is often the case that code is not very
sophisticated because it can be done simply and efficiently.
>> And we too know how to have blocking calls and multiple threads.
>
> ...and there are embedded OSes that have system calls and
> privileged modes that restrict access to the hardware, too. :-}
>
Yes, there are. Again, I have used some of these at times.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-27 02:22 +0000 |
| Message-ID | <111nc5a$4l2$1@reader1.panix.com> |
| In reply to | #400249 |
In article <111jvkg$168d$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 25/06/2026 13:56, Dan Cross wrote:
>> In article <111gm0p$2vhih$2@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 24/06/2026 13:04, Dan Cross wrote:
>>>> In article <111elok$2g1qh$2@dont-email.me>,
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> [snip]
>>>>> Agreed.
>>>>>
>>>>> It's only the setup that is a pain because of legacy terminal support.
>>>>
>>>> Is it really that hard?
>>>>
>>>> struct termios term;
>>>> memset(&term, 0, sizeof(term));
>>>> cfmakeraw(&term); // BSD extension
>>>> cfsetispeed(&term, B38400);
>>>> cfsetospeed(&term, B38400);
>>>> term.c_cflag |= CS8 | CREAD | CRTSCTS;
>>>> tcsetattr(fd, TCSANOW, &term)
>>>
>>> It took a good deal more than that when I did it. But it is certainly
>>> possible that my reference sources for the task were not the best
>>> available. Note also that it's not just the number of lines of C code -
>>> it's knowing what those lines are, what settings you need, which headers
>>> to find the declarations, etc.
>>
>> One presumes that you if you are using, say, the POSIX
>> interfaces, you'll have some idea of how to write code for POSIX
>> and have access to a reference. My system's man pages are
>> reasonable for the latter.
>
>Sure. But not all references are created equal, and I am merely saying
>that the references or examples that I used might not have been the
>best, or were maybe outdated or overly complex.
Ok, but that has nothing to do with the interface, but rather,
the resources available to you to learn the interface. The two
are qualitatively different.
>>>>> [snip]
>>>>> I guess I am used to microcontroller programming - things happen far
>>>>> more directly and efficiently there. (Or I use Python, were the source
>>>>> code is simple and easy, and you don't think about the layers in between
>>>>> the code and the hardware!)
>>>>
>>>> "Efficiently" with respect to what? One could argue that MCUs
>>>> waste a lot of CPU cycles because their software is usually
>>>> terribly unsophisticated. A blocking system calll like `poll`
>>>> allows the operating system to context switch to some other
>>>> runnable task while the poll is pending, without the complexity
>>>> of directly handling interrupts.
>>>
>>> No, I don't think you can argue that at all - sophisticated software at
>>> the OS level wastes as many cycles as sophisticated software at the
>>> application level.
>>
>> Again, I ask, "efficiently" with respect to what? Note what I
>> said: "One could argue that MCUs waste a lot of CPU cycles
>> because their software _is usually terribly unsophisticated_":
>> emphasis added.
>
>Let me rephrase - I don't think you can /reasonably/ argue that, without
>at a minimum some concrete examples of MCUs wasting lots of CPU cycles
>due to terribly unsophisticated software for UART handling, and a
>justification for thinking it is common practice. I suppose you could
>say that sometimes microcontroller software works by polling UART
>hardware status registers in busy-waiting loops, but it is not likely to
>be common practice except in special circumstances.
I'll wager a month's salary that the _vast_ bulk of MCU software
sits in a tight loop polling one or two bits in a couple of
registers. Sophisticated context handling, thread switching
(a lot of 8-bit MCUs just don't have enough memory available for
multiple stacks, let alone thread save areas), or even
interrupts are _probably_ pretty rare.
>If code on my microcontroller wants to sent data to the UART (i.e., put
>it into the software FIFO that feeds the hardware FIFO), the call is
>perhaps 30 cycles plus maybe 6 or 8 per byte sent. Entering a "wait for
>end of received frame event" is maybe 50 cycles, and the time from the
>UART detecting the idle time, triggering the event, and the resulting
>context switch starting up the blocked task is perhaps 200 cycles.
>Those are all rough guesses out of my head, I have not measured them.
>How many cpu cycles does it take for a program on Linux to send out a
>dozen bytes on a UART, or between the UART hardware detecting the
>receive timeout to the polling process exiting the poll() call?
That's an apples/oranges comparison. What you really want to
ask is, how much time does it take to enqueue data into the
outbound ring buffer for a particular device, and how many
cycles does it take to fill the output FIFO from the ring when
space becomes available? Both of those costs _can_ be very low.
What is the cost of busy-waiting? It's hard to say.
If you only have a small handful of tasks, and everything is in
the same address space, then sure, picking a different thread to
run and doing the coroutine jump dance to resume it isn't that
hard.
Distance between timing out (say) a poll and a user program
exiting a system call is difficult to measure, since a polled
event happening doesn't mean that the system call automatically
returns; it means that the task that invoked the system call is
unblocked gets marked runnable; when it actually runs again
depends on a lot of factors (load vs available resources;
scheduling latency; time quantums assigned to currently running
tasks; etc). Most Unix/Linux-style schedulers are not real
time schedulers; so we freqntly just say, "eventually."
There's a whole branch of systems research devoted to doing this
as efficiently as possible.
>> [snip]
>> The purpose of an operating system is to control hardware,
>> isolate software principles from one another, and provide useful
>> programming abstractions. Essentially what you're saying is
>> that you don't want or need that, for some kinds of programs.
>
>There a range of possible OS types, with kernels ranging from micro to
>monolithic, widely different ideas of how much separation different
>tasks need, and how much hardware control is done in the OS or in other
>code. It is certainly the case that the features I want from an RTOS on
>a microcontroller differ significantly from what I want in a general
>purpose OS on a PC or other "big" system.
>
>> That's fine. But to extrapolate from that to, "and this
>> category of software is more efficient", as an absolute
>> statement, is what I take exception to: there's too much
>> disconfirming evidence to the contrary. Perhaps not in the
>> programs you personally write, but I took your statement was
>> general and not restricted to only those programs.
>
>To be clear - when comparing efficiency, you have to know when you are
>comparing apples to apples, and apples to oranges. My point is that for
>many tasks, microcontrollers are more efficient but it is an apples to
>oranges comparison in the details since the big OS has many other
>important considerations.
That's kind of my point. The statement you made that I
responded to was that microcontroller software is "more
efficient" than what a general purpose OS does. It is more
nuanced than that, as it so often is: this is one reason I
dislike categorical statements of that nature.
>>> Directly handling interrupts in a microcontroller is not particularly
>>> complex - it's daily work for microcontroller developers.
>>
>> Yes, because if your needs are not as general as those demanded
>> by general purposes operating systems on general purpose CPUs,
>> it can be made reasonably simple.
>
>Exactly.
>
>Microcontroller code will typically be much more focused and specialised.
Which doesn't necessarily mean more efficient. That was my
point.
>> As I mentioned, most (not
>> all) programs that target microcontrollers are not terribly
>> sophisticated, and have very modest requirements in this regard.
>
>I am still not sure what you are saying here. It sounds a bit like you
>have been saying the code is not sophisticated and therefore inefficient
>and wasteful of cycles, when it is often the case that code is not very
>sophisticated because it can be done simply and efficiently.
What I am saying is that words have meaning, and if you're going
to make an absolute statement about the relative efficiency of
one category of system versus another, you need to qualify what
you mean.
>>> And we too know how to have blocking calls and multiple threads.
>>
>> ...and there are embedded OSes that have system calls and
>> privileged modes that restrict access to the hardware, too. :-}
>
>Yes, there are. Again, I have used some of these at times.
The salient characteristic is that they share many of the same
properties of OSes on larger systems: MPUs might divide the
available address space into discrete regions, and so context
switching now involves memory-management hardware, where perhaps
it did not before. The point is that, even within "embedded
systems" there's too much variability to make absolute
statements. In general, I advice refraining from such for
precisely that reason.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-28 18:59 +0200 |
| Message-ID | <111rjtr$3ofre$1@dont-email.me> |
| In reply to | #400257 |
On 27/06/2026 04:22, Dan Cross wrote:
> In article <111jvkg$168d$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 25/06/2026 13:56, Dan Cross wrote:
>>> In article <111gm0p$2vhih$2@dont-email.me>,
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 24/06/2026 13:04, Dan Cross wrote:
>>>>> In article <111elok$2g1qh$2@dont-email.me>,
>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>> [snip]
>>
>> Let me rephrase - I don't think you can /reasonably/ argue that, without
>> at a minimum some concrete examples of MCUs wasting lots of CPU cycles
>> due to terribly unsophisticated software for UART handling, and a
>> justification for thinking it is common practice. I suppose you could
>> say that sometimes microcontroller software works by polling UART
>> hardware status registers in busy-waiting loops, but it is not likely to
>> be common practice except in special circumstances.
>
> I'll wager a month's salary that the _vast_ bulk of MCU software
> sits in a tight loop polling one or two bits in a couple of
> registers. Sophisticated context handling, thread switching
> (a lot of 8-bit MCUs just don't have enough memory available for
> multiple stacks, let alone thread save areas), or even
> interrupts are _probably_ pretty rare.
I would not want to either make or take such a bet - there is such a
vast body of microcontroller software that there is no way to know. So
I can only talk about code that I have seen (whether I wrote it or
someone else did).
It is certainly true that a lot of microcontroller programs don't use an
RTOS - either because they have too few resources, because the
programmers are not confident with them, or simply because the
application doesn't need them. There are many advantages in writing
software without multiple threads - your memory setup is far simpler and
it is therefore easier to be sure it is correct, you have no race
conditions, synchronisation, locking, or atomic access considerations
(except in connection with interrupts, or hardware like DMA), and its
easier to have a full track of what is going on. I think you are on
fairly safe ground saying that most microcontroller software does not
use an RTOS or multi-threading, but "the vast bulk" is a risky stretch.
There is also no doubt that the use of RTOS's is much more common now
than it used to be (helped enormously by the general move towards 32-bit
microcontrollers with a good deal more ram).
It is a lot less common (without giving any statistics or numbers here)
for non-trivial microcontroller code to run without any interrupts. I
know of a few microcontrollers that have no interrupt mechanisms, such
as the PIC12x family, but they are not particularly common and long
outdated (I hesitate to say "obsolete" - Microchip have a reputation for
continuing to produce old devices, and they are still available to buy -
but you will not see them in new designs). It is extremely common to
have at least a regular timer interrupt, and interrupts for transfers of
UARTs, SPI, I²C, and ADC readings are found in a great many
microcontroller programs.
While, again, it is very difficult to get accurate information about
what people use in their code, there is the time-honoured technique of
following the money. When making a small microcontroller core,
supporting interrupts is not free - it takes die space, design effort,
and power. Devices which do not support interrupts at all are rare -
even in the world of 4-bit microcontrollers, you often have interrupts
(one of the few 4-bit families that was easily available to the masses
was the Atmel Marc 4, and it had 8 interrupt lines with different
priorities). If it were normal practice not to use the interrupts, I
think you'd have seen a few more devices that saved money and
power-usage by omitting them.
So a solid proportion of microcontroller programs do not have threads,
but do have interrupts. And they have a "main loop". Such "main loops"
generally do several things - you very often see a "while (true)" or
"for (;;)" loop with a series of "run_task1()", "run_task2()", type of
function call. And yes, some of these will poll for hardware register
bits to see what needs to be done. Many will be connected to a timer or
too, so they run periodically. Some will just run this loop
continuously, but another common pattern is to end with a "sleep" or
"wait-for-interrupt" instruction to put to the core to sleep until an
interrupt occurs. (I have had a few programs where the entire "main
loop" was a sleep instruction - all work was done in interrupt functions.)
Any discussion about "efficiency" or "sophistication" would have to be
in view of the tasks being handled by the software. (I note that you
did not say or imply that being inefficient or unsophisticated is
necessarily a bad thing.) A simple list of "run_task1(); run_task2();
... " is not as "sophisticated" as having a dynamic scheduler with
priority queues implemented as Fibonacci heaps, but it is vastly more
efficient for a small number of fixed tasks. A simpler solution for a
job might sometimes be less efficient in processor cycles than a more
advanced one, but it might be more efficient in development time, or
when looking at how you can be sure it is correct. ("Real-time"
programming is not about doing things quickly or efficiently - it's
about being sure that you do things within the required time limits.)
And "efficiency" of processor cycles is relevant when cycles saved could
be used for other purposes, or save energy, or let you use a cheaper or
slower device. That is not always a relevant factor. A microcontroller
might be trying to run on a battery for ten years, or it might be
controlling a 10 kW motor - in the former case, saving processor cycles
could mean saving money on battery sizes, but in the later case saving
power is irrelevant.
>
>> If code on my microcontroller wants to sent data to the UART (i.e., put
>> it into the software FIFO that feeds the hardware FIFO), the call is
>> perhaps 30 cycles plus maybe 6 or 8 per byte sent. Entering a "wait for
>> end of received frame event" is maybe 50 cycles, and the time from the
>> UART detecting the idle time, triggering the event, and the resulting
>> context switch starting up the blocked task is perhaps 200 cycles.
>> Those are all rough guesses out of my head, I have not measured them.
>> How many cpu cycles does it take for a program on Linux to send out a
>> dozen bytes on a UART, or between the UART hardware detecting the
>> receive timeout to the polling process exiting the poll() call?
>
> That's an apples/oranges comparison.
Yes, to some extent at least. Microcontrollers and "typical"
microcontroller software are appropriate for different tasks than "big"
processors and "big" OS's, and they do things differently. But
sometimes there is enough similarity in a task that comparisons are
possible (though not necessarily useful).
> What you really want to
> ask is, how much time does it take to enqueue data into the
> outbound ring buffer for a particular device, and how many
> cycles does it take to fill the output FIFO from the ring when
> space becomes available? Both of those costs _can_ be very low.
> What is the cost of busy-waiting? It's hard to say.
>
> If you only have a small handful of tasks, and everything is in
> the same address space, then sure, picking a different thread to
> run and doing the coroutine jump dance to resume it isn't that
> hard.
>
> Distance between timing out (say) a poll and a user program
> exiting a system call is difficult to measure, since a polled
> event happening doesn't mean that the system call automatically
> returns; it means that the task that invoked the system call is
> unblocked gets marked runnable; when it actually runs again
> depends on a lot of factors (load vs available resources;
> scheduling latency; time quantums assigned to currently running
> tasks; etc). Most Unix/Linux-style schedulers are not real
> time schedulers; so we freqntly just say, "eventually."
>
> There's a whole branch of systems research devoted to doing this
> as efficiently as possible.
"Efficiently" for a Linux system here is likely to have an emphasis on
efficiency of throughput, rather than for smaller transfers. That is,
of course, perfectly fine.
>
>>> [snip]
>>> The purpose of an operating system is to control hardware,
>>> isolate software principles from one another, and provide useful
>>> programming abstractions. Essentially what you're saying is
>>> that you don't want or need that, for some kinds of programs.
>>
>> There a range of possible OS types, with kernels ranging from micro to
>> monolithic, widely different ideas of how much separation different
>> tasks need, and how much hardware control is done in the OS or in other
>> code. It is certainly the case that the features I want from an RTOS on
>> a microcontroller differ significantly from what I want in a general
>> purpose OS on a PC or other "big" system.
>>
>>> That's fine. But to extrapolate from that to, "and this
>>> category of software is more efficient", as an absolute
>>> statement, is what I take exception to: there's too much
>>> disconfirming evidence to the contrary. Perhaps not in the
>>> programs you personally write, but I took your statement was
>>> general and not restricted to only those programs.
>>
>> To be clear - when comparing efficiency, you have to know when you are
>> comparing apples to apples, and apples to oranges. My point is that for
>> many tasks, microcontrollers are more efficient but it is an apples to
>> oranges comparison in the details since the big OS has many other
>> important considerations.
>
> That's kind of my point. The statement you made that I
> responded to was that microcontroller software is "more
> efficient" than what a general purpose OS does. It is more
> nuanced than that, as it so often is: this is one reason I
> dislike categorical statements of that nature.
>
That's fair enough (and I've tried to be a bit more nuanced in this
reply). Equally, however, you made some pretty categorical claims about
microcontroller software being "terribly unsophisticated" and "wasting a
lot of CPU cycles". But I think we have written enough on these things
- unless we can find a way to bring it back to C!
>>>> Directly handling interrupts in a microcontroller is not particularly
>>>> complex - it's daily work for microcontroller developers.
>>>
>>> Yes, because if your needs are not as general as those demanded
>>> by general purposes operating systems on general purpose CPUs,
>>> it can be made reasonably simple.
>>
>> Exactly.
>>
>> Microcontroller code will typically be much more focused and specialised.
>
> Which doesn't necessarily mean more efficient. That was my
> point.
Okay. I am not sure it was clear that this was your point, but it is a
point that I can agree with. Equally, I think it is obvious that a more
general approach - however sophisticated the code may be - will not
necessarily be more efficient. Generalisation usually comes at a cost
compared to dedicated solutions, if the details of the task are fixed
and known. (And in embedded systems - even embedded Linux systems - the
task requirements are usually a lot more fixed than than in a general OS.)
>
>>> As I mentioned, most (not
>>> all) programs that target microcontrollers are not terribly
>>> sophisticated, and have very modest requirements in this regard.
>>
>> I am still not sure what you are saying here. It sounds a bit like you
>> have been saying the code is not sophisticated and therefore inefficient
>> and wasteful of cycles, when it is often the case that code is not very
>> sophisticated because it can be done simply and efficiently.
>
> What I am saying is that words have meaning, and if you're going
> to make an absolute statement about the relative efficiency of
> one category of system versus another, you need to qualify what
> you mean.
>
Again, I am not sure that was clear from what you wrote - but I agree
with your point as you have rephrased it here.
>>>> And we too know how to have blocking calls and multiple threads.
>>>
>>> ...and there are embedded OSes that have system calls and
>>> privileged modes that restrict access to the hardware, too. :-}
>>
>> Yes, there are. Again, I have used some of these at times.
>
> The salient characteristic is that they share many of the same
> properties of OSes on larger systems: MPUs might divide the
> available address space into discrete regions, and so context
> switching now involves memory-management hardware, where perhaps
> it did not before. The point is that, even within "embedded
> systems" there's too much variability to make absolute
> statements. In general, I advice refraining from such for
> precisely that reason.
>
I am fully aware that there is a wide range in the embedded world - even
if you restrict it to microcontrollers and exclude embedded Linux and
the like. The smallest microcontroller I have worked with had no ram at
all, only its 32 8-bit registers (I still programmed it in C, with
gcc!), and I've seen speeds ranging from about 0.3 MIPs to 1000 MIPs
(without specifying what each "instruction" here could do). So I would
not want to make any bets about what the "vast bulk of microcontroller
software" does.
One thing you might not be aware of is the difference between what is
generally termed a "Memory Protection Unit" (MPU) and a "Memory
Management Unit" (MMU). With the proviso that the terms are not
strictly defined and the there can be exceptions in both hardware and
software usage, an MMU generally deals with translations of virtual
addresses to physical addresses as well as controlling accesses (at
either the virtual or physical address level). An MPU normally does not
do any translation - it is for access control and determining address
space characteristics like cacheability. In an RTOS on a
microcontroller, the MPU is typically configured once at startup and not
changed thereafter - including during context switches. There can be a
distinction between some kind of "privileged", "supervisor" or "system"
mode and "user", "problem" or "task" mode (terminology varies
significantly), and also between "secure" and "non-secure" modes. But
the MPU, together with any other security features, bus access blocks,
etc., will normally have a single setup to say what memory and
peripherals are accessible by code running in each mode. The MPU does
not need changed between threads (with the exception of sometimes
changing one window used for catching stack overflows in some setups),
and does not have the kind of context switch overhead required between
processes in a big system with virtual memory and security and
protection between tasks.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-07 23:19 +0000 |
| Message-ID | <112k1i1$kb7$1@reader1.panix.com> |
| In reply to | #400275 |
Sorry for the delayed response; we were traveling with the holiday. I just wanted to touch on a few points. In article <111rjtr$3ofre$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 27/06/2026 04:22, Dan Cross wrote: >[snip] >That's fair enough (and I've tried to be a bit more nuanced in this >reply). Equally, however, you made some pretty categorical claims about >microcontroller software being "terribly unsophisticated" and "wasting a >lot of CPU cycles". But I think we have written enough on these things >- unless we can find a way to bring it back to C! Fair. I thought I had tried to qualify it to say much, not all, however. >One thing you might not be aware of is the difference between what is >generally termed a "Memory Protection Unit" (MPU) and a "Memory >Management Unit" (MMU). With the proviso that the terms are not >strictly defined and the there can be exceptions in both hardware and >software usage, an MMU generally deals with translations of virtual >addresses to physical addresses as well as controlling accesses (at >either the virtual or physical address level). An MPU normally does not >do any translation - it is for access control and determining address >space characteristics like cacheability. In an RTOS on a >microcontroller, the MPU is typically configured once at startup and not >changed thereafter - including during context switches. There can be a >distinction between some kind of "privileged", "supervisor" or "system" >mode and "user", "problem" or "task" mode (terminology varies >significantly), and also between "secure" and "non-secure" modes. But >the MPU, together with any other security features, bus access blocks, >etc., will normally have a single setup to say what memory and >peripherals are accessible by code running in each mode. The MPU does >not need changed between threads (with the exception of sometimes >changing one window used for catching stack overflows in some setups), >and does not have the kind of context switch overhead required between >processes in a big system with virtual memory and security and >protection between tasks. No, I'm aware that MPUs don't generally provide relocation facilities, but they _do_ often provide more than one region; the Cortex-M7 parts we use for the service processor embedded in our machines supports (if memory serves) 16 that we divide between the various tasks we run on the microcontroller. In our embedded OS (Hubris) we manually permit each task's region (and depermit others) on context switch. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-07-08 14:52 +0000 |
| Message-ID | <uut3S.47771$i651.20379@fx45.iad> |
| In reply to | #400294 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >Sorry for the delayed response; we were traveling with the >holiday. I just wanted to touch on a few points. > >In article <111rjtr$3ofre$1@dont-email.me>, >David Brown <david.brown@hesbynett.no> wrote: >>On 27/06/2026 04:22, Dan Cross wrote: >>[snip] >>That's fair enough (and I've tried to be a bit more nuanced in this >>reply). Equally, however, you made some pretty categorical claims about >>microcontroller software being "terribly unsophisticated" and "wasting a >>lot of CPU cycles". But I think we have written enough on these things >>- unless we can find a way to bring it back to C! > >Fair. I thought I had tried to qualify it to say much, not all, >however. > >>One thing you might not be aware of is the difference between what is >>generally termed a "Memory Protection Unit" (MPU) and a "Memory >>Management Unit" (MMU). With the proviso that the terms are not >>strictly defined and the there can be exceptions in both hardware and >>software usage, an MMU generally deals with translations of virtual >>addresses to physical addresses as well as controlling accesses (at >>either the virtual or physical address level). An MPU normally does not >>do any translation - it is for access control and determining address >>space characteristics like cacheability. In an RTOS on a >>microcontroller, the MPU is typically configured once at startup and not >>changed thereafter - including during context switches. There can be a >>distinction between some kind of "privileged", "supervisor" or "system" >>mode and "user", "problem" or "task" mode (terminology varies >>significantly), and also between "secure" and "non-secure" modes. But >>the MPU, together with any other security features, bus access blocks, >>etc., will normally have a single setup to say what memory and >>peripherals are accessible by code running in each mode. The MPU does >>not need changed between threads (with the exception of sometimes >>changing one window used for catching stack overflows in some setups), >>and does not have the kind of context switch overhead required between >>processes in a big system with virtual memory and security and >>protection between tasks. > >No, I'm aware that MPUs don't generally provide relocation >facilities, but they _do_ often provide more than one region; >the Cortex-M7 parts we use for the service processor embedded in >our machines supports (if memory serves) 16 that we divide >between the various tasks we run on the microcontroller. In our >embedded OS (Hubris) we manually permit each task's region (and >depermit others) on context switch. There are, depending on how you count them, eight fixed partitions in the 32-bit address space (generally indexed by the top three bits). The first two are TCM (ROM and SRAM respectively). With external logic, two of the 1GB regions[*] can be statically or dynamically mapped to external SRAM, DRAM or specific busses and/or devices in an SoC that includes a CM7 processor. [*] the External Device and External RAM regions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-07-08 20:56 +0200 |
| Message-ID | <112m6g2$3rn8i$1@dont-email.me> |
| In reply to | #400294 |
On 08/07/2026 01:19, Dan Cross wrote: > Sorry for the delayed response; we were traveling with the > holiday. I just wanted to touch on a few points. > I'm on holiday too. I hope you are getting decent weather for your holiday - not too hot, but not as much rain as we've had. > In article <111rjtr$3ofre$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 27/06/2026 04:22, Dan Cross wrote: >> [snip] >> That's fair enough (and I've tried to be a bit more nuanced in this >> reply). Equally, however, you made some pretty categorical claims about >> microcontroller software being "terribly unsophisticated" and "wasting a >> lot of CPU cycles". But I think we have written enough on these things >> - unless we can find a way to bring it back to C! > > Fair. I thought I had tried to qualify it to say much, not all, > however. > >> One thing you might not be aware of is the difference between what is >> generally termed a "Memory Protection Unit" (MPU) and a "Memory >> Management Unit" (MMU). With the proviso that the terms are not >> strictly defined and the there can be exceptions in both hardware and >> software usage, an MMU generally deals with translations of virtual >> addresses to physical addresses as well as controlling accesses (at >> either the virtual or physical address level). An MPU normally does not >> do any translation - it is for access control and determining address >> space characteristics like cacheability. In an RTOS on a >> microcontroller, the MPU is typically configured once at startup and not >> changed thereafter - including during context switches. There can be a >> distinction between some kind of "privileged", "supervisor" or "system" >> mode and "user", "problem" or "task" mode (terminology varies >> significantly), and also between "secure" and "non-secure" modes. But >> the MPU, together with any other security features, bus access blocks, >> etc., will normally have a single setup to say what memory and >> peripherals are accessible by code running in each mode. The MPU does >> not need changed between threads (with the exception of sometimes >> changing one window used for catching stack overflows in some setups), >> and does not have the kind of context switch overhead required between >> processes in a big system with virtual memory and security and >> protection between tasks. > > No, I'm aware that MPUs don't generally provide relocation > facilities, but they _do_ often provide more than one region; > the Cortex-M7 parts we use for the service processor embedded in > our machines supports (if memory serves) 16 that we divide > between the various tasks we run on the microcontroller. In our > embedded OS (Hubris) we manually permit each task's region (and > depermit others) on context switch. > Sure, that is possible. Sometimes RTOS's on microcontrollers support changing the MPU for different tasks, but it is not a feature that is much used. You generally don't get very fine-grained control, making it difficult to split memory between tasks - region sizes are typically limited to powers of two, and it adds to the overhead for context switches. Of course different situations give different tradeoffs, and it is certainly something that people do at times. With the "Trustzone" stuff on newer Cortex-M devices, you can make a clear distinction between two types of code - "trusted" or "secured", and everything else - and make fine-grained separation of peripherals as well as memory.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-24 15:51 +0000 |
| Message-ID | <52T_R.2$7EZf.0@fx40.iad> |
| In reply to | #400223 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <111elok$2g1qh$2@dont-email.me>, >David Brown <david.brown@hesbynett.no> wrote: >>On 23/06/2026 19:39, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 23/06/2026 17:35, Scott Lurndal wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>>> On 22/06/2026 16:56, Scott Lurndal wrote: >>>>>>> Michael S <already5chosen@yahoo.com> writes: >>>>>>>> On Sun, 21 Jun 2026 12:18:39 +0200 >>>>>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>>>> >>> >>>> >>>>>> or >>>>>> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. >>>>> >>>>> Which describes several long-obsolete API implementations. >>>>> >>>> >>>> OK. >>>> >>>> But there is still termio stuff needed in the setup of the UART, when >>>> all that is needed in almost all cases this century is picking the baud >>>> rate, possibly enabling the RTS line as an RS-485 driver enable, picking >>>> 8,n,1 (other options are rare, but not quite non-existent), and then >>>> reading and writing characters. >>> >>> I would separate those into two distinct operations: >>> >> >>Yes. >> >>> - One-time setup. Setting the line characteristics (baud rate, >>> stop-bits, parity) and the UART characteristics (flow >>> control, Rx and Tx FIFOs, Carrier Detect). For which there >>> are standard POSIX interfaces (tcsetattr/tcgetattr) >>> >>> - steady-state operations, such as reading and writing which >>> use the normal file I/O operations (read, write, poll, et alia) >>> >> >>Agreed. >> >>It's only the setup that is a pain because of legacy terminal support. > >Is it really that hard? > > struct termios term; > memset(&term, 0, sizeof(term)); > cfmakeraw(&term); // BSD extension > cfsetispeed(&term, B38400); > cfsetospeed(&term, B38400); > term.c_cflag |= CS8 | CREAD | CRTSCTS; > tcsetattr(fd, TCSANOW, &term) > >Of course, on plan 9, it's even easier: > > echo -n b38400 l8 pn s1 >/dev/eia1ctl Or 'stty(1)' on unix/linux. e.g $ stty -icrnl -ocrnl cs8 38400 -crtscts < /dev/tty0 (-crtscts is a GNU coreutils extension to posix).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-23 14:44 -0700 |
| Message-ID | <111euoc$2isl7$3@dont-email.me> |
| In reply to | #400208 |
On 6/23/2026 10:39 AM, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 23/06/2026 17:35, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 22/06/2026 16:56, Scott Lurndal wrote: >>>>> Michael S <already5chosen@yahoo.com> writes: >>>>>> On Sun, 21 Jun 2026 12:18:39 +0200 >>>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> > >> >>>> or >>>> <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. >>> >>> Which describes several long-obsolete API implementations. >>> >> >> OK. >> >> But there is still termio stuff needed in the setup of the UART, when >> all that is needed in almost all cases this century is picking the baud >> rate, possibly enabling the RTS line as an RS-485 driver enable, picking >> 8,n,1 (other options are rare, but not quite non-existent), and then >> reading and writing characters. > > I would separate those into two distinct operations: > > - One-time setup. Setting the line characteristics (baud rate, > stop-bits, parity) and the UART characteristics (flow > control, Rx and Tx FIFOs, Carrier Detect). For which there > are standard POSIX interfaces (tcsetattr/tcgetattr) > > - steady-state operations, such as reading and writing which > use the normal file I/O operations (read, write, poll, et alia) > >> > There are other possible features that >> can be useful for UARTs, such as getting feedback when everything is >> sent (via a semaphore, condition variable, or similar synchronisation >> mechanism), > > That really depends on OS API. STDIO buffers output, and provides > a mechanism to flush the buffers. If one bypasses stdio and uses > read/write, the programmer can call tcdrain() to ensure the data > has been transmitted or set VMIN=1 and VTIME=0 with tcsetattr > to avoid any buffering in the kernel driver. For some reason that reminds me of EIEIO on the PPC. > >> getting feedback when there has been a pause since the last >> received character, and other such things. AFAIK these are not >> available with standard Linux serial port handling. > > The poll(2) system call can be used for this purpose, as it > can timeout if there is no character received within a > specified interval. >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-23 22:30 +0300 |
| Message-ID | <20260623223035.00004d15@yahoo.com> |
| In reply to | #400205 |
On Tue, 23 Jun 2026 15:35:52 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > David Brown <david.brown@hesbynett.no> writes: > >On 22/06/2026 16:56, Scott Lurndal wrote: > >> Michael S <already5chosen@yahoo.com> writes: > >>> On Sun, 21 Jun 2026 12:18:39 +0200 > >>> David Brown <david.brown@hesbynett.no> wrote: > >>> > >> > >>>> > >>> > >>> Serial device API of Linux (inherited from early Unixes) is too > >>> kludgy to my liking. Why oh why do they think that serial port > >>> somehow has to be related to terminal ?! > >> > >> Can you elaborate on that? What do you mean 'related to a > >> terminal'? > >> > >> The POSIX serial interface seems quite useful - using ioctl(2) > >> to handle non-data-transfer interfaces (e.g. setting the baud rate, > >> stop bits, parity, et alia) via library functions > >> (tcsetattr/tcgetattr) and using standard filesystem calls for > >> reading and writing. > >> > >> Once the serial port is opened, it is a simple byte stream just > >> like any other unix file. > >> > >> Bitbanging RS232C for SCADA was never a design goal, unlike > >> IEEE 488. > >> > >> > > > >Just look at the documentation: > ><https://docs.kernel.org/driver-api/serial/driver.html> > > Which describes how to write a kernel driver for a new > serial port (of which there hasn't been new hardware since > the PL011). Certainly not of interest or use to the average > user. > I personally implemented new serial port hardware and Linux driver for it approximately 8 years ago. Not your average user stuff, sure. I don't remeber all details now, but I think it was up to 4 or 5 Mbit/s per port with plenty of ports. About 10, IIRC. > > or > ><https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. > > Which describes several long-obsolete API implementations. > > > It's a > >total mess - it's all for handling serial terminals from the 1970's. > > > > I'm sure that the microprocessors you routinely use all still > support either the 16550 UART or the PL011 for debug purposes > if not for production purposes. Our most recently taped out > chip has a dozen pl011 compatible UARTS. > You demonstrate lack of imagination. > Sure, the modem signals are obsolete and not often used. > With that I agree. > With 115k baud, it's less likely that the hardware flow > control signals (RTS/CTS) are still used (although XON/XOFF is > still useful) in most cases, but the classic serial port still > lives and is useful, particularly in embedded hardware.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-23 22:48 +0300 |
| Message-ID | <20260623224836.00001a3c@yahoo.com> |
| In reply to | #400204 |
On Tue, 23 Jun 2026 07:25:56 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 22/06/2026 16:56, Scott Lurndal wrote: > > Michael S <already5chosen@yahoo.com> writes: > >> On Sun, 21 Jun 2026 12:18:39 +0200 > >> David Brown <david.brown@hesbynett.no> wrote: > >> > > > >>> > >> > >> Serial device API of Linux (inherited from early Unixes) is too > >> kludgy to my liking. Why oh why do they think that serial port > >> somehow has to be related to terminal ?! > > > > Can you elaborate on that? What do you mean 'related to a > > terminal'? > > > > The POSIX serial interface seems quite useful - using ioctl(2) > > to handle non-data-transfer interfaces (e.g. setting the baud rate, > > stop bits, parity, et alia) via library functions > > (tcsetattr/tcgetattr) and using standard filesystem calls for > > reading and writing. > > > > Once the serial port is opened, it is a simple byte stream just like > > any other unix file. > > > > Bitbanging RS232C for SCADA was never a design goal, unlike > > IEEE 488. > > > > > > Just look at the documentation: > <https://docs.kernel.org/driver-api/serial/driver.html> or > <https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux>. > It's a total mess - it's all for handling serial terminals from the > 1970's. Most of it is, of course, just a one-off setting - once you > have got the termio stuff right, Configuration API sometimes matters. In particular, support for various timeouts in termio is subpar relatively to what you have in Windows. May be, Windows has too many of them, esp. on the transmit side, but termios certainly has too few. What is even worse, is resolution. Out of memory, resolution of timeouts in termios is 0.1 sec. For SCADA-style protocols that's useless. So, it seems, the only way to implement such protocols on Linux or similar OSes, is to read one character at time by very high priority thread. And to pray for good luck. Today, with many cores available everiwhere, the chance for ending up lucky is decent. 25 years ago - less so. > and haven't accidentally got some > extra character translation or flow control, then it's just simple > reads and writes. > > Of course it is hard to remove stuff once it is there - user space > APIs are, rightly, as stable as they possibly can be. > But it is possible to add better API without removing old stuff. May be, it even exists. I didn't follow the field since ~2021.
[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