[quote=“diogoc”]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]
Yes, mostly. It will still send reports if nothing changed, but slower.
The card has two configuration parameters. One that specifies the minimum time in between messages (currently 1ms hard coded). Even if things change faster than that, it will not send faster. The other specifies what the maximum time in between messages will be (currently 10ms hard coded). Even if nothing changed, the card will send a report after that timeout. I intend to make both parameters configurable by the client from 0.1 to 5000.0 milliseconds.
The k8055m.dll internally creates a reader thread that consumes the HID reports as fast as possible, keeping the last one in memory and setting a flag that it has a current report. When the application calls the k8055m_recv() function and there is a report, it returns that one immediately and resets the flag. If there is none (flag not set), it will wait on a pthread condition until the reader thread signals it that there is a new message.
What will be added soon is to be able to register a Windows Event or pthread_cond_t object to be signaled when a new report was received (or an error occurred). After that signal, it is guaranteed that k8055m_recv() will not block and immediately return data or an error. That will greatly simplify developing event driven applications.
[quote=“J_Holland”][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.[/quote]
There was indeed one, but you didn’t create it, you only copied it from the original K8055 descriptors.
In short, the original K8055 causes DirectX to malfunction to the point, where DxDiag.exe crashes on WinXP! And that just because the card is connected. It doesn’t have to be used.
The K8055N has a “J” PIC and from the schematics I conclude that some of the input/output ports are wired differently. I still hope that it will be possible to support both cards with the open source firmware.
Hmmmm … I’m going to run some test and see what happens if the card tries to send faster.[/quote]
You are right. The USB handle in the firmware stays busy and limits the interval at which the card can send reports to pretty accurately 1000 per second.
So 1ms is the fastest rate possible. I’m still going to keep it dynamic though. There doesn’t seem to be any ill side effect from sending them slower than specified in the HID descriptors. So we can have the card report within 1ms if there is something to report, and shut up for up to seconds if there isn’t.
So how do you develop your software with this new modification? because the original dll shouldn’t work, right? or there is just one program that communicates with the device? That boot loader…?
Please keep in mind that this is work in progress. Many “convenience” functions are yet missing and will be added as soon as some more important protocol details and features get done. And documentation is needed badly.
The original K8055D.DLL does not work with these modified cards, correct.
The boot loader is something different and has nothing to do with the software using the card. This is only involved in uploading new firmware into the PIC.
There are a K8055M.DLL and a K8055D.DLL in the k8055-pic18f/client directory (after building them). The K8055M.DLL is the part that actually communicates with the card via the new protocol. It contains functions like k8055m_open(), k8055m_send(), and so on. A program, that wants to take full advantage of the new firmware features, will need to call those functions. This is a standard DLL written in C, exporting its API calls as STDCALL, so the usual ways of calling any DLL under Windows apply. I also try so keep all this stuff working under FreeBSD/Linux using libusb2, but I haven’t tried to compile it lately.
The K8055D.DLL is a “drop in” replacement. It exports the same functions that Velleman’s original K8055D.DLL has, so any existing software should continue to work. These functions translate the legacy function calls and call the functions in K8055M.DLL in turn. So this version of the K8055D.DLL can communicate with the new firmware. I have only tested with the original Visual Basic demo. Let me know if you discover any problems. Of course, it doesn’t use any new (and coming) features. But it allows existing software to use the modified card as if it was a good old original K8055.
Please keep in mind that this is work in progress. Many “convenience” functions are yet missing and will be added as soon as some more important protocol details and features get done. And documentation is needed badly.
The original K8055D.DLL does not work with these modified cards, correct.
The boot loader is something different and has nothing to do with the software using the card. This is only involved in uploading new firmware into the PIC.
There are a K8055M.DLL and a K8055D.DLL in the k8055-pic18f/client directory (after building them). The K8055M.DLL is the part that actually communicates with the card via the new protocol. It contains functions like k8055m_open(), k8055m_send(), and so on. A program, that wants to take full advantage of the new firmware features, will need to call those functions. This is a standard DLL written in C, exporting its API calls as STDCALL, so the usual ways of calling any DLL under Windows apply. I also try so keep all this stuff working under FreeBSD/Linux using libusb2, but I haven’t tried to compile it lately.
The K8055D.DLL is a “drop in” replacement. It exports the same functions that Velleman’s original K8055D.DLL has, so any existing software should continue to work. These functions translate the legacy function calls and call the functions in K8055M.DLL in turn. So this version of the K8055D.DLL can communicate with the new firmware. I have only tested with the original Visual Basic demo. Let me know if you discover any problems. Of course, it doesn’t use any new (and coming) features. But it allows existing software to use the modified card as if it was a good old original K8055.[/quote]
good and deep explanation thanks. I’ll see what i can do here.
This snapshot contains the current state of the firmware and all DLLs. The K8055M.DLL has all the API calls needed to control all current features of the new firmware and the DLL itself. This includes “reading” the current settings of output ports and debounce configuration when the card is opened, asynchronous reading of input data and controlling the interval of HID reports from the card.
The K8055D.DLL, that allows legacy applications to control the new firmware, is up to date.
What’s next?
Before wrapping this up into a first release, I want to add the ability to communicate with the original K8055 into the K8055M.DLL. This will allow one and the same application to control any K8055, K8055N and our Open Source K8055M. We also need at least a little bit of documentation for the API and how to build applications with these DLLs.
I would actually like someone, who is able to use the K8055M.DLL in their own program, by looking at the k8055m.c and k8055m.h files and asking me questions about them, to write that API documentation. The result will be much easier to read for less experienced developers, than whatever I would write.
firmware and bootloader 2012-04-10
testing using drop-in library and K8055_Demo.exe (Velleman\k8055_sdk_version4\Demo, 360.960 bytes)
digital output Out6 (O6) shows no activity (with standard MC and board - was OK)
card always detected as card 0 (independent of sk5 jumper)
tested with two MC’s - on the same board. Board modified: 2x15pF capacitors, 20MHz, R35 removed
for bootloader LPT adapter (i9.photobucket.com/albums/a72/oz … rt2003.jpg) + WinPic800_V3_59.exe (some errors at about ~98%) used.
firmware loaded using microchip HIDbootloader (no errors), in modified board.
can the digital outs be tested using K8055control.exe? (for example, using some switches)
[quote=“k750”]firmware and bootloader 2012-04-10
testing using drop-in library and K8055_Demo.exe (Velleman\k8055_sdk_version4\Demo, 360.960 bytes)
digital output Out6 (O6) shows no activity (with standard MC and board - was OK)[/quote]
Same K8055_Demo.exe works here. Did you copy all three DLLs from the client directory to the Demo?
Yes, sk5 is ignored at this point. sk6 is only used to control the bootloader start. I still hope for some brilliant idea how we can control the board address without using the jumpers, so that we can use them as IO ports.
[quote]tested with two MC’s - on the same board. Board modified: 2x15pF capacitors, 20MHz, R35 removed
for bootloader LPT adapter (i9.photobucket.com/albums/a72/oz … rt2003.jpg) + WinPic800_V3_59.exe (some errors at about ~98%) used.[/quote]
Does “some errors at about ~98%” mean that burning the bootloader hex file shows errors? That should not happen.
I am using a JDM type serial port programmer (Olimex PIC-PG2 rev. C) with WinPicpgm version 1.5.8.0. I get no errors and verification succeeds.
That’s the way it is supposed to work. The bootloader hasn’t changed in a while. Once that is programmed, all you need is the HIDbootloader to replace the firmware over USB (and pretty fast).
Yes. k8055control.exe is an interactive program. Once started it accepts keyboard input like
set_digital_out 5 1
set_digital_out_all 255 255
quit
I think I really need to write at least some rudimentary documentation.
Yes: K8055D.DLL, K8055M.DLL, pthreadGC2.dll and K8055_Demo.exe from k8055_sdk_version4.zip
sorry for a possibly stupid idee, but can this be done by hardcoding address bytes into firmware (then editing firmware using hex editor or use a little special written program to patch address bytes/checksum and upload to pic)?
i think this is based on my programmer/programmer setup (not file based). tomorrow will try different settings.
error address is at end of file (empty space), and bootloader works - this can’t be a reason for strange behavior of dig out6
255==11111111, but out6 without signs of live… (on the other board dead too, the only differece is 2x 18pF)
set_digital_out 5 1 must control the out6, says OK, but nothings happens…
it is posible without pain make the “time output” (ticks or something, time based, that can be converted to time) “inline” with other output (counters, ADC,…) from PIC (for frequency measurement). I know, this can be done indirectly by attaching of known frequency (for example pwm + divider) to one of counters, but i need both of pwm…
Yes: K8055D.DLL, K8055M.DLL, pthreadGC2.dll and K8055_Demo.exe from k8055_sdk_version4.zip[/quote]
That should definitely work.
sorry for a possibly stupid idee, but can this be done by hardcoding address bytes into firmware (then editing firmware using hex editor or use a little special written program to patch address bytes/checksum and upload to pic)?[/quote]
There is no “stupid idea” during brain storming. And I like this idea. The firmware.hex file is a simple text file - no need for a hex editor. The Vendor and Product ID’s we currently use are 0x10CF, 0x55F0 and there is only one occurrence of “CF10F055” in that file. So yes, a small program that edits that hex file and corrects the checksum before flashing it will do the trick. The line is the one starting with “:1033C0” and the checksum is just a 2’s complement of the previous bytes in the line. You and I can do that in Notepad.
[quote]i think this is based on my programmer/programmer setup (not file based). tomorrow will try different settings.
error address is at end of file (empty space), and bootloader works - this can’t be a reason for strange behavior of dig out6[/quote]
Right, if the bootloader works, this should not be the cause of the problem. The strangest thing is that there is absolutely no difference in the firmware or the DLLs between O6 and the other 7 output ports. Unlike the inputs, all the 8 digital outputs are actually one complete port byte in the PIC, with O1 being bit-0 to O8 being bit-7.
[quote]255==11111111, but out6 without signs of live… (the board is other too, the only differece is 2x 18pF)
set_digital_out 5 1 must control the out6, says OK, but nothings happens…[/quote]
Correct. 255==11111111. For the set_digital_out_all command, the first parameter is a mask telling which ports to change, the second are the actual values to change them to. So “255 255” will set them all ON. “255 0” will set them all OFF. “15 3” will set O1=ON, O2=ON, O3=OFF, O4=OFF and O5…O8 remain unchanged.
Not sure if I understand this question correctly, but I somehow sense you want something very similar to what I have planned for the near future.
I want to have several “modes” for digital as well as pwm outputs. The ones for pwm ports are obviously capture/compare/pwm. For the 8 digital ports, the modes aren’t as obvious. Currently we only have the normal mode, where the PC software has to tell when to turn a port on/off. For many applications, that isn’t going to be fast enough, so the on/off switching needs to be automated.
Take standard servos for example (the things you find in remote control models). They are controlled with a pulse of 1.0 to 2.0 milliseconds, about 25 times per second. A 1.0 millisecond pulse means full counter-clock wise, 2.0 milliseconds full clock wise and 1.5 milliseconds is center position. With the HID protocol being limited to 1 message per millisecond, that cannot work.
Guess what, since my last visit to HobbyTown-USA I have a Futaba S3003 servo laying around here. What I have in mind is to put a digital port into a different mode, where I can tell the K8055M to generate pulses of “length=X, pause=Y” measured in microseconds. Then let the PIC do all the work. For a standard servo, “length=1500, pause=38500” would be the exact signal to keep it in center position. So my program should look like this in the end:
i think this is similar. as i understand, the goal in both cases is to bypass the OS/PC overhead (delays) and let to pic just do the job.
for measurement needs, the exact (as possible) time position of measurement is sometimes critical. for example, if measuring frequency using one counter at PIC, and time interval between measurements - using app/OS (say using QueryPerformanceCounter/…Frequency), PIC message delivery time to app can be instable (inconstant), and measurement is at last imprecise.
if the same message from PIC incorporate both the counter and time values (counted by PIC) too, roughly speaking the frequency error/bias depends only on sensor/encoder error and on PIC “internal measurement frequency”. as i think that “time values” not necessarily must be absolute time values.
if for example: k8055m_set_servo(cardNumber, port, 1500, 38500, kill_condition, normall_stop_condition), then you have even more control. the conditions can be for example position sensor, time value etc…
if would be possible send command/s to pic, when other command is running (create some “command buffer” at PIC)… example:
command_5 running:
k8055m_set_servo(cardNumber, port, 1500, 38500, position>10, speed=20),
command sent to delayed execution (after the command 5 finishes):
k8055m_set_servo(cardNumber, port, 1500, 38500, nothing, position_counter=1250)
i dont have programmed pics or other mcs before, sorry, if this is in principle impossible.
the deadness of dig out6 on both of mc’s seems to unlikely, i’ll try to verify/measure a pcb tracks etc (on programmer and k8055), and if nothing - try to search the net about verifying of mc.
[quote=“k750”]for measurement needs, the exact (as possible) time position of measurement is sometimes critical. for example, if measuring frequency using one counter at PIC, and time interval between measurements - using app/OS (say using QueryPerformanceCounter/…Frequency), PIC message delivery time to app can be instable (inconstant), and measurement is at last imprecise.
if the same message from PIC incorporate both the counter and time values (counted by PIC) too, roughly speaking the frequency error/bias depends only on sensor/encoder error and on PIC “internal measurement frequency”. as i think that “time values” not necessarily must be absolute time values.[/quote]
Yes, there is the need for different input/counter modes too, like for frequency measurement. Here is an HS1101 based humidity sensor and Arduino code for it. The HS1101 is a variable capacitor and is in this case used to vary the frequency of a 555 timer. The Arduino code measures that frequency by counting the number of transitions over a period of time.
I think this could be done by using a K8055M counter differently. Instead of reporting every single button press/release and the new count, accumulate them over a time (like one second), report the final count, then automatically reset the counter and start over.
I did a little test and it seems that with this method we could count frequencies of up to 4kHz, maybe a little more. This is because we maintain the counters more or less “on the side” as part of the mainloop.
The mentioned Arduino code does it in a busy loop running for 1 second, which of course can count much faster. But if we do it that way, measuring a frequency will pause any other activity for that long. I’d like to come up with another solution.
ETA: After more tests it turns out that about 10,000 mainloop iterations per second is all we get with the current code. Any more added functionality will slow this down further. Counting frequencies will definitely be difficult, especially because the ports that have interrupt support (RB4 to RB7) are wired as outputs.
have resoldered back one board - all functions ok (off course, with old mc) - the reason for deadness of port 6 is definitely inside of the mc.
now waiting on willem programer - will then try again with bootloader programming
when experimenting with lpt programmer (playing with settings), sometime get interesting effect - the digital out 4 and 6 was dead (shame on me, not read mc to compare). the bootloader worked, firmware loaded without errors. after programming with oringinal settings, the port 6 was dead, but 4 - live. seems, that working bootloader it is not sufficient to tell, that he i OK.
got olimex pic-mcp-usb. after clearing and reprogramming MC, all ports are live now
the reason of dead dig out6 was incorectly loaded bootloader
for loading bootloader mplab v 8.84 used (on win7 x64 sp1)
[quote=“k750”]got olimex pic-mcp-usb. after clearing and reprogramming MC, all ports are live now
the reason of dead dig out6 was incorectly loaded bootloader[/quote]
That is wicked! With a corrupted bootloader I would have expected the firmware to not run at all. Then again, the PIC18F2550 and friends treat garbage code as NOP. So they eventually ignore some code but can “continue” a few addresses later. Or they go completely out of sync and end up running over the empty space at the end, then wrap around to address zero and “reboot”.
Anyhow, glad it finally worked and thanks for reporting back that the error wasn’t caused by our code.
thanks. I’ll see what i can do here.
