thanks. nice project and open source 
one question, that firmware wil work with all software compatible with k8055 like the original?
[quote=“diogoc”]thanks. nice project and open source
one question, that firmware wil work with all software compatible with k8055 like the original?[/quote]
That is the idea, if it doesn’t, that would be considered a bug at this point. As usual, this comes as-is, without any warranty.
At the moment, the HID message format on the USB connection should be identical to what the original K8055 firmware and the corresponding Velleman K8055D.DLL do. There may be some minor differences in timing, but the demo software in the SDK didn’t notice anything.
That said, the on-the-wire message format is probably one of the first things we need to change to support more features of the PIC18F chips. For example, they do have 10 bit resolution in the ADC, but the HID report only has room for the original 8 bits. Likewise the only reason we didn’t implement counters for all 5 digital inputs is that there is nowhere in the HID report to put that data.
However, even if we redefine the protocol from scratch, we certainly will continue to provide a backward compatible K8055D.DLL replacement. That DLL is already there inside the client directory. You can replace the ones you find in the SDK demo directories with our one and the demos will continue to work as if nothing happened.
ok. I will get a 18f2550 and do some tests 
You are aware that you also need a PIC programmer, since the bootloader cannot be put into the 18F2550 through the K8055 itself?
[quote=“MostlyHarmless”]
You are aware that you also need a PIC programmer, since the bootloader cannot be put into the 18F2550 through the K8055 itself?[/quote]
yes I have an ICD2. By the way, I cannot put the firmware directly in the pic without the bootloader, right?
[quote=“diogoc”][quote=“MostlyHarmless”]
You are aware that you also need a PIC programmer, since the bootloader cannot be put into the 18F2550 through the K8055 itself?[/quote]
yes I have an ICD2. By the way, I cannot put the firmware directly in the pic without the bootloader, right?[/quote]
Short answer: You should be able to do that.
Long answer:
I followed the Microchip programming examples of putting “forward” startup and interrupt vector jumps into the code. I didn’t test that though.
The idea is to put assembler “goto” instructions, “jumping” to where your code is, at locations where you suspect those vectors to be at runtime. By default, the reset vector is 0x0000, the high priority interrupt vector is 0x0008 and the low priority one is 0x0018. If you have a bootloader in the PIC, the boot loader is using those vectors. But because these parts of the code are in memory, that is considered read-only by the bootloader, it will not program them.
So if you program the firmware directly into the PIC with your ICD2, those forward jumps will be there and the firmware will operate as intended. It will just waste the program space, normally occupied by the bootloader. And it will waste an additional goto instruction execution on every interrupt. I couldn’t care less.
If you load the same firmware through the bootloader, the program space occupied by the bootloader itself is considered read-only, so it will ignore the programming instructions for that memory and forwarding of those jumps will follow the bootloader code. Currently that code tests for sk6 on reset, jumping to 0x1200 if it is not closed. And it jumps to 0x1208/0x1218 on high/low interrupt because the bootloader itself doesn’t use any interrupts at all.
There is a ifdef statement in the code that allows you to build it to use with the bootloader or without. If you search files for ‘bootloader’ you will find it.
The #define for that is in “HardwareProfile - K8055_PIC18F2550.h” on line 59:
#define PROGRAMMABLE_WITH_K8055_PIC18F2550_HID_BOOTLOADERYou would also need to change the linker script though. Otherwise there will still be 4608 unused bytes of program memory at the start.
I tested it and yes, the firmware .hex file, that is in the binary downloads, does work that way. You can burn it directly into the PIC with your ICD2 and have no bootloader at all.
Last night I looked a little closer into the I²C idea and it turns out that the MSSP module, which implements the bus in hardware, is using pins RB0/SDA and RB1/SCL. No chance to use any other pins. So the idea of using sk5/sk6 for the bus is dead and adding this bus to the K8055 will require some more hardware modifications and probably sacrificing the two digital outputs.
Also, the schematics for the K8055N are now on the Velleman site: vellemanusa.com/downloads/0/ … 55n-uk.pdf
That new connector sk9 is indeed a programming header.
They have also changed a few things about the address jumpers and the usage of some RA and RC ports around that.
Thanks for you answer.
That I2C ideia is for expanding the number of I/O?
[quote=“diogoc”]Thanks for you answer.
That I2C ideia is for expanding the number of I/O?[/quote]
No, I²C is a simple serial bus. A lot of sensor modules for building robots use it. Things like accelerometer, altimeter, GPS, ultrasound distance measuring and so on. The bus only needs 3 wires (ground, clock and data) and you can have a lot of modules connected to those 3 wires in parallel before you’re running into trouble.
Did anyone else try to convert a K8055 to these new PICs? I didn’t see any feedback. Please let us know if there are any problems with the instructions or even better, if there aren’t any and you succeeded. Any feedback would be greatly appreciated.
The next step is actually taking advantage of having such a more capable PIC.
I think for a PIC18F2550/2455 equipped board we need not only new commands, but a different HID report format, or rather formats. These PICs provide 10 bit ACD converters and would have absolutely no problem maintaining 5 digital input counters. All that data just doesn’t fit into the 8 bytes of the existing report.
Now while at it, rather than just changing that format, why not redefine the on-the-wire protocol from the ground up? Here is what I have in mind so far:
[ul][li]Report full 10 bit resolution in 16 bit short integers for the ACDs.[/li]
[li]Report counters for all 5 digital inputs.[/li]
[li]Allow to query the current settings of output ports. This will require different HID report message types. The PC would send a special command and the K8055 would report with the current settings. This functionality is useful because the current firmware maintains its status just fine even if the PC is rebooted (or disconnected from a powered USB hub).[/li]
[li]Send the default report only if any input states have changed, but with a minimum and maximum user definable interval. What I mean with that is that the K8055 would compare the current report with the last one and only send it if something has changed. New commands allow to set that it will send a report at least every X milliseconds, but no faster than every Y milliseconds.[/li]
[li]Make the interface DLL multithreaded, so that it consumes incoming reports as fast as possible. With the current DLL, a program that polls slower than every 10ms will always get 300ms old data.[/li]
[li]Support that the DLL will signal a user defined Windows Event or pthread-Mutex when it receives a report. This will make it easy to implement entirely event driven communication.[/li][/ul]
There will of course be a compatibility library on top of that, which will allow to run legacy applications unchanged.
Comments? Suggestions?
Regards,
MostlyHarmless
I agree with you. it is a great improvement for that board
my feedback to your firmware, I have used a bit and so far not encountered any problem, everything works ok
for future changes could be used eg PIC18F4550 and expand the number of inputs/outputs, but it implied a new pcb …
Thanks for the feedback, diogoc.
I have started coding some of those changes by first increasing the report size to 16 bytes and implementing all 5 counters. Next up is a different command format for setting outputs and doing counter reset/debounce. After that I’m going to try to work the analog inputs/outputs on full 10 bit resolution.
The 4550 is the 40-pin version, correct? I honestly don’t think this would work at this point. As you said, it requires a whole different pcb. I don’t even have a K8055N yet, and I find it rather difficult to develop firmware for something, I don’t have. If we had a few more developers joining, that may quickly change.
The work in progress is available here: github.com/wieck/k8055-pic18f/t … d-protocol
Of course, trying/testing the bleeding edge from the github repository requires to have the entire development environment installed, because it doesn’t contain any binaries.
That was a lot easier than I thought.
Current github branch new-hid-protocol has firmware counters on all 5 buttons, debounce times from 0.1 to 5000.0 milliseconds at 0.1ms precision and 10 bit resolution on analog inputs and outputs. My DAC1 ranges from 0.005 to 4.720 Volts. From that I calculated that 216 should be 1.0V and what do you know, my digital multimeter reports 1.001 Volts. That is more precise than the tolerance of all involved components.
I have created a new snapshot of the K8055M firmware and client libraries.
jannicash.info/k8055/download/Win32/2012-04-04/
This implements 10 bit resolution on A/D and PWM, changing the value range for both to 0…1023. It also implements counters for all 5 digital inputs and accurate debounce configuration from 0.1 to 5000.0 milliseconds. There is a little odd thing in the A/D conversion in that it seems to oscillate in the least significant bit. I guess that the TAD/TOSC settings are not perfect.
The card currently will send HID reports for new input values as fast as 1ms apart, if there are any changes in inputs. If not, they will be 10ms apart like the original K8055 did. These values will soon be client-configurable.
The client library can currently NOT talk to the original K8055. Adding backwards compatibility is on my short list. Also on the short list is adding some documentation for the new K8055M.DLL, which needs to be used to actually use all the new features. The Tcl/Tk demo2 script, which is using the K8055M.DLL via the K8055control.exe program, is able to control all current features.
The client library is internally multi-threaded now. This means that even if a client program is not polling for messages as fast as the K8055M is sending them, the HID messages will not sit around in the operating system’s HID ring buffer. This makes the original VB demo program more responsive.
The HID descriptors have also been fixed so that the card no longer causes problems with DirectX. Thanks to VEL255 for confirming some details in that regard.
This means that the new k8055 send the new values when there are changes in the inputs?
so the client program dont need polling, and it generates an event/interrupt when someting has changed?
[quote=“MostlyHarmless”]
The HID descriptors have also been fixed so that the card no longer causes problems with DirectX. Thanks to VEL255 for confirming some details in that regard.[/quote]
Was there a problem with the HID descriptors that I created? I haven’t looked at my card for a while its back running completely custom firmware in a test set but I will buy a K805N when they are available.