Need a bit of coding help

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi guys, I'm new here, to MCUs, and C, but not coding or electronics. I was working on a project and someone said I can do it better with an MCU, so I've been giving it a shot, but the C amd coding are throwing me for a bit of a loop. I'm a .NET and UI programmer and designer, so this is different for me. I'm just hoping I can get some help.

 

My concept is simple. It's basically an LED flash, a power led, a shutter push button, function push button (on/off)...

 

I have my flash/shutter down. Easy peasy. But coding a function push button is harder. I was thinking of using an integer that would be increments up with each press and reset after 2. 1, 2 and reset, 1, 2 and reset... And so on. And then use an if then to determine what would happen with other functions depending on the function integer value.

 

I also though about using a CD4013 to flip flop two pins hi and low. And then just poll those pins and use an if then based on a hi/low input.

 

if I could get a quick tutorial on how to do both in code, it'd make my day because I could really use both methods for lots of neat stuff. Thank you guys so much for any help.

 

PS: I'm using The ATMega48A. It seems to be the cheapest and best for my needs. I also have a copy of MikroBasic, so if I can do this in basic, I'd be ecstatic. Mychal gracias, my new friends!

-Dominic

Last Edited: Mon. Oct 27, 2014 - 09:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First step is to decide how you are going to connect the button to the micro. You probably need to read and understand thisfirst:

 

http://www.ganssle.com/debouncin...

 

So while reading an input bit appears, on the surface to be trivial "if (PINx & some_mask)" the problem you face is that the button needs time to settle. as suh, unless you use a hardware solution for debounce the usual technique is to run a timer interrupt (10ms say) and then poll the state of any input button(s) on each "tick". Only consider a button to be definitely in a state (up or down) when it has been seen in the same state for several ticks.

 

Once you have a reliable way to read button states it's then just a case or reading the state and if it's different from last time you know the button has been pressed or released. Either on each press or each release you increment a global variable (or perhaps a static) that is doing the 0,1,2 count.

 

BTW you posted in programmers/debugger - this is not a good forum to choose so I'll move this to the tiny/mega forum that is appropriate for mega48A questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dominicmluciano wrote:

hi guys, I'm new here, to MCUs, and C, but not coding or electronics. I was working on a project and someone said I can do it better with an MCU,. . . . .

 

Sounds just like me a while ago, and I also struggled with buttons at first - My project also has two buttons - but to set a clock.

 

I got there eventually, and I am not sure my approach is "best practice", but it works and I understand it :)

 

If you look at my "noob" project here :-

 

https://www.avrfreaks.net/forum/n...

 

. . . at the end I have posted my code in a zip. If you look at the "Buttons" header and class you can see how I read and de-bounce the buttons. I have modified and used this class in a few projects since then.

 

As a .NET developer you may find my more Object Oriented approach a bit more familiar.  I also work in .NET to pay the bills.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a .NET developer you may find my more Object Oriented approach a bit more familiar.

You do, of course, have the options for C++ ;-)

 

Of course whether you use C++ or C or Asm (or Forth or ....) the fact is that the way you actually read button states and the issues with bounce are all the same.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Buttons do bounce a little, but I find its much easier to read the switch at an interval longer than the settle time. I have experimentally determined that this is in microseconds for small switches, so it is a non problem designed as a hazing ritual to spook new microcontroller programmers.

 

Imagecraft compiler user

Last Edited: Mon. Oct 27, 2014 - 12:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:

Buttons do bounce a little,. . . .

 

 

I have always wondered how much.

 

Since my last visit here I have been delving into ATTiny's and Adc'S and having lots of fun in analogue school.

 

. . . .So much fun I went out and bought a DSO scope like a REAL professional, so when I have mastered the scope thingy I will pull out my switches and see how they really bounce.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

but I find its much easier to read the switch at an interval longer than the settle time

But how do you elapse that time? You presumably either do a synchronous delay (delay_ms(20) or something?) or you use a timer interrupt. If you are going to do a timer interrupt then why not just do debouncing properly rtaher than trying to avoid the issue? That way you can read button changes possibly faster than your 20ms or whatever the fixed delay time you chose was. If I'm hammering the "minutes" button on an alarm clock to get from 0 to 55 I want to be able to do it as fast as my bouncing finger allows!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you were using C++ you could use my debouncedswitch class...

 to debounce a switch yo look for a state change then wait and see if it's still changed

 

See the code here

https://github.com/kvasilak/Debo...

 

For the rest, you need to use a state machine.

The easiest state machine is the good ol switch statement. you code runs in a case untill something happens whereupon it moves to a different case.

 

Debounced.cpp shows this pretty well

 

NEVER EVER use delay().. Ever.. use millis and check for elapsed time.

 

//return true if it's been period ms since start

bool IsTimedOut(uint32_t period, uint32_t start)

{

uint32_t current = millis();

return(current - start > period);

}

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

NEVER EVER use delay().. Ever.. use millis and check for elapsed time.

I do agree that using the _delay() should be avoided especially in an application with multiple buttons as this will hold up the micro, but in the OP's case where he only has one button

_delayms(20);

Then check the switch again to confirm state will make that much of a difference.  He has not indicated that during the debounce time the micro will need to do other things.

 

One could also use a 10ms timer and count off two or three ticks and then check the pin state as well.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bad habits start early.

Don't use delay(), use a millisecond counter, it's not that hard.

 

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chartz wrote:
bobgardner wrote:

Buttons do bounce a little,. . . .

I have always wondered how much.

In my limited-but-careful experiment, it ranged from "virtually not at all" to 2.3 milliseconds (up to 12 distinct "bounces" on closure), depending on the switch/button.

Chartz wrote:
[...] so when I have mastered the scope thingy I will pull out my switches and see how they really bounce.
A wise choice.  I often wish that more people would do that test.

 

P.S. Your avatar image is a bit grainy, but it reminds me of a Massey-Ferguson tractor I used to own.

 

Regards,

Bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Bad habits "(using blocking delays)"start early." Well, once one is aware software delays make software evolution complicated, one can use them if one dooes not want one's project to evolve (ex : in an Arduino : all (my and other people for LCD init)  init phase uses software delays.

Then, in main loop, I use , as you do a millisecond counter because it is easier to add other tasks.  But what if one does not want to add other features?

 

 

BTW current and start are in milliseconds. What happens after 2**32 milliseconds (ca  60 days?). I would have used an abs in your function (I do it, but never tested it)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:

Bad habits start early.

Don't use delay(), use a millisecond counter, it's not that hard.

 

I'm more liberal than you.  I'd allow use of the delay functions to a newbie for about the first two blinking LED projects.laugh  After that, as you say, it's time to learn the correct way to handle longish delays in a uC, using timer interrupts and software counters / state machines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP, 2 questions and a suggestion:

 

1) Why do you think you need an external flip-flop?  It's extremely likely that you can get the functionality you want in software.

 

2) Are there any other timed functions in your project?  For example, how long does the LED flash?

 

The suggestion - look at my tutorial that includes a simple cyclic executive framework, you may find it a useful pattern to follow:

http://www.embeddedrelated.com/s...

 

There are also a couple of tutorials that deal with debouncing, starting with this one:

http://www.embeddedrelated.com/s...

Last Edited: Mon. Oct 27, 2014 - 04:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote a program that increments a count using the button under test, and increases and decreases the program loop time using the keyboard az keys. The idea is you peck the button and make the loop faster until you get an extra count or miss a count. I was surprised that I had to get the loop time down into the single digit microseconds to mess up reading those little tactile buttons. I guess Big Toggle Switches with heavy springs bounce longer.

 

Imagecraft compiler user

Last Edited: Mon. Oct 27, 2014 - 04:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have that code by chance? I'd love to see it :)

-Dominic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess Big Toggle Switches with heavy springs bounce longer.

 I guess y'all have never looked at the oft-referenced Ganssle experiments.  A fair variety of test subjects. 

http://www.ganssle.com/debouncin...

 

Indeed, Bob, IME "bigger is bouncier"--my longest observed times over the years have been on big industrial buttons.  (Another interesting factor there is that e.g. estop may be rarely used, and it may take some ms for the wiper current to burn through the oxidation.)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I know that, but I don't know how yet lol. As far as other timed functions, I have them covered. Mostly what I'm interested in is that button count increment deal. The only other thing I'd want to possibly do is use a phototrans to set an auto flash function.

-Dominic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mostly what I'm interested in is that button count increment deal.

Well at the core of it that's surely just:

int main(void) {
    while(1) {
        if (button_event) {
            state_variable++;
            if (state_variable > 2) {
                state_variable = 0;
            }
        }
    }
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I cant find it on my machine at work. Pretty sure its on my machine at home. Stand by till Mon evening...

 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's a basic button test loop, using 3 buttons - the "test" button, a display button and a reset button

 

 

// this code is in main() after all HW init

u8 button;
u8 last_button = 0;
u8 count = 0;
u8 pinb;

while (1)
{
    pinb = !PINB;  // invert active-low buttons;
    button = pinb & TEST_BUTTON_MASK;
    if (button && !last_button) // button is newly pushed
    {
        count++;  // count number of button pushes
    }
    last_button = button;

    if (pinb & DISPLAY_BUTTON_MASK)
    {
        display_count_on_your_particular_hw();
    }
    
    if (pinb & RESET_BUTTON_MASK)
    {
        count = 0;
    }
}

 

 

Last Edited: Tue. Oct 28, 2014 - 01:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:

"Bad habits "(using blocking delays)"start early." Well, once one is aware software delays make software evolution complicated, one can use them if one dooes not want one's project to evolve (ex : in an Arduino : all (my and other people for LCD init)  init phase uses software delays.

Then, in main loop, I use , as you do a millisecond counter because it is easier to add other tasks.  But what if one does not want to add other features?

 

 

BTW current and start are in milliseconds. What happens after 2**32 milliseconds (ca  60 days?). I would have used an abs in your function (I do it, but never tested it)

 

the wrap happens at 49 days with a uint32, 1 minute with a uint16.

Using unsigned math eliminates the need for abs()

See this explanation;

https://www.avrfreaks.net/forum/t...

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

Here's a basic button test loop, using 3 buttons - the "test" button, a display button and a reset button

 

// this code is in main() after all HW init

u8 button;
u8 last_button = 0;
u8 count = 0;
u8 pinb;

while (1)
{
    pinb = !PINB;  // invert active-low buttons;
    button = pinb & TEST_BUTTON_MASK;
    if (button && !last_button) // button is newly pushed
    {
        count++;  // count number of button pushes
    }
    last_button = button;

    if (pinb & DISPLAY_BUTTON_MASK)
    {
        display_count_on_your_particular_hw();
    }
    
    if (pinb & RESET_BUTTON_MASK)
    {
        count = 0;
    }
}

 

 

I have no idea what this is supposed to do.

it makes no sense as written

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meteor wrote:

 

P.S. Your avatar image is a bit grainy, but it reminds me of a Massey-Ferguson tractor I used to own

 

 

Close. It's a Ferguson. They were made from 1946 to 1956, and many still in use here in South Africa. I loved the one we had on the farm I grew up on. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:

 

kk6gm wrote:

 

Here's a basic button test loop, using 3 buttons - the "test" button, a display button and a reset button

 

// this code is in main() after all HW init

u8 button;
u8 last_button = 0;
u8 count = 0;
u8 pinb;

while (1)
{
    pinb = !PINB;  // invert active-low buttons;
    button = pinb & TEST_BUTTON_MASK;
    if (button && !last_button) // button is newly pushed
    {
        count++;  // count number of button pushes
    }
    last_button = button;

    if (pinb & DISPLAY_BUTTON_MASK)
    {
        display_count_on_your_particular_hw();
    }
    
    if (pinb & RESET_BUTTON_MASK)
    {
        count = 0;
    }
}

 

 

 

 

I have no idea what this is supposed to do.

it makes no sense as written

Well, those are two very different claims.  I will address the first.

 

1) Push the "test" button (the one you want to count bounces on) and release it

2) Push the display button to see how many counts the software registered

3) Push the reset button to clear the count (this could also be part of the display function, reducing the button count to 2).

 

The reason for separating out the display function is that converting and writing out an integer value can take a lot of time (relative to the button bounce time), so you don't want to be displaying while the button is bouncing.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Add incdelay and decdelay buttons so you can decrease the while loop delay until you start getting bad counts due to bounce. Dont forget to post the results! Inquiring minds want to know!

 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:

Add incdelay and decdelay buttons so you can decrease the while loop delay until you start getting bad counts due to bounce. Dont forget to post the results! Inquiring minds want to know!

 

Yes, a nice addition.  I think I'll play with this tonight.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dealing with many switch or other non-switch debounce.  Sorry it's in .asm

 

 sbic  Mades,Sw1         ; Sw1 made ?
  rjmp  Sw1_Made          ; Yes, handle sw1
  sbic  Mades,Sw2         ; No. Sw2 Made ?
  rjmp  Sw2_Made          ;   Yes, handle sw2

  and   Button2,Button1   ;
  and   Button3,Button2   ; Look for makes

  sbrc  Button3,Sw1       ; Sw1 pushed ?
  rjmp  Make_Sw1          ; Yes, make sw 1
  sbrc  Button3,Sw2       ; No. Sw2 pushed ?
  rjmp  Make_Sw2          ;   Yes, make sw 2
  rjmp  Leave_ReadSw      ; Leave

Make_Sw1:
  sbi   Mades,Sw1         ;    Set made
  rjmp  Leave_ReadSw
Sw1_Made:
  or    Button2,Button1
  or    Button3,Button2
  sbrc  Button3,Sw1       ; Sw1 still pushed ?
  rjmp  Leave_ReadSw      ; Yes, leave
  cbi   Mades,Sw1         ; No, say so

 

I have 3 registers.  You can see they are 'anded' - looking for three trues in a row with no false.  This declares the switch made.

If three trues make the switch made true, then I 'or' the registers and look for three false in a row.  Yes, first come fist served.

 

Last Edited: Tue. Oct 28, 2014 - 12:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, so back to my thing for a second. I've managed to get rolling pretty good using mikroBASIC. Except I'm not so sure how to debounce with it.

 

I added a delay before the program changes the state variable, but it's not working how it should. It should increment the variable each press resetting it after 2, but instead it's just cycling through each If Then I add.

 

if (Button(PIND, 1, 1, 1) <> 0) then 'Detect logical state
         delay_ms(100) 'Debounce
         FState = 1        'Update flag
      end if
      if (FState and Button(PIND, 1, 1, 1)) then 'Detect 1 to 0 transition
        'If Thens and FCount integer incrementation goes here
         End If
         FState = 0 'Reset flag
      end if

 

-Dominic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

domenic,

This:

My concept is simple. It's basically an LED flash, a power led, a shutter push button, function push button (on/off)...

has me wondering a few things as everyone is bent over debouncing a button.

 

This 'flash', is this a piece of photography equipment that you want to control with the AVR?  I ask only because the only possible 'output' you mention in your OP is the power LED. 

 

What is this device ultimately supposed to do?

With that question, could you post the sequence of events that are supposed to occur?

 

Example:

1) press function(on/off) button.  Initialize inputs and outputs

2) Turn ON 'power LED'

3) Wait for 'shutter' button

4) upon detecting a 'shutter' button press...........................................Now what?

 

The reason I ask is primarily because of the debouncing.  if this is a simple sequence of events then simply using the "DREADED _delay_ms()" may be all that you really need for now.  And contrary to some beliefs I personally would rather a beginner see the project at least work and get your enthusiasm going.  This way you have at least a basic building block of what you want the thing should do,  then you can tinker with it and make it better using the great ideas that have already been presented.

 

Also, I see you are now using mikroBASIC.  I thought originally you were going with C/C++.  I have not read all the posts cleanly so I guess along the way you switched teams?

 

Cheers!

 

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WTH???

 

I thought I was posting a new post, and my new post ended up overwriting most of my previous post 22!  That has NEVER happened before.  Not sure how I can recover that post...

 

 Anyway, here's some test code I came up with, using a test button, a display button, and buttons to inc or dec the loop delay by 25us each press.

 

#define TEST_BUTTON_MASK	(1<<0)
#define DISP_BUTTON_MASK	(1<<1)
#define DEC_BUTTON_MASK		(1<<2)
#define INC_BUTTON_MASK		(1<<3)


char Buf[LCD_WIDTH+1];

void delay_25us(u8 count)
{
  while (count-- != 0)
  {
    _delay_us(23);
  }
}

void display_count(u8 count)
{
  sprintf(Buf, "C: %u   ", count);
  lcd_display(0, 1, Buf);
}

void display_us(u8 count)
{
  sprintf(Buf, "US: %u   ", 25*count);
  lcd_display(0, 1, Buf);
}

int main(void)
{
  u8 last_button = 0;
  u8 button;
  u8 input;
  u8 count = 0;
  u8 delay_count = 0;
  
  DDRC = 0x80;	// PORTC7 output, 3-0 button inputs
  PORTC = 0x0F;	// C7 active low, pullups on 3-0
    
  lcd_init();
  lcd_display(0, 0, "Hello World!");

  while(1)
  {
    if (delay_count != 0)
    {
      delay_25us(delay_count);
    }
    
    input = ~PINC;
    
    button = input & TEST_BUTTON_MASK;
    if (button & !last_button) // leading edge of push
    {
      count++;
    }
    
    else if (input & DISP_BUTTON_MASK)
    {
      display_count(count);
      count = 0;
      _delay_ms(500);
    }
    
    else if (input & INC_BUTTON_MASK)
    {
      delay_count++;
      display_us(delay_count);
      _delay_ms(500);
    }
    
    else if (input & DEC_BUTTON_MASK)
    {
      delay_count--;
      display_us(delay_count);
      _delay_ms(500);
    }

    last_button = button;
  }
}

The results, with the common little PCB buttons, are as follows:

 

0us added delay: 50 pushes - 55 to 70 pushes detected

100us added delay: 50 pushes - 50+ pushes detected (I had more at least 1 time, but didn't write down the number)

200us added delay: 50 pushes - 50 pushes detected, never any more

 

Didn't test with any other button types, but that would be an interesting followup.

 

This was on a 16MHz ATmega1281.

Last Edited: Tue. Oct 28, 2014 - 01:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
WTH???

 

I thought I was posting a new post, and my new post ended up overwriting most of my previous post 22!  That has NEVER happened before.  Not sure how I can recover that post...

A fellow 'Freak who does automated hourly backups might come to the rescue... smiley

 

Your post #22 looked like this:

kk6gm wrote:
Here's a basic button test loop, using 3 buttons - the "test" button, a display button and a reset button

 

// this code is in main() after all HW init

u8 button;
u8 last_button = 0;
u8 count = 0;
u8 pinb;

while (1)
{
    pinb = !PINB;  // invert active-low buttons;
    button = pinb & TEST_BUTTON_MASK;
    if (button && !last_button) // button is newly pushed
    {
        count++;  // count number of button pushes
    }
    last_button = button;

    if (pinb & DISPLAY_BUTTON_MASK)
    {
        display_count_on_your_particular_hw();
    }
    
    if (pinb & RESET_BUTTON_MASK)
    {
        count = 0;
    }
}

You're welcome. smiley

 

P.S. OT @Chartz: Loved my Massey-Ferguson too, except for the fact that it lacked a "live" hydraulic. So when it came time to pull fence posts, the "MF" was the last choice. wink

 

Regards,

Bill

Last Edited: Tue. Oct 28, 2014 - 01:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meteor wrote:

 

kk6gm wrote:

WTH???

 

 

I thought I was posting a new post, and my new post ended up overwriting most of my previous post 22!  That has NEVER happened before.  Not sure how I can recover that post...

A fellow 'Freak who does automated hourly backups might come to the rescue... smiley

....

Regards,

Bill

Many thanks, I copied that back into #22.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WTH???

 

I thought I was posting a new post, and my new post ended up overwriting most of my previous post 22!  That has NEVER happened before.  Not sure how I can recover that post..

I copied Meteor's post and went to your post #22 to edit it with your original and when I got in it magically corrected itself.

 

Looks ok now.

 

EDIT: DOH'!!  Beat me to it

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Oct 28, 2014 - 01:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

WTH???

 

I thought I was posting a new post, and my new post ended up overwriting most of my previous post 22!  That has NEVER happened before.  Not sure how I can recover that post..

I copied Meteor's post and went to your post #22 to edit it with your original and when I got in it magically corrected itself.

 

Looks ok now.

 

 

Gosh, so much attention being paid to little old me!  Maybe now I can eat at the popular table!

The Kool-Aid tastes just the same there too!

Seriously, thanks for going in to fix it.  Guess I just beat you by a few seconds.

Yep!  wink

Last Edited: Tue. Oct 28, 2014 - 02:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

using mikroBASIC

That's a shame - there are very few Basic users here and even fewer that use Mikroelektronika products so I fear there won't be many that are going to be able to comment on your code sequences except to appraise the overall algorithmic approach perhaps?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the shutter locked down. It is incredibly easy, and I'm using a transistor with the LED to tap power directly from the source for a higher current, and just getting the on\off signal from the AVR pin.

 

The other part is an on\off "function" switch (and hopefully an on\off\auto switch if I can get it going right). It will ensure the flash either fires or doesn't depending on what the user wants, basically just turning the output ability for everything on\off (which I'm still figuring out). Now this is where I'm having trouble because I'm using delay_ms(x) (which does work fine for the shutter), but it's not properly debouncing the function button, so my if\then statement isn't working right because the switch bounce is causing the program to cycle through all of my incrementing variables basically instantly. So instead of FCount incrementing once each press and resetting after 2, one press is taking FCount = FCount +1 and making it worthless. So my If\Then works, just all in succession. And I can increase the delay time, but ~100ms is making is so the press isn't even recognized at all sometimes. This is the dilemma I'm running into. I'm afraid I need to debounce another way, possibly with hardware like I had it. I know I can use code to do it, but a CD4013 d type latch is a great power switch. Plus there's so many great power management IC's out there these days, especially for making sure batteries stay alive a long time.

 

As for Basic, it's my mother language. When I discovered mikroBASIC, it made this a million times easier because I'm more familiar with it. I can use code in C, but I'll be translating the concept into Basic. I'm having a much easier time this way, especially since it's such a "basic" program... hehehe yeswink

 

 

-Dominic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yea, I know, but it's just so much easier for now, especially since I just need to get this project wrapped up. Basic is my main language (despite starting on C++), so it just makes this so much easier to grasp for now.

-Dominic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Basic, it's my mother language. When I discovered mikroBASIC,

Then be ready to be blown away by BASCOM wink http://www.mcselec.com/

Lots of working code and good support even by some members here. You can download a 4K limited version.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly