No, it's not 1 April.
I was researching panic_blink() for someone who needed a little help,
when I noticed the comment above the function definition, not being the
kind to step down from a challenge (unless it's just really hard), I
decided to write morse code output code.
The option panicblink= has been hijacked to be a simple bitfield:
bit 1 : blink LEDs
bit 2 : sound the PC speaker.
the blinking option depends only on pc_keyb.c. the pcspeaker option
depends on kb_mksound() actually doing something. At the moment, both of
these mean i386. The call to panic_blink() in panic() is still guarded
by an i386 #ifdef, anyway, for the moment. The default is to blink only,
because I figured the beeps would be too annoying. Opinions?
It recognizes letters, and digits, and treats everything else as a
space. The timings are tunable by #defines. It repeats the message
indefinitely. And it should only bloat the kernel by a few hundred
bytes, although if someone wants to wrap this in its own config option,
well, that's good too.
Anyway, here's the patch. It's against linux-2.4.19-rc1-ac1+preempt, but
I suspect it applies against all recent -ac. If 2.5 has this, it will
hopefully apply with some fuzz against that, too. I don't have a tree.
(modem. ecch.)
diff -u -r -d linux.old/drivers/char/pc_keyb.c linux/drivers/char/pc_keyb.c
--- linux.old/drivers/char/pc_keyb.c Fri Jul 19 00:59:04 2002
+++ linux/drivers/char/pc_keyb.c Fri Jul 19 01:00:34 2002
@@ -1244,37 +1244,126 @@
#endif /* CONFIG_PSMOUSE */
-static int blink_frequency = HZ/2;
+static int blink_setting = 1;
/* Tell the user who may be running in X and not see the console that we have
panic'ed. This is to distingush panics from "real" lockups.
Could in theory send the panic message as morse, but that is left as an
- exercise for the reader. */
-void panic_blink(void)
-{
- static unsigned long last_jiffie;
- static char led;
- /* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is
- different. */
- if (!blink_frequency)
- return;
- if (jiffies - last_jiffie > blink_frequency) {
- led ^= 0x01 | 0x04;
+ exercise for the reader.
+ And now it's done! LED and speaker morse code by Andrew Rodland, 18-19 Jul 2002
+*/
+
+static const char * morse[] = {
+ ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
+ "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
+ "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
+ "-.--", "--..", /* Y-Z */
+ "-----", ".----", "..---", "...--", "....-", /* 0-4 */
+ ".....", "-....", "--...", "---..", "----." /* 5-9 */
+};
+
+#define DITLEN (HZ / 4)
+#define DAHLEN 3 * DITLEN
+#define FREQ 1000
+
+static __inline__ void do_blink (int led) {
+
+ if (! blink_setting & 0x01)
+ return;
+
+ led = led ? (0x01 | 0x04) : 0x00;
+
while (kbd_read_status() & KBD_STAT_IBF) mdelay(1);
kbd_write_output(KBD_CMD_SET_LEDS);
mdelay(1);
while (kbd_read_status() & KBD_STAT_IBF) mdelay(1);
mdelay(1);
kbd_write_output(led);
- last_jiffie = jiffies;
+}
+
+void panic_blink(char * buf)
+{
+ static unsigned long next_jiffie = 0;
+ static char * bufpos = 0;
+ static char * morsepos = 0;
+ static char state;
+
+ if (!blink_setting)
+ return;
+
+ if (!buf)
+ buf="ABC";
+
+
+ if (jiffies > next_jiffie || !bufpos) { //messy. fix.
+
+ if (state) {
+ do_blink(0);
+ state = 0;
+ next_jiffie = jiffies + DITLEN;
+ return;
+ }
+
+ if (!bufpos) {
+ bufpos = (char *)buf;
+ return;
+ }
+
+
+ if (!morsepos || !*morsepos) {
+
+ if (!*bufpos) { /*Repeat the message */
+ bufpos = (char *)buf;
+ morsepos = 0;
+ next_jiffie = jiffies + 3 * DAHLEN;
+ return;
+ }
+ next_jiffie = jiffies + DITLEN;
+
+ if (*bufpos >= 'A' && *bufpos <= 'Z') {
+ morsepos = (char *)morse[*bufpos - 'A'];
+ } else if (*bufpos >= 'a' && *bufpos <= 'z') {
+ morsepos = (char *)morse[*bufpos - 'a'];
+ } else if (*bufpos >= '0' && *bufpos <= '9') {
+ morsepos = (char *)morse[*bufpos - '0' + 26];
+ } else {
+ next_jiffie += 2*DITLEN;
+ }
+ bufpos ++;
+
+ return;
+ }
+
+ if (*morsepos == '.') {
+ if (blink_setting & 0x02)
+ kd_mksound(FREQ, DITLEN);
+ next_jiffie = jiffies + DITLEN;
+ do_blink(1);
+ state = 1;
+ morsepos++;
+ return;
+ } else if (*morsepos == '-') {
+ if (blink_setting & 0x02)
+ kd_mksound(FREQ, DAHLEN);
+ next_jiffie = jiffies + DAHLEN;
+ do_blink(1);
+ state = 1;
+ morsepos++;
+ return;
+ }
+
+ /*impossible*/
+ morsepos = 0;
+
}
+
}
static int __init panicblink_setup(char *str)
{
int par;
if (get_option(&str,&par))
- blink_frequency = par*(1000/HZ);
+ blink_setting = par;
return 1;
}
diff -u -r -d linux.old/kernel/panic.c linux/kernel/panic.c
--- linux.old/kernel/panic.c Fri Jul 19 00:59:04 2002
+++ linux/kernel/panic.c Thu Jul 18 21:45:45 2002
@@ -97,8 +97,8 @@
sti();
for(;;) {
#if defined(__i386__) && defined(CONFIG_VT)
- extern void panic_blink(void);
- panic_blink();
+ extern void panic_blink(char * buf);
+ panic_blink(buf);
#endif
CHECK_EMERGENCY_SYNC
}
On Fri, Jul 19, 2002 at 01:13:00AM -0400, Andrew Rodland wrote:
> No, it's not 1 April.
> I was researching panic_blink() for someone who needed a little help,
> when I noticed the comment above the function definition, not being the
> kind to step down from a challenge (unless it's just really hard), I
> decided to write morse code output code.
This is far more amusing than any of the April 1st Linus impersonations.
Good show!
Cheers,
Bill
Andrew Rodland <[email protected]> writes:
> I was researching panic_blink() for someone who needed a little help,
> when I noticed the comment above the function definition, not being the
> kind to step down from a challenge (unless it's just really hard), I
> decided to write morse code output code.
Great. Congratulations (having written the original comment).
I would encode the morse strings as bits in a integer instead of strings
though (perhaps with some macros to make it readable), that should shrink
it quite a bit.
>
> The option panicblink= has been hijacked to be a simple bitfield:
> bit 1 : blink LEDs
> bit 2 : sound the PC speaker.
>
> the blinking option depends only on pc_keyb.c. the pcspeaker option
> depends on kb_mksound() actually doing something. At the moment, both of
> these mean i386. The call to panic_blink() in panic() is still guarded
> by an i386 #ifdef, anyway, for the moment. The default is to blink only,
> because I figured the beeps would be too annoying. Opinions?
I would consider beeps annoying, but then I usually just cut the beeper
line on any new PC I install so personally I do not care. Still imagine
what a machine room that overheated and caused several boxes to panic
would sound like...
-Andi
On Fri, Jul 19, 2002 at 01:13:00AM -0400, Andrew Rodland wrote:
> I was researching panic_blink() for someone who needed a little help,
> when I noticed the comment above the function definition, not being the
> kind to step down from a challenge (unless it's just really hard), I
> decided to write morse code output code.
nice idea :)
> diff -u -r -d linux.old/drivers/char/pc_keyb.c linux/drivers/char/pc_keyb.c
> --- linux.old/drivers/char/pc_keyb.c Fri Jul 19 00:59:04 2002
> +++ linux/drivers/char/pc_keyb.c Fri Jul 19 01:00:34 2002
> @@ -1244,37 +1244,126 @@
> #endif /* CONFIG_PSMOUSE */
[...]
> +static const char * morse[] = {
> + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> + "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
This should read:
"..", ".---", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
i.e. there's a dot too much :)
> + "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> + "-.--", "--..", /* Y-Z */
> + "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> + ".....", "-....", "--...", "---..", "----." /* 5-9 */
> +};
73, Thorsten
--
| Thorsten Kranzkowski Internet: [email protected] |
| Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [email protected] [44.130.8.19] |
On Fri, 19 Jul 2002 16:36:55 +0000
Thorsten Kranzkowski <[email protected]> wrote:
> On Fri, Jul 19, 2002 at 01:13:00AM -0400, Andrew Rodland wrote:
> > I was researching panic_blink() for someone who needed a little
> > help, when I noticed the comment above the function definition, not
> > being the kind to step down from a challenge (unless it's just
> > really hard), I decided to write morse code output code.
>
> nice idea :)
>
> > diff -u -r -d linux.old/drivers/char/pc_keyb.c
> > linux/drivers/char/pc_keyb.c--- linux.old/drivers/char/pc_keyb.c Fri Jul 19 00:59:04 2002
> > +++ linux/drivers/char/pc_keyb.c Fri Jul 19 01:00:34 2002
> > @@ -1244,37 +1244,126 @@
> > #endif /* CONFIG_PSMOUSE */
>
> [...]
>
> > +static const char * morse[] = {
> > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H
> > */+ "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P
> > */
>
> This should read:
>
> "..", ".---", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P
> */
>
> i.e. there's a dot too much :)
>
Thank you. Fixed locally.
Since you seem to be something of a morse-wiz (the only letters I know
by heart are 'S', 'O', and 'S'), could you either make corrections on
my timings (ditlen, dahlen, inter-letter space, inter-word space), or
tell me that they're good?
--Andrew
P.S. Yes, in case anyone is wondering, I did create a module that does
nothing but generate a user-supplied panic. :)
Andrew Rodland wrote:
[snip]
> --Andrew
>
> P.S. Yes, in case anyone is wondering, I did create a module that does
> nothing but generate a user-supplied panic. :)
*ROTFL* Actually, I can see that being useful for testing... I fear
you have tweaked my curiosity to see that particular implementation. :)
Oh, the fun of getting someone to feed that patch to Linus... *grin*
*giggle*
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
On Fri, 19 Jul 2002 12:27:51 -0500
Eli Carter <[email protected]> wrote:
> Andrew Rodland wrote:
> [snip]
> > --Andrew
> >
> > P.S. Yes, in case anyone is wondering, I did create a module that
> > does nothing but generate a user-supplied panic. :)
>
> *ROTFL* Actually, I can see that being useful for testing... I fear
> you have tweaked my curiosity to see that particular implementation.
> :)
>
Actually, it was pretty simple. It was also my first module ever.
I had a lot of fun writing all of this stuff, but people keep
indicating that maybe some of it could actually be useful. If that's
the case, so much the better.
panictest.c follows.
--cut--
#define __KERNEL__
#define MODULE
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
static char *string = "SOS SOS SOS";
int __init panic_init(void) {
panic(string);
}
module_init(panic_init);
MODULE_LICENSE("GPL");
MODULE_PARM(string, "s");
MODULE_PARM_DESC(string, "The string to panic with.");
Thanks a million to the unnamed linux<AT>horizon.com for some great
suggestions/info. v2 of the morse-panic patch features better
punctuation handling, proper morse-like timings, and something like 1/5
the static data requirement, thanks to the varicode algo that I
couldn't come up with myself. :)
Patch follows.
diff -u -r linux.old/drivers/char/pc_keyb.c linux.new/drivers/char/pc_keyb.c
--- linux.old/drivers/char/pc_keyb.c Fri Jul 19 18:56:36 2002
+++ linux.new/drivers/char/pc_keyb.c Fri Jul 19 18:54:17 2002
@@ -1244,29 +1244,131 @@
#endif /* CONFIG_PSMOUSE */
-static int blink_frequency = HZ/2;
+static int blink_setting = 1;
/* Tell the user who may be running in X and not see the console that we have
panic'ed. This is to distingush panics from "real" lockups.
Could in theory send the panic message as morse, but that is left as an
- exercise for the reader. */
-void panic_blink(void)
-{
- static unsigned long last_jiffie;
- static char led;
- /* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is
- different. */
- if (!blink_frequency)
- return;
- if (jiffies - last_jiffie > blink_frequency) {
- led ^= 0x01 | 0x04;
+ exercise for the reader.
+ And now it's done! LED and speaker morse code by Andrew Rodland
+ <[email protected]>, with improvements based on suggestions from
+ [email protected].
+*/
+
+static const char morsetable[] = {
+ /* .- -... -.-. -.. . ..-. --. .... .. */
+ 006, 021, 025, 011, 002, 024, 013, 020, 004, /* A-I */
+ /* .--- -.- .-.. -- -.- --- .--. --.- .-. */
+ 036, 015, 022, 007, 005, 017, 026, 033, 012, /* J-R */
+ /* ... - ..- ...- .-- -..- -.-- --.. */
+ 010, 003, 014, 030, 016, 031, 035, 023, /* S-Z */
+
+ 077, 076, 074, 070, 060, 040, 041, 043, 047, 057 /* 0-9 */
+};
+
+
+#define DITLEN (HZ / 5)
+#define DAHLEN 3 * DITLEN
+#define SPACELEN 7 * DITLEN
+
+#define FREQ 844
+
+static __inline__ void do_blink (int led) {
+
+ if (! blink_setting & 0x01)
+ return;
+
+ led = led ? (0x01 | 0x04) : 0x00;
+
while (kbd_read_status() & KBD_STAT_IBF) mdelay(1);
kbd_write_output(KBD_CMD_SET_LEDS);
mdelay(1);
while (kbd_read_status() & KBD_STAT_IBF) mdelay(1);
mdelay(1);
kbd_write_output(led);
- last_jiffie = jiffies;
+}
+
+void panic_blink(char * buf)
+{
+ static unsigned long next_jiffie = 0;
+ static char * bufpos = 0;
+ static char morse = 0;
+ static char state;
+
+ if (!blink_setting)
+ return;
+
+ if (!buf)
+ buf="Panic lost?";
+
+
+ if (jiffies >= next_jiffie || !bufpos) { //messy. fix.
+
+ if (state) {
+ do_blink(0);
+ state = 0;
+ next_jiffie = jiffies + DITLEN;
+ return;
+ }
+
+ if (!bufpos) {
+ bufpos = (char *)buf;
+ return;
+ }
+
+
+ if (morse <=1 ) { /* Many thanks for the clever scheme, horizon! */
+ if (!*bufpos) { /*Repeat the message */
+ bufpos = (char *)buf;
+ next_jiffie = jiffies + 3 * DAHLEN;
+ return;
+ }
+
+ next_jiffie = jiffies + 3*DITLEN;
+
+ if (*bufpos >= 'A' && *bufpos <= 'Z') {
+ morse = morsetable[*bufpos - 'A'];
+ } else if (*bufpos >= 'a' && *bufpos <= 'z') {
+ morse = morsetable[*bufpos - 'a'];
+ } else if (*bufpos >= '0' && *bufpos <= '9') {
+ morse = morsetable[*bufpos - '0' + 26];
+ } else {
+ switch (*bufpos) {
+ case '/': morse = 0051; break; /* -..-. */
+ case '=': morse = 0061; break; /* -...- */
+ case '.': morse = 0152; break; /* .-.-.- */
+ case '?': morse = 0114; break; /* ..--.. */
+ case ',': morse = 0163; break; /* --..-- */
+ case '-': morse = 0141; break; /* -....- */
+ case '\'':morse = 0136; break; /* .----. */
+ case '"': morse = 0122; break; /* .-..-. */
+ case ':': morse = 0107; break; /* ---... */
+ default : /* Space */
+ next_jiffie += 4*DITLEN; /*For a total of 7*/
+ }
+ }
+ bufpos ++;
+ return;
+ }
+
+ if (morse & 001) {
+ if (blink_setting & 0x02)
+ kd_mksound(FREQ, DAHLEN);
+ next_jiffie = jiffies + DAHLEN;
+ do_blink(1);
+ state = 1;
+ morse >>= 1;
+ return;
+ } else {
+ if (blink_setting & 0x02)
+ kd_mksound(FREQ, DITLEN);
+ next_jiffie = jiffies + DITLEN;
+ do_blink(1);
+ state = 1;
+ morse >>= 1;
+ return;
+ }
+ /*impossible*/
}
}
@@ -1274,7 +1376,7 @@
{
int par;
if (get_option(&str,&par))
- blink_frequency = par*(1000/HZ);
+ blink_setting = par;
return 1;
}
diff -u -r linux.old/kernel/panic.c linux.new/kernel/panic.c
--- linux.old/kernel/panic.c Fri Jul 19 18:56:36 2002
+++ linux.new/kernel/panic.c Thu Jul 18 21:45:45 2002
@@ -97,8 +97,8 @@
sti();
for(;;) {
#if defined(__i386__) && defined(CONFIG_VT)
- extern void panic_blink(void);
- panic_blink();
+ extern void panic_blink(char * buf);
+ panic_blink(buf);
#endif
CHECK_EMERGENCY_SYNC
}
> +static const char * morse[] = {
> + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> + "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> + "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> + "-.--", "--..", /* Y-Z */
> + "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> + ".....", "-....", "--...", "---..", "----." /* 5-9 */
How about using bitmasks here. Say top five bits being the length, lower
5 bits being 1 for dash 0 for dit ?
But very nice
On Fri, 19 Jul 2002 20:35:15 -0400 (EDT)
Alan Cox <[email protected]> wrote:
> > +static const char * morse[] = {
> > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H
> > */+ "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P
> > */+ "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X
> > */+ "-.--", "--..", /* Y-Z
> > */+ "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> > + ".....", "-....", "--...", "---..", "----." /* 5-9 */
>
> How about using bitmasks here. Say top five bits being the length,
> lower 5 bits being 1 for dash 0 for dit ?
>
v2 uses an algorithm suggested to me in private that allows you to fit
7 bits of morse into 8 bits. Very clever method.
>
> But very nice
>
Thanks. :)
Hi,
On Fri, 19 Jul 2002, Alan Cox wrote:
> How about using bitmasks here. Say top five bits being the length, lower
> 5 bits being 1 for dash 0 for dit ?
Just have a look at his latest solution.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Fri, Jul 19, 2002 at 12:38:24PM +0200, you [Andi Kleen] wrote:
> Andrew Rodland <[email protected]> writes:
>
> > I was researching panic_blink() for someone who needed a little help,
> > when I noticed the comment above the function definition, not being the
> > kind to step down from a challenge (unless it's just really hard), I
> > decided to write morse code output code.
>
> I would consider beeps annoying, but then I usually just cut the beeper
> line on any new PC I install so personally I do not care. Still imagine
> what a machine room that overheated and caused several boxes to panic
> would sound like...
I'm just waiting for Andrew to come up with a proper morse code network
layer, so that the machines in the room can communicate (provided they have
a mic each)... Now combine that with Ingo's network console and...
-- v --
[email protected]
Nice joke. Unfortunately, this code is too useful to ignore. I distinctly
remember finding myself in the position of having completed the firmware of
an embedded device without properly recording the correspondence of led blink
patterns to error codes, the result being that if the firmware had ever failed
(luckily it never did) nobody would have been quite sure why. How much more
useful, satisfying and stylish to have encoded the failure messages in morse.
On Saturday 20 July 2002 01:02, Andrew Rodland wrote:
> Thanks a million to the unnamed linux<AT>horizon.com for some great
> suggestions/info. v2 of the morse-panic patch features better
> punctuation handling, proper morse-like timings, and something like 1/5
> the static data requirement, thanks to the varicode algo that I
> couldn't come up with myself. :)
Indeed, that one had me scratching my head, even with the code in front of
me. Let me describe the encoding method for the benefit of anybody not
energetic or foolish enough to puzzle it out for themselves:
- The sequence is encoded from low bit to high, zero=dit, one=dah
- The sequence always terminates with a one=dah, which is dropped,
followed by an infinite string of zeros.
The infinite string of zeros is shifted in from the top of the byte, hence
the terminating condition morse <= 1, which prudently covers the impossible
case of morse == 0.
This deserves a comment.
Note that there is a bug waiting to bite: you need to declare morse as
unsigned char, otherwise you will be unable to make good on your claim that
up to 7 morse bits can be encoded.
--
Daniel
Hi,
On Sat, 20 Jul 2002, Daniel Phillips wrote:
> Unfortunately, this code is too useful to ignore.
I think it's also a nice-to-have for 2.5.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Sat, 20 Jul 2002, Ville Herva wrote:
[...]
> I'm just waiting for Andrew to come up with a proper morse code network
> layer, so that the machines in the room can communicate (provided they have
> a mic each)... Now combine that with Ingo's network console and...
You mean like an implementation of RFC 1926: "An Experimental
Encapsulation of IP Datagrams on Top of ATM[1]"? ;-)
Neale.
[1] ATM: in this case it's "Acoustical Transmission Media"
Hi,
On Sat, 20 Jul 2002, Neale Banks wrote:
> You mean like an implementation of RFC 1926: "An Experimental
> Encapsulation of IP Datagrams on Top of ATM[1]"? ;-)
The author assumes that the users take whatever precautions that are
necessary before attempting to use this protocol in any crowded area.
Same thing to add here...
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Sat, Jul 20, 2002 at 05:19:13AM -0600, you [Thunder from the hill] wrote:
> Hi,
>
> On Sat, 20 Jul 2002, Daniel Phillips wrote:
> > Unfortunately, this code is too useful to ignore.
>
> I think it's also a nice-to-have for 2.5.
Okay, maybe it's just me being too lazy and ignorant to teach myself morse
code, but I'd advocate ksmgdump by Willy Tarreau instead
(http://miaif.lip6.fr/~tarreau/kmsgdump/) - it lets you save the oops to a
floppy or print it. ;)
And it does beep and blink the leds which seems a minimum requirement for a
basic bell-and-a-whistle feature these days...
-- v --
[email protected]
On Saturday 20 July 2002 15:22, Ville Herva wrote:
> On Sat, Jul 20, 2002 at 05:19:13AM -0600, you [Thunder from the hill] wrote:
> > Hi,
> >
> > On Sat, 20 Jul 2002, Daniel Phillips wrote:
> > > Unfortunately, this code is too useful to ignore.
> >
> > I think it's also a nice-to-have for 2.5.
>
> Okay, maybe it's just me being too lazy and ignorant to teach myself morse
> code...
Then teach it to a script, call it "unmorse" ;-)
echo dit dit dit dah dah dah dit dit dit | unmorse
--
Daniel
> > > Hi,
> > >
> > > On Sat, 20 Jul 2002, Daniel Phillips wrote:
> > > > Unfortunately, this code is too useful to ignore.
> > >
> > > I think it's also a nice-to-have for 2.5.
> >
> > Okay, maybe it's just me being too lazy and ignorant to teach myself morse
> > code...
>
> Then teach it to a script, call it "unmorse" ;-)
>
> echo dit dit dit dah dah dah dit dit dit | unmorse
Try this on for size:
/* dorssel.c, 1998 IOCCC entry
* Frans van Dorsselaer <[email protected]>
*/
#include<stdio.h>
#include<string.h>
main()
{
char*O,l[999]="'`acgo\177~|xp .-\0R^8)NJ6%K4O+A2M(*0ID57$3G1FBL";
while(O=fgets(l+45,954,stdin)){
*l=O[strlen(O)[O-1]=0,strspn(O,l+11)];
while(*O)switch((*l&&isalnum(*O))-!*l){
case-1:{char*I=(O+=strspn(O,l+12)+1)-2,O=34;
while(*I&3&&(O=(O-16<<1)+*I---'-')<80);
putchar(O&93?*I&8||!(I=memchr(l,O,44))?'?':I-l+47:32);
break;
case 1: ;}*l=(*O&31)[l-15+(*O>61)*32];
while(putchar(45+*l%2),(*l=*l+32>>1)>35);
case 0: putchar((++O,32));}
putchar(10);}
}
On Saturday 20 July 2002 16:55, Tomas Szepe wrote:
> Try this on for size:
Gosh, that's hard to read with all those indents...
While I realize how painful it would be to ignore the fact that '.' and '-'
are adjacent ascii codes, actually '_' makes it look more authentic.
By the way, you are demented ;-)
--
Daniel
.... ..
On Sat, 20 Jul 2002, Ville Herva wrote:
> Okay, maybe it's just me being too lazy and ignorant to teach myself morse
> code
.. .-- --- ..- .-.. -.. .-.. --- ...- . .. -
.-.. .- - . .-.. -.-- .. - .. ... ... --- -- . ... .- -. . - .... ..
-. --. - --- -.. --- .-- .. - .... -.-- --- ..- .-. --- --- .--. ...
.-. . --. .- .-. -.. ...,
- .... ..- -. -.. . .-.
--
(..- ... . .... - - .--.://.-- .-- .-- . . -... -... . --- .-. --.
/ ..- -. --. . . -.- .. ..-. -.-- --- ..- -.-. .- -. -. --- - -.. .
-.-. --- -.. .)
------ -... . --. .. -. --. . . -.- -.-. --- -.. . -... .-.. --- -.-.
-.- ------
...- . .-. ... .. --- -. : ...-- . .---- ..---
--././--./.../.- - -.. - ... ++:-- .-? -.-.++$ ..- .-.. .- ...- ....
..++++$ .--.++$ .-..++++(+++++)$ . .-- -$
-. --- ---? -.-? .-- -- --- - -- ...-$ .--. ...+ .--. . - -.-- - .--.
--. .--.+ -+ .....+ -..-+ .-. - !- ...- -...++ -.. ..? !-.. --.
.++++ ....* .-. --- -.-- -
------ . -. -.. --. . . -.- -.-. --- -.. . -... .-.. --- -.-. -.-
------
Once more Mr. unnamed sent me some suggestions, and once more I've
merged [my own adaptation of] them in. Also, I took an attempt to make
it somewhat more platform-independent, and re-organize. The original
panic_blink was in pc_keyb.c, and was guarded by an #ifdef __i386__ .
v3 moves the generic code out of pc_keyb (and into panic.c). It should
be able to blink on anything that uses pc_keyb (i386, some ARM, and
some MIPS, apparently), and should be able to beep on anything that
defines kd_mksound to do something (currently only i386). Also the code
has been reorganized so as to be easier to read and follow, and there
are a few more punctuation characters.
Yes, I actually _am_ trying to turn this into something useful.
Now, I don't have a 2.5 tree, and probably wouldn't understand it if I
did, but I get a feeling that this won't be so incredibly easy to port,
thanks to having everything use the input layer. Or am I wrong?
--hobbs
Patch follows
diff -u -r linux.old/drivers/char/pc_keyb.c linux.new/drivers/char/pc_keyb.c
--- linux.old/drivers/char/pc_keyb.c Fri Jul 19 18:56:36 2002
+++ linux.new/drivers/char/pc_keyb.c Sat Jul 20 13:18:40 2002
@@ -1244,41 +1244,13 @@
#endif /* CONFIG_PSMOUSE */
-static int blink_frequency = HZ/2;
+void pckbd_blink (char led) {
+ led = led ? (0x01 | 0x04) : 0x00;
-/* Tell the user who may be running in X and not see the console that we have
- panic'ed. This is to distingush panics from "real" lockups.
- Could in theory send the panic message as morse, but that is left as an
- exercise for the reader. */
-void panic_blink(void)
-{
- static unsigned long last_jiffie;
- static char led;
- /* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is
- different. */
- if (!blink_frequency)
- return;
- if (jiffies - last_jiffie > blink_frequency) {
- led ^= 0x01 | 0x04;
while (kbd_read_status() & KBD_STAT_IBF) mdelay(1);
kbd_write_output(KBD_CMD_SET_LEDS);
mdelay(1);
while (kbd_read_status() & KBD_STAT_IBF) mdelay(1);
mdelay(1);
kbd_write_output(led);
- last_jiffie = jiffies;
- }
-}
-
-static int __init panicblink_setup(char *str)
-{
- int par;
- if (get_option(&str,&par))
- blink_frequency = par*(1000/HZ);
- return 1;
}
-
-/* panicblink=0 disables the blinking as it caused problems with some console
- switches. otherwise argument is ms of a blink period. */
-__setup("panicblink=", panicblink_setup);
-
diff -u -r linux.old/kernel/panic.c linux.new/kernel/panic.c
--- linux.old/kernel/panic.c Fri Jul 19 18:56:36 2002
+++ linux.new/kernel/panic.c Sat Jul 20 17:28:41 2002
@@ -16,6 +16,8 @@
#include <linux/init.h>
#include <linux/sysrq.h>
#include <linux/interrupt.h>
+#include <linux/vt_kern.h>
+#include <linux/pc_keyb.h>
asmlinkage void sys_sync(void); /* it's really int */
@@ -28,9 +30,132 @@
panic_timeout = simple_strtoul(str, NULL, 0);
return 1;
}
-
__setup("panic=", panic_setup);
+static int blink_setting = 1;
+
+/* Tell the user who may be running in X and not see the console that we have
+ panic'ed. This is to distingush panics from "real" lockups.
+ Could in theory send the panic message as morse, but that is left as an
+ exercise for the reader.
+ And now it's done! LED and speaker morse code by Andrew Rodland
+ <[email protected]>, with improvements based on suggestions from
+ [email protected].
+*/
+
+static const unsigned char morsetable[] = {
+ /* ! " # $ % & ' */
+ 0, 0122, 0, 0310, 0, 0, 0163,
+ /* ( ) * + , - . / */
+ 055, 0155, 0, 0, 0163, 0141, 0152, 0051,
+ /* 0-9 */
+ 077, 076, 074, 070, 060, 040, 041, 043, 047, 057,
+ /* : ; < = > ? @ */
+ 0107, 0125, 0, 0061, 0, 0114, 0,
+ /* A-I */
+ 006, 021, 025, 011, 002, 024, 013, 020, 004,
+ /* J-R */
+ 036, 015, 022, 007, 005, 017, 026, 033, 012,
+ /* S-Z */
+ 010, 003, 014, 030, 016, 031, 035, 023,
+ /* [ \ ] ^ */
+ 0, 0, 0, 0,
+ /* _ */
+ 0154
+
+};
+
+#define DITLEN (HZ / 5)
+#define DAHLEN 3 * DITLEN
+#define SPACELEN 7 * DITLEN
+
+#define FREQ 844
+
+
+#if (defined(__i386__) && defined(CONFIG_VT)) || defined(CONFIG_PC_KEYB)
+#define do_blink(x) pckbd_blink(x)
+#else
+#define do_blink(x) 0
+#endif
+
+void panic_blink(char * buf)
+{
+ static unsigned long next_jiffie = 0;
+ static char * bufpos = 0;
+ static unsigned char morse = 0;
+ static char state = 1;
+
+ if (!blink_setting)
+ return;
+
+ if (!buf)
+ buf="Panic lost?";
+
+
+ if (bufpos && time_after (next_jiffie, jiffies)) {
+ return; /* Waiting for something. */
+ }
+
+ if (state) { /* Coming off of a blink. */
+ if (blink_setting & 0x01)
+ do_blink(0);
+
+ state = 0;
+
+ if(morse > 1) { /* Not done yet, just a one-dit pause. */
+ next_jiffie = jiffies + DITLEN;
+ } else { /* Get a new char, and figure out how much space. */
+
+ if(!bufpos)
+ bufpos = (char *)buf; /* First time through */
+
+ if(!*bufpos) {
+ bufpos = (char *)buf; /* Repeating */
+ next_jiffie = jiffies + SPACELEN;
+ } else {
+ next_jiffie = jiffies + DAHLEN; /* Inter-letter space */
+ }
+
+ if (*bufpos >= '!' && *bufpos <= '_') {
+ morse = morsetable[*bufpos - '!'];
+ } else if (*bufpos >= 'a' && *bufpos <= 'z') {
+ morse = morsetable[*bufpos - 'a' + 'A' - '!'];
+ } else {
+ next_jiffie = jiffies + SPACELEN; /*Space -- For a total of 7*/
+ state = 1; /* And bring us back here when we're done */
+ }
+ bufpos ++;
+ }
+ } else { /* Starting a new blink. We have valid code in morse. */
+ int len;
+
+ len = (morse & 001) ? DAHLEN : DITLEN;
+
+ if (blink_setting & 0x02)
+ kd_mksound(FREQ, len);
+
+ next_jiffie = jiffies + len;
+
+ if (blink_setting & 0x01)
+ do_blink(1);
+ state = 1;
+ morse >>= 1;
+ }
+}
+
+static int __init panicblink_setup(char *str)
+{
+ int par;
+ if (get_option(&str,&par))
+ blink_setting = par;
+ return 1;
+}
+
+/* panicblink=0 disables the blinking as it caused problems with some console
+ switches. otherwise argument is ms of a blink period. */
+__setup("panicblink=", panicblink_setup);
+
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -96,10 +221,7 @@
#endif
sti();
for(;;) {
-#if defined(__i386__) && defined(CONFIG_VT)
- extern void panic_blink(void);
- panic_blink();
-#endif
+ panic_blink(buf);
CHECK_EMERGENCY_SYNC
}
}
On Sun, 21 Jul 2002 07:32, Andrew Rodland wrote:
> Yes, I actually _am_ trying to turn this into something useful.
> Now, I don't have a 2.5 tree, and probably wouldn't understand it if I
> did, but I get a feeling that this won't be so incredibly easy to port,
> thanks to having everything use the input layer. Or am I wrong?
While it will be non-trivial, it won't be hard either.
The advantage of the input layer is that it no longer matters what
type of keyboard is attached - you can just call input_event() and
turn on and off the LED. The input layer abstracts out the magic
values needed for any particular keyboard.
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Sun, Jul 21, 2002 at 06:49:55PM +1000, Brad Hards wrote:
> While it will be non-trivial, it won't be hard either.
> The advantage of the input layer is that it no longer matters what
> type of keyboard is attached - you can just call input_event() and
> turn on and off the LED. The input layer abstracts out the magic
> values needed for any particular keyboard.
Hmm. I thought the original idea for the "flash LEDs on panic" was
so you knew something had gone wrong early in the boot, at the kind
of places where you don't have a console initialised. If you don't
have the console initialised, you sure as hell don't have the input
layer or keyboard drivers initialised.
Otherwise it becomes a "toy" feature that doesn't have much value.
What would be more useful would be to disable the console blank
timer on a panic() so it doesn't blank half-way through someone
reading the oops, leaving them with no way to read the rest of it!
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sun, 21 Jul 2002, Russell King wrote:
> Otherwise it becomes a "toy" feature that doesn't have much value.
> What would be more useful would be to disable the console blank
> timer on a panic() so it doesn't blank half-way through someone
> reading the oops, leaving them with no way to read the rest of it!
I actually thought of that last night when it happened whilst examining an
oops.
--- linux-2.5.25/kernel/panic.c.orig Sun Jul 21 12:45:56 2002
+++ linux-2.5.25/kernel/panic.c Sun Jul 21 12:09:42 2002
@@ -49,6 +49,9 @@
unsigned long caller = (unsigned long) __builtin_return_address(0);
#endif
+#ifdef CONFIG_VT
+ disable_console_blank();
+#endif
bust_spinlocks(1);
va_start(args, fmt);
vsprintf(buf, fmt, args);
--- linux-2.5.25/drivers/char/console.c.orig Sun Jul 21 12:46:18 2002
+++ linux-2.5.25/drivers/char/console.c Sun Jul 21 12:24:31 2002
@@ -2758,6 +2758,12 @@
timer_do_blank_screen(0, 1);
}
+void disable_console_blank(void)
+{
+ del_timer_sync(&console_timer);
+ blankinterval = 0;
+}
+
void poke_blanked_console(void)
{
del_timer(&console_timer);
--- linux-2.5.25/include/linux/console.h.orig Sun Jul 21 12:47:01 2002
+++ linux-2.5.25/include/linux/console.h Sun Jul 21 12:25:42 2002
@@ -112,6 +112,7 @@
extern void release_console_sem(void);
extern void console_conditional_schedule(void);
extern void console_unblank(void);
+extern void disable_console_blank(void);
/* VESA Blanking Levels */
#define VESA_NO_BLANKING 0
--
function.linuxpower.ca
Here's my contribution to the ongoing beautification:
static const unsigned char morsetable[] = {
0122, 0, 0310, 0, 0, 0163, /* "#$%&' */
055, 0155, 0, 0, 0163, 0141, 0152, 0051, /* ()*+,-./ */
077, 076, 074, 070, 060, 040, 041, 043, 047, 057, /* 0-9 */
0107, 0125, 0, 0061, 0, 0114, 0, /* :;<=>?@ */
006, 021, 025, 011, 002, 024, 013, 020, 004, /* A-I */
036, 015, 022, 007, 005, 017, 026, 033, 012, /* J-R */
010, 003, 014, 030, 016, 031, 035, 023, /* S-Z */
0, 0, 0, 0, 0154 /* [\]^_ */
};
unsigned char tomorse(char c)
{
return c >= '"' && c <= '_'? morsetable[c - '"']: 0;
}
used as:
+ if (!(morse = tomorse(toupper(*bufpos)))) {
+ next_jiffie = jiffies + SPACELEN; /*Space -- For a total of 7*/
+ state = 1; /* And bring us back here when we're done */
+ }
--
Daniel
On Sun, 21 Jul 2002 17:43:42 +0200
Daniel Phillips <[email protected]> wrote:
> Here's my contribution to the ongoing beautification:
>
> [snip patch]
Nice. Thanks. Merged in spirit, if not letter. :)
I suppose I should start putting this up on a webpage instead of
bothering the list every time there's an improvement.
On Fri, 19 Jul 2002, Alan Cox wrote:
> > +static const char * morse[] = {
> > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > + "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> > + "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> > + "-.--", "--..", /* Y-Z */
> > + "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> > + ".....", "-....", "--...", "---..", "----." /* 5-9 */
>
> How about using bitmasks here. Say top five bits being the length, lower
> 5 bits being 1 for dash 0 for dit ?
??? If the length is 1..5 I suspect you could use the top two bits and fit
the whole thing in a byte. But since bytes work well, use the top three
bits for length without the one bit offset. Still a big win over strings,
although a LOT harder to get right by eye.
I want to see this go to the sound card, so that when the admins are in
the ready room drinking coffee and listening to mp3s over the speakers
they will "get the message." Actually one guys says he can read morse in
his sleep, when he's "studying a manual" head down we might see about
that;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> On Fri, 19 Jul 2002, Alan Cox wrote:
>
> > > +static const char * morse[] = {
> > > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > > + "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> > > + "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> > > + "-.--", "--..", /* Y-Z */
> > > + "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> > > + ".....", "-....", "--...", "---..", "----." /* 5-9 */
> >
> > How about using bitmasks here. Say top five bits being the length, lower
> > 5 bits being 1 for dash 0 for dit ?
>
> ??? If the length is 1..5 I suspect you could use the top two bits and fit
> the whole thing in a byte. But since bytes work well, use the top three
> bits for length without the one bit offset. Still a big win over strings,
> although a LOT harder to get right by eye.
Please read back through the thread and see how 255 different 7 bit codes
complete with lengths can be packed into 8 bits.
--
Daniel
On Friday 26 July 2002 05:43, Daniel Phillips wrote:
> Please read back through the thread and see how 255 different 7 bit codes
> complete with lengths can be packed into 8 bits.
Err, make that 'binary code strings up to 7 bits in length'.
--
Daniel
From: "Daniel Phillips" <[email protected]>
> On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > On Fri, 19 Jul 2002, Alan Cox wrote:
> >
> > > > +static const char * morse[] = {
> > > > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > > > + "..", ".---.", "-.-", ".-..", "--", "-.", "---", ".--.", /* I-P */
> > > > + "--.-", ".-.", "...", "-", "..-", "...-", ".--", "-..-", /* Q-X */
> > > > + "-.--", "--..", /* Y-Z */
> > > > + "-----", ".----", "..---", "...--", "....-", /* 0-4 */
> > > > + ".....", "-....", "--...", "---..", "----." /* 5-9 */
> > >
> > > How about using bitmasks here. Say top five bits being the length,
lower
> > > 5 bits being 1 for dash 0 for dit ?
> >
> > ??? If the length is 1..5 I suspect you could use the top two bits and
fit
> > the whole thing in a byte. But since bytes work well, use the top three
> > bits for length without the one bit offset. Still a big win over
strings,
> > although a LOT harder to get right by eye.
>
> Please read back through the thread and see how 255 different 7 bit codes
> complete with lengths can be packed into 8 bits.
It appears someone is under the misapprehension that Morse characters are
all 5 elements or less. "SK" is an example of a six element meta-character,
one of a set that needs caring for, "...-.-".
(Gawd I wish I could forget that silly communications mode. <sigh>)
{^_^} W6MKU (Color me a spread-spectrum maven.)
On Friday 26 July 2002 06:52, jdow wrote:
> From: "Daniel Phillips" <[email protected]>
> > On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > > the whole thing in a byte. But since bytes work well, use the top three
> > > bits for length without the one bit offset. Still a big win over strings,
> > > although a LOT harder to get right by eye.
> >
> > Please read back through the thread and see how 255 different 7 bit codes
> > complete with lengths can be packed into 8 bits.
>
> It appears someone is under the misapprehension that Morse characters are
> all 5 elements or less. "SK" is an example of a six element meta-character,
> one of a set that needs caring for, "...-.-".
Need I point out that we are now perfectly positioned to invent the additional
morse codes needed to represent all the remaining ascii characters? We could
call the revised code... err... "remorse" ;-)
--
Daniel
On Fri, 26 Jul 2002, Daniel Phillips wrote:
> On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > On Fri, 19 Jul 2002, Alan Cox wrote:
> >
> > > > +static const char * morse[] = {
> > > > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
[...snip...]
> > >
> > > How about using bitmasks here. Say top five bits being the length, lower
> > > 5 bits being 1 for dash 0 for dit ?
> >
> > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > the whole thing in a byte. But since bytes work well, use the top three
> > bits for length without the one bit offset. Still a big win over strings,
> > although a LOT harder to get right by eye.
>
> Please read back through the thread and see how 255 different 7 bit codes
> complete with lengths can be packed into 8 bits.
???
1 - there are not 255 different 7 bit values, there are 128
2 - morse code has a longest value of 5 elements not 7
3 - Alan was talking about len+val representation, not stop-bit patterns,
which is what I guess you mean
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Fri, 26 Jul 2002, Daniel Phillips wrote:
> Need I point out that we are now perfectly positioned to invent the additional
> morse codes needed to represent all the remaining ascii characters? We could
> call the revised code... err... "remorse" ;-)
Were you planning on an RFC for that?
Instead of lights we might include a controller driver for those
"invisible fence" dog collars, insuring that the administrator didn't
miss the message.
Actually, the only change I would add to the original idea is an interface
to the sound driver, since a lot of folks listen to audio via computer
during
the work day.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Fri, 26 Jul 2002, Bill Davidsen wrote:
> On Fri, 26 Jul 2002, Daniel Phillips wrote:
>
> > On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > > On Fri, 19 Jul 2002, Alan Cox wrote:
> > >
> > > > > +static const char * morse[] = {
> > > > > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> [...snip...]
> > > >
> > > > How about using bitmasks here. Say top five bits being the length, lower
> > > > 5 bits being 1 for dash 0 for dit ?
> > >
> > > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > > the whole thing in a byte. But since bytes work well, use the top three
> > > bits for length without the one bit offset. Still a big win over strings,
> > > although a LOT harder to get right by eye.
> >
> > Please read back through the thread and see how 255 different 7 bit codes
> > complete with lengths can be packed into 8 bits.
>
> ???
> 1 - there are not 255 different 7 bit values, there are 128
> 2 - morse code has a longest value of 5 elements not 7
The '.' (also called full-stop) is 6 elements long. The ',' is also
6 elements long. For a correct implimentation, i.e., one that sounds
correct, you need to encode a 'pause' element into each symbol. This
is because the pause between Morse characters is sometimes ahead
of a character and sometimes behind a character (the pause is ahead
of characters starting with a dot and after characters ending with a
dot, including characters of all dots -- except for numbers, which
have pauses after them). In a previously life, I had to develop
the correct "fist" to pass the Socond Class Radio Telegraph License.
This means that it is probably best to use one 8-byte character
for each Morse-code character.
If anybody's interested I have some DOS assembly circa 1987 that
did this stuff. It ignored the correct "fist", and has spaces after
each character. It doesn't sound too bad.
> 3 - Alan was talking about len+val representation, not stop-bit patterns,
> which is what I guess you mean
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On Fri, 26 Jul 2002, Richard B. Johnson wrote:
> The '.' (also called full-stop) is 6 elements long. The ',' is also
> 6 elements long. For a correct implimentation, i.e., one that sounds
> correct, you need to encode a 'pause' element into each symbol. This
> is because the pause between Morse characters is sometimes ahead
> of a character and sometimes behind a character (the pause is ahead
> of characters starting with a dot and after characters ending with a
> dot, including characters of all dots -- except for numbers, which
> have pauses after them). In a previously life, I had to develop
> the correct "fist" to pass the Socond Class Radio Telegraph License.
I had forgotten that, haven't used code in decades, and while I doubt
there will be many of those characters in a panic message (might use !
tho) best to have them.
Unless there are exceptions to the nice rules you present, no need to
encode the pause, just apply your rules to it. Hard to fit dot, dash, and
pause in a single bit in any case.
> This means that it is probably best to use one 8-byte character
> for each Morse-code character.
Clearly, if only to avoid complex code. This looks seriously neat!
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Hi to all,
I am not a "morse" guy myself, but appreciate this idea.
Here is what I dug out, (Google and my handbooks)
International Morse Code
Letter Morse Letter Morse Digit Morse
A .- N -. 0 -----
B -... O --- 1 .----
C -.-. P .--. 2 ..---
D -.. Q --.- 3 ...--
E . R .-. 4 ....-
F ..-. S ... 5 .....
G --. T - 6 -....
H .... U ..- 7 --...
I .. V ...- 8 ---..
J .--- W .-- 9 ----.
K -.- X -..-
L .-.. Y -.--
M -- Z --..
Punctuation Mark Morse
Full-stop (period) .-.-.-
Comma --..--
Question mark (query) ..--..
Hyphen (-) -....-
Fraction bar (/) -..-.
Double dash (=) -...-
(less common)
Brackets (parentheses) -.--.-
Quotation marks .-..-.
Colon ---...
Apostrophe .----.
Procedure codes
Commence transmission -.-.- (CT)
Wait .-... (AS)
End of message .-.-. (AR)
End of work ...-.- (SK)
The procedure codes are sent as a single character
If the duration of a dot is taken to be one unit then
that of a dash is three units.
The space between the components of one character is one
unit, between characters is three units and between
words seven units.
To indicate that a mistake has been made and for the
receiver to delete the last word send ........ (eight dots).
Regards (73) Jens ZL2TJT
"Richard B. Johnson" wrote:
> On Fri, 26 Jul 2002, Bill Davidsen wrote:
>
> > On Fri, 26 Jul 2002, Daniel Phillips wrote:
> >
> > > On Thursday 25 July 2002 14:51, Bill Davidsen wrote:
> > > > On Fri, 19 Jul 2002, Alan Cox wrote:
> > > >
> > > > > > +static const char * morse[] = {
> > > > > > + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
> > [...snip...]
> > > > >
> > > > > How about using bitmasks here. Say top five bits being the length, lower
> > > > > 5 bits being 1 for dash 0 for dit ?
> > > >
> > > > ??? If the length is 1..5 I suspect you could use the top two bits and fit
> > > > the whole thing in a byte. But since bytes work well, use the top three
> > > > bits for length without the one bit offset. Still a big win over strings,
> > > > although a LOT harder to get right by eye.
> > >
> > > Please read back through the thread and see how 255 different 7 bit codes
> > > complete with lengths can be packed into 8 bits.
> >
> > ???
> > 1 - there are not 255 different 7 bit values, there are 128
> > 2 - morse code has a longest value of 5 elements not 7
>
> The '.' (also called full-stop) is 6 elements long. The ',' is also
> 6 elements long. For a correct implimentation, i.e., one that sounds
> correct, you need to encode a 'pause' element into each symbol. This
> is because the pause between Morse characters is sometimes ahead
> of a character and sometimes behind a character (the pause is ahead
> of characters starting with a dot and after characters ending with a
> dot, including characters of all dots -- except for numbers, which
> have pauses after them). In a previously life, I had to develop
> the correct "fist" to pass the Socond Class Radio Telegraph License.
>
> This means that it is probably best to use one 8-byte character
> for each Morse-code character.
>
> If anybody's interested I have some DOS assembly circa 1987 that
> did this stuff. It ignored the correct "fist", and has spaces after
> each character. It doesn't sound too bad.
>
> > 3 - Alan was talking about len+val representation, not stop-bit patterns,
> > which is what I guess you mean
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
> The US military has given us many words, FUBAR, SNAFU, now ENRON.
> Yes, top management were graduates of West Point and Annapolis.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Jens Schmidt writes:
> I am not a "morse" guy myself, but appreciate this idea.
Yeah, same here. I have to wonder if morse is the
best encoding, since many people don't know it.
The vast majority of us would need a microphone and
translator program anyway, so a computer-friendly
encoding makes more sense. Modems don't do morse.
> (less common)
> Brackets (parentheses) -.--.-
Left/right just assumed?
> Procedure codes
> Commence transmission -.-.- (CT)
> Wait .-... (AS)
> End of message .-.-. (AR)
> End of work ...-.- (SK)
> The procedure codes are sent as a single character
If morse fans actually know these, then an interpretation
for correct usage in an oops would need to be determined.
> If the duration of a dot is taken to be one unit then
> that of a dash is three units.
> The space between the components of one character is one
> unit, between characters is three units and between
> words seven units.
The ARRL doesn't do this below 18 WPM. They use an
alternate timing (Farnsworth) that sends characters
at 18 WPM and adds extra space to slow down the result.
http://www.arrl.org/files/infoserv/tech/code-std.txt
The latest patch was doing 12 WPM. At that speed,
the ARRL would use Farnsworth timing.
>>>>>>> +static const char * morse[] = {
>>>>>>> + ".-", "-...", "-.-.", "-..", ".", "..-.", "--.", "....", /* A-H */
Packing into bytes while still being readable:
#define o 0 // dot
#define _ 1 // dash
#define PACK(a,b,c,d,e,f,g,h) (((((((a*2+b)*2+c)*2+d)*2+e)*2+f)*2+g)*2+h)
#define M7(a,b,c,d,e,f,g) PACK(1,a,b,c,d,e,f,g)
#define M6(b,c,d,e,f,g) PACK(0,1,b,c,d,e,f,g)
#define M5(c,d,e,f,g) PACK(0,0,1,c,d,e,f,g)
#define M4(d,e,f,g) PACK(0,0,0,1,d,e,f,g)
#define M3(e,f,g) PACK(0,0,0,0,1,e,f,g)
#define M2(f,g) PACK(0,0,0,0,0,1,f,g)
#define M1(g) PACK(0,0,0,0,0,0,1,g)
static const u8 morse[] = {
M2(o,_), M4(_,o,o,o), M4(_,o,_,o), M3(_,o,o), // A B C D
M1(o), M4(o,o,_,o), M3(_,_,o), M4(o,o,o,o), // E F G H
I suspect it's false economy to not encode all of ASCII.
If you have all of ASCII, then the ugly switch() goes away
and all you need is a foo&0x7f to ensure things don't go
from bad to worse.
>> The '.' (also called full-stop) is 6 elements long. The ',' is also
>> 6 elements long. For a correct implimentation, i.e., one that sounds
>> correct, you need to encode a 'pause' element into each symbol. This
>> is because the pause between Morse characters is sometimes ahead
>> of a character and sometimes behind a character (the pause is ahead
>> of characters starting with a dot and after characters ending with a
>> dot, including characters of all dots -- except for numbers, which
>> have pauses after them). In a previously life, I had to develop
>> the correct "fist" to pass the Socond Class Radio Telegraph License.
If this is desirable, which I doubt, then it's best generated
by looking at the characters.
No offense to anyone intended, but since this most recent discussion is
on the _original_ thread, perhaps some of you have not read the latest
"v3" version of the patch. It does make a bunch of the recent comments
irrelevant (some of the recent discussion, however, is very
interesting.)
If that thread is lost to most normal people by now, and they don't
wantto go gooja-surfing, I'll find a place on the web to put this stuff
up.
--hobbs
On Fri, 26 Jul 2002 22:05:03 -0400 (EDT)
"Albert D. Cahalan" <[email protected]> wrote:
> Jens Schmidt writes:
>
> > I am not a "morse" guy myself, but appreciate this idea.
>
> Yeah, same here. I have to wonder if morse is the
> best encoding, since many people don't know it.
> The vast majority of us would need a microphone and
> translator program anyway, so a computer-friendly
> encoding makes more sense. Modems don't do morse.
"asciimorse" would be possible, just going through the byte and doing -
for 1 and . for 0... as a matter of fact, it would probably only take
about two lines of code to get that to be an option, too. Does everyone
else think that that's really the situation? (Personally, I can't do
morse in my head. But neither do I have any oops-decoding hardware. >:)
I'll probably code it anyway. It should allow for a faster transmission
rate, anyway, since you don't have to accomodate humans. (Anyone who
can decode "asciimorse" in their head is a REAL freak. Er. no offense.)
> [some stuff on formats]
> I suspect it's false economy to not encode all of ASCII.
> If you have all of ASCII, then the ugly switch() goes away
> and all you need is a foo&0x7f to ensure things don't go
> from bad to worse.
>
The ugly switch _is_ gone. However, all of the characters that have a
reasonable encoding are between " and Z (with the exception of
lowercase, which can be mapped onto uppercase with one line).
so current tomorse does:
if (c >= 'a' && c <= 'z') {
c = c - 'a' + 'A'; //This could be a bit-twiddle, but why?
}
if (c >= '"' && c <= 'Z') {
return morsetable[c - '"'];
} else {
return 0;
}
I think this is plenty good. :)
As for Farnsworth spacing... someone provide me with proper timings
(ditlen, inter-component space, inter-letter space) for
12wpm+farnsworth and I'll code it in, if it's really that much better.
I think it's OK the way it is, but I'm one of those types who doesn't
know anything more than 'S', 'O', and 'S'. (Well, and 'E' and 'V' and
the numbers. :)
About changing the encoding: I still don't think that anything could
really be better, from a program-flow standpoint, than what we've got
now. Prove me wrong and I'll be happy.
I don't really think the pretty macros gain anything either, unless the
morse code letters are under heavy development. Last I checked, they're
not. :)
--hobbs's $0.02
On Fri, 26 Jul 2002, Albert D. Cahalan wrote:
> Jens Schmidt writes:
>
> > I am not a "morse" guy myself, but appreciate this idea.
>
> Yeah, same here. I have to wonder if morse is the
> best encoding, since many people don't know it.
> The vast majority of us would need a microphone and
> translator program anyway, so a computer-friendly
> encoding makes more sense. Modems don't do morse.
What other widely known encoding for blinking lights did you have in mind.
Clearly there are more people who know morse than any other encoding you
could make up, and even those who don't know it would know what it is.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, 29 Jul 2002, Bill Davidsen wrote:
> On Fri, 26 Jul 2002, Albert D. Cahalan wrote:
>
> > Jens Schmidt writes:
> >
> > > I am not a "morse" guy myself, but appreciate this idea.
> >
> > Yeah, same here. I have to wonder if morse is the
> > best encoding, since many people don't know it.
> > The vast majority of us would need a microphone and
> > translator program anyway, so a computer-friendly
> > encoding makes more sense. Modems don't do morse.
>
> What other widely known encoding for blinking lights did you have in mind.
> Clearly there are more people who know morse than any other encoding you
> could make up, and even those who don't know it would know what it is.
>
> --
> bill davidsen <[email protected]>
> CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.
>
The Morse Code we are talking about is not the "rip-snorting" 20
words/per/minute that Radio Operators and Hams use. Instead it's
the 3 to 5 words/per/minute code you hear on aircraft navigation
radios, used by all pilots to identify navigation aids. The
'beep' you hear from a ^G is the "dash". A shorter one makes the
"dot".
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
Bill Davidsen writes:
> On Fri, 26 Jul 2002, Albert D. Cahalan wrote:
>> Jens Schmidt writes:
>>> I am not a "morse" guy myself, but appreciate this idea.
>>
>> Yeah, same here. I have to wonder if morse is the
>> best encoding, since many people don't know it.
>> The vast majority of us would need a microphone and
>> translator program anyway, so a computer-friendly
>> encoding makes more sense. Modems don't do morse.
>
> What other widely known encoding for blinking lights did you have in mind.
> Clearly there are more people who know morse than any other encoding you
> could make up, and even those who don't know it would know what it is.
ROTFL
This is NOT morse over blinking lights. Even at 12 WPM,
which is moderately fast, you'd have to stare at the
lights for over an hour without blinking! Keep in mind
that people know morse by sound, not sight, so you'd
have to slow it down. Maybe 24 hours for an oops?
(note: in morse, hex digits are slow)
No, the lights just blink. Encoding just the instruction
pointer, in binary, might be worthwhile. I have doubts.
As for the audio... you can copy morse for over an hour
or you can tape record 4 minutes of noise. Hard choice?
On Mon, 29 Jul 2002, Albert D. Cahalan wrote:
> Bill Davidsen writes:
> > What other widely known encoding for blinking lights did you have in mind.
> > Clearly there are more people who know morse than any other encoding you
> > could make up, and even those who don't know it would know what it is.
>
> ROTFL
>
> This is NOT morse over blinking lights. Even at 12 WPM,
> which is moderately fast, you'd have to stare at the
> lights for over an hour without blinking! Keep in mind
> that people know morse by sound, not sight, so you'd
> have to slow it down. Maybe 24 hours for an oops?
>
> (note: in morse, hex digits are slow)
I certainly didn't think more than the original (prime cause) message was
going to be sent, the whole oops would be useless, some "dereference NULL
pointer" might be, and even "oh shit I die now" would be pretty obvious to
anyone who knows any code at all.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.