From mark at extron.com.au Fri Jun 1 01:09:46 2007 From: mark at extron.com.au (Mark Barber) Date: Fri Jun 1 01:20:16 2007 Subject: [Icc-avr] Ethernet dev Appl? help? In-Reply-To: <001301c7a41d$3d717100$010201c4@net> References: <465EDF5C.5050503@telia.com><465EEC34.6080101@jpl.nasa.gov><465F190B.3090108@telia.com><000701c7a3f4$02995760$010201c4@net> <009601c7a403$398fc8d0$6d01a8c0@mark> <001301c7a41d$3d717100$010201c4@net> Message-ID: <00a401c7a424$45f74780$6d01a8c0@mark> Gerhard, Here is the link to the Atmel web site. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2727 AVR-460 is the kit number. You will need to use a micro with external memory access. The 32 is not suitable. It helps if you have a basic understanding of the ISO networking layer model and some basic understanding of the TCP/IP environment but not essential. The supplied code in the starter kit is well documented. Best of luck. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 **********************************? ? -----Original Message----- From: AMS Solutions - GJ Laubscher [mailto:amsol@amssolutions.co.za] Sent: Friday, 1 June 2007 5:20 PM To: mark@extron.com.au Subject: Re: [Icc-avr] Ethernet dev Appl? help? Hi Mark, thx for info, do you have a website link to the toolkit? Did you find it relatively easy to implement? I am think of using a mega32 or 64, suitable? Regards, Gerhard Laubscher Cape Town , Table View PO Box 132, Table View, 7439 South Africa South Africa TeleFax : +27-21-557 0160 Mobile : 082 366 1950 email : amsol@amssolutions.co.za ----- Original Message ----- From: "Mark Barber" To: "'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.'" Sent: Friday, June 01, 2007 6:13 AM Subject: RE: [Icc-avr] Ethernet dev Appl? help? Gerhard, Have a look at the Atmel Embedded Internet Toolkit. I used this as a learning tool and managed to develop a TCP/IP interface using the ATmega128. It was not the fastest unit on the network but it did work correctly and achieved some simple control and monitoring. If nothing else it is a good starting point. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 ********************************** -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of AMS Solutions - GJ Laubscher Sent: Friday, 1 June 2007 12:25 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] Ethernet dev Appl? help? Hi All, I am interested to develope an application with ethernet tcp/ip connectivity in order to monitor remote site io. Has anybody here done something similar that you can share or point me in the right direction? I would appreciate any feedback? Regards, Gerhard Laubscher Cape Town , Table View PO Box 132, Table View, 7439 South Africa South Africa TeleFax : +27-21-557 0160 Mobile : 082 366 1950 email : amsol@amssolutions.co.za _______________________________________________ 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 jh.bodin at telia.com Fri Jun 1 01:27:06 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri Jun 1 01:36:58 2007 Subject: [Icc-avr] Ethernet dev Appl? help? In-Reply-To: <000701c7a3f4$02995760$010201c4@net> References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <465F190B.3090108@telia.com> <000701c7a3f4$02995760$010201c4@net> Message-ID: <465FD85A.90006@telia.com> Hi Gerhard, we are using Lantronix XPORT which is simple to use and works great. It is small! Slightly longer than a "dumb" RJ45 connector and contains a complete TCP/IP stack. Ethernet connection is 10/100 Mbit/s. It interfaces to your system through a normal asynchronous serial port at 3.3V level. Supported protocols: TCP/IP, UDP/IP, ARP, ICMP, SNMP, TFTP, Telnet, DHCP, BOOTP, HTTP, and AutoIP. We are also using a special version, XPORT ModBus, which is a TCP/IP to ModBus gateway. There is also the XPORT AR version if you want to put "user code" in it although I have no experience of this one. http://www.lantronix.com http://www.lantronix.com/device-networking/embedded-device-servers/xport.html Best Regards Johan Bodin From jh.bodin at telia.com Fri Jun 1 01:50:03 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri Jun 1 01:59:53 2007 Subject: SV: SV: [Icc-avr] Accessing only the LSByte of a long In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EBABA@seattle.ecpower.dk> References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov><465F190B.3090108@telia.com><072D96786BFC014AAEBA9EB07A8070EA1EBAB0@seattle.ecpower.dk> <200705312201.l4VM1XkO096743@dragonsgate2.imagecraft.com> <072D96786BFC014AAEBA9EB07A8070EA1EBABA@seattle.ecpower.dk> Message-ID: <465FDDBB.7080601@telia.com> Steven Lose wrote: > Makes me a bit confused, would any compiler make a solution > that course a standard C expression to malfunction? Of course not, but writing something to one union member and then reading the value from another member is non-standard. There is nothing in the C standard that will guarantee that it will work (although I have used it many times :o). To play it safe, you need to keep track of which member was written last, just as in John Baraclough's example. Unless there is some padding or other strange stuff, the size of a union is equal to the size of the largest member type so it can be used to save RAM if you store only one type at a time. Best Regards Johan From sl at ecpower.dk Fri Jun 1 01:57:38 2007 From: sl at ecpower.dk (Steven Lose) Date: Fri Jun 1 02:07:32 2007 Subject: SV: [Icc-avr] Ethernet dev Appl? help? References: <465EDF5C.5050503@telia.com><465EEC34.6080101@jpl.nasa.gov><465F190B.3090108@telia.com><000701c7a3f4$02995760$010201c4@net><009601c7a403$398fc8d0$6d01a8c0@mark><001301c7a41d$3d717100$010201c4@net> <00a401c7a424$45f74780$6d01a8c0@mark> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EBAE9@seattle.ecpower.dk> Hi. Do you know how to get updates to the kit? I bought one 4 years ago, so there has probably been updates after that, but seems not to on the web. ;o) Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk -----Oprindelig meddelelse----- Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Mark Barber Sendt: 1. juni 2007 10:10 Til: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.' Emne: RE: [Icc-avr] Ethernet dev Appl? help? Gerhard, Here is the link to the Atmel web site. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2727 AVR-460 is the kit number. You will need to use a micro with external memory access. The 32 is not suitable. It helps if you have a basic understanding of the ISO networking layer model and some basic understanding of the TCP/IP environment but not essential. The supplied code in the starter kit is well documented. Best of luck. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 **********************************? ? -----Original Message----- From: AMS Solutions - GJ Laubscher [mailto:amsol@amssolutions.co.za] Sent: Friday, 1 June 2007 5:20 PM To: mark@extron.com.au Subject: Re: [Icc-avr] Ethernet dev Appl? help? Hi Mark, thx for info, do you have a website link to the toolkit? Did you find it relatively easy to implement? I am think of using a mega32 or 64, suitable? Regards, Gerhard Laubscher Cape Town , Table View PO Box 132, Table View, 7439 South Africa South Africa TeleFax : +27-21-557 0160 Mobile : 082 366 1950 email : amsol@amssolutions.co.za ----- Original Message ----- From: "Mark Barber" To: "'Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this.'" Sent: Friday, June 01, 2007 6:13 AM Subject: RE: [Icc-avr] Ethernet dev Appl? help? Gerhard, Have a look at the Atmel Embedded Internet Toolkit. I used this as a learning tool and managed to develop a TCP/IP interface using the ATmega128. It was not the fastest unit on the network but it did work correctly and achieved some simple control and monitoring. If nothing else it is a good starting point. Regards Mark ********************************** Mark Barber Extron Technologies Pty. Ltd. www.extron.com.au Ph: 613-9761-8166 Fx: 613-9761-8177 ********************************** -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of AMS Solutions - GJ Laubscher Sent: Friday, 1 June 2007 12:25 PM To: Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this. Subject: [Icc-avr] Ethernet dev Appl? help? Hi All, I am interested to develope an application with ethernet tcp/ip connectivity in order to monitor remote site io. Has anybody here done something similar that you can share or point me in the right direction? I would appreciate any feedback? Regards, Gerhard Laubscher Cape Town , Table View PO Box 132, Table View, 7439 South Africa South Africa TeleFax : +27-21-557 0160 Mobile : 082 366 1950 email : amsol@amssolutions.co.za _______________________________________________ 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 david_brown at hotpop.com Fri Jun 1 04:22:26 2007 From: david_brown at hotpop.com (David Brown) Date: Fri Jun 1 04:08:39 2007 Subject: [Icc-avr] Accessing only the LSByte of a long In-Reply-To: <465F190B.3090108@telia.com> References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <465F190B.3090108@telia.com> Message-ID: <46600172.9010306@hotpop.com> Johan H. Bodin wrote: > Bruce Parham wrote: > > #define get_byte(_x, _y) (*((volatile unsigned char *)(&_x) + > _y)) > > Thanks Bruce, I will use something like that, keeping in mind that it > is "endianness" dependent. This will eliminate all the shifting too. > > > Sergio Paulo Sider wrote: > > I would use also "unions", but you are correct, it depends on the > > endianness of the compiler. > > There is another risk with unions, AFAIK the ANSI rules do not force > the compiler to map all union members to the same starting address. > Most implementations probably do it in the expected way but I guess > there are exceptions for example on machines where word/long alignment > improves performance. > I'm not an expert in the details of ANSI C, but my understanding is that the alignment of a union is the largest alignment of the members of that union. So the alignment requirements of the members will not cause then to start at different addresses, but it may change the alignment of the whole union. I can't think off-hand of any reason why union members would not be at the same starting address. I don't know if the standards enforce this rule - but without it, the whole concept of union would be useless. > > But on my work, I think the benefits of this (macro or union) > > approach are greater than the portability problems it would create. > > A good comment is really required.. > > I agree 100% even though I think it would be better if the compiler > would be smart enough to "see" that the code was trying to access > single bytes of the long variable even if written in the "portable way". > > > 73 = Best Regards > Johan Bodin > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From johan at edab.nu Fri Jun 1 04:47:00 2007 From: johan at edab.nu (=?iso-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Jun 1 04:55:44 2007 Subject: [Icc-avr] Function Pointer with arguments? References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <001f01c7a3f0$3c1d2510$0301a8c0@Sylvain> Message-ID: <009701c7a442$90ade220$64026e0a@EDAB1> So what do you want to send in the call to the function? Now it says FunctionPTR(); But instead you would like to send some info to all registered task functions? Or is it some data specific to KeyScan? ----- Original Message ----- From: "Sylvain Bissonnette" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this." Sent: Friday, June 01, 2007 3:57 AM Subject: [Icc-avr] Function Pointer with arguments? > Hi, > > I have some code that use function pointer with no argument, but I need to > pass one argument. > > Now it's look like > TaskRegister(&KeyScan,T100MS); > > but now I want something like > TaskRegister(&KeyScan(int x),T100MS); > > Here is my code with no argument I want to modify > > Any help will be welcome > Thanks > > //******************************** > // G L O B A L V A R I A B L E > //******************************** > typedef struct Task > { > void (*FunctionPTR)(void); > uint Interval; > uint Ticker; > }Task; > Task TaskList[MAX_TASK]; > int TaskMax = 0; > > //------------------------------------ > > int TaskRegister(void(*FunctionPTR)(void), > uint Interval) > { > TaskList[TaskMax].FunctionPTR = FunctionPTR; > TaskList[TaskMax].Interval = Interval; > TaskList[TaskMax].Ticker = 0; > TaskMax++; > } > > //---------------------------------------- > > #pragma interrupt_handler TaskExecute:12 > void TaskExecute(void) > { > static ushort i,j; > static void (*FunctionPTR)(void); > > TCNT0 = 255 - (XTAL / 8 / 10000); > > for (i=0;i { > if (TaskList[i].Ticker++ >= TaskList[i].Interval) > { > FunctionPTR = TaskList[i].FunctionPTR; > TaskList[i].Ticker = 0; > FunctionPTR(); > } > } > } > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > From jh.bodin at telia.com Fri Jun 1 04:46:27 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Fri Jun 1 04:56:22 2007 Subject: [Icc-avr] Accessing only the LSByte of a long In-Reply-To: <465EEC34.6080101@jpl.nasa.gov> References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> Message-ID: <46600713.70805@telia.com> I ended up with this... Regards Johan ------------ // bytepick.h #ifndef BYTEPICK_INCLUDED #define BYTEPICK_INCLUDED // This should ideally be predefined by the compiler...: #define LITTLE_ENDIAN //#define BIG_ENDIAN // Sanity check: #ifdef LITTLE_ENDIAN #ifdef BIG_ENDIAN #error "You can't have both endian types in bytepick.h!" #endif #endif #ifndef LITTLE_ENDIAN #ifndef BIG_ENDIAN #error "You must select big/little endian in bytepick.h!" #endif #endif // Here we go: #ifdef BIG_ENDIAN #define HIGH_BYTE_32(longvar) (*((unsigned char *)(&longvar))) #define MID_H_BYTE_32(longvar) (*((unsigned char *)(&longvar) + 1)) #define MID_L_BYTE_32(longvar) (*((unsigned char *)(&longvar) + 2)) #define LOW_BYTE_32(longvar) (*((unsigned char *)(&longvar) + 3)) #define HIGH_BYTE_16(shortvar) (*((unsigned char *)(&shortvar))) #define LOW_BYTE_16(shortvar) (*((unsigned char *)(&shortvar) + 1)) #else #define HIGH_BYTE_32(longvar) (*((unsigned char *)(&longvar) + 3)) #define MID_H_BYTE_32(longvar) (*((unsigned char *)(&longvar) + 2)) #define MID_L_BYTE_32(longvar) (*((unsigned char *)(&longvar) + 1)) #define LOW_BYTE_32(longvar) (*((unsigned char *)(&longvar))) #define HIGH_BYTE_16(shortvar) (*((unsigned char *)(&shortvar) + 1)) #define LOW_BYTE_16(shortvar) (*((unsigned char *)(&shortvar))) #endif #endif // BYTEPICK_INCLUDED ------------ From sbissonnette at microsyl.com Fri Jun 1 06:23:54 2007 From: sbissonnette at microsyl.com (sbissonnette@microsyl.com) Date: Fri Jun 1 06:33:58 2007 Subject: [Icc-avr] Function Pointer with arguments? In-Reply-To: <009701c7a442$90ade220$64026e0a@EDAB1> References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <001f01c7a3f0$3c1d2510$0301a8c0@Sylvain> <009701c7a442$90ade220$64026e0a@EDAB1> Message-ID: <25788.199.22.57.2.1180704234.squirrel@www.microsyl.com> Hi Johan, No the parameter must be different for each registrated function. If a function don't need parameter I can send a dummy one it will be Ok. Thanks Johan, Sylvain > So what do you want to send in the call to the function? > Now it says > FunctionPTR(); > But instead you would like to send some info to all registered task > functions? Or is it some data specific to KeyScan? > > ----- Original Message ----- > From: "Sylvain Bissonnette" > To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT > needtosubscribeto icc-announce if you are a member of this." > > Sent: Friday, June 01, 2007 3:57 AM > Subject: [Icc-avr] Function Pointer with arguments? > > >> Hi, >> >> I have some code that use function pointer with no argument, but I need >> to >> pass one argument. >> >> Now it's look like >> TaskRegister(&KeyScan,T100MS); >> >> but now I want something like >> TaskRegister(&KeyScan(int x),T100MS); >> >> Here is my code with no argument I want to modify >> >> Any help will be welcome >> Thanks >> >> //******************************** >> // G L O B A L V A R I A B L E >> //******************************** >> typedef struct Task >> { >> void (*FunctionPTR)(void); >> uint Interval; >> uint Ticker; >> }Task; >> Task TaskList[MAX_TASK]; >> int TaskMax = 0; >> >> //------------------------------------ >> >> int TaskRegister(void(*FunctionPTR)(void), >> uint Interval) >> { >> TaskList[TaskMax].FunctionPTR = FunctionPTR; >> TaskList[TaskMax].Interval = Interval; >> TaskList[TaskMax].Ticker = 0; >> TaskMax++; >> } >> >> //---------------------------------------- >> >> #pragma interrupt_handler TaskExecute:12 >> void TaskExecute(void) >> { >> static ushort i,j; >> static void (*FunctionPTR)(void); >> >> TCNT0 = 255 - (XTAL / 8 / 10000); >> >> for (i=0;i> { >> if (TaskList[i].Ticker++ >= TaskList[i].Interval) >> { >> FunctionPTR = TaskList[i].FunctionPTR; >> TaskList[i].Ticker = 0; >> FunctionPTR(); >> } >> } >> } >> _______________________________________________ >> 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 johan at edab.nu Fri Jun 1 06:42:04 2007 From: johan at edab.nu (=?iso-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Jun 1 06:50:48 2007 Subject: [Icc-avr] Function Pointer with arguments? References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <001f01c7a3f0$3c1d2510$0301a8c0@Sylvain> <009701c7a442$90ade220$64026e0a@EDAB1> <25788.199.22.57.2.1180704234.squirrel@www.microsyl.com> Message-ID: <001201c7a452$a412af70$64026e0a@EDAB1> I think this is what you want to do: typedef struct Task { void (*FunctionPTR)(int); uint Interval; uint Ticker; }Task; Task TaskList[MAX_TASK]; int TaskMax = 0; //------------------------------------ int TaskRegister(void(*FunctionPTR)(int),uint Interval) { TaskList[TaskMax].FunctionPTR = FunctionPTR; TaskList[TaskMax].Interval = Interval; TaskList[TaskMax].Ticker = 0; TaskMax++; return 0; } //---------------------------------------- #pragma interrupt_handler TaskExecute:12 void TaskExecute(void) { static ushort i,j; static void (*FunctionPTR)(int); int dataToSend; TCNT0 = 255 - (XTAL / 8 / 10000); for (i=0;i= TaskList[i].Interval) { FunctionPTR = TaskList[i].FunctionPTR; TaskList[i].Ticker = 0; dataToSend = 0; FunctionPTR(dataToSend); } } } From johan at edab.nu Fri Jun 1 06:43:54 2007 From: johan at edab.nu (=?iso-8859-1?Q?Johan_Wallstr=F6m?=) Date: Fri Jun 1 06:52:37 2007 Subject: [Icc-avr] Function Pointer with arguments? References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <001f01c7a3f0$3c1d2510$0301a8c0@Sylvain> Message-ID: <001601c7a452$e5549e30$64026e0a@EDAB1> Just to clarify, you would still register tasks like you did previously: void KeyScan(int x) { } void main() { TaskRegister(&KeyScan,T100MS); } ----- Original Message ----- From: "Sylvain Bissonnette" To: "Discussion list for ICCAVR and ICCtiny Users. You do NOT needtosubscribeto icc-announce if you are a member of this." Sent: Friday, June 01, 2007 3:57 AM Subject: [Icc-avr] Function Pointer with arguments? > Hi, > > I have some code that use function pointer with no argument, but I need to > pass one argument. > > Now it's look like > TaskRegister(&KeyScan,T100MS); > > but now I want something like > TaskRegister(&KeyScan(int x),T100MS); > > Here is my code with no argument I want to modify > > Any help will be welcome > Thanks > > //******************************** > // G L O B A L V A R I A B L E > //******************************** > typedef struct Task > { > void (*FunctionPTR)(void); > uint Interval; > uint Ticker; > }Task; > Task TaskList[MAX_TASK]; > int TaskMax = 0; > > //------------------------------------ > > int TaskRegister(void(*FunctionPTR)(void), > uint Interval) > { > TaskList[TaskMax].FunctionPTR = FunctionPTR; > TaskList[TaskMax].Interval = Interval; > TaskList[TaskMax].Ticker = 0; > TaskMax++; > } > > //---------------------------------------- > > #pragma interrupt_handler TaskExecute:12 > void TaskExecute(void) > { > static ushort i,j; > static void (*FunctionPTR)(void); > > TCNT0 = 255 - (XTAL / 8 / 10000); > > for (i=0;i { > if (TaskList[i].Ticker++ >= TaskList[i].Interval) > { > FunctionPTR = TaskList[i].FunctionPTR; > TaskList[i].Ticker = 0; > FunctionPTR(); > } > } > } > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr > > From BobGardner at aol.com Fri Jun 1 17:27:38 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Fri Jun 1 17:38:31 2007 Subject: [Icc-avr] iccavr 7.13a Message-ID: Where do I dl the 7.13a version? I dled the demo version (over the modem!) and I think its version 7.13. ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070601/b34b7ece/attachment.html From richard-lists at imagecraft.com Fri Jun 1 18:00:08 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Jun 1 18:10:16 2007 Subject: [Icc-avr] iccavr 7.13a In-Reply-To: References: Message-ID: <200706020110.l521AEfU019187@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070601/cd6ba1c7/attachment.html From BobGardner at aol.com Fri Jun 1 19:29:00 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Fri Jun 1 19:39:07 2007 Subject: [Icc-avr] iccavr v7.13a?? Message-ID: version dled from demo says 7.13, Apr 24 07 size 7901951.... is that one 7.13a?? ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070601/83d9634a/attachment.html From a.r.khorasani at gmail.com Sat Jun 2 06:47:55 2007 From: a.r.khorasani at gmail.com (A. R. Khorasani) Date: Sat Jun 2 06:57:50 2007 Subject: [Icc-avr] Ethernet dev Appl? help? In-Reply-To: <000701c7a3f4$02995760$010201c4@net> References: <465EDF5C.5050503@telia.com> <465EEC34.6080101@jpl.nasa.gov> <465F190B.3090108@telia.com> <000701c7a3f4$02995760$010201c4@net> Message-ID: check *RTL8019AS* Realtek Full-Duplex Ethernet Controller with Plug and *... * On 6/1/07, AMS Solutions - GJ Laubscher wrote: > > Hi All, > I am interested to develope an application with ethernet tcp/ip > connectivity > in order to monitor > remote site io. Has anybody here done something similar that you can > share > or point me in the right direction? I would appreciate any feedback? > > Regards, > Gerhard Laubscher > Cape Town , Table View PO Box 132, Table View, 7439 > South Africa South Africa > TeleFax : +27-21-557 0160 Mobile : 082 366 1950 > email : amsol@amssolutions.co.za > > > > _______________________________________________ > 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/20070602/ba6fb295/attachment.html From BobGardner at aol.com Sat Jun 2 07:05:31 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sat Jun 2 07:16:22 2007 Subject: [Icc-avr] 7.13a where are u? Message-ID: I clicked on the demos link in the about box and I got a 'Sorry' box about demos html not found and maybe I typed the url wrong... except that I clicked on the url in the about box. Seems like once upon a time I could ftp from somewhere in dragonsgate to get the latest beta? ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070602/f2c4575f/attachment.html From richard-lists at imagecraft.com Sat Jun 2 12:09:20 2007 From: richard-lists at imagecraft.com (Richard) Date: Sat Jun 2 12:19:36 2007 Subject: [Icc-avr] 7.13a where are u? In-Reply-To: References: Message-ID: <200706021919.l52JJYGa029039@dragonsgate2.imagecraft.com> Bob, gotta, but I just tried installing the latest demo and it says 7.13A. I think may be your web browser caches the old one? The direct URL is http://www.imagecraft.com/pub/iccv7avr_demo.exe I will upload it to dragonsgate later tonight if your problem still persists... At 07:05 AM 6/2/2007, BobGardner@aol.com wrote: >I clicked on the demos link in the about box and I got a 'Sorry' box >about demos html not found and maybe I typed the url wrong... except >that I clicked on the url in the about box. Seems like once upon a >time I could ftp from somewhere in dragonsgate to get the latest beta? > > > > >---------- >See what's free at AOL.com. >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From sl at ecpower.dk Mon Jun 4 14:58:40 2007 From: sl at ecpower.dk (Steven Lose) Date: Mon Jun 4 15:08:42 2007 Subject: [Icc-avr] Adr. of variables Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EBBB8@seattle.ecpower.dk> Hi. While trying to find a bug, I have made a lot of dummy variables to try and figure out if any variable gets overwritten. But to work, they must be next in memory to the variables I want to test. How do I make sure? I can't convince my self when looking at the map file. Should the Variables be initialized at boot or by Init function afterwards? My code is like this: Unsigned char ucMemDebug1 = 0x55; Unsigned char ucOriginalVariable1; Unsigned char ucMemDebug2 = 0x55; Unsigned char ucOriginalVariable2; Unsigned char ucMemDebug3 = 0x55; Etc. A function is checking the variables during runtime to se if they are overwritten. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070604/18a6646d/attachment.html From richard-lists at imagecraft.com Mon Jun 4 15:25:16 2007 From: richard-lists at imagecraft.com (Richard) Date: Mon Jun 4 15:35:51 2007 Subject: [Icc-avr] Adr. of variables In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EBBB8@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1EBBB8@seattle.ecpower.dk> Message-ID: <200706042235.l54MZota057807@dragonsgate2.imagecraft.com> If they are global or static variables, all the ones with initialization will be together in the "data" area. All the ones without explicit init will be together in the "bss" area. Although the order of allocation is not guaranteed and in fact, I believe is backward between the data and bss areas. All the bss variables are initialized to zero by the Startup code. See Help on Startup code and "Program Areas" for detail. If they are on the stack, then some variables may be allocated to registers. At 02:58 PM 6/4/2007, Steven Lose wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7A6F3.832E7369" > >Hi. > >While trying to find a bug, I have made a lot of dummy variables to >try and figure out if any variable gets overwritten. > >But to work, they must be next in memory to the variables I want to test. > >How do I make sure? >I can't convince my self when looking at the map file. >Should the Variables be initialized at boot or by Init function afterwards? > >My code is like this: > >Unsigned char ucMemDebug1 = 0x55; >Unsigned char ucOriginalVariable1; >Unsigned char ucMemDebug2 = 0x55; >Unsigned char ucOriginalVariable2; >Unsigned char ucMemDebug3 = 0x55; > >Etc. > >A function is checking the variables during runtime to se if they >are overwritten. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jh.bodin at telia.com Tue Jun 5 03:06:10 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Tue Jun 5 03:16:12 2007 Subject: [Icc-avr] Adr. of variables In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA1EBBB8@seattle.ecpower.dk> References: <072D96786BFC014AAEBA9EB07A8070EA1EBBB8@seattle.ecpower.dk> Message-ID: <46653592.8090808@telia.com> Steven Lose wrote: > But to work, they must be next in memory to the variables I want to test. You could try an array and use an element somwhere in the middle. Regards Johan Bodin char bLoop; char abChunk[21]; ... // test variable surrounded by +/-10 bytes #define MYTESTVAR *((char *)(&abChunk[10])) ... // init' all bytes for (bLoop = 0; bLoop < 21, bLoop++) abChunk[bLoop] = 0; // or other suitable known value MYTESTVAR = somevalue; vRunTheCodeThatIsSuspectedToCurruptMemory (); vCheckTheContentsOfabChunk (); ... From asyms at technosoft.co.uk Tue Jun 5 04:19:42 2007 From: asyms at technosoft.co.uk (Andy Syms) Date: Tue Jun 5 04:36:04 2007 Subject: [Icc-avr] Two wire interface (I2C) In-Reply-To: <46653592.8090808@telia.com> Message-ID: I have seen in an application note that the TWBR register must not be set to less than 10. There is no mention of this limitation in the Mega2560 data sheet that I can see; does anyone know if is it still valid ? Regards Andy From sl at ecpower.dk Tue Jun 5 08:06:43 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue Jun 5 08:16:45 2007 Subject: SV: [Icc-avr] Adr. of variables References: <072D96786BFC014AAEBA9EB07A8070EA1EBBB8@seattle.ecpower.dk> <46653592.8090808@telia.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA1EBC1F@seattle.ecpower.dk> Hi Johan. It's a big change with risk of introducing another error. I have introduced a smaller change by init all variables so they get put in the same data area. Richard: wasn't there a change some time ago allowing static variables to be viewed in the map file? 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 Johan H. Bodin Sendt: 5. juni 2007 12:06 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: [Icc-avr] Adr. of variables Steven Lose wrote: > But to work, they must be next in memory to the variables I want to test. You could try an array and use an element somwhere in the middle. Regards Johan Bodin char bLoop; char abChunk[21]; ... // test variable surrounded by +/-10 bytes #define MYTESTVAR *((char *)(&abChunk[10])) ... // init' all bytes for (bLoop = 0; bLoop < 21, bLoop++) abChunk[bLoop] = 0; // or other suitable known value MYTESTVAR = somevalue; vRunTheCodeThatIsSuspectedToCurruptMemory (); vCheckTheContentsOfabChunk (); ... _______________________________________________ Icc-avr mailing list Icc-avr@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Tue Jun 5 10:08:21 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Jun 5 10:18:25 2007 Subject: [Icc-avr] Two wire interface (I2C) In-Reply-To: References: <46653592.8090808@telia.com> Message-ID: The only limitation I'm aware of in the TWI is that the CPU clock must be at least 16x the TWI bit rate in slave mode. In master mode, the setting of TWBR depends on the slowest external slave device on the I2C bus. It would help to know of which application note you are thinking. All the best for now, John At 12:19 05/06/2007, you wrote: >I have seen in an application note that the TWBR register must not be set to >less than 10. > >There is no mention of this limitation in the Mega2560 data sheet that I can >see; does anyone know if is it still valid ? > >Regards > >Andy > > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From paul.aa9gg at gmail.com Tue Jun 5 10:36:08 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Jun 5 10:46:08 2007 Subject: [Icc-avr] Two wire interface (I2C) In-Reply-To: References: <46653592.8090808@telia.com> Message-ID: <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.com> I think this is the one your talking about: http://www.atmel.com/dyn/resources/prod_documents/doc2564.pdf On 6/5/07, John Baraclough wrote: > > The only limitation I'm aware of in the TWI is that the CPU clock > must be at least 16x the TWI bit rate in slave mode. In master mode, > the setting of TWBR depends on the slowest external slave device on > the I2C bus. It would help to know of which application note you are > thinking. > > All the best for now, > John > > > At 12:19 05/06/2007, you wrote: > >I have seen in an application note that the TWBR register must not be set > to > >less than 10. > > > >There is no mention of this limitation in the Mega2560 data sheet that I > can > >see; does anyone know if is it still valid ? > > > >Regards > > > >Andy > > > > > >_______________________________________________ > >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070605/e58236b7/attachment-0001.html From j_baraclough at zetnet.co.uk Tue Jun 5 12:46:35 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Jun 5 12:56:40 2007 Subject: [Icc-avr] Two wire interface (I2C) In-Reply-To: <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.co m> References: <46653592.8090808@telia.com> <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.com> Message-ID: OK, I've got it now. I notice that the app. note is dated September 2004 and doesn't give any reason for that minimum setting. It also states that the prescalar bits in the status register should be set to zero, which is really strange. The only reason I can think of for requiring a minimum of 10 CPU clocks for each cycle of SCL is to allow the CPU to execute some cycles after the start condition is transmitted and before the interrupt occurs. I can't think of any good reason for not using the prescalar. Anyway I've put a question on comp.arch.embedded as there are a couple of Atmel employees who lurk there and occasionally answer questions. All the best for now, John At 18:36 05/06/2007, you wrote: >I think this is the one your talking about: >http://www.atmel.com/dyn/resources/prod_documents/doc2564.pdf > > >On 6/5/07, John Baraclough ><j_baraclough@zetnet.co.uk> wrote: >The only limitation I'm aware of in the TWI is that the CPU clock >must be at least 16x the TWI bit rate in slave mode. In master mode, >the setting of TWBR depends on the slowest external slave device on >the I2C bus. It would help to know of which application note you are >thinking. > >All the best for now, >John > > >At 12:19 05/06/2007, you wrote: > >I have seen in an application note that the TWBR register must not be set to > >less than 10. > > > >There is no mention of this limitation in the Mega2560 data sheet > that I can > >see; does anyone know if is it still valid ? > > > >Regards > > > >Andy > > > > > >_______________________________________________ > >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070605/2e8ebc0c/attachment.html From paul.aa9gg at gmail.com Tue Jun 5 12:59:32 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Jun 5 13:09:41 2007 Subject: [Icc-avr] Two wire interface (I2C) In-Reply-To: References: <46653592.8090808@telia.com> <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.com> Message-ID: <20f5efc40706051259t6c33303eo3bea84923bc6c3a3@mail.gmail.com> ...and let's not forget the boys at AVR Freaks ( www.avrfreaks.net ) Anyway I've put a question on comp.arch.embedded as there are a couple of > Atmel employees who lurk there and occasionally answer questions. > > Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070605/789bd365/attachment.html From j_baraclough at zetnet.co.uk Tue Jun 5 13:05:14 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Jun 5 13:15:16 2007 Subject: [Icc-avr] Two wire interface (I2C) In-Reply-To: <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.co m> References: <46653592.8090808@telia.com> <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.com> Message-ID: The description of the TWI module in my copy of the mega8 data sheet (dated 10/03) has a footnote regarding the setting of the TWBR to a minimum of 10. I think it is unlikely that the TWI module has changed much between then and now, so I would err on the side of caution and use that value. It does mean that you'll have to use a CPU clock of 4MHz to achieve the maximum 400kHz throughput on the TWI, but you're probably doing that anyway. All the best for now, John From jassenbaum at htp-tel.de Tue Jun 5 16:44:26 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Jun 5 16:52:37 2007 Subject: [Icc-avr] Two wire interface (I2C) References: <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.com> Message-ID: The reason for recommended TWBR setting to 10 minimum can be evaluated from "Two-wire Serial Interface Characteristics" (see footnotes). It has nothing to do with execute extra cpu cycles but with TWI timing. Some more-easy-to-understand explanations can be found in appnote AVR315 (doc2564.pdf) on page 4: "If TWBR is lower than 10, the Master may produce an incorrect output on SDA and SCL for the reminder of the byte." and in datasheet of ATmega406 Rev E on page 145: "The problem occurs when operating the TWI in Master mode, sending Start + SLA + R/W to a slave (a slave does not need to be connected to the bus for the condition to happen)." And the recommendation for not using the prescaler is just "to simplify the handling of the TWI Status bits." (doc2564.pdf, page 4, again) I think, if you take a look to "Table 1. CPU and SCL frequencies versus Bit Rate Generator register settings" (doc2564.pdf, page 5), you'll not think of using the prescaler no more. Except, you want to slow down your TWI to very low speed, say, 400Hz for any reason - what I'd call really strange, then :-) Best regards, Johannes > OK, I've got it now. I notice that the app. note is dated September > 2004 and doesn't give any reason for that minimum setting. It also > states that the prescalar bits in the status register should be set > to zero, which is really strange. > The only reason I can think of for requiring a minimum of 10 CPU > clocks for each cycle of SCL is to allow the CPU to execute some > cycles after the start condition is transmitted and before the > interrupt occurs. I can't think of any good reason for not using the prescalar. > Anyway I've put a question on comp.arch.embedded as there are a > couple of Atmel employees who lurk there and occasionally answer questions. > All the best for now, > John > At 18:36 05/06/2007, you wrote: >>I think this is the one your talking about: >>http://www.atmel.com >>/dyn/resources/prod_documents/doc2564.pdf >> >> >>On 6/5/07, John Baraclough >><j_baraclough@zetnet.co.uk> wrote: >>The only limitation I'm aware of in the TWI is that the CPU clock >>must be at least 16x the TWI bit rate in slave mode. In master mode, >>the setting of TWBR depends on the slowest external slave device on >>the I2C bus. It would help to know of which application note you are >>thinking. >> >>All the best for now, >>John >> >> >>At 12:19 05/06/2007, you wrote: >> >I have seen in an application note that the TWBR register must not be set to >> >less than 10. >> > >> >There is no mention of this limitation in the Mega2560 data sheet >> that I can >> >see; does anyone know if is it still valid ? >> > >> >Regards >> > >> >Andy >> > >> > >> >_______________________________________________ >> >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 jassenbaum at htp-tel.de Tue Jun 5 16:45:06 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Jun 5 16:53:18 2007 Subject: [Icc-avr] Two wire interface (I2C) References: <20f5efc40706051036o16755e03gd7c4ca7570d32571@mail.gmail.com> Message-ID: The formula for TWI clock is cpu clock / (16 + (2*TWBR)*4^TWPS So you'll need a cpu clock of at least 14.4MHz to achieve the 400kHz throughput on TWI. Best regards, Johannes > The description of the TWI module in my copy of the mega8 data sheet > (dated 10/03) has a footnote regarding the setting of the TWBR to a > minimum of 10. I think it is unlikely that the TWI module has changed > much between then and now, so I would err on the side of caution and > use that value. It does mean that you'll have to use a CPU clock of > 4MHz to achieve the maximum 400kHz throughput on the TWI, but you're > probably doing that anyway. > All the best for now, > John > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr From jassenbaum at htp-tel.de Wed Jun 6 16:45:47 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Jun 6 16:54:25 2007 Subject: [Icc-avr] New Map File Summary to come Message-ID: Hi all, if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to ask you to beta-test new Map File Summary IDE function to be released soon. Thanks to the suggestions, I got from some of you, new Map File Summary tells more details especially about flash usage (e.g. if and how much flash space is reserved for boot loader by compiler options) and the memory space left (for flash and eeprom). And it calculates boot loader adresses correctly now. To test it, just download http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll and copy the dll to you iccv7avr bin directory (with IDE closed). (URL will become invalid as soon as dll is part of iccv7avr setup.) Thank you for support. Best regards, Johannes From tim at sabretechnology.co.uk Fri Jun 8 02:06:33 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Fri Jun 8 02:16:41 2007 Subject: [Icc-avr] 128K devices and Pro version Message-ID: <04671BB8D269034BBC4BB6BA894867260A7B31@sserver.SabreTechnology.local> Hello, I'm a bit confused about the Pro version of the compiler and 128K devices. Can anyone explain how it works to me? I'm currently writing some code for an AT90USB1287 with the Std compiler, which only supports 64K code, and we are at about 95% full. I think this is 95% of the 64K not 95% of the 128K. The help file contains various references to "setting RAMPZ manually" if I want to use the upper 64K code space, and keeping arrays within the same 64K space. If I upgrade to the Pro version, does it handle RAMPZ automatically, and I can use the full 128K while the compiler worries about RAMPZ? -- 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 snewbold at unlnotes.unl.edu Fri Jun 8 02:11:35 2007 From: snewbold at unlnotes.unl.edu (Stefan Newbold) Date: Fri Jun 8 02:21:38 2007 Subject: [Icc-avr] Stefan Newbold is out of the office. Message-ID: I will be out of the office starting 06/06/2007 and will not return until 06/12/2007. I will respond to your message when I return. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070608/292e00b6/attachment.html From richard-lists at imagecraft.com Fri Jun 8 02:25:54 2007 From: richard-lists at imagecraft.com (Richard) Date: Fri Jun 8 02:36:07 2007 Subject: [Icc-avr] 128K devices and Pro version In-Reply-To: <04671BB8D269034BBC4BB6BA894867260A7B31@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867260A7B31@sserver.SabreTechnology.local> Message-ID: <200706080936.l589a7S3013987@dragonsgate2.imagecraft.com> RAMPZ is only used for referencing constant in the upper pages. For program code usage, things are transparent. And yes, the 95% full is in relation to the 64K byte limit. At 02:06 AM 6/8/2007, Tim Mitchell wrote: >Hello, > >I'm a bit confused about the Pro version of the compiler and 128K >devices. Can anyone explain how it works to me? > >I'm currently writing some code for an AT90USB1287 with the Std >compiler, which only supports 64K code, and we are at about 95% full. I >think this is 95% of the 64K not 95% of the 128K. > >The help file contains various references to "setting RAMPZ manually" if >I want to use the upper 64K code space, and keeping arrays within the >same 64K space. If I upgrade to the Pro version, does it handle RAMPZ >automatically, and I can use the full 128K while the compiler worries >about RAMPZ? // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From tim at sabretechnology.co.uk Fri Jun 8 03:54:59 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Fri Jun 8 04:05:07 2007 Subject: [Icc-avr] 128K devices and Pro version Message-ID: <04671BB8D269034BBC4BB6BA894867260A7B37@sserver.SabreTechnology.local> Richard wrote: > RAMPZ is only used for referencing constant in the upper pages. For > program code usage, things are transparent. > > And yes, the 95% full is in relation to the 64K byte limit. OK, so basically it will handle anything which does not involve lpm/elpm instructions? My application drives a graphical LCD so I have a lot of constant arrays defined for the character set generation, e.g. const unsigned char charwidth0[]={ 2,2,4,6,6,5,6,3,3,3,6,4,3,4,2,5, 5,3,5,5,5,5,5,5,5,5,2,3,4,5,4,6, 6,6,5,6,6,5,5,6,6,4,5,5,5,6,5,6, 5,6,5,5,6,5,6,6,6,6,5,3,5,3,4,5, 3,5,5,4,5,5,3,5,5,2,3,5,2,6,5,5, 5,5,4,3,3,5,4,6,4,5,4,4,2,4,6,6}; Will the compiler handle accesses to this array transparently? Or do I have to force the location of the array into a known page and set RAMPZ myself when accessing it? (How do you do that?) > At 02:06 AM 6/8/2007, Tim Mitchell wrote: >> Hello, >> >> I'm a bit confused about the Pro version of the compiler and 128K >> devices. Can anyone explain how it works to me? >> >> I'm currently writing some code for an AT90USB1287 with the Std >> compiler, which only supports 64K code, and we are at about 95% >> full. I think this is 95% of the 64K not 95% of the 128K. >> >> The help file contains various references to "setting RAMPZ manually" >> if I want to use the upper 64K code space, and keeping arrays within >> the same 64K space. If I upgrade to the Pro version, does it handle >> RAMPZ automatically, and I can use the full 128K while the compiler >> worries about RAMPZ? > > // richard (This email is for mailing lists. To reach me directly, > please use richard at imagecraft.com) > > _______________________________________________ > Icc-avr mailing list > Icc-avr@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-avr -- 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 info at imagecraft.com Fri Jun 8 04:13:26 2007 From: info at imagecraft.com (ImageCraft) Date: Fri Jun 8 04:23:40 2007 Subject: [Icc-avr] Re: I have interrupt/ISR. Linker gives error. Any t houghts. In-Reply-To: <754643.79003.qm@web33013.mail.mud.yahoo.com> References: <754643.79003.qm@web33013.mail.mud.yahoo.com> Message-ID: <200706081123.l58BNcEr015471@dragonsgate2.imagecraft.com> Did you for sure selected M6450 in Project->Options->Target? At 07:34 PM 6/7/2007, Babuddin Ahmad wrote: >Hello All: > >I am working with Atmel 6450. > >The code looks as below: >#pragma interrupt_handler timer0_ovf_isr:12 >void timer0_ovf_isr() { ... } > >error: >code address 0:0x16 already contains a value. >code address 0:0x17 already contains a value. > >Please help me to solve this problem. > >Note: The above code works with another Atmel 8 bit >controller. > >Waiting for your response. > >Babuddin > > > > >____________________________________________________________________________________ >Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s >user panel and lay it on us. >http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 // info 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 jassenbaum at htp-tel.de Fri Jun 8 12:32:28 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Fri Jun 8 12:40:37 2007 Subject: [Icc-avr] Re: I have interrupt/ISR. Linker gives error. Any thoughts. References: <754643.79003.qm@web33013.mail.mud.yahoo.com> <200706081123.l58BNcEr015471@dragonsgate2.imagecraft.com> Message-ID: Babuddin, please be careful with numerical interrupt vectors. They may work with another controller, but because same interrupt may have another number on other controllers, they may fail as well. The only safe way to use interrupt handler pragmas for any controller that support same intterupt, are symbolic interrupt vector names, as defined in the io header files and supported by application builder since begin of this year. E.g. #pragma interrupt_handler timer0_ovf_isr: iv_TIMER0_OVF void timer0_ovf_isr() { ... } will work correctly even if interrupt vector number is different from 12. You always must setup compiler options for the right part and #include the right io header file, of course. Hope it helps. Johannes > At 07:34 PM 6/7/2007, Babuddin Ahmad wrote: >>Hello All: >> >>I am working with Atmel 6450. >> >>The code looks as below: >>#pragma interrupt_handler timer0_ovf_isr:12 >>void timer0_ovf_isr() { ... } >> >>error: >>code address 0:0x16 already contains a value. >>code address 0:0x17 already contains a value. >> >>Please help me to solve this problem. >> >>Note: The above code works with another Atmel 8 bit >>controller. >> >>Waiting for your response. >> >>Babuddin >> >> >> >> >>___________________________________________________________________________________ From russccit at gmail.com Sun Jun 10 03:35:31 2007 From: russccit at gmail.com (Orous Husky) Date: Sun Jun 10 03:45:38 2007 Subject: [Icc-avr] Paid Assistance With AVR Project Message-ID: <6d58c5f0706100335k7aebe21cn5bad17beb1185a8c@mail.gmail.com> Hi All, If this is an imappropiate place to post this, please forgive my error. I'm trying to get a project off the ground and could use assistance. I'd like to use an AVR butterfly to display the position of a linear position pot in 32nds of an inch from 0/32 to 34/32. I'm using a linear 10K pot output to PF0. This is a simple proof of concept design, so the program should just loop thru and display readings on the LCD display. I'd of course want this is Icc-AVR and would need the source. I can't afford much, $60 USD but this could start us on a relationship for more work. Next steps for the project include a pressure transducer (0-5VDC output) and sending the collected data out the UART. Thank you Russ ccit@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070610/7942bc75/attachment.html From tim at sabretechnology.co.uk Tue Jun 12 00:52:08 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Jun 12 01:02:22 2007 Subject: [Icc-avr] 128K devices and Pro version Message-ID: <04671BB8D269034BBC4BB6BA894867260A7B57@sserver.SabreTechnology.local> Sorry to keep on about this, but I am still not sure of the answer, if I upgrade to Advanced or Pro version, can I use the upper 64K of flash in my 128K device to store constant data? And if so, do I have to manually fix the location of all constant data so that I can ensure that RAMPZ is set correctly? In Sept 06 there is an entry in the list where Richard says that in the "next release" he will add an option to support transparent access to const data for >64K devices - I can't find such an option in the latest version, did it ever happen? (http://dragonsgate.net/pipermail/icc-avr/2006-September/007695.html) -- 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 richard-lists at imagecraft.com Tue Jun 12 01:36:01 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Jun 12 01:46:15 2007 Subject: [Icc-avr] 128K devices and Pro version In-Reply-To: <04671BB8D269034BBC4BB6BA894867260A7B57@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867260A7B57@sserver.SabreTechnology.local> Message-ID: <200706120846.l5C8kEKZ068352@dragonsgate2.imagecraft.com> At 12:52 AM 6/12/2007, Tim Mitchell wrote: >Sorry to keep on about this, but I am still not sure of the answer, if I >upgrade to Advanced or Pro version, can I use the upper 64K of flash in >my 128K device to store constant data? And if so, do I have to manually >fix the location of all constant data so that I can ensure that RAMPZ is >set correctly? Yes, you can use the upper 64K to store constant, and currently you will still need to set RAMPZ manually. It's not so bad though. By default, all the constant data are loaded first, so you can use the Map file to see if it overflows to the upper 64K page. If it does, you can just partition your data such that for example, a big table would be in the upper 64K and all the other ones in the lower 64K so it's easy to change RAMPZ when you access the big table. >In Sept 06 there is an entry in the list where Richard says that in the >"next release" he will add an option to support transparent access to >const data for >64K devices - I can't find such an option in the latest >version, did it ever happen? >(http://dragonsgate.net/pipermail/icc-avr/2006-September/007695.html) Not yet... lots to do, not enough time.. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From tim at sabretechnology.co.uk Tue Jun 12 02:56:07 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Jun 12 03:06:32 2007 Subject: [Icc-avr] 128K devices and Pro version Message-ID: <04671BB8D269034BBC4BB6BA894867260A7B5D@sserver.SabreTechnology.local> Richard wrote: > At 12:52 AM 6/12/2007, Tim Mitchell wrote: >> Sorry to keep on about this, but I am still not sure of the answer, >> if I upgrade to Advanced or Pro version, can I use the upper 64K of >> flash in my 128K device to store constant data? And if so, do I have >> to manually fix the location of all constant data so that I can >> ensure that RAMPZ is set correctly? > > Yes, you can use the upper 64K to store constant, and currently you > will still need to set RAMPZ manually. It's not so bad though. By > default, all the constant data are loaded first, so you can use the > Map file to see if it overflows to the upper 64K page. If it does, > you can just partition your data such that for example, a big table > would be in the upper 64K and all the other ones in the lower 64K so > it's easy to change RAMPZ when you access the big table. > Still confused. In the map file, it does not seem to list constants declared inline... E.g. I have a function void disp_string(const char *x) if I call disp_string("Hello World") the string "Hello World" is referenced as L130 in the source file, but is not listed at all in the "lit" area of the map file and there doesn't seem to be space left for it - how do I find out where it is stored? The lit area only seems to list constants declared separately, eg const char teststring[]="Hello World" is listed as "teststring" in the map file. -- 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 tim at sabretechnology.co.uk Tue Jun 12 03:12:54 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Jun 12 03:23:16 2007 Subject: [Icc-avr] 128K devices and Pro version - map file question Message-ID: <04671BB8D269034BBC4BB6BA894867260A7B5F@sserver.SabreTechnology.local> Re my earlier post about map file, having analysed the hex file it appears the "inline" consts are concealed within the lit area listing, in between the named consts. -- 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 richard-lists at imagecraft.com Tue Jun 12 03:42:03 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue Jun 12 03:52:17 2007 Subject: [Icc-avr] 128K devices and Pro version In-Reply-To: <04671BB8D269034BBC4BB6BA894867260A7B5D@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867260A7B5D@sserver.SabreTechnology.local> Message-ID: <200706121052.l5CAqGLf070295@dragonsgate2.imagecraft.com> Does your lit area straddle both pages? If not, then you don't have a problem!! At 02:56 AM 6/12/2007, Tim Mitchell wrote: >Still confused. >In the map file, it does not seem to list constants declared inline... > >E.g. I have a function >void disp_string(const char *x) > >if I call disp_string("Hello World") the string "Hello World" is >referenced as L130 in the source file, but is not listed at all in the >"lit" area of the map file and there doesn't seem to be space left for >it - how do I find out where it is stored? > >The lit area only seems to list constants declared separately, >eg const char teststring[]="Hello World" is listed as "teststring" in >the map file. > > >-- >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 > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From tim at sabretechnology.co.uk Tue Jun 12 04:52:06 2007 From: tim at sabretechnology.co.uk (Tim Mitchell) Date: Tue Jun 12 05:02:33 2007 Subject: [Icc-avr] 128K devices and Pro version Message-ID: <04671BB8D269034BBC4BB6BA894867260A7B69@sserver.SabreTechnology.local> Richard wrote: > Does your lit area straddle both pages? If not, then you don't have a > problem!! > No, it does not, so it will be OK. I was just worrying that some strings were not in the lit area, but it appears they are there, just not listed. -- 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 j_baraclough at zetnet.co.uk Tue Jun 12 12:32:51 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Tue Jun 12 12:42:57 2007 Subject: [Icc-avr] 128K devices and Pro version In-Reply-To: <04671BB8D269034BBC4BB6BA894867260A7B69@sserver.SabreTechno logy.local> References: <04671BB8D269034BBC4BB6BA894867260A7B69@sserver.SabreTechnology.local> Message-ID: Hi Tim, If the compiler finds exactly the same string used more than once in any particular source file it will only include that string once in the lit area and reference that occurrence accordingly. However, if that string is used in more than one source file, it will be included in the lit area for every source file in which it occurs. This can sometimes be a little confusing if you look at the contents of the Flash in AVRStudio and see the same string in several places. For strings that are used across files, a single literal declaration is the best approach. All the best for now, John At 12:52 12/06/2007, you wrote: >Richard wrote: > > Does your lit area straddle both pages? If not, then you don't have a > > problem!! > > > >No, it does not, so it will be OK. I was just worrying that some strings >were not in the lit area, but it appears they are there, just not >listed. > >-- >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 > >_______________________________________________ >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/20070612/9f63172d/attachment.html From paul.aa9gg at gmail.com Tue Jun 12 13:22:18 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Jun 12 13:32:30 2007 Subject: [Icc-avr] New Map File Summary to come In-Reply-To: References: Message-ID: <20f5efc40706121322r12ab4328yc63f60867a6c2e40@mail.gmail.com> I think I found a problem.. assuming I'm reading it correctly. In the area of "SRAM area "bss" = 1234 (0x4D2) bytes from 0x0128 to 0x05F9 these are all my variables...correct? ok..if so most of the sizes are correct but there is one VERY wrong. I have defined "done" as an integer and it is reporting a size of 44 bytes! The processor is an AtMega6490 and I'm at about 99% full. On 6/6/07, Johannes Assenbaum wrote: > > Hi all, > > if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to > ask you to beta-test new Map File Summary IDE function to be released soon. > > Thanks to the suggestions, I got from some of you, new Map File Summary > tells more details especially about flash usage (e.g. if and how much > flash space is reserved for boot loader by compiler options) and the memory > space left (for flash and eeprom). And it calculates boot loader adresses > correctly now. > > To test it, just download > http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll > and copy the dll to you iccv7avr bin directory (with IDE closed). > > (URL will become invalid as soon as dll is part of iccv7avr setup.) > > Thank you for support. > > Best regards, > Johannes > > _______________________________________________ > 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/20070612/b6d46e83/attachment.html From rodney at junipersys.com Tue Jun 12 13:58:32 2007 From: rodney at junipersys.com (Rodney Pearson) Date: Tue Jun 12 14:08:56 2007 Subject: [Icc-avr] New Map File Summary to come In-Reply-To: <20f5efc40706121322r12ab4328yc63f60867a6c2e40@mail.gmail.com> References: <20f5efc40706121322r12ab4328yc63f60867a6c2e40@mail.gmail.com> Message-ID: When I have run into one of these in the past it usually means I have a string literal somewhere (usually printf() and I have not selected the "Strings in Flash Only" option in the "Target" options. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Paul Mateer Sent: Tuesday, June 12, 2007 2:22 PM To: Johannes Assenbaum; 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] New Map File Summary to come I think I found a problem.. assuming I'm reading it correctly. In the area of "SRAM area "bss" = 1234 (0x4D2) bytes from 0x0128 to 0x05F9 these are all my variables...correct? ok..if so most of the sizes are correct but there is one VERY wrong. I have defined "done" as an integer and it is reporting a size of 44 bytes! The processor is an AtMega6490 and I'm at about 99% full. On 6/6/07, Johannes Assenbaum wrote: Hi all, if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to ask you to beta-test new Map File Summary IDE function to be released soon. Thanks to the suggestions, I got from some of you, new Map File Summary tells more details especially about flash usage ( e.g. if and how much flash space is reserved for boot loader by compiler options) and the memory space left (for flash and eeprom). And it calculates boot loader adresses correctly now. To test it, just download http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll and copy the dll to you iccv7avr bin directory (with IDE closed). (URL will become invalid as soon as dll is part of iccv7avr setup.) Thank you for support. Best regards, Johannes _______________________________________________ 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/20070612/d4f1ae3a/attachment.html From paul.aa9gg at gmail.com Tue Jun 12 14:09:10 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Tue Jun 12 14:19:20 2007 Subject: [Icc-avr] New Map File Summary to come In-Reply-To: References: <20f5efc40706121322r12ab4328yc63f60867a6c2e40@mail.gmail.com> Message-ID: <20f5efc40706121409n3985c0feo9743a0c14c051465@mail.gmail.com> nope....just double checked On 6/12/07, Rodney Pearson wrote: > > When I have run into one of these in the past it usually means I have a > string literal somewhere (usually printf() and I have not selected the > "Strings in Flash Only" option in the "Target" options. > > > > Cheers! > > > > Rodney Pearson > > Software Engineer > > Juniper Systems, Inc. > > www.junipersys.com > > > ------------------------------ > > *From:* icc-avr-bounces@imagecraft.com [mailto: > icc-avr-bounces@imagecraft.com] *On Behalf Of *Paul Mateer > *Sent:* Tuesday, June 12, 2007 2:22 PM > *To:* Johannes Assenbaum; 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] New Map File Summary to come > > > > I think I found a problem.. assuming I'm reading it correctly. > In the area of "SRAM area "bss" = 1234 (0x4D2) bytes from 0x0128 to 0x05F9 > > these are all my variables...correct? > > ok..if so most of the sizes are correct but there is one VERY wrong. I > have defined "done" as an integer and it is reporting a size of 44 bytes! > The processor is an AtMega6490 and I'm at about 99% full. > > On 6/6/07, *Johannes Assenbaum* wrote: > > Hi all, > > if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to > ask you to beta-test new Map File Summary IDE function to be released soon. > > Thanks to the suggestions, I got from some of you, new Map File Summary > tells more details especially about flash usage ( e.g. if and how much > flash space is reserved for boot loader by compiler options) and the memory > space left (for flash and eeprom). And it calculates boot loader adresses > correctly now. > > To test it, just download > http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll > and copy the dll to you iccv7avr bin directory (with IDE closed). > > (URL will become invalid as soon as dll is part of iccv7avr setup.) > > Thank you for support. > > Best regards, > Johannes > > _______________________________________________ > 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 > > -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070612/7eff0de1/attachment-0001.html From jassenbaum at htp-tel.de Tue Jun 12 14:32:20 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Tue Jun 12 14:40:32 2007 Subject: [off-list] RE: [Icc-avr] 128K devices and Pro version References: <04671BB8D269034BBC4BB6BA894867260A7B57@sserver.SabreTechnology.local> Message-ID: > In Sept 06 there is an entry in the list where Richard says that in the > "next release" he will add an option to support transparent access to > const data for >64K devices - I can't find such an option in the latest > version, did it ever happen? > (http://dragonsgate.net/pipermail/icc-avr/2006-September/007695.html) Thank you! Even if reply was not really satisfying :-| I mean, I'm trying to win Richard to support fully transparent lit area of any size for over two years now, and the area name "elit" he mentioned was actually invoked by myself. Best regards, Johannes From sl at ecpower.dk Tue Jun 12 23:31:29 2007 From: sl at ecpower.dk (Steven Lose) Date: Tue Jun 12 23:41:42 2007 Subject: SV: [Icc-avr] New Map File Summary to come References: <20f5efc40706121322r12ab4328yc63f60867a6c2e40@mail.gmail.com> <20f5efc40706121409n3985c0feo9743a0c14c051465@mail.gmail.com> Message-ID: <072D96786BFC014AAEBA9EB07A8070EA22F1D1@seattle.ecpower.dk> Hi. If you have some static variables it would look like that. Unsigned char ucA; Static Unsigned char ucB; Looks in map file like ucA is 2 byte Med venlig hilsen / Best regards / mit freundlichen Gr??en EC POWER A/S Steven Lose Software Ingeni?r Tlf.: +45 87434100 Direkte tlf. +45 58286608 Email: sl@ecpower.dk www.ecpower.dk ________________________________ Fra: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] P? vegne af Paul Mateer Sendt: 12. juni 2007 23:09 Til: Discussion list for ICCAVR and ICCtiny Users. You do NOT need tosubscribe to icc-announce if you are a member of this. Emne: Re: [Icc-avr] New Map File Summary to come nope....just double checked On 6/12/07, Rodney Pearson wrote: When I have run into one of these in the past it usually means I have a string literal somewhere (usually printf() and I have not selected the "Strings in Flash Only" option in the "Target" options. Cheers! Rodney Pearson Software Engineer Juniper Systems, Inc. www.junipersys.com ________________________________ From: icc-avr-bounces@imagecraft.com [mailto: icc-avr-bounces@imagecraft.com ] On Behalf Of Paul Mateer Sent: Tuesday, June 12, 2007 2:22 PM To: Johannes Assenbaum; 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] New Map File Summary to come I think I found a problem.. assuming I'm reading it correctly. In the area of "SRAM area "bss" = 1234 (0x4D2) bytes from 0x0128 to 0x05F9 these are all my variables...correct? ok..if so most of the sizes are correct but there is one VERY wrong. I have defined "done" as an integer and it is reporting a size of 44 bytes! The processor is an AtMega6490 and I'm at about 99% full. On 6/6/07, Johannes Assenbaum wrote: Hi all, if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to ask you to beta-test new Map File Summary IDE function to be released soon. Thanks to the suggestions, I got from some of you, new Map File Summary tells more details especially about flash usage ( e.g. if and how much flash space is reserved for boot loader by compiler options) and the memory space left (for flash and eeprom). And it calculates boot loader adresses correctly now. To test it, just download http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll and copy the dll to you iccv7avr bin directory (with IDE closed). (URL will become invalid as soon as dll is part of iccv7avr setup.) Thank you for support. Best regards, Johannes _______________________________________________ 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 -- Paul Mateer, AA9GG Elan Engineering Corp. www.elanengr.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070613/55f13aa2/attachment.html From paul.aa9gg at gmail.com Wed Jun 13 06:22:18 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Wed Jun 13 06:32:32 2007 Subject: [Icc-avr] New Map File Summary to come In-Reply-To: <072D96786BFC014AAEBA9EB07A8070EA22F1D1@seattle.ecpower.dk> References: <20f5efc40706121322r12ab4328yc63f60867a6c2e40@mail.gmail.com> <20f5efc40706121409n3985c0feo9743a0c14c051465@mail.gmail.com> <072D96786BFC014AAEBA9EB07A8070EA22F1D1@seattle.ecpower.dk> Message-ID: <20f5efc40706130622m3642f979hed47deb056b8f8b7@mail.gmail.com> nothing is defined as static On 6/13/07, Steven Lose wrote: > > Hi. > > > > If you have some static variables it would look like that. > > > > Unsigned char ucA; > > Static Unsigned char ucB; > > > > Looks in map file like ucA is 2 byte > > Med venlig hilsen / Best regards / mit freundlichen Gr??en > > *EC POWER A/S* > > *Steven Lose* > > Software Ingeni?r > > Tlf.: +45 87434100 > > Direkte tlf. +45 58286608 > > Email: sl@ecpower.dk > > www.ecpower.dk > ------------------------------ > > *Fra:* icc-avr-bounces@imagecraft.com [mailto: > icc-avr-bounces@imagecraft.com] *P? vegne af *Paul Mateer > *Sendt:* 12. juni 2007 23:09 > *Til:* Discussion list for ICCAVR and ICCtiny Users. You do NOT need > tosubscribe to icc-announce if you are a member of this. > *Emne:* Re: [Icc-avr] New Map File Summary to come > > > > nope....just double checked > > On 6/12/07, *Rodney Pearson* wrote: > > When I have run into one of these in the past it usually means I have a > string literal somewhere (usually printf() and I have not selected the > "Strings in Flash Only" option in the "Target" options. > > > > Cheers! > > > > Rodney Pearson > > Software Engineer > > Juniper Systems, Inc. > > www.junipersys.com > > > ------------------------------ > > *From:* icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] > *On Behalf Of *Paul Mateer > *Sent:* Tuesday, June 12, 2007 2:22 PM > *To:* Johannes Assenbaum; 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] New Map File Summary to come > > > > I think I found a problem.. assuming I'm reading it correctly. > In the area of "SRAM area "bss" = 1234 (0x4D2) bytes from 0x0128 to 0x05F9 > > these are all my variables...correct? > > ok..if so most of the sizes are correct but there is one VERY wrong. I > have defined "done" as an integer and it is reporting a size of 44 bytes! > The processor is an AtMega6490 and I'm at about 99% full. > > On 6/6/07, *Johannes Assenbaum* wrote: > > Hi all, > > if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to > ask you to beta-test new Map File Summary IDE function to be released soon. > > Thanks to the suggestions, I got from some of you, new Map File Summary > tells more details especially about flash usage ( e.g. if and how much > flash space is reserved for boot loader by compiler options) and the memory > space left (for flash and eeprom). And it calculates boot loader adresses > correctly now. > > To test it, just download > http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll > and copy the dll to you iccv7avr bin directory (with IDE closed). > > (URL will become invalid as soon as dll is part of iccv7avr setup.) > > Thank you for support. > > Best regards, > Johannes > > _______________________________________________ > 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 > > > > > -- > Paul Mateer, AA9GG > Elan Engineering Corp. > www.elanengr.com > > _______________________________________________ > 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/20070613/feecc1c3/attachment-0001.html From jassenbaum at htp-tel.de Wed Jun 13 11:31:26 2007 From: jassenbaum at htp-tel.de (Johannes Assenbaum) Date: Wed Jun 13 11:39:48 2007 Subject: [Icc-avr] New Map File Summary to come References: <20f5efc40706121409n3985c0feo9743a0c14c051465@mail.gmail.com> <072D96786BFC014AAEBA9EB07A8070EA22F1D1@seattle.ecpower.dk> <20f5efc40706130622m3642f979hed47deb056b8f8b7@mail.gmail.com> Message-ID: <1FLkWqOyA6liaGvu2oNonT0BzlUg09waBBdfSSY2Bk0@akmail> @Paul This is from variables, that are local within an asm source or object module. Some of lib functions use such. In .mp file (and so in Map File Summary, too) they always "longer" the variable listed before, no chance to change this, sorry. @Steven Static variables should not be invisible in map file no more since iccavr V7.09, and Map File Summary should list them as well as non-static variables. If you still find any static variables unlisted, please send me the .mp file. Best regards, Johannes > nothing is defined as static > On 6/13/07, Steven Lose wrote: >> >> Hi. >> >> >> >> If you have some static variables it would look like that. >> >> >> >> Unsigned char ucA; >> >> Static Unsigned char ucB; >> >> >> >> Looks in map file like ucA is 2 byte >> >> Med venlig hilsen / Best regards / mit freundlichen Gr??en >> >> *EC POWER A/S* >> >> *Steven Lose* >> >> Software Ingeni?r >> >> Tlf.: +45 87434100 >> >> Direkte tlf. +45 58286608 >> >> Email: sl@ecpower.dk >> >> www.ecpower.dk >> ------------------------------ >> >> *Fra:* icc-avr-bounces@imagecraft.com [mailto: >> icc-avr-bounces@imagecraft.com] *P? vegne af *Paul Mateer >> *Sendt:* 12. juni 2007 23:09 >> *Til:* Discussion list for ICCAVR and ICCtiny Users. You do NOT need >> tosubscribe to icc-announce if you are a member of this. >> *Emne:* Re: [Icc-avr] New Map File Summary to come >> >> >> >> nope....just double checked >> >> On 6/12/07, *Rodney Pearson* wrote: >> >> When I have run into one of these in the past it usually means I have a >> string literal somewhere (usually printf() and I have not selected the >> "Strings in Flash Only" option in the "Target" options. >> >> >> >> Cheers! >> >> >> >> Rodney Pearson >> >> Software Engineer >> >> Juniper Systems, Inc. >> >> www.junipersys.com >> >> >> ------------------------------ >> >> *From:* icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] >> *On Behalf Of *Paul Mateer >> *Sent:* Tuesday, June 12, 2007 2:22 PM >> *To:* Johannes Assenbaum; 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] New Map File Summary to come >> >> >> >> I think I found a problem.. assuming I'm reading it correctly. >> In the area of "SRAM area "bss" = 1234 (0x4D2) bytes from 0x0128 to 0x05F9 >> >> these are all my variables...correct? >> >> ok..if so most of the sizes are correct but there is one VERY wrong. I >> have defined "done" as an integer and it is reporting a size of 44 bytes! >> The processor is an AtMega6490 and I'm at about 99% full. >> >> On 6/6/07, *Johannes Assenbaum* wrote: >> >> Hi all, >> >> if you are using the latest version of ICCV7 for AVR (7.13A), I'd like to >> ask you to beta-test new Map File Summary IDE function to be released soon. >> >> Thanks to the suggestions, I got from some of you, new Map File Summary >> tells more details especially about flash usage ( e.g. if and how much >> flash space is reserved for boot loader by compiler options) and the memory >> space left (for flash and eeprom). And it calculates boot loader adresses >> correctly now. >> >> To test it, just download >> http://avr.jassenbaum.de/iccv7avr/files/mpdAVR.dll >> and copy the dll to you iccv7avr bin directory (with IDE closed). >> >> (URL will become invalid as soon as dll is part of iccv7avr setup.) >> >> Thank you for support. >> >> Best regards, >> Johannes >> >> _______________________________________________ >> 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 >> >> >> >> >> -- >> Paul Mateer, AA9GG >> Elan Engineering Corp. >> www.elanengr.com >> >> _______________________________________________ >> 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 RichardH at spectra-displays.co.uk Thu Jun 14 08:02:05 2007 From: RichardH at spectra-displays.co.uk (Richard Handley) Date: Thu Jun 14 08:12:18 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny Message-ID: Hi I have a working piece of code which fails when I try to run it at 1200 baud. Using the application builder I get the following (16MHz xtal) UCSR0B = 0x00; //disable while setting baud rate UCSR0A = 0x00; UCSR0C = 0x06; UBRR0L = 0x40; //set baud rate lo UBRR0H = 0x00; //set baud rate hi UCSR0B = 0x18; this fails to communicate with the PC at 1200 baud. If I change it to 9600 - UCSR0B = 0x00; //disable while setting baud rate UCSR0A = 0x00; UCSR0C = 0x06; UBRR0L = 0x67; //set baud rate lo UBRR0H = 0x00; //set baud rate hi UCSR0B = 0x18; Then all works ok. Any ideas what might be wrong?? Kind regards Richard Handley Spectra Displays Ltd Tel: +44 (0) 1954 261 402 Fax: +44 (0) 1954 261 403 www.spectra-displays.co.uk This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Spectra Displays Ltd. (Registered at 194 Station Road, Willingham, Cambridge CB4 5HQ, UK. Reg No: 2428206). If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify Spectra Displays by telephone on +44 (0) 1954 261402 or by fax on +44 (0) 1954 261403 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070614/58f50f7c/attachment.html From DRaymond at Bankspower.com Thu Jun 14 08:19:20 2007 From: DRaymond at Bankspower.com (David Raymond) Date: Thu Jun 14 08:29:34 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: Message-ID: <0E755D4F91B6D344B39791054F52A2A9012208CF@gbexchange.bankspower.local> Try UBRR0H = 0x03; for 1200 baud. 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 Richard Handley Sent: Thursday, June 14, 2007 8:02 AM To: icc-avr@imagecraft.com Subject: [Icc-avr] Mega 128 Baud Rate funny Hi I have a working piece of code which fails when I try to run it at 1200 baud. Using the application builder I get the following (16MHz xtal) UCSR0B = 0x00; //disable while setting baud rate UCSR0A = 0x00; UCSR0C = 0x06; UBRR0L = 0x40; //set baud rate lo UBRR0H = 0x00; //set baud rate hi UCSR0B = 0x18; this fails to communicate with the PC at 1200 baud. If I change it to 9600 - UCSR0B = 0x00; //disable while setting baud rate UCSR0A = 0x00; UCSR0C = 0x06; UBRR0L = 0x67; //set baud rate lo UBRR0H = 0x00; //set baud rate hi UCSR0B = 0x18; Then all works ok. Any ideas what might be wrong?? Kind regards Richard Handley Spectra Displays Ltd Tel: +44 (0) 1954 261 402 Fax: +44 (0) 1954 261 403 www.spectra-displays.co.uk This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Spectra Displays Ltd. (Registered at 194 Station Road, Willingham, Cambridge CB4 5HQ, UK. Reg No: 2428206). If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify Spectra Displays by telephone on +44 (0) 1954 261402 or by fax on +44 (0) 1954 261403 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070614/65b98adb/attachment.html From fletcherjones at worldonline.co.uk Thu Jun 14 08:36:07 2007 From: fletcherjones at worldonline.co.uk (Patrick Fletcher-Jones) Date: Thu Jun 14 08:46:26 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: Message-ID: <000501c7ae99$b9d5bbd0$0c01a8c0@cad> Just had a look and yes the app builder says, UBRR = 832 But the app builder code produced shows UBRR = 64 The MSB is not right, the 9600 does not use the MSB so a value of 0x00 is ok. Have not tested it but just my thoughts. VBR, Patrick -----Original Message----- From: icc-avr-bounces@imagecraft.com [mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Handley Sent: 14 June 2007 16:02 To: icc-avr@imagecraft.com Subject: [Icc-avr] Mega 128 Baud Rate funny Hi I have a working piece of code which fails when I try to run it at 1200 baud. Using the application builder I get the following (16MHz xtal) UCSR0B = 0x00; //disable while setting baud rate UCSR0A = 0x00; UCSR0C = 0x06; UBRR0L = 0x40; //set baud rate lo UBRR0H = 0x00; //set baud rate hi UCSR0B = 0x18; this fails to communicate with the PC at 1200 baud. If I change it to 9600 - UCSR0B = 0x00; //disable while setting baud rate UCSR0A = 0x00; UCSR0C = 0x06; UBRR0L = 0x67; //set baud rate lo UBRR0H = 0x00; //set baud rate hi UCSR0B = 0x18; Then all works ok. Any ideas what might be wrong?? Kind regards Richard Handley Spectra Displays Ltd Tel: +44 (0) 1954 261 402 Fax: +44 (0) 1954 261 403 HYPERLINK "http://www.spectra-displays.co.uk/"www.spectra-displays.co.uk This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Spectra Displays Ltd. (Registered at 194 Station Road, Willingham, Cambridge CB4 5HQ, UK. Reg No: 2428206). If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify Spectra Displays by telephone on +44 (0) 1954 261402 or by fax on +44 (0) 1954 261403 No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 13/06/2007 12:50 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 13/06/2007 12:50 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070614/44702ce4/attachment-0001.html From j_baraclough at zetnet.co.uk Thu Jun 14 09:03:35 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Jun 14 09:13:58 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: References: Message-ID: According to the data sheet a Baud rate of 1200 from 16MHz clock requires a divisor of 832, which is the same as 0x0340. All the best for now, John At 16:02 14/06/2007, you wrote: >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7AE94.F806DD09" >Content-class: urn:content-classes:message > >Hi > >I have a working piece of code which fails when I try to run it at >1200 baud. Using the application builder I get the following (16MHz xtal) > > > UCSR0B = 0x00; //disable while setting baud rate > UCSR0A = 0x00; > UCSR0C = 0x06; > UBRR0L = 0x40; //set baud rate lo > UBRR0H = 0x00; //set baud rate hi > UCSR0B = 0x18; > >this fails to communicate with the PC at 1200 baud. > >If I change it to 9600 - > > UCSR0B = 0x00; //disable while setting baud rate > UCSR0A = 0x00; > UCSR0C = 0x06; > UBRR0L = 0x67; //set baud rate lo > UBRR0H = 0x00; //set baud rate hi > UCSR0B = 0x18; > >Then all works ok. > >Any ideas what might be wrong?? > >Kind regards > >Richard Handley >Spectra Displays Ltd >Tel: +44 (0) 1954 261 402 >Fax: +44 (0) 1954 261 403 >www.spectra-displays.co.uk > >This email is confidential and intended solely for the use of the >individual to whom it is addressed. Any views or opinions presented >are solely those of the author and do not necessarily represent >those of Spectra Displays Ltd. (Registered at 194 Station Road, >Willingham, Cambridge CB4 5HQ, UK. Reg No: 2428206). > >If you are not the intended recipient, be advised that you have >received this email in error and that any use, dissemination, >forwarding, printing, or copying of this email is strictly >prohibited. If you have received this email in error please notify >Spectra Displays by telephone on +44 (0) 1954 261402 or by fax on >+44 (0) 1954 261403 > >_______________________________________________ >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/20070614/b01a1f29/attachment.html From jh.bodin at telia.com Thu Jun 14 09:44:25 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Thu Jun 14 09:54:36 2007 Subject: [Icc-avr] Program doesn't start Message-ID: <46717069.30906@telia.com> Hi, I am struggling with an atmega324p program that refuses to start. Nothing happens at all and all pins seem to stay in input mode (hi-z) after reset. Programming and verification works well and the fuse/lock bits have been carefully checked. Just to see if the program comes alive after reset, I put an endless loop in main() that is supposed to flash a LED. Between the entry point of main and this LED flashing loop, there are only some basic register init's (pin levels & directions etc.). No interrupts are enabled at this point. And now the funny part: I created a new project with just a single source file containing EXACTLY the same main() function - Guess what.. THIS PROGRAM WORKS! The file is attached. BTW, the project options are set exactly the same for both programs. I desperately tried to trace the execution manually from the reset vector to the LED flashing loop but I did not find any vectors in the list files... Do I need a brain transplant or is there something wrong in the compiler? I have been scratching my head for hours, all day actually... Best Regards Johan Bodin -------------- next part -------------- // Desperate test.. #include // CPU dependent stuff #include // SEI(), CLI(), WDR() etc. void main (void) { unsigned short w; // cstartup init' just finshed and we're still running // at Fclk = Fxtal/8 = 460.8 kHz. Let's party! Here we go: // Initialize port levels, directions and pull-ups // PA7 - Unused, configured as input with pull-up // PA6 - Unused, configured as input with pull-up // PA5 - Unused, configured as input with pull-up // PA4 - Unused, configured as input with pull-up // PA3 - "TARIF"!? configured as input with pull-up for now... *#* *#* *#* *#* // PA2 - Unused, configured as input with pull-up // PA1 - Unused, configured as input with pull-up // PA0 - Analog input, relay charge check via voltage divider PORTA = 0b11111110; // output level or pull-up if input (1=on) DDRA = 0b00000000; // direction (1=output) DIDR0 = 0b00000001; // turn off digital input buffer on PA0 (save power) // PB7 - Unused, configured as input with pull-up (also ISP sck) // PB6 - Unused, configured as input with pull-up (also ISP MISO) // PB5 - Unused, configured as input with pull-up (also ISP MOSI) // PB4 - Unused, configured as input with pull-up // PB3 - Unused, configured as input with pull-up // PB2 - Unused, configured as input with pull-up // PB1 - Unused, configured as input with pull-up // PB0 - Unused, configured as input with pull-up PORTB = 0b11111111; // output level or pull-up if input (1=on) DDRB = 0b00000000; // direction (1=output) // PC7 - Unused, configured as input with pull-up (maybe TOSC2 XTAL) // PC6 - Unused, configured as input with pull-up (maybe TOSC1 XTAL) // PC5 - Input, pushbutton "SW1", active low, external pull-up, no internal p-u // PC4 - Output, "LED1", active low // PC3 - Output, power relay pulse "ON" // PC2 - Output, power relay pulse "OFF" // PC1 - Unused, configured as input with pull-up // PC0 - Unused, configured as input with pull-up PORTC = 0b11010011; // output level or pull-up if input (1=on) DDRC = 0b00011100; // direction (1=output) // PD7 - Output, OC2A squarewave output for +24V charge pump // PD6 - Output, auxiliary relay pulse "ON" // PD5 - Output, auxiliary relay pulse "OFF" // PD4 - Input, MBUS power fail, /PF from TSS721A, active low, no internal p-u // PD3 - Output, USART1/TXD1 to MBUS // PD2 - Input, USART1/RXD1 from MBUS, no internal p-u // PD1 - Output, USART0/TXD0 to IEC61107 meter // PD0 - Input, USART0/RXD0 from IEC61107 meter, no internal p-u PORTD = 0b00001010; // output level or pull-up if input (1=on) DDRD = 0b11101010; // direction (1=output) // Select watchdog timeout period WDR (); // reset watchdog MCUSR &= ~(1 << WDRF); // clear WDRF (this is perhaps unnecessary...) WDTCSR = 0b00011000; // WDCE = WDE = 1, now WDE+WDPx must be written within 4 Tcy WDTCSR = 0b00001110; // WDE = 1, set 1s timeout // Disable unused modules (that are ON after reset...) ACSR = (1 << ACD); // disable analog comparator // Turn off clock to unused modules // Note1: The ADC clock is turned on/off by the ADC function! // Note2: The TIMER2 clock is turned on/off by the charge pump functions! PRR0 = 0b11001101; // shut down TWI, TIMER2, TIMER1, SPI, ADC // Select system clock frequency CLKPR = 0x80; // "unlock" - now CLKPSx must be written within 4 Tcy CLKPR = 0x02; // change from XTAL/8 to XTAL/4 = 921.6 kHz //##################### for (;;) { for (w = 0; w < 10000; w++) WDR (); PORTC &= ~0b00010000; // blink the LED for (w = 0; w < 10000; w++) WDR (); PORTC |= 0b00010000; } // Set up Timer0 + OC0A to generate a 100Hz tick interrupt // vInit100HzTick (); // SEI (); // set the I bit (global interrupt enable) // vRunApp (); // here we go! } From j_baraclough at zetnet.co.uk Thu Jun 14 09:44:46 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Jun 14 09:55:01 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: <000501c7ae99$b9d5bbd0$0c01a8c0@cad> References: <000501c7ae99$b9d5bbd0$0c01a8c0@cad> Message-ID: It looks like the App Builder may be truncating the value for UBRR to 8-bits, which would always make UBRRxH be zero. Need to go and try some other processors and see what happens. All the best for now, John At 16:36 14/06/2007, you wrote: >Just had a look and yes the app builder says, > >UBRR = 832 > >But the app builder code produced shows > >UBRR = 64 > >The MSB is not right, the 9600 does not use the MSB so a value of 0x00 is ok. > >Have not tested it but just my thoughts. > >VBR, >Patrick > > >-----Original Message----- >From: icc-avr-bounces@imagecraft.com >[mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Handley >Sent: 14 June 2007 16:02 >To: icc-avr@imagecraft.com >Subject: [Icc-avr] Mega 128 Baud Rate funny > >Hi > >I have a working piece of code which fails when I try to run it at >1200 baud. Using the application builder I get the following (16MHz xtal) > > > UCSR0B = 0x00; //disable while setting baud rate > UCSR0A = 0x00; > UCSR0C = 0x06; > UBRR0L = 0x40; //set baud rate lo > UBRR0H = 0x00; //set baud rate hi > UCSR0B = 0x18; > >this fails to communicate with the PC at 1200 baud. > >If I change it to 9600 - > > UCSR0B = 0x00; //disable while setting baud rate > UCSR0A = 0x00; > UCSR0C = 0x06; > UBRR0L = 0x67; //set baud rate lo > UBRR0H = 0x00; //set baud rate hi > UCSR0B = 0x18; > >Then all works ok. > >Any ideas what might be wrong?? > >Kind regards > >Richard Handley >Spectra Displays Ltd >Tel: +44 (0) 1954 261 402 >Fax: +44 (0) 1954 261 403 >www.spectra-displays.co.uk > >This email is confidential and intended solely for the use of the >individual to whom it is addressed. Any views or opinions presented >are solely those of the author and do not necessarily represent >those of Spectra Displays Ltd. (Registered at 194 Station Road, >Willingham, Cambridge CB4 5HQ, UK. Reg No: 2428206). > >If you are not the intended recipient, be advised that you have >received this email in error and that any use, dissemination, >forwarding, printing, or copying of this email is strictly >prohibited. If you have received this email in error please notify >Spectra Displays by telephone on +44 (0) 1954 261402 or by fax on >+44 (0) 1954 261403 > > >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: >13/06/2007 12:50 > > >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: >13/06/2007 12:50 >_______________________________________________ >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/20070614/0268ca9e/attachment.html From jh.bodin at telia.com Thu Jun 14 10:04:13 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Thu Jun 14 10:14:22 2007 Subject: [Icc-avr] Re: Program doesn't start - problem solved... Message-ID: <4671750D.2080605@telia.com> Hi, the program started up OK when the watchdog was disabled... It also started OK if some big static varables were removed... I run a slow clock (460 kHz) just after reset and the default WDT timeout is only 16ms... I will now have a look into the start-up files to see if they are properly clearing the watchdog in the init' / clearing loops... Johan From j_baraclough at zetnet.co.uk Thu Jun 14 10:31:56 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Jun 14 10:42:12 2007 Subject: [Icc-avr] Program doesn't start In-Reply-To: <46717069.30906@telia.com> References: <46717069.30906@telia.com> Message-ID: Hi Johan, It sounds as though your first project has a compilation problem. Firstly compare the hex files from each project and see if they look to be a similar size. Secondly load each project into AVR Studio and look at the program memory window. You can tell a lot from those two simple tests. What do you see in the message pane when the first compilation runs? All the best for now, John At 17:44 14/06/2007, you wrote: >Hi, > >I am struggling with an atmega324p program that refuses to start. >Nothing happens at all and all pins seem to stay in input mode >(hi-z) after reset. Programming and verification works well and >the fuse/lock bits have been carefully checked. > >Just to see if the program comes alive after reset, I put an endless >loop in main() that is supposed to flash a LED. Between the entry >point of main and this LED flashing loop, there are only some basic >register init's (pin levels & directions etc.). No interrupts are >enabled at this point. > >And now the funny part: > >I created a new project with just a single source file containing >EXACTLY the same main() function - Guess what.. THIS PROGRAM WORKS! >The file is attached. > >BTW, the project options are set exactly the same for both programs. > >I desperately tried to trace the execution manually from the reset >vector to the LED flashing loop but I did not find any vectors in the >list files... > >Do I need a brain transplant or is there something wrong in the compiler? > >I have been scratching my head for hours, all day actually... > >Best Regards >Johan Bodin > > >// Desperate test.. > >#include // CPU dependent stuff >#include // SEI(), CLI(), WDR() etc. > >void main (void) >{ > unsigned short w; > > // cstartup init' just finshed and we're still running > // at Fclk = Fxtal/8 = 460.8 kHz. Let's party! Here we go: > > // Initialize port levels, directions and pull-ups > > // PA7 - Unused, configured as input with pull-up > // PA6 - Unused, configured as input with pull-up > // PA5 - Unused, configured as input with pull-up > // PA4 - Unused, configured as input with pull-up > // PA3 - "TARIF"!? configured as input with pull-up for now... > *#* *#* *#* *#* > // PA2 - Unused, configured as input with pull-up > // PA1 - Unused, configured as input with pull-up > // PA0 - Analog input, relay charge check via voltage divider > > PORTA = 0b11111110; // output level or pull-up if input (1=on) > DDRA = 0b00000000; // direction (1=output) > DIDR0 = 0b00000001; // turn off digital input buffer on PA0 > (save power) > > // PB7 - Unused, configured as input with pull-up (also ISP sck) > // PB6 - Unused, configured as input with pull-up (also ISP MISO) > // PB5 - Unused, configured as input with pull-up (also ISP MOSI) > // PB4 - Unused, configured as input with pull-up > // PB3 - Unused, configured as input with pull-up > // PB2 - Unused, configured as input with pull-up > // PB1 - Unused, configured as input with pull-up > // PB0 - Unused, configured as input with pull-up > > PORTB = 0b11111111; // output level or pull-up if input (1=on) > DDRB = 0b00000000; // direction (1=output) > > // PC7 - Unused, configured as input with pull-up (maybe TOSC2 XTAL) > // PC6 - Unused, configured as input with pull-up (maybe TOSC1 XTAL) > // PC5 - Input, pushbutton "SW1", active low, external pull-up, > no internal p-u > // PC4 - Output, "LED1", active low > // PC3 - Output, power relay pulse "ON" > // PC2 - Output, power relay pulse "OFF" > // PC1 - Unused, configured as input with pull-up > // PC0 - Unused, configured as input with pull-up > > PORTC = 0b11010011; // output level or pull-up if input (1=on) > DDRC = 0b00011100; // direction (1=output) > > // PD7 - Output, OC2A squarewave output for +24V charge pump > // PD6 - Output, auxiliary relay pulse "ON" > // PD5 - Output, auxiliary relay pulse "OFF" > // PD4 - Input, MBUS power fail, /PF from TSS721A, active low, no > internal p-u > // PD3 - Output, USART1/TXD1 to MBUS > // PD2 - Input, USART1/RXD1 from MBUS, no internal p-u > // PD1 - Output, USART0/TXD0 to IEC61107 meter > // PD0 - Input, USART0/RXD0 from IEC61107 meter, no internal p-u > > PORTD = 0b00001010; // output level or pull-up if input (1=on) > DDRD = 0b11101010; // direction (1=output) > > // Select watchdog timeout period > > WDR (); // reset watchdog > MCUSR &= ~(1 << WDRF); // clear WDRF (this is perhaps unnecessary...) > WDTCSR = 0b00011000; // WDCE = WDE = 1, now WDE+WDPx must be > written within 4 Tcy > WDTCSR = 0b00001110; // WDE = 1, set 1s timeout > > // Disable unused modules (that are ON after reset...) > > ACSR = (1 << ACD); // disable analog comparator > > // Turn off clock to unused modules > // Note1: The ADC clock is turned on/off by the ADC function! > // Note2: The TIMER2 clock is turned on/off by the charge pump functions! > > PRR0 = 0b11001101; // shut down TWI, TIMER2, TIMER1, SPI, ADC > > // Select system clock frequency > > CLKPR = 0x80; // "unlock" - now CLKPSx must be written > within 4 Tcy > CLKPR = 0x02; // change from XTAL/8 to XTAL/4 = 921.6 kHz > > //##################### > > for (;;) > { > for (w = 0; w < 10000; w++) > WDR (); > PORTC &= ~0b00010000; // blink the LED > for (w = 0; w < 10000; w++) > WDR (); > PORTC |= 0b00010000; > } > > // Set up Timer0 + OC0A to generate a 100Hz tick interrupt > >// vInit100HzTick (); > >// SEI (); // set the I bit (global interrupt enable) > >// vRunApp (); // here we go! >} > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr From j_baraclough at zetnet.co.uk Thu Jun 14 10:43:50 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Thu Jun 14 10:54:05 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: References: <000501c7ae99$b9d5bbd0$0c01a8c0@cad> Message-ID: It looks like a bug in the Application Builder. I've tried several different processors, clock rates & baud rates and UBRR0H always comes back as 0 although the correct value is displayed on the tab. Devices with two UARTs also have the problem with UBRR1H. All the best for now, John At 17:44 14/06/2007, you wrote: >It looks like the App Builder may be truncating the value for UBRR >to 8-bits, which would always make UBRRxH be zero. > >Need to go and try some other processors and see what happens. > >All the best for now, >John > > >At 16:36 14/06/2007, you wrote: >>Just had a look and yes the app builder says, >> >>UBRR = 832 >> >>But the app builder code produced shows >> >>UBRR = 64 >> >>The MSB is not right, the 9600 does not use the MSB so a value of 0x00 is ok. >> >>Have not tested it but just my thoughts. >> >>VBR, >>Patrick >> >> >>-----Original Message----- >>From: icc-avr-bounces@imagecraft.com [ >>mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Handley >>Sent: 14 June 2007 16:02 >>To: icc-avr@imagecraft.com >>Subject: [Icc-avr] Mega 128 Baud Rate funny >> >>Hi >> >>I have a working piece of code which fails when I try to run it at >>1200 baud. Using the application builder I get the following (16MHz xtal) >> >> >> UCSR0B = 0x00; //disable while setting baud rate >> UCSR0A = 0x00; >> UCSR0C = 0x06; >> UBRR0L = 0x40; //set baud rate lo >> UBRR0H = 0x00; //set baud rate hi >> UCSR0B = 0x18; >> >>this fails to communicate with the PC at 1200 baud. >> >>If I change it to 9600 - >> >> UCSR0B = 0x00; //disable while setting baud rate >> UCSR0A = 0x00; >> UCSR0C = 0x06; >> UBRR0L = 0x67; //set baud rate lo >> UBRR0H = 0x00; //set baud rate hi >> UCSR0B = 0x18; >> >>Then all works ok. >> >>Any ideas what might be wrong?? >> >>Kind regards >> >>Richard Handley >>Spectra Displays Ltd >>Tel: +44 (0) 1954 261 402 >>Fax: +44 (0) 1954 261 403 >>www.spectra-displays.co.uk >> >>This email is confidential and intended solely for the use of the >>individual to whom it is addressed. Any views or opinions >>presented are solely those of the author and do not necessarily >>represent those of Spectra Displays Ltd. (Registered at 194 >>Station Road, Willingham, Cambridge CB4 5HQ, UK. Reg No: 2428206). >> >>If you are not the intended recipient, be advised that you have >>received this email in error and that any use, dissemination, >>forwarding, printing, or copying of this email is strictly >>prohibited. If you have received this email in error please notify >>Spectra Displays by telephone on +44 (0) 1954 261402 or by fax on >>+44 (0) 1954 261403 >> >> >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: >>13/06/2007 12:50 >> >> >>No virus found in this outgoing message. >>Checked by AVG Free Edition. >>Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: >>13/06/2007 12:50 >>_______________________________________________ >>Icc-avr mailing list >>Icc-avr@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-avr >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070614/214716ca/attachment.html From paul.aa9gg at gmail.com Thu Jun 14 11:09:46 2007 From: paul.aa9gg at gmail.com (Paul Mateer) Date: Thu Jun 14 11:19:59 2007 Subject: [Icc-avr] Re: Program doesn't start - problem solved... In-Reply-To: <4671750D.2080605@telia.com> References: <4671750D.2080605@telia.com> Message-ID: <20f5efc40706141109t49eef346xecfca15a892437de@mail.gmail.com> One of the reasons I'll start a project with the WD disabled! On 6/14/07, Johan H. Bodin wrote: > > Hi, > > the program started up OK when the watchdog was disabled... > It also started OK if some big static varables were removed... > > I run a slow clock (460 kHz) just after reset and the default > WDT timeout is only 16ms... I will now have a look into the > start-up files to see if they are properly clearing the watchdog > in the init' / clearing loops... > > Johan > > _______________________________________________ > 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/20070614/e0bb7cec/attachment.html From RichardH at spectra-displays.co.uk Thu Jun 14 12:18:38 2007 From: RichardH at spectra-displays.co.uk (Richard Handley) Date: Thu Jun 14 12:29:00 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny Message-ID: Hi its the app builder! as Dave said, if you set UBRR0H = 0x03 then it works. Thanks for your help Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070614/e2b28c13/attachment.html From richard-lists at imagecraft.com Thu Jun 14 12:52:28 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jun 14 13:03:12 2007 Subject: [Icc-avr] Re: Program doesn't start - problem solved... In-Reply-To: <4671750D.2080605@telia.com> References: <4671750D.2080605@telia.com> Message-ID: <200706142003.l5EK3AVP011280@dragonsgate2.imagecraft.com> That's the problem. The startup clears the BSS area and if you have huge block of static vars, they take time to initialize. You can disable the watchdog in the startup file. At 10:04 AM 6/14/2007, Johan H. Bodin wrote: >Hi, > >the program started up OK when the watchdog was disabled... >It also started OK if some big static varables were removed... > >I run a slow clock (460 kHz) just after reset and the default >WDT timeout is only 16ms... I will now have a look into the >start-up files to see if they are properly clearing the watchdog >in the init' / clearing loops... > >Johan > >_______________________________________________ >Icc-avr mailing list >Icc-avr@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-avr // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From jh.bodin at telia.com Thu Jun 14 13:35:19 2007 From: jh.bodin at telia.com (Johan H. Bodin) Date: Thu Jun 14 13:45:29 2007 Subject: [Icc-avr] Program doesn't start In-Reply-To: References: <46717069.30906@telia.com> Message-ID: <4671A687.2010001@telia.com> Hi, John Baraclough wrote: > It sounds as though your first project has a compilation problem. The problem was that the watchdog became hungry already before the execution reached main()! :-) It works nicely now after putting "wdr" instructions in the zeroing/init loops in init.s and reassembling crtatmega.s... Paul Mateer, AA9GG wrote: > One of the reasons I'll start a project with the WD disabled! It wasn't *my* code that forgot to feed the dog! ;-) 73/BR Johan SM6LKM .-.-. From richard-lists at imagecraft.com Thu Jun 14 19:16:37 2007 From: richard-lists at imagecraft.com (Richard) Date: Thu Jun 14 19:27:25 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: References: <000501c7ae99$b9d5bbd0$0c01a8c0@cad> Message-ID: <200706150227.l5F2RNOY016102@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070614/b2be0e76/attachment.html From j_baraclough at zetnet.co.uk Fri Jun 15 09:01:15 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Fri Jun 15 09:11:34 2007 Subject: [Icc-avr] Mega 128 Baud Rate funny In-Reply-To: <200706150227.l5F2RNOY016102@dragonsgate2.imagecraft.com> References: <000501c7ae99$b9d5bbd0$0c01a8c0@cad> <200706150227.l5F2RNOY016102@dragonsgate2.imagecraft.com> Message-ID: Hi Richard, So far I've tried: M8, M16, M32, M128, M169, M323, M640, M2561, M8515, M8535, M48 & M88. All exhibit the same problem with UBRR0H (and UBRR1H where appropriate). It looks to be a pretty fundamental problem with truncation to 8-bits after the correct calculation is performed. HTH. All the best for now, John At 03:16 15/06/2007, you wrote: >Ooops. Thanks for the report. Offhand, which ones have you tested to >be broken? I will have the dev team fix them ASAP. > >At 10:43 AM 6/14/2007, John Baraclough wrote: >>It looks like a bug in the Application Builder. I've tried several >>different processors, clock rates & baud rates and UBRR0H always >>comes back as 0 although the correct value is displayed on the tab. >>Devices with two UARTs also have the problem with UBRR1H. >> >>All the best for now, >>John >> >> >>At 17:44 14/06/2007, you wrote: >>>It looks like the App Builder may be truncating the value for UBRR >>>to 8-bits, which would always make UBRRxH be zero. >>> >>>Need to go and try some other processors and see what happens. >>> >>>All the best for now, >>>John >>> >>> >>>At 16:36 14/06/2007, you wrote: >>>>Just had a look and yes the app builder says, >>>> >>>>UBRR = 832 >>>> >>>>But the app builder code produced shows >>>> >>>>UBRR = 64 >>>> >>>>The MSB is not right, the 9600 does not use the MSB so a value of >>>>0x00 is ok. >>>> >>>>Have not tested it but just my thoughts. >>>> >>>>VBR, >>>>Patrick >>>> >>>> >>>>-----Original Message----- >>>>From: icc-avr-bounces@imagecraft.com [ >>>>mailto:icc-avr-bounces@imagecraft.com] On Behalf Of Richard Handley >>>>Sent: 14 June 2007 16:02 >>>>To: icc-avr@imagecraft.com >>>>Subject: [Icc-avr] Mega 128 Baud Rate funny >>>> >>>>Hi >>>> >>>>I have a working piece of code which fails when I try to run it >>>>at 1200 baud. Using the application builder I get the following (16MHz xtal) >>>> >>>> >>>> UCSR0B = 0x00; //disable while setting baud rate >>>> UCSR0A = 0x00; >>>> UCSR0C = 0x06; >>>> UBRR0L = 0x40; //set baud rate lo >>>> UBRR0H = 0x00; //set baud rate hi >>>> UCSR0B = 0x18; >>>> >>>>this fails to communicate with the PC at 1200 baud. >>>> >>>>If I change it to 9600 - >>>> >>>> UCSR0B = 0x00; //disable while setting baud rate >>>> UCSR0A = 0x00; >>>> UCSR0C = 0x06; >>>> UBRR0L = 0x67; //set baud rate lo >>>> UBRR0H = 0x00; //set baud rate hi >>>> UCSR0B = 0x18; >>>> >>>>Then all works ok. >>>> >>>>Any ideas what might be wrong?? >>>> >>>>Kind regards >>>> >>>>Richard Handley > >// richard (This email is for mailing lists. To reach me directly, >please use richard at imagecraft.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/20070615/70ac0c65/attachment.html From BobGardner at aol.com Sat Jun 16 09:35:35 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sat Jun 16 09:46:39 2007 Subject: [Icc-avr] width of download panel doesnt stick? Message-ID: The gray panel with the 'download' box in the terminal window.... didn't that width of that used to save in a recent version? using 7.13a Anyone else confirm this behavior? ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070616/c72fbb6d/attachment.html From BobGardner at aol.com Sat Jun 16 16:11:59 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sat Jun 16 16:22:20 2007 Subject: [Icc-avr] ldiv workaround? Message-ID: Trying to compile something that uses ldiv... any workaround for this other than downloading GCC? I guess this is a part of c99? ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070616/c9071d63/attachment.html From richard-lists at imagecraft.com Sat Jun 16 16:54:18 2007 From: richard-lists at imagecraft.com (Richard) Date: Sat Jun 16 17:05:09 2007 Subject: [Icc-avr] ldiv workaround? In-Reply-To: References: Message-ID: <200706170005.l5H057lo043922@dragonsgate2.imagecraft.com> An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070616/93644eed/attachment.html From BobGardner at aol.com Sun Jun 17 07:50:41 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sun Jun 17 08:02:42 2007 Subject: [Icc-avr] terminal window? Message-ID: I asked this question a couple days ago, but no one responded. I hope I'm not the only person on the mail list using 7.13a? Will SOMEONE try to size the download panel in the terminal window right a little bit and see if it remembers the size? Did this used to work just fine or am I having a hallucination or a flashback or just going crazy!?! ************************************** See what's free at http://www.aol.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dragonsgate.net/pipermail/icc-avr/attachments/20070617/376902a1/attachment.html From j_baraclough at zetnet.co.uk Sun Jun 17 12:10:54 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sun Jun 17 12:21:12 2007 Subject: [Icc-avr] terminal window? In-Reply-To: References: Message-ID: It's certainly a fixed size in my 7.13A. I've never tried to resize it before so I don't know what happened in earlier versions. All the best for now, John At 15:50 17/06/2007, you wrote: >I asked this question a couple days ago, but no one responded. I >hope I'm not the only person on the mail list using 7.13a? Will >SOMEONE try to size the download panel in the terminal window right >a little bit and see if it remembers the size? Did this used to work >just fine or am I having a hallucination or a flashback or just going crazy!?! > > > > >---------- >See what's free at AOL.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/20070617/efa74936/attachment.html From BobGardner at aol.com Sun Jun 17 12:27:23 2007 From: BobGardner at aol.com (BobGardner@aol.com) Date: Sun Jun 17 12:38:39 2007 Subject: [Icc-avr] terminal window? Message-ID: Just to be absolutely clear John... I mean grab th