From bjonaspero at hotmail.com Tue Apr 1 04:02:46 2008 From: bjonaspero at hotmail.com (=?iso-8859-1?Q?Bj=F6rn_Lindgren?=) Date: Tue Apr 1 05:02:48 2008 Subject: [Icc-avr] Incredibly slow AVRISP mkII In-Reply-To: <200803281220.m2SCKZf2030813@mail.imagecraft.com> References: <200803281220.m2SCKZf2030813@mail.imagecraft.com> Message-ID: This isn't the right forum, I know, but I've posted this to Atmel and it seems to take more than a few days to get an answer. So if someone have an answer to this, I'm greatful.Why is my new programming-interface 11 times slower than myold? New: AVRISP mkII (USB) with updated firmware 1.09 Old: AVRISP(COM-port) with firmware 2.0A To program an ATmega32 (mostly with 0x00)it takes 17 minutes!! With the old AVRISP the same file takes 1 minuteand 30 seconds (when using a simple SI-prog-interface from ImageCraft'scompiler the same thing takes 21 seconds). RegardsBj?rn Lindgren _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080401/646b84c2/attachment.html From tim at sabretechnology.co.uk Tue Apr 1 04:24:28 2008 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Apr 1 05:24:35 2008 Subject: [Icc-avr] Incredibly slow AVRISP mkII Message-ID: <04671BB8D269034BBC4BB6BA8948672610AB00@sserver.SabreTechnology.local> Bj?rn Lindgren wrote: > This isn't the right forum, I know, but I've posted this to Atmel and > it seems to take more than a few days to get an answer. So if someone > have an answer to this, I'm greatful. > > Why is my new programming-interface 11 times slower than my old? New: > AVRISP mkII (USB) with updated firmware 1.09 Old: AVRISP (COM-port) > with firmware 2.0A To program an ATmega32 (mostly with 0x00) it takes > 17 minutes!! With the old AVRISP the same file takes 1 minute and 30 > seconds (when using a simple SI-prog-interface from ImageCraft's > compiler the same thing takes 21 seconds). You need to set "ISP Freq" in the "Board" tab of the AVRISP dialog to something higher (1/4 of the system clock). It comes with it set very slow. -- Tim Mitchell tim@sabretechnology.co.uk http://www.sabretechnology.co.uk Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ Registered in England and Wales no.3131504 t:01482 801003 f:01482 801078 From BobGardner at aol.com Tue Apr 1 04:24:34 2008 From: BobGardner at aol.com (BobGardner@aol.com) Date: Tue Apr 1 05:31:44 2008 Subject: [Icc-avr] Incredibly slow AVRISP mkII Message-ID: Set the baudrate as high as it will go ====================================== In a message dated 4/1/2008 8:03:53 A.M. Eastern Daylight Time, bjonaspero@hotmail.com writes: Why is my new programming-interface 11 times slower than my old? **************Create a Home Theater Like the Pros. Watch the video on AOL Home. (http://home.aol.com/diy/home-improvement-eric-stromer?video=15&ncid=aolhom00030000000001) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080401/aab5727f/attachment.html From bobgardner at aol.com Tue Apr 1 09:27:24 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Apr 1 10:27:44 2008 Subject: [Icc-avr] iccavr comport range/usb com port number Message-ID: <8CA6234C8D5489C-924-2E0@webmail-md06.sysops.aol.com> I zapped the com1 on my iccavr machine... plugged it into the wrong place...? I'll try and use a USB serial port but it looks like its com9 or 10... can anyone think of a way to get the USB port down into the com1-4 range? I guess I should uninstall the driver for com1... maybe that would free it up? Anyway of getting more com port choices in the terminal window Richard? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080401/ae44ff5d/attachment.html From graham at altongate.co.uk Tue Apr 1 09:58:07 2008 From: graham at altongate.co.uk (Graham Whyte) Date: Tue Apr 1 10:58:45 2008 Subject: [Icc-avr] iccavr comport range/usb com port number In-Reply-To: <8CA6234C8D5489C-924-2E0@webmail-md06.sysops.aol.com> Message-ID: Hi Bob I use USB serial from time to time In its properties in device manager you can usually set it to any available port # There is a problem seeing which ports are already allocated to non-present devices You need to get device manager to reveal unused but allocated ports There could be many from previous bluetooth or cellphone installations for example This method below works really well Go to Control Panel / System Click Advanced tab Click Environment Variables button In Sytem Variables click New button Create a variable called DEVMGR_SHOW_NONPRESENT_DEVICES Set its value to 1 OK back out of everything Re-boot ??? Now if you go to Device Manager you can click View menu and check Show hidden devices You can now see all the unused com ports from previous installations These can be removed by right clicking and selecting Uninstall I had 14 dead ones last time I did this You should be able to free up down to com4 or less Then set the USB port # Graham -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com]On Behalf Of bobgardner@aol.com Sent: 01 April 2008 18:27 To: icc-avr@imagecraft.com Subject: [Icc-avr] iccavr comport range/usb com port number I zapped the com1 on my iccavr machine... plugged it into the wrong place... I'll try and use a USB serial port but it looks like its com9 or 10... can anyone think of a way to get the USB port down into the com1-4 range? I guess I should uninstall the driver for com1... maybe that would free it up? Anyway of getting more com port choices in the terminal window Richard? ---------------------------------------------------------------------------- ---- Planning your summer road trip? Check out AOL Travel Guides. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080401/3aee2e17/attachment.html From adobson at exponent.com Tue Apr 1 10:14:29 2008 From: adobson at exponent.com (Andrew Dobson) Date: Tue Apr 1 11:14:32 2008 Subject: [Icc-avr] iccavr comport range/usb com port number In-Reply-To: <8CA6234C8D5489C-924-2E0@webmail-md06.sysops.aol.com> Message-ID: To get the com port assignment to a more realistic number the procedure I use it to open device manager and expand the ports section, then look at the ports available to you and compare this to the ports the hardware has. The reason for this is so that you can identify an available com port without clashes with real physical devices. Select the USB com port you want to change, if you are unsure which one it is then unplug it and plug it back in while watching which port it enumerates to. Once you know which port it is then right click and select properties and when the ensuing window pops up select "Port Settings", in this window you need to select "Advanced..." and then in the bottom left of the window there is a drop down of available ports, if you click on it, it will show all ports up to 256, however, those that are already utilized will show up like "Com1 (in use)" etc. So, given that you know you only have one physical com port (COM1) you can select any other com port, even the ones in use, and force this USB serial port to that port after clicking on yes to this dialog box: "This COM name is being used by another device (such as another com port or modem). Using duplicate names can lead to inaccessible devices and changed settings. Do you want to continue?" The usual warnings apply to forcing use of a com port to one "in use", but if you know what hardware you currently have installed or USB devices plugged in then it would be safe to proceed. If your computer is anything like mine you should see multiple entries for com ports up to 10, even though you know they are not all currently available, i.e. the USB or Bluetooth devices are not plugged in. Hope this helps you regain control of your com ports. Regards, Andy. -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of bobgardner@aol.com Sent: Tuesday, April 01, 2008 10:27 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] iccavr comport range/usb com port number I zapped the com1 on my iccavr machine... plugged it into the wrong place... I'll try and use a USB serial port but it looks like its com9 or 10... can anyone think of a way to get the USB port down into the com1-4 range? I guess I should uninstall the driver for com1... maybe that would free it up? Anyway of getting more com port choices in the terminal window Richard? ________________________________ Planning your summer road trip? Check out AOL Travel Guides . From benra at imt.liu.se Tue Apr 1 21:49:57 2008 From: benra at imt.liu.se (Bengt Ragnemalm) Date: Tue Apr 1 22:49:44 2008 Subject: SV: [Icc-avr] iccavr comport range/usb com port number In-Reply-To: References: <8CA6234C8D5489C-924-2E0@webmail-md06.sysops.aol.com> Message-ID: <001b01c89485$624c2de0$b160ec82@Shagrat> Thanks Bob! I was aware of the problem but not that it was so easy to get rid of. I just tested (reboot is not necessary) and I had unused COM-ports from previous Bluetooth devices from 53 to 92! I am a little curious about what had happened with COM port 3 to 52 though. Do unused ports uninstall themselves with time? Maybe they sneak out through some cracks in the Windows. /Bengt _____ Fr?n: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] F?r Graham Whyte Skickat: den 1 april 2008 19:58 Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. ?mne: RE: [Icc-avr] iccavr comport range/usb com port number Hi Bob I use USB serial from time to time In its properties in device manager you can usually set it to any available port # There is a problem seeing which ports are already allocated to non-present devices You need to get device manager to reveal unused but allocated ports There could be many from previous bluetooth or cellphone installations for example This method below works really well Go to Control Panel / System Click Advanced tab Click Environment Variables button In Sytem Variables click New button Create a variable called DEVMGR_SHOW_NONPRESENT_DEVICES Set its value to 1 OK back out of everything Re-boot ??? Now if you go to Device Manager you can click View menu and check Show hidden devices You can now see all the unused com ports from previous installations These can be removed by right clicking and selecting Uninstall I had 14 dead ones last time I did this You should be able to free up down to com4 or less Then set the USB port # Graham -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com]On Behalf Of bobgardner@aol.com Sent: 01 April 2008 18:27 To: icc-avr@imagecraft.com Subject: [Icc-avr] iccavr comport range/usb com port number I zapped the com1 on my iccavr machine... plugged it into the wrong place... I'll try and use a USB serial port but it looks like its com9 or 10... can anyone think of a way to get the USB port down into the com1-4 range? I guess I should uninstall the driver for com1... maybe that would free it up? Anyway of getting more com port choices in the terminal window Richard? _____ Planning your summer road trip? Check out AOL Travel Guides. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080402/671b9461/attachment.html From richard at imagecraft.com Wed Apr 2 23:56:41 2008 From: richard at imagecraft.com (Richard Man) Date: Wed Apr 2 23:59:08 2008 Subject: [Icc-avr] eBox-AVR, a complete AVR kit Message-ID: <200804030759.m337x66v034939@mail.imagecraft.com> Know anyone starting with embedded design? Know any school that needs a complete embedded kit for their courses? Want to help support ImageCraft? Introducing eBox-AVR, a complete kit with an AVR ATMega16, keypad, LED, LCD and 10 example projects, even comes with a battery. To purchase and look at the amazingly cute yellow top tub it comes in, go to our website www.imagecraft.com, then click on Hardware, then "ImageCraft eBox" button. Thank you. // richard From fredrik.reinodt at comlink.se Fri Apr 4 04:11:25 2008 From: fredrik.reinodt at comlink.se (Comlink AB - Fredrik Reinodt) Date: Fri Apr 4 05:11:39 2008 Subject: [Icc-avr] csscanf return value Message-ID: <33AD11C8D1BE7F40AAF46BB9FC3530560A7F7C@obelix.ComLink.local> Hi I have a problem using csscanf() to parse incomming strings. It seems to me that the return value isn't the number of matched and assigned items, as described in standard C documentation for sscanf() (ImageCraft documentation says nothing about the return value). Looking in the C:\iccv7avr\libsrc.avr\libsrc library, I can see that _scanf() and cscanf() returns the variable 'converted', but csscanf() returns some pointer arithmetic (p - buf, I guess it's the number of read characters). Is that difference done on purpose, or is it a bug. Best regards /Fredrik Reinodt? From ivanv at realtimedesigns.com.au Mon Apr 7 17:58:25 2008 From: ivanv at realtimedesigns.com.au (Ivan Vernot) Date: Mon Apr 7 18:59:09 2008 Subject: [Icc-avr] How to get rid of Warning 'Illegal storage class const ' Message-ID: Hello All, I have just upgraded to latest ICCAVR 7.16A and am faced with 'upgrading' my code to take into account the new __flash keyword To get something compiling I enabled 'Treat 'const' as '_flash' option in Complier options but I get the following warnings never-the-less. !W D:\Real_Time_Designs\Clients\CathRx\3DREMO~1\Source\usart128.h(122):[warning ] Illegal storage class const for parameter 'data'. Storage class removed. Complains about the following function prototype extern void USART1_cputch(const INT8U data); and similarly !W D:\Real_Time_Designs\Clients\CathRx\3DREMO~1\Source\usart128.c(124):[warning ] Illegal storage class const for parameter 'data'. Storage class removed. Complains about the function void USART1_cputch(const INT8U data) { } 1. How do I stop it complaining about code that compiled without warning previously? 2. Is it safe to ignore these warnings? 3. Is there anything documented/discussed as to a possible strategy to upgrade existing code? Thank you in advance Ivan Vernot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080408/525d5454/attachment.html From ggreig at rossvideo.com Tue Apr 8 06:23:46 2008 From: ggreig at rossvideo.com (Glenn Greig) Date: Tue Apr 8 07:25:09 2008 Subject: [Icc-avr] How to get rid of Warning 'Illegal storage class const ' In-Reply-To: Message-ID: Hello Ivan - You do not need the const keyword in the examples you have given, since the parameter is passed by value. The const keyword is only meaningful (in an argument list) for parameters passed by reference (i.e. pointers). Cheers, Glenn -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com]On Behalf Of Ivan Vernot Sent: April 7, 2008 8:58 PM To: icc-avr@imagecraft.com Subject: [Icc-avr] How to get rid of Warning 'Illegal storage class const ' Hello All, I have just upgraded to latest ICCAVR 7.16A and am faced with 'upgrading' my code to take into account the new __flash keyword To get something compiling I enabled 'Treat 'const' as '_flash' option in Complier options but I get the following warnings never-the-less. !W D:\Real_Time_Designs\Clients\CathRx\3DREMO~1\Source\usart128.h(122):[warning] Illegal storage class const for parameter 'data'. Storage class removed. Complains about the following function prototype extern void USART1_cputch(const INT8U data); and similarly !W D:\Real_Time_Designs\Clients\CathRx\3DREMO~1\Source\usart128.c(124):[warning] Illegal storage class const for parameter 'data'. Storage class removed. Complains about the function void USART1_cputch(const INT8U data) { } 1. How do I stop it complaining about code that compiled without warning previously? 2. Is it safe to ignore these warnings? 3. Is there anything documented/discussed as to a possible strategy to upgrade existing code? Thank you in advance Ivan Vernot -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080408/3cdb029a/attachment.html From jassenbaum at htp-tel.de Wed Apr 9 15:47:27 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Apr 9 16:48:32 2008 Subject: [Icc-avr] OT: XMega A1 Evaluation and Application Board References: <7B0EB27CF1CC93439B5CFB7526E5D74C541CF6@mickey.PBNV.local> <0MKp8S-1JFZ4J2Bfx-0004Fk@mrelay.perfora.net> Message-ID: Hi all, who are interested in XMega, as A1 is on the run now, I'm not only having ideas about xmega eva and app boards but going to realize them. First will be a versatile A1 board, with basic features like this: * 100pin XMega A1 * on-board 3V regulator with Vin.max >= 30VDC/20VAC * on-board reference regulator connectable to AREF2 (PORTB) * on-board JTAG and PDI connectors (PORTB and more) * 2 DAC outputs to stereo plug (PORTB) * 8 ADC inputs from pin headers (PORTA) * external SRAM (128KB, LPC mode) by EBI * external LCD via pin headers (which are common?) by EBI * one of ports (PORTF?) used as system port with socket for a SD- or DataFlash-Card and IR-transceiver on-board * pin headers for AWEX ports (PORTC and PORTE) * couple of RS232 interfaces and one RS485 on-board (PORTD?) At the moment I'm still free for suggestions, so please feel free and tell me your wishes. Maybe there are some I can fulfill. Best regards, Johannes From Pirsch at synentec.com Wed Apr 9 22:29:03 2008 From: Pirsch at synentec.com (Pirsch) Date: Wed Apr 9 23:29:23 2008 Subject: AW: [Icc-avr] OT: XMega A1 Evaluation and Application Board In-Reply-To: Message-ID: What about an Interface for an Image Sensor (MT9M001 from Micron) for example regards Matthias Pirsch SynenTec GmbH Otto-Hahn-Str. 9a 25337 Elmshorn GERMANY Tel. +49-4121-4631112 Fax.+49-4121-4631111 Gesch?ftsf?hrung: Stefan Hummel, Matthias Pirsch St.-Nr.: 1829419754 / Amtsgericht PinnebergHRB 2536EL Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder dieses E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -----Urspr?ngliche Nachricht----- Von: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] Im Auftrag von Johannes Assenbaum Gesendet: Donnerstag, 10. April 2008 00:47 An: icc-avr@imagecraft.com Betreff: [Icc-avr] OT: XMega A1 Evaluation and Application Board Hi all, who are interested in XMega, as A1 is on the run now, I'm not only having ideas about xmega eva and app boards but going to realize them. First will be a versatile A1 board, with basic features like this: * 100pin XMega A1 * on-board 3V regulator with Vin.max >= 30VDC/20VAC * on-board reference regulator connectable to AREF2 (PORTB) * on-board JTAG and PDI connectors (PORTB and more) * 2 DAC outputs to stereo plug (PORTB) * 8 ADC inputs from pin headers (PORTA) * external SRAM (128KB, LPC mode) by EBI * external LCD via pin headers (which are common?) by EBI * one of ports (PORTF?) used as system port with socket for a SD- or DataFlash-Card and IR-transceiver on-board * pin headers for AWEX ports (PORTC and PORTE) * couple of RS232 interfaces and one RS485 on-board (PORTD?) At the moment I'm still free for suggestions, so please feel free and tell me your wishes. Maybe there are some I can fulfill. Best regards, Johannes _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From fletcherjones at worldonline.co.uk Thu Apr 10 02:32:26 2008 From: fletcherjones at worldonline.co.uk (Patrick Fletcher-Jones) Date: Thu Apr 10 03:32:45 2008 Subject: AW: [Icc-avr] OT: XMega A1 Evaluation and Application Board In-Reply-To: Message-ID: Yes I'd also vote for this interface. Patrick On 10/04/2008 06:29, "Pirsch" wrote: > What about an Interface for an Image Sensor (MT9M001 from Micron) for > example > > regards > > Matthias Pirsch > SynenTec GmbH > Otto-Hahn-Str. 9a > 25337 Elmshorn > GERMANY > > Tel. +49-4121-4631112 > Fax.+49-4121-4631111 > Gesch?ftsf?hrung: Stefan Hummel, Matthias Pirsch > St.-Nr.: 1829419754 / Amtsgericht PinnebergHRB 2536EL > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder dieses E-Mail > irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > -----Urspr?ngliche Nachricht----- > Von: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > Im Auftrag von Johannes Assenbaum > Gesendet: Donnerstag, 10. April 2008 00:47 > An: icc-avr@imagecraft.com > Betreff: [Icc-avr] OT: XMega A1 Evaluation and Application Board > > Hi all, who are interested in XMega, > > as A1 is on the run now, I'm not only having ideas about xmega eva and app > boards but going to realize them. First will be a versatile A1 board, with > basic features like this: > > * 100pin XMega A1 > * on-board 3V regulator with Vin.max >= 30VDC/20VAC > * on-board reference regulator connectable to AREF2 (PORTB) > * on-board JTAG and PDI connectors (PORTB and more) > * 2 DAC outputs to stereo plug (PORTB) > * 8 ADC inputs from pin headers (PORTA) > * external SRAM (128KB, LPC mode) by EBI > * external LCD via pin headers (which are common?) by EBI > * one of ports (PORTF?) used as system port with socket for a SD- or > DataFlash-Card and IR-transceiver on-board > * pin headers for AWEX ports (PORTC and PORTE) > * couple of RS232 interfaces and one RS485 on-board (PORTD?) > > At the moment I'm still free for suggestions, so please feel free and tell > me your wishes. Maybe there are some I can fulfill. > > Best regards, > Johannes > > > > _______________________________________________ > 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 Thu Apr 10 08:38:28 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Apr 10 09:38:50 2008 Subject: [Icc-avr] OT: XMega A1 Evaluation and Application Board In-Reply-To: References: <7B0EB27CF1CC93439B5CFB7526E5D74C541CF6@mickey.PBNV.local> <0MKp8S-1JFZ4J2Bfx-0004Fk@mrelay.perfora.net> Message-ID: <47FE3474.8020108@zetnet.co.uk> I would like the RS485 interface to be configurable for either half-duplex or full duplex (RS422) with optional pull-up, pull-down and termination resistors. This will cover all possible requirements and can easily be done with a MAX489, three resistors and a few links. Will you be fitting xm64, xm128 or xm256? All the best for now, John Johannes Assenbaum wrote: > Hi all, who are interested in XMega, > > as A1 is on the run now, I'm not only having ideas about xmega eva and app boards but going to realize them. First will be a versatile A1 board, with basic features like this: > > * 100pin XMega A1 > * on-board 3V regulator with Vin.max >= 30VDC/20VAC > * on-board reference regulator connectable to AREF2 (PORTB) > * on-board JTAG and PDI connectors (PORTB and more) > * 2 DAC outputs to stereo plug (PORTB) > * 8 ADC inputs from pin headers (PORTA) > * external SRAM (128KB, LPC mode) by EBI > * external LCD via pin headers (which are common?) by EBI > * one of ports (PORTF?) used as system port with socket for a SD- or DataFlash-Card and IR-transceiver on-board > * pin headers for AWEX ports (PORTC and PORTE) > * couple of RS232 interfaces and one RS485 on-board (PORTD?) > > At the moment I'm still free for suggestions, so please feel free and tell me your wishes. Maybe there are some I can fulfill. > > Best regards, > Johannes > > > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > > From BobGardner at aol.com Fri Apr 11 20:00:32 2008 From: BobGardner at aol.com (BobGardner@aol.com) Date: Fri Apr 11 21:00:55 2008 Subject: [Icc-avr] Any ucos users? Message-ID: Has anyone used ucos recently? Like since version 7.0? I think the ports on Micrium are sort of ancient... when the function pointers got added I think it added a word to the stack frame, which would mean the os assembler file needs to be massaged somehow. **************It's Tax Time! Get tips, forms and advice on AOL Money & Finance. (http://money.aol.com/tax?NCID=aolcmp00300000002850) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080411/f95581c3/attachment.html From jassenbaum at htp-tel.de Wed Apr 16 14:20:49 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Apr 16 15:22:01 2008 Subject: [Icc-avr] Header files update References: Message-ID: Hi all, there are new header files available for mega8HVA and mega16HVA at http://avr.jassenbaum.de/iccv7avr/index.html Best regards, Johannes From andrew_166 at msn.com Mon Apr 21 02:33:13 2008 From: andrew_166 at msn.com (Andrew) Date: Mon Apr 21 03:33:25 2008 Subject: [Icc-avr] USART SPI Master Message-ID: Hi, Is there or does anybody have an example (written in c) of setting up and using the USART as an SPI master? Thanks, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080421/66a98e60/attachment.html From andrew_166 at msn.com Mon Apr 21 03:31:38 2008 From: andrew_166 at msn.com (Andrew) Date: Mon Apr 21 04:31:50 2008 Subject: [Icc-avr] USART SPI Master References: Message-ID: Hi, I have written the following : - //----------------------------------------------------------------------------- // // Function name : uart2_SPI // // Returns : None // // Parameters : None // // Purpose : UART2 initialize as an SPI Master. // //----------------------------------------------------------------------------- void uart2_SPI(void) { // Baud rate must be set to 0 prior to enabling the USART as SPI // master, to ensure proper initialization of the XCK line. UBRR2 = 0; // Set XCK line to output, ie. set USART in master mode. DDRH |= BIT(4); // Set XCK (BIT(4)) as an output // Set USART to Master SPI mode. UCSR2C = (1 << UMSEL21) | (1 << UMSEL20); // Set clock polarity and phase to correct SPI mode. UCSR2C = (1 << UCPOL2) | (1 << UCPHA2); // // Enable RX and TX. UCSR2B = (1 << RXEN2) | (1 << TXEN2); // Set baud rate. Must be set _after_ enabling the transmitter. UBRR2 = 7; // Gives 1MHz } For some reason i am getting "undeclared identifier `UCPHA2'" in the ICCAVR compilier i am using an ATmega640 and i have included the correct header s: - #include // Include the ATmega 640 header file #include // Include ICCAVR's macro's libary header Can anybody see what i have done wrong, or is it simply that the ICCAVR header does not contain UCPHA2 and thus i must set the register maually? Thanks, Andy ----- Original Message ----- From: Andrew To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Sent: Monday, April 21, 2008 10:33 AM Subject: [Icc-avr] USART SPI Master Hi, Is there or does anybody have an example (written in c) of setting up and using the USART as an SPI master? Thanks, Andy ------------------------------------------------------------------------------ _______________________________________________ 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/20080421/68cd2728/attachment.html From jassenbaum at htp-tel.de Mon Apr 21 03:34:49 2008 From: jassenbaum at htp-tel.de (jassenbaum@htp-tel.de) Date: Mon Apr 21 04:35:28 2008 Subject: [Icc-avr] USART SPI Master In-Reply-To: References: Message-ID: <20080421123449.8zn8y91kwp6o0w4o@webmail.htp.net> How about searching the atmel app notes page and finding AVR317? Best regards, Johannes Quoting Andrew : > Hi, > > Is there or does anybody have an example (written in c) of setting > up and using the USART as an SPI master? > > Thanks, > > Andy From j_baraclough at zetnet.co.uk Mon Apr 21 04:51:58 2008 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Mon Apr 21 05:52:33 2008 Subject: [SPAM] Re: [Icc-avr] USART SPI Master In-Reply-To: References: Message-ID: <480C7FDE.40901@zetnet.co.uk> Hi Andy, A quick look at the latest header filers shows that the appropriate bit definitions are missing. I'm sure that Johannes is working on it but in the mean time you'll need to put in a manual definition in your code file: // Temporary fix - remove when header files updated. #define UDORD2 2 #define UCPHA2 1 #define UCPOL2 0 Once the new header files are in place you may get a re-definition warning, in which case you can remove the manual definition. HTH. John Andrew wrote: > Hi, > > I have written the following : - > > > //----------------------------------------------------------------------------- > // > // Function name : uart2_SPI > // > // Returns : None > // > // Parameters : None > // > // Purpose : UART2 initialize as an SPI Master. > // > //----------------------------------------------------------------------------- > *void* uart2_SPI(*void*) > { > // Baud rate must be set to 0 prior to enabling the USART as SPI > // master, to ensure proper initialization of the XCK line. > UBRR2 = 0; > > // Set XCK line to output, ie. set USART in master mode. > DDRH |= BIT(4); // Set XCK (BIT(4)) as an output > > // Set USART to Master SPI mode. > UCSR2C = (1 << UMSEL21) | (1 << UMSEL20); > > // Set clock polarity and phase to correct SPI mode. > UCSR2C = (1 << UCPOL2) | (1 << UCPHA2); // > > // Enable RX and TX. > UCSR2B = (1 << RXEN2) | (1 << TXEN2); > > // Set baud rate. Must be set _after_ enabling the transmitter. > UBRR2 = 7; // Gives 1MHz > > } > > For some reason i am getting "undeclared identifier `UCPHA2'" in the > ICCAVR compilier i am using an ATmega640 and i have included the > correct header s: - > > > #include // Include the ATmega 640 header file > #include // Include ICCAVR's macro's libary header > > Can anybody see what i have done wrong, or is it simply that the > ICCAVR header does not contain UCPHA2 and thus i must set the register > maually? > > > > Thanks, > > > > Andy > > From jassenbaum at htp-tel.de Tue Apr 22 15:14:59 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Apr 22 16:16:21 2008 Subject: [Icc-avr] Header files update References: Message-ID: Hi all, io header files are going to change some more this time. Please go http://avr.jassenbaum.de/iccv7avr/index.html to download the beta and tell me if anything goes wrong. Best regards, Johannes From ianjames at waitrose.com Sun Apr 27 07:00:23 2008 From: ianjames at waitrose.com (Ian) Date: Sun Apr 27 08:01:16 2008 Subject: [Icc-avr] Reading fuses on a mega168 Message-ID: Hi, Can anyone help with reading fuses on Mega168. I have tried the following method which was suggested by Johannes Assenbaum for a Mega88, unfortunately the results are incorrect! < readfusesbye.s> ; unsigned char readfusesbyte(unsigned int ioaddr, unsigned int fuseaddr); ; _readfusesbyte:: movw r26,r16 ; load X-pointer with ioaddr movw r30,r18 ; load Z-pointer with fuseaddr clr r18 ; clear interrupts-enabled flag brid readfusesbyte1 ldi r18,1 ; set interrupts-enabled flag cli ; disable interrupts readfusesbyte1: ldi r16,0x09 ; bit names change but not the values. Yet... st X,r16 ; write SPM control register lpm r16,Z ; read fuses sbrc r18,0 sei ; re-enable interrupts if enabled before ret unsigned char readfusesbyte(unsigned int ioaddr, unsigned int fuseaddr); void ReadFuseLock(void) { unsigned char Fuse[4]; _CLI(); // Read lock bits Fuse[0] = readfusesbyte(SPMCSR,0x0001); // Read low fuses bits Fuse[1] = readfusesbyte(SPMCSR,0x0000); // Read high fuses bits Fuse[2] = readfusesbyte(SPMCSR,0x0003); // Read extended fuses bits Fuse[3] = readfusesbyte(SPMCSR,0x0002); _SEI(); } -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From BobGardner at aol.com Sun Apr 27 08:40:21 2008 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sun Apr 27 09:41:04 2008 Subject: [Icc-avr] history of c Message-ID: Is there a technical reason that char functions like putchar tend to promote the chars to ints? putchar and getchar have 'always' had a return type of int. Some of this 'tradition' has to do with a historical desire to make everything an integer so it will run fast on a pdp11 I guess, but if I make a mistake and return a char instead of an int, does something break? Does the wrong half of the int get used as the return value if there is a size mismatch? I can see how you can return a char in an int, but how do you return an int in a char? What gets returned? The hi byte or the lo byte? **************Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos. (http://autos.aol.com/used?NCID=aolcmp00300000002851) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080427/6947461d/attachment.html From MDipperstein at CalAmp.com Mon Apr 28 14:06:53 2008 From: MDipperstein at CalAmp.com (Michael Dipperstein) Date: Mon Apr 28 15:07:34 2008 Subject: [Icc-avr] history of c In-Reply-To: Message-ID: I believe that putchar and getchar return int, because they have to be able to return EOF and EOF is an int. ICC will just give you the lsb if you cast an int to a char, but I think you'll loose the ability to distinguish between EOF and a normal character. -Mike -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: Sunday, April 27, 2008 8:40 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] history of c Is there a technical reason that char functions like putchar tend to promote the chars to ints? putchar and getchar have 'always' had a return type of int. Some of this 'tradition' has to do with a historical desire to make everything an integer so it will run fast on a pdp11 I guess, but if I make a mistake and return a char instead of an int, does something break? Does the wrong half of the int get used as the return value if there is a size mismatch? I can see how you can return a char in an int, but how do you return an int in a char? What gets returned? The hi byte or the lo byte? ________________________________ Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080428/7835d5f1/attachment.html From ianjames at waitrose.com Tue Apr 29 01:31:41 2008 From: ianjames at waitrose.com (Ian) Date: Tue Apr 29 02:32:24 2008 Subject: [Icc-avr] Reading fuses on Mega168 Message-ID: Hi, Following on from my previous post regarding reading fuses on the Mega168 I have found that passing the value 0x57 to the function readfusesbyte [unsigned char readfusesbyte(unsigned int ioaddr, unsigned int fuseaddr);] results in this: ; dbg[0] = readfusesbyte(0x57,0x0001); ldi R18,1 ldi R19,0 ldi R16,87 ldi R17,0 where as passing the value SPMCSR results in this: ; dbg[1] = readfusesbyte(SPMCSR,0x0000); clr R18 clr R19 in R16,0x37 clr R17 where SPMCSR is defined as /* SPM Control and Status Register */ #define SPMCSR (*(volatile unsigned char *)0x57) Can anyone shed any light on the anomaly?. I have included a partial copy of the .s file thus: ; unsigned char readfusesbyte(unsigned int ioaddr, unsigned int fuseaddr); ; ; void ReadFuseLock(void) ; { .dbline 22 ; _CLI(); cli .dbline 24 ; // Read lock bits ; dbg[0] = readfusesbyte(0x57,0x0001); ldi R18,1 ldi R19,0 ldi R16,87 ldi R17,0 xcall _readfusesbyte sts _dbg,R16 .dbline 27 ; ; // Read low fuses bits ; dbg[1] = readfusesbyte(SPMCSR,0x0000); clr R18 clr R19 in R16,0x37 clr R17 xcall _readfusesbyte sts _dbg+1,R16 .dbline 30 I would be grateful for an explaination as I am wondering if there are any other potential anomolies I should know about. Regards, Ian James -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From t.jaspers at cpseurope.com Tue Apr 29 01:43:15 2008 From: t.jaspers at cpseurope.com (Jaspers, Ton) Date: Tue Apr 29 02:43:57 2008 Subject: [Icc-avr] history of c In-Reply-To: Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C624507@mickey.PBNV.local> There is a reason. An 'int' is an undefined type. It is whatever your computer likes best. In other words what is most efficient on your system. On some systems it may be a 16 bit variable on others an 18 bit or a 32 bit variable. You never know unless you qualify it explicitly as in 'unsigned short int' or signed 'long int', etc.. So in all cases where the exact type does not matter we tend to use 'int' and allow the compiler to use what ever works best on a particular system. Obviously there are many cases where you need to define your variables exact. Always use modifiers in those cases such as 'unsigned', 'short', 'const' and lots more. It may help to typedef your variables, but then there are scholars that heavily oppose typedeffing. They argue that it hides valuable information. cheers, Ton PS I still have my first edition of K&R. Must have ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: zondag 27 april 2008 17:40 To: icc-avr@imagecraft.com Subject: [Icc-avr] history of c Is there a technical reason that char functions like putchar tend to promote the chars to ints? putchar and getchar have 'always' had a return type of int. Some of this 'tradition' has to do with a historical desire to make everything an integer so it will run fast on a pdp11 I guess, but if I make a mistake and return a char instead of an int, does something break? Does the wrong half of the int get used as the return value if there is a size mismatch? I can see how you can return a char in an int, but how do you return an int in a char? What gets returned? The hi byte or the lo byte? ________________________________ Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080429/1ded154f/attachment.html From johan at edab.nu Tue Apr 29 01:52:42 2008 From: johan at edab.nu (=?ISO-8859-15?Q?Johan_Wallstr=F6m?=) Date: Tue Apr 29 02:53:18 2008 Subject: [Icc-avr] Reading fuses on Mega168 In-Reply-To: References: Message-ID: <4816E1DA.8010008@edab.nu> Notice how the calls are slightly different, in the first one you have a 1 instead of a 0 ; dbg[0] = readfusesbyte(0x57,0x0001); ldi R18,1 ldi R19,0 The above loads 0x0001... ldi R16,87 ldi R17,0 The above loads 0x57 where as passing the value SPMCSR results in this: ; dbg[1] = readfusesbyte(SPMCSR,0x0000); clr R18 clr R19 The above loads 0x0000 (by clearing the registers) in R16,0x37 clr R17 The above loads what 0x57 POINTS TO, and clears the upper byte to prepare for the function call From BobGardner at aol.com Tue Apr 29 05:29:51 2008 From: BobGardner at aol.com (BobGardner@aol.com) Date: Tue Apr 29 06:30:41 2008 Subject: [Icc-avr] stack size needed to use fp? Message-ID: Hello imagecraft users. I have had 'problems' with my programs going nuts and the common theme seems to be something to do with fp print or fp divide. I'll ask for forgiveness for using fp right now. But I'd like one or two folks out there to edit and compile a simple program using floats and %7.1f format spec and tell me if it runs ok with hw stack of 0x80 or the hw stack has to be larger to run. I've tried every stack size up to 0x400 and still get blowups and strings of garbage printed out. I can dump ram and see a repeating pattern all thru ram. This would obviously clobber the stack, but if this is a 'bug', how could it be in version after version and no one else run into it? If its my arcane programming style, then I need some help bad. Thanks for reading. **************Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos. (http://autos.aol.com/used?NCID=aolcmp00300000002851) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080429/959eb72a/attachment.html From paul.aa9gg at gmail.com Tue Apr 29 05:39:45 2008 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Apr 29 06:40:27 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: References: Message-ID: <20f5efc40804290539i5c84f22amcae59a26005d68c6@mail.gmail.com> Hi Bob.... I use floating point quite a bit actually with the Mega32 and Mega6490. Typically my stack return is around 255 (0xFF). Dumb question...do you have floating point selected for printf version? I also use "Strings in Flash" option. On Tue, Apr 29, 2008 at 7:29 AM, wrote: > Hello imagecraft users. I have had 'problems' with my programs going nuts > and the common theme seems to be something to do with fp print or fp divide. > I'll ask for forgiveness for using fp right now. But I'd like one or two > folks out there to edit and compile a simple program using floats and %7.1f > format spec and tell me if it runs ok with hw stack of 0x80 or the hw stack > has to be larger to run. I've tried every stack size up to 0x400 and still > get blowups and strings of garbage printed out. I can dump ram and see a > repeating pattern all thru ram. This would obviously clobber the stack, but > if this is a 'bug', how could it be in version after version and no one else > run into it? If its my arcane programming style, then I need some help bad. > Thanks for reading. > > > > > ------------------------------ > Need a new ride? Check out the largest site for U.S. used car listings at AOL > Autos . > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080429/be1c5a3d/attachment-0001.html From MUihlein at 3psinc.com Tue Apr 29 06:06:55 2008 From: MUihlein at 3psinc.com (Mike Uihlein) Date: Tue Apr 29 07:07:40 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: Message-ID: Just a thought but... I had very similar problem (repeating pattern all thru ram) and random blowups when I simply made a mistake on how I declared variables and the program was compiled using multiple modules. I cannot remember exactly, but I missed some "externs" or had some type of nested declaration. It was a simple mistake, but had the same symptom. Mike Uihlein 3PS, Inc. 512-610-5209 muihlein@3psinc.com -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of BobGardner@aol.com Sent: Tuesday, April 29, 2008 7:30 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] stack size needed to use fp? Hello imagecraft users. I have had 'problems' with my programs going nuts and the common theme seems to be something to do with fp print or fp divide. I'll ask for forgiveness for using fp right now. But I'd like one or two folks out there to edit and compile a simple program using floats and %7.1f format spec and tell me if it runs ok with hw stack of 0x80 or the hw stack has to be larger to run. I've tried every stack size up to 0x400 and still get blowups and strings of garbage printed out. I can dump ram and see a repeating pattern all thru ram. This would obviously clobber the stack, but if this is a 'bug', how could it be in version after version and no one else run into it? If its my arcane programming style, then I need some help bad. Thanks for reading. ________________________________ Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos . From ianjames at waitrose.com Tue Apr 29 06:28:43 2008 From: ianjames at waitrose.com (Ian) Date: Tue Apr 29 07:29:37 2008 Subject: [Icc-avr] Reading fuses on Mega168 Message-ID: Hi Johan, I see your point so I changed the code thus: ; dbg[0] = readfusesbyte(0x57,0x0001); ldi R18,1 ldi R19,0 ldi R16,87 ldi R17,0 xcall _readfusesbyte sts _dbg,R16 .dbline 27 ; ; // Read high fuses bits ; dbg[2] = readfusesbyte(SPMCSR,0x0003); ldi R18,3 ldi R19,0 in R16,0x37 clr R17 xcall _readfusesbyte sts _dbg+2,R16 .dbline 30 Still the same problem, the first example uses ldi instructions to load R16/17 with 87 whereas the second example uses in instruction to load 0x37 into R16 and clrs R17. The actual definition of SPMSCR is #define SPMCSR (*(volatile unsigned char *)0x57) which for some strange reason the compiler translates to 0x37. Regard, Ian James -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From rnd-iccavr3 at rnd.se Tue Apr 29 07:07:00 2008 From: rnd-iccavr3 at rnd.se (Magnus Johansson) Date: Tue Apr 29 08:08:04 2008 Subject: [Icc-avr] Reading fuses on Mega168 In-Reply-To: References: Message-ID: <48172B84.9080907@rnd.se> > whereas the second example uses in instruction to load 0x37 into R16 and > clrs R17. Well, what Johan said, whatever byte is at address 0x37. > The actual definition of SPMSCR is > > #define SPMCSR (*(volatile unsigned char *)0x57) > > which for some strange reason the compiler translates to 0x37. Check out the m48/m88/m168 datasheet pages 345 and 346, especially the notes on page 346. From edi.imhof.ml at ihe.ch Tue Apr 29 07:47:59 2008 From: edi.imhof.ml at ihe.ch (Edi Im Hof) Date: Tue Apr 29 08:48:43 2008 Subject: [Icc-avr] Reading fuses on Mega168 In-Reply-To: References: Message-ID: <4817351F.9050108@ihe.ch> Ian schrieb: > > The actual definition of SPMSCR is > > #define SPMCSR (*(volatile unsigned char *)0x57) > > which for some strange reason the compiler translates to 0x37. This actually addresses the very same location. All the registers from $00 .. $3F are mirrored to $20 .. $5F Witch leaves still the question why the compiler does this know ... Are you really sure you are looking in the right file where the SPMCSR is defined? Edi > > Regard, > > Ian James > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + IH electronic + Phone: ++41 52 320 90 00 + + Edi Im Hof + Fax: ++41 52 320 90 04 + + Doernlerstrasse 1 + URL: http://www.ihe.ch + + CH-8545 Sulz + E-Mail: edi.imhof@ihe.ch + + Switzerland + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From webbra.mlist at verizon.net Tue Apr 29 07:52:19 2008 From: webbra.mlist at verizon.net (Rich Webb) Date: Tue Apr 29 08:53:05 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: <200804291350.m3TDo7ca096644@mail.imagecraft.com> References: <200804291350.m3TDo7ca096644@mail.imagecraft.com> Message-ID: <48173623.8070306@verizon.net> > Hello imagecraft users. I have had 'problems' with my programs going nuts > and the common theme seems to be something to do with fp print or fp divide. > I'll ask for forgiveness for using fp right now. But I'd like one or two folks > out there to edit and compile a simple program using floats and %7.1f format > spec and tell me if it runs ok with hw stack of 0x80 or the hw stack has to be > larger to run. I've tried every stack size up to 0x400 and still get blowups > and strings of garbage printed out. I can dump ram and see a repeating > pattern all thru ram. This would obviously clobber the stack, but if this is a > 'bug', how could it be in version after version and no one else run into it? If > its my arcane programming style, then I need some help bad. Thanks for > reading. Just guessing, but you may be overrunning your buffer space, since the printf() conversion routines return "ftoa error: number too big" (or "...small") if the target of the conversion is out of range. It appears from a little experimenting that %f and %g hit the wall in sprintf() somewhere below 2E-9 and above 2E9, rather than handling the full E-38 to E+38 range. FWIW, this was with V7.16a with a stack size of 50 on an AT90CAN128 that I happened to have mounted for another project. The fragment: anum = 1.0; bnum = 1.0; while (1) { if (tick) { tick = 0; anum *= 17.3; bnum *= 1.3; sprintf(buf, "%g / %g = %g\r\n", anum, bnum, anum / bnum); ... } } produces: 17.299999 / 1.3 = 13.307691 299.289947 / 1.69 = 177.094665 5177.715332 / 2.196999 = 2356.721191 89574.460937 / 2.856099 = 31362.523437 1.549638e6 / 3.712928 = 417362.75 2.680873e7 / 4.826806 = 5.554135e6 4.637910e8 / 6.274847 = 7.391272e7 ftoa error: number too big / 8.157299 = 9.836079e8 ftoa error: number too big / 10.604487 = ftoa error: number too big ftoa error: number too big / 13.785831 = ftoa error: number too big From bobgardner at aol.com Tue Apr 29 08:00:13 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Apr 29 09:01:08 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: <20f5efc40804290539i5c84f22amcae59a26005d68c6@mail.gmail.com> References: <20f5efc40804290539i5c84f22amcae59a26005d68c6@mail.gmail.com> Message-ID: <8CA7820DCD939E0-AAC-14CF@webmail-db07.sysops.aol.com> Thanks for the comeback. I have tried to cprintf("#7.1f\n",x); without the fp print ticked and, not surprisingly, it doesnt print out the number. I think the fp routines work pretty well... I have even had a couple of projects where I did some fp calcs, but then cast the results to ints and printed those numbers as ints. That worked, so I 'suspect' the cprintf conversion. I have tried cprintf using %e and %g as well as %f. -----Original Message----- From: Paul Mateer Sent: Tue, 29 Apr 2008 8:39 am Subject: Re: [Icc-avr] stack size needed to use fp? Hi Bob.... I use floating point quite a bit actually with the Mega32 and Mega6490.? Typically my stack return is around 255 (0xFF).? Dumb question...do you have floating point selected for printf version?? I also use "Strings in Flash" option. On Tue, Apr 29, 2008 at 7:29 AM, wrote: Hello imagecraft users. I have had 'problems' with my programs going nuts and the common theme seems to be something to do with fp print or fp divide. I'll ask for forgiveness for using fp right now. But I'd like one or two folks out there to edit and compile a simple program using floats and %7.1f format spec and tell me if it runs ok with hw stack of 0x80 or the hw stack has to be larger to run. I've tried every stack size up to 0x400 and still get blowups and strings of garbage printed out. I can dump ram and see a repeating pattern all thru ram. This would obviously clobber the stack, but if this is a 'bug', how could it be in version after version and no one else run into it? If its my arcane programming style, then I need some help bad. Thanks for reading. ? Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080429/f62ee954/attachment.html From tim at sabretechnology.co.uk Tue Apr 29 08:31:45 2008 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Apr 29 09:32:31 2008 Subject: [Icc-avr] Reading fuses on Mega168 Message-ID: <04671BB8D269034BBC4BB6BA8948672610AC6C@sserver.SabreTechnology.local> > Still the same problem, the first example uses ldi instructions to > load > R16/17 with 87 > whereas the second example uses in instruction to load 0x37 into R16 > and clrs R17. > > The actual definition of SPMSCR is > > #define SPMCSR (*(volatile unsigned char *)0x57) > > which for some strange reason the compiler translates to 0x37. > SPMCSR is not a constant, it is effectively a variable reading the special function register. So your "readfusesbyte(SPMCSR,0x0003)" will use the contents of the SPMCSR register, not the number 0x57, hence the "in R16,0x37" The reason it's 0x37 not 0x57 is because you can access most of the special function registers as I/O (using in/out opcodes) or as SRAM (using lds/sts opcodes), but the i/o address is not the same as the sram address - normally 0x20 lower. The compiler obviously knows this somehow, "lds R16,0x57" would give the same result. If you look in the datasheet register summary the IO address is shown without brackets and the sram address is shown with brackets. -- Tim Mitchell tim@sabretechnology.co.uk http://www.sabretechnology.co.uk Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ Registered in England and Wales no.3131504 t:01482 801003 f:01482 801078 From bobgardner at aol.com Tue Apr 29 08:31:54 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Apr 29 09:32:37 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: <48173623.8070306@verizon.net> References: <200804291350.m3TDo7ca096644@mail.imagecraft.com> <48173623.8070306@verizon.net> Message-ID: <8CA782549D38634-AAC-1799@webmail-db07.sysops.aol.com> Good clue Rich! So my whole problem could be sort of an fp underflow..... Wonder if I could hide an 0x55aa before and after the fp convert buffer and check for buffer overrun after cprintfs? Any idea how to find the address of the fp buffer? -----Original Message----- From: Rich Webb To: icc-avr@imagecraft.com Sent: Tue, 29 Apr 2008 10:52 am Subject: Re: [Icc-avr] stack size needed to use fp? > Hello imagecraft users. I have had 'problems' with my programs going nuts > and the common theme seems to be something to do with fp print or fp divide. > I'll ask for forgiveness for using fp right now. But I'd like one or two folks > out there to edit and compile a simple program using floats and %7.1f format > spec and tell me if it runs ok with hw stack of 0x80 or the hw stack has to be > larger to run. I've tried every stack size up to 0x400 and still get blowups > and strings of garbage printed out. I can dump ram and see a repeating > pattern all thru ram. This would obviously clobber the stack, but if this is a > 'bug', how could it be in version after version and no one else run into it? If > its my arcane programming style, then I need some help bad. Thanks for > reading.? ? Just guessing, but you may be overrunning your buffer space, since the printf() conversion routines return "ftoa error: number too big" (or "...small") if the target of the conversion is out of range.? ? It appears from a little experimenting that %f and %g hit the wall in sprintf() somewhere below 2E-9 and above 2E9, rather than handling the full E-38 to E+38 range.? ? FWIW, this was with V7.16a with a stack size of 50 on an AT90CAN128 that I happened to have mounted for another project.? ? The fragment:? ? ? anum = 1.0;? ? bnum = 1.0;? ? ? while (1) {? ? if (tick) {? ? tick = 0;? ? ? anum *= 17.3;? ? bnum *= 1.3;? ? ? sprintf(buf, "%g / %g = %g\r\n", anum, bnum, anum / bnum);? ? ...? ? }? ? }? ? produces:? ? 17.299999 / 1.3 = 13.307691 ? 299.289947 / 1.69 = 177.094665 ? 5177.715332 / 2.196999 = 2356.721191 ? 89574.460937 / 2.856099 = 31362.523437 ? 1.549638e6 / 3.712928 = 417362.75 ? 2.680873e7 / 4.826806 = 5.554135e6 ? 4.637910e8 / 6.274847 = 7.391272e7 ? ftoa error: number too big / 8.157299 = 9.836079e8 ? ftoa error: number too big / 10.604487 = ftoa error: number too big ? ftoa error: number too big / 13.785831 = ftoa error: number too big? ? _______________________________________________? 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/20080429/d44736f8/attachment-0001.html From webbra.mlist at verizon.net Tue Apr 29 11:37:41 2008 From: webbra.mlist at verizon.net (Rich Webb) Date: Tue Apr 29 12:38:28 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: <200804291728.m3THSTAB002126@mail.imagecraft.com> References: <200804291728.m3THSTAB002126@mail.imagecraft.com> Message-ID: <48176AF5.7090808@verizon.net> > Good clue Rich! So my whole problem could be sort of an fp underflow..... > Wonder if I could hide an 0x55aa before and after the fp convert > buffer and check for buffer overrun after cprintfs? Any idea how to > find the address of the fp buffer? I was thinking more along the lines of overflowing an sprintf(buf,...) buffer, rather than a side effect of printf() or cprintf(). I typically load a buffer with sprintf() and then fire the characters out the e.g., UART, one at a time when the UDRE (UART data ready empty) interrupt occurs. In the fragment that I threw together I just pulled a nice round "#define BUFLEN 128" out of the air rather than trying to optimize space for the anticipated maximum length of the output string, or else I would have tromped over who knows what when the error strings were printed instead of the numerics. I do use floats for user interfaces and such but the values are usually on the order of 1 to 100 (4.8 V, 23.7 C, ...) and had not hit upon the ftoa error message before this. From jassenbaum at htp-tel.de Tue Apr 29 12:21:53 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Apr 29 13:23:21 2008 Subject: [Icc-avr] Reading fuses on Mega168 References: Message-ID: It's just C and because of SPMCSR macro defines a pointer. You need to write dbg[1] = readfusesbyte((unsigned int)&SPMCSR,0x0000); to get what you want. > Hi, > Following on from my previous post regarding reading fuses on the Mega168 > I have found that passing the value 0x57 to the function readfusesbyte > [unsigned char readfusesbyte(unsigned int ioaddr, unsigned int fuseaddr);] > results in this: > ; dbg[0] = readfusesbyte(0x57,0x0001); > ldi R18,1 > ldi R19,0 > ldi R16,87 > ldi R17,0 > where as passing the value SPMCSR results in this: > ; dbg[1] = readfusesbyte(SPMCSR,0x0000); > clr R18 > clr R19 > in R16,0x37 > clr R17 > where SPMCSR is defined as > /* SPM Control and Status Register */ > #define SPMCSR (*(volatile unsigned char *)0x57) > Can anyone shed any light on the anomaly?. > I have included a partial copy of the .s file thus: > ; unsigned char readfusesbyte(unsigned int ioaddr, unsigned int fuseaddr); > ; > ; void ReadFuseLock(void) > ; { > .dbline 22 > ; _CLI(); > cli > .dbline 24 > ; // Read lock bits > ; dbg[0] = readfusesbyte(0x57,0x0001); > ldi R18,1 > ldi R19,0 > ldi R16,87 > ldi R17,0 > xcall _readfusesbyte > sts _dbg,R16 > .dbline 27 > ; > ; // Read low fuses bits > ; dbg[1] = readfusesbyte(SPMCSR,0x0000); > clr R18 > clr R19 > in R16,0x37 > clr R17 > xcall _readfusesbyte > sts _dbg+1,R16 > .dbline 30 > I would be grateful for an explaination as I am wondering if there are any > other potential anomolies I should know about. > Regards, > Ian James > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > -- > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.6/1402 - Release Date: 28.04.08 13:29 From jassenbaum at htp-tel.de Tue Apr 29 12:33:04 2008 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Apr 29 13:34:32 2008 Subject: [Icc-avr] stack size needed to use fp? References: <200804291350.m3TDo7ca096644@mail.imagecraft.com> <48173623.8070306@verizon.net> <8CA782549D38634-AAC-1799@webmail-db07.sysops.aol.com> Message-ID: > Good clue Rich! So my whole problem could be sort of an fp underflow..... Wonder if > I could hide an 0x55aa before and after the fp convert buffer and check for buffer > overrun after cprintfs? Any idea how to find the address of the fp buffer? > -----Original Message----- > From: Rich Webb > To: icc-avr@imagecraft.com > Sent: Tue, 29 Apr 2008 10:52 am > Subject: Re: [Icc-avr] stack size needed to use fp? >> Hello imagecraft users. I have had 'problems' with my programs going nuts > and >> the common theme seems to be something to do with fp print or fp divide. > I'll >> ask for forgiveness for using fp right now. But I'd like one or two folks > out >> there to edit and compile a simple program using floats and %7.1f format > spec >> and tell me if it runs ok with hw stack of 0x80 or the hw stack has to be > larger >> to run. I've tried every stack size up to 0x400 and still get blowups > and >> strings of garbage printed out. I can dump ram and see a repeating > pattern all >> thru ram. This would obviously clobber the stack, but if this is a > 'bug', how >> could it be in version after version and no one else run into it? If > its my >> arcane programming style, then I need some help bad. Thanks for > reading.? > ? > Just guessing, but you may be overrunning your buffer space, since the printf() > conversion routines return "ftoa error: number too big" (or "...small") if the > target of the conversion is out of range.? > ? > It appears from a little experimenting that %f and %g hit the wall in sprintf() > somewhere below 2E-9 and above 2E9, rather than handling the full E-38 to E+38 > range.? > ? > FWIW, this was with V7.16a with a stack size of 50 on an AT90CAN128 that I happened > to have mounted for another project.? > ? > The fragment:? > ? > ? anum = 1.0;? > ? bnum = 1.0;? > ? > ? while (1) {? > ? if (tick) {? > ? tick = 0;? > ? > ? anum *= 17.3;? > ? bnum *= 1.3;? > ? > ? sprintf(buf, "%g / %g = %g\r\n", anum, bnum, anum / bnum);? > ? ...? > ? }? > ? }? > ? > produces:? > ? > 17.299999 / 1.3 = 13.307691 ? > 299.289947 / 1.69 = 177.094665 ? > 5177.715332 / 2.196999 = 2356.721191 ? > 89574.460937 / 2.856099 = 31362.523437 ? > 1.549638e6 / 3.712928 = 417362.75 ? > 2.680873e7 / 4.826806 = 5.554135e6 ? > 4.637910e8 / 6.274847 = 7.391272e7 ? > ftoa error: number too big / 8.157299 = 9.836079e8 ? > ftoa error: number too big / 10.604487 = ftoa error: number too big ? > ftoa error: number too big / 13.785831 = ftoa error: number too big? > ? > _______________________________________________? > Icc-avr mailing list? > Icc-avr@imagecraft.com? > http://dragonsgate.net/mailman/listinfo/icc-avr? From bobgardner at aol.com Tue Apr 29 14:14:30 2008 From: bobgardner at aol.com (bobgardner@aol.com) Date: Tue Apr 29 15:15:19 2008 Subject: [Icc-avr] stack size needed to use fp? In-Reply-To: References: <200804291350.m3TDo7ca096644@mail.imagecraft.com> <48173623.8070306@verizon.net> <8CA782549D38634-AAC-1799@webmail-db07.sysops.aol.com> Message-ID: <8CA78552629F6B8-AAC-34E3@webmail-db07.sysops.aol.com> Hey Johannes.... there wasnt any body in your message... just quotes.... I bet you know where the fp buffer is dont you? -----Original Message----- From: Johannes Assenbaum To: icc-avr@imagecraft.com Sent: Tue, 29 Apr 2008 3:33 pm Subject: Re: [Icc-avr] stack size needed to use fp? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080429/2a753028/attachment.html From sbissonnette at microsyl.com Wed Apr 30 18:50:07 2008 From: sbissonnette at microsyl.com (Sylvain Bissonnette) Date: Wed Apr 30 18:51:31 2008 Subject: [Icc-avr] ADC Differential input Message-ID: <000b01c8ab2d$af325ad0$0301a8c0@Sylvain> Hi, That's the first time I have to use the differential input on a AVR and my question is if I chose the value 01000 in the MUX register it's written Posisive Diff Input : ADC0 Negative Diff Input : ADC0 I don't understand why it's the same input? Thanks Sylvain Bissonnette -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080430/3f6565dc/attachment.html From BobGardner at aol.com Wed Apr 30 19:04:48 2008 From: BobGardner at aol.com (BobGardner@aol.com) Date: Wed Apr 30 20:05:33 2008 Subject: [Icc-avr] ADC Differential input Message-ID: I wondered about that too. Datasheet says they dont test diff mode in 40 pin dip package. I havent been able to get it to work. When using gain of 10 or 200, I think the dc component must be 1/10th or 1/200th of vref.... it amplifies, then subtracts the amplified signals... so it is very easy to 'clip' if dc level is > 0.5V In a message dated 4/30/2008 8:52:11 P.M. Eastern Daylight Time, sbissonnette@microsyl.com writes: Hi, That's the first time I have to use the differential input on a AVR and my question is if I chose the value 01000 in the MUX register it's written Posisive Diff Input : ADC0 Negative Diff Input : ADC0 I don't understand why it's the same input? Thanks Sylvain Bissonnette _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr **************Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos. (http://autos.aol.com/used?NCID=aolcmp00300000002851) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20080430/8dc21568/attachment.html