E/X-Mag Microcontroller Programming (Atmel AT90S2313)

**LorneCash** · 10-19-2005, 10:41 PM

I understand there is not a real time clock and that i will have to set up timers based on the clock speed. How do i go about doing that? Is there an internal counter of the number of clock cycles since power on, or do i have to incrament a register and do it all myself or what? Since i know i will need many timers is there a way to set up at least part of it as a function or subroutine or will i have to repete the code for every timer i need.

**BigEvil** · 10-20-2005, 08:14 AM

Good work. Ihave always been interested in this. Keep us posted on the progress.

Oh, another thing I was wondering, is it possible to download the code off of the controller board and look at it?

**LorneCash** · 10-20-2005, 09:29 AM

Originally posted by BigEvil

Good work. Ihave always been interested in this. Keep us posted on the progress.

Oh, another thing I was wondering, is it possible to download the code off of the controller board and look at it?

Yes, Kinda... you can download the code from one gun and copy it to another or reload it on that gun later and you can look at the code but the AVR Studio compiles it to a hex file. You can load this hex file back into the Studio and it will translate it back to assembly language but it's not really too helpful because about Even though its back to assembly there are no comments and about 25% of the stuff you do in the Studio is a function and generates assembly code that you never wrote and won't need to. Maybe it would be more useful to a more advenced programmer but I really couldn't make much of it.

**bit-wizard** · 10-20-2005, 11:19 AM

Timing on the AVR

You were asking about timing ... the AVR has 8 and 16 bit timers (depending on the variant) that can be configured to time at different rates, based on the oscillator. Depending on how the prescalers are configured, you can choose the rate that it "counts" at. I've written quite a bit of code for the AVR series micro (Tiny15, 4433, Mega8, Mega16, Mega32), and could get you started on some of the low-level routines to configure the peripherals if you like.

bit-wizard

**LorneCash** · 10-20-2005, 12:25 PM

ACE Functionality

Can someone please explain to me how to check the ACE for a signal? I tried checking it the same way i checked the Trigger (HES) but it didn't give me a signal... Do i need to send power to it somehow first and then check it?

**BigEvil** · 10-21-2005, 07:26 AM

Originally posted by LorneCash

Can someone please explain to me how to check the ACE for a signal? I tried checking it the same way i checked the Trigger (HES) but it didn't give me a signal... Do i need to send power to it somehow first and then check it?

Im pretty sure the ACE is always powered when the marker is on. I know from pics where you can see the IR light comming from the emmitter that it was 'on' eventhough the ACE was set to 0.

There should be 2 wires going to the ace board that are used: one is a +5v and the other is SIG. The board, like the rest of the gun, uses the frame as a ground, (probably the screw that hold the ACE in.)

As far as checking it for a signal, I am guessing that you would have to have the ACE set to 1 and then cover the eye sensor. Im not sure, but I would be that the SIG wire would be where you need to check. However, I am not sure of the value that you would be looking for. I dont know if its a +5v or much smaller. Remember, I am only guessing

**athomas** · 10-21-2005, 10:11 AM

Since the Atmel works with a 5v supply on the board, I would assume a 0 to 5v signal from the ACE to indicate an on or off condition.

**Miscue** · 10-21-2005, 08:52 PM

Originally posted by LorneCash

Can someone please explain to me how to check the ACE for a signal? I tried checking it the same way i checked the Trigger (HES) but it didn't give me a signal... Do i need to send power to it somehow first and then check it?

No... it's always on. Should be pretty straight forward to get input from the ACE.

**Miscue** · 10-21-2005, 09:01 PM

Originally posted by BigEvil

Good work. Ihave always been interested in this. Keep us posted on the progress.

Oh, another thing I was wondering, is it possible to download the code off of the controller board and look at it?

If the chip was locked, no (assuming there isn't a hack). Otherwise yes...

I think it's easier to look at what the program does on the simulator than to figure out what it's doing by looking at the assembly. Although... yeah, you can figure out exactly how it works by examining the hex file. I don't know why you would want to go through that trouble though.

**Miscue** · 10-21-2005, 09:05 PM

PB1 - ??? (warp feed maybe)

This is the low voltage line. There is no dedicated pin going from the microcontroller to the warp feed specifically. The Intellifeed port shares the same line as the output line going to the solenoid.

One of the things you'll want to do is: Prime the loader if the ACE does not detect a ball... kinda makes sense... no ball = try to feed a ball! To do this, it's the same as firing the marker... but you only send a signal to the solenoid line for a short duration... just enough for your loader to pick it up... but not nearly enough to fire the marker.

This line sharing also infers that you can fire the marker via the Intellifeed cable. Also... if your loader has a problem... it can fire your marker. It is very possible to locate a cheater board in your loader.

Cable a bunch of EMags together through the Intellifeed port... fire one marker and they all shoot in unison!

**Miscue** · 10-21-2005, 09:25 PM

Originally posted by LorneCash

I understand there is not a real time clock and that i will have to set up timers based on the clock speed. How do i go about doing that? Is there an internal counter of the number of clock cycles since power on, or do i have to incrament a register and do it all myself or what? Since i know i will need many timers is there a way to set up at least part of it as a function or subroutine or will i have to repete the code for every timer i need.

Total number of clock cycles since power on? Not that I know of.

Yeah... you can write a subroutine for the timer stuff. When the built-in timer rolls over... it results in an interrupt... have it go to a subroutine then.

**Miscue** · 10-21-2005, 09:40 PM

Starts off kinda like this to do your timer interrupt routine.

.CSEG ; Start Code Segment
.ORG 0 ; Set Program Counter to 0
rjmp RESET ; Reset Handler
.ORG OVF0addr
rjmp timerInt

timerInt:
push r16
in r16,SREG
etc. etc.

Low Battery...

sbis PINB, 1
rjmp lowBatt

ACE...

sbis PINB, 6
rjmp resetACE2

**Miscue** · 10-21-2005, 10:11 PM

Originally posted by LorneCash

Port B
PB7 - N/C
PB6 - ACE
PB5 - N/C
PB4 - Display RS
PB3 - Display DATA IN
PB2 - Display CLOCK
PB1 - ??? (warp feed maybe)
PB0 - N/C

Port D
PD7 - N/C
PD6 - Display CE
PD5 - Bottom Button
PD4 - Top Button
PD3 - Solenoid
PD2 - Trigger (HES)
PD1 - N/C
PD0 - N/C

Can someone double check these? I haven't gotten far enough in the code to use all of them yet and it would be extreemly frustrating if i had this part wrong. Send Me a PM and i'll edit my post so as not to confuse anyone who reads this later.

Those are correct... PB1 = Low Voltage signal like I mentioned.

**Miscue** · 10-21-2005, 10:32 PM

Something I wrote in '03... if it gives you any ideas on how you might want to do your timer scheme.

My shot buffering and timing scheme is completely different. What I have now is a leaky bucket approach. I have a bunch of timers that are independent of each other, instead of one clock timer. These timers are at all times counting down to 0, decremented after an interrupt. These timers are filled up to appropriate values when the trigger is pulled. About a dozen instructions control all of these timers, which greatly simplifies things.

If like timer A is not 0 (the bucket hasn't leaked out completely yet), event A cannot happen yet... it just skips that part.

So like, I'd have timers A, B, C:

If A timer = 0
turn off solenoid (event A)
if B timer = 0
can look at trigger for new shot(event B)
if C timer = 0
shoot ball if buffered (event C)

Stuff like that. These events can me mixed up, it doesn't matter what order they are in really. Before, stuff had to happen sequentially... and basing everything off of one timer had it's problems - made coding larger, clumsy, and more difficult.

Also, there is now no distinction between a buffered shot and a non-buffered shot... everything is a 'buffered' shot I suppose - and my code checks the trigger only once (rather than multiple times like in Q1.1), regardless of what stage of the cycle it is in. The rule is: A shot can be buffered when the debounce timer has expired. If this is your first shot, then it's already at 0. If during a cycle, you can buffer a shot after the debounce timer expires. Now, this shot cannot be fired until the ROF timer is at 0. For your first shot, it is already 0. Otherwise it must wait for the ROF timer to expire.

This probably doesn't make sense... I'd have to use diagrams to explain it better.

E/X-Mag Microcontroller Programming (Atmel AT90S2313)

E/X-Mag Microcontroller Programming (Atmel AT90S2313)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment