Post by thread:[PIC] PIC programmer performance comparison, etc

I designed one for Peter C (DIY electronics), the K185. Both VPP and VDD are in 0.25V increments, and it operates from the USB port, with a stepup/stepdown switcher set, allowing USB V-level as low as 4V. It is intended for production useage, with a throwaway socket, etc. Uses PIC16F88, and the firmware is upgradeable via the web. I plan it to be operable with those long USB extension cables (100ft+) so it can be dragged over the production floor. Of course, it drops its power when unused. It is waiting for me to release a new programmer protocol before it can be firmed up and released. I think it can go out in Feb 2006 if not before. --Bob Chen Xiao Fan wrote: {Quote hidden}>I think Olin may have already read the thread in the >Microchip Forum. > >Microchip Forum >http://forum.microchip.com/tm.asp?m=117082 >Subject: Open Source PIC Programmer >>From Ken: >"Let me add that another requirement that I feel is mandatory >for a PIC programmer is a variable Vpp supply that is adjusted >programmatically. I think most of us are in agreement that Vdd >should be variable, but I feel that having a programmatically >variable Vpp supply keeps one from "painting oneself into a corner". >It is also necessary to comply with programming specifications >since some of the Vpp max/min windows are fairly narrow compared >with others. I'm not currently subscribed to the PICList, but I >remember making a PICList post (more detailed post) about this >a while back. It still might be in the archives." > >Ken is considering a cross-platform GUI programmer >software (using RealBaisc 2005 or similar) for a good >PIC programmer (firmware controlled variable Vdd >and variable Vpp). I think this is an interesting >topic. > >I am not so sure about Wisp628 but I think it is not >really controlled as well. PICKit 1/PICkit 2 can >control the Vpp in theory but WH Tan finds the >Vpp waveform is not good enough. Currently PICKit >2 does not support 18F so this is only a future >issue. It can do variable Vdd as well but I think >it is not implemented y*et. > >MPLAB ICD2 is using an SMPS (boost converter) >to get Vpp and use a digital poti to control the >Vpp. However it does not control target Vdd and that >is why it has problem with Vpp-before-Vdd device and >the reason it is called a prototype programmer. > >EasyProg is a production programmer according to >Microchip's definition since it can vary the Vdd >for verification (2-pass varify). However, >EasyProg does not do firmware control of Vpp right >now so Olin is recommending a volatge divider for >some new PIC 18F device. > >{Original Message removed}

I have several questions regarding K185. This looks quite attractive: USB powered, variable Vpp and Vdd, firmware upgradeable through Web, built-in SMPS, design for production, ICSP+ZIF socket. 1) How about the chip support? Can it program dsPICs? 2) Am I right to assume Vpp and Vdd are automatically controlled once the right chip is selected? What is the range of Vpp (9V to 15V or even wider)? What is the range of Vdd (1.8V to 5.5V or even wider)? Does it have alternative supply input other than USB? 3) Any information regarding the target retail price (<=US$100? without the long USB extension cable)? Regards, Xiaofan {Original Message removed}

Will there be a button on it or something to trigger the programming cycle when you're using a long USB extension and not right by the computer? Some sort of go/no go indicator might help to figure out if programming was successful if you can't see the monitor. Just an idea :) Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 10/6/05, Bob Axtell <spam_OUTengineerTakeThisOuTcotse.net> wrote: > I designed one for Peter C (DIY electronics), the K185. Both > VPP and VDD are in 0.25V increments, and it operates from the > USB port, with a stepup/stepdown switcher set, allowing USB V-level as > low as 4V. It is intended for production useage, with a throwaway > socket, etc. Uses PIC16F88, and the firmware is upgradeable > via the web. I plan it to be operable with those long USB extension > cables (100ft+) so it can be dragged over the production floor. Of > course, it drops its power when unused.

Josh Koffman wrote: {Quote hidden}>Will there be a button on it or something to trigger the programming >cycle when you're using a long USB extension and not right by the >computer? Some sort of go/no go indicator might help to figure out if >programming was successful if you can't see the monitor. > >Just an idea :) > >Josh >-- >A common mistake that people make when trying to design something >completely foolproof is to underestimate the ingenuity of complete >fools. > -Douglas Adams > >On 10/6/05, Bob Axtell <.....engineerKILLspam@spam@cotse.net> wrote: > > >>I designed one for Peter C (DIY electronics), the K185. Both >>VPP and VDD are in 0.25V increments, and it operates from the >>USB port, with a stepup/stepdown switcher set, allowing USB V-level as >>low as 4V. It is intended for production useage, with a throwaway >>socket, etc. Uses PIC16F88, and the firmware is upgradeable >>via the web. I plan it to be operable with those long USB extension >>cables (100ft+) so it can be dragged over the production floor. Of >>course, it drops its power when unused. >> >> > > > The new application will sense the presence of the chip, even in ICSP mode, and after a solid detection cycle, programming commences. When finished, a GREEN/RED LED will indicate sucess/failure. --Bob -- Note: To protect our network, attachments must be sent to attachKILLspamengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Chen Xiao Fan wrote: >I have several questions regarding K185. This looks quite >attractive: USB powered, variable Vpp and Vdd, firmware >upgradeable through Web, built-in SMPS, design for production, >ICSP+ZIF socket. > >1) How about the chip support? Can it program dsPICs? > > The unit will operate on Protocol 19, a different approach to PIC programming. P19 is a high-speed scripting language; the programmer itself has no self-knowledge of the device itself. The user can program a script to perform a series of actions to, say, execute a bulk erase, etc, write the memory array, read the memory array, etc. What is unique is that P19 allows the user to write a special script that only writes the bootblock panel, or panel 6 only, or all EXCEPT panel 6, etc . DIY decided on this approach after becoming convinced that Microchip programming methods will be unpredictable. It has been a tough firmware job, because the method must be backward-hardware-compatible with a large worldwide installed base. While I plan for it to handle DsPICs, I have not tried to write a script for them yet. It might be possible that there are special hardware issues that I have not addressed closely. Chip support is a tough task. The problem is that somehow, somewhere, somebody must maintain every revision of every PIC MicroChip makes. It's possible to do so, but only at an incredible expense. Small companies cannot afford to do so. Instead, P19 has a script format that will include a field for the person who developed the script and tested it to enter their name/handle or email address after having sucessfully tested it ON THE ACTUAL device. This sorta indicates that testing was done by someone willing to write his name in the field. DIY would then accumulate these entries into a "CHIPINFO.DIY" that can be downloaded. Of course, I will create a lot of scripts myself. >2) Am I right to assume Vpp and Vdd are automatically controlled >once the right chip is selected? > The default values are automatically controlled, yes. But a script can cause the unit to write at 5V but verify at 2V, for example. The application allows for the obvious > What is the range of Vpp >(9V to 15V or even wider)? > Presently it is 9V to 14.5V. I could change the range some by adjusting the raw-VCC to raw-VPP switcher. >What is the range of Vdd >(1.8V to 5.5V or even wider)? > > 2V to 6V; lower limit is set by the drive of the PGD/PGC driving devices (LVXX). >Does it have alternative supply input other than USB? > > Not at the moment. I could not find a reason. It can deliver 50mA+ on VPP and VDD. >3) Any information regarding the target retail price (<=US$100? >without the long USB extension cable)? > > DIY is trying to decide. It is somewhat more sophisticated than the simple devices being sold presently. My guess is somwhere around $125 USD. Size is 3.25" x 3.25", all SMT. It also has a chip handler port, which can be reprogrammed to handle special programmer needs, such as certain switching needs while programming. Our delay is the time needed to test P19 thoroughly before including P19 in the firmware of the K185. --Bob >Regards, >Xiaofan > >{Original Message removed}

Mark Rages wrote: {Quote hidden}>>The new application will sense the presence of the chip, even in ICSP >>mode, and after >>a solid detection cycle, programming commences. When finished, a >>GREEN/RED LED >>will indicate sucess/failure. >> >>--Bob >> >> > >How will you indicate success/failure to colorblind users? > >Regards, >Mark >markrages@gmail >-- >You think that it is a secret, but it never has been one. > - fortune cookie > > > How serious is that? I can wink it, as well.... --Bob -- Note: To protect our network, attachments must be sent to .....attachKILLspam.....engineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

On 10/6/05, Bob Axtell <engineerspam_OUTcotse.net> wrote: {Quote hidden}> Chen Xiao Fan wrote: > > >I have several questions regarding K185. This looks quite > >attractive: USB powered, variable Vpp and Vdd, firmware > >upgradeable through Web, built-in SMPS, design for production, > >ICSP+ZIF socket. > > > >1) How about the chip support? Can it program dsPICs? > > > > > The unit will operate on Protocol 19, a different approach to PIC > programming. P19 is a high-speed scripting language; the programmer > itself has no self-knowledge of the device itself. The user can program a > script to perform a series of actions to, say, execute a bulk erase, > etc, write > the memory array, read the memory array, etc. What is unique is that > P19 allows the user to write a special script that only writes the bootblock > panel, or panel 6 only, or all EXCEPT panel 6, etc . DIY decided on this > approach after becoming convinced that Microchip programming methods > will be unpredictable. It has been a tough firmware job, because the > method must be backward-hardware-compatible with a large worldwide > installed base. Is the P19 spec published? Regards, Mark markrages@gmail -- You think that it is a secret, but it never has been one. - fortune cookie

Wouter van Ooijen wrote: >>The unit will operate on Protocol 19, a different approach to PIC >>programming. P19 is a high-speed scripting language; the programmer >>itself has no self-knowledge of the device itself. (snip) >> >> > >Firmware-wise that sounds exactly like my work-in-progress >Wisp648/Wisp2550 :) > >Wouter van Ooijen > >-- ------------------------------------------- >Van Ooijen Technische Informatica: http://www.voti.nl >consultancy, development, PICmicro products >docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > > Yes, Peter and I decided in Jan 2005 that a scripting method is the only possible scheme that will allow the use of simple '628 devices that will cover the entire PIC range. But it isn't a trivial task, is it? --Bob -- Note: To protect our network, attachments must be sent to @spam@attachKILLspamengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Mark Rages wrote: {Quote hidden}>On 10/6/05, Bob Axtell <KILLspamengineerKILLspamcotse.net> wrote: > > >>Chen Xiao Fan wrote: >> >> >> >>>I have several questions regarding K185. This looks quite >>>attractive: USB powered, variable Vpp and Vdd, firmware >>>upgradeable through Web, built-in SMPS, design for production, >>>ICSP+ZIF socket. >>> >>>1) How about the chip support? Can it program dsPICs? >>> >>> >>> >>> >>The unit will operate on Protocol 19, a different approach to PIC >>programming. P19 is a high-speed scripting language; the programmer >>itself has no self-knowledge of the device itself. The user can program a >>script to perform a series of actions to, say, execute a bulk erase, >>etc, write >>the memory array, read the memory array, etc. What is unique is that >>P19 allows the user to write a special script that only writes the bootblock >>panel, or panel 6 only, or all EXCEPT panel 6, etc . DIY decided on this >>approach after becoming convinced that Microchip programming methods >>will be unpredictable. It has been a tough firmware job, because the >>method must be backward-hardware-compatible with a large worldwide >>installed base. >> >> > >Is the P19 spec published? > >Regards, >Mark >markrages@gmail >-- >You think that it is a secret, but it never has been one. > - fortune cookie > > > It has been published to a small core of heavy DIY programmer users for a month or two now. But the specs are not very helpful without a Win32 application. It will be general knowledge soon, but I have to finish the Win32 application first; which is not my forte- I am a firmware guy basically. It is being written in Delphi6 with all upgrades and some terrific new components. The present "MicroPro" will not be able to handle P19 because its basic approach is too simplistic. P19 will be free to all DIY programmer users, and all specs except the updater / encryptor will be freely available, in three seperate manuals: P19 MicroCode Scripting Manual (explains the scripting tokens); P19 CHIPINFO.DIY format manual, and the P19 Protocol Transfer Manual (how to control the programmer so users will be able to create their own applications. The firmware updater has a built-in decryption algorithm which will be active on the K185 and future programmers, but older programmers can utilize P19 by simply programming a HEX file. All control and data transfers are checksum-protected so errors are eliminated. DIY has been hit with pirate clones, and as a result, future programmers will be upgradeable by algorithm to registered users only. DIY will encourage Linux users to create their own apps to control P19. --Bob -- Note: To protect our network, attachments must be sent to RemoveMEattachTakeThisOuTengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Wouter van Ooijen wrote: >>The unit will operate on Protocol 19, a different approach to PIC >>programming. P19 is a high-speed scripting language; the programmer >>itself has no self-knowledge of the device itself. (snip) >> >> > >Firmware-wise that sounds exactly like my work-in-progress >Wisp648/Wisp2550 :) > >Wouter van Ooijen > >-- ------------------------------------------- >Van Ooijen Technische Informatica: http://www.voti.nl >consultancy, development, PICmicro products >docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > > I was not aware of anything you were doing, Wouter. Peter just hired me to fix his problem and P19 resulted. --Bob -- Note: To protect our network, attachments must be sent to spamBeGoneattachspamBeGoneengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

On 10/6/05, Bob Axtell <TakeThisOuTengineerEraseMEspam_OUTcotse.net> wrote: {Quote hidden}> Wouter van Ooijen wrote: > > >>The unit will operate on Protocol 19, a different approach to PIC > >>programming. P19 is a high-speed scripting language; the programmer > >>itself has no self-knowledge of the device itself. (snip) > >> > >> > > > >Firmware-wise that sounds exactly like my work-in-progress > >Wisp648/Wisp2550 :) > > > >Wouter van Ooijen > > > > > Yes, Peter and I decided in Jan 2005 that a scripting method > is the only possible scheme that will allow the use of simple > '628 devices that will cover the entire PIC range. > > But it isn't a trivial task, is it? > > --Bob > This would seem like a great opportunity to standardize and save some redundant work. Regards, Mark markrages@gmail -- You think that it is a secret, but it never has been one. - fortune cookie

> Yes, Peter and I decided in Jan 2005 that a scripting method > is the only possible scheme that will allow the use of simple > '628 devices that will cover the entire PIC range. > > But it isn't a trivial task, is it? Of course not, even a good approach won't reduce a big task to nothing :( BTW IIRC my first communication about this was in novmeber 2004, to Rob Hamerling (who did not read it because his email or he himslef, I forgot, rejected word documents). Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

> I was not aware of anything you were doing, Wouter. I was not hinting at anything like that. When an idea is good it tends to pop up independently at different places. > Peter just hired > me to fix his problem and P19 resulted. Peter contacted me too but I felt I could not free the time to do they job for DIY. Doing my own programmers is a smaller task, and I can set my own schedule. And I will probably sell your DIY proggers too :) Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

On 10/6/05, Wouter van Ooijen <RemoveMEwouterTakeThisOuTvoti.nl> wrote: > > This would seem like a great opportunity to standardize and save some > > redundant work. > > Could be, but healthy competition has its benefits too. And > standardisation requires a lot of talk and finally agreement. Remember > when the PIClist tried to agree on the perfect PIC > demo/starter/programmer board? > With mature technology, commoditization produces more beneficial competition than fragmentation. And you're right -- I don't really expect a standard out of this lot. Regards, Mark markrages@gmail -- You think that it is a secret, but it never has been one. - fortune cookie

> > >How will you indicate success/failure to colorblind users? > > > > > How serious is that? I can wink it, as well.... > > > > --Bob > > About 15% serious (assuming most of your users are male): > > http://www.designmatrix.com/pl/cyberpl/cftcb.html We have this discussion every few months, it seems. For a guy like me, red/green (or even yellow/green or amber/green, or especially orange and red OR yellow) LED signalling is completely useless. I usually ignore LEDs, since I can rarely suss out the meaning. Unless they're blinking, of course. For my money, the ideal LED output is a blink code- blink three times, then off for the duration of, say, five blinks, then repeat. It requires a key to interpret, moreso than red/green does, but if it only ever blinks in the case of a failure... Mike H.

Wouter van Ooijen wrote: >>I was not aware of anything you were doing, Wouter. >> >> > >I was not hinting at anything like that. When an idea is good it tends >to pop up independently at different places. > > > Yes. It is the only conceivable solution. --Bob. {Quote hidden}>>Peter just hired >>me to fix his problem and P19 resulted. >> >> > >Peter contacted me too but I felt I could not free the time to do they >job for DIY. Doing my own programmers is a smaller task, and I can set >my own schedule. And I will probably sell your DIY proggers too :) > >Wouter van Ooijen > >-- ------------------------------------------- >Van Ooijen Technische Informatica: http://www.voti.nl >consultancy, development, PICmicro products >docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > -- Note: To protect our network, attachments must be sent to attachEraseME.....engineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Good info, Mike. Thanks! --Bob Mike Hord wrote: {Quote hidden}>>>>How will you indicate success/failure to colorblind users? >>>> >>>> >>>> >>>How serious is that? I can wink it, as well.... >>> >>>--Bob >>> >>> >>About 15% serious (assuming most of your users are male): >> >>www.designmatrix.com/pl/cyberpl/cftcb.html >> >> > >We have this discussion every few months, it seems. > >For a guy like me, red/green (or even yellow/green or >amber/green, or especially orange and red OR yellow) >LED signalling is completely useless. I usually ignore LEDs, >since I can rarely suss out the meaning. Unless they're >blinking, of course. > >For my money, the ideal LED output is a blink code- >blink three times, then off for the duration of, say, five >blinks, then repeat. It requires a key to interpret, moreso >than red/green does, but if it only ever blinks in the case >of a failure... > >Mike H. > > > -- Note: To protect our network, attachments must be sent to EraseMEattachengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

There is some blinking LED standard for the sensors and some industrial electronics device. NAMUR NE44 is one of them for the chemical plants. Normally blinking means some fault conditions there. Green LED will indicate the power status, yellow LED will indicate the output status and red LED will indicate fault status (often blinking). We have some in-house indicator standards for our sensors. They may not be fully implemented depending on the sensors. 1) green: power-on (static on), short-circuit (4Hz blinking), under-voltage (100ms-150ms flash) = operational state of the sensor interface 2) yellow: stable signal indication (static on), unstable signal indication (4Hz blinking) = operational state of sensor, signal quality 3) Yellow/Green: human interface indication for teach-in, etc Regards, Xiaofan {Original Message removed}

Chen Xiao Fan wrote: >One more question to Bob the KIT185 developer. > >Why use a 16F88? > > It has the most bang for the buck. >In this case I assume that a 16F88 and an USB to RS232 converters >are used. Why not use a slightly higher end PICs like 18F2520 or >better 18F2550 USB parts (USB CDC class). > Nice idea. But P19, the firmware core, had to run on the older Kitsrus programmers. Had to run on the same processor or the slightly larger 648. DIY is a volume mfgr, so likes to keep the part costs low.The F88 is a winning PIC design, with NO bad habits, and it can run F628 firmware code. > I assume you will one day >used up all the Flash memory available to the 16F88, just like >the case with Olin's EasyProg, Wouter's Wisp628 and the old KITSRUS >programmers. > No, I won't. One requirement was that the P19 protocol had to FIT the older Kitsrus Programmers. It does. It is unlikely that firmware space will run out because the "firmware" is a scripting engine, NOT a programmer. Except for actual data, control tokens are downloaded to "make it all happen". I don't expect many firmware changes. The P19 as it stands does NOT even use 2K (628). > Or maybe the programming algorithm is dynamically downloaded >from the PCs to the F88. In this case, a 16F88 may be good enough. > > >Regards, >Xiaofan > > But thanks for asking. The K185 and the P19 will consume ONE year of time, the longest project set I have ever done. --Bob -- Note: To protect our network, attachments must be sent to RemoveMEattachEraseMEEraseMEengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Thank a lot for taking your time for replying. With all these answers, it seems P19 and Kit185 will be worth the one year of time you spend on it. The only potential disadvantage is the US$125 price tag. ;-) It is hitting the price of MPLAB ICD2 and PICSTART+. Of course this is a production class programmer and the cheapest right now is Olin's ProProg (US$295). Maybe the hardware is also quite complicated with the built-in adjustable SMPS. But it is often said that "you pay what you get". I wish you a great success with P19 and Kit185. It is also very nice that the existing customers can upgrade to P19. With the publish of major part of P19, maybe it is also possible to port P19 to other programmers if it offers significant benefits than the original protocol. Now we have quite some protocols. 1) closed: ICD2 and clones (APIs closed) 2) partially open protocols (?): PICSTART+ and clones, Warp 13A, Promate II/III (API seems to be available) 3) open protocols: EasyProg/ProProg, Wisp628, PICKit 1/2, Wisp648/2550 (not yet available), KitsRus P19 (not yet available) Regards, Xiaofan {Original Message removed}

Clones seems to be very hard to deal with. How to define a pirate clones? It has hit Warp 13A and as a result the firmware and the PC host software for Warp 13A is not publicly available any more. What if the clone makers is a registered user (often this is the case) under one name and clone maker under another name? Then he/she has access to the latest firmware/host software. Microchip is slightly different. It earns money from Chips and thus they may not really cares about clones of ICD2/PS+/etc (They do care a lot on chip clones or even the Zilog 8-pins). However for the third-party programmer vendors, IP protection is really a difficult issue. A lawyer is often too expensive and not so effective here. Regards, Xiaofan -----Original Message----- From: Bob Axtell Sent: Friday, October 07, 2005 4:44 AM To: Microcontroller discussion list - Public. Subject: Re: [PIC] PIC programmer performance comparison, etc ... DIY has been hit with pirate clones, and as a result, future programmers will be upgradeable by algorithm to registered users only. DIY will encourage Linux users to create their own apps to control P19. --Bob

One more question regarding KIT185. Since this is a production class programmer, it is desired to have off-pc programming capability. Does it have an optional feature ($$ added) of providing a storage like SD/MMC like Promate III and a button for programming/verify. An LCD is desired as well. That is why I think a 18F2520/2550 can be a good fit since they have enough I/O pins. Right now I guess KIT185 will not have these features because it does not have an optional power input and it uses 16F88. Maybe the follow-up may consider these features for a sub-US$200 production class programmer. Some more buttons like that in Promate III is also nice features. Maybe a buzzer can be added to take care of those blind PIC developers. ;-) *** This reminds me some interesting OT stuff *** When my wife was applying for visas to go to US last time, the visa officer was a blind but he was quite professional. I really think this is an achievement for him even though he has an assistant to help him. I also think that the State Department is respectable for taking in blind visa officers. Not so sure they still do it though. To bad I do not think our optic sensors can be used by a blind. ;-( *** End of OT stuff ***************************** Regards, Xiaofan

> Clones seems to be very hard to deal with. An encrypted bootloading system (or firmware updates only by programmed chips)is one answer. But with sufficient incentive such a scheme will be cracked, so the art is to keep the incentive sufficiently low. Note that for a vendor who has a good name to defend a clone is not just a lost sale: a bad clone will do damage to your good name, which can harm you much more than the lost sales. I choose the other approach: I opened everything up, I allow homebrew clones, I occasionally sell pre-programmed chips to someone who wants to build legal clones. I get the benefit of the goodwill, but I have to live with some cloning activity (an occasionaly I have to help someone getting his home-brew clone to work). Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

How about the traffic light "solution" ... have seperate LED's. Admittedlty I know very little about "accessiblity" issues, but multiple LED's seems like a better solution for the colour-blind than having multiple "blink codes", although, blinking lights do make me happy.... Rolf Mike Hord wrote: {Quote hidden}>>>>How will you indicate success/failure to colorblind users? >>>> >>>> >>>> >>>How serious is that? I can wink it, as well.... >>> >>>--Bob >>> >>> >>About 15% serious (assuming most of your users are male): >> >>www.designmatrix.com/pl/cyberpl/cftcb.html >> >> > >We have this discussion every few months, it seems. > >For a guy like me, red/green (or even yellow/green or >amber/green, or especially orange and red OR yellow) >LED signalling is completely useless. I usually ignore LEDs, >since I can rarely suss out the meaning. Unless they're >blinking, of course. > >For my money, the ideal LED output is a blink code- >blink three times, then off for the duration of, say, five >blinks, then repeat. It requires a key to interpret, moreso >than red/green does, but if it only ever blinks in the case >of a failure... > >Mike H. > > >