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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-23 17:12 +0000 |
| Message-ID | <111eeq8$3vc$1@reader1.panix.com> |
| In reply to | #400206 |
In article <111eavb$2c615$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 23/06/2026 17:35, Scott Lurndal wrote:
>
>>> 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.
>
>16550 UARTs are long obsolete. Some embedded processors might have
>UARTs that have register sets compatible with them, but I don't think it
>is common. Microcontrollers certainly don't make any attempt to have
>compatibility with those register sets.
This is simply incorrect. Lots of parts still have integrated
16550-compatible UARTs; the designware part that is common in a
lot of SoC's will even go up to 3MBAUD.
>> Sure, the modem signals are obsolete and not often used.
>>
>> 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.
>
>I use serial ports all the time. I've never had any use for XON/XOFF,
>or hardware flow control (the RTS signal is often used for RS-485 drive
>enable), and regularly use 3 MBaud for local connections to fast
>microcontrollers.
I use 3MBAUD, 16550-compatible UARTs embedded in AMD's EPYC SoCs
daily. We use hardware flow control to avoid dropping
characters when speaking to a fast uctlr running our own
embedded OS. The DW part in the SoC even supports auto HW flow
control and manages the FIFOs and signaling more or less
independently of the host (which actually caused a problem in
our driver a few months back).
If reliable delivery of data is important to you, some kind of
flow control is useful, whether hardware or software based. If
it's just for debug spew, you may not care.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-23 21:07 +0200 |
| Message-ID | <111eli4$2g1qh$1@dont-email.me> |
| In reply to | #400207 |
On 23/06/2026 19:12, Dan Cross wrote: > In article <111eavb$2c615$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 23/06/2026 17:35, Scott Lurndal wrote: >> >>>> 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. >> >> 16550 UARTs are long obsolete. Some embedded processors might have >> UARTs that have register sets compatible with them, but I don't think it >> is common. Microcontrollers certainly don't make any attempt to have >> compatibility with those register sets. > > This is simply incorrect. Lots of parts still have integrated > 16550-compatible UARTs; the designware part that is common in a > lot of SoC's will even go up to 3MBAUD. I don't know all embedded microprocessors. I suspect that in order to remain as "PC compatible" as possible, x86 SoC's might have 16550 compatible UARTs. Many others do not. The NXP i.mx family, which is one of the most popular in industrial usage, have UARTs that do not have 16550 register sets. There is a reason linux/drivers/tty/serial has several dozen C files, supporting several dozen UARTs. Critically, embedded UARTs (excluding 16550 compatible ones) support DMA. And of the perhaps 20 or 30 microcontroller families I have used over the years, I don't remember ever having seen one with a UART that is 16550 compatible. (I did, on a couple of boards, use a dedicated 16x50 UART chip, possibly a 16450.) Of course all these UARTs can /talk/ to 16550 UARTs, but they are not compatible in their design or hardware register maps despite plenty of similarity. > >>> Sure, the modem signals are obsolete and not often used. >>> >>> 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. >> >> I use serial ports all the time. I've never had any use for XON/XOFF, >> or hardware flow control (the RTS signal is often used for RS-485 drive >> enable), and regularly use 3 MBaud for local connections to fast >> microcontrollers. > > I use 3MBAUD, 16550-compatible UARTs embedded in AMD's EPYC SoCs > daily. We use hardware flow control to avoid dropping > characters when speaking to a fast uctlr running our own > embedded OS. The DW part in the SoC even supports auto HW flow > control and manages the FIFOs and signaling more or less > independently of the host (which actually caused a problem in > our driver a few months back). > > If reliable delivery of data is important to you, some kind of > flow control is useful, whether hardware or software based. If > it's just for debug spew, you may not care. > If your systems are fast enough, and you have the right priorities for your threads, interrupts, DMAs, etc., then you don't need flow control. And most protocols (other than debug outputs) used over serial ports in embedded systems are not continuous traffic flows - you have packets, and typically have request/response patterns. As long as you have DMA to give you FIFOs that are big enough, you can consider the packet reception and answering as high-level software flow control.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-23 23:00 +0300 |
| Message-ID | <20260623230002.000063d8@yahoo.com> |
| In reply to | #400210 |
On Tue, 23 Jun 2026 21:07:48 +0200 David Brown <david.brown@hesbynett.no> wrote: > > And of the perhaps 20 or 30 microcontroller families I have used over > the years, I don't remember ever having seen one with a UART that is > 16550 compatible. (I did, on a couple of boards, use a dedicated > 16x50 UART chip, possibly a 16450.) > I think, I had seen one, in the early 2000, on IBM PPC 4xx embedded chip. Whether it should be considered MCU or embedded processor is a matter of opinion. But it was pretty low end chip, esp. comparatively to PowerQUICC I that I was used to back in this era. Other than that I agree. It seems that Dan Cross has no [1st-hand programming] experience with MCUs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-24 08:32 +0200 |
| Message-ID | <111ftl8$2q327$1@dont-email.me> |
| In reply to | #400214 |
On 23/06/2026 22:00, Michael S wrote: > On Tue, 23 Jun 2026 21:07:48 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> And of the perhaps 20 or 30 microcontroller families I have used over >> the years, I don't remember ever having seen one with a UART that is >> 16550 compatible. (I did, on a couple of boards, use a dedicated >> 16x50 UART chip, possibly a 16450.) >> > > I think, I had seen one, in the early 2000, on IBM PPC 4xx embedded > chip. Whether it should be considered MCU or embedded processor is a > matter of opinion. But it was pretty low end chip, esp. comparatively to > PowerQUICC I that I was used to back in this era. > I know of the PPC 4xx series, but never used one. The PPC microcontrollers I used first were in the 5xx series - PPC506, if I remember correctly, then perhaps PPC561. (This is from memory, so I might have the numbers wrong.) And then a couple in the 5xxx families. One of those had two cores, and was my first use of ASMP in a microcontroller. All the devices I used had microcontroller-style UARTs. > Other than that I agree. It seems that Dan Cross has no [1st-hand > programming] experience with MCUs. > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-24 21:54 +0300 |
| Message-ID | <20260624215416.00003747@yahoo.com> |
| In reply to | #400220 |
On Wed, 24 Jun 2026 08:32:08 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 23/06/2026 22:00, Michael S wrote: > > On Tue, 23 Jun 2026 21:07:48 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> And of the perhaps 20 or 30 microcontroller families I have used > >> over the years, I don't remember ever having seen one with a UART > >> that is 16550 compatible. (I did, on a couple of boards, use a > >> dedicated 16x50 UART chip, possibly a 16450.) > >> > > > > I think, I had seen one, in the early 2000, on IBM PPC 4xx embedded > > chip. Whether it should be considered MCU or embedded processor is a > > matter of opinion. But it was pretty low end chip, esp. > > comparatively to PowerQUICC I that I was used to back in this era. > > > > I know of the PPC 4xx series, but never used one. The PPC > microcontrollers I used first were in the 5xx series - PPC506, if I > remember correctly, then perhaps PPC561. (This is from memory, so I > might have the numbers wrong.) I am pretty sure that you are wrong. IBM and their licensees did not make 5xx core. Only Moto/Freescale/NXP made such parts. But they call their cores MPC rather than PPC. > And then a couple in the 5xxx > families. Here I am less than 100% sure, but 90% sure that the same applies to 5xxx. Most likely your device was called MPC rather than PPC. > One of those had two cores, and was my first use of ASMP in > a microcontroller. All the devices I used had microcontroller-style > UARTs. > > > Other than that I agree. It seems that Dan Cross has no [1st-hand > > programming] experience with MCUs. > > > > > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-24 21:09 +0200 |
| Message-ID | <111ha19$37vah$1@dont-email.me> |
| In reply to | #400233 |
On 24/06/2026 20:54, Michael S wrote: > On Wed, 24 Jun 2026 08:32:08 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 23/06/2026 22:00, Michael S wrote: >>> On Tue, 23 Jun 2026 21:07:48 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> >>>> And of the perhaps 20 or 30 microcontroller families I have used >>>> over the years, I don't remember ever having seen one with a UART >>>> that is 16550 compatible. (I did, on a couple of boards, use a >>>> dedicated 16x50 UART chip, possibly a 16450.) >>>> >>> >>> I think, I had seen one, in the early 2000, on IBM PPC 4xx embedded >>> chip. Whether it should be considered MCU or embedded processor is a >>> matter of opinion. But it was pretty low end chip, esp. >>> comparatively to PowerQUICC I that I was used to back in this era. >>> >> >> I know of the PPC 4xx series, but never used one. The PPC >> microcontrollers I used first were in the 5xx series - PPC506, if I >> remember correctly, then perhaps PPC561. (This is from memory, so I >> might have the numbers wrong.) > > I am pretty sure that you are wrong. > IBM and their licensees did not make 5xx core. Only Moto/Freescale/NXP > made such parts. But they call their cores MPC rather than PPC. Indeed - they were MPC5xx and MPC5xxx devices. But they had PowerPC cores, like the PPC 4xx family, though of course different devices had different variants of the embedded PowerPC cores. > >> And then a couple in the 5xxx >> families. > > Here I am less than 100% sure, but 90% sure that the same applies to > 5xxx. Most likely your device was called MPC rather than PPC. > Yes. >> One of those had two cores, and was my first use of ASMP in >> a microcontroller. All the devices I used had microcontroller-style >> UARTs. >> >>> Other than that I agree. It seems that Dan Cross has no [1st-hand >>> programming] experience with MCUs. >>> >>> >>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-24 10:48 +0000 |
| Message-ID | <111gcm2$43e$1@reader1.panix.com> |
| In reply to | #400214 |
In article <20260623230002.000063d8@yahoo.com>,
Michael S <already5chosen@yahoo.com> wrote:
>On Tue, 23 Jun 2026 21:07:48 +0200
>David Brown <david.brown@hesbynett.no> wrote:
>> And of the perhaps 20 or 30 microcontroller families I have used over
>> the years, I don't remember ever having seen one with a UART that is
>> 16550 compatible. (I did, on a couple of boards, use a dedicated
>> 16x50 UART chip, possibly a 16450.)
>
>I think, I had seen one, in the early 2000, on IBM PPC 4xx embedded
>chip. Whether it should be considered MCU or embedded processor is a
>matter of opinion. But it was pretty low end chip, esp. comparatively to
>PowerQUICC I that I was used to back in this era.
>
>Other than that I agree. It seems that Dan Cross has no [1st-hand
>programming] experience with MCUs.
a) specious conclusion, and b) my statement was not limited to
MCUs.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-24 10:47 +0000 |
| Message-ID | <111gckb$rk9$1@reader1.panix.com> |
| In reply to | #400210 |
In article <111eli4$2g1qh$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 23/06/2026 19:12, Dan Cross wrote:
>> In article <111eavb$2c615$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 23/06/2026 17:35, Scott Lurndal wrote:
>>>
>>>>> 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.
>>>
>>> 16550 UARTs are long obsolete. Some embedded processors might have
>>> UARTs that have register sets compatible with them, but I don't think it
>>> is common. Microcontrollers certainly don't make any attempt to have
>>> compatibility with those register sets.
>>
>> This is simply incorrect. Lots of parts still have integrated
>> 16550-compatible UARTs; the designware part that is common in a
>> lot of SoC's will even go up to 3MBAUD.
>
>I don't know all embedded microprocessors. I suspect that in order to
>remain as "PC compatible" as possible, x86 SoC's might have 16550
>compatible UARTs.
Essentially every modern x86 SoC has at least one; usually
several. They may or may not be lined out, but they're there.
Some other systems may use 16550-compatible parts as well; as I
mentioned, DesignWare markets one as an embeddable piece of IP
that one can incorporate into one's own design.
>Many others do not. The NXP i.mx family, which is one of the most
>popular in industrial usage, have UARTs that do not have 16550 register
>sets. There is a reason linux/drivers/tty/serial has several dozen C
>files, supporting several dozen UARTs. Critically, embedded UARTs
>(excluding 16550 compatible ones) support DMA.
I did not say that other systems used 16550, I was disputing the
incorrect statement that "16550 UARTs are long obsolete." If
you mean discrete UART chips signaling at TTL levels, whether
shifted to RS-232 levels or not, you're correct, but I took your
statement to be more general. Simply, they are not obsolete at
all, and they're extraordinarily common.
>And of the perhaps 20 or 30 microcontroller families I have used over
>the years, I don't remember ever having seen one with a UART that is
>16550 compatible. (I did, on a couple of boards, use a dedicated 16x50
>UART chip, possibly a 16450.)
Ok, but your personal experience is anecdotal and by your own
admission not representative of large machines. Judging that
the obsolesence (or not) of a part based on your own experience
alone is not a great way to make judgements about these things.
>Of course all these UARTs can /talk/ to 16550 UARTs,
Yes, that's the whole point of a serial protocol between
disparate systems. :-)
>but they are not
>compatible in their design or hardware register maps despite plenty of
>similarity.
If you go back and re-read Scott's statement, he said modern
systems are usually using a 16550 or a PL101-compatible UART.
That's true; ARM and x86 parts are extraordinarily common.
Of course, there are and have been others; I've personally
worked with Zilog and Motorola parts in addition to the
aforementioned two.
>>>> Sure, the modem signals are obsolete and not often used.
>>>>
>>>> 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.
>>>
>>> I use serial ports all the time. I've never had any use for XON/XOFF,
>>> or hardware flow control (the RTS signal is often used for RS-485 drive
>>> enable), and regularly use 3 MBaud for local connections to fast
>>> microcontrollers.
>>
>> I use 3MBAUD, 16550-compatible UARTs embedded in AMD's EPYC SoCs
>> daily. We use hardware flow control to avoid dropping
>> characters when speaking to a fast uctlr running our own
>> embedded OS. The DW part in the SoC even supports auto HW flow
>> control and manages the FIFOs and signaling more or less
>> independently of the host (which actually caused a problem in
>> our driver a few months back).
>>
>> If reliable delivery of data is important to you, some kind of
>> flow control is useful, whether hardware or software based. If
>> it's just for debug spew, you may not care.
>
>If your systems are fast enough, and you have the right priorities for
>your threads, interrupts, DMAs, etc., then you don't need flow control.
>
>And most protocols (other than debug outputs) used over serial ports in
>embedded systems are not continuous traffic flows - you have packets,
>and typically have request/response patterns. As long as you have DMA
>to give you FIFOs that are big enough, you can consider the packet
>reception and answering as high-level software flow control.
Again, extrapolating from your own personal experience to other
areas is leading to a specious conclusion. You hinted at the
issue: _if_ your systems can keep up, you may be ok. But on a
large system, running a multiuser multitasking operating system,
doing a ton of IO on high speed devices, dealing with many
thousands of interrupts a second across many cores, you may not
be able to keep up.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-24 15:02 +0200 |
| Message-ID | <111gkgm$2vhih$1@dont-email.me> |
| In reply to | #400221 |
On 24/06/2026 12:47, Dan Cross wrote: > In article <111eli4$2g1qh$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 23/06/2026 19:12, Dan Cross wrote: >>> In article <111eavb$2c615$1@dont-email.me>, >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 23/06/2026 17:35, Scott Lurndal wrote: >>>> >>>>>> 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. >>>> >>>> 16550 UARTs are long obsolete. Some embedded processors might have >>>> UARTs that have register sets compatible with them, but I don't think it >>>> is common. Microcontrollers certainly don't make any attempt to have >>>> compatibility with those register sets. >>> >>> This is simply incorrect. Lots of parts still have integrated >>> 16550-compatible UARTs; the designware part that is common in a >>> lot of SoC's will even go up to 3MBAUD. >> >> I don't know all embedded microprocessors. I suspect that in order to >> remain as "PC compatible" as possible, x86 SoC's might have 16550 >> compatible UARTs. > > Essentially every modern x86 SoC has at least one; usually > several. They may or may not be lined out, but they're there. Fair enough. But x86 SoC's are a tiny fraction of SoC or embedded processors, which are predominantly ARM based. And microcontrollers are orders of magnitude more common than processors, embedded or not. Assuming you are correct (and I have no reason to doubt it, but have not checked independently) that modern x86 SoCs have 16550 UARTs, then they are by definition not obsolete. But in pretty much all other devices, built-in UARTs are not 16550 compatible because there are no benefits in doing that, while alternative designs are significantly better (in various possible ways). So "obsolete" was an exaggeration. But I think if you were to make a list of the top hundred microcontrollers and microprocessor SoCs, order by the number of devices shipped during the last few years, I do not expect you'd see more than a few low down in the list that had a 16550 UART. (Scott also mentioned PL011 UARTs, which I did not discuss - these are ARM designs and thus common in some ARM microprocessors, though not in ARM microcontrollers. They are also not found in most industrial ARM SoCs, such as the i.mx families - makers of such chips already have their own peripheral device IPs, which they use. The PL011, from the quick look I had, seems a reasonable enough UART for many purposes, with support for DMA and timeouts. It appears to lack RS-485 support, but perhaps I missed some details.) > > Some other systems may use 16550-compatible parts as well; as I > mentioned, DesignWare markets one as an embeddable piece of IP > that one can incorporate into one's own design. > There are countless 16550 (or 8250, or similar) models available under a variety of licenses. >> Many others do not. The NXP i.mx family, which is one of the most >> popular in industrial usage, have UARTs that do not have 16550 register >> sets. There is a reason linux/drivers/tty/serial has several dozen C >> files, supporting several dozen UARTs. Critically, embedded UARTs >> (excluding 16550 compatible ones) support DMA. > > I did not say that other systems used 16550, I was disputing the > incorrect statement that "16550 UARTs are long obsolete." If > you mean discrete UART chips signaling at TTL levels, whether > shifted to RS-232 levels or not, you're correct, but I took your > statement to be more general. Simply, they are not obsolete at > all, and they're extraordinarily common. I accept that they exist - I dispute that they are common, at least viewed in relation to the types of microprocessor SoCs or microcontrollers currently available, or in terms of numbers shipped. > >> And of the perhaps 20 or 30 microcontroller families I have used over >> the years, I don't remember ever having seen one with a UART that is >> 16550 compatible. (I did, on a couple of boards, use a dedicated 16x50 >> UART chip, possibly a 16450.) > > Ok, but your personal experience is anecdotal and by your own > admission not representative of large machines. Judging that > the obsolesence (or not) of a part based on your own experience > alone is not a great way to make judgements about these things. > Embedded ARM systems outship embedded x86 systems by a factor of 1000 or more (from my attempts at googling - noting that you don't get real, concrete figures without paying real, concrete money to marketing and analysis companies). There are also devices where the core is neither ARM nor x86. None of these, as a rule, have 16550's - they have much better UARTs. (For small microcontrollers, "better" can mean smaller and lower power, rather than necessarily additional useful features.) Remember, the sole reason anyone would want to use a 16550 is compatibility with code that expects a 16550. And that means, to a very large extent, old x86 code or newer x86 code that is written to be compatible with the old code and hardware. >> Of course all these UARTs can /talk/ to 16550 UARTs, > > Yes, that's the whole point of a serial protocol between > disparate systems. :-) > >> but they are not >> compatible in their design or hardware register maps despite plenty of >> similarity. > > If you go back and re-read Scott's statement, he said modern > systems are usually using a 16550 or a PL101-compatible UART. > That's true; ARM and x86 parts are extraordinarily common. It's entirely possible that there has been different interpretations about "the microprocessors you routinely use". It's very likely that on some or all of the PC's I have on my desk, there is a 16550 (or related) UART inside - probably as part of the supporting chipset rather than the processor, and probably not even routed to a header on the motherboard. On some of my older "archived" machines, they certainly had 16550-style serial ports. In the context, however, I viewed it in terms of the microprocessors and microcontrollers I work with. Glancing around my desk, I think I have perhaps 2 different Linux SoCs and 6 or 7 different microcontrollers on boards that I am using in projects under active development at the moment. Those are the ones I am /using/, and none have 16550's (or even PL011's). If I were to add up the count of microcontrollers and embedded processors and microcontrollers in my office, I'd guess I could easily find a hundred in products that we neither design nor program - in switches, routers, keyboards, powerbanks, monitors, hard drives, "smart" lights, oscilloscopes, and everything else. And there's probably another half-hundred microcontrollers in boards that we have made, in boxes around the office which I am not working with at the moment. (I've had the same office for 20 years, and still have not found the rubbish bin...) Now, I can agree that there are likely to be some PL011 UARTs around - if nothing else, I know there is one on each of the Raspberry Pi's I have scattered about. It was the 16550 I said (admittedly an exaggeration) was obsolete, not the PL011 - the PL011 is a perfectly serviceable UART for many modern uses. I would not be surprised if there was a PL011 in the ARM SoC's in some of the routers and managed switches I have, for example. But there are none in any of the chips I work with, as far as I am aware. > > Of course, there are and have been others; I've personally > worked with Zilog and Motorola parts in addition to the > aforementioned two. > To be clear here, you are saying you have worked with microprocessors or microcontrollers with other kinds of UARTs than 16550's or PL011's ? Or with other stand-alone UART chips? I know both Motorola and Zilog produced stand-alone UART chips, and I know Motorola (then Freescale, now part of NXP) have made a countless number of processors and microcontrollers with built-in UARTs that are not 16550 compatible. >>>>> Sure, the modem signals are obsolete and not often used. >>>>> >>>>> 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. >>>> >>>> I use serial ports all the time. I've never had any use for XON/XOFF, >>>> or hardware flow control (the RTS signal is often used for RS-485 drive >>>> enable), and regularly use 3 MBaud for local connections to fast >>>> microcontrollers. >>> >>> I use 3MBAUD, 16550-compatible UARTs embedded in AMD's EPYC SoCs >>> daily. We use hardware flow control to avoid dropping >>> characters when speaking to a fast uctlr running our own >>> embedded OS. The DW part in the SoC even supports auto HW flow >>> control and manages the FIFOs and signaling more or less >>> independently of the host (which actually caused a problem in >>> our driver a few months back). >>> >>> If reliable delivery of data is important to you, some kind of >>> flow control is useful, whether hardware or software based. If >>> it's just for debug spew, you may not care. >> >> If your systems are fast enough, and you have the right priorities for >> your threads, interrupts, DMAs, etc., then you don't need flow control. >> >> And most protocols (other than debug outputs) used over serial ports in >> embedded systems are not continuous traffic flows - you have packets, >> and typically have request/response patterns. As long as you have DMA >> to give you FIFOs that are big enough, you can consider the packet >> reception and answering as high-level software flow control. > > Again, extrapolating from your own personal experience to other > areas is leading to a specious conclusion. You hinted at the > issue: _if_ your systems can keep up, you may be ok. But on a > large system, running a multiuser multitasking operating system, > doing a ton of IO on high speed devices, dealing with many > thousands of interrupts a second across many cores, you may not > be able to keep up. > Of course you can, if that's what you want to do with the system. A Gbit network interface generates thousands of interrupts a second. But is entirely fair to say that general purpose OS's, and x86 hardware, are not well suited to quick reactions and low or predictable latencies. Throughput is usually not an issue, but accurate timing is hard to achieve. It is not without reason that many embedded systems have a Linux SOM for networking and high-level decisions, and microcontrollers for the fast reaction and deterministic control stuff. (Many SoC's targetting industrial embedded Linux have microcontrollers in the SoC itself.) And it is also fair to say that if you want to have demanding serial port usage on a general-purpose OS, you want a decent, modern UART rather than an old-fashioned 16550.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-25 11:29 +0000 |
| Message-ID | <111j3ej$3n1$1@reader1.panix.com> |
| In reply to | #400228 |
In article <111gkgm$2vhih$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 24/06/2026 12:47, Dan Cross wrote:
>> In article <111eli4$2g1qh$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 23/06/2026 19:12, Dan Cross wrote:
>>>> In article <111eavb$2c615$1@dont-email.me>,
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> On 23/06/2026 17:35, Scott Lurndal wrote:
>>>>>>> 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.
>>>>>
>>>>> 16550 UARTs are long obsolete. Some embedded processors might have
>>>>> UARTs that have register sets compatible with them, but I don't think it
>>>>> is common. Microcontrollers certainly don't make any attempt to have
>>>>> compatibility with those register sets.
>>>>
>>>> This is simply incorrect. Lots of parts still have integrated
>>>> 16550-compatible UARTs; the designware part that is common in a
>>>> lot of SoC's will even go up to 3MBAUD.
>>>
>>> I don't know all embedded microprocessors. I suspect that in order to
>>> remain as "PC compatible" as possible, x86 SoC's might have 16550
>>> compatible UARTs.
>>
>> Essentially every modern x86 SoC has at least one; usually
>> several. They may or may not be lined out, but they're there.
>
>Fair enough.
>
>But x86 SoC's are a tiny fraction of SoC or embedded processors, which
>are predominantly ARM based. And microcontrollers are orders of
>magnitude more common than processors, embedded or not.
Again, not something I was commenting on. Low(er) volume !=
obsolete.
>Assuming you are correct (and I have no reason to doubt it, but have not
>checked independently) that modern x86 SoCs have 16550 UARTs, then they
>are by definition not obsolete. But in pretty much all other devices,
>built-in UARTs are not 16550 compatible because there are no benefits in
>doing that, while alternative designs are significantly better (in
>various possible ways).
There are things I do not like about the 8250-series UARTs, but
I do not know what criteria you are using to judge the relative
merits of the 16550 versus alternatives. Given that you don't
use them, one wonders what your basis for comparison is, as
well.
>So "obsolete" was an exaggeration. But I think if you were to make a
>list of the top hundred microcontrollers and microprocessor SoCs, order
>by the number of devices shipped during the last few years, I do not
>expect you'd see more than a few low down in the list that had a 16550 UART.
Perhaps? But also irrelevant.
>(Scott also mentioned PL011 UARTs, which I did not discuss - these are
>ARM designs and thus common in some ARM microprocessors, though not in
>ARM microcontrollers. They are also not found in most industrial ARM
>SoCs, such as the i.mx families - makers of such chips already have
>their own peripheral device IPs, which they use. The PL011, from the
>quick look I had, seems a reasonable enough UART for many purposes, with
>support for DMA and timeouts. It appears to lack RS-485 support, but
>perhaps I missed some details.)
I just checked and it looks like ST ships PL011's in a bunch of
Cortex-M class parts. Of course, there are a ton of ARM
microcontrollers, but if you reread Scott's message (again) he
mentions mircoprocessors, not specificially uctlr's.
>> Some other systems may use 16550-compatible parts as well; as I
>> mentioned, DesignWare markets one as an embeddable piece of IP
>> that one can incorporate into one's own design.
>
>There are countless 16550 (or 8250, or similar) models available under a
>variety of licenses.
Yes.
>>> Many others do not. The NXP i.mx family, which is one of the most
>>> popular in industrial usage, have UARTs that do not have 16550 register
>>> sets. There is a reason linux/drivers/tty/serial has several dozen C
>>> files, supporting several dozen UARTs. Critically, embedded UARTs
>>> (excluding 16550 compatible ones) support DMA.
>>
>> I did not say that other systems used 16550, I was disputing the
>> incorrect statement that "16550 UARTs are long obsolete." If
>> you mean discrete UART chips signaling at TTL levels, whether
>> shifted to RS-232 levels or not, you're correct, but I took your
>> statement to be more general. Simply, they are not obsolete at
>> all, and they're extraordinarily common.
>
>I accept that they exist - I dispute that they are common, at least
>viewed in relation to the types of microprocessor SoCs or
>microcontrollers currently available, or in terms of numbers shipped.
That's fine, but I made no statement about that.
>>> And of the perhaps 20 or 30 microcontroller families I have used over
>>> the years, I don't remember ever having seen one with a UART that is
>>> 16550 compatible. (I did, on a couple of boards, use a dedicated 16x50
>>> UART chip, possibly a 16450.)
>>
>> Ok, but your personal experience is anecdotal and by your own
>> admission not representative of large machines. Judging that
>> the obsolesence (or not) of a part based on your own experience
>> alone is not a great way to make judgements about these things.
>
>Embedded ARM systems outship embedded x86 systems by a factor of 1000 or
>more (from my attempts at googling - noting that you don't get real,
>concrete figures without paying real, concrete money to marketing and
>analysis companies). There are also devices where the core is neither
>ARM nor x86. None of these, as a rule, have 16550's - they have much
>better UARTs. (For small microcontrollers, "better" can mean smaller
>and lower power, rather than necessarily additional useful features.)
term% uname -a
OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64
term% dmesg | grep 16550
com0 at simplebus0: dw16550
term%
>Remember, the sole reason anyone would want to use a 16550 is
>compatibility with code that expects a 16550. And that means, to a very
>large extent, old x86 code or newer x86 code that is written to be
>compatible with the old code and hardware.
Sure. I'm sure there are any number of reasons why a vendor
would pick any given type of UART; software compatibility with
existing drivers is surely one of them.
> [snip personal experience]
>
>> Of course, there are and have been others; I've personally
>> worked with Zilog and Motorola parts in addition to the
>> aforementioned two.
>
>To be clear here, you are saying you have worked with microprocessors or
>microcontrollers with other kinds of UARTs than 16550's or PL011's ? Or
>with other stand-alone UART chips?
Yes to both. In this case, I am referring specifically to
discrete UART parts from both vendors.
>I know both Motorola and Zilog
>produced stand-alone UART chips, and I know Motorola (then Freescale,
>now part of NXP) have made a countless number of processors and
>microcontrollers with built-in UARTs that are not 16550 compatible.
I don't know what the latter has to do with the former, or the
larger discussion. You seem to be discussing something that I
never said or implied.
FTR I am saying I have used discrete UART parts from both Zilog
(Zilog UARTs used to be common in Sun workstations) and Motorola
(they had a reasonable DUART that worked well with 68k).
>>>>>> Sure, the modem signals are obsolete and not often used.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> I use serial ports all the time. I've never had any use for XON/XOFF,
>>>>> or hardware flow control (the RTS signal is often used for RS-485 drive
>>>>> enable), and regularly use 3 MBaud for local connections to fast
>>>>> microcontrollers.
>>>>
>>>> I use 3MBAUD, 16550-compatible UARTs embedded in AMD's EPYC SoCs
>>>> daily. We use hardware flow control to avoid dropping
>>>> characters when speaking to a fast uctlr running our own
>>>> embedded OS. The DW part in the SoC even supports auto HW flow
>>>> control and manages the FIFOs and signaling more or less
>>>> independently of the host (which actually caused a problem in
>>>> our driver a few months back).
>>>>
>>>> If reliable delivery of data is important to you, some kind of
>>>> flow control is useful, whether hardware or software based. If
>>>> it's just for debug spew, you may not care.
>>>
>>> If your systems are fast enough, and you have the right priorities for
>>> your threads, interrupts, DMAs, etc., then you don't need flow control.
>>>
>>> And most protocols (other than debug outputs) used over serial ports in
>>> embedded systems are not continuous traffic flows - you have packets,
>>> and typically have request/response patterns. As long as you have DMA
>>> to give you FIFOs that are big enough, you can consider the packet
>>> reception and answering as high-level software flow control.
>>
>> Again, extrapolating from your own personal experience to other
>> areas is leading to a specious conclusion. You hinted at the
>> issue: _if_ your systems can keep up, you may be ok. But on a
>> large system, running a multiuser multitasking operating system,
>> doing a ton of IO on high speed devices, dealing with many
>> thousands of interrupts a second across many cores, you may not
>> be able to keep up.
>
>Of course you can, if that's what you want to do with the system.
No, not really.
Perhaps in the uctlr world that is true, but in that world
workloads tend to be fixed and predictible; in the world of
large systems, things are far more dynamic. Interrupts can, and
do, get lost; FIFOs get full; data can get corrupted; flow
control and synchronization between endpoints in a
communications protocol is useful.
Perhaps that doesn't matter for your use cases, and you've never
needed it; but don't extrapolate to other use cases you have no
experience with.
>A Gbit network interface generates thousands of interrupts a second. But
>is entirely fair to say that general purpose OS's, and x86 hardware, are
>not well suited to quick reactions and low or predictable latencies.
The hardware is fine. It's the OS that usually struggles
because there may be more load on the machine than can
reasonably be accommodated.
>Throughput is usually not an issue, but accurate timing is hard to
>achieve. It is not without reason that many embedded systems have a
>Linux SOM for networking and high-level decisions, and microcontrollers
>for the fast reaction and deterministic control stuff. (Many SoC's
>targetting industrial embedded Linux have microcontrollers in the SoC
>itself.) And it is also fair to say that if you want to have demanding
>serial port usage on a general-purpose OS, you want a decent, modern
>UART rather than an old-fashioned 16550.
Again, you haven't specified what's "old-fashioned" about it, or
what makes alternatives superior; on modern systems, this is not
your father's 8250. Modern SoCs support DMA and MMIO accesses
for UARTs and speeds up to 3MBAUD or more, even if the registers
are the same 'ol 16550 registers since the 486 era (with some
extensions, of course).
Beyond that, you're correct that many modern SoCs have embedded
microcontrollers capable of real-time response; yay. Using one
just to avoid flow control over a serial protocol seems like
going to extremes to avoid a simple thing. As I mentioned, the
DW part even does CTS/RTS HW flow control automatically, without
software intervention.
This is hardly an obsolete part in any measurable sense, and
arguments about the volume of microcontrollers using other parts
don't make it obsolete.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-25 15:31 +0000 |
| Subject | NIC interrupt rates (was UART discussion; previously was Re: this guy talks about fopen (and im thinking about fopen for network) |
| Message-ID | <cRb%R.280$GLn8.251@fx07.iad> |
| In reply to | #400241 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <111gkgm$2vhih$1@dont-email.me>, >David Brown <david.brown@hesbynett.no> wrote: <snip> >>A Gbit network interface generates thousands of interrupts a second. But >>is entirely fair to say that general purpose OS's, and x86 hardware, are >>not well suited to quick reactions and low or predictable latencies. > I would dispute that. A modern 1Gb (or faster) network interface will use various hardware interrupt moderation techniques to reduce the interrupt rate to the OS. 10/25/50/100Gb network adapters must use such techniques to achieve line rate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-25 19:15 +0200 |
| Message-ID | <111jnmp$3tni8$1@dont-email.me> |
| In reply to | #400241 |
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: >>> In article <111eli4$2g1qh$1@dont-email.me>, >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 23/06/2026 19:12, Dan Cross wrote: >>>>> In article <111eavb$2c615$1@dont-email.me>, >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> On 23/06/2026 17:35, Scott Lurndal wrote: >>>>>>>> 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. >>>>>> >>>>>> 16550 UARTs are long obsolete. Some embedded processors might have >>>>>> UARTs that have register sets compatible with them, but I don't think it >>>>>> is common. Microcontrollers certainly don't make any attempt to have >>>>>> compatibility with those register sets. >>>>> >>>>> This is simply incorrect. Lots of parts still have integrated >>>>> 16550-compatible UARTs; the designware part that is common in a >>>>> lot of SoC's will even go up to 3MBAUD. >>>> >>>> I don't know all embedded microprocessors. I suspect that in order to >>>> remain as "PC compatible" as possible, x86 SoC's might have 16550 >>>> compatible UARTs. >>> >>> Essentially every modern x86 SoC has at least one; usually >>> several. They may or may not be lined out, but they're there. >> >> Fair enough. >> >> But x86 SoC's are a tiny fraction of SoC or embedded processors, which >> are predominantly ARM based. And microcontrollers are orders of >> magnitude more common than processors, embedded or not. > > 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". >> Assuming you are correct (and I have no reason to doubt it, but have not >> checked independently) that modern x86 SoCs have 16550 UARTs, then they >> are by definition not obsolete. But in pretty much all other devices, >> built-in UARTs are not 16550 compatible because there are no benefits in >> doing that, while alternative designs are significantly better (in >> various possible ways). > > There are things I do not like about the 8250-series UARTs, but > I do not know what criteria you are using to judge the relative > merits of the 16550 versus alternatives. Given that you don't > use them, one wonders what your basis for comparison is, as > well. I already said that I /had/ used one, as specific external chip, on a board. Admittedly that was a long time ago. But regardless of how much or how little I have used them, I am entirely capable of looking at a datasheet and judging the features a device has or does not have. I can look at the way a peripheral is connected, and the kind of databus it supports, the kind of inputs and outputs it has, the registers it has, and everything else. That's an important part of the job I do. The idea that I would have to have /used/ a device to be able to compare it to other related devices is, frankly, bizarre. > >> So "obsolete" was an exaggeration. But I think if you were to make a >> list of the top hundred microcontrollers and microprocessor SoCs, order >> by the number of devices shipped during the last few years, I do not >> expect you'd see more than a few low down in the list that had a 16550 UART. > > Perhaps? But also irrelevant. > >> (Scott also mentioned PL011 UARTs, which I did not discuss - these are >> ARM designs and thus common in some ARM microprocessors, though not in >> ARM microcontrollers. They are also not found in most industrial ARM >> SoCs, such as the i.mx families - makers of such chips already have >> their own peripheral device IPs, which they use. The PL011, from the >> quick look I had, seems a reasonable enough UART for many purposes, with >> support for DMA and timeouts. It appears to lack RS-485 support, but >> perhaps I missed some details.) > > 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? ST makes a /lot/ of devices with Cortex-M cores, and I have not looked at the details of more than a small fraction of them. None of the ones I have seen have a PL011, and it would surprise me to hear that they used them. If ST incorporates a PL011 into a microcontroller with a Cortex-M core, they need to pay royalties to ARM for that (along with the cost of the cpu core) - if they use one of their own UART peripherals, it costs them nothing but the die space and they can choose from UARTs that smaller and lower power than the PL011, or ones with additional features and capabilities. ST has had re-usable UART cores from long before the PL011 existed. I am not saying that I know for sure that they haven't picked PL011's, but I find hard to see how it would make sense. I am also not saying the PL011 is a bad UART - it has more useful features than the 16550 (DMA support is key) - but it also lacks features that I find useful in the UARTs in the ST Cortex-M33 device I am working with right now. The only reference to PL011's that I found on ST's site was on some ARM926 based processors from fifteen years ago. You can still buy the devices, so they are not obsolete, but they are long outdated and marked "not suitable for new designs". (Again, the PL011 appears to be a reasonable enough UART, but it's not used in modern processors targeting industrial use. Basically, it's not used in processors where you expect to use the UART for something other than debugging output or a serial terminal.) > Of course, there are a ton of ARM > microcontrollers, but if you reread Scott's message (again) he > mentions mircoprocessors, not specificially uctlr's. > And if you re-read Scott's message, you'll see there's been a dozen posts since then - mentioning other related things. We have moved on from there. >>> Some other systems may use 16550-compatible parts as well; as I >>> mentioned, DesignWare markets one as an embeddable piece of IP >>> that one can incorporate into one's own design. >> >> There are countless 16550 (or 8250, or similar) models available under a >> variety of licenses. > > Yes. > >>>> Many others do not. The NXP i.mx family, which is one of the most >>>> popular in industrial usage, have UARTs that do not have 16550 register >>>> sets. There is a reason linux/drivers/tty/serial has several dozen C >>>> files, supporting several dozen UARTs. Critically, embedded UARTs >>>> (excluding 16550 compatible ones) support DMA. >>> >>> I did not say that other systems used 16550, I was disputing the >>> incorrect statement that "16550 UARTs are long obsolete." If >>> you mean discrete UART chips signaling at TTL levels, whether >>> shifted to RS-232 levels or not, you're correct, but I took your >>> statement to be more general. Simply, they are not obsolete at >>> all, and they're extraordinarily common. >> >> I accept that they exist - I dispute that they are common, at least >> viewed in relation to the types of microprocessor SoCs or >> microcontrollers currently available, or in terms of numbers shipped. > > That's fine, but I made no statement about that. > >>>> And of the perhaps 20 or 30 microcontroller families I have used over >>>> the years, I don't remember ever having seen one with a UART that is >>>> 16550 compatible. (I did, on a couple of boards, use a dedicated 16x50 >>>> UART chip, possibly a 16450.) >>> >>> Ok, but your personal experience is anecdotal and by your own >>> admission not representative of large machines. Judging that >>> the obsolesence (or not) of a part based on your own experience >>> alone is not a great way to make judgements about these things. >> >> Embedded ARM systems outship embedded x86 systems by a factor of 1000 or >> more (from my attempts at googling - noting that you don't get real, >> concrete figures without paying real, concrete money to marketing and >> analysis companies). There are also devices where the core is neither >> ARM nor x86. None of these, as a rule, have 16550's - they have much >> better UARTs. (For small microcontrollers, "better" can mean smaller >> and lower power, rather than necessarily additional useful features.) > > term% uname -a > OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64 > term% dmesg | grep 16550 > com0 at simplebus0: dw16550 > term% That is very interesting, and somewhat unexpected. Thanks for the example. Where is this riscv core from? > >> Remember, the sole reason anyone would want to use a 16550 is >> compatibility with code that expects a 16550. And that means, to a very >> large extent, old x86 code or newer x86 code that is written to be >> compatible with the old code and hardware. > > Sure. I'm sure there are any number of reasons why a vendor > would pick any given type of UART; software compatibility with > existing drivers is surely one of them. > >> [snip personal experience] >> >>> Of course, there are and have been others; I've personally >>> worked with Zilog and Motorola parts in addition to the >>> aforementioned two. >> >> To be clear here, you are saying you have worked with microprocessors or >> microcontrollers with other kinds of UARTs than 16550's or PL011's ? Or >> with other stand-alone UART chips? > > Yes to both. In this case, I am referring specifically to > discrete UART parts from both vendors. > >> I know both Motorola and Zilog >> produced stand-alone UART chips, and I know Motorola (then Freescale, >> now part of NXP) have made a countless number of processors and >> microcontrollers with built-in UARTs that are not 16550 compatible. > > I don't know what the latter has to do with the former, or the > larger discussion. You seem to be discussing something that I > never said or implied. > (As a general point, not everything people write is an immediate direct response to what someone else wrote - nor is it necessarily disputing what they wrote. People add extra information, anecdotes, clarifications, questions, and digressions. Several times you have said my comments were irrelevant, or denied saying or implying the point you think I am disputing. My posts are not a series of attacks on what I imagine you said. While it is entirely possible that I misunderstand or misread something someone says, and respond to that misunderstood point, usually if I write something that does not appear to be a direct response to a previous point, it is not a direct response to /any/ point - real or imagined. Conversations would quickly get boring if they never wander a little from previous points.) > FTR I am saying I have used discrete UART parts from both Zilog > (Zilog UARTs used to be common in Sun workstations) and Motorola > (they had a reasonable DUART that worked well with 68k). > >>>>>>> Sure, the modem signals are obsolete and not often used. >>>>>>> >>>>>>> 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. >>>>>> >>>>>> I use serial ports all the time. I've never had any use for XON/XOFF, >>>>>> or hardware flow control (the RTS signal is often used for RS-485 drive >>>>>> enable), and regularly use 3 MBaud for local connections to fast >>>>>> microcontrollers. >>>>> >>>>> I use 3MBAUD, 16550-compatible UARTs embedded in AMD's EPYC SoCs >>>>> daily. We use hardware flow control to avoid dropping >>>>> characters when speaking to a fast uctlr running our own >>>>> embedded OS. The DW part in the SoC even supports auto HW flow >>>>> control and manages the FIFOs and signaling more or less >>>>> independently of the host (which actually caused a problem in >>>>> our driver a few months back). >>>>> >>>>> If reliable delivery of data is important to you, some kind of >>>>> flow control is useful, whether hardware or software based. If >>>>> it's just for debug spew, you may not care. >>>> >>>> If your systems are fast enough, and you have the right priorities for >>>> your threads, interrupts, DMAs, etc., then you don't need flow control. >>>> >>>> And most protocols (other than debug outputs) used over serial ports in >>>> embedded systems are not continuous traffic flows - you have packets, >>>> and typically have request/response patterns. As long as you have DMA >>>> to give you FIFOs that are big enough, you can consider the packet >>>> reception and answering as high-level software flow control. >>> >>> Again, extrapolating from your own personal experience to other >>> areas is leading to a specious conclusion. You hinted at the >>> issue: _if_ your systems can keep up, you may be ok. But on a >>> large system, running a multiuser multitasking operating system, >>> doing a ton of IO on high speed devices, dealing with many >>> thousands of interrupts a second across many cores, you may not >>> be able to keep up. >> >> Of course you can, if that's what you want to do with the system. > > No, not really. > > Perhaps in the uctlr world that is true, but in that world > workloads tend to be fixed and predictible; in the world of > large systems, things are far more dynamic. Interrupts can, and > do, get lost; FIFOs get full; data can get corrupted; flow > control and synchronization between endpoints in a > communications protocol is useful. I do appreciate that on "big" systems things are more dynamic and unpredictable compared to many microcontroller systems. And yes, things can get lost or corrupted - that is true in communications in microcontroller systems too. As the Mythbuster's tee-shirt says, failure is always an option. You almost always want some kind of control, synchronisation, error checking, and retry mechanism. You usually have several of these, at different levels of the system from the hardware, through low-level drivers or interfaces, and up to high-level control. But yes, really - you /can/ handle thousands of interrupts per second on Linux systems if you want to. I've happily passed packets through Linux systems at high speeds, without failures. My current system has a microcontroller connected to a Linux SOM. My focus is on the microcontroller software, but amongst other things I have Python code on the PC sending UDP telegrams via the SOM (with a USB to Ethernet dongle) to the microcontroller. I run about 2,000+ transactions a second, without failures - where a transaction means the Linux SOM getting a packet in, routing it out to the microcontroller, getting a reply back, and routing that towards the PC. In the background, the SOM is continuously bzipping and bunzipping a big file, just to have it working on something. How many interrupts per second do you think that is? Of course there are other patterns of interrupts that are more stressful than the ones I have there. But then, I am running just a single core SoC here, and the speed bottlenecks are mostly in the Python test code. And I have done nothing towards improving the latencies or anything else - this is a bog standard Debian ARM installation. > > Perhaps that doesn't matter for your use cases, and you've never > needed it; but don't extrapolate to other use cases you have no > experience with. > I have worked on systems where we have locked interrupts and programs to particular cores (of a 4 core SoC) to minimise jitter, with real-time extensions in the kernel. Admittedly there were not many packets handled in and out every millisecond, but the millisecond tick needed to be within about 1% jitter. Of course there are vast combinations of hardware and requirements that I have /not/ worked with. But I have seen enough to know that you can do a great deal with Linux even without careful tuning - and even more with tuning. Thousands of interrupts per second is peanuts to a modern Linux system - big or small. Tens or hundreds of thousands of interrupts per second - then you are pushing it, and will want to re-think things a bit. (My understanding is that for very fast network cards on big systems, you dedicate a core to the task and using polling rather than interrupts to avoid context switches. But that is definitely outside my experience.) And certainly it is harder to do high frequency operations on Linux, and on microprocessors, than on microcontrollers. Context switches are massively more demanding, and you have little details like "security" that are a different world on a multi-user system than on a microcontroller. On one 500 MHz microcontroller I did some testing with an RTOS doing round-robin context switches at 1 MHz, taking about 10% of the processor capacity. I don't think you'd get far with a jiffy rate of 1 MHz on any Linux system, big or small. And I have also had a system where I did bit-banging of a 115200 baud UART with 4x oversampling. That's 460,800 timer interrupts per second - on a microcontroller running with a 18.432 MHz clock. 40 clocks per interrupt, and time to spare for the rest of the application. >> A Gbit network interface generates thousands of interrupts a second. But >> is entirely fair to say that general purpose OS's, and x86 hardware, are >> not well suited to quick reactions and low or predictable latencies. > > The hardware is fine. It's the OS that usually struggles > because there may be more load on the machine than can > reasonably be accommodated. > >> Throughput is usually not an issue, but accurate timing is hard to >> achieve. It is not without reason that many embedded systems have a >> Linux SOM for networking and high-level decisions, and microcontrollers >> for the fast reaction and deterministic control stuff. (Many SoC's >> targetting industrial embedded Linux have microcontrollers in the SoC >> itself.) And it is also fair to say that if you want to have demanding >> serial port usage on a general-purpose OS, you want a decent, modern >> UART rather than an old-fashioned 16550. > > Again, you haven't specified what's "old-fashioned" about it, or > what makes alternatives superior; on modern systems, this is not > your father's 8250. Modern SoCs support DMA and MMIO accesses > for UARTs and speeds up to 3MBAUD or more, even if the registers > are the same 'ol 16550 registers since the 486 era (with some > extensions, of course). Well, to be fair it depends on what you want to do with the UART - and my bias is towards industrial systems. I guess the biggest want an RS-485 driver line - when doing faster communication, that is an essential feature. (While I have never had the dubious pleasure of implementing Profibus DP, it runs at 12 Mbps on RS-485.) I like better control of FIFOs and triggers, for both interrupts and DMA. I have occasionally had need of 9 bit characters. Sending break characters is important in some protocols, like LIN. Automatic detection of frame start characters can significantly reduce the load on the rest of the system. Many modern full-featured UARTs have additional features like swapping pin polarity (great for when people wire up RS-485 buses incorrectly) or Rx/Tx pins, IrDA support, Smartcard support, Manchester encoding and other things that could reasonably also be done in hardware outside the UART. And of course there are different balances that can be achieved between features and power usage, and die space. Usually most UARTs are usable for most purposes, but some are definitely more convenient and better suited than others for offloading work. > > Beyond that, you're correct that many modern SoCs have embedded > microcontrollers capable of real-time response; yay. Using one > just to avoid flow control over a serial protocol seems like > going to extremes to avoid a simple thing. As I mentioned, the > DW part even does CTS/RTS HW flow control automatically, without > software intervention. > I would not pick a UART to /avoid/ hardware flow control support - but it is not a feature I have seen as useful since the days of dial-up modems. XON/XOFF style of software flow control is completely absent from anything I have been involved in. Of course there this software synchronisation and control, but it is at a higher level. > This is hardly an obsolete part in any measurable sense, and > arguments about the volume of microcontrollers using other parts > don't make it obsolete. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-25 18:29 +0000 |
| Message-ID | <Zre%R.8448$DyOf.3672@fx24.iad> |
| In reply to | #400246 |
David Brown <david.brown@hesbynett.no> writes: >On 25/06/2026 13:29, Dan Cross wrote: >> In article <111gkgm$2vhih$1@dont-email.me>, >> David Brown <david.brown@hesbynett.no> wrote: >>> >>> Embedded ARM systems outship embedded x86 systems by a factor of 1000 or >>> more (from my attempts at googling - noting that you don't get real, >>> concrete figures without paying real, concrete money to marketing and >>> analysis companies). There are also devices where the core is neither >>> ARM nor x86. None of these, as a rule, have 16550's - they have much >>> better UARTs. (For small microcontrollers, "better" can mean smaller >>> and lower power, rather than necessarily additional useful features.) >> >> term% uname -a >> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64 >> term% dmesg | grep 16550 >> com0 at simplebus0: dw16550 >> term% > >That is very interesting, and somewhat unexpected. Thanks for the >example. Where is this riscv core from? The dw16550 is synopsys (DW_apb_uart) optimized for the ARM APB bus. It's modeled on the 16550 for backward compatability yet includes additional features from 16650 and 16750 designs using MMIO registers rather than the x86 I/O space registers. It seems to be popular in some DSUs (e.g. Marvell Armada). > <snip> (My understanding is that for very fast network >cards on big systems, you dedicate a core to the task and using polling >rather than interrupts to avoid context switches. But that is >definitely outside my experience.) > There are various techniques to moderate the interrupt frequency at high packet arrival rates. Usually based on a packet-count + timer; the interrupt fires after the specified number of packets has arrived or the timer has expired.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-25 20:52 +0200 |
| Message-ID | <111jtcr$8p9$1@dont-email.me> |
| In reply to | #400247 |
On 25/06/2026 20:29, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 25/06/2026 13:29, Dan Cross wrote: >>> In article <111gkgm$2vhih$1@dont-email.me>, >>> David Brown <david.brown@hesbynett.no> wrote: > >>>> >>>> Embedded ARM systems outship embedded x86 systems by a factor of 1000 or >>>> more (from my attempts at googling - noting that you don't get real, >>>> concrete figures without paying real, concrete money to marketing and >>>> analysis companies). There are also devices where the core is neither >>>> ARM nor x86. None of these, as a rule, have 16550's - they have much >>>> better UARTs. (For small microcontrollers, "better" can mean smaller >>>> and lower power, rather than necessarily additional useful features.) >>> >>> term% uname -a >>> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64 >>> term% dmesg | grep 16550 >>> com0 at simplebus0: dw16550 >>> term% >> >> That is very interesting, and somewhat unexpected. Thanks for the >> example. Where is this riscv core from? > > The dw16550 is synopsys (DW_apb_uart) optimized for the ARM > APB bus. It's modeled on the 16550 for backward compatability > yet includes additional features from 16650 and 16750 designs > using MMIO registers rather than the x86 I/O space registers. > > It seems to be popular in some DSUs (e.g. Marvell Armada). > > >> <snip> (My understanding is that for very fast network >> cards on big systems, you dedicate a core to the task and using polling >> rather than interrupts to avoid context switches. But that is >> definitely outside my experience.) >> > > There are various techniques to moderate the interrupt frequency > at high packet arrival rates. Usually based on a packet-count + timer; the > interrupt fires after the specified number of packets has arrived > or the timer has expired. Basically, a FIFO at the packet level, in the same way that byte FIFOs work for UARTs ? I am sure that is a very good idea, especially for the higher speed interfaces. I don't see a problem with thousands of interrupts a second for 1 Gbps networking, but I do not see it going so well when scaling by a factor of 100 for 100 Gpbs! And for even higher rates, I believe it is common to have various kinds of accelerators tightly integrated with the network interface, further reducing the work (or at least the latency challenges) for the host. But again, those are not things I have done myself.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-26 14:58 +0000 |
| Message-ID | <psw%R.39143$7EZf.32201@fx40.iad> |
| In reply to | #400248 |
David Brown <david.brown@hesbynett.no> writes: >On 25/06/2026 20:29, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 25/06/2026 13:29, Dan Cross wrote: >>>> In article <111gkgm$2vhih$1@dont-email.me>, >>>> David Brown <david.brown@hesbynett.no> wrote: >> >>>>> >>>>> Embedded ARM systems outship embedded x86 systems by a factor of 1000 or >>>>> more (from my attempts at googling - noting that you don't get real, >>>>> concrete figures without paying real, concrete money to marketing and >>>>> analysis companies). There are also devices where the core is neither >>>>> ARM nor x86. None of these, as a rule, have 16550's - they have much >>>>> better UARTs. (For small microcontrollers, "better" can mean smaller >>>>> and lower power, rather than necessarily additional useful features.) >>>> >>>> term% uname -a >>>> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64 >>>> term% dmesg | grep 16550 >>>> com0 at simplebus0: dw16550 >>>> term% >>> >>> That is very interesting, and somewhat unexpected. Thanks for the >>> example. Where is this riscv core from? >> >> The dw16550 is synopsys (DW_apb_uart) optimized for the ARM >> APB bus. It's modeled on the 16550 for backward compatability >> yet includes additional features from 16650 and 16750 designs >> using MMIO registers rather than the x86 I/O space registers. >> >> It seems to be popular in some DSUs (e.g. Marvell Armada). >> >> >>> <snip> (My understanding is that for very fast network >>> cards on big systems, you dedicate a core to the task and using polling >>> rather than interrupts to avoid context switches. But that is >>> definitely outside my experience.) >>> >> >> There are various techniques to moderate the interrupt frequency >> at high packet arrival rates. Usually based on a packet-count + timer; the >> interrupt fires after the specified number of packets has arrived >> or the timer has expired. > >Basically, a FIFO at the packet level, in the same way that byte FIFOs >work for UARTs ? I am sure that is a very good idea, especially for the >higher speed interfaces. I don't see a problem with thousands of >interrupts a second for 1 Gbps networking, That's a lot of unnecessary overhead. Consider that at 1Gb/s, the controller can theoretically receive 1,488,095 64-byte packets every second. That's a million and a half interrupts per second. > but I do not see it going so >well when scaling by a factor of 100 for 100 Gpbs! Tis truth, forsooth. > And for even higher >rates, I believe it is common to have various kinds of accelerators >tightly integrated with the network interface, further reducing the work >(or at least the latency challenges) for the host. Indeed. Packet classification/Receive-side-scaling, handling the various tunneling protocols, VLANs, IPSEC, MPLS et alia are all efficiently done by hardware accelerators. Something I have done myself :-) > But again, those are >not things I have done myself. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-26 11:46 -0700 |
| Message-ID | <111mhe1$oeu5$1@dont-email.me> |
| In reply to | #400253 |
On 6/26/2026 7:58 AM, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 25/06/2026 20:29, Scott Lurndal wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 25/06/2026 13:29, Dan Cross wrote: >>>>> In article <111gkgm$2vhih$1@dont-email.me>, >>>>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>>>> >>>>>> Embedded ARM systems outship embedded x86 systems by a factor of 1000 or >>>>>> more (from my attempts at googling - noting that you don't get real, >>>>>> concrete figures without paying real, concrete money to marketing and >>>>>> analysis companies). There are also devices where the core is neither >>>>>> ARM nor x86. None of these, as a rule, have 16550's - they have much >>>>>> better UARTs. (For small microcontrollers, "better" can mean smaller >>>>>> and lower power, rather than necessarily additional useful features.) >>>>> >>>>> term% uname -a >>>>> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64 >>>>> term% dmesg | grep 16550 >>>>> com0 at simplebus0: dw16550 >>>>> term% >>>> >>>> That is very interesting, and somewhat unexpected. Thanks for the >>>> example. Where is this riscv core from? >>> >>> The dw16550 is synopsys (DW_apb_uart) optimized for the ARM >>> APB bus. It's modeled on the 16550 for backward compatability >>> yet includes additional features from 16650 and 16750 designs >>> using MMIO registers rather than the x86 I/O space registers. >>> >>> It seems to be popular in some DSUs (e.g. Marvell Armada). >>> >>> >>>> <snip> (My understanding is that for very fast network >>>> cards on big systems, you dedicate a core to the task and using polling >>>> rather than interrupts to avoid context switches. But that is >>>> definitely outside my experience.) >>>> >>> >>> There are various techniques to moderate the interrupt frequency >>> at high packet arrival rates. Usually based on a packet-count + timer; the >>> interrupt fires after the specified number of packets has arrived >>> or the timer has expired. >> >> Basically, a FIFO at the packet level, in the same way that byte FIFOs >> work for UARTs ? I am sure that is a very good idea, especially for the >> higher speed interfaces. I don't see a problem with thousands of >> interrupts a second for 1 Gbps networking, > > That's a lot of unnecessary overhead. Consider that at 1Gb/s, > the controller can theoretically receive 1,488,095 64-byte packets every second. > > That's a million and a half interrupts per second. > >> but I do not see it going so >> well when scaling by a factor of 100 for 100 Gpbs! > > Tis truth, forsooth. > > >> And for even higher >> rates, I believe it is common to have various kinds of accelerators >> tightly integrated with the network interface, further reducing the work >> (or at least the latency challenges) for the host. > > Indeed. Packet classification/Receive-side-scaling, handling the > various tunneling protocols, VLANs, IPSEC, MPLS et alia are all efficiently > done by hardware accelerators. Something I have done myself :-) Well done. :^) > >> But again, those are >> not things I have done myself. >>
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-27 01:57 +0000 |
| Message-ID | <111nama$4pm$1@reader1.panix.com> |
| In reply to | #400248 |
In article <111jtcr$8p9$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 25/06/2026 20:29, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 25/06/2026 13:29, Dan Cross wrote:
>>>> In article <111gkgm$2vhih$1@dont-email.me>,
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>>>>
>>>>> Embedded ARM systems outship embedded x86 systems by a factor of 1000 or
>>>>> more (from my attempts at googling - noting that you don't get real,
>>>>> concrete figures without paying real, concrete money to marketing and
>>>>> analysis companies). There are also devices where the core is neither
>>>>> ARM nor x86. None of these, as a rule, have 16550's - they have much
>>>>> better UARTs. (For small microcontrollers, "better" can mean smaller
>>>>> and lower power, rather than necessarily additional useful features.)
>>>>
>>>> term% uname -a
>>>> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64
>>>> term% dmesg | grep 16550
>>>> com0 at simplebus0: dw16550
>>>> term%
>>>
>>> That is very interesting, and somewhat unexpected. Thanks for the
>>> example. Where is this riscv core from?
>>
>> The dw16550 is synopsys (DW_apb_uart) optimized for the ARM
>> APB bus. It's modeled on the 16550 for backward compatability
>> yet includes additional features from 16650 and 16750 designs
>> using MMIO registers rather than the x86 I/O space registers.
>>
>> It seems to be popular in some DSUs (e.g. Marvell Armada).
>>
>>
>>> <snip> (My understanding is that for very fast network
>>> cards on big systems, you dedicate a core to the task and using polling
>>> rather than interrupts to avoid context switches. But that is
>>> definitely outside my experience.)
>>>
>>
>> There are various techniques to moderate the interrupt frequency
>> at high packet arrival rates. Usually based on a packet-count + timer; the
>> interrupt fires after the specified number of packets has arrived
>> or the timer has expired.
>
>Basically, a FIFO at the packet level, in the same way that byte FIFOs
>work for UARTs ? I am sure that is a very good idea, especially for the
>higher speed interfaces. I don't see a problem with thousands of
>interrupts a second for 1 Gbps networking, but I do not see it going so
>well when scaling by a factor of 100 for 100 Gpbs! And for even higher
>rates, I believe it is common to have various kinds of accelerators
>tightly integrated with the network interface, further reducing the work
>(or at least the latency challenges) for the host. But again, those are
>not things I have done myself.
It's important to understand that, when we talk about e.g. 100
Gbps NICs, that is not measuring single-stream performance; that
usually tops out well-below 100G. Rather, that's aggregated
across all streams handled by the ASIC. Any given part has many
queues, handling of those (and interrupt delivery) will be
smeared across cores to minimize per-interrupt latency, and
often a substantial amount of hardware offload is in play;
everything from IP checksum offloads to automatic recognition of
layer 4 protocols for hashing entire flows to dedicated queues
(to maintain locality when handling a given stream).
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-06-25 22:53 +0300 |
| Message-ID | <20260625225349.00006618@yahoo.com> |
| In reply to | #400247 |
On Thu, 25 Jun 2026 18:29:13 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > David Brown <david.brown@hesbynett.no> writes: > >On 25/06/2026 13:29, Dan Cross wrote: > >> In article <111gkgm$2vhih$1@dont-email.me>, > >> David Brown <david.brown@hesbynett.no> wrote: > > >>> > >>> Embedded ARM systems outship embedded x86 systems by a factor of > >>> 1000 or more (from my attempts at googling - noting that you > >>> don't get real, concrete figures without paying real, concrete > >>> money to marketing and analysis companies). There are also > >>> devices where the core is neither ARM nor x86. None of these, as > >>> a rule, have 16550's - they have much better UARTs. (For small > >>> microcontrollers, "better" can mean smaller and lower power, > >>> rather than necessarily additional useful features.) > >> > >> term% uname -a > >> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64 > >> term% dmesg | grep 16550 > >> com0 at simplebus0: dw16550 > >> term% > > > >That is very interesting, and somewhat unexpected. Thanks for the > >example. Where is this riscv core from? > > The dw16550 is synopsys (DW_apb_uart) optimized for the ARM > APB bus. It's modeled on the 16550 for backward compatability > yet includes additional features from 16650 and 16750 designs > using MMIO registers rather than the x86 I/O space registers. > > It seems to be popular in some DSUs (e.g. Marvell Armada). > > > > <snip> (My understanding is that for very fast network > >cards on big systems, you dedicate a core to the task and using > >polling rather than interrupts to avoid context switches. But that > >is definitely outside my experience.) > > > > There are various techniques to moderate the interrupt frequency > at high packet arrival rates. Usually based on a packet-count + > timer; the interrupt fires after the specified number of packets has > arrived or the timer has expired. In my STM32 designs it was possible (and easy) to take interupt moderation to its ultimate end, i.e. no interrupts at all. Their DMA is *that* good. Of course, my not very demanding requirements also helped. Unfortunately, for various reasons, both good and bad, after 2020 my Cortex-M MCUs tend to be from TI TIVA series rather than from STM32. TI DMA is not a total crap, but not in the STM class. I think, their DMA is based on some old ARM-supplied components, but not 100% sure about it. So, while on TiVa I have to make do with interrupt moderation instead of elimination.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-27 01:52 +0000 |
| Message-ID | <111naco$ka2$1@reader1.panix.com> |
| In reply to | #400246 |
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.
I get that you don't think this series is suitable for embedded
use, and that's fine: don't use it if you you don't want to in
microcontroller applications. But you're using your experience
in that domain to extrapolate and make a value judgement that
doesn't follow in a different domain.
>>> Assuming you are correct (and I have no reason to doubt it, but have not
>>> checked independently) that modern x86 SoCs have 16550 UARTs, then they
>>> are by definition not obsolete. But in pretty much all other devices,
>>> built-in UARTs are not 16550 compatible because there are no benefits in
>>> doing that, while alternative designs are significantly better (in
>>> various possible ways).
>>
>> There are things I do not like about the 8250-series UARTs, but
>> I do not know what criteria you are using to judge the relative
>> merits of the 16550 versus alternatives. Given that you don't
>> use them, one wonders what your basis for comparison is, as
>> well.
>
>I already said that I /had/ used one, as specific external chip, on a
>board. Admittedly that was a long time ago.
Yes, a long time ago: my statement was about the present, as was
your judgement.
>But regardless of how much or how little I have used them, I am entirely
>capable of looking at a datasheet and judging the features a device has
>or does not have. I can look at the way a peripheral is connected, and
>the kind of databus it supports, the kind of inputs and outputs it has,
>the registers it has, and everything else. That's an important part of
>the job I do. The idea that I would have to have /used/ a device to be
>able to compare it to other related devices is, frankly, bizarre.
The DW APB from Synopsis is common and I mentioned it at least
twice before Scott did, but you don't seem at all familiar with
it; it's pretty common.
>> [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.
The RPi2040 and Zynq boards seem to have PL011s, but are much
lower volume.
>> Of course, there are a ton of ARM
>> microcontrollers, but if you reread Scott's message (again) he
>> mentions mircoprocessors, not specificially uctlr's.
>
>And if you re-read Scott's message, you'll see there's been a dozen
>posts since then - mentioning other related things. We have moved on
>from there.
Yes, all of which seemed to be based on an incorrect reading of,
and follow ups to, his.
>> [snip]
>> term% uname -a
>> OpenBSD rv64.local 7.9 GENERIC.MP#5 riscv64
>> term% dmesg | grep 16550
>> com0 at simplebus0: dw16550
>> term%
>
>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 know both Motorola and Zilog
>>> produced stand-alone UART chips, and I know Motorola (then Freescale,
>>> now part of NXP) have made a countless number of processors and
>>> microcontrollers with built-in UARTs that are not 16550 compatible.
>>
>> I don't know what the latter has to do with the former, or the
>> larger discussion. You seem to be discussing something that I
>> never said or implied.
>
>(As a general point, not everything people write is an immediate direct
>response to what someone else wrote - nor is it necessarily disputing
>what they wrote. People add extra information, anecdotes,
>clarifications, questions, and digressions. Several times you have said
>my comments were irrelevant, or denied saying or implying the point you
>think I am disputing. My posts are not a series of attacks on what I
>imagine you said. While it is entirely possible that I misunderstand or
>misread something someone says, and respond to that misunderstood point,
>usually if I write something that does not appear to be a direct
>response to a previous point, it is not a direct response to /any/ point
>- real or imagined. Conversations would quickly get boring if they
>never wander a little from previous points.)
Ok, fair points. I conress I find it somewhat difficult to
follow your exact line of discussion becuase it jumps between
seemingly-unrelated points.
>> [snip]
>> No, not really.
>>
>> Perhaps in the uctlr world that is true, but in that world
>> workloads tend to be fixed and predictible; in the world of
>> large systems, things are far more dynamic. Interrupts can, and
>> do, get lost; FIFOs get full; data can get corrupted; flow
>> control and synchronization between endpoints in a
>> communications protocol is useful.
>
>I do appreciate that on "big" systems things are more dynamic and
>unpredictable compared to many microcontroller systems. And yes, things
>can get lost or corrupted - that is true in communications in
>microcontroller systems too. As the Mythbuster's tee-shirt says,
>failure is always an option. You almost always want some kind of
>control, synchronisation, error checking, and retry mechanism. You
>usually have several of these, at different levels of the system from
>the hardware, through low-level drivers or interfaces, and up to
>high-level control.
>
>But yes, really - you /can/ handle thousands of interrupts per second on
>Linux systems if you want to.
Of course. But eventually, if you saturate the system enough,
something has to give. That's when data in flight can get lost.
>I've happily passed packets through Linux
>systems at high speeds, without failures. My current system has a
>microcontroller connected to a Linux SOM. My focus is on the
>microcontroller software, but amongst other things I have Python code on
>the PC sending UDP telegrams via the SOM (with a USB to Ethernet dongle)
>to the microcontroller. I run about 2,000+ transactions a second,
>without failures - where a transaction means the Linux SOM getting a
>packet in, routing it out to the microcontroller, getting a reply back,
>and routing that towards the PC. In the background, the SOM is
>continuously bzipping and bunzipping a big file, just to have it working
>on something. How many interrupts per second do you think that is?
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.
>Of course there are other patterns of interrupts that are more stressful
>than the ones I have there. But then, I am running just a single core
>SoC here, and the speed bottlenecks are mostly in the Python test code.
>And I have done nothing towards improving the latencies or anything else
>- this is a bog standard Debian ARM installation.
>
>> Perhaps that doesn't matter for your use cases, and you've never
>> needed it; but don't extrapolate to other use cases you have no
>> experience with.
>
>I have worked on systems where we have locked interrupts and programs to
>particular cores (of a 4 core SoC) to minimise jitter, with real-time
>extensions in the kernel. Admittedly there were not many packets
>handled in and out every millisecond, but the millisecond tick needed to
>be within about 1% jitter.
So you're optimizing for latency, not throughput. Ok.
>Of course there are vast combinations of hardware and requirements that
>I have /not/ worked with. But I have seen enough to know that you can
>do a great deal with Linux even without careful tuning - and even more
>with tuning. Thousands of interrupts per second is peanuts to a modern
>Linux system - big or small. Tens or hundreds of thousands of
>interrupts per second - then you are pushing it, and will want to
>re-think things a bit. (My understanding is that for very fast network
>cards on big systems, you dedicate a core to the task and using polling
>rather than interrupts to avoid context switches. But that is
>definitely outside my experience.)
>
>And certainly it is harder to do high frequency operations on Linux, and
>on microprocessors, than on microcontrollers. Context switches are
>massively more demanding, and you have little details like "security"
>that are a different world on a multi-user system than on a
>microcontroller. On one 500 MHz microcontroller I did some testing with
>an RTOS doing round-robin context switches at 1 MHz, taking about 10% of
>the processor capacity. I don't think you'd get far with a jiffy rate
>of 1 MHz on any Linux system, big or small. And I have also had a
>system where I did bit-banging of a 115200 baud UART with 4x
>oversampling. That's 460,800 timer interrupts per second - on a
>microcontroller running with a 18.432 MHz clock. 40 clocks per
>interrupt, and time to spare for the rest of the application.
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?
>>> Throughput is usually not an issue, but accurate timing is hard to
>>> achieve. It is not without reason that many embedded systems have a
>>> Linux SOM for networking and high-level decisions, and microcontrollers
>>> for the fast reaction and deterministic control stuff. (Many SoC's
>>> targetting industrial embedded Linux have microcontrollers in the SoC
>>> itself.) And it is also fair to say that if you want to have demanding
>>> serial port usage on a general-purpose OS, you want a decent, modern
>>> UART rather than an old-fashioned 16550.
>>
>> Again, you haven't specified what's "old-fashioned" about it, or
>> what makes alternatives superior; on modern systems, this is not
>> your father's 8250. Modern SoCs support DMA and MMIO accesses
>> for UARTs and speeds up to 3MBAUD or more, even if the registers
>> are the same 'ol 16550 registers since the 486 era (with some
>> extensions, of course).
>
>Well, to be fair it depends on what you want to do with the UART - and
>my bias is towards industrial systems. I guess the biggest want an
>RS-485 driver line - when doing faster communication, that is an
>essential feature. (While I have never had the dubious pleasure of
>implementing Profibus DP, it runs at 12 Mbps on RS-485.) I like better
>control of FIFOs and triggers, for both interrupts and DMA. I have
>occasionally had need of 9 bit characters. Sending break characters is
>important in some protocols, like LIN. Automatic detection of frame
>start characters can significantly reduce the load on the rest of the
>system. Many modern full-featured UARTs have additional features like
>swapping pin polarity (great for when people wire up RS-485 buses
>incorrectly) or Rx/Tx pins, IrDA support, Smartcard support, Manchester
>encoding and other things that could reasonably also be done in hardware
>outside the UART.
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.
>And of course there are different balances that can be achieved between
>features and power usage, and die space.
>
>Usually most UARTs are usable for most purposes, but some are definitely
>more convenient and better suited than others for offloading work.
>
>> Beyond that, you're correct that many modern SoCs have embedded
>> microcontrollers capable of real-time response; yay. Using one
>> just to avoid flow control over a serial protocol seems like
>> going to extremes to avoid a simple thing. As I mentioned, the
>> DW part even does CTS/RTS HW flow control automatically, without
>> software intervention.
>
>I would not pick a UART to /avoid/ hardware flow control support - but
>it is not a feature I have seen as useful since the days of dial-up
>modems. XON/XOFF style of software flow control is completely absent
>from anything I have been involved in. Of course there this software
>synchronisation and control, but it is at a higher level.
Correction: it's not a feature that is usefulf or _your use
cases_. Again, I urge caution in making assumptions about other
use cases based on that.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-27 19:46 +0200 |
| Message-ID | <111p2a1$34arg$1@dont-email.me> |
| In reply to | #400255 |
On 27/06/2026 03:52, 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. OK. Yes, I agree that 16550 (or similar) UARTs will be fine for the tasks you'd expect on such systems. > > I get that you don't think this series is suitable for embedded > use, and that's fine: don't use it if you you don't want to in > microcontroller applications. But you're using your experience > in that domain to extrapolate and make a value judgement that > doesn't follow in a different domain. > My experience also covers embedded Linux systems, but those have all been ARM (I've worked briefly with Coldfire, AVR32 and MIPs embedded Linux systems, but only very superficially, long ago). We have a customer that used some embedded Intel devices, and I have a few routers and firewalls lying around with x86 cores - but I have no reason to look at the UARTs on such systems. > > The DW APB from Synopsis is common and I mentioned it at least > twice before Scott did, but you don't seem at all familiar with > it; it's pretty common. > No, I have not used it or read anything about it. >>> [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. > 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! >> 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. > Ok, fair points. I conress I find it somewhat difficult to > follow your exact line of discussion becuase it jumps between > seemingly-unrelated points. That in turn is a fair point. And we do seem to have lost C far behind. I'm trying to snip a bit, and not wander too far. >> But yes, really - you /can/ handle thousands of interrupts per second on >> Linux systems if you want to. > > Of course. But eventually, if you saturate the system enough, > something has to give. That's when data in flight can get lost. > Yes, that's an undeniable truth. >> I've happily passed packets through Linux >> systems at high speeds, without failures. My current system has a >> microcontroller connected to a Linux SOM. My focus is on the >> microcontroller software, but amongst other things I have Python code on >> the PC sending UDP telegrams via the SOM (with a USB to Ethernet dongle) >> to the microcontroller. I run about 2,000+ transactions a second, >> without failures - where a transaction means the Linux SOM getting a >> packet in, routing it out to the microcontroller, getting a reply back, >> and routing that towards the PC. In the background, the SOM is >> continuously bzipping and bunzipping a big file, just to have it working >> on something. How many interrupts per second do you think that is? > > 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. >> Of course there are other patterns of interrupts that are more stressful >> than the ones I have there. But then, I am running just a single core >> SoC here, and the speed bottlenecks are mostly in the Python test code. >> And I have done nothing towards improving the latencies or anything else >> - this is a bog standard Debian ARM installation. >> >>> Perhaps that doesn't matter for your use cases, and you've never >>> needed it; but don't extrapolate to other use cases you have no >>> experience with. >> >> I have worked on systems where we have locked interrupts and programs to >> particular cores (of a 4 core SoC) to minimise jitter, with real-time >> extensions in the kernel. Admittedly there were not many packets >> handled in and out every millisecond, but the millisecond tick needed to >> be within about 1% jitter. > > So you're optimizing for latency, not throughput. Ok. That particular case was optimising for low jitter in the latency rather than absolute latency, though we wanted low absolute latency too. Throughput was not high, and was - most of the time - very stable. > >> Of course there are vast combinations of hardware and requirements that >> I have /not/ worked with. But I have seen enough to know that you can >> do a great deal with Linux even without careful tuning - and even more >> with tuning. Thousands of interrupts per second is peanuts to a modern >> Linux system - big or small. Tens or hundreds of thousands of >> interrupts per second - then you are pushing it, and will want to >> re-think things a bit. (My understanding is that for very fast network >> cards on big systems, you dedicate a core to the task and using polling >> rather than interrupts to avoid context switches. But that is >> definitely outside my experience.) >> >> And certainly it is harder to do high frequency operations on Linux, and >> on microprocessors, than on microcontrollers. Context switches are >> massively more demanding, and you have little details like "security" >> that are a different world on a multi-user system than on a >> microcontroller. On one 500 MHz microcontroller I did some testing with >> an RTOS doing round-robin context switches at 1 MHz, taking about 10% of >> the processor capacity. I don't think you'd get far with a jiffy rate >> of 1 MHz on any Linux system, big or small. And I have also had a >> system where I did bit-banging of a 115200 baud UART with 4x >> oversampling. That's 460,800 timer interrupts per second - on a >> microcontroller running with a 18.432 MHz clock. 40 clocks per >> interrupt, and time to spare for the rest of the application. > > 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 :-) ) > > 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. Then I withdraw all my objections! > >> And of course there are different balances that can be achieved between >> features and power usage, and die space. >> >> Usually most UARTs are usable for most purposes, but some are definitely >> more convenient and better suited than others for offloading work. >> >>> Beyond that, you're correct that many modern SoCs have embedded >>> microcontrollers capable of real-time response; yay. Using one >>> just to avoid flow control over a serial protocol seems like >>> going to extremes to avoid a simple thing. As I mentioned, the >>> DW part even does CTS/RTS HW flow control automatically, without >>> software intervention. >> >> I would not pick a UART to /avoid/ hardware flow control support - but >> it is not a feature I have seen as useful since the days of dial-up >> modems. XON/XOFF style of software flow control is completely absent >>from anything I have been involved in. Of course there this software >> synchronisation and control, but it is at a higher level. > > Correction: it's not a feature that is usefulf or _your use > cases_. Again, I urge caution in making assumptions about other > use cases based on that. > When I wrote "not a feature I have seen as useful", I was being subjective - it is not a statement or assumption about things that I have /not/ seen. Maybe other people do still find that kind of flow control useful, even in modern usage - I am not assuming it does not happen, merely saying that it is not something I have needed myself or seen used (in situations where I know the details) for a very long time. But given that I have made unwarranted extrapolations before, I can see how you might think I was doing so again.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web