Hello,
I bought a used board P8055-1. It works fine. But there is a very bad mistake in the concept. The board activates output 8 blinking when initalizing for a few seconds. (The manual writes that LD4 will blink)
This may not be! Never at any type of I/O-interface!.
A I/O-interfaceport has never to be activated unless this is done by applikation. Now I need a external/additional logic to disable such stupid beaviour at initialisation.
Is there a modified firmware available?
Best regards
Have you tried to search this forum?
Regards,
Jan
I like such useful answers - many thanks
As far as I know, there are two starting points for alternate firmware. There is a user named Simon, who created some more or less compatible firmware for slightly different microcontrollers. He did not publish the source code for his firmware.
Then there is my Open8055 project for PIC18F2550 and PIC18F25K50 chips. It uses a modified USB HID message format, so it isn’t a drop in solution either. But since the source code is available, you should be able to take that, strip all the advanced functionality and go back to using the original HID message format.
Regards,
Jan
Hi,
[quote=“MostlyHarmless”]
As far as I know, there are two starting points for alternate firmware. There is a user named Simon, who created some more or less compatible firmware for slightly different microcontrollers. He did not publish the source code for his firmware. [/quote]
Ok - I will look what he has done or can do
I can’t do any programming in this micocontollerworld. And I don’t want to learn it. I need only a firmware without this bug of switching on a port while it inits. I think this is a problem “velleman” has to clear with a new/other firmwarechip.
Thank you very much
Wolfgang
No, they don’t.
The K8055(N) is marketed as an “Experiment Board” and the flashing of LD8 during firmware startup is a well documented feature. It is a debugging aid in the Microchip USB stack and it has helped numerous times here on the forum to find out if connectivity problems are on the microcontroller side (firmware not running) or on the PC side (USB stack not enumerating properly). Just because this useful feature of an experiment kit is in conflict with your particular use case doesn’t make it a bug.
Regards,
Jan
No, they don’t.[/quote]
I know - but this is not a excuse for a bad design bug!
I know - but this is not a excuse für a bad design bug!
It is a very stupid debug help! There are other ways to signal than to activate a outputline. Sorry -this is stupid!
[quote]Just because this useful feature of an experiment kit is in conflict with your particular use case doesn’t make it a bug.
Regards,
Jan[/quote]
Never ever a output of an I/O-Interface may be activatet for such things like a status of init.
I say it again: This is a very bad designbug! It makes the board not useful in this form. May be, that some people do not worry about.
But all people, which want do switch aktors, motors or something else have to do workarounds with relais and power-on- timedelay or something else to block unwantet signals for a time.
Let me know if you have a specific idea how to achieve the same functionality without activating any output port. I assume you know what each on/off cycle of the flashing LD8 on the P8055-1 actually means, in the context of connecting a USB client device to a host controller.
With “specific idea” I mean a usable functional specification. No hand waving. No “do something else”. Tell exactly what to do.
This is certainly true for any production I/O-interface.
As said, the K8055(N) is an experiment kit, not a production I/O-interface.
That repeated, if you can deliver that func-spec above, I might just create that firmware, burn it into a PIC18F25K50 and send it to you.
Regards,
Jan
Let me know if you have a specific idea how to achieve the same functionality without activating any output port. [/quote]
I am a user in this case and not a board-/firmware developer!
I don’t know - and I don’ need to know this! My software sees if the device answers. More is not necessary here.
I worked with hundreds of interfaces in my live as technican. Before the PC I startet with CP/M. And I never had a interface, which activated any outputs as as internal signal! This may not happen. Never ever!
Leaving this LED function away is the simpliest thing. Otherwise this is part of a hardware developer, not the user! As cardriver you want a car working and not to tell the company how to do!
This is certainly true for any production I/O-interface.
As said, the K8055(N) is an experiment kit, not a production I/O-interface.
[/quote]
That makes no difference. I can not experiment with the connected elements correct when this interface does things, which are not usual and not allowed! What would you say if a experimental car would do a 10 meter way when switching on the ignition to tell you that all works? You say: This is not a production car but a experimental car?
[quote]That repeated, if you can deliver that func-spec above, I might just create that firmware, burn it into a PIC18F25K50 and send it to you.
Regards,
Jan[/quote]
Thank you - The easiest way is to switch this function off. It is not needed! The PC signals the connection of a working USB-Device with a beep. The software can ask the interface at startup for a status. A LED on a outputport is not necessary! Never!
Best regards and a nice weekend.
You don’t need that functionality because you were able to assemble the board to a point, where it actually communicates properly with the PC. That speaks for your soldering skills and I commend you for that. But you seem to forget that this sort of “kit”, sold at stores like Radio Shack, also attracts people with beginner and intermediate kit assembly skills. They frequently do make assembly mistakes and that is when that diagnostic information comes in handy.
Stick around on the board and try to help a few folks with your knowledge and you will see. And I mean this in the most honest way. I believe you do have the knowledge, expertise and experience of a technician, who worked in the field for decades (that is what I understood from your previous messages). Your experience and expertise is certainly wanted here. You will notice that a lot of questions in this corner of the forum aren’t about microcontrollers or problems with the Velleman kits themselves. But more of a general “I lack electronics skills, please help me” nature. This is where your expertise is needed more than mine.
Regards,
Jan
Although we agree with MostlyHarmless’ point of view, we just happen to have a spare PIC 16C745 programmed with a version of the code that does not feature the flashing led.
If you return the original PIC, we’d be happy to swap it for you, as a one-time courtesy.
Sorry, since this is not an open source project, we’re unable to supply the source.
Please return it with a few words of explanation to:
Velleman Projects Tech. Dept.
Legen Heirweg 33
9890 Gavere
Belgium
You don’t need that functionality because you were able to assemble the board to a point, where it actually communicates properly with the PC. That speaks for your soldering skills and I commend you for that. But you seem to forget that this sort of “kit”, sold at stores like Radio Shack, also attracts people with beginner and intermediate kit assembly skills. They frequently do make assembly mistakes and that is when that diagnostic information comes in handy.[/quote]
I think this interface is a experimentally thing for advanced users tu experiment with extern things to switch or input. Not a tester for solderqualities!
A solderbeginner should not start with it. There are easyer things available. And a advanced person, which wants to experiment with external things in the I/O does not need a internal testfunktion on a outputline! Such a person can use the testsoftware to see if the board works internal, USB and on the I/O-lines. There is never a really need for a statusled on a outputline. This can block the usability for advanced users! In my case I need a extra delayed relais to block the unwanted output after power on for some seconds.
This LED has no real worth! It can only show that the PIC works. All other usermistakes can not be tested.
If the PIC works, you will hear the USB-Connection-Beep, you can see the device in the systemmanager and you can use the testsoftware.
[quote]
Stick around on the board and try to help a few folks with your knowledge and you will see. And I mean this in the most honest way. I believe you do have the knowledge, expertise and experience of a technician, who worked in the field for decades (that is what I understood from your previous messages). Your experience and expertise is certainly wanted here. You will notice that a lot of questions in this corner of the forum aren’t about microcontrollers or problems with the Velleman kits themselves. But more of a general “I lack electronics skills, please help me” nature. This is where your expertise is needed more than mine.
Regards,
Jan[/quote]
I will help if I can. If there is interest I may like to share my experiences. For example my little modification of this board for temperature measurement with a PT100. Very easy with only two additional potentiometers, a resistor and a PT100.
I am on the way to make a documentation.
For many years we’ve used 2 k8000 cards for a water show. (In Dutch ‘Waterorgel’)
I don’t know if they were experimental, but they’ve done a good job. However the parallel printer port is a problem for new laptops.
On your site you can find the following text under the k8000,
*** FOR USB INTERFACE SEE K8055 AND K8061 ***.
Because I needed 32 digital outputs the K8061 was not an option because it’s more expensive for the same 8 digital outputs.
Knowing the k8055, there will be 4 of them to drive the water show.
Can you offer the same solution to me, sending the PIC for replacement?
I think Lupus52 has a point, and that experimental should mean that you can have an experience with how professional things work at a low price. Of course there will be some drawbacks comparing with professional, but I think that should not be the blinking led at startup.
It’s clear that a professional interface can’t just set any output just for testing.
Hilbrand
If you return the 4 pics, we can supply 4 pics programmed with the alternative code.
Make sure you indicate your requirements when you return the pics.
[quote=“VEL417”]Although we agree with MostlyHarmless’ point of view, we just happen to have a spare PIC 16C745 programmed with a version of the code that does not feature the flashing led.
If you return the original PIC, we’d be happy to swap it for you, as a one-time courtesy.
Sorry, since this is not an open source project, we’re unable to supply the source.
Please return it with a few words of explanation to:
[/quote]
Thank you - i will do it in a time. Now I need the Board working for evaluation the testsystem here and cannot work without.
Bumping an old thread here…
The LED flashing on power-up is a slight issue, but one that can be easily worked around. No need to change the PIC.
As for other ‘real world’ interfaces that output strange signals, consider the parallel (LPT port). Since the demise of the beloved ISA bus for which many prototype PC cards were available, one of the only options to hook up digital IO to a PC was to use the LPT port. Very well documented, and an industry standard interface…8 digital output ports and 5 digital input lines on a printer port. Just like the K8055, but without the analogue I/O.
However, when ‘Plug and Pray’ came along, using the port as a mission critical interface was no longer possible…during boot any Windows from W95 OSR2 upwards sends out signals on the port during boot to identify printers hooked up to the LPT port. Parallel port interfaces that worked perfectly fine on pre-95 OS’s started playing up with printer port VXD’s initialising during boot.
Things then changed when PC manufacturers started dropping ‘legacy’ COM and LPT ports in favour of USB. Systems which I originally controlled with an ISA interface and had to modify to operate from a printer port now needed to be reworked to operate with something else. 8 output, 5 input…the K8055 was the obvious choice for me.
I’m still using them to this day, for ‘quick and dirty’ prototyping, monitoring and control on industrial and commercial systems…cheap, reliable and easy to control with a PC. Yes, the LED flash can be a problem, but the simplest resolution is to hook up the USB to a port that is permanently powered. Even with the PC powered off, the +5vSB line powers the PC USB ports and the board stays live. I’ve read Inputs 1 and 2 (and registered counts on the counter)…powered the system off, come back a week later and fired up the computer, and not only does the LED not flash with a permanently powered board but the counts in the counter registers are preserved and even updated with no software running!
If that really is a problem, and you use a laptop or wish to disconnect the board and reconnect it, then there is a simple electronic workaround which I’ve tried and works for me.
Remove pin 9 (Gnd) of the output ULN2803A and connect it to the negative side of a 22uF 16v electrolytic capacitor. Connect the positive side of the capacitor to +5v. Connect Pin9 and the capacitor negative to Gnd Via a 2k2 resistor.
When the board is first powered up, the potential on the ground pin of the ULN2803 will be near enough +5v as the capacitor is almost a short circuit to +5v on power up. As the capacitor charges through the 1k resistor, the voltage across it reaches 5v, lowering the Pin 9 to near enough ground. This has the effect that, during power up, the two output pulses which would normally flash the LED are below the potential on Pin9 and hence do not get transferred to the outputs. Once the capacitor is charged, the board will work as usual.
Fortunately on the VM110, the ULN2803A’s are fully socketed, so this ‘fix’ works on these boards too.
[quote=“retrotecchie”]Bumping an old thread here…
The LED flashing on power-up is a slight issue, but one that can be easily worked around. No need to change the PIC.
Fortunately on the VM110, the ULN2803A’s are fully socketed, so this ‘fix’ works on these boards too.[/quote]
Nice - but not really a solution of a programmers bug! A bad workaround - not more!
As a electronics engineer in the training, aerospace and defence industry for the last thirty years…let me tell you this. An electronic fix that can be implemented in hardware in a matter of a few minutes and a cost of under £1/1 Euro beats the hell out of hours of development and recoding and reworking software any day!
Bad workaround? No. A workaround that has saved time, money and redevelopment costs and solved a problem cheaply and effectively.