Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - JTR

61
USB Infrared Toy / Bug in winlirc
In /SendReceiveData.cpp


395    // put back into sampling mode
396    //
397    temp[0] = 's';
398    serial.Write(temp,1);
399    Sleep(50);

These three lines should not be there. The IR TOY is already in irS mode so the 's' does not need to be sent. If it did then winlirc would then have to read the response "SO1" from the serial port. It does not do this. If it did then it would fail with the older firmware, if it does not then the "S" becomes the first "send packet size" token.

In any case if it were required and actually did re-enter the irS mode then the new settings that have just been sent to the IR TOY would be clobbered and the defaults restored.

I have managed to recompile the IR TOY DLL and it *seems" to me to be working but to recompile I had to change the #include "afxres.h" to windows.h and add another define for something that was missing (I think this is a VS++ 2010 problem but I am not sure...). I would rather have someone who really knows what they are doing fix this and recompile just in case there is a problem with what I did that still lurks unseen.
62
Client software / IRToy problems...
Jawi, The new client looks really good and has some nice features added. I gave it a try out and found that the device.samples.reverseOrder  mode option for the IR TOY does not work any more.  The client always shows the output in reverse mode regardless of the setting. Somewhere between ols-0.9.5-b2 and ols-0.9.6-b3 this feature got broken.

(It appears to be broken on the logic shrimp too...)

Also noted that the comment in the cfg file is still opposite to the function.

Finally, did you ever implement  the infinite samples mode that was floated quite some time ago now?

Anyway apart from the above it worked well with the latest IR TOY firmware and I love that you got rid of the mouse movement screen artifacts.
63
USB Infrared Toy / Re: Firmware V22 bug
Also note that any overflow condition will never be correctly returned to the PC as the wrong CDC buffer is used to return it.
64
USB Infrared Toy / Firmware V22 bug
In irS.c

Last byte of frequency is not sent at all.

case IRIO_FREQ:
                        if ((irToy.HardwareVersion > 1)) { // end of capture flush
                            WaitInReady();

                            for (j = 0; j < [s:]5[/s:]; j++) {


                    case IRIO_FREQ:
                        if ((irToy.HardwareVersion > 1)) { // end of capture flush
                            WaitInReady();

                            for (j = 0; j < 6; j++) {
65
USB Infrared Toy / Re: Bad Reliability when sending IR Codes!
The IR TOY firmware just does not do things correctly and introduces errors that are quite obviously visible in the images posted in this thread. The errors can also be demonstrated mathematically and be shown to either increase or decrease depending on the IR remote type.

From the get-go some poor choices were made in the firmware coding and the effect on distorting the real timings was overlooked.

Someday I may test out the corrections I have but there doesn't seem to be much of a need. It seems as long as the IR TOY supports the most common types of remotes "approximately" well enough then, well it aint broke so don't fix it.

Its broke though...
66
General discussion / Re: New USB PICs. 16F145x
Well, I have ported the HID stack into the new look (classes now separated from core) standard USB framework and it will be available soonish. Not so my samples of these nice new PICs. Estimated time to ship 100 days. Hopefully by then microchip will have sorted out all the problems with MPLAB X and XC8 so I can recompile the stack for these parts and/or I will have finished porting my PIC18 assembler stack to these parts.

Yes a USB-UART is an ideal app for these parts and I have many other designs floating around. My damn fast PIC24 / dsPIC33 programmer for one.
68
General discussion / Re: New USB PICs. 16F145x
I've always been interested. :)

Seems to me that there is a savings of at least a Dollar over a similar PIC18F14K50 board and and that may be 25-30% of the total cost. I think that one or two people had rather unrealistic expectations of how cheap these parts would/should be.

1.57 one off price for the rather cute 14-pin part is hard to beat for a USB micro.
69
General discussion / Re: New USB PICs. 16F145x
[quote author="ian"]Nice, its like another new 16Fxxxx we're using, but with USB. Microchip seems to be trying to push what used to be the 18F line down to 16Fs. I bet the price is better than the older 18F2550 too (sadly no estimate is provided).[/quote]


$1.18 in volume for the 20-pin 18F14K50 compatible part.
70
Bus Pirate Development / Re: Bus Pirate firmware v6.2 development
Great! I have done all that too with my own "every USB (ds)PIC" stack.

I am glad that someone else is doing this for the DP stack independently so the stacks can grow in their different directions. Chances are we both have copied the same source for the descriptor structures as posted on the microchip forum so they are going to look the same in any case. If that is the case be advised that the structures for the strings do not work with C18  Well I could not get them to work at least so I just left the strings as is, (the LE part worked though).  Later I will change this to eliminate the linked list that caused the above melt down with a single error. 

I also used structures for the setup packet with very interesting results. Some wins and some loses on code side so in the end I when with a hybrid system. 

For various reasons I have decided that I will not be adding to the current stack anymore. Instead I am busy making sure that it is stable and right now I am documenting (in some detail) how the CDC- API works and how to use it.

Hope to post this on a wiki somewhere as well as having it in the source code.

Well back to the documentation. The biggest PITA ever. At least though I might finally understand how my own code works. :)
71
Bus Pirate Development / Re: Bus Pirate firmware v6.2 development
[quote author="Xykon"]I got my BPv4 today so I compiled the latest svn version to try it out. I found a little problem with the USB PID and description.

I also found that in descriptors.h, the iProduct reads Logic Shrimp whereas Bus Pirate V4 would sound nicer:

This is the complete modification:
Code: [Select]
-     /* USB_iProduct */  28, USB_STRING_DESCRIPTOR_TYPE, 'L',0,'o',0,'g',0,'i',0,'c',0,' ',0,'S',0,'h',0,'r',0,'i',0,'m',0,'p',0,' ',0,
+    /* USB_iProduct */   28, USB_STRING_DESCRIPTOR_TYPE, 'B',0,'u',0,'s',0,' ',0,'P',0,'i',0,'r',0,'a',0,'t',0,'e',0,' ',0,'V',0,'4',0,' ',0,
 };
[/quote]

You have to count the length byte and the descriptor type so the correct length is 30. Of course there is no need for the extra ' ', 0, on the end so they can be deleted and then the count of 28 would be correct.
72
Bus Pirate Development / Re: Bus Pirate firmware v6.2 development
Just found a bug in the package. Someone (me?) changed the descriptor strings but didn't update the length. Also the interrupts may need to be enabled in base.h. Still looking into this, the problems I am seeing may be because of the wrong descriptor count.

ROMPTR const unsigned char cdc_str_descs[] = {
        /* 0 */                  4, USB_STRING_DESCRIPTOR_TYPE, LOWB(USB_LANGID_English_United_States), HIGHB(USB_LANGID_English_United_States),
        /* USB_iManufacturer */ 42, USB_STRING_DESCRIPTOR_TYPE, 'D',0,'a',0,'n',0,'g',0,'e',0,'r',0,'o',0,'u',0,'s',0,' ',0,'P',0,'r',0,'o',0,'t',0,'o',0,'t',0,'y',0,'p',0,'e',0,'s',0,
        /* USB_iProduct */    [s:]28[/s:]  30, USB_STRING_DESCRIPTOR_TYPE, 'B',0,'u',0,'s',0,' ',0,'P',0,'i',0,'r',0,'a',0,'t',0,'e',0,' ',0,'V',0,'4',0,' ',0,
        /* USB_iSerialNum */    18, USB_STRING_DESCRIPTOR_TYPE, '0',0,'0',0,'0',0,'0',0,'0',0,'0',0,'0',0,'1',0

Yeah, I bet it was when it was changed from Logic Shrimp to Bus Pirate V4
74
Bus Pirate Support / Re: Bus Pirate v4 problem with OLS and Sump
I could not see anything wrong with it myself but there have been other fixes that may relate. Equally it could be that the client was not setup correctly. I did post a config for the new sump mode somewhere on this forum. Things get lost in time though and God only knows if the correct information is reaching the end user.
75
Bus Pirate Development / Re: Bus Pirate firmware v6.2 development
Ian strike while the iron is hot. I have been doing a lot of work lately on the usb stack and fixing bugs in my copy and the lastest version was posted to the above link today (yesterday now).  Seriously I can see no reason why the BPv4 is not just days away from being vastly in advance of the BPv3. The amount of work that myself and others have put in to it and it is just waiting for a final push. Maybe DP can declare August BPv4 month and give away PCBs to anyone who fines a genuine bug or something.

I have a lot of new stuff to be released soon including a port of the BPv4 bootloader to the "standard" format of the USB stack (along with the HID projects and maybe something extra).

I also have a seriously good idea cooking and I want to get onto that. ;)

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01602449872session_write_close ( )...(null):0
20.01642581488ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01642582264Database_MySQL->query( ).../DatabaseHandler.php:119
40.06182721024Database_MySQL->error( ).../Db-mysql.class.php:273