Skip to main content ↑ ↓
Topic: Sampling mode design (Read 2188 times) previous topic - next topic

Sampling mode design

Sorry I didn't make this comment before, but since USB is a little-endian protocol (see Chapter 8, Protocol Layer) it would seem to make the most sense for the IR Toy Sampling mode to put the high byte of the period second instead of first.  If the IR Toy were implemented with actual USB commands then this would surely be preferred.

However, since the IR Toy is really a byte stream riding on top of a serial CDC stream that is, in turn, riding on top of the USB byte stream, then I suppose it doesn't really matter.  I really just point this out as part of a larger desire to encourage people to use the actual USB protocol for complicated USB devices rather than always fall back to the simplistic serial adaptor that causes so many problems with its dependence upon virtual baud rate and getting stuck into 7-bit or 8-bit codes to break out of one mode and enter another.

Re: Sampling mode design

Reply #1 –
you can cast the stream as a short and just read it that way. You don't need to shift anything around then. USB/serial it doesn't really matter.

Re: Sampling mode design

Reply #2 –
[quote author="dukey"]you can cast the stream as a short and just read it that way. You don't need to shift anything around then. USB/serial it doesn't really matter.[/quote]No, you can't cast on an Intel machine with the IRToy sampling mode.  That's because the IRToy sends the data big-endian, and Intel is little-endian.  If the IRToy sampling mode were designed differently, as I suggested, then it would work with casting as you suggest.  However, non-Intel processors such as PowerPC would then not be able to cast.

Re: Sampling mode design

Reply #3 –
We can make it configurable without effecting the interrupt routine performance.
Got a question? Please ask in the forum for the fastest answers.

Re: Sampling mode design

Reply #4 –
I think I should retract my suggestion.

Honoring the USB little-endian standard makes more sense when you're implementing actual USB commands which directly communicate with endpoints.  But the IRToy uses the serial protocol on top of USB, and by the time you consider the higher level protocol, I admit that it really doesn't matter what byte order you use.  The original big-endian order actually makes very much sense for a serial protocol where humans will be reading the values in a manual terminal session.

I see that there is now both the original big-endian format 0x21 and a little-endian format 0x20.  That's certainly fine.  I doubt you'll ever run out of Flash as the IRToy firmware grows, but just in case I wanted to say that you could drop little-endian if nobody uses it and you're running out of firmware space.

Sorry for the thrash.

Re: Sampling mode design

Reply #5 –
No worries, I'll leave it for now. It's about 6 lines of code.
Got a question? Please ask in the forum for the fastest answers.

Re: Sampling mode design

Reply #6 –
The Wiki has some comments under Potential issues

Tracking the byte stream would be easier with an actual custom class USB endpoint, because the IRToy could send the byte stream as a packet with a clear beginning and ending.  Note that although each endpoint has a rather small maximum packet size, the USB specification allows for larger packets by automatically concatenating maximum-size packets until a packet is seen which is shorter than maximum, or zero.  This would avoid the problem of waiting for the 0xFF 0xFF terminator, but would add the trouble of real USB programming in the client rather than simple serial I/O.  I might experiment with this on my own.  ... but this design might require the PIC to store the entire sample sequence in RAM in order to avoid gaps in the packets, which might not be possible.

I also hope to review the PIC firmware at some point.

Re: Sampling mode design

Reply #7 –
Have you considered using the Capture mode of the CCP module for IR waveform timing measurements?

Unfortunately, the CCP1 pin conflicts with P1A (PWM) and CCP2 is unconnected on my IRToy v1.  I might try running a jumper.

It seems like the Capture module can only trigger on rising edges or falling edges, but not both.  This makes we wonder about two things:

1) Could the Capture interrupt flip the edge sensing on every transition?

2) Could CCP1 and CCP2 be tied to the same signal, with both Capture modules active at the same time, one triggering on falling edges and the other triggering on rising edges?  The latter would require external hardware to disconnect or disable the IR detector when transmitting via P1A (PWM) and to disable the IR LED when measuring incoming IR.  That's because of the dual purpose pins (and the fact that the module can only do Capture or PWM, but not both at the same time).

Strangely enough, P1A, the PWM output, is not documented as being present on the PIC18F2550, but it seems to be working anyway!  Has anyone noticed this in the data sheet?

P.S. Even if Capture mode won't work, it still seems possible to improve the Timer utilization for IR measurement.

Re: Sampling mode design

Reply #8 –
I'm using CCP2 on the updated hardware to count the raw IR frequency. It's such a small period that it seemed best to do it with the CCP module.

Using a 18F24J50 would be an improvement because hardware could be moved between pins, and the chip could be smaller.

I'm sorry, I don't have any answers to the questions though :)
Got a question? Please ask in the forum for the fastest answers.

Re: Sampling mode design

Reply #9 –
Thanks.  I usually try to answer these sorts of questions on my own, but I just don't have time to experiment.  I will try to modify my v1 board to mimic the updated hardware, and then I can at least try the CCP2 code that you have working.