Page 2 of 25 FirstFirst 12345612 ... LastLast
Results 31 to 60 of 736

Thread: E/X-Mag Microcontroller Programming (Atmel AT90S2313)

  1. #31
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365
    Quote Originally Posted by bit-wizard
    Definitely use the hardware timers. Cycle counting is possible, but accuracy depends on several factors. First, most AVR instructions are single cycle, but NOT ALL instructions. Jumps, for instance, can take more than 1 cycle. Second, if you are using interrupts, they would throw off your cycle-count based timing because they can occur unpredictably.

    Configuring the timers can be a bit of a pain initially, but it is well worth it in terms of the accuracy and flexibility that it allows. They make it much easier to change your code and functionality without having to count cycles by hand to make sure that you have just blown your timing by adding a few more instructions. In my experience, the overall project will be made much simpler in the long run if you use the hardware timers.


    bit-wizard

    I thought i read somewhere that this chip doesn't have true interrupts.

    The other thing is that the hardware timers only have certain resolutions built in(1,8,64,256,1024) . Maybe i just need some help understanding them, but if i want a timer that is exactly 30ms for the solenoid I can't use 8 because 8x4=32 now i think that is in cycles so that's actually is 4ms but either way how would i get it to branch when a value in milliseconds is hit how do i do the calculation with the timer and do i have to take into consideration the time (lines of code) between when the timer actually ends to when it is detected and when the next operation is starting?

    I hope that made sense it's still a bit fuzzy to me.

  2. #32
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by LorneCash
    I thought i read somewhere that this chip doesn't have true interrupts.

    The other thing is that the hardware timers only have certain resolutions built in(1,8,64,256,1024) . Maybe i just need some help understanding them, but if i want a timer that is exactly 30ms for the solenoid I can't use 8 because 8x4=32 now i think that is in cycles so that's actually is 4ms but either way how would i get it to branch when a value in milliseconds is hit how do i do the calculation with the timer and do i have to take into consideration the time (lines of code) between when the timer actually ends to when it is detected and when the next operation is starting?

    I hope that made sense it's still a bit fuzzy to me.
    Urm.... this isn't as complicated as you are making it out to be... just think about it a bit and figure out a way to do it.

  3. #33
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by LorneCash
    OK midterms are over time to get back into this...

    I have been looking at the timer stuff again and was reading in the AT90S2313 User Guide about Timer/Counters. Because of the nature of the timers needed for this project (30ms) I thought it would be easier to just execute a loop for a certain number of cycles based on the frequency of the chip. If i remember correctly the chip is a 4MHz chip so 4 instructions should equal 1ms.

    Is this the best way to go about this or should i try to use the Counters?
    4 instructions = 1ms? 4,000,000 (cycles/second) / 1,000 (ms/second) = 4,000 (cycles/ms).

    Like bit-wizard mentioned... one instruction does not necessarily take 1 clock cycle. It can be done without the timers... but you can also run around with scissors and laces untied.

  4. #34
    Well, I am very familiar with programming PIC's but I'll see if I can lend some of experience to use with AVR's.
    To be honest, I use loops for all of my timing. The easiest way I've found is to create a subroutine that has a timing delay of 1ms. Just look at the instruction set summary and see how many clock cycles each instruction takes. Each clock cycle should take 1/4 us. Once you have the subroutine of 1ms, timing is really easy. In lame programming it would look like this:

    move #ms in to count1

    loop
    call subroutine for delay of 1ms
    decrement count1 by 1
    test to see if count 1 is zero
    if not zero, go back to loop
    if zero, timing operation done.

    It depends on what you have interrupts doing to determine whether you should worry about them happening during a timing loop and screwing it up. In my case, I have only used interrupts for turning the gun off, so as you can see in this case, it really isn't an issue. But say, if you had a button that was an interrupt used for turning the eye on/off, and it flashed an led to indicate that, then yes it could throw off your timing if it happened in the middle of the loop.

    The free counting timers as mentioned are also another valid option. Just from my experience with PIC's, it is an 8-bit register that increments every cycle unless some type of scaler that was mentioned is put on the timer- and then when it overflows an interrupt is triggered. What I would do is set the mutiplier/prescaler to 1024. Then an interrupt would be triggered approximately every .25 ms. Then you can use an inner loop of 4 to time 1ms and the outer loop to time the # of ms you want.

    I think I might have to get in to programming AVR's. I've always wanted to program a new chip for my Tribal BBT and it might be kind of fun to get in on this project.

  5. #35
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by moppedclean
    Well, I am very familiar with programming PIC's but I'll see if I can lend some of experience to use with AVR's.
    To be honest, I use loops for all of my timing. The easiest way I've found is to create a subroutine that has a timing delay of 1ms. Just look at the instruction set summary and see how many clock cycles each instruction takes. Each clock cycle should take 1/4 us. Once you have the subroutine of 1ms, timing is really easy. In lame programming it would look like this:

    move #ms in to count1

    loop
    call subroutine for delay of 1ms
    decrement count1 by 1
    test to see if count 1 is zero
    if not zero, go back to loop
    if zero, timing operation done.

    It depends on what you have interrupts doing to determine whether you should worry about them happening during a timing loop and screwing it up. In my case, I have only used interrupts for turning the gun off, so as you can see in this case, it really isn't an issue. But say, if you had a button that was an interrupt used for turning the eye on/off, and it flashed an led to indicate that, then yes it could throw off your timing if it happened in the middle of the loop.

    The free counting timers as mentioned are also another valid option. Just from my experience with PIC's, it is an 8-bit register that increments every cycle unless some type of scaler that was mentioned is put on the timer- and then when it overflows an interrupt is triggered. What I would do is set the mutiplier/prescaler to 1024. Then an interrupt would be triggered approximately every .25 ms. Then you can use an inner loop of 4 to time 1ms and the outer loop to time the # of ms you want.

    I think I might have to get in to programming AVR's. I've always wanted to program a new chip for my Tribal BBT and it might be kind of fun to get in on this project.
    This is a bad way to do it... he should stick with the timer interrupts.

  6. #36
    No, it's not a bad way to do it- just a different way. It works perfectly fine and is incredibly accurate. I'm not sure if the Atmel micro's have more than one free counter, but if they don't, I would make use of that free counter for the automatic turn off feature.

  7. #37
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by moppedclean
    No, it's not a bad way to do it- just a different way. It works perfectly fine and is incredibly accurate. I'm not sure if the Atmel micro's have more than one free counter, but if they don't, I would make use of that free counter for the automatic turn off feature.
    I agree that it's different... and that is all.

    Does it work? If you make the rest of your code accomodate it... yes. This is silly if you don't have to do this.

    Is it elegant? No.

    Could it become problematic? Yes.

    Does it offer advantages over using interrupts? No.

    Whether it "works" or not doesn't mean it's good. You can wrap towels around your feet to use as shoes... and this "works" too.

  8. #38
    Join Date
    Jan 2002
    Location
    Halifax, N.S., Canada
    Posts
    7,368
    I agree that using interrupts has its advantages. The problem with not using them, is you can get caught in the loop where you can't do anything until it is finished. for that time period, no outside input is possible. Using interrupts, you can continually sample your inputs and control your outputs.
    Except for the Automag in front, its usually the man behind the equipment that counts.

  9. #39
    Join Date
    May 2005
    Location
    Virginia
    Posts
    205
    If your micro is running at 4Mhz, you can get the 30ms "tick" rate that you want with the 16 bit timer in the 2313.

    Choose the /64 prescaler setting. This results in a count frequency of 4000000/64 = 62500 counts per second. You want the timer to "time out" at 30ms, so .030 * 62500 = 1875. Therefore, set the timer up for compare-match mode and set the OCR1A match compare registers to 1875 (don't forget these 2 8 bit regs must be set in the proper order). Start the timer.

    You have 2 main methods to handle a "time out".
    1) Set up the match compare interrupt. It will be generated every 30ms. You can perform your periodic code in this interrupt service routine
    2) Otherwise, you could just poll the OCF1A bit in the TIFR register. It will be set to a '1' by the hardware everytime the timer reaches 30ms. Don't forget that you will have to manually clear it after you read that it is set to a '1'. So essentially, you'd have a test in your main loop that looks at the value of OCF1A, and whenever it is set, you branch and perform your periodic code.

    Either of these approaches will provide you with a stable, accurate time base. Method 1 is more precise, but a bit more challenging if you aren't familiar with programming interrupts. Method 2 is easier to implement, but can be slightly less accurate than method 1.

    Best of luck. Keep hanging in there with this project

    bit-wizard



    Quote Originally Posted by LorneCash
    I thought i read somewhere that this chip doesn't have true interrupts.

    The other thing is that the hardware timers only have certain resolutions built in(1,8,64,256,1024) . Maybe i just need some help understanding them, but if i want a timer that is exactly 30ms for the solenoid I can't use 8 because 8x4=32 now i think that is in cycles so that's actually is 4ms but either way how would i get it to branch when a value in milliseconds is hit how do i do the calculation with the timer and do i have to take into consideration the time (lines of code) between when the timer actually ends to when it is detected and when the next operation is starting?

    I hope that made sense it's still a bit fuzzy to me.

  10. #40
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    30ms is no good... it needs 1ms ticks.

  11. #41
    Join Date
    May 2005
    Location
    Virginia
    Posts
    205
    Not necessarily true. Most mechanical switches take at least 10ms to finish "bouncing", so 5 or 10ms is a decent interval to check. Even if the Emag does use a hall switch, a similar check interval is warranted. We are talking about 1/100 of a second, and based on human reaction time, +/- 10 or 20 or 30ms is still faster than someone can pull. So while 1ms would work, there is nothing that says that it "needs" a 1 ms tick.

    The reason I included the info for 30ms is because that is what he said he was trying to get. If he wants a different interval, he can compute it using the same method that I illustrated. I would shoot for somewhere between 2 and 10ms if I were doing it myself.

    Hope this helps.

    bit-wizard


    Quote Originally Posted by Miscue
    30ms is no good... it needs 1ms ticks.

  12. #42
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by bit-wizard
    Not necessarily true. Most mechanical switches take at least 10ms to finish "bouncing", so 5 or 10ms is a decent interval to check.
    Hehehe. Yeah... well. Paintball seems to ignore this line of thought.

    The 1ms resolution... was for adjusting your BPS cap mostly. And... I discovered that there is about a 1ms tolerance... for whether the "4.x FA problem" shows up or not... and whether the marker shoots or not. Took me longer to figure out why this is... than it did to write the whole thing.

  13. #43
    Join Date
    May 2005
    Location
    Virginia
    Posts
    205
    Interesting. I can see your point ... if you are trying to adjust the number of balls per second around 20 or above, you do get down to increments of 1/1000ths of a second (amazingly). So in other words, your statement of the need for 1ms tick resolution is based on the resolution of the adjustment that one tries to make, not any switch reading or debouncing that must take place.

    If he wants to use the 1ms tick, it can be obtained by using the /8 prescaler with the match compare value set at 500.

    bit-wizard

    Quote Originally Posted by Miscue
    Hehehe. Yeah... well. Paintball seems to ignore this line of thought.

    The 1ms resolution... was for adjusting your BPS cap mostly. And... I discovered that there is about a 1ms tolerance... for whether the "4.x FA problem" shows up or not... and whether the marker shoots or not. Took me longer to figure out why this is... than it did to write the whole thing.

  14. #44
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365
    Quote Originally Posted by bit-wizard
    Interesting. I can see your point ... if you are trying to adjust the number of balls per second around 20 or above, you do get down to increments of 1/1000ths of a second (amazingly). So in other words, your statement of the need for 1ms tick resolution is based on the resolution of the adjustment that one tries to make, not any switch reading or debouncing that must take place.

    If he wants to use the 1ms tick, it can be obtained by using the /8 prescaler with the match compare value set at 500.

    bit-wizard
    Just so I'm clear on the agreed best method...

    1. Use the Timer/Counter on the chip
    2. Set the prescalor to 8
    3. Make a 1ms tick by counting the timer 500x
    4. place the 1ms loop inside a loop that will run a given number of times so it can be used for multiple timers
    5. Set the given number to 30 and call the Subroutine for the Solenoid timer.

    I'm working with the microprocessors professor who seems very helpful so I want to make sure and do things the best way not the easiest way.

    Where should i use the interrupts vs polling? I know the argument about using interrupts for detecting a trigger pull that way it is never missed but realistically i know that isn't necessary. I can't think of an example of when two things would ever need to happen at once so it seems to me that i could just use poling for everything and interrupts to incrament/decrament the "bucket" when the timer overflows... any thoughts?

  15. #45
    Join Date
    May 2005
    Location
    Virginia
    Posts
    205

    My recommendation

    I would certainly recommend that you make use of the on-chip timer hardware. If you are interested in 1ms resolution, as Miscue suggests, then you would configure the timer to use the divide-by-8 prescaler setting. You would place the value 500 in the match-compare registers. See my previous 11/7 post for details. Also, read the 2313 datasheet concerning the 16-bit timers. Your microprocessors prof should be able to explain this to you if you tell him what you are trying to accomplish (using the 16 bit hardware timer to generate a periodic 1ms tick interrupt).

    If I were doing this project, I'd set the timer up to generate a periodic interrupt. This interrupt would occur every 1ms if you set the hardware up as previously described. You would then have this interrupt 'inc'rement a register. If it is only an 8-bit register, you will have a maximum timeable intervale of 255/1000=.255s. If you use a 16-bit register combination, then you can time up to 65.535s. You could then use this timer value in your foreground (main-line) code for timeout, debouncing, solenoid triggering, etc.

    As a note, be sure that if you are using a 16-bit register combo for timing, that you disable interrupts momentarily around the place where you access it in the main line to prevent an interrupt from changing the value of it after you've only read 8 of the 16 bits.

    I'd use polling to check the trigger input. No real need for an interrupt there assuming that the rest of your code isn't too huge or slow. If you use the timer to generate a tick interrupt which will automatically increment your "ticker", then you can compare to it to generate timeouts and such. For example, if you want to delay for 3ms, you would
    1) disable interrupts
    2) read your ticker 16 bit register into a working register pair
    3) reenable interrupts
    4) Add 3 to the value in your working register
    5) enter a loop where you
    a) disable interrupts
    b) read the ticker registers into a second pair of working registers
    c) reenable interrupts (because you want them disabled for the minimum possible amount of time)
    d) compare the value you just read to the value you computed in step 4
    e) when they are equal, you have reached your delay interval

    Timing this way will be accurate to within 1ms. For instace, if you are trying to delay for 3ms this way, you will be guaranteed to have delayed between 2 and 3ms. If you need an absolute minimum delay of 3ms, then you would set the delay value to 4ms, which would delay between 3 and 4 ms guaranteed.

    bit-wizard

  16. #46
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365
    Bit-Wizard:
    thanks a lot for the help on timers i managed to figure them out and used the Timer/Counters on the chip with interrupts to acomplish my tasks.
    Last edited by LorneCash; 11-24-2005 at 02:27 AM.

  17. #47
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365
    Miscue,

    I am trying to make a semi auto mode but i can't seem to figure out how to eliminate a full auto/burst. I know one of the possibilities is that the polarity on the solenoid has to be changed. Is there an easy way to check this to verify it is wrong? what were the other causes that you encountered? I thought I read somewhere that you originally had three full auto bugs. I added a d-bounce loop and that eliminated most of them but it still happens sometimes may be every 100 to 150 shots.

  18. #48
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365

    Strings

    My Bigest problem at now is the display. I got it to work but I don't know how to make it output from a string. I have to write it character by character. I talked to my microprocessors professor and he wasn't much help this time. Although he did use agilent displays, all the displays he used were smart displays... All he could tell me is that (in my best paraphrase) if I give a string of characters to the controller it can convert them to ASCII but that i will have to use an offset or pointer or something, here's where i get confused, to assign the charmap to the ASCII number.

    Can someone explain how this is done in as much detail as possible? A few code samples would be good too so i get the syntax correct.

  19. #49
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by LorneCash
    Miscue,

    I am trying to make a semi auto mode but i can't seem to figure out how to eliminate a full auto/burst. I know one of the possibilities is that the polarity on the solenoid has to be changed. Is there an easy way to check this to verify it is wrong? what were the other causes that you encountered? I thought I read somewhere that you originally had three full auto bugs. I added a d-bounce loop and that eliminated most of them but it still happens sometimes may be every 100 to 150 shots.
    Does it shoot extra shots while the trigger is pulled or released? Adjust your trigger conservatively to rule out mechanical trigger bounce.

  20. #50
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by LorneCash
    My Bigest problem at now is the display. I got it to work but I don't know how to make it output from a string. I have to write it character by character. I talked to my microprocessors professor and he wasn't much help this time. Although he did use agilent displays, all the displays he used were smart displays... All he could tell me is that (in my best paraphrase) if I give a string of characters to the controller it can convert them to ASCII but that i will have to use an offset or pointer or something, here's where i get confused, to assign the charmap to the ASCII number.

    Can someone explain how this is done in as much detail as possible? A few code samples would be good too so i get the syntax correct.
    I don't understand... if you can write it character by character, then it's just a matter of creating a repeat loop outputting characters until you reach a NULL string termination character.

    You adjust your offset pointer... that points to your char bitmaps... based off the ASCII values.

    Pseudocode:

    Put next character in the string into MyChar
    (MyChar - 65) * (Byte size of bitmap character) = Desired offset for char bitmap

    Note: 65 is ASCII for 'A'. 'A' - 65 = 0... an offset of 0 is needed to get to the head of the char bitmap array. I'm assuming that the first character in your char bitmap is 'A'. Otherwise you'll have to change it from 65 to something appropriate.
    Last edited by Miscue; 11-29-2005 at 06:46 PM.

  21. #51
    Join Date
    Apr 2004
    Location
    Sweden
    Posts
    555
    PM me, need a lil story from ya
    Proud owner of #VV04026

    MY WORK - X-MAGs Around the World Are you one among the Lucky Ones? - [X-Mag EXCELS]

  22. #52
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365
    Quote Originally Posted by Miscue
    Does it shoot extra shots while the trigger is pulled or released? Adjust your trigger conservatively to rule out mechanical trigger bounce.

    Yea, you're right, the gun i'm using for this project i bougnt on eBay and have never actually played with. when i loaded 3.2 on it, it bounced there too in e mode i think that's because of the trigger rod not being adjusted properly, but either way can you tell me how to check if the solenoid is wired backwards?

  23. #53
    Join Date
    May 2005
    Location
    Virginia
    Posts
    205
    I don't think I understand your question about the solenoid being wired backwards. Solenoids are simply many turns of wire around a tube that the plunger rides in. When the solenoid is energized, the plunger is pulled into the tube. When it is de-energized, a spring returns it to its original position. Depending on how it is mechanically designed, this action can provide either a push or a pull from the plunger. The one in the emag looks like it should pull into the solenoid body when it is energized, pulling down on the sear. With all that said, most solenoids work the same way regardless of which direction the current is flowing. So you can't really have it in backwards unless there is an external circuit element like a diode in the current path preventing the current from flowing in one direction. The fact that it works for you most of the time indicates that it is wired correctly. Sorry if I missed the jist of your quetion -- if that's not what you were asking, please re-phrase.

    Thanks,
    bit-wizard

  24. #54
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by bit-wizard
    I don't think I understand your question about the solenoid being wired backwards. Solenoids are simply many turns of wire around a tube that the plunger rides in. When the solenoid is energized, the plunger is pulled into the tube. When it is de-energized, a spring returns it to its original position. Depending on how it is mechanically designed, this action can provide either a push or a pull from the plunger. The one in the emag looks like it should pull into the solenoid body when it is energized, pulling down on the sear. With all that said, most solenoids work the same way regardless of which direction the current is flowing. So you can't really have it in backwards unless there is an external circuit element like a diode in the current path preventing the current from flowing in one direction. The fact that it works for you most of the time indicates that it is wired correctly. Sorry if I missed the jist of your quetion -- if that's not what you were asking, please re-phrase.

    Thanks,
    bit-wizard
    Here is the problem. The solenoid also creates a magnetic field - an opposite pole depending on how it is wired.

    The EMag uses a magnetic HES sensor to detect trigger pulls. The solenoid is close enough to interfere with this. I've screwed around with this A LOT. It is well within the field... even relocating the HES/solenoid a pretty good distance further doesn't fix it, nor magnetic shielding. BTW... if you ever wondered what the difference was between 4.20 and 4.01 - it's a fix for this. Took me a while to understand what was happening.

    If it is going FA when the trigger is released... then the solenoid is registering a trigger pull in place of the trigger magnet. With shot buffering, this can result in perpetual FA.

    If it is going FA when the trigger is pulled... it is canceling the trigger magnet... so even though the trigger is pulled, the solenoid cancels the field temporarily. So: Trigger pull, solenoid cancels field and appears to not be pulled... solenoid powers down... trigger has not moved but a new trigger pull has been detected. = semi-perpetual FA because it doesn't consistently defeat the trigger magnet.

    The first one I mentioned is sometimes referred to as the "4.x FA problem." The second is the "3.x FA problem," and is "fixed" by flipping the solenoid wires. However, the 3.x software also has the "4.x FA problem," it's just harder to reproduce... 4.x magnifies it big time.

    4.20 solves both problems... At least, I was unable to find a counter-example... it cured a lot of really bad FA EMags.
    Last edited by Miscue; 11-26-2005 at 03:22 PM.

  25. #55
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365

    Dwell

    Kind of off the subject but how did 30ms become the magic number for solenoid dwell? Is there any research results for different dwell times that i could see? If it's somewhere else on AO can someone copy and paste it into this thread. I think it would make sense to post it here. I thought i read somewhere that it was 25ms in other some software versions.

    Also, what is the recommended time to advance the warp feed without firing the gun?

  26. #56
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by LorneCash
    Kind of off the subject but how did 30ms become the magic number for solenoid dwell? Is there any research results for different dwell times that i could see? If it's somewhere else on AO can someone copy and paste it into this thread. I think it would make sense to post it here. I thought i read somewhere that it was 25ms in other some software versions.

    Also, what is the recommended time to advance the warp feed without firing the gun?
    These values were determined by Tom Kaye/AGD... the amount of time needed for the bolt to reliably make a full stroke.

    You can prime the warp by turning on the solenoid for a fraction of a millisecond.

  27. #57
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365

    Low battery FA bug

    I've just discovered the low battery FA bug in my software. Does swaping the solenoid wires fix that or was that fix done in the software?

  28. #58
    Join Date
    Oct 2000
    Location
    Las Vegas, NV
    Posts
    7,104
    Quote Originally Posted by LorneCash
    I've just discovered the low battery FA bug in my software. Does swaping the solenoid wires fix that or was that fix done in the software?
    Did you try this with the marker aired up? When you get the low battery FA condition, it does not have enough power to pull the solenoid... as far as I remember.

    Makes you feel all warm and fuzzy don't it.

    Also... if I remember correctly... the problem is that the solenoid draws too much power in low battery condition... dropping the voltage below normal operational levels. The HES isn't a passive kind of switch... it requires power to work right... insufficient voltage = the HES does not output correctly... and you get FA. Don't quote me on that... I tested this situation with a different kind of switch but do not remember the results.

    I also tried... to make the gun not fire when it detects low voltage. However, this does not work right... it screws things up... semi-random behavior... not shooting when supposed to... when the marker has normal power. Seems that the solenoid drops it to low voltage condition all the time... even if the battery isn't low.

    BTW... this post... although short... represents many... many hours of work... to come to these conclusions. Also... many hours wondering to myself... "Why isn't there a well-placed capacitor? Taiwan makes them pretty cheap."
    Last edited by Miscue; 11-29-2005 at 07:08 PM.

  29. #59
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365

    Display

    I think my problem with the display may be that i don't know where in memory my CHRMAP: is being saved.

    I define it like this:

    CHARMAP: .DB 0x00,0x00,0x00,0x00,0x00,0x7C,0x8A,0x92,0xA2,0x7C ; " ",0
    .DB 0x02,0x42,0xFE,0x02,0x02,0x46,0x8A,0x92,0x92,0x62 ; 1,2
    .DB 0x44,0x82,0x92,0x92,0x6C,0x18,0x28,0x48,0xFE,0x08 ; 3,4
    .DB 0xE4,0xA2,0xA2,0xA2,0x9C,0x3C,0x52,0x92,0x92,0x0C ; 5,6
    .DB 0x80,0x8E,0x90,0xA0,0xC0,0x6C,0x92,0x92,0x92,0x6C ; 7,8
    ...

    How do I give it a specific start location in memory so i know what the offset should be? Or is that the wrong approach?

  30. #60
    Join Date
    Aug 2005
    Location
    Milwaukee WI
    Posts
    365

    Display 2

    I used to define my text strings like this:

    M_TRUE: .DB SPACE,SPACE,SPACE,SPACE,SPACE,SPACE,BLOCK,BLOCK,0x ff,0xff

    notice the "0xff" at the end of the row... I was using that to tell the loop it is at the end of the string. Is there a better way to do this so I can just define my strings like this:

    M_TRUE: .DB "MY TEXT"

    (Also see my previous post)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •