Previous in Forum: Primavera Sofware   Next in Forum: Wireless
Close
Close
Close
Rate Comments: Nested
Active Contributor

Join Date: May 2008
Posts: 12

data acquisition using atmega32

04/17/2009 2:25 PM

im working on a project of data acquisition:

the task is as follows:

there is a 50Hz clk with 10.5%duty cycle. after the on time of this pulse the data packet comprising of 50 bytes including start, stop, chksum, and 2 iniaillizing bytes is to be transferred. each bit of these 50 bytes is sent on a 128khz pulse. the valid data from byte 3 to 47 is to be transmitted to the spi port. each 50hz signal will transmit only single packet comprising of 50 bytes as mentioned above.

i developed the required code using c language. i utilized timer0 and timer1 to generate 50hz signal. i used two timers because after the on time the data is to be transferred in the off time. the 128khz signal is interpreted as an interrupt. timer0 and timer1 are also operating on interrupt basis. at timer0 overfolw, the 128khz signal interrupt and timer1 interrupt is activated and timer0 interrupt is deactivated.

in timer1 interrupt, the timer0 interrupt is activated while timer1 interrupt is deactivated.

during 128khz interrupt, the 50 bytes are received on a port pin(bit by bit on each rising edge of 128khz signal) and sent to the spi port.

ive utilized avr studio4 with winavr to develop the code.

the issue is that the code is running well in the simulator, but not in proteus and in real hardware.

can anyone indicate the possible problems and any error in building code logic.

share your suggestions and better solutions as well.

thanks

Register to Reply
Interested in this topic? By joining CR4 you can "subscribe" to
this discussion and receive notification when new comments are added.
Commentator

Join Date: Jul 2008
Location: LA, CA
Posts: 97
#1

Re: data acquisition using atmega32

04/19/2009 6:07 PM

Well, considering everything... Is this for school? lol

Anyway, timing is of utmost importance; therefore - code optimization is necessary to ensure that the system will work. This means checking and probably counting each clock tick that each instruction takes. I know - I had a similar problem in college :) But with this controller, I couldn't find the actual timing diagrams as "they" use to have in The Good Ole Days... Timing may become problematic when you start having a bunch of interrupts or some other instructions that take a lot of clock ticks. Another thing is that with these kinds of problems - you really need to 'detect the real world' and not use timers as your 'starting point' because they probably do not coincide with the real world. Just cause you have timers in the controller running at the right times, doesn't mean that they're corresponding with the 'real world.' You'll need to have some logic and inputs to the controller to 'know' when the 'real' falling edge is and have that as your 'initial starting point' for the 'main' code. You can have the timers give you an indication of when the approximate on/off times are, but not much beyond that because in some 'cycles' of that 50Hz - that's in the real world - you may find that it's actually shorter(faster) than you've accounted for... Or that it maybe longer than your accounting for... When it does happen and yes it will happen, the system will fail if 'everything' is set "properly."

Well, for one thing... Does the prototype work at all? Maybe at start up it does? Then completely fails? That would indicate a 'timing problem' with the code and the real world.

__________________
Bla - de - bla - de - BLA!!! "That's Me!!!"
Register to Reply
Register to Reply

Previous in Forum: Primavera Sofware   Next in Forum: Wireless
You might be interested in: Bar Code Scanners, Bar Code Cards, Bar Code Software

Advertisement