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

2
USB Infrared Toy / Re: bug report
Good catch there arhi.

Looking back though what I have here it very much appears this bug was created on an unofficial forked (nearly got that right!) version by me. However, what I have here and consider to be the official IR TOY V22 firmware still uses the old irtoy.s[80] buffer.

Last time I looked the IR TOY firmware did not exist in the SVN and what I clearly stated was a forked version (at best partially tested) has been promoted up the chain to be official release.

As it is, and at least with what I am looking at, this is only a "paper error." The DecoderBuffer actually get a whole 256 byte page and all the used bytes are written to in the ISR. The decoder still should work given the same RAM allocation as I am seeing in the MAP file.

Still, it should be corrected to:

BYTE DecoderBuffer[12];

Now we can be certain that however it is linked it will still be workable.
3
Project logs / Re: Jack-O'-Launchpad
Well, I got as far as to raid my launchpad to get the USB cable. I feel all warm and fuzzy and special inside that I know how to use the usb cable that came with an entirely new ISA. Gee, I'm a fast learner and versatile to. This should help my get a job one day...
5
Open source USB stack / Re: Stack hangs when firmware sends data and cdc port is clo
[quote author="barbiani"]Yes. This is exactly what I am trying to do since the begining... not send data if there is nobody 'listening'.

Quote
if (CDC_Inbdp->BDSTAT & UOWN)
{
putda_cdc() ;
}

Does this has anything to do with End Point available?[/quote]

Yes, that's it. In your case you probably will want to use:

if (CDC_Inbdp->BDSTAT & UOWN)
{
putc_cdc() ;
}


This will slow down the transfer speed a little (2-4 machine instructions) but that is hardly going to matter.
6
Open source USB stack / Re: Stack hangs when firmware sends data and cdc port is clo
There is no certain way for any CDC firmware to know when the CDC port is open contained within the CDC spec. It is one of the real limitations with CDC. You can know when the IN endpoint is available to your fw and not block your code based on this.  That is about it. There are discussions on other forums about using DTR etc but in the end DTR could be anything at any time. Sorry to say that there are no guarantees built in to the system, only dubious hacks and workarounds.

Anyway, in the end the problem you are having is application / implementation related. Don't call out to anything that is blocking when you can determine in advance that it is going to block. You could just as easily have the same issue with a printer on the parallel port as you do with USB and CDC.
7
Bus Pirate Support / Re: Bus Pirate Firmware 6.3 BETA development
[quote author="matthijs"][quote author="JTR"]STOP PRESS!

The info/conclusion here is not completely correct (but it got us closer so nice work anyway...) [/quote]

I did not mean to suggest that simply removing the loop was a solution, just that removing the loop fixes the problem and thus the real cause was in the loop somewhere, as you confirmed.

However, looking more closely at the UTXBF bit that is checked by UART1TxRdy shows that it indicates whether the (four byte) UART TX buffer is full. This means that with the current code (along with your fix), the while loop waits until the TX buffer is not full (as opposed to waiting until the TX buffer is _empty_). Additionally, the code for the UART1TX function which does the actual transmission is:

Code: [Select]
void UART1TX(char c) {
    if (bpConfig.quiet) return;
    while (U1STAbits.UTXBF == 1); //if buffer is full, wait
    U1TXREG = c;
}
So this means it already waits for room in the buffer during the queuing of bytes. In particular, this means that after sending a line, the buffer could be full and the while loop will wait at most one bit time. However, if the overhead of sending a byte (e.g. function returns) is more than a bit time, the current while loop doesn't actually do anything.

In any case, wouldn't it make more sense to use WAITTXEmpty instead of the while loop as it is now? This would actually wait for the last byte from the buffer to be fully transmitted, which seems like a better plan?[/quote]

Yes, I agree with all of this. The BP should wait for a complete UART flush before going to the bootloader (and entering the UART mode.) It seems the thinking here got confused somewhere, (Ready != Complete) and the whole thing only worked previously because two bugs mostly cancelled each other out.

Anyway, there is enough insight on the issue now for it to be fixed properly and pushed to the SVN by interested parties.
8
Bus Pirate Support / Re: Bus Pirate Firmware 6.3 BETA development
STOP PRESS!

The info/conclusion here is not completely correct (but it got us closer so nice work anyway...)
http://http://code.google.com/p/dangerous-prototypes-open-hardware/issues/detail?id=5#c1

The real cause for this problem is this in baseIO.c

unsigned char UART1TXRdy(void) {
      return  U1STAbits.UTXBF;
}

The returned TRUE/FALSE polarity is wrong (inverted.) 

Previously I had advised that this:

    while (UART1TXRdy == 0); //wait untill TX finishes

should be this:

    while (0 == UART1TXRdy()); //wait untill TX finishes

While this test was incorrect UART1TXRdy() was never called so the bug in it never appeared.

Now with the above fix-up it does and needs to be corrected to:

unsigned char UART1TXRdy(void) {
      return  !U1STAbits.UTXBF;
}


This appears in TWO places inside baseIO.c. Both need to be corrected.

As best I can see the only functions in the BPv3 that this will affect (fix!) are the entry to the bootloader and the baudrate setting for the UART mode.

Before finalizing on the above solution I would recommend that people try it and double check my theory then push the correction to the SVN.
10
Bus Pirate Support / Re: Bus Pirate Firmware 6.3 BETA development
This USB stack fix for the BPv4 needs to be pushed to the svn.

http://code.google.com/p/dangerous-prot ... sb_stack.c

Line 456 reads:
            if (epbd->BDSTAT &= ~BSTALL)

This should be:

            if (epbd->BDSTAT &= BSTALL)

This is only a minor issue and in practice has no effect other than to prevent the USB stack from passing the USB Chapter 9 compliance test. The same fx is required on all releases of the USB stack including from the IR TOY and free standing echo tests etc...

Thanks...
11
General discussion / Re: PIC types for UBW
[quote author="Sleepwalker3"]The only thing I've found is that the K have a 10bit ADC, the non-K has 12 bit...[/quote]

No, that is NQR. Generally the non-K parts with 12-bit ADC are the one's that end in either 3 or 8. That is, they in fact have 3 added to the last digit to denote an update from 10-bit to 12-bit ADC.

For example:

18F2553 is a 2550 with a 12-bit ADC instead of the 10-bit ADC found on the 2550.
18F2458 is a 2455 with a 12-bit ADC instead of the 10-bit ADC found on the 2455.

K or non-K has nothing to do with the ADC resolution.

Someday there may in fact be a 18F25K53, who knows what microchip have planned...

EDIT: Spelling
12
USB Infrared Toy / Re: Errors compiling firmware.
Edit and scrubbed all that I said here previously...

The MPLAB X project for V22 in the SVN is N/A and should be removed it contains references to files that were removed by Ian and/or myself and/or others when DP decided to drop little used features and when the open source USB stack was refactored.

It would seem that V22 was created with MPLAB 8.xx  and only the MPLAB 8.xx project is useful.  MPLAB X was still beta software when all this was done and it seems that an old experimental MPLAB X project for V21 has been miss-copied to the SVN.

For MPLAB X support you can import the MPLAB 8.xx project into MPLAB X (will have to delete the MPLAB X folder first) under File -> New Project -> Import existing MPLAB 8.xx
13
USB Infrared Toy / Re: USBIRToy not working in SUMP mode
Sorry! I was wrong.  The "official" IR TOY firmware is two generations behind my own forked version and there is no prj_usb_config.h file associated with V22.  You would make the above changes in HardwareProfile.h where "T2_RXsampleperiod" is defined.

Sorry about that...
14
Bus Pirate Support / Re: Bus Pirate v4 reset kills its USB connection
I cannot see anywhere where the BPv4 is reset in BBIO mode. Not at least in firmware 6.3. It appears that someone has already addressed this issue and the command 0b000 ffff does cause a soft return to procMenu and not a hard reset in the BPv4.
15
USB Infrared Toy / Re: USBIRToy not working in SUMP mode
That is really great to here. The SUMP mode does show some interesting things that otherwise remain hidden and don't be afraid to play around with the settings to get better resolution and more samples. You can add some new defines to the prj_usb_config.h  and SUMP.h file and tinker a bit if there is something that breaks the compile or just ask me. 

32K samples at 150KHz sample rate is a lot more fun that 4K samples at 10K sample rate.

In  prj_usb_config.h add this:

//====================================
// SUMP mode defines, choose ONE only
//====================================

// NOTE! Whatever settings are selected here must also be selected manually in the OLS client
// Currently there is no automatic matching.

//#define SUMP10K        // 10kHz SUMP mode
#define SUMP100K      // 100kHz SUMP mode
//#define SUMP125K      // 125kHz SUMP mode
//#define SUMP150K      // 150kHz SUMP mode MAX recommended until further testing.
//#define SUMP200K      // 200kHz SUMP mode Firmware 22A only (Fast double buffer)
//#define SUMP240K      // 240kHz SUMP mode  Firmware 23A only (Insane quad buffering)

#define SUMP_SAMPLE_PKT_CNT 0x100  //( * 64 byte packets) 0 = 65536 (MAX)


In SUMP.h add this:

//============================================
// See prj_usb_config.h for user mode defines.
//============================================

//SUMP sample period with TIMER2
#if defined SUMP10K
#define T2_RXsampleperiod()    PR2 = 149; T2CON = PRE_x4  + POST_x2 //10kHz 12M / 15 / 4 / 2  Note that PR2 needs to one less than calulated value
#elif defined SUMP100K
#define T2_RXsampleperiod()    PR2 = 119; T2CON = 0  //100kHz 12M / 120  Note that PR2 needs to one less than calulated value
#elif defined SUMP120K
#define T2_RXsampleperiod()    PR2 = 99; T2CON = 0  //120kHz 12M / 100  Note that PR2 needs to one less than calulated value
#elif defined SUMP125K
#define T2_RXsampleperiod()    PR2 = 11; T2CON = PRE_x4  + POST_x2  //125kHz 12M / 12 / 4 / 2  Note that PR2 needs to one less than calulated value
#elif defined SUMP150K
#define T2_RXsampleperiod()    PR2 = 9; T2CON = PRE_x4  + POST_x2  //125kHz 12M / 12 / 4 / 2  Note that PR2 needs to one less than calulated value
#elif defined SUMP200K
#define T2_RXsampleperiod()    PR2 = 59; T2CON = 0  //200kHz 12M / 60  Note that PR2 needs to one less than calulated value
#elif defined SUMP240K
#define T2_RXsampleperiod()    PR2 = 49; T2CON = 0  //240kHz 12M / 50  Note that PR2 needs to one less than calulated value
#endif

//*************************************************************************************************

In the OLS client IR TOY plugin alter these lines to include the new options.

device.samplerates = 10000, 20000, 100000, 125000, 150000, 200000, 240000


device.capturesizes = 1024, 4096, 8192, 16384, 32768

BTW, the OLS people know about the new IR TOY SUMP mode. I cannot say why an updated CFG file was never included in the OLS client. Just one of those oversights I guess...