From paul.aa9gg at gmail.com Mon Mar 2 08:57:11 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Mon Mar 2 10:04:07 2009 Subject: [Icc-avr] EEPROM question Message-ID: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> Is it possible to save to the EEPROM from within an interrupt? I have 2 bytes I need to save ASAP if the interrupt is true. Any ideas? -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From DRaymond at Bankspower.com Mon Mar 2 09:29:23 2009 From: DRaymond at Bankspower.com (David Raymond) Date: Mon Mar 2 10:38:48 2009 Subject: [Icc-avr] EEPROM question In-Reply-To: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> Message-ID: <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> It is certainly possible. The main question you need to ask is whether you can remain in the interrupt for as long as it takes to write to EEPROM. It will be all other interrupts that need to tolerate this delay. A USART interrupt at high baud rates will not be able to for example. To avoid this one would normally set a flag and write to EEPROM from a foreground process. In this case the definition of ASAP comes into question. Imagecraft's EEPROM write library functions used to wait until EEPROM was ready, write the byte, and immediately exit. They were then changed to write the byte and then wait until the write was complete before exiting. If using the earlier version and if EEPROM were not written by another process your interrupt would only have to wait one write cycle before exiting. Our solution is to keep a shadow copy of EEPROM in ram. The program always uses access to ram for reading or writing variables. A function called from the main loop checks to see if EEPROM is busy and if not busy if it needs to be updated. Then it writes to EEPROM. Dave Raymond Software Engineer Gale Banks Engineering Ph (626) 969-9600 x3301 Fx (626) 334-2376 Visit us on the Web: www.bankspower.com E-mail: draymond@bankspower.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer Sent: Monday, March 02, 2009 8:57 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: [Icc-avr] EEPROM question Is it possible to save to the EEPROM from within an interrupt? I have 2 bytes I need to save ASAP if the interrupt is true. Any ideas? -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr ****verified by GBE SPAM FILTER**** From Sam.Lowenstein at ngc.com Mon Mar 2 09:32:13 2009 From: Sam.Lowenstein at ngc.com (Lowenstein, Samuel D (IT)) Date: Mon Mar 2 10:39:13 2009 Subject: [Icc-avr] EEPROM question In-Reply-To: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> Message-ID: <6A56D82ACD5A414390131171CDC0E282D532FA@xmbv3802.northgrum.com> Is there any reason you can't store it to a static global int, then do the transfer to EEPROM after exiting the ISR? -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer Sent: Monday, March 02, 2009 11:57 AM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: [Icc-avr] EEPROM question Is it possible to save to the EEPROM from within an interrupt? I have 2 bytes I need to save ASAP if the interrupt is true. Any ideas? -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From paul.aa9gg at gmail.com Mon Mar 2 09:44:08 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Mon Mar 2 10:51:03 2009 Subject: [Icc-avr] EEPROM question In-Reply-To: <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> Message-ID: <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> I'm watching an optical encoder and I need to save a shaft position value at power loss. I stiffened up my power supply with a 1000uF cap to give me some time. I currently save to eeprom outside the interrupt, but I seem to be missing a count or 2 from the encoder. On Mon, Mar 2, 2009 at 11:29 AM, David Raymond wrote: > It is certainly possible. The main question you need to ask is whether > you can remain in the interrupt for as long as it takes to write to > EEPROM. It will be all other interrupts that need to tolerate this > delay. A USART interrupt at high baud rates will not be able to for > example. > To avoid this one would normally set a flag and write to EEPROM from a > foreground process. In this case the definition of ASAP comes into > question. > Imagecraft's EEPROM write library functions used to wait until EEPROM > was ready, write the byte, and immediately exit. They were then changed > to write the byte and then wait until the write was complete before > exiting. If using the earlier version and if EEPROM were not written by > another process your interrupt would only have to wait one write cycle > before exiting. > Our solution is to keep a shadow copy of EEPROM in ram. The program > always uses access to ram for reading or writing variables. A function > called from the main loop checks to see if EEPROM is busy and if not > busy if it needs to be updated. Then it writes to EEPROM. > > > Dave Raymond > Software Engineer > Gale Banks Engineering > Ph (626) 969-9600 x3301 > Fx (626) 334-2376 > Visit us on the Web: www.bankspower.com > E-mail: draymond@bankspower.com > > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer > Sent: Monday, March 02, 2009 8:57 AM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > Subject: [Icc-avr] EEPROM question > > > Is it possible to save to the EEPROM from within an interrupt? ?I have > 2 bytes I need to save ASAP if the interrupt is true. ?Any ideas? > > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > ****verified by GBE SPAM FILTER**** > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From Sam.Lowenstein at ngc.com Mon Mar 2 10:01:37 2009 From: Sam.Lowenstein at ngc.com (Lowenstein, Samuel D (IT)) Date: Mon Mar 2 11:08:36 2009 Subject: [Icc-avr] EEPROM question In-Reply-To: <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com><0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> Message-ID: <6A56D82ACD5A414390131171CDC0E282D532FB@xmbv3802.northgrum.com> Have you considered storing the values in a circular buffer? When you get a power fail interrupt, you do the transfer. From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer Sent: Monday, March 02, 2009 12:44 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: Re: [Icc-avr] EEPROM question I'm watching an optical encoder and I need to save a shaft position value at power loss. I stiffened up my power supply with a 1000uF cap to give me some time. I currently save to eeprom outside the interrupt, but I seem to be missing a count or 2 from the encoder. On Mon, Mar 2, 2009 at 11:29 AM, David Raymond wrote: > It is certainly possible. The main question you need to ask is whether > you can remain in the interrupt for as long as it takes to write to > EEPROM. It will be all other interrupts that need to tolerate this > delay. A USART interrupt at high baud rates will not be able to for > example. > To avoid this one would normally set a flag and write to EEPROM from a > foreground process. In this case the definition of ASAP comes into > question. > Imagecraft's EEPROM write library functions used to wait until EEPROM > was ready, write the byte, and immediately exit. They were then > changed to write the byte and then wait until the write was complete > before exiting. If using the earlier version and if EEPROM were not > written by another process your interrupt would only have to wait one > write cycle before exiting. > Our solution is to keep a shadow copy of EEPROM in ram. The program > always uses access to ram for reading or writing variables. A function > called from the main loop checks to see if EEPROM is busy and if not > busy if it needs to be updated. Then it writes to EEPROM. > > > Dave Raymond > Software Engineer > Gale Banks Engineering > Ph (626) 969-9600 x3301 > Fx (626) 334-2376 > Visit us on the Web: www.bankspower.com > E-mail: draymond@bankspower.com > > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer > Sent: Monday, March 02, 2009 8:57 AM > To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > Subject: [Icc-avr] EEPROM question > > > Is it possible to save to the EEPROM from within an interrupt? ?I have > 2 bytes I need to save ASAP if the interrupt is true. ?Any ideas? > > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > ****verified by GBE SPAM FILTER**** > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From jassenbaum at htp-tel.de Mon Mar 2 10:56:20 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Mon Mar 2 12:03:14 2009 Subject: [Icc-avr] EEPROM question References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> Message-ID: How much is "some time"? And is vcc upto then still enough to keep AVR cpu running all the time? And is it sure, that AVR cpu is the last to survive beyond all mechanics? Btw: What's your AVR? Best regards, Johannes > I'm watching an optical encoder and I need to save a shaft position > value at power loss. I stiffened up my power supply with a 1000uF cap > to give me some time. I currently save to eeprom outside the > interrupt, but I seem to be missing a count or 2 from the encoder. > On Mon, Mar 2, 2009 at 11:29 AM, David Raymond wrote: >> It is certainly possible. The main question you need to ask is whether >> you can remain in the interrupt for as long as it takes to write to >> EEPROM. It will be all other interrupts that need to tolerate this >> delay. A USART interrupt at high baud rates will not be able to for >> example. >> To avoid this one would normally set a flag and write to EEPROM from a >> foreground process. In this case the definition of ASAP comes into >> question. >> Imagecraft's EEPROM write library functions used to wait until EEPROM >> was ready, write the byte, and immediately exit. They were then changed >> to write the byte and then wait until the write was complete before >> exiting. If using the earlier version and if EEPROM were not written by >> another process your interrupt would only have to wait one write cycle >> before exiting. >> Our solution is to keep a shadow copy of EEPROM in ram. The program >> always uses access to ram for reading or writing variables. A function >> called from the main loop checks to see if EEPROM is busy and if not >> busy if it needs to be updated. Then it writes to EEPROM. >> >> >> Dave Raymond >> Software Engineer >> Gale Banks Engineering >> Ph (626) 969-9600 x3301 >> Fx (626) 334-2376 >> Visit us on the Web: www.bankspower.com >> E-mail: draymond@bankspower.com >> >> >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer >> Sent: Monday, March 02, 2009 8:57 AM >> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> tosubscribe to icc-announce if you are a member of this. >> Subject: [Icc-avr] EEPROM question >> >> >> Is it possible to save to the EEPROM from within an interrupt? ?I have >> 2 bytes I need to save ASAP if the interrupt is true. ?Any ideas? >> >> -- >> Paul Mateer, AA9GG >> Elan Engineering Corp. >> www.elanengr.com >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> >> ****verified by GBE SPAM FILTER**** >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From paul.aa9gg at gmail.com Mon Mar 2 11:10:09 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Mon Mar 2 12:17:06 2009 Subject: [Icc-avr] EEPROM question In-Reply-To: References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> Message-ID: <20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com> When the 12v line drops my 5v line is up for a good 500mS. CPU is a Mega32 On Mon, Mar 2, 2009 at 12:56 PM, Johannes Assenbaum wrote: > How much is "some time"? And is vcc upto then still enough to keep AVR cpu running all the time? And is it sure, that AVR cpu is the last to survive beyond all mechanics? Btw: What's your AVR? > > Best regards, > Johannes > > >> I'm watching an optical encoder and I need to save a shaft position >> value at power loss. ?I stiffened up my power supply with a 1000uF cap >> to give me some time. ?I currently save to eeprom outside the >> interrupt, but I seem to be missing a count or 2 from the encoder. > > >> On Mon, Mar 2, 2009 at 11:29 AM, David Raymond wrote: >>> It is certainly possible. The main question you need to ask is whether >>> you can remain in the interrupt for as long as it takes to write to >>> EEPROM. It will be all other interrupts that need to tolerate this >>> delay. A USART interrupt at high baud rates will not be able to for >>> example. >>> To avoid this one would normally set a flag and write to EEPROM from a >>> foreground process. In this case the definition of ASAP comes into >>> question. >>> Imagecraft's EEPROM write library functions used to wait until EEPROM >>> was ready, write the byte, and immediately exit. They were then changed >>> to write the byte and then wait until the write was complete before >>> exiting. If using the earlier version and if EEPROM were not written by >>> another process your interrupt would only have to wait one write cycle >>> before exiting. >>> Our solution is to keep a shadow copy of EEPROM in ram. The program >>> always uses access to ram for reading or writing variables. A function >>> called from the main loop checks to see if EEPROM is busy and if not >>> busy if it needs to be updated. Then it writes to EEPROM. >>> >>> >>> Dave Raymond >>> Software Engineer >>> Gale Banks Engineering >>> Ph (626) 969-9600 x3301 >>> Fx (626) 334-2376 >>> Visit us on the Web: www.bankspower.com >>> E-mail: draymond@bankspower.com >>> >>> >>> -----Original Message----- >>> From: icc-avr-bounces@imagecraft.com >>> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer >>> Sent: Monday, March 02, 2009 8:57 AM >>> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >>> tosubscribe to icc-announce if you are a member of this. >>> Subject: [Icc-avr] EEPROM question >>> >>> >>> Is it possible to save to the EEPROM from within an interrupt? ?I have >>> 2 bytes I need to save ASAP if the interrupt is true. ?Any ideas? >>> >>> -- >>> Paul Mateer, AA9GG >>> Elan Engineering Corp. >>> www.elanengr.com >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> >>> ****verified by GBE SPAM FILTER**** >>> >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> > > > >> -- >> Paul Mateer, AA9GG >> Elan Engineering Corp. >> www.elanengr.com > >> _______________________________________________ >> 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 From schaefer at mabel.info Mon Mar 2 20:33:04 2009 From: schaefer at mabel.info (=?ISO-8859-1?Q?Thomas_Sch=E4fer?=) Date: Mon Mar 2 21:40:36 2009 Subject: [Icc-avr] EEPROM question In-Reply-To: <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> Message-ID: <49ACB300.70206@mabel.info> Hi Paul, I don't know if your hardware is alraedy fixed. In a quite similar situation I used a NVRAM (particularly the NVRAM inside a DS1306 RTC) to store the device state. I don't think it's very elegant nor feasible to try to access the EEPROM inside a IRQ routine. regards, Thomas Paul Mateer schrieb: > I'm watching an optical encoder and I need to save a shaft position > value at power loss. I stiffened up my power supply with a 1000uF cap > to give me some time. I currently save to eeprom outside the > interrupt, but I seem to be missing a count or 2 from the encoder. > > > On Mon, Mar 2, 2009 at 11:29 AM, David Raymond wrote: >> It is certainly possible. The main question you need to ask is whether >> you can remain in the interrupt for as long as it takes to write to >> EEPROM. It will be all other interrupts that need to tolerate this >> delay. A USART interrupt at high baud rates will not be able to for >> example. >> To avoid this one would normally set a flag and write to EEPROM from a >> foreground process. In this case the definition of ASAP comes into >> question. >> Imagecraft's EEPROM write library functions used to wait until EEPROM >> was ready, write the byte, and immediately exit. They were then changed >> to write the byte and then wait until the write was complete before >> exiting. If using the earlier version and if EEPROM were not written by >> another process your interrupt would only have to wait one write cycle >> before exiting. >> Our solution is to keep a shadow copy of EEPROM in ram. The program >> always uses access to ram for reading or writing variables. A function >> called from the main loop checks to see if EEPROM is busy and if not >> busy if it needs to be updated. Then it writes to EEPROM. >> >> >> Dave Raymond >> Software Engineer >> Gale Banks Engineering >> Ph (626) 969-9600 x3301 >> Fx (626) 334-2376 >> Visit us on the Web: www.bankspower.com >> E-mail: draymond@bankspower.com >> >> >> -----Original Message----- >> From: icc-avr-bounces@imagecraft.com >> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer >> Sent: Monday, March 02, 2009 8:57 AM >> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> tosubscribe to icc-announce if you are a member of this. >> Subject: [Icc-avr] EEPROM question >> >> >> Is it possible to save to the EEPROM from within an interrupt? I have >> 2 bytes I need to save ASAP if the interrupt is true. Any ideas? >> >> -- >> Paul Mateer, AA9GG >> Elan Engineering Corp. >> www.elanengr.com >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> >> ****verified by GBE SPAM FILTER**** >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > > > From sl at ecpower.dk Mon Mar 2 23:17:16 2009 From: sl at ecpower.dk (Steven Lose) Date: Tue Mar 3 00:25:28 2009 Subject: SV: [Icc-avr] EEPROM question In-Reply-To: <20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com><0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local><20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> <20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA592CD3@seattle.ecpower.dk> Hi Poul. You have to look at Johannes answer, and then decide if 500ms is time enough. Or to put it in another way, does the shaft still move when your 500ms is gone? 500ms is not a long time for a mechanical system, If the shaft and whatever is attached to it has just a little weight then it will properly still be in motion. 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 Paul Mateer Sendt: 2. marts 2009 20:10 Til: Johannes Assenbaum; 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] EEPROM question When the 12v line drops my 5v line is up for a good 500mS. CPU is a Mega32 On Mon, Mar 2, 2009 at 12:56 PM, Johannes Assenbaum wrote: > How much is "some time"? And is vcc upto then still enough to keep AVR cpu running all the time? And is it sure, that AVR cpu is the last to survive beyond all mechanics? Btw: What's your AVR? > > Best regards, > Johannes > > >> I'm watching an optical encoder and I need to save a shaft position >> value at power loss. ?I stiffened up my power supply with a 1000uF cap >> to give me some time. ?I currently save to eeprom outside the >> interrupt, but I seem to be missing a count or 2 from the encoder. > > >> On Mon, Mar 2, 2009 at 11:29 AM, David Raymond wrote: >>> It is certainly possible. The main question you need to ask is whether >>> you can remain in the interrupt for as long as it takes to write to >>> EEPROM. It will be all other interrupts that need to tolerate this >>> delay. A USART interrupt at high baud rates will not be able to for >>> example. >>> To avoid this one would normally set a flag and write to EEPROM from a >>> foreground process. In this case the definition of ASAP comes into >>> question. >>> Imagecraft's EEPROM write library functions used to wait until EEPROM >>> was ready, write the byte, and immediately exit. They were then changed >>> to write the byte and then wait until the write was complete before >>> exiting. If using the earlier version and if EEPROM were not written by >>> another process your interrupt would only have to wait one write cycle >>> before exiting. >>> Our solution is to keep a shadow copy of EEPROM in ram. The program >>> always uses access to ram for reading or writing variables. A function >>> called from the main loop checks to see if EEPROM is busy and if not >>> busy if it needs to be updated. Then it writes to EEPROM. >>> >>> >>> Dave Raymond >>> Software Engineer >>> Gale Banks Engineering >>> Ph (626) 969-9600 x3301 >>> Fx (626) 334-2376 >>> Visit us on the Web: www.bankspower.com >>> E-mail: draymond@bankspower.com >>> >>> >>> -----Original Message----- >>> From: icc-avr-bounces@imagecraft.com >>> [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer >>> Sent: Monday, March 02, 2009 8:57 AM >>> To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >>> tosubscribe to icc-announce if you are a member of this. >>> Subject: [Icc-avr] EEPROM question >>> >>> >>> Is it possible to save to the EEPROM from within an interrupt? ?I have >>> 2 bytes I need to save ASAP if the interrupt is true. ?Any ideas? >>> >>> -- >>> Paul Mateer, AA9GG >>> Elan Engineering Corp. >>> www.elanengr.com >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> >>> ****verified by GBE SPAM FILTER**** >>> >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> > > > >> -- >> Paul Mateer, AA9GG >> Elan Engineering Corp. >> www.elanengr.com > >> _______________________________________________ >> 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 _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Tue Mar 3 02:07:59 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Mar 3 03:14:58 2009 Subject: SV: [Icc-avr] EEPROM question In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA592CD3@seattle.ecpower.dk> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com><0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local><20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> <20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com> <072D96786BFC014AAEBA9EB07A8070EA592CD3@seattle.ecpower.dk> Message-ID: <49AD017F.3000206@zetnet.co.uk> Although it is normally very bad practice to call any function from an ISR, especially something as slow as an EEPROM write, in this case the ISR will never exit as it is a powerdown interrupt and an EEPROM write may be acceptable. Personally I would go for a fast NVRAM on an SPI interface. FRAM from RAMTRON would seem to be a good choice in this case. http://uk.farnell.com/ramtron/fm25640-g/fram-serial-spi-64k-25640-soic8/dp/1210790 All the best for now, John From paul.aa9gg at gmail.com Tue Mar 3 06:56:52 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Mar 3 08:03:49 2009 Subject: SV: [Icc-avr] EEPROM question In-Reply-To: <49AD017F.3000206@zetnet.co.uk> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> <20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com> <072D96786BFC014AAEBA9EB07A8070EA592CD3@seattle.ecpower.dk> <49AD017F.3000206@zetnet.co.uk> Message-ID: <20f5efc40903030656y7bb097ecp12dcf8688500ae46@mail.gmail.com> Thanks to all who responded. Yes the 500mS is plenty long enough to do the save outside the ISR. I also forgot to "trap" it after the write so that it just sits there doing nothing as the power drops. Turned out it was looping and doing many writes to the E2 and would crash/trash the E2 with a "bad write" as the power dropped further. On Tue, Mar 3, 2009 at 4:07 AM, John Baraclough wrote: > Although it is normally very bad practice to call any function from an ISR, > especially something as slow as an EEPROM write, in this case the ISR will > never exit as it is a powerdown interrupt and an EEPROM write may be > acceptable. > > Personally I would go for a fast NVRAM on an SPI interface. FRAM from > RAMTRON would seem to be a good choice in this case. > > http://uk.farnell.com/ramtron/fm25640-g/fram-serial-spi-64k-25640-soic8/dp/1210790 > > All the best for now, > John > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From richard at imagecraft.com Wed Mar 4 21:36:44 2009 From: richard at imagecraft.com (Richard Man) Date: Wed Mar 4 22:42:48 2009 Subject: [Icc-avr] ICCAVR V7.20A released Message-ID: <200903050642.n256glg7071062@mail.imagecraft.com> CHANGE LOGS: V7.20A March 4th, 2009 IDE - Added Tools->EnvOptions->General->BackupPolicy. The choices are == Unlimited (in BACKUP\ directory) == One Only (in BACKUP\ directory) - minor enhancement to the register software dialog - Added entries for M1284P, and Tiny48/88. No AppBuilder for them yet. Compiler - Fixed a compiler crash error related to the "faster code to load a constant into a long variable" optimization introduced in V7.20. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From benra at imt.liu.se Wed Mar 4 22:58:12 2009 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Thu Mar 5 00:05:21 2009 Subject: SV: SV: [Icc-avr] EEPROM question In-Reply-To: <20f5efc40903030656y7bb097ecp12dcf8688500ae46@mail.gmail.com> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com><0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local><20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com><20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com><072D96786BFC014AAEBA9EB07A8070EA592CD3@seattle.ecpower.dk><49AD017F.3000206@zetnet.co.uk> <20f5efc40903030656y7bb097ecp12dcf8688500ae46@mail.gmail.com> Message-ID: <179C1E73C9E1412B9BAAD1CFC9BCB417@Shagrat> Yes calling a function from within a INT is very inefficient as ICCAVR have to save all registers. But in this case we are talking about ms so maybe it doesn't matter. Anyway, to speed thing up you can write your own EEPROM code, just copy the original. Personally I see no problem with using the internal EEPROM, it will need a minimum of hardware. You just need to be sure that you got the time. Whats the point of doing it outside if this is the last thing the CPU should do? It could be a good idea to give the CPU some extra power separated from the rest, also be sure that nothing is loading the CPU. Maybe you should put the CPU I/O in some special mode before saving? Bengt >-----Ursprungligt meddelande----- >Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >bounces@imagecraft.com] F?r Paul Mateer >Skickat: den 3 mars 2009 15:57 >Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >tosubscribe to icc-announce if you are a member of this. >?mne: Re: SV: [Icc-avr] EEPROM question > >Thanks to all who responded. Yes the 500mS is plenty long enough to >do the save outside the ISR. I also forgot to "trap" it after the >write so that it just sits there doing nothing as the power drops. >Turned out it was looping and doing many writes to the E2 and would >crash/trash the E2 with a "bad write" as the power dropped further. > > >On Tue, Mar 3, 2009 at 4:07 AM, John Baraclough > wrote: >> Although it is normally very bad practice to call any function from an >ISR, >> especially something as slow as an EEPROM write, in this case the ISR >will >> never exit as it is a powerdown interrupt and an EEPROM write may be >> acceptable. >> >> Personally I would go for a fast NVRAM on an SPI interface. FRAM from >> RAMTRON would seem to be a good choice in this case. >> >> http://uk.farnell.com/ramtron/fm25640-g/fram-serial-spi-64k-25640- >soic8/dp/1210790 >> >> All the best for now, >> John >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > > > >-- >Paul Mateer, AA9GG >Elan Engineering Corp. >www.elanengr.com >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From paul.aa9gg at gmail.com Thu Mar 5 06:23:17 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 5 07:30:18 2009 Subject: SV: [Icc-avr] EEPROM question In-Reply-To: <179C1E73C9E1412B9BAAD1CFC9BCB417@Shagrat> References: <20f5efc40903020857u1b7cac1ib28b640de25c8ce1@mail.gmail.com> <0E755D4F91B6D344B39791054F52A2A9060AFC2D@gbexchange.bankspower.local> <20f5efc40903020944v2085cd49x641e5f1019ff769f@mail.gmail.com> <20f5efc40903021110r3a6904d2o29deea738aa69b13@mail.gmail.com> <072D96786BFC014AAEBA9EB07A8070EA592CD3@seattle.ecpower.dk> <49AD017F.3000206@zetnet.co.uk> <20f5efc40903030656y7bb097ecp12dcf8688500ae46@mail.gmail.com> <179C1E73C9E1412B9BAAD1CFC9BCB417@Shagrat> Message-ID: <20f5efc40903050623u2bdcf05el4c22a8e6faef7319@mail.gmail.com> Once I put the bigger cap on the power line I now have plenty of time to do the save outside the interrupt. My biggest problem was not having the "while loop" after the save to do nothing and just let the power drop out. On Thu, Mar 5, 2009 at 12:58 AM, Bengt Ragnemalm wrote: > Yes calling a function from within a INT is very inefficient as ICCAVR have > to save all registers. But in this case we are talking about ms so maybe it > doesn't matter. > > Anyway, to speed thing up you can write your own EEPROM code, just copy the > original. > > Personally I see no problem with using the internal EEPROM, it will need a > minimum of hardware. You just need to be sure that you got the time. Whats > the point of doing it outside if this is the last thing the CPU should do? > > It could be a good idea to give the CPU some extra power separated from the > rest, also be sure that nothing is loading the CPU. Maybe you should put the > CPU I/O in some special mode before saving? > > Bengt > >>-----Ursprungligt meddelande----- >>Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr- >>bounces@imagecraft.com] F?r Paul Mateer >>Skickat: den 3 mars 2009 15:57 >>Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need >>tosubscribe to icc-announce if you are a member of this. >>?mne: Re: SV: [Icc-avr] EEPROM question >> >>Thanks to all who responded. ?Yes the 500mS is plenty long enough to >>do the save outside the ISR. ?I also forgot to "trap" it after the >>write so that it just sits there doing nothing as the power drops. >>Turned out it was looping and doing many writes to the E2 and would >>crash/trash the E2 with a "bad write" as the power dropped further. >> >> >>On Tue, Mar 3, 2009 at 4:07 AM, John Baraclough >> wrote: >>> Although it is normally very bad practice to call any function from an >>ISR, >>> especially something as slow as an EEPROM write, in this case the ISR >>will >>> never exit as it is a powerdown interrupt and an EEPROM write may be >>> acceptable. >>> >>> Personally I would go for a fast NVRAM on an SPI interface. FRAM from >>> RAMTRON would seem to be a good choice in this case. >>> >>> http://uk.farnell.com/ramtron/fm25640-g/fram-serial-spi-64k-25640- >>soic8/dp/1210790 >>> >>> All the best for now, >>> John >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> >> >> >> >>-- >>Paul Mateer, AA9GG >>Elan Engineering Corp. >>www.elanengr.com >>_______________________________________________ >>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 From dhgrundysr at safeinc.com Sat Mar 7 10:15:11 2009 From: dhgrundysr at safeinc.com (Dave Grundy) Date: Sat Mar 7 12:43:08 2009 Subject: [Icc-avr] CRC-16-CCITT calculations Message-ID: <49B2B9AE.000006.01028@DAVESRDELL9300> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1431 bytes Desc: not available Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090307/f75a47d5/attachment-0001.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 31851 bytes Desc: not available Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090307/f75a47d5/attachment-0001.gif From ira at extrasensory.com Sat Mar 7 12:07:14 2009 From: ira at extrasensory.com (Ira) Date: Sat Mar 7 13:14:26 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <49B2B9AE.000006.01028@DAVESRDELL9300> References: <49B2B9AE.000006.01028@DAVESRDELL9300> Message-ID: <0MKp8S-1Lg2no0fWH-000g8X@mrelay.perfora.net> At 10:15 AM 3/7/2009, you wrote: >Does anyone have any code for calculating a 16 bt CRC using the CCITT >polynomial of X^16 + x^12 + x^5 + 1 ?? I'm looking for it in both C and = 54K of animation garbage and advertising for a 1 sentence question. Why???? Ira From adobson at exponent.com Sat Mar 7 12:14:16 2009 From: adobson at exponent.com (Andrew Dobson) Date: Sat Mar 7 13:21:18 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <49B2B9AE.000006.01028@DAVESRDELL9300> References: <49B2B9AE.000006.01028@DAVESRDELL9300> Message-ID: I have used this in the past, the only caveat is to make sure you get the initial conditions right and use the corresponding polynomial at the other end: Bit Width 16 Polynomial 0x1021 Initial Value 0xFFFF Initial Inversion NO Output Inversion NO XOR on Output NO / ************ Utility Function ************* // // Function: char_alpha // // Description - Performs check of data passed in and returns CRC of this data // // Parameters - // old_crc - previous iteration of CRC // data - data to obtain CRC of // Returns - // CRC of processed data // ************* // int16_t crc_1021(int16_t old_crc, uint8_t data) { int16_t crc; int16_t x; x = x = ((old_crc>>8) ^ data) & 0xff; x ^= x>>4; crc = (old_crc << 8) ^ (x << 12) ^ (x <<5) ^ x; crc &= 0xffff; return crc; } Call this via a loop to iterate through the bytes to CRC: for (i = 0; i < byte_cnt; ++i) crc = crc_1021(crc, reply[i]); reply[byte_cnt++] = crc >> 8; reply[byte_cnt++] = crc & 0x00FF; Look at this page to make use of a calculator for various types of polynomial, the one I used had the 0xFFFF initial condition in parentheses: http://www.lammertbies.nl/comm/info/crc-calculation.html I do not have AVR code as this was used on a Cypress PSoC, but I am sure that you could look at the code produced and optimise it for AVR. Regards, Andy. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Dave Grundy Sent: Saturday, March 07, 2009 11:15 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] CRC-16-CCITT calculations Hi: Does anyone have any code for calculating a 16 bt CRC using the CCITT polynomial of X^16 + x^12 + x^5 + 1 ?? I'm looking for it in both C and AVR Assembly code. Thanks, Dave Grundy FREE Animations for your email - by IncrediMail! Click Here! From sbeaver at columbus.rr.com Sat Mar 7 12:14:47 2009 From: sbeaver at columbus.rr.com (Stephen Beaver) Date: Sat Mar 7 19:01:18 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <49B2B9AE.000006.01028@DAVESRDELL9300> Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 31851 bytes Desc: not available Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090307/1a0a952d/attachment-0001.gif From Albert.vanVeen at pertronic.co.nz Sun Mar 8 11:14:30 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Sun Mar 8 12:21:40 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <0MKp8S-1Lg2no0fWH-000g8X@mrelay.perfora.net> References: <49B2B9AE.000006.01028@DAVESRDELL9300> <0MKp8S-1Lg2no0fWH-000g8X@mrelay.perfora.net> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063F0C@sbs.pertronic.local> Here is a function I used in a previous life (1992) to calculate file checksums: ================================== This is a file checksum program, implementing the CCITT 16 bit CRC algorithm (Ref Byte Sept. 86) using a polynomial with X^16 + X^12 + X^5 + X^0. The input is file or dir name(s) and output is the checksum of the file(s) or the ones of the files in that dir, printed to standard output. ================================== #define POLY 0x8408 /* Polynomial in the algorithm shifted by one bit and LSB and MSB reversed */ chkfile( fname, fstatus ) char *fname[ 40 ]; struct stat *fstatus; { FILE *fp; register int j, ch; register unsigned int crc; char *ptr; time_t dh; if( (fstatus->st_mode & S_IFMT ) == S_IFREG ) { if(( fp = fopen( fname, "r" )) == NULL ) { printf( "'%s' open failure, no checksum performed\n", fname ); } else { crc = 0xffff; while( ( ch = getc( fp ) ) != EOF ) { for( j = 0; j < 8; j++, ch >>= 1 ) { if(( crc & 0x0001 ) ^ ( ch & 0x0001 )) crc = ( crc>>1 ) ^ POLY; else crc >>= 1; } } crc = (unsigned short) ((~crc << 8 ) | (~crc >> 8 & 0xff )); ptr = (char *)ctime( &fstatus->st_mtime ); cftime( ptr, "%D %T", &fstatus->st_mtime ); ptr[ 24 ] = '\0'; printf( "%-38s %9d %s %X\n", fname, fstatus->st_size, ptr, crc ); fclose( fp ); } } else printf( "'%s' is a special/dir/non-readable file, no checksum performed\n", fname ); } -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Ira Sent: Sunday, March 08, 2009 09:07 AM To: Dave Grundy; Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Subject: Re: [Icc-avr] CRC-16-CCITT calculations At 10:15 AM 3/7/2009, you wrote: >Does anyone have any code for calculating a 16 bt CRC using the CCITT >polynomial of X^16 + x^12 + x^5 + 1 ?? I'm looking for it in both C >and = 54K of animation garbage and advertising for a 1 sentence question. Why???? Ira _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From t.jaspers at cpseurope.com Mon Mar 9 00:46:45 2009 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Mon Mar 9 01:53:51 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <0MKp8S-1Lg2no0fWH-000g8X@mrelay.perfora.net> Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C7F3709@mickey.PBNV.local> > -----Original Message----- > From: Ira > Subject: Re: [Icc-avr] CRC-16-CCITT calculations > > 54K of animation garbage and advertising for a 1 sentence > question. Why???? > Instead of stating the obvious, you could also set your reader to "text only". That effectively supresses all the binary stuff. The "Microsoft" binary emails are a fact of life, learn to live with it. Ton From jh.bodin at telia.com Mon Mar 9 05:52:24 2009 From: jh.bodin at telia.com (Johan H. Bodin) Date: Mon Mar 9 06:59:27 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <49B2B9AE.000006.01028@DAVESRDELL9300> References: <49B2B9AE.000006.01028@DAVESRDELL9300> Message-ID: <49B51F18.6060803@telia.com> Dave, the looped version below is quite compact (needs no table) but takes a few CPU cycles to complete. The code is for a PIC compiler (I couldn't find any generic C version right now) but should be easy to rewrite for AVR. At the end is a PIC16 assembly version that does the same calculation in 17 cycles straight code without tables(!). Porting this to AVR assembly is left as an excercise for the reader ;-) Regards Johan Bodin SM6LKM ######################## uns16 wCrc; // unsigned short (16-bit) ... void vUpdateCrc (char bNewByte) { char bBitCount; wCrc.high8 ^= bNewByte; // XOR new byte into MSByte of CRC bBitCount = 8; do // loop 8 times { if (wCrc.15) // MSBit == 1? (wCrc & 0x8000 ?) { wCrc <<= 1; // yes, shift CRC one bit to the left wCrc ^= 0x1021; // jam the poly' in } else // no, bit 15 of original CRC was zero wCrc <<= 1; // just shift } while (--bBitCount); // all 8 bits done? // wCrc is now updated! } ... Usage: 1. wCrc = 0xFFFF; // initialize, 0xFFFF is standard 2. call vUpdateCrc() with all message bytes 3. wCrc is ready for transmission or comparison ######################## // Initialize CRC = 0xFFFF // Send CRC after data block, MSByte first ........... ; new byte arrives in W here ; Index is a temporary variable xorwf CRC16_High,w movwf Index andlw 0xF0 swapf Index,f xorwf Index,f movf Index,w andlw 0xF0 xorwf CRC16_Low,w movwf CRC16_High rlf Index,w rlf Index,w xorwf CRC16_High,f andlw 0xE0 xorwf CRC16_High,f swapf Index,f xorwf Index,w movwf CRC16_Low ; done in 17 Tcy, straight code! ........... From Albert.vanVeen at pertronic.co.nz Mon Mar 9 11:10:49 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Mon Mar 9 12:18:01 2009 Subject: [Icc-avr] CRC-16-CCITT calculations In-Reply-To: <49B51F18.6060803@telia.com> References: <49B2B9AE.000006.01028@DAVESRDELL9300> <49B51F18.6060803@telia.com> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063F0F@sbs.pertronic.local> Very nice! And interesting to see different methods for a simple thing. Maybe we should have an algorithmic forum on the side... (If I only had time.) Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Johan H. Bodin Sent: Tuesday, March 10, 2009 02:52 AM To: ICCAVR list Subject: Re: [Icc-avr] CRC-16-CCITT calculations Dave, the looped version below is quite compact (needs no table) but takes a few CPU cycles to complete. The code is for a PIC compiler (I couldn't find any generic C version right now) but should be easy to rewrite for AVR. At the end is a PIC16 assembly version that does the same calculation in 17 cycles straight code without tables(!). Porting this to AVR assembly is left as an excercise for the reader ;-) Regards Johan Bodin SM6LKM ######################## uns16 wCrc; // unsigned short (16-bit) ... void vUpdateCrc (char bNewByte) { char bBitCount; wCrc.high8 ^= bNewByte; // XOR new byte into MSByte of CRC bBitCount = 8; do // loop 8 times { if (wCrc.15) // MSBit == 1? (wCrc & 0x8000 ?) { wCrc <<= 1; // yes, shift CRC one bit to the left wCrc ^= 0x1021; // jam the poly' in } else // no, bit 15 of original CRC was zero wCrc <<= 1; // just shift } while (--bBitCount); // all 8 bits done? // wCrc is now updated! } ... Usage: 1. wCrc = 0xFFFF; // initialize, 0xFFFF is standard 2. call vUpdateCrc() with all message bytes 3. wCrc is ready for transmission or comparison ######################## // Initialize CRC = 0xFFFF // Send CRC after data block, MSByte first ........... ; new byte arrives in W here ; Index is a temporary variable xorwf CRC16_High,w movwf Index andlw 0xF0 swapf Index,f xorwf Index,f movf Index,w andlw 0xF0 xorwf CRC16_Low,w movwf CRC16_High rlf Index,w rlf Index,w xorwf CRC16_High,f andlw 0xE0 xorwf CRC16_High,f swapf Index,f xorwf Index,w movwf CRC16_Low ; done in 17 Tcy, straight code! ........... _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From jassenbaum at htp-tel.de Mon Mar 9 11:52:13 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Mon Mar 9 12:59:19 2009 Subject: [Icc-avr] CRC-16-CCITT calculations References: <49B2B9AE.000006.01028@DAVESRDELL9300> Message-ID: Hi Dave, for basic c and asm code, I'd take Atmel appnotes are AVR350 and AVR236 as a reference. Best regards, Johannes > Hi: > Does anyone have any code for calculating a 16 bt CRC using the CCITT > polynomial of X^16 + x^12 + x^5 + 1 ?? I'm looking for it in both C and AVR > Assembly code. > Thanks, > Dave Grundy From j_baraclough at zetnet.co.uk Tue Mar 10 10:34:08 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Mar 10 11:41:16 2009 Subject: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps Message-ID: <49B6B2A0.4080008@zetnet.co.uk> Hi All, This is a bit of a stab in the dark, but I hope that one of you guys can solve my problem. Last year I built a DMX controlled flicker box to drive a stage fire effect. It works well but I am now trying to incorporate a 6N137 opto-isolator between the RS485 receiver and the AVR mega8 to try and remove an occasional ground loop problem. I have tried several circuits from a variety DMX websites but can't get anything to work. I do have an isolated 5V supply for the RX485 receiver and input side of the 6N137, so it's not that. Any hints would be welcome. All the best for now, John From sergiosider at gmail.com Tue Mar 10 10:51:26 2009 From: sergiosider at gmail.com (Sergio Sider) Date: Tue Mar 10 11:58:32 2009 Subject: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps In-Reply-To: <49B6B2A0.4080008@zetnet.co.uk> References: <49B6B2A0.4080008@zetnet.co.uk> Message-ID: <79fd91cd0903101151i75022d9ft68a0003fb234de2f@mail.gmail.com> Hi John, I used H11L1 in the past. Now, I use SI8441 from Silabs. No complaints, 3 choices for speed, the fastest one runs at 100Mbit/s if I am not wrong. And it?s cheap. Regards, Sergio. On Tue, Mar 10, 2009 at 3:34 PM, John Baraclough wrote: > Hi All, > > This is a bit of a stab in the dark, but I hope that one of you guys can > solve my problem. Last year I built a DMX controlled flicker box to drive a > stage fire effect. It works well but I am now trying to incorporate a 6N137 > opto-isolator between the RS485 receiver and the AVR mega8 to try and remove > an occasional ground loop problem. I have tried several circuits from a > variety DMX websites but can't get anything to work. I do have an isolated > 5V supply for the RX485 receiver and input side of the 6N137, so it's not > that. > > Any hints would be welcome. > > All the best for now, > John > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From obparham at jpl.nasa.gov Tue Mar 10 11:33:12 2009 From: obparham at jpl.nasa.gov (Bruce Parham) Date: Tue Mar 10 12:40:21 2009 Subject: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps In-Reply-To: <49B6B2A0.4080008@zetnet.co.uk> References: <49B6B2A0.4080008@zetnet.co.uk> Message-ID: <49B6C078.4050500@jpl.nasa.gov> John, You might want to check out the Analog Dev. ADM2486. I don't know what kind of baud rate DMX uses but, if it's under 20 Mb, that part should do it and it has built-in isolated power. Bruce John Baraclough wrote: > Hi All, > > This is a bit of a stab in the dark, but I hope that one of you guys can solve my problem. Last year I built a DMX controlled flicker box to drive a stage fire effect. It works well but I am now trying to incorporate a 6N137 opto-isolator between the RS485 receiver and the AVR mega8 to try and remove an occasional ground loop problem. I have tried several circuits from a variety DMX websites but can't get anything to work. I do have an isolated 5V supply for the RX485 receiver and input > side of the 6N137, so it's not that. > > Any hints would be welcome. > > All the best for now, > John From j_baraclough at zetnet.co.uk Tue Mar 10 11:33:39 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Mar 10 12:40:47 2009 Subject: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps In-Reply-To: <79fd91cd0903101151i75022d9ft68a0003fb234de2f@mail.gmail.com> References: <49B6B2A0.4080008@zetnet.co.uk> <79fd91cd0903101151i75022d9ft68a0003fb234de2f@mail.gmail.com> Message-ID: <49B6C093.3070202@zetnet.co.uk> Hi Sergio, Thanks. I'll have a look for a UK supplier of the SI8441. All the best for now, John Sergio Sider wrote: > Hi John, > > I used H11L1 in the past. > > Now, I use SI8441 from Silabs. No complaints, 3 choices for speed, the > fastest one runs at 100Mbit/s if I am not wrong. > And it?s cheap. > > Regards, > Sergio. > > > > From sl at ecpower.dk Tue Mar 10 11:11:22 2009 From: sl at ecpower.dk (Steven Lose) Date: Tue Mar 10 12:53:42 2009 Subject: SV: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps In-Reply-To: <49B6B2A0.4080008@zetnet.co.uk> References: <49B6B2A0.4080008@zetnet.co.uk> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA5BF94E@seattle.ecpower.dk> Hi John. I have attached a Diagram that shows how I do it. I don't use PC410 instead of 6N137 but the diagram must be very similar. 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: 10. marts 2009 19:34 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this.; Discussion List for ICC08/11/12/16 users. You do NOT need to subscribeto icc-announce if you are a member of this.; icc-430@imagecraft.com Emne: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps Hi All, This is a bit of a stab in the dark, but I hope that one of you guys can solve my problem. Last year I built a DMX controlled flicker box to drive a stage fire effect. It works well but I am now trying to incorporate a 6N137 opto-isolator between the RS485 receiver and the AVR mega8 to try and remove an occasional ground loop problem. I have tried several circuits from a variety DMX websites but can't get anything to work. I do have an isolated 5V supply for the RX485 receiver and input side of the 6N137, so it's not that. Any hints would be welcome. All the best for now, John _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- A non-text attachment was scrubbed... Name: RS485_ISO.bmp Type: image/bmp Size: 681858 bytes Desc: RS485_ISO.bmp Url : http://dragonsgate.net/pipermail/icc-avr/attachments/20090310/847fdd8e/RS485_ISO-0001.bin From obparham at jpl.nasa.gov Tue Mar 10 12:17:44 2009 From: obparham at jpl.nasa.gov (Bruce Parham) Date: Tue Mar 10 13:24:53 2009 Subject: [Icc-avr] OT: Opto-isolation of RS485 signals at 250kbps In-Reply-To: <49B6C078.4050500@jpl.nasa.gov> References: <49B6B2A0.4080008@zetnet.co.uk> <49B6C078.4050500@jpl.nasa.gov> Message-ID: <49B6CAE8.6020004@jpl.nasa.gov> Oops, strike the last bit about isolated power (I was thinking about another part). Other then that, it's pretty much a single part solution - one chip and a couple bypass caps. Bruce Bruce Parham wrote: > John, > > You might want to check out the Analog Dev. ADM2486. I don't know what kind of baud rate DMX > uses but, if it's under 20 Mb, that part should do it and it has built-in isolated power. > > Bruce > > > John Baraclough wrote: >> Hi All, >> >> This is a bit of a stab in the dark, but I hope that one of you guys can solve my problem. Last year I built a DMX controlled flicker box to drive a stage fire effect. It works well but I am now trying to incorporate a 6N137 opto-isolator between the RS485 receiver and the AVR mega8 to try and remove an occasional ground loop problem. I have tried several circuits from a variety DMX websites but can't get anything to work. I do have an isolated 5V supply for the RX485 receiver and input >> side of the 6N137, so it's not that. >> >> Any hints would be welcome. >> >> All the best for now, >> John > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From richard at imagecraft.com Wed Mar 11 13:57:26 2009 From: richard at imagecraft.com (Richard Man) Date: Thu Mar 12 02:04:08 2009 Subject: [Icc-avr] Competing with "Free" Software Message-ID: <200903121004.n2CA47DF053163@mail.imagecraft.com> I just wrote a blog entry of the subject, and I welcome any comments you may have. http://imagecraft.wordpress.com/2009/03/12/competing-with-free-software/ // richard From prsalter at bigpond.net.au Thu Mar 12 01:21:43 2009 From: prsalter at bigpond.net.au (Paul Salter) Date: Thu Mar 12 02:29:04 2009 Subject: [Icc-avr] Competing with "Free" Software References: <200903121004.n2CA47DF053163@mail.imagecraft.com> Message-ID: Hi Richard, not sure why you have the need to write this blog. As a professional embedded designer I would, and have, recommended your compiler to my associates who have purchased your product. My customers would cringe if I was using a free compiler as there are limitations with those types of products as you suggested and reeks of non professionalism. Also, the technical support for your product is exemplary. Regards Paul Salter ----- Original Message ----- From: "Richard Man" To: ; ; ; ; ; Sent: Thursday, March 12, 2009 8:57 AM Subject: [Icc-avr] Competing with "Free" Software >I just wrote a blog entry of the subject, and I welcome any comments you >may have. > > http://imagecraft.wordpress.com/2009/03/12/competing-with-free-software/ > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From richard-lists at imagecraft.com Wed Mar 11 14:45:30 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Mar 12 02:52:14 2009 Subject: [Icc-avr] Competing with "Free" Software In-Reply-To: References: <200903121004.n2CA47DF053163@mail.imagecraft.com> Message-ID: <200903121052.n2CAqCRU054253@mail.imagecraft.com> Thanks. It's just a way for me to note down my thoughts. If everyone thinks like you do, I would indeed have no need to write the entry :-) Thanks again. At 01:21 AM 3/12/2009, Paul Salter wrote: >Hi Richard, not sure why you have the need to write this blog. > >As a professional embedded designer I would, and have, recommended >your compiler to my associates who have purchased your product. > >My customers would cringe if I was using a free compiler as there >are limitations with those types of products as you suggested and >reeks of non professionalism. > >Also, the technical support for your product is exemplary. // richard From prsalter at bigpond.net.au Thu Mar 12 01:51:02 2009 From: prsalter at bigpond.net.au (Paul Salter) Date: Thu Mar 12 02:58:30 2009 Subject: [Icc-avr] Competing with "Free" Software References: <200903121004.n2CA47DF053163@mail.imagecraft.com> <200903121052.n2CAqCRU054253@mail.imagecraft.com> Message-ID: <38C17B750C8344EC859AF837EA6A7776@rev> It just frustrates me that people think that way. You are a market leader. Regards Paul ----- Original Message ----- From: "Richard Man" To: Sent: Thursday, March 12, 2009 9:45 AM Subject: Re: [Icc-avr] Competing with "Free" Software > Thanks. It's just a way for me to note down my thoughts. If everyone > thinks like you do, I would indeed have no need to write the entry :-) > > Thanks again. > > At 01:21 AM 3/12/2009, Paul Salter wrote: >>Hi Richard, not sure why you have the need to write this blog. >> >>As a professional embedded designer I would, and have, recommended >>your compiler to my associates who have purchased your product. >> >>My customers would cringe if I was using a free compiler as there >>are limitations with those types of products as you suggested and >>reeks of non professionalism. >> >>Also, the technical support for your product is exemplary. > > // richard > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From richard-lists at imagecraft.com Wed Mar 11 15:02:34 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Mar 12 03:09:17 2009 Subject: [Icc-avr] Competing with "Free" Software In-Reply-To: <38C17B750C8344EC859AF837EA6A7776@rev> References: <200903121004.n2CA47DF053163@mail.imagecraft.com> <200903121052.n2CAqCRU054253@mail.imagecraft.com> <38C17B750C8344EC859AF837EA6A7776@rev> Message-ID: <200903121109.n2CB9Gjp055281@mail.imagecraft.com> Actually, another way to look at this is that especially for the AVR market, we need to capture even more of the professional's market. I have been resistant to do mixed pointer compilers since forever and I have came to the realization that for us to continue to excel in the AVR space, especially to best support the XMega, this is the way to go. It just means a lot of blood sweat, and tear on my part :-), or is that :-(?! Thanks again. At 01:51 AM 3/12/2009, Paul Salter wrote: >It just frustrates me that people think that way. > >You are a market leader. > >Regards > >Paul // richard From Albert.vanVeen at pertronic.co.nz Thu Mar 12 11:09:00 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Thu Mar 12 12:16:12 2009 Subject: [Icc-avr] Competing with "Free" Software In-Reply-To: <200903121052.n2CAqCRU054253@mail.imagecraft.com> References: <200903121004.n2CA47DF053163@mail.imagecraft.com> <200903121052.n2CAqCRU054253@mail.imagecraft.com> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063F17@sbs.pertronic.local> You are right in your fears. Even in our company ICC and GCC compete, with the boss saying: Why should I pay Albert & Daniel a thousand bucks each for a compiler, when Simon and Jeremy can do it with a free compiler? And now 'they' are trying to standardise the company on GCC, and I would not doubt their professionalism as Paul suggests. Your article was well written, and useful, I think. Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man Sent: Thursday, March 12, 2009 11:46 AM To: icc-avr@imagecraft.com Subject: Re: [Icc-avr] Competing with "Free" Software Thanks. It's just a way for me to note down my thoughts. If everyone thinks like you do, I would indeed have no need to write the entry :-) Thanks again. At 01:21 AM 3/12/2009, Paul Salter wrote: >Hi Richard, not sure why you have the need to write this blog. > >As a professional embedded designer I would, and have, recommended your >compiler to my associates who have purchased your product. > >My customers would cringe if I was using a free compiler as there are >limitations with those types of products as you suggested and reeks of >non professionalism. > >Also, the technical support for your product is exemplary. // richard _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From andrew_166 at msn.com Thu Mar 12 13:34:59 2009 From: andrew_166 at msn.com (Andrew) Date: Thu Mar 12 14:42:05 2009 Subject: [Icc-avr] Competing with "Free" Software In-Reply-To: <200903121004.n2CA47DF053163@mail.imagecraft.com><200903121052.n2CAqCRU054253@mail.imagecraft.com> <5F8515C5ED67B6439B4F93D7B5E08A36063F17@sbs.pertronic.local> References: <200903121004.n2CA47DF053163@mail.imagecraft.com><200903121052.n2CAqCRU054253@mail.imagecraft.com> <5F8515C5ED67B6439B4F93D7B5E08A36063F17@sbs.pertronic.local> Message-ID: HI, I have always used ICCAVR for all of my projects, but my most recent one which involved an AVR AT90. I used the GCC complier (WinAVR) as it had a collection of drivers written for the USB stack, so instead of spending hours re-writing it for ICCAVR I decided to use the GCC compiler, and to be honest I found the complier to be good and well supported, and I really liked the way it seamlessly integrated into AVR studio (i am, also using the new AVR32 Studio, which TBH works very well). >From my point of view I don't really use the code optimizers as the AVR range is priced in such a way that for high performance application I can just get an AVR32 or Xmega (not good engineering I agree) for a few pennies more instead of trying to squeeze the application into an AVR mega for example and possibly costing me allot more design time. I don't agree with the non-professionalism statement, from what I have seen the customer does not care what compiler was used (nor have most even heard of any or ever asked), just that the product works, the code is written in a portable, manageable way and the product delivered on time and on budget. Having said that I still use ICCAVR as the support from Imagecraft is second to none. Andy -------------------------------------------------- From: "Albert vanVeen" Sent: Thursday, March 12, 2009 7:09 PM 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] Competing with "Free" Software > You are right in your fears. > Even in our company ICC and GCC compete, with the boss saying: Why > should I pay Albert & Daniel a thousand bucks each for a compiler, when > Simon and Jeremy can do it with a free compiler? > And now 'they' are trying to standardise the company on GCC, and I would > not doubt their professionalism as Paul suggests. > > Your article was well written, and useful, I think. > > Albert. > > > -----Original Message----- > From: icc-avr-bounces@imagecraft.com > [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Man > Sent: Thursday, March 12, 2009 11:46 AM > To: icc-avr@imagecraft.com > Subject: Re: [Icc-avr] Competing with "Free" Software > > Thanks. It's just a way for me to note down my thoughts. If everyone > thinks like you do, I would indeed have no need to write the entry :-) > > Thanks again. > > At 01:21 AM 3/12/2009, Paul Salter wrote: >>Hi Richard, not sure why you have the need to write this blog. >> >>As a professional embedded designer I would, and have, recommended your > >>compiler to my associates who have purchased your product. >> >>My customers would cringe if I was using a free compiler as there are >>limitations with those types of products as you suggested and reeks of >>non professionalism. >> >>Also, the technical support for your product is exemplary. > > // richard > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -- > > This message has been scanned for viruses and > > dangerous content by Bizo EmailFilter, and is > > believed to be clean. > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From danar at astrixnet.com Thu Mar 12 11:19:34 2009 From: danar at astrixnet.com (Dana Raymond) Date: Thu Mar 12 19:32:49 2009 Subject: [Icc-avr] RE: Free Software In-Reply-To: <200903122000.n2CK0Ltn062745@mail.imagecraft.com> References: <200903122000.n2CK0Ltn062745@mail.imagecraft.com> Message-ID: I haven't read the blog entry, But as have most Embedded systems people I've encountered the misguided amature who says "I can do it myself, how hard can it be?" "Contractors are always dishonest and inflate the project costs to suit themselves" "Cheap is good, free is better". I selected ICCAVR a few years ago based on its mid-range pricepoint and comments on avrfreaks.net. I believed we lucked-out with this one. The level of support yopu have provided Richard encourages me to make the extra effprt to bring any bugs I may discover to your attention. "BNUGS?" What are Bugs? That's not a bug it's a feature Richard. Please feel free to use me as a sales reference if you need to.I want to keep you as happy as you have kept us. Dana Frank Raymond -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: March 12, 2009 4:00 PM To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 56, Issue 10 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. Competing with "Free" Software (Richard Man) 2. Re: Competing with "Free" Software (Paul Salter) 3. Re: Competing with "Free" Software (Richard Man) 4. Re: Competing with "Free" Software (Paul Salter) 5. Re: Competing with "Free" Software (Richard Man) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Mar 2009 13:57:26 -0800 From: Richard Man Subject: [Icc-avr] Competing with "Free" Software To: icc-announce@imagecraft.com, icc-avr@imagecraft.com, icc-mot@imagecraft.com, icc-430@imagecraft.com, icc-arm@imagecraft.com, icc-prop@imagecraft.com Message-ID: <200903121004.n2CA47DF053163@mail.imagecraft.com> Content-Type: text/plain; charset="us-ascii"; format=flowed I just wrote a blog entry of the subject, and I welcome any comments you may have. http://imagecraft.wordpress.com/2009/03/12/competing-with-free-software/ // richard ------------------------------ Message: 2 Date: Thu, 12 Mar 2009 20:21:43 +1100 From: "Paul Salter" Subject: Re: [Icc-avr] Competing with "Free" Software To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Hi Richard, not sure why you have the need to write this blog. As a professional embedded designer I would, and have, recommended your compiler to my associates who have purchased your product. My customers would cringe if I was using a free compiler as there are limitations with those types of products as you suggested and reeks of non professionalism. Also, the technical support for your product is exemplary. Regards Paul Salter ----- Original Message ----- From: "Richard Man" To: ; ; ; ; ; Sent: Thursday, March 12, 2009 8:57 AM Subject: [Icc-avr] Competing with "Free" Software >I just wrote a blog entry of the subject, and I welcome any comments you >may have. > > http://imagecraft.wordpress.com/2009/03/12/competing-with-free-software/ > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ Message: 3 Date: Wed, 11 Mar 2009 14:45:30 -0800 From: Richard Man Subject: Re: [Icc-avr] Competing with "Free" Software To: Message-ID: <200903121052.n2CAqCRU054253@mail.imagecraft.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks. It's just a way for me to note down my thoughts. If everyone thinks like you do, I would indeed have no need to write the entry :-) Thanks again. At 01:21 AM 3/12/2009, Paul Salter wrote: >Hi Richard, not sure why you have the need to write this blog. > >As a professional embedded designer I would, and have, recommended >your compiler to my associates who have purchased your product. > >My customers would cringe if I was using a free compiler as there >are limitations with those types of products as you suggested and >reeks of non professionalism. > >Also, the technical support for your product is exemplary. // richard ------------------------------ Message: 4 Date: Thu, 12 Mar 2009 20:51:02 +1100 From: "Paul Salter" Subject: Re: [Icc-avr] Competing with "Free" Software To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: <38C17B750C8344EC859AF837EA6A7776@rev> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response It just frustrates me that people think that way. You are a market leader. Regards Paul ----- Original Message ----- From: "Richard Man" To: Sent: Thursday, March 12, 2009 9:45 AM Subject: Re: [Icc-avr] Competing with "Free" Software > Thanks. It's just a way for me to note down my thoughts. If everyone > thinks like you do, I would indeed have no need to write the entry :-) > > Thanks again. > > At 01:21 AM 3/12/2009, Paul Salter wrote: >>Hi Richard, not sure why you have the need to write this blog. >> >>As a professional embedded designer I would, and have, recommended >>your compiler to my associates who have purchased your product. >> >>My customers would cringe if I was using a free compiler as there >>are limitations with those types of products as you suggested and >>reeks of non professionalism. >> >>Also, the technical support for your product is exemplary. > > // richard > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ Message: 5 Date: Wed, 11 Mar 2009 15:02:34 -0800 From: Richard Man Subject: Re: [Icc-avr] Competing with "Free" Software To: Message-ID: <200903121109.n2CB9Gjp055281@mail.imagecraft.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Actually, another way to look at this is that especially for the AVR market, we need to capture even more of the professional's market. I have been resistant to do mixed pointer compilers since forever and I have came to the realization that for us to continue to excel in the AVR space, especially to best support the XMega, this is the way to go. It just means a lot of blood sweat, and tear on my part :-), or is that :-(?! Thanks again. At 01:51 AM 3/12/2009, Paul Salter wrote: >It just frustrates me that people think that way. > >You are a market leader. > >Regards > >Paul // richard ------------------------------ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr End of Icc-avr Digest, Vol 56, Issue 10 *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090312/d71f5d0f/attachment-0001.html From tslava at gmail.com Sat Mar 14 15:35:13 2009 From: tslava at gmail.com (tslava@gmail.com) Date: Sat Mar 14 16:42:26 2009 Subject: [Icc-avr] Touchscreen controller Message-ID: Did anybody ever make a touchscreen controller with Atmega and willing to share the code? I have a problem with edge compensation. Any help will be appreciated. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090314/ec42ce2f/attachment.html From steve.williams at westnet.com.au Sun Mar 15 05:03:35 2009 From: steve.williams at westnet.com.au (Steve Williams) Date: Sun Mar 15 06:11:16 2009 Subject: [Fwd: Re: [Icc-avr] Competing with "Free" Software] Message-ID: <49BCFCA7.9020208@westnet.com.au> Hi Richard, Now I have had time to think (day time here in Ozz now) and read other posts to the forum, I would like to echo other users words. I for one have just recently purchased your ARM compiler and already have your AVR compiler. The reason I purchased the Arm Compiler over other Professional compilers and GNU compiler offerings is for the professional and expedient service supplied by the Imagecraft team and in particular you Richard. Having said that if find yourself in the position of needing to concentrate on the smaller 8 & 16 bit targets EG. AVR and HC11 etc. I would be more than happy to have Imagecraft use GCC as the compiler for the ARM targets with the Imagecraft IDE and support as the professional service paid for when purchasing the ICCARM compiler. If that is the way you decide to go. In any case I would again like to say keep up the good work and don't forget to enjoy life along the way! Cheers Steve Williams Insilicon Embedded Solutions Pty Ltd -------------- next part -------------- An embedded message was scrubbed... From: Steve Williams Subject: RE: [Icc-avr] Competing with "Free" Software Date: Fri, 13 Mar 2009 14:16:13 +1000 Size: 1444 Url: http://dragonsgate.net/pipermail/icc-avr/attachments/20090315/8f81ef80/Icc-avrCompetingwithFreeSoftware.eml From dlakin at valeport.co.uk Tue Mar 17 00:20:03 2009 From: dlakin at valeport.co.uk (Den Lakin) Date: Tue Mar 17 01:27:08 2009 Subject: [Icc-avr] xmega fusebits Message-ID: <8238C08C7D245243BD124393093F67257F4292@vp-server> How are the fusebits set on the xmega128A1. I am wanting to set the brown out to minimum level and hence set FUSEBYTE5 = 0x0F, but not sure what the correct macro is for this ? I am programming using the PDI interface using AVR Studio4 and JtagICE mk2. Also, has anyone done a bootloader for this beast yet? Best Regards Den Lakin Engineer Valeport Ltd St Peter's Quay Totnes Devon TQ9 5EW United Kingdom Tel: +44 (0)1803 869292 Fax: +44 (0)1803 869293 E-mail: dlakin@valeport.co.uk Web: www.valeport.co.uk Valeport Ltd is registered as a company in England & Wales, at the above address. Company Number: 1950444 VAT Number: GB 430 4453 84 From james.hatley at comcast.net Tue Mar 17 08:32:40 2009 From: james.hatley at comcast.net (Jim Hatley) Date: Tue Mar 17 09:39:50 2009 Subject: [Icc-avr] xmega fusebits References: <8238C08C7D245243BD124393093F67257F4292@vp-server> Message-ID: Den, Fusebits can be set using the JtagICE mk2 in Studio using the JTAG mode, I've tried this and it does work. Fusebits should also be settable in the PDI mode but I have not tried that at this point. You should see the fusebit menu in Studio if you do a connect etc. ( Maybe you have but... ) I suggest that you get to the JTAG mode as it works very well for the xmega and gives a much more in depth understanding of what is going on inside the xmega and how things are arranged. Using the JTAG mode ( for me ) is essential in development with the xmega. The xmega is much more complex than the atmega and requires a more comprehensive debug capability. I have been unable to discover yet how to set fusebits from the command line program. I may have missed it in the documentation. I'm sure that eventually it will work from the command line. The fusebits are not settable from inside an application program but you can read them through the NVM controller ( as you probably know ). Good Luck, Jim ----- Original Message ----- From: Den Lakin To: icc-avr@imagecraft.com Sent: Tuesday, March 17, 2009 1:20 AM Subject: [Icc-avr] xmega fusebits How are the fusebits set on the xmega128A1. I am wanting to set the brown out to minimum level and hence set FUSEBYTE5 = 0x0F, but not sure what the correct macro is for this ? I am programming using the PDI interface using AVR Studio4 and JtagICE mk2. Also, has anyone done a bootloader for this beast yet? Best Regards Den Lakin Engineer Valeport Ltd St Peter's Quay Totnes Devon TQ9 5EW United Kingdom Tel: +44 (0)1803 869292 Fax: +44 (0)1803 869293 E-mail: dlakin@valeport.co.uk Web: www.valeport.co.uk Valeport Ltd is registered as a company in England & Wales, at the above address. Company Number: 1950444 VAT Number: GB 430 4453 84 _______________________________________________ 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/20090317/2fb391c8/attachment.html From H.Fuerstenberger at glp.de Wed Mar 18 00:01:02 2009 From: H.Fuerstenberger at glp.de (=?iso-8859-1?Q?F=FCrstenberger=2C_Holger?=) Date: Wed Mar 18 01:08:25 2009 Subject: [Icc-avr] Support of ATmega324P Message-ID: <0870D146C1394543BA6773B969A091AF212F28646C@glp-xchg-itt.intern.glp.de> Hello everybody, i'm using the ATmega324P in a project and just writing the Software with ICCAVR V7.17. I noticed, that in the App-Builder Timer2 doesn't support the second Compare (OCR2B) Register. So I set the register manually. But the second major problem is, that the compiler doesn't use the "mul" command in a 16x16 Multiplication. Is there a simple solution to fix this problem? I don't want to use the loop calculation with shift commands. Best regards, Holger F?rstenberger (Software Engineering) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090318/cc08478d/attachment.html From dlakin at valeport.co.uk Wed Mar 18 00:51:41 2009 From: dlakin at valeport.co.uk (Den Lakin) Date: Wed Mar 18 01:58:41 2009 Subject: [Icc-avr] RE: Icc-avr Digest, Vol 56, Issue 13 In-Reply-To: <9A0C89DFDA91443083F9FD3731D88726@valeport.local> References: <9A0C89DFDA91443083F9FD3731D88726@valeport.local> Message-ID: <8238C08C7D245243BD124393093F67257F4338@vp-server> Thanks for the info Jim. Unfortunately I cant use Jtag mode, but the PDI mode allows good debugging - not sure what extra you get from Jtag mode. It seems that I have to start AVR studio without the debug mode and connect direct to set the fuses. I assume that once these are set they do not change upon each power cycle. Best Regards Den Lakin Engineer Valeport Ltd St Peter's Quay Totnes Devon TQ9 5EW United Kingdom Tel: +44 (0)1803 869292 Fax: +44 (0)1803 869293 E-mail: dlakin@valeport.co.uk Web: www.valeport.co.uk Valeport Ltd is registered as a company in England & Wales, at the above address. Company Number: 1950444 VAT Number: GB 430 4453 84 -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of icc-avr-request@imagecraft.com Sent: 18 March 2009 07:30 To: icc-avr@imagecraft.com Subject: Icc-avr Digest, Vol 56, Issue 13 Send Icc-avr mailing list submissions to icc-avr@imagecraft.com To subscribe or unsubscribe via the World Wide Web, visit http://dragonsgate.net/mailman/listinfo/icc-avr or, via email, send a message with subject or body 'help' to icc-avr-request@imagecraft.com You can reach the person managing the list at icc-avr-owner@imagecraft.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Icc-avr digest..." Today's Topics: 1. xmega fusebits (Den Lakin) 2. Re: xmega fusebits (Jim Hatley) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Mar 2009 08:20:03 -0000 From: "Den Lakin" Subject: [Icc-avr] xmega fusebits To: Message-ID: <8238C08C7D245243BD124393093F67257F4292@vp-server> Content-Type: text/plain; charset="us-ascii" How are the fusebits set on the xmega128A1. I am wanting to set the brown out to minimum level and hence set FUSEBYTE5 = 0x0F, but not sure what the correct macro is for this ? I am programming using the PDI interface using AVR Studio4 and JtagICE mk2. Also, has anyone done a bootloader for this beast yet? Best Regards Den Lakin Engineer Valeport Ltd St Peter's Quay Totnes Devon TQ9 5EW United Kingdom Tel: +44 (0)1803 869292 Fax: +44 (0)1803 869293 E-mail: dlakin@valeport.co.uk Web: www.valeport.co.uk Valeport Ltd is registered as a company in England & Wales, at the above address. Company Number: 1950444 VAT Number: GB 430 4453 84 ------------------------------ Message: 2 Date: Tue, 17 Mar 2009 09:32:40 -0700 From: "Jim Hatley" Subject: Re: [Icc-avr] xmega fusebits To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribeto icc-announce if you are a member of this." Message-ID: Content-Type: text/plain; charset="iso-8859-1" Den, Fusebits can be set using the JtagICE mk2 in Studio using the JTAG mode, I've tried this and it does work. Fusebits should also be settable in the PDI mode but I have not tried that at this point. You should see the fusebit menu in Studio if you do a connect etc. ( Maybe you have but... ) I suggest that you get to the JTAG mode as it works very well for the xmega and gives a much more in depth understanding of what is going on inside the xmega and how things are arranged. Using the JTAG mode ( for me ) is essential in development with the xmega. The xmega is much more complex than the atmega and requires a more comprehensive debug capability. I have been unable to discover yet how to set fusebits from the command line program. I may have missed it in the documentation. I'm sure that eventually it will work from the command line. The fusebits are not settable from inside an application program but you can read them through the NVM controller ( as you probably know ). Good Luck, Jim ----- Original Message ----- From: Den Lakin To: icc-avr@imagecraft.com Sent: Tuesday, March 17, 2009 1:20 AM Subject: [Icc-avr] xmega fusebits How are the fusebits set on the xmega128A1. I am wanting to set the brown out to minimum level and hence set FUSEBYTE5 = 0x0F, but not sure what the correct macro is for this ? I am programming using the PDI interface using AVR Studio4 and JtagICE mk2. Also, has anyone done a bootloader for this beast yet? Best Regards Den Lakin Engineer Valeport Ltd St Peter's Quay Totnes Devon TQ9 5EW United Kingdom Tel: +44 (0)1803 869292 Fax: +44 (0)1803 869293 E-mail: dlakin@valeport.co.uk Web: www.valeport.co.uk Valeport Ltd is registered as a company in England & Wales, at the above address. Company Number: 1950444 VAT Number: GB 430 4453 84 _______________________________________________ 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/20090317/2fb391c8/a ttachment-0001.html ------------------------------ _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr End of Icc-avr Digest, Vol 56, Issue 13 *************************************** From james.hatley at comcast.net Wed Mar 18 06:13:01 2009 From: james.hatley at comcast.net (Jim Hatley) Date: Wed Mar 18 07:20:10 2009 Subject: [Icc-avr] XMega Fuse Bits References: <9A0C89DFDA91443083F9FD3731D88726@valeport.local> <8238C08C7D245243BD124393093F67257F4338@vp-server> Message-ID: <8C47A1C805E44749B2548AF13E314BE8@red7> Yes in the non-debug mode and you only need to set fuses once. I have not tried the PDI mode with Studio, debugging may be the same, don't know ... I just know that debugging in JTAG mode works well. It has speeded up the project here significantly. Jim ----- Original Message ----- From: Den Lakin To: icc-avr@imagecraft.com Sent: Wednesday, March 18, 2009 1:51 AM Subject: [Icc-avr] RE: Icc-avr Digest, Vol 56, Issue 13 Thanks for the info Jim. Unfortunately I cant use Jtag mode, but the PDI mode allows good debugging - not sure what extra you get from Jtag mode. It seems that I have to start AVR studio without the debug mode and connect direct to set the fuses. I assume that once these are set they do not change upon each power cycle. <<< snip >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090318/4f997d1e/attachment.html From claus at norsk-display.com Thu Mar 19 03:22:40 2009 From: claus at norsk-display.com (Claus Wahl / Norsk Display AS) Date: Thu Mar 19 04:30:10 2009 Subject: [Icc-avr] XP invalid pointer In-Reply-To: <8238C08C7D245243BD124393093F67257F4338@vp-server> References: <9A0C89DFDA91443083F9FD3731D88726@valeport.local> <8238C08C7D245243BD124393093F67257F4338@vp-server> Message-ID: <49C22B00.8090607@norsk-display.com> Hi, I've got a strange problem after installing on a new XPsp3 machine: The v7.20A opens normally, usb key is found and the project file is opened as normal. The source file, however is opened without displaying the content of the file. When trying to open the source file, an error window states "invalid pointer operation". I had this problem also with v7.20 We're using the built-in editor. Any solutions? best regards Claus From paul.aa9gg at gmail.com Thu Mar 19 08:01:47 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 09:09:04 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt Message-ID: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> Hello all.... I am trying to use the analog comparator in a project, but can't seem to get the interrupt to fire. I can see the flag set in the ACSR, but it never seems to vector to the interrupt routine. Here is my setup: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0; ACSR = 0x0B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } Any ideas? Global interrupts are set. Thanks.... -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From j_baraclough at zetnet.co.uk Thu Mar 19 08:48:04 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Mar 19 09:55:24 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> Message-ID: <49C27744.4060307@zetnet.co.uk> Hi Paul, You code looks good and I don't know if this helps, but there is an errata entry for the Analog Comparator in the latest mega32 data sheet (p 343). It suggests disabling and re-enabling the AC after startup. All the best for now, John Paul Mateer wrote: > Hello all.... > I am trying to use the analog comparator in a project, but can't seem > to get the interrupt to fire. I can see the flag set in the ACSR, but > it never seems to vector to the interrupt routine. Here is my setup: > > //Comparator initialize > // trigger on: Rising output edge > void comparator_init(void) > { > ACSR = 0; > ACSR = 0x0B; > } > > #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP > void ana_comp_isr(void) > { > //analog comparator compare event > while(1) > { > DECIMAL_POINT |= DP2; > for(x=0;x<=250;x++){;} > DECIMAL_POINT &= ~DP2; > for(x=0;x<=250;x++){;} > } > } > > > Any ideas? Global interrupts are set. > > Thanks.... > > > From paul.aa9gg at gmail.com Thu Mar 19 09:24:37 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 10:31:55 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <49C27744.4060307@zetnet.co.uk> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> Message-ID: <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> Well I tried that....did not help. I just noticed too that no matter how I set the detect, it always seems to be in the "toggle" mode!!! I don't understand what the heck is going on here! I've been fighting this stupid thing all morning now! What am I doing wrong???? On Thu, Mar 19, 2009 at 11:48 AM, John Baraclough wrote: > Hi Paul, > > You code looks good and I don't know if this helps, but there is an errata > entry for the Analog Comparator in the latest mega32 data sheet (p 343). It > suggests disabling and re-enabling the AC after startup. > > All the best for now, > John > > > Paul Mateer wrote: >> >> Hello all.... >> I am trying to use the analog comparator in a project, but can't seem >> to get the interrupt to fire. I can see the flag set in the ACSR, but >> it never seems to vector to the interrupt routine. Here is my setup: >> >> //Comparator initialize >> // trigger on: Rising output edge >> void comparator_init(void) >> { >> ?ACSR = 0; >> ?ACSR = 0x0B; >> } >> >> #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP >> void ana_comp_isr(void) >> { >> ?//analog comparator compare event >> ?while(1) >> ?{ >> ? ? DECIMAL_POINT |= DP2; >> ? ? ?for(x=0;x<=250;x++){;} >> ? ? DECIMAL_POINT &= ~DP2; >> ? ? ?for(x=0;x<=250;x++){;} >> ?} >> } >> >> >> Any ideas? Global interrupts are set. >> >> Thanks.... >> >> >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From richard-lists at imagecraft.com Wed Mar 18 22:45:41 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Mar 19 10:52:14 2009 Subject: [Icc-avr] XP invalid pointer In-Reply-To: <49C22B00.8090607@norsk-display.com> References: <9A0C89DFDA91443083F9FD3731D88726@valeport.local> <8238C08C7D245243BD124393093F67257F4338@vp-server> <49C22B00.8090607@norsk-display.com> Message-ID: <200903191852.n2JIqCZ7039468@mail.imagecraft.com> Try deleting c:\iccv7avr\bin\editors.ini. Let me know if it does fix the problem and whether you have made any changes using Tools->EditorOptions.... At 03:22 AM 3/19/2009, Claus Wahl / Norsk Display AS wrote: >Hi, >I've got a strange problem after installing on a new XPsp3 machine: > >The v7.20A opens normally, usb key is found and the project file is >opened as normal. >The source file, however is opened without displaying the content of >the file. When trying to open the source file, an error window >states "invalid pointer operation". > >I had this problem also with v7.20 > >We're using the built-in editor. > >Any solutions? // richard From j_baraclough at zetnet.co.uk Thu Mar 19 10:11:53 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Mar 19 11:19:11 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> Message-ID: <49C28AE9.9010405@zetnet.co.uk> Hi Paul, I've never used the AC so I'm only guessing. What is connected to AIN0 & AIN1? They should both be inside the GND to VCC range. Have you tried using the internal 2.56V bandgap reference instead of AIN0? All the best for now, John Paul Mateer wrote: > Well I tried that....did not help. > I just noticed too that no matter how I set the detect, it always > seems to be in the "toggle" mode!!! > > I don't understand what the heck is going on here! I've been fighting > this stupid thing all morning now! What am I doing wrong???? > > > From paul.aa9gg at gmail.com Thu Mar 19 10:13:19 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 11:20:38 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> Message-ID: <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> Am I fighting a compiler bug??? Was using ver 7.19, just d/led v7.20 no differance. On Thu, Mar 19, 2009 at 12:24 PM, Paul Mateer wrote: > Well I tried that....did not help. > I just noticed too that no matter how I set the detect, it always > seems to be in the "toggle" mode!!! > > I don't understand what the heck is going on here! I've been fighting > this stupid thing all morning now! What am I doing wrong???? > > > On Thu, Mar 19, 2009 at 11:48 AM, John Baraclough > wrote: >> Hi Paul, >> >> You code looks good and I don't know if this helps, but there is an errata >> entry for the Analog Comparator in the latest mega32 data sheet (p 343). It >> suggests disabling and re-enabling the AC after startup. >> >> All the best for now, >> John >> >> >> Paul Mateer wrote: >>> >>> Hello all.... >>> I am trying to use the analog comparator in a project, but can't seem >>> to get the interrupt to fire. I can see the flag set in the ACSR, but >>> it never seems to vector to the interrupt routine. Here is my setup: >>> >>> //Comparator initialize >>> // trigger on: Rising output edge >>> void comparator_init(void) >>> { >>> ?ACSR = 0; >>> ?ACSR = 0x0B; >>> } >>> >>> #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP >>> void ana_comp_isr(void) >>> { >>> ?//analog comparator compare event >>> ?while(1) >>> ?{ >>> ? ? DECIMAL_POINT |= DP2; >>> ? ? ?for(x=0;x<=250;x++){;} >>> ? ? DECIMAL_POINT &= ~DP2; >>> ? ? ?for(x=0;x<=250;x++){;} >>> ?} >>> } >>> >>> >>> Any ideas? Global interrupts are set. >>> >>> Thanks.... >>> >>> >>> >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > > > > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From j_baraclough at zetnet.co.uk Thu Mar 19 10:35:19 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Mar 19 11:42:39 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> Message-ID: <49C29067.3050607@zetnet.co.uk> Hi Paul, Have a look at the assembler in the list file and see what's being generated. All the best for now, John Paul Mateer wrote: > Am I fighting a compiler bug??? Was using ver 7.19, just d/led v7.20 > no differance. > > From paul.aa9gg at gmail.com Thu Mar 19 10:38:53 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 11:46:11 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <49C28AE9.9010405@zetnet.co.uk> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <49C28AE9.9010405@zetnet.co.uk> Message-ID: <20f5efc40903191138r288a10bcrfd8422ccf6e48362@mail.gmail.com> This is my first time too. I have 2 separate voltage dividers connected to AIN0 and AIN1. AIN0 is at 1.47vdc and AIN1 is at 1.94vdc. I currently have my main loop spitting out the value of ACSR and I do see ACO and ACI set as AIN1 is lowered, but the interrupt never fires. My current init is: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0x80; for(x=0;x<=500;x++){;} ACSR = 0x00; ACSR = 0x03; ACSR = 0x1B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } On Thu, Mar 19, 2009 at 1:11 PM, John Baraclough wrote: > Hi Paul, > > I've never used the AC so I'm only guessing. What is connected to AIN0 & > AIN1? They should both be inside the GND to VCC range. Have you tried using > the internal 2.56V bandgap reference instead of AIN0? > > All the best for now, > John > > > Paul Mateer wrote: >> >> Well I tried that....did not help. >> I just noticed too that no matter how I set the detect, it always >> seems to be in the "toggle" mode!!! >> >> I don't understand what the heck is going on here! I've been fighting >> this stupid thing all morning now! What am I doing wrong???? >> >> >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From paul.aa9gg at gmail.com Thu Mar 19 11:10:04 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 12:17:21 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <49C29067.3050607@zetnet.co.uk> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> Message-ID: <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> OK...not sure what I'm looking at and am confused: (0060) //Comparator initialize (0061) // trigger on: Rising output edge (0062) void comparator_init(void) (0063) { (0064) ACSR = 0x00; _comparator_init: 22C 2422 CLR R2 22D B828 OUT 0x08,R2 (0065) ACSR = 0x0B; 22E E08B LDI R24,0xB 22F B988 OUT 0x08,R24 230 9508 RET (0066) (0067) } _ana_comp_isr: 92E 938A ST -Y,R24 92F 939A ST -Y,R25 930 B78F IN R24,0x3F 931 938A ST -Y,R24 (0059) } (0060) (0061) //---------------------------------------------------------------------- (0062) #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP (0063) void ana_comp_isr(void) (0064) { (0065) //analog comparator compare event (0066) comp_test = comp_test + 1; 932 9180 0060 LDS R24,comp_test 934 9190 0061 LDS R25,comp_test+1 936 9601 ADIW R24,1 937 9390 0061 STS comp_test+1,R25 939 9380 0060 STS comp_test,R24 93B 9189 LD R24,Y+ 93C BF8F OUT 0x3F,R24 93D 9199 LD R25,Y+ 93E 9189 LD R24,Y+ 93F 9518 RETI On Thu, Mar 19, 2009 at 1:35 PM, John Baraclough wrote: > Hi Paul, > > Have a look at the assembler in the list file and see what's being > generated. > > All the best for now, > John > > > Paul Mateer wrote: >> >> Am I fighting a compiler bug??? ?Was using ver 7.19, just d/led v7.20 >> no differance. >> >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From j_baraclough at zetnet.co.uk Thu Mar 19 12:03:55 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Mar 19 13:11:15 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> Message-ID: <49C2A52B.8000306@zetnet.co.uk> Hi Paul, Well it's not a compiler bug as that code is writing the correct values to the correct location for ACSR ($08). The only thing I can suggest is to try the following initalisation. It's a bit of brute force but it may work. //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0x13; // Enable AC and clear ACI bit for(x=0;x<50;x++) // Delay some to make sure it's taken effect. ; ACSR = 0x80; // Disable AC. for(x=0;x<50;x++) ; ACSR = 0x13; // Enable AC and clear ACI bit. for(x=0;x<50;x++) ; ACSR = 0x1B; // Enable AC, clear ACI bit and set ACIE bit. } HTH All the best for now, John Paul Mateer wrote: > OK...not sure what I'm looking at and am confused: > > (0060) //Comparator initialize > (0061) // trigger on: Rising output edge > (0062) void comparator_init(void) > (0063) { > (0064) ACSR = 0x00; > _comparator_init: > 22C 2422 CLR R2 > 22D B828 OUT 0x08,R2 > (0065) ACSR = 0x0B; > 22E E08B LDI R24,0xB > 22F B988 OUT 0x08,R24 > 230 9508 RET > (0066) > (0067) } > > > _ana_comp_isr: > 92E 938A ST -Y,R24 > 92F 939A ST -Y,R25 > 930 B78F IN R24,0x3F > 931 938A ST -Y,R24 > (0059) } > (0060) > (0061) //---------------------------------------------------------------------- > (0062) #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP > (0063) void ana_comp_isr(void) > (0064) { > (0065) //analog comparator compare event > (0066) comp_test = comp_test + 1; > 932 9180 0060 LDS R24,comp_test > 934 9190 0061 LDS R25,comp_test+1 > 936 9601 ADIW R24,1 > 937 9390 0061 STS comp_test+1,R25 > 939 9380 0060 STS comp_test,R24 > 93B 9189 LD R24,Y+ > 93C BF8F OUT 0x3F,R24 > 93D 9199 LD R25,Y+ > 93E 9189 LD R24,Y+ > 93F 9518 RETI > > > > > From paul.aa9gg at gmail.com Thu Mar 19 12:17:53 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 13:25:11 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <49C2A52B.8000306@zetnet.co.uk> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> <49C2A52B.8000306@zetnet.co.uk> Message-ID: <20f5efc40903191317n705c97abo5610c89c11642289@mail.gmail.com> Well...that did not work either! I tried enabling the ICP (ACIC) and it DOES trigger THAT interrupt! This just doesn't make sense. On Thu, Mar 19, 2009 at 3:03 PM, John Baraclough wrote: > Hi Paul, > > Well it's not a compiler bug as that code is writing the correct values to > the correct location for ACSR ($08). The only thing I can suggest is to try > the following initalisation. It's a bit of brute force but it may work. > > //Comparator initialize > // trigger on: Rising output edge > void comparator_init(void) > { > ACSR = 0x13; ? ? ? ? ? // Enable AC and clear ACI bit > for(x=0;x<50;x++) ? ? ?// Delay some to make sure it's taken effect. > ?; > > ACSR = 0x80; ? ? ? ? ? // Disable AC. > for(x=0;x<50;x++) > ?; > > ACSR = 0x13; ? ? ? ? ? // Enable AC and clear ACI bit. > for(x=0;x<50;x++) > ?; > > ACSR = 0x1B; ? ? ? ? ? // Enable AC, clear ACI bit and set ACIE bit. > } > > HTH > > All the best for now, > John > > > > Paul Mateer wrote: >> >> OK...not sure what I'm looking at and am confused: >> >> (0060) //Comparator initialize >> (0061) // trigger on: Rising output edge >> (0062) void comparator_init(void) >> (0063) { >> (0064) ?ACSR = 0x00; >> _comparator_init: >> ? ? 22C 2422 ? ? ?CLR ?R2 >> ? ? 22D B828 ? ? ?OUT ?0x08,R2 >> (0065) ?ACSR = 0x0B; >> ? ? 22E E08B ? ? ?LDI ?R24,0xB >> ? ? 22F B988 ? ? ?OUT ?0x08,R24 >> ? ? 230 9508 ? ? ?RET >> (0066) >> (0067) } >> >> >> _ana_comp_isr: >> ? ? 92E 938A ? ? ?ST ? -Y,R24 >> ? ? 92F 939A ? ? ?ST ? -Y,R25 >> ? ? 930 B78F ? ? ?IN ? R24,0x3F >> ? ? 931 938A ? ? ?ST ? -Y,R24 >> (0059) } >> (0060) >> (0061) >> //---------------------------------------------------------------------- >> (0062) #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP >> (0063) void ana_comp_isr(void) >> (0064) { >> (0065) ?//analog comparator compare event >> (0066) ? ?comp_test = comp_test + 1; >> ? ? 932 9180 0060 LDS ?R24,comp_test >> ? ? 934 9190 0061 LDS ?R25,comp_test+1 >> ? ? 936 9601 ? ? ?ADIW R24,1 >> ? ? 937 9390 0061 STS ?comp_test+1,R25 >> ? ? 939 9380 0060 STS ?comp_test,R24 >> ? ? 93B 9189 ? ? ?LD ? R24,Y+ >> ? ? 93C BF8F ? ? ?OUT ?0x3F,R24 >> ? ? 93D 9199 ? ? ?LD ? R25,Y+ >> ? ? 93E 9189 ? ? ?LD ? R24,Y+ >> ? ? 93F 9518 ? ? ?RETI >> >> >> >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From richard-lists at imagecraft.com Thu Mar 19 01:19:34 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Mar 19 13:26:06 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <49C2A52B.8000306@zetnet.co.uk> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> <49C2A52B.8000306@zetnet.co.uk> Message-ID: <200903192126.n2JLQ5pM041346@mail.imagecraft.com> At 12:03 PM 3/19/2009, John Baraclough wrote: >Hi Paul, > >Well it's not a compiler bug as that code is writing the correct >values to the correct location for ACSR ($08). The only thing I can >suggest is to try the following initalisation. It's a bit of brute >force but it may work. The compiler always get suspected :-) Thanks for helping, John. Paul, sorry I can't contribute. I presume you have set the correct device etc.? Check Project->Options->Target just to make sure. Do make sure you don't have interrupt disable somewhere accidentally? // richard From paul.aa9gg at gmail.com Thu Mar 19 12:32:52 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 19 13:40:10 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <200903192126.n2JLQ5pM041346@mail.imagecraft.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> <49C2A52B.8000306@zetnet.co.uk> <200903192126.n2JLQ5pM041346@mail.imagecraft.com> Message-ID: <20f5efc40903191332j15c88e71oaec45e51472c0008@mail.gmail.com> How/where can i tell if it is vectoring to the proper ISR ( vector # 19, @ 0x024)? On Thu, Mar 19, 2009 at 4:19 AM, Richard Man wrote: > At 12:03 PM 3/19/2009, John Baraclough wrote: >> >> Hi Paul, >> >> Well it's not a compiler bug as that code is writing the correct values to >> the correct location for ACSR ($08). The only thing I can suggest is to try >> the following initalisation. It's a bit of brute force but it may work. > > The compiler always get suspected :-) > > Thanks for helping, John. > > Paul, sorry I can't contribute. I presume you have set the correct device > etc.? Check Project->Options->Target just to make sure. Do make sure you > don't have interrupt disable somewhere accidentally? > > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From j_baraclough at zetnet.co.uk Thu Mar 19 12:42:45 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Mar 19 13:50:04 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903191317n705c97abo5610c89c11642289@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> <49C27744.4060307@zetnet.co.uk> <20f5efc40903191024q1d52cf26vb250f0b67f66a936@mail.gmail.com> <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> <49C2A52B.8000306@zetnet.co.uk> <20f5efc40903191317n705c97abo5610c89c11642289@mail.gmail.com> Message-ID: <49C2AE45.2030400@zetnet.co.uk> Hi Paul, Sorry, but the only idea I've got left is to try another chip (from a different batch if possible). I'm just off to collect my wife from her evening class, but will be back here in about an hour. You must be coming to the end of your working day by now. All the best for now, John Paul Mateer wrote: > Well...that did not work either! I tried enabling the ICP (ACIC) and > it DOES trigger THAT interrupt! This just doesn't make sense. > > From jassenbaum at htp-tel.de Thu Mar 19 14:43:36 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Thu Mar 19 15:50:53 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt References: <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> Message-ID: I had similar with other edge sensing interrupt on mega16 once ago, and I remember solution was to do the init not by single one-in-all setup, but step-by-step: 1. clear device interrupt flag 2. setup edge detector (IS bits) (2a. give device time to settle) 3. clear device interrupt flag 4. if interrupt flag still set, then loop from 2 or re-init 5. enable device interrupt As mega32 is same chip generation as mega16, I'd try something like this: void comparator_init(void) { char ACI_timeout = 0; ACSR = 0x00; delay(); ACSR = 0x03; // setup for rising edge delay(); while ((ACSR & BIT(ACI)) && !ACI_timeout) { // add timeout code here // ACSR = 0x13; // clear interrupt flag delay(); } ACSR = 0xB; // enable device interrupt } with "delay();" longer than AC worst case propagation delay, which is not documented. "Typ." are 500-750ns... Hope it helps. Best regards, Johannes > OK...not sure what I'm looking at and am confused: > (0060) //Comparator initialize > (0061) // trigger on: Rising output edge > (0062) void comparator_init(void) > (0063) { > (0064) ACSR = 0x00; > _comparator_init: > 22C 2422 CLR R2 > 22D B828 OUT 0x08,R2 > (0065) ACSR = 0x0B; > 22E E08B LDI R24,0xB > 22F B988 OUT 0x08,R24 > 230 9508 RET > (0066) > (0067) } > _ana_comp_isr: > 92E 938A ST -Y,R24 > 92F 939A ST -Y,R25 > 930 B78F IN R24,0x3F > 931 938A ST -Y,R24 > (0059) } > (0060) > (0061) //---------------------------------------------------------------------- > (0062) #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP > (0063) void ana_comp_isr(void) > (0064) { > (0065) //analog comparator compare event > (0066) comp_test = comp_test + 1; > 932 9180 0060 LDS R24,comp_test > 934 9190 0061 LDS R25,comp_test+1 > 936 9601 ADIW R24,1 > 937 9390 0061 STS comp_test+1,R25 > 939 9380 0060 STS comp_test,R24 > 93B 9189 LD R24,Y+ > 93C BF8F OUT 0x3F,R24 > 93D 9199 LD R25,Y+ > 93E 9189 LD R24,Y+ > 93F 9518 RETI > On Thu, Mar 19, 2009 at 1:35 PM, John Baraclough > wrote: >> Hi Paul, >> >> Have a look at the assembler in the list file and see what's being >> generated. >> >> All the best for now, >> John >> >> >> Paul Mateer wrote: >>> >>> Am I fighting a compiler bug??? ?Was using ver 7.19, just d/led v7.20 >>> no differance. >>> >>> >> >> _______________________________________________ >> Icc-avr mailing list >> Icc-avr@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-avr >> > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From claus at norsk-display.com Thu Mar 19 15:11:06 2009 From: claus at norsk-display.com (Claus Wahl / Norsk Display AS) Date: Thu Mar 19 16:18:27 2009 Subject: [Fwd: Re: VS: [Icc-avr] XP invalid pointer] Message-ID: <49C2D10A.6050801@norsk-display.com> Hi, Richard No help Originally, I did no alterations to the editor preferences and options. It seems that some files are ok, most are not. The original ICC files (header files) seem to be normally loaded, while most of our own files gives a fatal error while loading. I suspect that the files are marked in some strange way, but then why not all? I do not understand this at all. Could it be some file coding?? It seems like new files made in the IDE OR WordPad are ok, but if I copy the content of a bad file into it, it goes bad. I will install on a similar PC and see how things go there. best regards Claus > -----Opprinnelig melding----- > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > P? vegne av Richard Man > Sendt: 19. mars 2009 07:46 > Til: icc-avr@imagecraft.com > Emne: Re: [Icc-avr] XP invalid pointer > > Try deleting c:\iccv7avr\bin\editors.ini. Let me know if it does fix the > problem and whether you have made any changes using > Tools->EditorOptions.... > > > At 03:22 AM 3/19/2009, Claus Wahl / Norsk Display AS wrote: > >> Hi, >> I've got a strange problem after installing on a new XPsp3 machine: >> >> The v7.20A opens normally, usb key is found and the project file is >> opened as normal. >> The source file, however is opened without displaying the content of >> the file. When trying to open the source file, an error window >> states "invalid pointer operation". >> >> I had this problem also with v7.20 >> >> We're using the built-in editor. >> >> Any solutions? >> > > // richard > > > _______________________________________________ > 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/20090320/fc01a62f/attachment.html From paul.aa9gg at gmail.com Fri Mar 20 06:22:58 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Fri Mar 20 07:30:18 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: References: <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> Message-ID: <20f5efc40903200722n68e392dwd09873eefa002713@mail.gmail.com> Well....that didn't work either. No matter what I do the AC interrupt does not fire. I can get the ICP (ACIC) interrupt to work with no problem. It seems to me that it is a vector issue. How/where in the .lst file can i tell if it is vectoring to the proper ISR for the ACI( vector #19, @ 0x024)? On Thu, Mar 19, 2009 at 5:43 PM, Johannes Assenbaum wrote: > I had similar with other edge sensing interrupt on mega16 once ago, and I remember solution was to do the init not by single one-in-all setup, but step-by-step: > 1. clear device interrupt flag > 2. setup edge detector (IS bits) > (2a. give device time to settle) > 3. clear device interrupt flag > 4. if interrupt flag still set, then loop from 2 or re-init > 5. enable device interrupt > > As mega32 is same chip generation as mega16, I'd try something like this: > > void comparator_init(void) > { > ?char ACI_timeout = 0; > > ?ACSR = 0x00; > ?delay(); > ?ACSR = 0x03; // setup for rising edge > ?delay(); > ?while ((ACSR & BIT(ACI)) && !ACI_timeout) > ?{ > ?// add timeout code here > ?// > ?ACSR = 0x13; // clear interrupt flag > ?delay(); > ?} > ?ACSR = 0xB; // enable device interrupt > } > > with "delay();" longer than AC worst case propagation delay, which is not documented. "Typ." are 500-750ns... > > Hope it helps. > > Best regards, > Johannes > > >> OK...not sure what I'm looking at and am confused: > >> (0060) //Comparator initialize >> (0061) // trigger on: Rising output edge >> (0062) void comparator_init(void) >> (0063) { >> (0064) ?ACSR = 0x00; >> _comparator_init: >> ? ? ?22C 2422 ? ? ?CLR ? ? ? ?R2 >> ? ? ?22D B828 ? ? ?OUT ? ? ? ?0x08,R2 >> (0065) ?ACSR = 0x0B; >> ? ? ?22E E08B ? ? ?LDI ? ? ? ?R24,0xB >> ? ? ?22F B988 ? ? ?OUT ? ? ? ?0x08,R24 >> ? ? ?230 9508 ? ? ?RET >> (0066) >> (0067) } > > >> _ana_comp_isr: >> ? ? ?92E 938A ? ? ?ST -Y,R24 >> ? ? ?92F 939A ? ? ?ST -Y,R25 >> ? ? ?930 B78F ? ? ?IN R24,0x3F >> ? ? ?931 938A ? ? ?ST -Y,R24 >> (0059) } >> (0060) >> (0061) //---------------------------------------------------------------------- >> (0062) #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP >> (0063) void ana_comp_isr(void) >> (0064) { >> (0065) ?//analog comparator compare event >> (0066) ? ?comp_test = comp_test + 1; >> ? ? ?932 9180 0060 LDS ? ? ? ?R24,comp_test >> ? ? ?934 9190 0061 LDS ? ? ? ?R25,comp_test+1 >> ? ? ?936 9601 ? ? ?ADIW ? ? ? R24,1 >> ? ? ?937 9390 0061 STS ? ? ? ?comp_test+1,R25 >> ? ? ?939 9380 0060 STS ? ? ? ?comp_test,R24 >> ? ? ?93B 9189 ? ? ?LD R24,Y+ >> ? ? ?93C BF8F ? ? ?OUT ? ? ? ?0x3F,R24 >> ? ? ?93D 9199 ? ? ?LD R25,Y+ >> ? ? ?93E 9189 ? ? ?LD R24,Y+ >> ? ? ?93F 9518 ? ? ?RETI > > >> On Thu, Mar 19, 2009 at 1:35 PM, John Baraclough >> wrote: >>> Hi Paul, >>> >>> Have a look at the assembler in the list file and see what's being >>> generated. >>> >>> All the best for now, >>> John >>> >>> >>> Paul Mateer wrote: >>>> >>>> Am I fighting a compiler bug??? ?Was using ver 7.19, just d/led v7.20 >>>> no differance. >>>> >>>> >>> >>> _______________________________________________ >>> Icc-avr mailing list >>> Icc-avr@imagecraft.com >>> http://dragonsgate.net/mailman/listinfo/icc-avr >>> > > > >> -- >> Paul Mateer, AA9GG >> Elan Engineering Corp. >> www.elanengr.com > >> _______________________________________________ >> 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 From j_baraclough at zetnet.co.uk Fri Mar 20 06:59:51 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Mar 20 08:07:13 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903200722n68e392dwd09873eefa002713@mail.gmail.com> References: <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> <20f5efc40903200722n68e392dwd09873eefa002713@mail.gmail.com> Message-ID: <49C3AF67.9050702@zetnet.co.uk> Hi Paul, This is becoming a bit of a saga isn't it and it's just about to get worse!. As far as I know, you can't see the contents of the jump table in the .lst file. However, if you load the code into the AVR Studio simulator, you can see the jump table there. It normally consists of a series of JMP insructions, but may also contain some code if other interrupts are not used. You will have to follow the JMP instruction to see if it leads to the correct code for the ISR and is the same as you see in the .lst file. All the best for now, John Paul Mateer wrote: > Well....that didn't work either. No matter what I do the AC interrupt > does not fire. I can get the ICP (ACIC) interrupt to work with no > problem. It seems to me that it is a vector issue. How/where in the > .lst file can i tell if it is vectoring to the proper ISR for the ACI( > vector #19, @ 0x024)? > From paul.aa9gg at gmail.com Fri Mar 20 07:44:18 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Fri Mar 20 08:51:36 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <49C3AF67.9050702@zetnet.co.uk> References: <20f5efc40903191113t292a138fx885bf34d34c68858@mail.gmail.com> <49C29067.3050607@zetnet.co.uk> <20f5efc40903191210v17405392yc97f3e87aef428a3@mail.gmail.com> <20f5efc40903200722n68e392dwd09873eefa002713@mail.gmail.com> <49C3AF67.9050702@zetnet.co.uk> Message-ID: <20f5efc40903200844q7db6e4abya6780563bee49710@mail.gmail.com> I give up on this one. I've spun my wheels for 2 days($$$) now trying to get this simple thing to work. Since the flag does set, I'm just going to poll for it. Thank you both, Johannes and John, for your help. Maybe someone else might want to play with the AC interrupt (mega32) and see if they have any problems. thanks again On Fri, Mar 20, 2009 at 9:59 AM, John Baraclough wrote: > Hi Paul, > > This is becoming a bit of a saga isn't it and it's just about to get worse!. > As far as I know, you can't see the contents of the jump table in the .lst > file. However, if you load the code into the AVR Studio simulator, you can > see the jump table there. It normally consists of a series of JMP > insructions, but may also contain some code if other interrupts are not > used. You will have to follow the JMP instruction to see if it leads to the > correct code for the ISR and is the same as you see in the .lst file. > > All the best for now, > John > > > Paul Mateer wrote: >> >> Well....that didn't work either. ?No matter what I do the AC interrupt >> does not fire. ?I can get the ICP (ACIC) interrupt to work with no >> problem. ?It seems to me that it is a vector issue. ? How/where in the >> .lst file can i tell if it is vectoring to the proper ISR for the ACI( >> vector #19, @ 0x024)? >> > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From claus at norsk-display.com Fri Mar 20 12:59:33 2009 From: claus at norsk-display.com (Claus Wahl / Norsk Display AS) Date: Fri Mar 20 14:07:02 2009 Subject: [Icc-avr] XP invalid pointer Message-ID: <49C403B5.2080006@norsk-display.com> Hi - The solution was to remove all traces of ICCAVR, and then re-install. I reinstalled twice before without any luck, this time did a more thorough removal. Now it accepts all files, so I guess you were on the right track, Richard. This was probably an oddity - an as always: Thanks for a good product. We have made tens of thousands of displays and installed in most counties, - and have a workhorse of a compiler. If some problem should be addressed, it would be the possibility to compile for a similar processor and make it work 98%...A pity then that a misplaced or moved bit could be wrongfully accepted. A bad programming practice, I know, but it has been supported by Atmel & compiler(s). I'm looking forward to implementing a better practice for the Xmega this year! all the best Claus -------- Opprinnelig melding -------- Emne: [Fwd: Re: VS: [Icc-avr] XP invalid pointer] Dato: Fri, 20 Mar 2009 00:11:06 +0100 Fra: Claus Wahl / Norsk Display AS Svar-Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this. Organisasjon: Norsk Display AS Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribe to icc-announce if you are a member of this. Hi, Richard No help Originally, I did no alterations to the editor preferences and options. It seems that some files are ok, most are not. The original ICC files (header files) seem to be normally loaded, while most of our own files gives a fatal error while loading. I suspect that the files are marked in some strange way, but then why not all? I do not understand this at all. Could it be some file coding?? It seems like new files made in the IDE OR WordPad are ok, but if I copy the content of a bad file into it, it goes bad. I will install on a similar PC and see how things go there. best regards Claus > -----Opprinnelig melding----- > Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > P? vegne av Richard Man > Sendt: 19. mars 2009 07:46 > Til: icc-avr@imagecraft.com > Emne: Re: [Icc-avr] XP invalid pointer > > Try deleting c:\iccv7avr\bin\editors.ini. Let me know if it does fix the > problem and whether you have made any changes using > Tools->EditorOptions.... > > > At 03:22 AM 3/19/2009, Claus Wahl / Norsk Display AS wrote: > >> Hi, >> I've got a strange problem after installing on a new XPsp3 machine: >> >> The v7.20A opens normally, usb key is found and the project file is >> opened as normal. >> The source file, however is opened without displaying the content of >> the file. When trying to open the source file, an error window >> states "invalid pointer operation". >> >> I had this problem also with v7.20 >> >> We're using the built-in editor. >> >> Any solutions? >> > > // richard > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > > > > From lvcep at arnet.com.ar Fri Mar 20 13:44:32 2009 From: lvcep at arnet.com.ar (Claudio E Palumbo) Date: Fri Mar 20 14:52:17 2009 Subject: [Icc-avr] float conversion References: <49C403B5.2080006@norsk-display.com> Message-ID: <001901c9a9a5$0dfb49c0$0400000a@labelius> Hi, somebody knows how I can convert a float (4 bytes size, AVR) variable to double (8 bytes size, PC) ? Thanks in advance Saluda atte. CEP Claudio E Palumbo lvcep@hotmail.com lvcep@hotmail.com From owena99 at gmail.com Sat Mar 21 04:52:46 2009 From: owena99 at gmail.com (owena99) Date: Sat Mar 21 06:00:15 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt In-Reply-To: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> References: <20f5efc40903190901re9c53fcr98841ef5997ce592@mail.gmail.com> Message-ID: Hello all.... I am trying to use the analog comparator in a project, but can't seem to get the interrupt to fire. I can see the flag set in the ACSR, but it never seems to vector to the interrupt routine. Here is my setup: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0; ACSR = 0x0B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } Any ideas? Global interrupts are set. Thanks.... This works ok on the Tiny11 with the ICCTINY compiler and may need modifying for the mega16/32 I am sure I have also had simular code working the on the mega16 only for debugging purposes but can not find a copy. >From the tiny11 code: // ???*** DO NOT INADVERTABLY ENABLE PULLUPS ON ANALOG COMPARATOR PINS ***??? char I=0; #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { // set flag and Keep code in ISR routine to minimum! I=1; } CLI(); //Comparator init ACSR = ACSR & 0xF7;//ensure interrupt is off before changing ACSR = 0x0B; SEI(); I am getting forgetful but I seem to recollect that Avrstudio will ignore a breakpoint in the analogue comparator ISR when using jtagiceMk2 or the simulator when the interrupt condition is met on the analogue comparator pins. I find you have to debug the ANA ISR in real time (toggle a pin with a Led attached to it from within the isr) or manually set the interrupt flag in studio to enter the isr when debugging in studio. Regards, Owen. From owena99 at gmail.com Sat Mar 21 14:41:55 2009 From: owena99 at gmail.com (owena99) Date: Sat Mar 21 15:49:36 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt Message-ID: Hello all.... I am trying to use the analog comparator in a project, but can't seem to get the interrupt to fire. I can see the flag set in the ACSR, but it never seems to vector to the interrupt routine. Here is my setup: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0; ACSR = 0x0B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } Any ideas? Global interrupts are set. Thanks.... Sending again did not make the list the first time! This works ok on the Tiny11 with the ICCTINY compiler and may need modifying for the mega16/32 I am sure I have also had simular code working the on the mega16 only for debugging purposes but can not find a copy. >From the tiny11 code: // ??*** DO NOT INADVERTABLY ENABLE PULLUPS ON ANALOG COMPARATOR PINS ***?? char I=0; #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { // set flag and Keep code in ISR routine to minimum! I=1; } CLI(); //Comparator init ACSR = ACSR & 0xF7;//ensure interrupt is off before changing ACSR = 0x0B; SEI(); I am getting forgetful but I seem to recollect that Avrstudio will ignore a breakpoint in the analogue comparator ISR when using jtagiceMk2 or the simulator when the interrupt condition is met on the analogue comparator pins. I find you have to debug the ANA ISR in real time (toggle a pin with a Led attached to it from within the isr) or manually set the interrupt flag in studio to enter the isr when debugging in studio. Regards, Owen. From owena99 at gmail.com Sun Mar 22 18:33:37 2009 From: owena99 at gmail.com (owena99) Date: Sun Mar 22 19:41:07 2009 Subject: [Icc-avr] FW: Using ATMega32 Comparator Interrupt Message-ID: Hello all.... I am trying to use the analog comparator in a project, but can't seem to get the interrupt to fire. I can see the flag set in the ACSR, but it never seems to vector to the interrupt routine. Here is my setup: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0; ACSR = 0x0B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } Any ideas? Global interrupts are set. Thanks.... Sending again did not make the list the first time! This works ok on the Tiny11 with the ICCTINY compiler and may need modifying for the mega16/32 I am sure I have also had simular code working the on the mega16 only for debugging purposes but can not find a copy. >From the tiny11 code: // ??*** DO NOT INADVERTABLY ENABLE PULLUPS ON ANALOG COMPARATOR PINS ***?? char I=0; #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { // set flag and Keep code in ISR routine to minimum! I=1; } CLI(); //Comparator init ACSR = ACSR & 0xF7;//ensure interrupt is off before changing ACSR = 0x0B; SEI(); I am getting forgetful but I seem to recollect that Avrstudio will ignore a breakpoint in the analogue comparator ISR when using jtagiceMk2 or the simulator when the interrupt condition is met on the analogue comparator pins. I find you have to debug the ANA ISR in real time (toggle a pin with a Led attached to it from within the isr) or manually set the interrupt flag in studio to enter the isr when debugging in studio. Regards, Owen. From richard at imagecraft.com Sun Mar 22 07:58:10 2009 From: richard at imagecraft.com (Richard Man) Date: Sun Mar 22 20:05:24 2009 Subject: [Icc-avr] RIP: Everett Greene, ICC Consultant Message-ID: <200903230405.n2N45MuX038093@mail.imagecraft.com> It's with a heavy heart that I am reporting the passing of a friend and a consultant to ImageCraft. Besides being a personal friend, Everett wrote all the command line simulators for the ImageCraft products, allowing fast testing of the compilers and he wrote all products' low level floating point libraries except for ARM and the Propeller. He will be missed. If you wish to send his family (addressing Ms. Greene is fine) a card, you can send it to me and I will forward it to the family. Richard Man ImageCraft 706 Colorado Ave Palo Alto, CA 94303 // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From owena99 at gmail.com Mon Mar 23 02:39:37 2009 From: owena99 at gmail.com (owena99) Date: Mon Mar 23 03:47:09 2009 Subject: [Icc-avr] Test Post Message-ID: I have not been able to post lately? Owen. From owena99 at gmail.com Mon Mar 23 02:50:43 2009 From: owena99 at gmail.com (owena99) Date: Mon Mar 23 03:58:14 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt Message-ID: Hello all.... I am trying to use the analog comparator in a project, but can't seem to get the interrupt to fire. I can see the flag set in the ACSR, but it never seems to vector to the interrupt routine. Here is my setup: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0; ACSR = 0x0B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } Any ideas? Global interrupts are set. Thanks.... Sending again did not make the list the first time! This works ok on the Tiny11 with the ICCTINY compiler and may need modifying for the mega16/32 I am sure I have also had simular code working the on the mega16 only for debugging purposes but can not find a copy. >From the tiny11 code: // ??*** DO NOT INADVERTABLY ENABLE PULLUPS ON ANALOG COMPARATOR PINS ***?? char I=0; #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { // set flag and Keep code in ISR routine to minimum! I=1; } CLI(); //Comparator init ACSR = ACSR & 0xF7;//ensure interrupt is off before changing ACSR = 0x0B; SEI(); I am getting forgetful but I seem to recollect that Avrstudio will ignore a breakpoint in the analogue comparator ISR when using jtagiceMk2 or the simulator when the interrupt condition is met on the analogue comparator pins. I find you have to debug the ANA ISR in real time (toggle a pin with a Led attached to it from within the isr) or manually set the interrupt flag in studio to enter the isr when debugging in studio. Regards, Owen. From owena99 at gmail.com Mon Mar 23 02:59:25 2009 From: owena99 at gmail.com (OWEN ALLISON) Date: Mon Mar 23 04:06:47 2009 Subject: [Icc-avr] Using ATMega32 Comparator Interrupt Message-ID: <4ba8b7010903230359h368cac96yd9497ad4b5b87c38@mail.gmail.com> Sending again did not make the list the first time! This works ok on the Tiny11 with the ICCTINY compiler and may need modifying for the mega16/32 I am sure I have also had simular code working the on the mega16 only for debugging purposes but can not find a copy. >From the tiny11 code: // ??*** DO NOT INADVERTABLY ENABLE PULLUPS ON ANALOG COMPARATOR PINS ***?? char I=0; #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { // set flag and Keep code in ISR routine to minimum! I=1; } CLI(); //Comparator init ACSR = ACSR & 0xF7;//ensure interrupt is off before changing ACSR = 0x0B; SEI(); I am getting forgetful but I seem to recollect that Avrstudio will ignore a breakpoint in the analogue comparator ISR when using jtagiceMk2 or the simulator when the interrupt condition is met on the analogue comparator pins. I find you have to debug the ANA ISR in real time (toggle a pin with a Led attached to it from within the isr) or manually set the interrupt flag in studio to enter the isr when debugging in studio. Regards, Owen. Hello all.... I am trying to use the analog comparator in a project, but can't seem to get the interrupt to fire. I can see the flag set in the ACSR, but it never seems to vector to the interrupt routine. Here is my setup: //Comparator initialize // trigger on: Rising output edge void comparator_init(void) { ACSR = 0; ACSR = 0x0B; } #pragma interrupt_handler ana_comp_isr:iv_ANA_COMP void ana_comp_isr(void) { //analog comparator compare event while(1) { DECIMAL_POINT |= DP2; for(x=0;x<=250;x++){;} DECIMAL_POINT &= ~DP2; for(x=0;x<=250;x++){;} } } Any ideas? Global interrupts are set. Thanks.... From j_baraclough at zetnet.co.uk Mon Mar 23 03:01:15 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Mar 23 04:08:40 2009 Subject: [Icc-avr] Test Post In-Reply-To: References: Message-ID: <49C76BFB.4040900@zetnet.co.uk> Yes you have. Did you recently change the email address from which you post and forget to re-register with the list? All the best for now, John owena99 wrote: > I have not been able to post lately? > Owen. > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > From owena99 at gmail.com Mon Mar 23 03:53:36 2009 From: owena99 at gmail.com (owena99) Date: Mon Mar 23 05:01:09 2009 Subject: [Icc-avr] Test Post In-Reply-To: <49C76BFB.4040900@zetnet.co.uk> References: <49C76BFB.4040900@zetnet.co.uk> Message-ID: Hi John, Has the post on Using ATMega32 Comparator Interrupt got through to the list I am not seeing any return of posts at all. I have changed my email address a few months ago and did re register, have been receiving posts on the new address but have not tried to post to the list until 2 days ago. The Imagecraft site seems to have been down for the last couple of days and is now up again, just tried to find the area to re-register but could not find it on the Imagecraft site probably male blindness!. Regards Owen. Owen Allison. Yes you have. Did you recently change the email address from which you post and forget to re-register with the list? All the best for now, John owena99 wrote: > I have not been able to post lately? > Owen. > > _______________________________________________ > 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 From j_baraclough at zetnet.co.uk Mon Mar 23 05:15:30 2009 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Mar 23 06:22:54 2009 Subject: [Icc-avr] Test Post In-Reply-To: References: <49C76BFB.4040900@zetnet.co.uk> Message-ID: <49C78B72.7050301@zetnet.co.uk> Yes. They've all got through. I'm sure it's an issue with the email address that the listserver is expecting. It's a problem that only Richard can sort out. All the best for now, John owena99 wrote: > Hi John, > Has the post on Using ATMega32 Comparator Interrupt got > through to the list I am not seeing any return of posts at all. > I have changed my email address a few months ago and did re register, have > been receiving posts on the new address but have not tried to post to the > list until 2 days ago. > The Imagecraft site seems to have been down for the last couple of days and > is now up again, just tried to find the area to re-register but could not > find it on the Imagecraft site probably male blindness!. > > Regards Owen. > > Owen Allison. > > > Yes you have. Did you recently change the email address from which you > post and forget to re-register with the list? > > All the best for now, > John > > > owena99 wrote: > >> I have not been able to post lately? >> Owen. >> >> _______________________________________________ >> 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 > > > From Albert.vanVeen at pertronic.co.nz Mon Mar 23 11:16:21 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Mon Mar 23 12:23:47 2009 Subject: [Icc-avr] Test Post In-Reply-To: References: <49C76BFB.4040900@zetnet.co.uk> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063F20@sbs.pertronic.local> Yes, we've seen about 6 of those, wondering if you were leaning on the keys a bit long... Albert. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of owena99 Sent: Tuesday, March 24, 2009 12:54 AM 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] Test Post Hi John, Has the post on Using ATMega32 Comparator Interrupt got through to the list I am not seeing any return of posts at all. I have changed my email address a few months ago and did re register, have been receiving posts on the new address but have not tried to post to the list until 2 days ago. The Imagecraft site seems to have been down for the last couple of days and is now up again, just tried to find the area to re-register but could not find it on the Imagecraft site probably male blindness!. Regards Owen. Owen Allison. Yes you have. Did you recently change the email address from which you post and forget to re-register with the list? All the best for now, John owena99 wrote: > I have not been able to post lately? > Owen. > > _______________________________________________ > 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 -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter, and is believed to be clean. From andrew_166 at msn.com Mon Mar 23 13:42:15 2009 From: andrew_166 at msn.com (denso123) Date: Mon Mar 23 14:49:33 2009 Subject: [Icc-avr] Atmel AES Bootloader CRC Help. In-Reply-To: <0MKpCa-1LaD8M3j0s-0001BT@mrelay.perfora.net> References: <0MKpCa-1LaD8M3j0s-0001BT@mrelay.perfora.net> Message-ID: Hi, I have ported the Atmel AES bootloader to ICCAVR and so far is seems to be working, apart from the CRC routine. Sometimes it passes the application memory as fine, other times it returns with a fault, i am wondering if a registry is getting changed as as the crc is running and thus why it is hit and miss. I was wondering if the CRC routine, which is written in assembler, needs modifying for ICCAVR? although it works fine when i use it to crc my packets of data when the application is boot loaded. Can somebody see anything wrong with the CRC routine (NB; i am using an ATmega 640, don't think this will make any difference) ***************************************************** CODE *************************************** // Polynome used in CRC calculations CRCPOLYNOME = 0x8005 _CRC:: ldi r19, 0x08 ldi R26, CRCPOLYNOME CRC_Loop: ; Rotate left. If MSb is 1 -> divide with Generator-polynome. lsl r18 rol r16 rol r17 brcc CRC_SkipEor eor r16, R26 eor r17, r27 CRC_SkipEor: dec r19 brne CRC_Loop ret To check the application space is valid the following code is run: - unsigned int crc = 0x00; const unsigned char *p = (const unsigned char *)0x000000; const unsigned char *n = (const unsigned char *)MEM_SIZE; do { crc = CRC(crc, *p++); } while (--n); where MEM_SIZE is equal to 57344 as i am using a 4K word bootloader space so that would be 65536-8192 = the 57344. i am not sure if the pointers i have defined *p and *n should be flash pointers and thus defined as __flash? Any help on this would be could Andy From richard-lists at imagecraft.com Mon Mar 23 02:51:02 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Mon Mar 23 14:58:20 2009 Subject: [Icc-avr] Atmel AES Bootloader CRC Help. In-Reply-To: References: <0MKpCa-1LaD8M3j0s-0001BT@mrelay.perfora.net> Message-ID: <200903232258.n2NMwI70061056@mail.imagecraft.com> If you use 7.15 or later and did not have the :"Treat const as __flash," then "p" should definiely be __flash unsigned char *p; "n" should be an int, not a pointer. If you ever deference n in your code (i.e. *n) then it definitely can be the source of your error: int n = MEM_SIZE; and it's neither const or __flash. It's a read/writable variable. Did you specify "Fill unused bytes with.."? Otherwise, the cell content is 0xFF? At 01:42 PM 3/23/2009, denso123 wrote: >Hi, > >I have ported the Atmel AES bootloader to ICCAVR and so far is seems >to be working, apart from the CRC routine. Sometimes it passes the >application memory as fine, other times it returns with a fault, i >am wondering if a registry is getting changed as as the crc is >running and thus why it is hit and miss. > >I was wondering if the CRC routine, which is written in assembler, >needs modifying for ICCAVR? although it works fine when i use it to >crc my packets of data when the application is boot loaded. Can >somebody see anything wrong with the CRC routine (NB; i am using an >ATmega 640, don't think this will make any difference) > >***************************************************** CODE >*************************************** > >// Polynome used in CRC calculations >CRCPOLYNOME = 0x8005 > >_CRC:: > ldi r19, 0x08 > ldi R26, ldi r27, >CRCPOLYNOME > >CRC_Loop: > ; Rotate left. If MSb is 1 -> divide with Generator-polynome. > lsl r18 > rol r16 > rol r17 > brcc CRC_SkipEor > > eor r16, R26 > eor r17, r27 > >CRC_SkipEor: > dec r19 > brne CRC_Loop > ret > >To check the application space is valid the following code is run: - > >unsigned int crc = 0x00; > >const unsigned char *p = (const unsigned char *)0x000000; >const unsigned char *n = (const unsigned char *)MEM_SIZE; > >do >{ >crc = CRC(crc, *p++); >} >while (--n); > >where MEM_SIZE is equal to 57344 as i am using a 4K word bootloader >space so that would be 65536-8192 >= the 57344. > >i am not sure if the pointers i have defined *p and *n should be >flash pointers and thus defined as __flash? > >Any help on this would be could > >Andy > // richard From andrew_166 at msn.com Mon Mar 23 14:07:48 2009 From: andrew_166 at msn.com (denso123) Date: Mon Mar 23 15:15:07 2009 Subject: [Icc-avr] Atmel AES Bootloader CRC Help. In-Reply-To: <200903232258.n2NMwI70061056@mail.imagecraft.com> References: <0MKpCa-1LaD8M3j0s-0001BT@mrelay.perfora.net> <200903232258.n2NMwI70061056@mail.imagecraft.com> Message-ID: Hi Richard, Thanks for the fast response (great support as usual :) ): - "Did you specify "Fill unused bytes with.."? Otherwise, the cell content is 0xFF?" I am guessing you mean when i am making the encrypted Hex using the Atmel PC Software, I must tell it to fill the rest of the un used space with nothing? If so i will check that. This is how Atmel wrote the code for the IAR complier: - unsigned int crc = 0; unsigned char APPFLASH *p = (unsigned char APPFLASH *)0x000000; unsigned char APPFLASH *n = (unsigned char APPFLASH *)MEM_SIZE; do { crc = CRC(crc, *p++); } while (--n); where APPFLASH #if MEM_SIZE < 65536 #define BOOTFLASH __flash #define APPFLASH __flash #else #define BOOTFLASH __farflash #define APPFLASH __hugeflash #endif For ICCAVR are you saying i need the following: - __flash unsigned char *p = 0; unsigned int *n = MEM_SIZE; in the assembly i sent you as i am rubbish at it, is Atmel using and registers that are different in ICCAVR than in IAR that may cause a problem (r19, r25, r16 etc)? NOTE: I Am using the latest ICCAVR 7.20A (with advanced dongle) and i have Treat const as __flash," -------------------------------------------------- From: "Richard Man" Sent: Monday, March 23, 2009 10:51 AM To: Subject: Re: [Icc-avr] Atmel AES Bootloader CRC Help. > If you use 7.15 or later and did not have the :"Treat const as __flash," > then "p" should definiely be > > __flash unsigned char *p; > > "n" should be an int, not a pointer. If you ever deference n in your code > (i.e. *n) then it definitely can be the source of your error: > > int n = MEM_SIZE; > > and it's neither const or __flash. It's a read/writable variable. > > Did you specify "Fill unused bytes with.."? Otherwise, the cell content is > 0xFF? > > > At 01:42 PM 3/23/2009, denso123 wrote: >>Hi, >> >>I have ported the Atmel AES bootloader to ICCAVR and so far is seems to be >>working, apart from the CRC routine. Sometimes it passes the application >>memory as fine, other times it returns with a fault, i am wondering if a >>registry is getting changed as as the crc is running and thus why it is >>hit and miss. >> >>I was wondering if the CRC routine, which is written in assembler, needs >>modifying for ICCAVR? although it works fine when i use it to crc my >>packets of data when the application is boot loaded. Can somebody see >>anything wrong with the CRC routine (NB; i am using an ATmega 640, don't >>think this will make any difference) >> >>***************************************************** CODE >>*************************************** >> >>// Polynome used in CRC calculations >>CRCPOLYNOME = 0x8005 >> >>_CRC:: >> ldi r19, 0x08 >> ldi R26, > ldi r27, >CRCPOLYNOME >> >>CRC_Loop: >> ; Rotate left. If MSb is 1 -> divide with Generator-polynome. >> lsl r18 >> rol r16 >> rol r17 >> brcc CRC_SkipEor >> >> eor r16, R26 >> eor r17, r27 >> >>CRC_SkipEor: >> dec r19 >> brne CRC_Loop >> ret >> >>To check the application space is valid the following code is run: - >> >>unsigned int crc = 0x00; >> >>const unsigned char *p = (const unsigned char *)0x000000; >>const unsigned char *n = (const unsigned char *)MEM_SIZE; >> >>do >>{ >>crc = CRC(crc, *p++); >>} >>while (--n); >> >>where MEM_SIZE is equal to 57344 as i am using a 4K word bootloader space >>so that would be 65536-8192 >>= the 57344. >> >>i am not sure if the pointers i have defined *p and *n should be flash >>pointers and thus defined as __flash? >> >>Any help on this would be could >> >>Andy >> > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > From andrew_166 at msn.com Tue Mar 24 09:59:25 2009 From: andrew_166 at msn.com (denso123) Date: Tue Mar 24 11:06:48 2009 Subject: [Icc-avr] Atmel AES Bootloader CRC Help. In-Reply-To: References: <0MKpCa-1LaD8M3j0s-0001BT@mrelay.perfora.net><200903232258.n2NMwI70061056@mail.imagecraft.com> Message-ID: Hi, i have looked at the memory map information for may application and it say's that : - "flash size is 65536 bytes (64KB) - 8648 bytes reserved for a boot loader = 56888 bytes as 100%" Surely this is wrong as i have looked at the memory map information for my boot loader and i get : - "flash size is 8192 bytes (8KB) (Boot Loader)" Thus the Application space available should be = 65536 - 8192 = 57344 Bytes???? am i missing something or is this an error? if so is the error a simple math's mistake or will this impact on the hex file produced? Thanks, ANdy -------------------------------------------------- From: "denso123" Sent: Monday, March 23, 2009 10:07 PM 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] Atmel AES Bootloader CRC Help. > Hi Richard, > > Thanks for the fast response (great support as usual :) ): - > > "Did you specify "Fill unused bytes with.."? Otherwise, the cell > content is 0xFF?" > > I am guessing you mean when i am making the encrypted Hex using the Atmel > PC Software, I must tell it to fill the rest of the un used space with > nothing? If so i will check that. > > This is how Atmel wrote the code for the IAR complier: - > > unsigned int crc = 0; > unsigned char APPFLASH *p = (unsigned char APPFLASH *)0x000000; > unsigned char APPFLASH *n = (unsigned char APPFLASH *)MEM_SIZE; > > do > { > crc = CRC(crc, *p++); > } > while (--n); > > where APPFLASH > > #if MEM_SIZE < 65536 > #define BOOTFLASH __flash > #define APPFLASH __flash > #else > #define BOOTFLASH __farflash > #define APPFLASH __hugeflash > #endif > > For ICCAVR are you saying i need the following: - > > __flash unsigned char *p = 0; > unsigned int *n = MEM_SIZE; > > in the assembly i sent you as i am rubbish at it, is Atmel using and > registers that are different in ICCAVR than in IAR that may cause a > problem (r19, r25, r16 etc)? > > NOTE: I Am using the latest ICCAVR 7.20A (with advanced dongle) and i have > Treat const as __flash," > > > > -------------------------------------------------- > From: "Richard Man" > Sent: Monday, March 23, 2009 10:51 AM > To: > Subject: Re: [Icc-avr] Atmel AES Bootloader CRC Help. > >> If you use 7.15 or later and did not have the :"Treat const as __flash," >> then "p" should definiely be >> >> __flash unsigned char *p; >> >> "n" should be an int, not a pointer. If you ever deference n in your code >> (i.e. *n) then it definitely can be the source of your error: >> >> int n = MEM_SIZE; >> >> and it's neither const or __flash. It's a read/writable variable. >> >> Did you specify "Fill unused bytes with.."? Otherwise, the cell content >> is 0xFF? >> >> >> At 01:42 PM 3/23/2009, denso123 wrote: >>>Hi, >>> >>>I have ported the Atmel AES bootloader to ICCAVR and so far is seems to >>>be working, apart from the CRC routine. Sometimes it passes the >>>application memory as fine, other times it returns with a fault, i am >>>wondering if a registry is getting changed as as the crc is running and >>>thus why it is hit and miss. >>> >>>I was wondering if the CRC routine, which is written in assembler, needs >>>modifying for ICCAVR? although it works fine when i use it to crc my >>>packets of data when the application is boot loaded. Can somebody see >>>anything wrong with the CRC routine (NB; i am using an ATmega 640, don't >>>think this will make any difference) >>> >>>***************************************************** CODE >>>*************************************** >>> >>>// Polynome used in CRC calculations >>>CRCPOLYNOME = 0x8005 >>> >>>_CRC:: >>> ldi r19, 0x08 >>> ldi R26, >> ldi r27, >CRCPOLYNOME >>> >>>CRC_Loop: >>> ; Rotate left. If MSb is 1 -> divide with Generator-polynome. >>> lsl r18 >>> rol r16 >>> rol r17 >>> brcc CRC_SkipEor >>> >>> eor r16, R26 >>> eor r17, r27 >>> >>>CRC_SkipEor: >>> dec r19 >>> brne CRC_Loop >>> ret >>> >>>To check the application space is valid the following code is run: - >>> >>>unsigned int crc = 0x00; >>> >>>const unsigned char *p = (const unsigned char *)0x000000; >>>const unsigned char *n = (const unsigned char *)MEM_SIZE; >>> >>>do >>>{ >>>crc = CRC(crc, *p++); >>>} >>>while (--n); >>> >>>where MEM_SIZE is equal to 57344 as i am using a 4K word bootloader space >>>so that would be 65536-8192 >>>= the 57344. >>> >>>i am not sure if the pointers i have defined *p and *n should be flash >>>pointers and thus defined as __flash? >>> >>>Any help on this would be could >>> >>>Andy >>> >> >> // richard >> >> _______________________________________________ >> 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 > From bobgardner at aol.com Thu Mar 26 10:17:27 2009 From: bobgardner at aol.com (bobgardner@aol.com) Date: Thu Mar 26 11:25:10 2009 Subject: [Icc-avr] One big c file vs lots of little files Message-ID: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> Back in the day of line editors and small memory, standard procedure was to carve a project up into modules, which were usually files, which had one or more subroutines or functions that were probably related somehow. Once these were debugged, you could just add that module in the make file and the linker would link it in. Nowdays, computers are fast and it isnt a problem editing the c source to a program that might compile to 32 or 64 or 128k of binary. This goes against the standard practice of lots of small c and h and obj files, but I hereby submit my two reasons why I like this technique. One is iccv7avr specific. First, configuration management seems a LOT less error prone if I have a directory called widget32, and in that dir is a widget32.prj and a widget32.c and a widget32.hex, etc etc. Secondly, the iccv7avr compiler will use an rcall if possible instead of a call, which saves a cycle and a word of flash. It cant do this if the call is in another file. So if speed and space are valuable, then use the one big source file technique. Rebuttals? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090326/a921aa69/attachment.html From richard-lists at imagecraft.com Thu Mar 26 00:06:04 2009 From: richard-lists at imagecraft.com (Richard Man) Date: Thu Mar 26 12:12:47 2009 Subject: [Icc-avr] One big c file vs lots of little files In-Reply-To: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> References: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> Message-ID: <200903262012.n2QKCkKk036917@mail.imagecraft.com> a) it's a better programming practice to modularize. b) a future compiler version will optimize CALLs to RCALLs At 10:17 AM 3/26/2009, bobgardner@aol.com wrote: >Back in the day of line editors and small memory, standard procedure >was to carve a project up into modules, which were usually files, >which had one or more subroutines or functions that were probably >related somehow. Once these were debugged, you could just add that >module in the make file and the linker would link it in. Nowdays, >computers are fast and it isnt a problem editing the c source to a >program that might compile to 32 or 64 or 128k of binary. This goes >against the standard practice of lots of small c and h and obj >files, but I hereby submit my two reasons why I like this technique. >One is iccv7avr specific. First, configuration management seems a >LOT less error prone if I have a directory called widget32, and in >that dir is a widget32.prj and a widget32.c and a widget32.hex, etc >etc. Secondly, the iccv7avr compiler will use an rcall if possible >instead of a call, which saves a cycle and a word of flash. It cant >do this if the call is in another file. So if speed and space are >valuable, then use the one big source file technique. Rebuttals? // richard From paul.aa9gg at gmail.com Thu Mar 26 11:16:37 2009 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Mar 26 12:24:06 2009 Subject: [Icc-avr] One big c file vs lots of little files In-Reply-To: <200903262012.n2QKCkKk036917@mail.imagecraft.com> References: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> <200903262012.n2QKCkKk036917@mail.imagecraft.com> Message-ID: <20f5efc40903261216s14bd81e6o4dc707e1019f1a9b@mail.gmail.com> I have always use modules. On Thu, Mar 26, 2009 at 3:06 AM, Richard Man wrote: > a) it's a better programming practice to modularize. > b) a future compiler version will optimize CALLs to RCALLs > > At 10:17 AM 3/26/2009, bobgardner@aol.com wrote: >> >> Back in the day of line editors and small memory, standard procedure was >> to carve a project up into modules, which were usually files, which had one >> or more subroutines or functions that were probably related somehow. Once >> these were debugged, you could just add that module in the make file and the >> linker would link it in. Nowdays, computers are fast and it isnt a problem >> editing the c source to a program that might compile to 32 or 64 or 128k of >> binary. This goes against the standard practice of lots of small c and h and >> obj files, but I hereby submit my two reasons why I like this technique. One >> is iccv7avr specific. First, configuration management seems a LOT less error >> prone if I have a directory called widget32, and in that dir is a >> widget32.prj and a widget32.c and a widget32.hex, etc etc. Secondly, the >> iccv7avr compiler will use an rcall if possible instead of a call, which >> saves a cycle and a word of flash. It cant do this if the call is in another >> file. So if speed and space are valuable, then use the one big source file >> technique. Rebuttals? > > // richard > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com From Albert.vanVeen at pertronic.co.nz Thu Mar 26 11:37:50 2009 From: Albert.vanVeen at pertronic.co.nz (Albert vanVeen) Date: Thu Mar 26 12:45:19 2009 Subject: [Icc-avr] One big c file vs lots of little files In-Reply-To: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> References: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> Message-ID: <5F8515C5ED67B6439B4F93D7B5E08A36063F26@sbs.pertronic.local> Modules are not 1) a simple way of editing smaller files; 2) a theoretical nicety. Modules are pretty much necessary to achieve/keep maintainability and reuseability. Once a module works, you don't have to worry about that (those) functions anymore. The last 8 projects I've worked on each comprise about 10 modules, of which at most half are unique to that project. Not to mention sharing with colleagues. I also don't find editing big files is particularly handy. Albert. ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of bobgardner@aol.com Sent: Friday, March 27, 2009 07:17 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] One big c file vs lots of little files Back in the day of line editors and small memory, standard procedure was to carve a project up into modules, which were usually files, which had one or more subroutines or functions that were probably related somehow. Once these were debugged, you could just add that module in the make file and the linker would link it in. Nowdays, computers are fast and it isnt a problem editing the c source to a program that might compile to 32 or 64 or 128k of binary. This goes against the standard practice of lots of small c and h and obj files, but I hereby submit my two reasons why I like this technique. One is iccv7avr specific. First, configuration management seems a LOT less error prone if I have a directory called widget32, and in that dir is a widget32.prj and a widget32.c and a widget32.hex, etc etc. Secondly, the iccv7avr compiler will use an rcall if possible instead of a call, which saves a cycle and a word of flash. It cant do this if the call is in another file. So if speed ! and space are valuable, then use the one big source file technique. Rebuttals? ________________________________ Live traffic, local info, maps, directions and more with the NEW MapQuest Toolbar. Get it now ! -- This message has been scanned for viruses and dangerous content by Bizo EmailFilter , and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20090327/0f3cf687/attachment.html From jassenbaum at htp-tel.de Fri Mar 27 15:39:42 2009 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Mar 27 16:47:13 2009 Subject: [Icc-avr] One big c file vs lots of little files References: <8CB7C5641301900-1330-904@webmail-dg05.sysops.aol.com> Message-ID: If you are concerned about speed and space, then I don't think, that those few calls reduced to rcall, you may get from single source file, will be enough for a real solution. Just think of adding one single c line to get out of space again, or that target environment times signals a little bit different than your developement hardware... So if you are concerned about speed and space, then at the very first think of doing critical code in a different way. C as such is able to waste lots of space and speed, if you write suboptimal code, and even optimisers cannot help out then. And this is still independent of iccv7avr and other AVR compilers. Other question: What do you mean with errors prone if you use more than one source file? I'm using dozen of source files and more in a project directory without any problems quite normally. Best regards, Johannes > Back in the day of line editors and small memory, standard procedure was to carve a > project up into modules, which were usually files, which had one or more > subroutines or functions that were probably related somehow. Once these were > debugged, you could just add that module in the make file and the linker would link > it in. Nowdays, computers are fast and it isnt a problem editing the c source to a > program that might compile to 32 or 64 or 128k of binary. This goes against the > standard practice of lots of small c and h and obj files, but I hereby submit my > two reasons why I like this technique. One is iccv7avr specific. First, > configuration management seems a LOT less error prone if I have a directory called > widget32, and in that dir is a widget32.prj and a widget32.c and a widget32.hex, > etc etc. Secondly, the iccv7avr compiler will use an rcall if possible instead of a > call, which saves a cycle and a word of flash. It cant do this if the call is in > another file. So if speed ! > and space are valuable, then use the one big source file technique. Rebuttals?