Yahoo Groups archive
Messages
Page 106 of 307 · 15341 messages matched
2007-10-11 by Graham Davies
--- In AVR-Chat@yahoogroups.com, "kernels_nz" wrote: > Wow, I see to be generating a bit of interest ... Although I share Roy's distaste for allowing the wrong skill set to control a design approach, I can see reasons why what Hein describes could be optimum. I think we're lookin
2007-10-10 by Manuel Gonzalez
Would you provide us with that routine? I'm very interested! Thanks, Manuel Gonzalez > Hi Graham, > > Yeah, im thinking that thats probably the best way to go, I wasnt so > much worried about speed as that I dont yet have a lot of faith in the > compiler dealing with floating poi
2007-10-10 by larry barello
You can use fixed point math. For example, treat a 32 bit number as 24.8 bits. You can work through the math to get the rules: add and subtract numbers. Right shift 8 when you want the results. Fixed point routines can be faster than floating point, but the real gain is in potent
2007-10-10 by Roy E. Burrage
It appears that most of the scale circuits you've seen are the result of some digital guy messing around in my world...analog. Do it your way. It's unfortunate that specsmanship is becoming the norm rather than the exception any more, and an understanding of both conversion techn
2007-10-10 by Russell Shaw
kernels_nz wrote: > Hi Rob, > > Wow, I see to be generating a bit of interest with what I viewed as a > pretty simple problem. Firstly, in practice, every trade-approved > weigh-scale that ive seen so far has used at least a 24-bit A2D > converter. The load-cells are completely p
2007-10-10 by kernels_nz
Hi Rob, Wow, I see to be generating a bit of interest with what I viewed as a pretty simple problem. Firstly, in practice, every trade-approved weigh-scale that ive seen so far has used at least a 24-bit A2D converter. The load-cells are completely passive, they are merely a whea
2007-10-10 by Roy E. Burrage
We do a little bit with measurement here, Hein. www.measuretech-tn.com My experience has been that a scale, most mechanical measuring devices for that matter, aren't very accurate below 10% to 20% of their full scale range. A set of ANSI Class 1 calibration weights is only accura
2007-10-10 by dlc
However, if you parallel the outputs you should be safe. The Atmel parts are CMOS outputs, not bipolar so they have a negative temp. coefficient. To be the most repeatable I would sink the current and not source it. DLC David VanHorn wrote: > Trigger the int, and in the int, set
2007-10-10 by dlc
You wouldn't use PWM to do that, you'd simply use the timer to fire the ISR at the resolution you want. For instance, if you want a 1KHz PWM and you want an 8 bit resolution then you'd need to set your timer to interrupt every (1ms/256). Turn the LED on at the beginning of the cy
2007-10-10 by David VanHorn
Trigger the int, and in the int, set and clear the bits you want. But know this: The output current you'll get is quite variable chip to chip, and batch to batch. Those limits on current in the data sheet are not guaranteeing any sort of regulation, they are "do not exceed" numbe
2007-10-10 by Thomas Keller
Oh. come on. Unless you're using an AVR that hasn't got sufficient resources, doing fractional math is no problem. Any of the available C compilers will do a fine job of floating point, or fixed point math for you. Indeed, I saw some assembly language fixed point7.8 mat routines
2007-10-10 by Thomas Keller
OK, one guy wrote back and said it wasn't possible, but I don't think that's correct, because the PWM can also trigger interrupts. Again: I need to drive more than 20 mA to an LED being PWMed by an ATtiny25. I want to use the PWM module on timer/counter0 to drive an interrupt rou
2007-10-10 by kernels_nz
Hi Tom, Im still having nightmares from my uni days when I tried to do some 32-bit multiplication and division on a AVR with the Codevision compiler and completely gave up on it. Since then I have always tried my best to avoid floating point and "long int" math on the AVR, but I
2007-10-09 by kernels_nz
Hi Graham, Yeah, im thinking that thats probably the best way to go, I wasnt so much worried about speed as that I dont yet have a lot of faith in the compiler dealing with floating point numbers on the 8-bit processor. I did get an excellent reply on the Atmel ARM forum from a g
2007-10-09 by Graham Davies
--- In AVR-Chat@yahoogroups.com, "kernels_nz" wrote: > > ... low sample rates (10 s/s) ... > ... the bit thats got me a bit > worried is migrating the code > from the existing 32-bit processor > to a baby AVR. At such a low sample rate, why not stick with the floating point? Or,
2007-10-09 by kernels_nz
Hi Roy, generally you don't need a particularly accurate reference, just one that doesn't vary with time and environmental factors. All measurement is done relative to a "calibrated test weight", so scales are calibrated and do not rely on the accuracy of the reference. In practi
2007-10-09 by Roy E. Burrage
Is it 24 bit accuracy or 24 bit resolution? At 24 bits, 1 part in almost 17 million...where do we get a reference that accurate with a reasonable cost suitable for a weigh scale product? I suspect 12 bit accuracy would be plenty accurate for your application and you wouldn't have
2007-10-09 by kernels_nz
Hi there, this one is out of left field a bit (Baseball phrase ???) but im working on a weigh-scale project that uses a 24-bit ADC and I was just wondering whether anyone had ever written a weigh-scale module for a 8-bit micro controller. Im just interested to see how all the cal
2007-10-06 by David Kelly
On Oct 5, 2007, at 7:05 PM, Thomas Keller wrote: > > I don't know why, I thought I understood it, but I am having > difficulty > determining the correct control register bits to set to obtain the > phase > correct PWM mode I wish to operate in. > > I want to have an interrupt han
2007-10-06 by Thomas Keller
I don't know why, I thought I understood it, but I am having difficulty determining the correct control register bits to set to obtain the phase correct PWM mode I wish to operate in. I want to have an interrupt handler set or clear a pair of GPIOs based on the status of the PWM
2007-10-04 by Richard Cooke
John, I can't use HVPP since my board is using a SMT part. Maybe I should build up a board with a dip version while I'm developing the code and when I get it where I want it I can then program the surface mount part. Richard Cooke Lake Forest, CA USA --- In AVR-Chat@yahoogroups.c
2007-10-04 by Thomas Keller
John Samperi wrote: > > At 09:19 AM 4/10/2007, you wrote: > >OK, here is the code that si reading the EEPROM: (sans comments): > > > >RETRY: > > > > sbic EECR, EEPE > > rjmp RETRY > > > > out EEARL, POINTER > > in BUFFER, EEDR > > hmmmmmmmmmmmmmmmmmmmm that looks NOTHING like wha
2007-10-04 by enkitec@gmail.com
On 3 Oct 2007 at 18:19, Thomas Keller wrote: > OK, here is the code that si reading the EEPROM: (sans comments): > > RETRY: > > sbic EECR, EEPE > rjmp RETRY > > out EEARL, POINTER > in BUFFER, EEDR > > > tom > Is your uP the ATMEGA48? What is the EEARH value? Mark Jordan
2007-10-04 by Bruce Parham
Thomas Keller wrote: > OK, here is the code that si reading the EEPROM: (sans comments): > > RETRY: > > sbic EECR, EEPE > rjmp RETRY > > out EEARL, POINTER in BUFFER, EEDR > > > tom >
2007-10-04 by John Samperi
At 09:19 AM 4/10/2007, you wrote: >OK, here is the code that si reading the EEPROM: (sans comments): > >RETRY: > > sbic EECR, EEPE > rjmp RETRY > > out EEARL, POINTER > in BUFFER, EEDR hmmmmmmmmmmmmmmmmmmmm that looks NOTHING like what the data sheet shows, even with comments. Re
2007-10-03 by Thomas Keller
OK, here is the code that si reading the EEPROM: (sans comments): RETRY: sbic EECR, EEPE rjmp RETRY out EEARL, POINTER in BUFFER, EEDR tom
2007-10-03 by Thomas Keller
Bruce Parham wrote: > > > > > > Yes, I have used the up/.download memory feature. > > > > I tested that by downloading it into the simulator, then > > saving it to a differently named file, and manually > > scanning that file to determine if the correcct data > > were present. Th
2007-10-03 by John Samperi
At 04:38 AM 4/10/2007, you wrote: >I've replaced the chip and now I'm back to work. Is it a DIP package? Can you plug it in for HVPP to investigate the problem? Try an external clock as suggested also. The only time I have had a chip die in a similar fashion was by using code gen
2007-10-03 by Tim Gilbert
When I've had similar things happen it has usually turned out to be the CKSEL fuses. I've had situations where the fuses where clears to "0000"; I connected an external clock and was able to reset them. Regards, Tim Gilbert JEM Innovation Inc. 303-926-9053 (office) 303-437-4342 (
2007-10-03 by Bruce Parham
> > Yes, I have used the up/.download memory feature. > > I tested that by downloading it into the simulator, then > saving it to a differently named file, and manually > scanning that file to determine if the correcct data > were present. They were > > I am reading the EEPROM pe
2007-10-03 by Richard Cooke
Hi John, I haven't come close to 10,000 times. I'm using the Dragon to program the 48V chip. I've replaced the chip and now I'm back to work. I would like to know what happened so if was something I did I can avoid it in the future. Richard Cooke Lake Forest, CA USE --- In AVR-Ch
2007-10-03 by Thomas Keller
David VanHorn wrote: > > > > > I am reading the EEPROM per the sample code in that data > > sheet. I know this is working correctly because I can watch the > > associated registers in the IO view, and see that the address > > \register for the EEPROM is taking on correct values,
2007-10-03 by Tim Mitchell
Richard Cooke wrote: > Hi Folks, > > I'm working with the ATMEGA48V and I've been happily working with my > prototype board for a month now and all of a sudden I'm getting the > following error message when I try and program the chip: > > WARNING: FLASH byte address 0x0000 is 0x0
2007-10-03 by John Samperi
At 01:26 PM 3/10/2007, you wrote: > I am reading the EEPROM per the sample code in that data >sheet. Just remember that the last 2 steps?? need to be performed within 4 cycles IIRC. So if you are dodling with the simulator it may not work. May be better to run the whole routine a
2007-10-03 by David VanHorn
> > I am reading the EEPROM per the sample code in that data > sheet. I know this is working correctly because I can watch the > associated registers in the IO view, and see that the address > \register for the EEPROM is taking on correct values, but no data is > appearing in the
2007-10-03 by Thomas Keller
John Samperi wrote: > > At 11:46 AM 3/10/2007, you wrote: > > >Am I running into yet another > >problem with AVRStudio, or am I missing some other subtle point? > > Have downloaded the data into EEPROM by upload/download memory? > > >> HOW Yes, I have used the up/.download memory
2007-10-03 by John Samperi
At 11:46 AM 3/10/2007, you wrote: >Am I running into yet another >problem with AVRStudio, or am I missing some other subtle point? Have downloaded the data into EEPROM by upload/download memory? >> HOW
2007-10-03 by Thomas Keller
I jus went through the AVRStudio help files. I find nothing in there stating that there are known problem,s reading data from the EEPROM in simulation. ***ARGH*** I suspect Atmel is trying to sabotage my development project *hahahha* tom
2007-10-03 by Thomas Keller
Additional information: watching the EEPROM in the IO view, I can see that the address in the low byte address register is incrementing and decrementing as it should, per my code. The problem is that no data is being read from those locations in the EEPROM, despite there being da
2007-10-03 by Thomas Keller
OK, I'm confused. I am starting debug, and then loading the data from the .eep file created by the assembler. To be certain it was loading the EEPROM data, I saved the data back out to another file and manually confirmed that the data in the file represents the data in my EEPROM
2007-10-03 by John Samperi
At 03:33 AM 3/10/2007, you wrote: >Does this mean the chip is no good? Have you programmed the chip more than 10,000 times already? What are you using to program the chip? Regards John Samperi ******************************************************** Ampertronics Pty. Ltd. 11 Brok
2007-10-02 by John Samperi
At 08:10 AM 3/10/2007, you wrote: > When assembling with AVRASM32, you can write: > > ldi r16, byte1(256040); = 0x28 > ldi r17, byte2(256040); = 0xE8 > ldi r18, byte3(256040); = 0x03 hmmm interesting, so how many registers can you fill that way? I guess at least 4 for 32 bits. Pe
2007-10-02 by Thomas Keller
John: ****DOH**** what the hell was I thinking? Of ***COURSE*** they're 8 bits! I've been spending too much time looking at AVR32 and MSC430 literature *heh* I need to build a timing looop to test my firmware concepts for a new product, and I have to build the timing loop manuall
2007-10-02 by enkitec@gmail.com
When assembling with AVRASM32, you can write: ldi r16, byte1(256040); = 0x28 ldi r17, byte2(256040); = 0xE8 ldi r18, byte3(256040); = 0x03 Mark Jordan On 3 Oct 2007 at 8:00, John Samperi wrote: > At 07:52 AM 3/10/2007, you wrote: > >R25 is a 32 bit register, > > Since when? All r
2007-10-02 by David VanHorn
On 10/2/07, Thomas Keller wrote: > > Why would the following instruciton yield an "parameter out of range" > error in AVR-ASM? > > ldi R25, 256040 R25 is an 8 bit register! (as are ALL the registers..) You need to load this in bytes. A 16 bit value can be loaded like this: ldi R1
2007-10-02 by John Samperi
At 07:52 AM 3/10/2007, you wrote: >R25 is a 32 bit register, Since when? All registers are 8 bits. You need to load R25 and then R26 with 8 bits. Anyway 256040 is larger than 16 bits. Regards John Samperi ******************************************************** Ampertronics Pty.
2007-10-02 by Thomas Keller
Why would the following instruciton yield an "parameter out of range" error in AVR-ASM? ldi R25, 256040 R25 is a 32 bit register, that should be a completely acceptable instruction as I understand the instruction set manual. any thoughts? tom
2007-10-02 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, enkitec@... wrote: >But I don't think there's any mechanism to directly >deal with a 32 bit value in the assembler. Using the gnu assembler for 8-bit AVRs, 32-bit values are manipulated using hhi8 and hlo8 along with the better known hi8 and lo8 o
2007-10-02 by Don Kinzer
--- In AVR-Chat@yahoogroups.com, "Richard Cooke" wrote: > Does this mean the chip is no good? Is there a work-around? Possibly. If it were a higher address I would say almost certainly so. The fact that it is address 0 might indicate some other problem, e.g. the power supply. > O
2007-10-02 by Richard Cooke
Hi Folks, I'm working with the ATMEGA48V and I've been happily working with my prototype board for a month now and all of a sudden I'm getting the following error message when I try and program the chip: WARNING: FLASH byte address 0x0000 is 0x00 (should be 0x1E).. FAILED! Does t