MC9RS08KAx IR-RC5 remote help?

[abicash]

Hi I am quite new to Freescale and have good experience on ATMEL and TI. The MC9xx device was suggested by one of my component suppliers for a project that I am starting (over ATMEL) considering the very-low-cost of the MC9RS08KAx-6pin devices. Project: IR Remote based on Philips-RC5 protocol (Transmitter+Receiver) with one switch(Transmitter) to control one device(Receiver) . Now I can build the project from scratch,but luckily I found a ready code for the receiver section in Assembly on the Freescale site, under code/snippets. I was wondering if such a code is there somewhere for the transmitter side as well!So that all of my development time is cut. P.S.:Meanwhile I am loving the CodeWarrior IDE and the amazing devices,cursing myself for not looking at these devices earlier.

[fabio]

Hello Abicash,

Are you aware of the fact the RS08 are very different from the HC08 and S08 devices ?

The RS08 family (from which the KA devices are part of) is a subset of the S08 instruction set, with a different programming model.

The example code you found is really designed for RS08 devices?

Best regards,

[bigmac]

Hello,

I entirely support Fabio's comment.  However, if your reference is AN3402, this does pertain to the RS08 device you intend using.  For the decoding process, there is implied use of an external IR sensor/demodulator module, the output of which is connected to the MCU.

The IR encoding process is a completely different situation, because you need to accurately generate a high frequency carrier signal (36 kHz in the case of RC5 protocol), in addition to on-off keying of the carrier.  With careful selection of bus clock, this may be feasible as a software process, but it is also possible that the RS08 device may be inadequate for the task.

Freescale does have other devices, from the 9S08 family, that contain special hardware resources for the purpose of generating the carrier signal.  AN3053 would apply to these MCUs, but may also be of interest because the document also summarizes many of the different encoding schemes, including RC5.

Regards,

Mac

[abicash]

Hi Fabio and Bigmac, Thanks for your replies.Really appreciated! The first thing that Fabio mentioned was [quote]Are you aware of the fact the RS08 are very different from the HC08 and S08 devices ?[/quote] Yes I know this for some time now. [quote]The example code you found is really designed for RS08 devices?[/quote] As mentioned by Bigmac,Yes,the one I found (AN3402) was for RS08 devices.This one was exactly the same design as I had intended to use. Bigmac,as you rightly mentioned,after looking around a bit I understand that RS08KAx devices would be insufficient for the generation side.I had d/l AN3053 but had missed it in my folder now containing loads of data regarding this project.Thnaks for pointing that to me.I can now see the source code for RC5 in that Now I want you to suggest a right device for this to me. Meanwhile I want to go off topic for a bit.Since I used ATMEL all my life as a priority device,it was ATMEL AVR that was intended for this purpose.But the sorry state of sampling and distibutor support (which I have put up on forums on avrfreaks.net) had compelled me to look somewhere else,which being TI earlier.But TI doesn't seem to have a comprehensive product line-up which would meet my purpose,which Freescale very well does along with very good sampling/tooling support.I am more than happy at the moment contrary to one avrfreak who has said "you will be sorry" for using freescale.I dont know where that comes from!Unless he's referring to a substantial order that awaits Freescale. *edit* I am looking for very-low-cost controller devices.RS08KA fit the bill but S08RC/RD dont.Any suggestions?

Message Edited by abicash on 2008-02-12 06:48 AM

[fabio]

Hello Abicash,

What about the MC9S08QD2 or QD4 they are cheap, two 16-bit timers (three CCP channels), 2 or 4 KiB of FLASH and 128 or 256 bytes of RAM ...

Best regards,

[abicash]

Thanks again Fabio for replying instantly. Will the s/w for MC9S08RC/RD/RE/RG be compatible with MC9S08QD2 family? If so,these are pretty good devices.I see a budgetary pricing of $0.6~ which suites me!

[fabio]

Except for the Carrier Modulator Timer (CMT), the peripherals are similar (TPM, RTI, etc.).

Note that only the Rx devices (RC, RD, RE and RG) implement the CMT module.

Best regards,

[bigmac]

Hello,

To use the QD2 for the IR encoder application, you would need to write your own code.  Since there is no CMT, the carrier would need to be generated by other means - there are a couple of possibilities.

But first, let's examine the characteristics of the RC5 format, to get a better idea about the timing considerations required.  The QD2 device is capable of generating nominal bus frequencies of 8MHz, 4MHz, 2MHz or 1MHz. I will assume "standard" trimming to exactly these frequencies.

The RC5 carrier requires a frequency of 36kHz, with about 30 percent duty.  For a 4MHz bus, each carrier cycle would occupy exactly 111 bus cycles, possibility with an ON period of 34 cycles, and an OFF period of 77 cycles.  For 8 MHz bus, the number of cycles will double.

Each burst of carrier may be either 32 or 64 carrier cycles.  The gap between carrier bursts will correspond with 3556 or 7111 bus cycles, assuming 4 MHz.

The first possibility -

1. Use a timed firmware loop to generate each carrier cycle.  The loop must provide the number of cycles required for the correct carrier frequency, and must also test for when the carrier burst is complete.  Interrupts must not occur while the burst is being generated.  This would also imply that the firmware must be coded in assembler.
2. Use a TPM channel, with software only output compare mode, to time the gap between carrier bursts.  In this case, the interrupt would probably be used.

This method should be feasible for a bus frequency of 4MHz.  "Padding" cycles will probably be needed within the loop, to adjust the timing.

The second possibility -

It would be tempting to consider whether the TPM channel could also be used to generate the carrier signal, in addition to the gap period, this time using the channel hardware output pin to directly switch the IRED driver transistor.

This will require the processing of the ISR within a worst case period of 34 bus cyles, for 4MHz.  I doubt that this is feasible.  However, for 8 MHz bus, the worst case period would be 68 bus cycles, which might just be feasible, with very careful coding, again in assembler.  No other interrupts, except the timer channel interrupt, should be enabled during the carrier burst period.

Regards,

Mac

[bigmac]

Hello,

I have had some additional thoughts about the last paragraph of my earlier post -

This will require the processing of the ISR within a worst case period of 34 bus cyles, for 4MHz.  I doubt that this is feasible.  However, for 8 MHz bus, the worst case period would be 68 bus cycles, which might just be feasible, with very careful coding, again in assembler.  No other interrupts, except the timer channel interrupt, should be enabled during the carrier burst period.

To somewhat ease the critical timing, the operation could remain within the ISR for the whole carrier mark period (34 cycles), rather than exiting and re-entering the interrupt, as was originally intended.  Within the ISR, the channel register would be first incremented by 34, and the channel flag polled in a tight loop  When the flag became set, the channel register would be incremented by 77, to time the remainder of the carrier period, and the ISR exited.  The channel flag also needs to be cleared (twice), and the next output states setup within the ISR.

With the more relaxed critical timing, it may be feasible to use C coding.

Regards,

Mac

[abicash]

Hi Bigmac Thanks for the tips. Instead of the software time delays,will it be feasible to generate interrupt driven timed delays? I mean for the carrier generation. I think this task would be quite complex with assembly,simply because I am still illiterate and the time period is 1 month for completion of project. So as suggested C-coding would be preferable.

Message Edited by abicash on 2008-02-13 08:18 AM

[JimDon]

abichash,
 I have a question - doe s this product only have to work with it self?
That is, does it also have to work with any "universal" remote, or just your own remote?

[abicash]

So lots of timing calculations. Now for some more suggestions. What are the minimum specs that I need for this? I think Flash=1k,RAM=?,Timers=atleast 2-8bit for software carrier generation(will be easier this way)while the loop for bursts can be added in s/w whereas the other timer would be used for generating the 14 bits,Comparator=?,I wont need SPI/SCI interface,Minimum 1 I/O pin..These seems very crude justifications but maybe I will expect some help!

Message Edited by abicash on 2008-02-13 11:06 AM

[bigmac]

Hello,

Since you were originally considering use of the 9RS08KA2 device, I was assuming that you had already determined that an 8-pin package would provide sufficient I/O for your application.  Therefore, the 9S08QD2 seemed a good fit.  It is certainly rich in timers, with two separate TPM modules, with a total number of three channels available.  Each TPM module is much more flexible than the MTIM module within the KA2.  Since the QD2 device contains an ADC module, you won't really need a comparator facility.

In all probability, 2K of flash should be plenty, assuming any processing, outside of the RC5 output generation, is not extremely complex.  I can't imagine that it would be, considering the few pins available on the package.

If you require direct battery operation, perhaps from a single lithium cell, the QD2 may not be suitable.  Its minimum operating voltage is 2.7 volts, and you may need a device with a minimum limit of 1.8 volts.  If this is the case, you might consider the 8-pin version of the 9S08QG4 device, but it will likely be more expensive.

When assigning functions to the various pins of the QD2, allocate PTA0 to PTA3 first.  Allocate PTA4 (output only) last.  This will simplify the debug process, in that the BDM connections will remain clear if PTA4 and PTA5 are not used (refer to Fig. 2.2 within the data sheet).

Regards,

Mac

Message Edited by bigmac on 2008-02-14 03:29 AM

[abicash]

Hi, To answer JimDons query,Yes,the application demands being operated only with itself.So that there should be no interference from any Universal remotes,and vice versa.For this I plan to use an address/command which isnt used by any remote and I would be supplied with a UNiversal remote shortly,wherein I would be in a position to guess which addresses(32) or commands(64) are not used. @Bigmac:I was definitely considering the cheapest device offered since the whole Transmitter+Receiver+Pow Supply has to be not more than $2.For the receiver side therefore I chose the KA2 partly since the code was ready.I was planning for a PIC device on Transmitter side,PIC12F629 to be precise due to lower cost and Pincount.It has 1750 byte Flash and 64 byte RAM along with 2 timers,6 I/Os.So QD2 is somewhat similar (better) but for the Low voltage you mentioned!So QG4.But its got some things that I dont neeed like the ADC and enormous Flash/RAM.The KAx devices are absolutely suited for the application,but you really feel they wont be sufficient for transmission?.Today a Freescale Technical Support person is to meet me on this.Meanwhile I would really appreciate if you helped me more on this.Thanks and regards

Message Edited by abicash on 2008-02-14 06:31 AM

[bigmac]

Hello,

abicash wrote:
The KAx devices are absolutely suited for the application,but you really feel they wont be sufficient for transmission?

I am reasonably certain that it would be possible to build a transmitter using the KAx device.  But because of the very limited capability of the MTIM, in comparison with the TPM module, the use of timed firmware loops, using tight assembly code would be required, which you said you did not currently have the expertise to handle.

A few years back, I was able to use a HC705 device, a predecessor of the HC908 and 9S08 devices, for a similar purpose, for a proprietary IR coding scheme.  The device had only 1.2K of PROM, 64 bytes of RAM, and a single timer that was even less flexible than the MTIM.

Regards,

Mac

[abicash]

Hi all, The Freescale support person recommended a newer device QA4 which is quite similar to QGx,and promised a very good price for a package[a price with which I am extrememly happy] @oc2ucX: The projects very good.Maybe I can port it to RC5.Since you've written it in C,it may be helpful.Thanks @JimDon: I dont think thats a good idea.An extra device will eat space and money (even though its TSSOP and quite low priced)..Thanks anyway @Bigmac:It seems imperative that I use assembly if I were to use KA2 which ,again as I said earlier,doesnt sound a good idea for now atleast.Freescale support has assured a kickstart for this project and Codewarrior overall.But since QA devices are pretty new,Codewarrior doesnt seem to support it.Do you have idea how to use these if they are not supported by codewarrior? Meanwhile I am provided with two development boards,USBSPYDER08 and DEMO9RS08KASP v.1.00.Talk about support!I am also provided with loads of manuals and tech material.One of which has a 4-5 line explanation of a demo project resembling mine.It is using KA2 as IR transmitter,but without code or anything.So these two days I am spending on this material.Please provide any suggestions or additions.Thanks as usual

[JimDon]

Codewarrior support for a new device:

I once had this problem and support sent the files as the service pack was not yet ready for release due to other problems, but they had the support files for the device needed.

I suggest you enter a service request and see if  they are available.

As for the Spyder, I found that it worked fine (and fits in your pocket nicely), but it seems to single step the device very slowly compared to the P&E BDM.
If you don't already have on, mouser has a good price.
 841-USBMULTILINKBDME

While mouser does not seem to  be an FSL preferred vendor, on small quantities for prototyping (and perhaps larger quantities) they have never failed to have the best price. Plus you don't have to go thru a big deal as far as quotes, and they show you real prices upto 500 peices and some times more. I am a little guy and the treat much better then the traditional rep houses.

You could also get a DEMOJM or a DEMOQE, which will give you a full P&E BDM  AND will supply 3.3V to the boards. It's not in a nice case like the Multililnk, but the are only around 50.00 and are perfect for the bench (plus you also get a neat demo board in the bargain).

To further my previous point concerning protocols, if this does not have to work with other remotes, you are free to take short cuts that may speed your development. The SCI just makes things quicker, but in your case since you only need to send a single command, I don't thing this will be an issue. None the less, the is nothing magical about RC-5.





Message Edited by JimDon on 2008-02-15 11:30 AM

[abicash]

Hi JimDon, As for now, I am pretty happy with two dev boards which I have been supplied (DEMORS08KASP and USBSPYDER).Although the USBSPYDER has a QG4 device on it,contrary to the KA2 which I was expecting.Learning a few tricks.Monday/Tuesay,FSL has arranged a one day training.I have noticed a thing with USBSPYDER that its not recognised sometimes,and have to remove it and insert it and redo the connection process.Maybe some problems with Windows drivers or the USBcomm chip on board.Not an issue for the moment...I have opened a new project using the AN3402 MC9RS08KA2,compiled it and loaded it on the flash.But if i single-step it,I lose connection with board.One thing was conspicuous with its absense in the app note was BUS FREQUENCY DEclaration.Is it necessary if we are using ICS?

[abicash]

oops double post!

Message Edited by abicash on 2008-02-16 10:58 AM

[abicash]

So everything was ignorance on my part

Apology for the ignorant earlier post.

Understanding things now..will get back if have more queries/problems.

Thanks and regards

[bigmac]

Hello,

You might wish to consider the attached untested assembly code.  Compared with the HC908 and 9S08 devices, the 9RS08 is quite a challenge to code.  No interrupts in run mode, no nested sub-routines, no stack, and only a simple MTIM available for polled timing.

The MTIM overflow period corresponds with one half the RC5 bit period (actually 892 us).

Regards,

Mac