MP3Car.com - View Single Post

OdysseyPC · 03-23-2005, 05:42 AM

That's a pretty cool project you got going on there ...

One thing I could provide you is some optimisation for your firmware. Your method of decoding is referred to as polling, which can be inefficient if your PIC needs to do other processing.

Now if you're like me you'd say nah polling will work and I won't need the PIC to do other things, but I think i've grown now to realise go efficient from the start.

Anyways to the point. You would be best to setup an interrupt routine for your bit collecting. You've already done the hardwork by collecting and decoding the signals your after. You would set your interrupt to trigger on rising/falling edges and simply calculate the time between successive triggers.

Using this method you can decode the signals by:
1. detecting the 9ms low/4.5ms high sequence indicating the start of a code sequence.
2. once a code sequence is detected you then calculate for the next 32 rising/falling edges.
3. If time between sucessive rising/falling edges is ~.5ms it's a zero, otherwise it's a one.
4. Once 32 bits have been collected then you can set a flag to indicate you have a valid code for the program to decode.

This should improve the efficiency of your code, I use this technique a lot for decoding signals of this variety. Hope this helps

03-23-2005, 05:42 AM	#2
OdysseyPC Constant Bitrate Join Date: Oct 2003 Location: ACT, Australia Posts: 114	That's a pretty cool project you got going on there ... One thing I could provide you is some optimisation for your firmware. Your method of decoding is referred to as polling, which can be inefficient if your PIC needs to do other processing. Now if you're like me you'd say nah polling will work and I won't need the PIC to do other things, but I think i've grown now to realise go efficient from the start. Anyways to the point. You would be best to setup an interrupt routine for your bit collecting. You've already done the hardwork by collecting and decoding the signals your after. You would set your interrupt to trigger on rising/falling edges and simply calculate the time between successive triggers. Using this method you can decode the signals by: 1. detecting the 9ms low/4.5ms high sequence indicating the start of a code sequence. 2. once a code sequence is detected you then calculate for the next 32 rising/falling edges. 3. If time between sucessive rising/falling edges is ~.5ms it's a zero, otherwise it's a one. 4. Once 32 bits have been collected then you can set a flag to indicate you have a valid code for the program to decode. This should improve the efficiency of your code, I use this technique a lot for decoding signals of this variety. Hope this helps __________________ Caputer Mk. II '02 VX Holden Commodore Series II Executive MII12000, 512MB RAM, 60GB HDD (5400rpm), 16X DVD, TS200V Morex 60W DC-DC, Custom S/SDC OS/Software: Developing...