Re: [SLUG] Suggestions for a monochrome printer.
How much do you value your limbs at? We have a Brother HL-5250DN which we are fairly happy with. The current successor seems to be this: http://www.shopbot.com.au/pp-brother-hl-5340d-price-181171.html which is listed starting at $218. If you already have a laser printer it might be possible to get a duplexing attachment, though I suspect it would cost nearly as much as a new printer anyway. Regards, Jon. On 23/05/10 02:00, wbenn...@turing.une.edu.au wrote: Can anyone suggest a monochrome printer with duplex function that works with Linux, for domestic use? I've been told that, with duplex function, it will cost an arm and a leg. (Actually, if it works satisfactorily, I'll compromise on a leg.) William Bennett. -- Australia's leading Ubuntu trainer http://learnubuntu.com.au -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Suggestions for a monochrome printer.
Can anyone suggest a monochrome printer with duplex function that works with Linux, for domestic use? I've been told that, with duplex function, it will cost an arm and a leg. (Actually, if it works satisfactorily, I'll compromise on a leg.) William Bennett. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Serial write problem
Jim Donovan wrote: I have been working with a single-board computer (TS-7250, using the built-in linux) which, about three times per second, sends 8-byte messages out through COM2 to another device. Very occasionally (it can go 20 hours without failing) a message doesn't all get transmitted. Only 7 of the eight bytes get sent. On these occasions, the status returned by write(2) is "Resource temporarily unavailable". It seems reasonable to try another write(2) to transmit the eighth byte. However, it crashes without returning. We tried with COM1 and the same thing happened. This is illogical - we are not using handshaking and the UART has no way of knowing what is going on at the other end of the line or even whether there is anything there. I have dumped termios and the control registers immediately before the crash; no corruption or other abnormality is evident. Before I try a different linux (cut-down debian Potato is available), does anyone have any simpler suggestions? Thanks, Jim Donovan I'd be trying to see if its happening after a set time or set number of bytes. I'd also try and blast data out and see if you can cause the failure in a short enough time frame to debug it. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Serial write problem
On 22 May 2010 20:46, Jim Donovan wrote: > > I have been working with a single-board computer (TS-7250, using the built-in > linux) which, about three times per second, sends 8-byte messages out through > COM2 to another device. Very occasionally (it can go 20 hours without > failing) a message doesn't all get transmitted. Only 7 of the eight bytes get > sent. On these occasions, the status returned by write(2) is "Resource > temporarily unavailable". What line discipline is the tty driver in? raw? cooked? What do you see on the other side? Looking at tty(4) now I see that things progressed hugely since I last programmed serial terminals, so I'm not up to date with all the API's but I assume the principles of serial communications are still similar - there could be (usually should be) some flow-control and checksum mechanism going on between the two sides which might interfere with the flow (flow control could be either using STOP and START bytes (^Q/^S) or lowering the signal on one of the lines). > > It seems reasonable to try another write(2) to transmit the eighth byte. > However, it crashes without returning. We tried with COM1 and the same thing > happened. This is illogical - we are not using handshaking and the UART has > no way of knowing what is going on at the other end of the line or even > whether there is anything there. I have dumped termios and the control > registers immediately before the crash; no corruption or other abnormality is > evident. How do you define a "crash"? The program explodes? The UART stops responding? The entire single board kernel crashes? what? Can you give more details from the control registers and the other data you gathered? > > Before I try a different linux (cut-down debian Potato is available), does > anyone have any simpler suggestions? > > Thanks, > > Jim Donovan > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Serial write problem
I have been working with a single-board computer (TS-7250, using the built-in linux) which, about three times per second, sends 8-byte messages out through COM2 to another device. Very occasionally (it can go 20 hours without failing) a message doesn't all get transmitted. Only 7 of the eight bytes get sent. On these occasions, the status returned by write(2) is "Resource temporarily unavailable". It seems reasonable to try another write(2) to transmit the eighth byte. However, it crashes without returning. We tried with COM1 and the same thing happened. This is illogical - we are not using handshaking and the UART has no way of knowing what is going on at the other end of the line or even whether there is anything there. I have dumped termios and the control registers immediately before the crash; no corruption or other abnormality is evident. Before I try a different linux (cut-down debian Potato is available), does anyone have any simpler suggestions? Thanks, Jim Donovan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
