From tim at sabretechnology.co.uk Tue Sep 1 01:11:36 2009 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Sep 1 02:22:27 2009 Subject: [Icc-avr] Processor is going into a halt! Message-ID: <04671BB8D269034BBC4BB6BA894867261CB95B@sserver.SabreTechnology.local> ----Original Message---- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Jim Hatley Sent: 28 August 2009 16:23 To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: Re: [Icc-avr] Processor is going into a halt! > Hello Tim, > > I believe that the pull up on the USART receive line can > be controlled from the PORTx pin even if the USART is > enabled. > > See page 79 in the ATmega128(P) specification (revP 08/07 > version). Sorry, you're right. For some reason I thought I'd read that the RXD function completely disconnected the pin from IO. Should have read the data sheet! -- Tim Mitchell From info at spide.nl Wed Sep 2 00:43:39 2009 From: info at spide.nl (J.H. van der Spiegel) Date: Wed Sep 2 01:54:28 2009 Subject: SV: SV: [Icc-avr] Processor is going into a halt! In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA675852@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA67582D@seattle.ecpower.dk> <4A97C6D5.6030400@johnfromarran.org.uk> <072D96786BFC014AAEBA9EB07A8070EA67584D@seattle.ecpower.dk> <072D96786BFC014AAEBA9EB07A8070EA675852@seattle.ecpower.dk> Message-ID: Hi Steve, I've found that measuring voltage does not always work. The probe impedance (R / / C) is the cause I am told. You can then better with a flow sensor measuring the current in the track. You measure than through induction and the circuit is not affected. This method can also be used to measure ground and vcc noise. I hope that you can do with this suggestion..... Good luck Joop v.d. Spiegel -----Oorspronkelijk bericht----- Van: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] Namens Steven Lose Verzonden: zaterdag 29 augustus 2009 9:49 Aan: Johannes Assenbaum; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Onderwerp: SV: SV: SV: [Icc-avr] Processor is going into a halt! Hi Johannes. It's Interesting. I didn't pay that much attention on the 5V psu when I was at the site. I hope that the things I have done on the updated board in conjunction with the better casing will solve the case. I think Ill go to the site and do some more noise and OSC measurement. ( 7 Hour drive ) Thanks to everybody for inputs on this case. I'll get back with an update app. 3 weeks from now when I have the new pcb and have tested it at the site. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Johannes Assenbaum Sendt: 28. august 2009 21:03 Til: icc-avr@imagecraft.com Emne: Re: SV: SV: [Icc-avr] Processor is going into a halt! Hi Steven, I had similar with a tiny2313 soft-starting and -braking a motor by pwm just few days ago. Every now and then the AVR stopped working completely, including the watchdog. Clock was the internal RC osc in this case. It turned out, that due to a broken capacitor at input, vcc regulator got instable from braking noise on 12V power line, and I measured spikes of few microseconds upto 10V on vcc - which actually did not trash the chip. but "only" made it halt fully. In another case, from a customer I know, that his mega8 with external 8MHz XTAL osc in full-swing mode sometimes runs into general halt, too - in that case there is a high-power flashlight circuit just a few cm apart, and I'm suspicous, that very high di/dt influencing spikes on osc in/out (or vcc?) is the reason, even if controller pcb has a full gnd plane next to high-current circuit. I was thinking of those cases, as you told of the elevator control just behind the wall... Best regards, Johannes > Hi John. > You might be right, but how come that processor is resuming operation without > booting, just by pulling that Rx pin down? > That's what puzzles me. > I haven't tried pulling other pins down to see it that would have the same effect. > Med venlig hilsen / Best regards / mit freundlichen Gr??en > EC POWER A/S > Steven Lose > Software Ingeni?r > Tlf.: +45 87434100 > Direkte tlf. +45 58286608 > Email: sl@ecpower.dk > www.ecpower.dk > -----Oprindelig meddelelse----- > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? > vegne af John Baraclough > Sendt: 28. august 2009 14:00 > Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to > icc-announce if you are a member of this. > Emne: Re: SV: [Icc-avr] Processor is going into a halt! > Hi Steven, > I suspect that crystal sharing is at the root of your problem. A track > 70mm long will have a significant on the capacitance at the XTAL2 pin. > Easily enough to stop the oscillator. If you need to do that you should > use an external encapsulated oscillator driving both XTAL1 pins as is > done in the STK500, however you will probably fix the situation by using > two separate crystals. > All the best for now, > John > Steven Lose wrote: >> Hi. >> >> Yes, I have tried with an JTAG ICE II, and AVR STUDIO 4.17 >> Normally this fault will appear within minutes or a few Hours, but when I put the >> JTAG on, it run 14 Hours straight, and I then decided to take it off again. >> >> The Crystal (8MHz) is close to the processor with gnd around and in the layer >> below. >> So far it's normal, but there is a second processor (ATMEGA 8) that gets its clock >> from the same crystal by connecting the XTAL2 of the MEGA128 to the XTAL1 on the >> MEGA8. the track is running on top and Button layer passing 2 via's with gnd on >> the layer just below all the way. >> Track distance is approximate 70mm. >> >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr __________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4387 (20090901) __________ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.eset.com __________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4387 (20090901) __________ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.eset.com __________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4387 (20090901) __________ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.eset.com From sl at ecpower.dk Wed Sep 2 22:33:03 2009 From: sl at ecpower.dk (Steven Lose) Date: Wed Sep 2 23:43:57 2009 Subject: SV: SV: SV: [Icc-avr] Processor is going into a halt! In-Reply-To: References: <072D96786BFC014AAEBA9EB07A8070EA67582D@seattle.ecpower.dk><4A97C6D5.6030400@johnfromarran.org.uk><072D96786BFC014AAEBA9EB07A8070EA67584D@seattle.ecpower.dk><072D96786BFC014AAEBA9EB07A8070EA675852@seattle.ecpower.dk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA675A5F@seattle.ecpower.dk> Hi Joop. Measuring with probe is not an easy thing, but using a pick up coil is also a bit tricky. I have a coil probe and I have used it before to locate noise. It can tell me if there is noise on an area of a pcb, but not point out a specific track. But it can tell me if the osc is running or not. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af J.H. van der Spiegel Sendt: 2. september 2009 09:44 Til: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribetoicc-announce if you are a member of this.' Emne: RE: SV: SV: [Icc-avr] Processor is going into a halt! Hi Steve, I've found that measuring voltage does not always work. The probe impedance (R / / C) is the cause I am told. You can then better with a flow sensor measuring the current in the track. You measure than through induction and the circuit is not affected. This method can also be used to measure ground and vcc noise. I hope that you can do with this suggestion..... Good luck Joop v.d. Spiegel -----Oorspronkelijk bericht----- Van: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] Namens Steven Lose Verzonden: zaterdag 29 augustus 2009 9:49 Aan: Johannes Assenbaum; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this. Onderwerp: SV: SV: SV: [Icc-avr] Processor is going into a halt! Hi Johannes. It's Interesting. I didn't pay that much attention on the 5V psu when I was at the site. I hope that the things I have done on the updated board in conjunction with the better casing will solve the case. I think Ill go to the site and do some more noise and OSC measurement. ( 7 Hour drive ) Thanks to everybody for inputs on this case. I'll get back with an update app. 3 weeks from now when I have the new pcb and have tested it at the site. Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Johannes Assenbaum Sendt: 28. august 2009 21:03 Til: icc-avr@imagecraft.com Emne: Re: SV: SV: [Icc-avr] Processor is going into a halt! Hi Steven, I had similar with a tiny2313 soft-starting and -braking a motor by pwm just few days ago. Every now and then the AVR stopped working completely, including the watchdog. Clock was the internal RC osc in this case. It turned out, that due to a broken capacitor at input, vcc regulator got instable from braking noise on 12V power line, and I measured spikes of few microseconds upto 10V on vcc - which actually did not trash the chip. but "only" made it halt fully. In another case, from a customer I know, that his mega8 with external 8MHz XTAL osc in full-swing mode sometimes runs into general halt, too - in that case there is a high-power flashlight circuit just a few cm apart, and I'm suspicous, that very high di/dt influencing spikes on osc in/out (or vcc?) is the reason, even if controller pcb has a full gnd plane next to high-current circuit. I was thinking of those cases, as you told of the elevator control just behind the wall... Best regards, Johannes > Hi John. > You might be right, but how come that processor is resuming operation without > booting, just by pulling that Rx pin down? > That's what puzzles me. > I haven't tried pulling other pins down to see it that would have the same effect. > Med venlig hilsen / Best regards / mit freundlichen Gr??en > EC POWER A/S > Steven Lose > Software Ingeni?r > Tlf.: +45 87434100 > Direkte tlf. +45 58286608 > Email: sl@ecpower.dk > www.ecpower.dk > -----Oprindelig meddelelse----- > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? > vegne af John Baraclough > Sendt: 28. august 2009 14:00 > Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to > icc-announce if you are a member of this. > Emne: Re: SV: [Icc-avr] Processor is going into a halt! > Hi Steven, > I suspect that crystal sharing is at the root of your problem. A track > 70mm long will have a significant on the capacitance at the XTAL2 pin. > Easily enough to stop the oscillator. If you need to do that you should > use an external encapsulated oscillator driving both XTAL1 pins as is > done in the STK500, however you will probably fix the situation by using > two separate crystals. > All the best for now, > John > Steven Lose wrote: >> Hi. >> >> Yes, I have tried with an JTAG ICE II, and AVR STUDIO 4.17 >> Normally this fault will appear within minutes or a few Hours, but when I put the >> JTAG on, it run 14 Hours straight, and I then decided to take it off again. >> >> The Crystal (8MHz) is close to the processor with gnd around and in the layer >> below. >> So far it's normal, but there is a second processor (ATMEGA 8) that gets its clock >> from the same crystal by connecting the XTAL2 of the MEGA128 to the XTAL1 on the >> MEGA8. the track is running on top and Button layer passing 2 via's with gnd on >> the layer just below all the way. >> Track distance is approximate 70mm. >> >> > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr __________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4387 (20090901) __________ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.eset.com __________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4387 (20090901) __________ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.eset.com __________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4387 (20090901) __________ Het bericht is gecontroleerd door ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From danar at astrixnet.com Fri Sep 4 08:03:59 2009 From: danar at astrixnet.com (Dana Raymond) Date: Fri Sep 4 09:14:50 2009 Subject: [Icc-avr] RE: Processor is going into a halt! In-Reply-To: <200909031900.n83J02d5043122@mail.imagecraft.com> References: <200909031900.n83J02d5043122@mail.imagecraft.com> Message-ID: Locating noise can be challenging for sure. What is usually needed is a good toolbox of equipment. I've used a differential probe and good quality scope. But, I think adopting "good" noise abatement practices has probably been the most fruitful approach. Much of my career has been designing embedded systems for industrial environments, which are usually noisy. There are habits I have adopted that have probably saved hundreds or thousands of hours overall. If you hit a brick wall with this issue you may consider consulting one of the labs that specialize in EMI/RFI compliance testing. Of course that takes a few bucks, but in my experience they will not only locate issues but provide expert assistance as well. From paul.aa9gg at gmail.com Fri Sep 4 08:26:55 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Fri Sep 4 09:37:45 2009 Subject: [Icc-avr] RE: Processor is going into a halt! In-Reply-To: References: <200909031900.n83J02d5043122@mail.imagecraft.com> Message-ID: <20f5efc40909040826r791124dehda92d1c56f11f8be@mail.gmail.com> Murata makes some nice small i/o and power emi filters. On Fri, Sep 4, 2009 at 10:03 AM, Dana Raymond wrote: > Locating noise can be challenging for sure. What is usually needed is a good > toolbox of equipment. I've used a differential probe and good quality scope. > > But, I think adopting "good" noise abatement practices has probably been the > most fruitful approach. Much of my career has been designing embedded > systems for industrial environments, which are usually noisy. There are > habits I have adopted that have probably saved hundreds or thousands of > hours overall. > > If you hit a brick wall with this issue you may consider consulting one of > the labs that specialize in EMI/RFI compliance testing. Of course that takes > a few bucks, but in my experience they will not only locate issues but > provide expert assistance as well. > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com NAQCC 3123, SKCC 4628, FPQRP 2003, CW 29 From jassenbaum at htp-tel.de Fri Sep 4 17:18:46 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Sep 4 18:29:38 2009 Subject: [Icc-avr] io header files update References: Message-ID: Hi all, there are new io header files and updates available at http://avr.jassenbaum.de/iccv7avr/index.html After IccAVR 7.22B there are: Changes by 2009-09-02 - new: header files for ATMega16M1 - update: header files for ATMega32/64M1 changed to meet new M1-only datasheet Changes by 2009-08-26 - new: header files for ATtiny4/5/9 (asm only) - fix: in iot85v.h wrong sub header file was included Changes by 2009-08-25 - fix: changed interrupt vector space to 32bit for AT90USB82/ATMega8U2 Changes by 2009-08-20 - update: added error "ATxmega128A1_revD is outdated ..." to iccioavr.h and removed ioxm128A1revDv.h from latest_ioh archive Best regards, Johannes From sl at ecpower.dk Sun Sep 6 23:23:44 2009 From: sl at ecpower.dk (Steven Lose) Date: Mon Sep 7 00:34:48 2009 Subject: SV: [Icc-avr] RE: Processor is going into a halt! In-Reply-To: References: <200909031900.n83J02d5043122@mail.imagecraft.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA675B45@seattle.ecpower.dk> Hi. I think the pcb design is already well protected with filters on both IO and Mains. It has also passed all EMI test, T?V test and so on. But yes, a test company must also be able to tell me at which noise level it will fail. Just turn up the noise until it fails. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Dana Raymond Sendt: 4. september 2009 17:04 Til: icc-avr@imagecraft.com Emne: [Icc-avr] RE: Processor is going into a halt! Locating noise can be challenging for sure. What is usually needed is a good toolbox of equipment. I've used a differential probe and good quality scope. But, I think adopting "good" noise abatement practices has probably been the most fruitful approach. Much of my career has been designing embedded systems for industrial environments, which are usually noisy. There are habits I have adopted that have probably saved hundreds or thousands of hours overall. If you hit a brick wall with this issue you may consider consulting one of the labs that specialize in EMI/RFI compliance testing. Of course that takes a few bucks, but in my experience they will not only locate issues but provide expert assistance as well. _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From Pirsch at SynenTec.com Mon Sep 7 04:59:00 2009 From: Pirsch at SynenTec.com (Matthias Pirsch) Date: Mon Sep 7 06:09:58 2009 Subject: [Icc-avr] Qdec on xmega Message-ID: Hi, I was Trying to expand the 16 Bit qdec on atxmega to 32 Bit. Using the event channel as a source for the second Timer only allowed to count up witch makes no sense with a motor that moves ccw and cw. The next approach was the use the OVF interrupt on the qdec Timer and read out the DIR Bit in the CTRLFSET or CLR register for that timer to increment/decrement the upper 16 Bit. But there was a undeterministic behavior from the isr that serves the interrupt. Does anybody have a approach for that problem ???? Regards Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090907/e076454d/attachment.html From petolachka at abv.bg Sun Sep 13 22:36:28 2009 From: petolachka at abv.bg (Zlaty Lambov) Date: Sun Sep 13 23:44:20 2009 Subject: [Icc-avr] bootloader problem Message-ID: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> Hi! I have a problem with ICCAVR v7.14B professional.I use Atmega 2561.The following bootloader code work OK in Atmega 128 ,but it doesn't work in Atmega 2561(the bootloader can't write in flash).Please help me to find the problem.Here is my code: //******************************************************************************************** .text SPMCR = 0x68 ; void write_fpage (unsigned int adr, unsigned char function); ; bits 8:15 adr addresses the page...(must setup RAMPZ beforehand!!!) _write_fpage:: XCALL __WAIT_SPMEN__ MOV R31,R17 MOV R30,R16 ;move address to z pointer (R31=ZH R30=ZL) STS SPMCR,R18 ;argument 2 decides function SPM ;perform pagewrite RET ; void fill_temp_buffer (unsigned int data, unsigned int adr); ; bits 7:1 in adr addresses the word in the page... (2=first word, 4=second word etc..) _fill_temp_buffer:: XCALL __WAIT_SPMEN__ MOV R31,R19 MOV R30,R18 ;move adress to z pointer (R31=ZH R30=ZL) MOV R1,R17 MOV R0,R16 ;move data to reg 0 and 1 LDI R19,0x01 STS SPMCR,R19 SPM ;Store program memory RET ;unsigned int read_program_memory (unsigned int adr ,unsigned char cmd); _read_program_memory:: MOV R31,R17 ;R31=ZH R30=ZL MOV R30,R16 ;move adress to z pointer SBRC R18,0 ;read lockbits? (second argument=0x09) STS SPMCR,R18 ;if so, place second argument in SPMEN register ELPM ;read LSB MOV R16,R0 INC R30 ELPM MOV R17,R0 ;read MSB (ignored when reading lockbits) RET ;void write_lock_bits (unsigned char val); _write_lock_bits:: MOV R0,R16 LDI R17,0x09 STS SPMCR,R17 SPM ;write lockbits RET _enableRWW:: XCALL __WAIT_SPMEN__ LDI R27,0x11 STS SPMCR,R27 SPM RET __WAIT_SPMEN__: LDS R27,SPMCR ; load SPMCR to R27 SBRC R27,0 ; check SPMEN flag RJMP __WAIT_SPMEN__ ; wait for SPMEN flag cleared RET //******************************************************************************************** Best regards, Zlati Lambov From jassenbaum at htp-tel.de Mon Sep 14 11:50:30 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Mon Sep 14 13:01:32 2009 Subject: [Icc-avr] bootloader problem References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> Message-ID: Did you rebuild the project (by menu) after changing the target? Best regards, Johannes > Hi! > I have a problem with ICCAVR v7.14B professional.I use Atmega 2561.The following > bootloader code work OK in Atmega 128 ,but it doesn't work in Atmega 2561(the > bootloader can't write in flash).Please help me to find the problem.Here is my > code: > //********************************************************************************* > *********** > .text > SPMCR = 0x68 > ; void write_fpage (unsigned int adr, unsigned char function); > ; bits 8:15 adr addresses the page...(must setup RAMPZ beforehand!!!) > _write_fpage:: > XCALL __WAIT_SPMEN__ > MOV R31,R17 > MOV R30,R16 ;move address to z pointer (R31=ZH R30=ZL) > STS SPMCR,R18 ;argument 2 decides function > SPM ;perform pagewrite > RET > ; void fill_temp_buffer (unsigned int data, unsigned int adr); > ; bits 7:1 in adr addresses the word in the page... (2=first word, 4=second word > etc..) > _fill_temp_buffer:: > XCALL __WAIT_SPMEN__ > MOV R31,R19 > MOV R30,R18 ;move adress to z pointer (R31=ZH R30=ZL) > MOV R1,R17 > MOV R0,R16 ;move data to reg 0 and 1 > LDI R19,0x01 > STS SPMCR,R19 > SPM ;Store program memory > RET > ;unsigned int read_program_memory (unsigned int adr ,unsigned char cmd); > _read_program_memory:: > MOV R31,R17 ;R31=ZH R30=ZL > MOV R30,R16 ;move adress to z pointer > SBRC R18,0 ;read lockbits? (second argument=0x09) > STS SPMCR,R18 ;if so, place second argument in SPMEN register > ELPM ;read LSB > MOV R16,R0 > INC R30 > ELPM > MOV R17,R0 ;read MSB (ignored when reading lockbits) > RET > ;void write_lock_bits (unsigned char val); > _write_lock_bits:: > MOV R0,R16 > LDI R17,0x09 > STS SPMCR,R17 > SPM ;write lockbits > RET > _enableRWW:: > XCALL __WAIT_SPMEN__ > LDI R27,0x11 > STS SPMCR,R27 > SPM > RET > __WAIT_SPMEN__: > LDS R27,SPMCR ; load SPMCR to R27 > SBRC R27,0 ; check SPMEN flag > RJMP __WAIT_SPMEN__ ; wait for SPMEN flag cleared > RET > //********************************************************************************* > *********** > Best regards, > Zlati Lambov > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From amsol at amssolutions.co.za Tue Sep 15 21:36:16 2009 From: amsol at amssolutions.co.za (Gerhard at AMS Solutions) Date: Tue Sep 15 22:47:24 2009 Subject: [Icc-avr] KeeLoQ - Atmel Appl? References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> Message-ID: <003b01ca3687$3aa61c10$1f00a8c0@XPSP2> Hi Group, Has anyone here done a software decryption using Atmel and microchip KEELOQ HCS3(xx) eg HCS300 and are prepare to assist or share code etc. I want to use atmel, since all my dev tools (yes ICCAVR....) are in place. Any feedback will be appreciated! Regards, Gerhard Laubscher AMS Solutions....... Electronic System design made easy Telp : +27 21 557 0160 Cell : 082 366 1950 eMail : amsol@amssolutions.co.za Skype : gerhardjl Website : http://www.amssolutions.co.za PO Box 132, Table View, 7439 Cape Town South Africa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090916/acceec98/attachment.html From sl at ecpower.dk Thu Sep 17 00:58:20 2009 From: sl at ecpower.dk (Steven Lose) Date: Thu Sep 17 02:09:35 2009 Subject: [Icc-avr] Maxim DS1388 I2C RTC and WDT Message-ID: <072D96786BFC014AAEBA9EB07A8070EA6761A4@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090917/a1b9b3fa/attachment.jpe From paul.aa9gg at gmail.com Thu Sep 17 07:53:31 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Sep 17 09:04:39 2009 Subject: [Icc-avr] Maxim DS1388 I2C RTC and WDT In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA6761A4@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA6761A4@seattle.ecpower.dk> Message-ID: <20f5efc40909170753n47f933b4mcaade1cf33265deb@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: not available Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090917/f83423a0/attachment.jpe From sl at ecpower.dk Thu Sep 17 10:11:37 2009 From: sl at ecpower.dk (Steven Lose) Date: Thu Sep 17 11:22:48 2009 Subject: SV: [Icc-avr] Maxim DS1388 I2C RTC and WDT In-Reply-To: <20f5efc40909170753n47f933b4mcaade1cf33265deb@mail.gmail.com> References: <072D96786BFC014AAEBA9EB07A8070EA6761A4@seattle.ecpower.dk> <20f5efc40909170753n47f933b4mcaade1cf33265deb@mail.gmail.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA676231@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image004.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090917/135e954b/attachment-0002.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image001.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090917/135e954b/attachment-0003.jpe From paul.aa9gg at gmail.com Thu Sep 17 10:38:48 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Sep 17 11:49:56 2009 Subject: [Icc-avr] Maxim DS1388 I2C RTC and WDT In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA676231@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA6761A4@seattle.ecpower.dk> <20f5efc40909170753n47f933b4mcaade1cf33265deb@mail.gmail.com> <072D96786BFC014AAEBA9EB07A8070EA676231@seattle.ecpower.dk> Message-ID: <20f5efc40909171038y790340b5rdc9fc5142b4fd8de@mail.gmail.com> Yes... I have seen that before. You must clear the flags before you can enable things. Glad you figured it out, datasheets can be so cryptic at times. On Thu, Sep 17, 2009 at 12:11 PM, Steven Lose wrote: > Hi Poul. > > > > Yes it should be straight forward, and it also was for the RTC part. > > But the WDT was a bit tricky. After disabling the WDT and writing the > desired timer value, the WDT should be enabled by writing to the control > register. > > Bit 1 is WDT enable; Bit 0 enables the WDT to pull the Reset pin when the > WDT reaches 0. > > > > No problem on setting bit 1 and verify that the WDT was counting, but > writing 0x03 to the control register so it would also pull the reset pin, > returned a NACK. > > > > Anyway, I found a solution. Before writing 0x03 to the control register, I > write 0 to the Flag register, and everything works! > > > > I just can?t see anything in the datasheet that tells me to do so. > > > > > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > *EC POWER A/S* > > *Steven Lose* > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > > > ------------------------------ > > *Fra:* icc-avr-bounces@imagecraft.com [mailto: > icc-avr-bounces@imagecraft.com] *P? vegne af *Paul Mateer > *Sendt:* 17. september 2009 16:54 > *Til:* Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > *Emne:* Re: [Icc-avr] Maxim DS1388 I2C RTC and WDT > > > > Seems pretty straight forward. What's the problem? > > On Thu, Sep 17, 2009 at 2:58 AM, Steven Lose wrote: > > Hi. > > > > Is there anyone here that has experience with this part? > > If, yes. Anyone using the WDT? > > > > > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > *EC POWER A/S* > > *Steven Lose* > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > > > > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > NAQCC 3123, SKCC 4628, FPQRP 2003, CW 29 > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com NAQCC 3123, SKCC 4628, FPQRP 2003, CW 29 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090917/aa7a6cf1/attachment.html From sl at ecpower.dk Thu Sep 17 12:36:17 2009 From: sl at ecpower.dk (Steven Lose) Date: Thu Sep 17 13:47:28 2009 Subject: SV: [Icc-avr] Maxim DS1388 I2C RTC and WDT In-Reply-To: <20f5efc40909171038y790340b5rdc9fc5142b4fd8de@mail.gmail.com> References: <072D96786BFC014AAEBA9EB07A8070EA6761A4@seattle.ecpower.dk><20f5efc40909170753n47f933b4mcaade1cf33265deb@mail.gmail.com><072D96786BFC014AAEBA9EB07A8070EA676231@seattle.ecpower.dk> <20f5efc40909171038y790340b5rdc9fc5142b4fd8de@mail.gmail.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA676233@seattle.ecpower.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2650 bytes Desc: image002.jpg Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090917/cc2be623/attachment.jpe From amsol at amssolutions.co.za Mon Sep 21 05:18:33 2009 From: amsol at amssolutions.co.za (Gerhard at AMS Solutions) Date: Mon Sep 21 06:29:39 2009 Subject: [Icc-avr] help > TIMR > M16 References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> <003b01ca3687$3aa61c10$1f00a8c0@XPSP2> Message-ID: <00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2> Hi Group, ?Please help? On a Mega16, I wish to configure eg Timr0 for 'Auto Reload' Mega16 configured for internal RC Osc = 8Mhz Pre_Scale to 8 Timing period required = 120uSec I am considering this init_proc for TIMR0 Config (8-bit auto reload) - void init_timr0(void) { CLI(); //dis all Interrupts TCCR0=0x00; //stop timer TCNT0=0x00; // timr0 Count = 0 OCR0=120; // OutPutCompare0 8mhz/8 = 1mhz this period=1us, therefor 120=120uSec? OCIE0=1; // enable timer0 'Output Compare' match interrupt SEI(); //enable interrupts TCCR0=0b00011010; // Timer0 Started with > Timr0=prescale 8 / CTC mode / OC0 toggle } I assume now that with Timer0 enabled, TCNT0 will increment with every pre-scale(div8) clock-pulse (1us) When TCNT0 value reaches OCR0 (120) an Output Compare Intr is executed.... TCNT0 is cleared to 0 once the ISR is executed.... ? ------Interrupt Service Routine ----- #pragma interrupt_handler TIMR0:20 //timer0 Compare Vector.... ? void TIMR0(void) { // execute local ISR } //end TIMR0 Is this about correct? Am I missing something? Thank you for your valued feedback. Regards, Gerhard Laubscher AMS Solutions....... Electronic System design made easy Telp : +27 21 557 0160 Cell : 082 366 1950 eMail : amsol@amssolutions.co.za Skype : gerhardjl Website : http://www.amssolutions.co.za PO Box 132, Table View, 7439 Cape Town South Africa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090921/b359c515/attachment.html From design at johnfromarran.org.uk Mon Sep 21 06:10:44 2009 From: design at johnfromarran.org.uk (John Baraclough) Date: Mon Sep 21 07:22:01 2009 Subject: [Icc-avr] help > TIMR > M16 In-Reply-To: <00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2> References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> <003b01ca3687$3aa61c10$1f00a8c0@XPSP2> <00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2> Message-ID: <4AB77B54.70200@johnfromarran.org.uk> Hi Gerhard, That looks fine to me and should work OK. All the best for now, John Gerhard at AMS Solutions wrote: > Hi Group, > ?Please help? > On a Mega16, I wish to configure eg Timr0 for 'Auto Reload' > Mega16 configured for internal RC Osc = 8Mhz > Pre_Scale to 8 > Timing period required = 120uSec > > I am considering this init_proc for TIMR0 Config (8-bit auto reload) - > > void init_timr0(void) > { > CLI(); //dis all Interrupts > TCCR0=0x00; //stop timer > TCNT0=0x00; // timr0 Count = 0 > OCR0=120; // OutPutCompare0 8mhz/8 = 1mhz this period=1us, > therefor 120=120uSec? > OCIE0=1; // enable timer0 'Output Compare' match interrupt > SEI(); //enable interrupts > TCCR0=0b00011010; // Timer0 Started with > Timr0=prescale 8 / CTC > mode / OC0 toggle > } > > I assume now that with Timer0 enabled, > TCNT0 will increment with every pre-scale(div8) clock-pulse (1us) > When TCNT0 value reaches OCR0 (120) an Output Compare Intr is executed.... > TCNT0 is cleared to 0 once the > ISR is executed.... ? > > > ------Interrupt Service Routine ----- > #pragma interrupt_handler TIMR0:20 //timer0 Compare Vector.... ? > void TIMR0(void) > { > // execute local ISR > } //end TIMR0 > > > Is this about correct? > Am I missing something? > > Thank you for your valued feedback. > > Regards, > Gerhard Laubscher > AMS Solutions....... Electronic System design made easy > Telp : +27 21 557 0160 Cell : 082 366 1950 > eMail : amsol@amssolutions.co.za > Skype : gerhardjl > Website : http://www.amssolutions.co.za > PO Box 132, Table View, 7439 > Cape Town > South Africa > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From paul.aa9gg at gmail.com Mon Sep 21 06:49:51 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Mon Sep 21 08:01:03 2009 Subject: [Icc-avr] help > TIMR > M16 In-Reply-To: <4AB77B54.70200@johnfromarran.org.uk> References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> <003b01ca3687$3aa61c10$1f00a8c0@XPSP2> <00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2> <4AB77B54.70200@johnfromarran.org.uk> Message-ID: <20f5efc40909210649m340a24ecpdcaea9c967bb04cc@mail.gmail.com> Don't forget to enable the interrupts via TIMSK ? Timer/Counter Interrupt Mask Register On Mon, Sep 21, 2009 at 8:10 AM, John Baraclough wrote: > Hi Gerhard, > > That looks fine to me and should work OK. > > All the best for now, > John > > > Gerhard at AMS Solutions wrote: >> >> Hi Group, >> ?Please help? >> On a Mega16, I wish to configure eg Timr0 for 'Auto Reload' >> Mega16 configured for internal RC Osc = 8Mhz >> Pre_Scale to 8 >> Timing period required = 120uSec >> ?I am considering this init_proc for TIMR0 Config (8-bit auto reload) - >> ?void init_timr0(void) >> ?{ >> ? CLI(); ? ? ? ? ? ?//dis all Interrupts >> ? TCCR0=0x00; ?//stop timer >> ? TCNT0=0x00; ?// timr0 Count = 0 >> ? OCR0=120; ? ? // OutPutCompare0 8mhz/8 = 1mhz this period=1us, therefor >> 120=120uSec? >> ? OCIE0=1; ? ? ? // enable timer0 'Output Compare' match interrupt >> ? SEI(); ? ? ? ? ? //enable interrupts >> ? TCCR0=0b00011010; // Timer0 Started with > Timr0=prescale 8 / ?CTC mode >> / OC0 toggle >> ?} >> ??I assume now that with Timer0 enabled, >> ?TCNT0 will increment with every pre-scale(div8) clock-pulse (1us) >> When TCNT0 value reaches OCR0 (120) an Output Compare Intr is executed.... >> TCNT0 is cleared to 0 once the >> ISR is executed.... ? >> ??------Interrupt Service Routine ----- >> #pragma interrupt_handler TIMR0:20 //timer0 Compare Vector.... ? >> ?void TIMR0(void) >> ?{ >> ? ?// execute local ISR >> ?} //end TIMR0 >> ??Is this about correct? >> Am I missing something? >> ?Thank you for your valued feedback. >> ?Regards, >> Gerhard Laubscher >> AMS Solutions....... Electronic System design made easy >> Telp : +27 21 557 0160 ?Cell : 082 366 1950 >> eMail : amsol@amssolutions.co.za >> ?Skype : gerhardjl >> Website : http://www.amssolutions.co.za >> PO Box 132, Table View, 7439 >> Cape Town >> South Africa >> >> ?????------------------------------------------------------------------------ >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com NAQCC 3123, SKCC 4628, FPQRP 2003, CW 29 From dsmith at medeco.com Mon Sep 21 07:00:15 2009 From: dsmith at medeco.com (David Smith) Date: Mon Sep 21 08:11:28 2009 Subject: [Icc-avr] help > TIMR > M16 References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg><003b01ca3687$3aa61c10$1f00a8c0@XPSP2><00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2><4AB77B54.70200@johnfromarran.org.uk> <20f5efc40909210649m340a24ecpdcaea9c967bb04cc@mail.gmail.com> Message-ID: I think Paul hit your problem on the head. It looks like in your code that you are saying ... >> OCIE0=1; // enable timer0 'Output Compare' match interrupt If you haven't redefined OCIE0 to be a bitfield or something and are using it as defined in the mega16 header file, this is probably where your problem is. The header defines it as #define OCIE0 1 Which is the bit position in the TIMSK register. To set it, you need to do something like the following ... TIMSK |= (1< TIMR > M16 Don't forget to enable the interrupts via TIMSK - Timer/Counter Interrupt Mask Register On Mon, Sep 21, 2009 at 8:10 AM, John Baraclough wrote: > Hi Gerhard, > > That looks fine to me and should work OK. > > All the best for now, > John > > > Gerhard at AMS Solutions wrote: >> >> Hi Group, >> ?Please help? >> On a Mega16, I wish to configure eg Timr0 for 'Auto Reload' >> Mega16 configured for internal RC Osc = 8Mhz >> Pre_Scale to 8 >> Timing period required = 120uSec >> ?I am considering this init_proc for TIMR0 Config (8-bit auto reload) - >> ?void init_timr0(void) >> ?{ >> ? CLI(); ? ? ? ? ? ?//dis all Interrupts >> ? TCCR0=0x00; ?//stop timer >> ? TCNT0=0x00; ?// timr0 Count = 0 >> ? OCR0=120; ? ? // OutPutCompare0 8mhz/8 = 1mhz this period=1us, therefor >> 120=120uSec? >> ? OCIE0=1; ? ? ? // enable timer0 'Output Compare' match interrupt >> ? SEI(); ? ? ? ? ? //enable interrupts >> ? TCCR0=0b00011010; // Timer0 Started with > Timr0=prescale 8 / ?CTC mode >> / OC0 toggle >> ?} >> ??I assume now that with Timer0 enabled, >> ?TCNT0 will increment with every pre-scale(div8) clock-pulse (1us) >> When TCNT0 value reaches OCR0 (120) an Output Compare Intr is executed.... >> TCNT0 is cleared to 0 once the >> ISR is executed.... ? >> ??------Interrupt Service Routine ----- >> #pragma interrupt_handler TIMR0:20 //timer0 Compare Vector.... ? >> ?void TIMR0(void) >> ?{ >> ? ?// execute local ISR >> ?} //end TIMR0 >> ??Is this about correct? >> Am I missing something? >> ?Thank you for your valued feedback. >> ?Regards, >> Gerhard Laubscher >> AMS Solutions....... Electronic System design made easy >> Telp : +27 21 557 0160 ?Cell : 082 366 1950 >> eMail : amsol@amssolutions.co.za >> ?Skype : gerhardjl >> Website : http://www.amssolutions.co.za >> PO Box 132, Table View, 7439 >> Cape Town >> South Africa >> >> ?????------------------------------------------------------------------------ >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com NAQCC 3123, SKCC 4628, FPQRP 2003, CW 29 _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From bgarner at fhrd.net Mon Sep 21 07:51:07 2009 From: bgarner at fhrd.net (Bobby Garner) Date: Mon Sep 21 09:02:21 2009 Subject: [Icc-avr] help > TIMR > M16 In-Reply-To: <4AB77B54.70200@johnfromarran.org.uk> References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg> <003b01ca3687$3aa61c10$1f00a8c0@XPSP2> <00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2> <4AB77B54.70200@johnfromarran.org.uk> Message-ID: <4AB792DB.7040108@fhrd.net> However, the request for help implies that it is not performing to expectations. What seems to be the problem? Is the DDR bit for the OC0 output pin 'set'? Bobby Garner John Baraclough wrote: > Hi Gerhard, > > That looks fine to me and should work OK. > > All the best for now, > John > > > Gerhard at AMS Solutions wrote: >> Hi Group, >> ?Please help? >> On a Mega16, I wish to configure eg Timr0 for 'Auto Reload' >> Mega16 configured for internal RC Osc = 8Mhz >> Pre_Scale to 8 >> Timing period required = 120uSec >> >> I am considering this init_proc for TIMR0 Config (8-bit auto reload) - >> >> void init_timr0(void) >> { >> CLI(); //dis all Interrupts >> TCCR0=0x00; //stop timer >> TCNT0=0x00; // timr0 Count = 0 >> OCR0=120; // OutPutCompare0 8mhz/8 = 1mhz this period=1us, >> therefor 120=120uSec? >> OCIE0=1; // enable timer0 'Output Compare' match interrupt >> SEI(); //enable interrupts >> TCCR0=0b00011010; // Timer0 Started with > Timr0=prescale 8 / CTC >> mode / OC0 toggle >> } >> >> I assume now that with Timer0 enabled, >> TCNT0 will increment with every pre-scale(div8) clock-pulse (1us) >> When TCNT0 value reaches OCR0 (120) an Output Compare Intr is >> executed.... >> TCNT0 is cleared to 0 once the >> ISR is executed.... ? >> >> >> ------Interrupt Service Routine ----- >> #pragma interrupt_handler TIMR0:20 //timer0 Compare Vector.... ? >> void TIMR0(void) >> { >> // execute local ISR >> } //end TIMR0 >> >> >> Is this about correct? >> Am I missing something? >> >> Thank you for your valued feedback. >> >> Regards, >> Gerhard Laubscher >> AMS Solutions....... Electronic System design made easy >> Telp : +27 21 557 0160 Cell : 082 366 1950 >> eMail : amsol@amssolutions.co.za >> Skype : gerhardjl >> Website : http://www.amssolutions.co.za >> PO Box 132, Table View, 7439 >> Cape Town >> South Africa >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090921/c3776cb9/attachment-0001.html From amsol at amssolutions.co.za Mon Sep 21 08:29:12 2009 From: amsol at amssolutions.co.za (Gerhard at AMS Solutions) Date: Mon Sep 21 09:40:15 2009 Subject: [Icc-avr] help > TIMR > M16 References: <1165247860.65128.1252906588936.JavaMail.apache@mail34.abv.bg><003b01ca3687$3aa61c10$1f00a8c0@XPSP2><00aa01ca3ab5$a31feaf0$1f00a8c0@XPSP2><4AB77B54.70200@johnfromarran.org.uk><20f5efc40909210649m340a24ecpdcaea9c967bb04cc@mail.gmail.com> Message-ID: <013d01ca3ad0$4545a080$1f00a8c0@XPSP2> Hi Group, Thank you for your helpful feedback! I am testing and will get back to you re my results. Thanks for the hint re TIMSK and OCEI0. Regards,Gerhard Laubscher AMS Solutions....... Electronic System design made easy Telp : +27 21 557 0160 Cell : 082 366 1950 eMail : amsol@amssolutions.co.za Skype : gerhardjl Website : http://www.amssolutions.co.za PO Box 132, Table View, 7439 Cape Town South Africa ----- Original Message ----- From: David Smith To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090921/15d6ba91/attachment.html From bobgardner at aol.com Fri Sep 25 17:33:40 2009 From: bobgardner at aol.com (bobgardner@aol.com) Date: Fri Sep 25 18:45:04 2009 Subject: [Icc-avr] version number Message-ID: <8CC0C582116D9C3-1810-9D73@webmail-d006.sysops.aol.com> Hello fellow iccavr users. I have noticed that the map file generated by the the 7.22b compiler?says it was generated by version 7.22a. Not a big deal, but I've been dinged more than once by some sw qc weenie that insists on having stuff like that recorded for all posterity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090925/3497955c/attachment.html From richard at imagecraft.com Fri Sep 25 23:16:52 2009 From: richard at imagecraft.com (Richard Man) Date: Sat Sep 26 00:31:00 2009 Subject: [Icc-avr] ICCAVR 7.22C released Message-ID: <200909260730.n8Q7Ux1O099821@mail.imagecraft.com> Very minor bug fixes: V7.22C - Sept 26, 2009 Dongle Driver - Added 64 bits driver Library - Fixed a bug with 7.22A/B that if you call both csprintf/sprintf, the function sdepi is multiply defined. // richard blog: // mailing list: http://www.dragonsgate.net/mailman/listinfo // photo book: http://www.blurb.com/bookstore/detail/745963 [ For technical support on ImageCraft products, please include all previous replies in your msgs. ]