Baracuda + Micro

[Michaelo]

Hers is the current keyboard routine... simple switches though no rotary encoding but...

void loop()
{
  if(bcount++ > BCT) check_battery();

  delay(300); // a small delay //
  
  int keyinput = getkeypress();
  
  if(keyinput)
  {
    do_menu(keyinput);  
  }
}

int getkeypress()
{
  /*
    No need to check individual keys, we simply check them all at once...
    We could allow key combinations if so desired...
   */  

  int keydata = PINB;
    
  // Loose the bit we don't want, we just need PB2 to PB5 //
  keydata = ((keydata << 2)>> 4);

  // debounce //
  delay(5);
  if(keydata == ((PINB<<2)>>4) && keydata < 15)
  {
    return(keydata);
  }
  return(0);  
}


void do_menu(int input)
{
  lcd.clear();
  lcd.setCursor(0, 0);

  // examples //
  switch(input)
  {
    case  7: lcd.print("     Frequency      ");
    break;
    
    case 11: lcd.print("     Pulses           ");
    break;
    
    case 13: lcd.print(" something else    ");
    break;
    
    case 14: lcd.print("    <---------->    ");
    break;
    
    default: // do something...
    break;
  }
} 

Using php instead of code format it nicer

Mike

[Michaelo]

Hi Mike
I haven’t done any programming for microprocessors but I found this menu processing example interesting.
Have a good day,
Chet

That looks cool and I have a couple of the Nokia display... much check it out...
Nice one...Chet

[Chet]

I was kinda being sarcastic... the code isn't finished, I actually dropped by to ask if anyone had ideas for what should be in the menu, allowing that we can only set/change timing ATM...
I worked in a similar environment but with both hardware and software engineers. Strangely enough, the software guys were often at loggerheads as to which way to approach and solve problems, but the hardware guys seemed to agree most of the time
Mike

Hi Mike
I haven’t done any programming for microprocessors but I found this menu processing example interesting.
Have a good day,
Chet

http://www.allaboutcircuits.com/projects/how-to-use-a-rotary-encoder-in-a-mcu-based-project/

[Michaelo]

It would be lame excuse not to post own work because of what others will think and say.
On contrary; it is better to expose it to public criticism because that's the best way to improve it.
People here should calm down, there is no point in arguing on ego basis.
Every honest work is welcome.

P.S.
Sheesh!
Programming experts are the toughest ones! I worked with a programming team for one foreign company.
It was horror a while after personal egos awakened!
Sort of deja vous here!

I was kinda being sarcastic... the code isn't finished, I actually dropped by to ask if anyone had ideas for what should be in the menu, allowing that we can only set/change timing ATM...
I worked in a similar environment but with both hardware and software engineers. Strangely enough, the software guys were often at loggerheads as to which way to approach and solve problems, but the hardware guys seemed to agree most of the time
Mike

[ivconic]

Just dropped by to post some LCD code but after reading the last few posts, I'm reluctant less my code be judged bad or sub standard...

For what it's worth, the final code will be almost certainly be interrupt driven but that in no way distract form Teleno's excellent polling solution.
I should also note that from the outset the aims were to provide micro precision (and adjustable) timing for the bara and that, with the exception of the user interface, has already been achieved.

Mike

It would be lame excuse not to post own work because of what others will think and say.
On contrary; it is better to expose it to public criticism because that's the best way to improve it.
People here should calm down, there is no point in arguing on ego basis.
Every honest work is welcome.

P.S.
Sheesh!
Programming experts are the toughest ones! I worked with a programming team for one foreign company.
It was horror a while after personal egos awakened!
Sort of deja vous here!

[Michaelo]

Just dropped by to post some LCD code but after reading the last few posts, I'm reluctant less my code be judged bad or sub standard...

For what it's worth, the final code will be almost certainly be interrupt driven but that in no way distract form Teleno's excellent polling solution.
I should also note that from the outset the aims were to provide micro precision (and adjustable) timing for the bara and that, with the exception of the user interface, has already been achieved.

Mike

[Teleno]

the whole point of separating timing critical matters into a timer based interrupt loop, is that the rest of that code that isn't critical can be run at leisure.

My point was time critical matters are better handled by polling interrupt flags rather than ISR, and I proved that with actual code vs. ISR code, and that got you all wired up.

Still waiting for you to put your code where your mouth is.

[ODM]

When you're done writing this diatribe and actually read what was written earlier, the whole point of separating timing critical matters into a timer based interrupt loop, is that the rest of that code that isn't critical can be run at leisure. So there is plenty of time to wait out lcd delays, do debouncing for buttons, update audio output by PWM and so on. All of that can be skipped by interrupt at any time.

And the best part is a whole new operating pulse sequence, menu option, can be just thrown in. Neither side will interfere with the other.

I'll write something for an example later.

[ivconic]

Delay sucks!
Mills kills!

[Teleno]

I don't mean to sound offensive but frankly that is pretty crappy programming. Let's take an example; for LCD use it's rather nice to use a ready-made library (such as http://community.atmel.com/projects/hd44780-library ) and focus efforts on the actual detector implementation. Programming is not necessarily as much about writing code to bit-bang displays and toggle IOs at the same time, as it is about avoiding writing all those lines with a library like that, for example.

Using this kind of library which uses no hardware timers but counter based delay loops, the cpu's practically wasting time in those necessary delays to run a hd44780 display, just decrementing and jumping.

OK let's take a peek at the actual code from your suggested library:

hd44780.h

#define [B]Delay_ns[/B](__ns) \ 
    if((unsigned long) (F_CPU/1000000000.0 * __ns) != F_CPU/1000000000.0 * __ns)\ 
          __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1000000000.0 * __ns)+1);\ 
    else __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1000000000.0 * __ns)) 
  #define [B]Delay_us[/B](__us) \ 
    if((unsigned long) (F_CPU/1000000.0 * __us) != F_CPU/1000000.0 * __us)\ 
          __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1000000.0 * __us)+1);\ 
    else __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1000000.0 * __us)) 
  #define [B]Delay_ms[/B](__ms) \ 
    if((unsigned long) (F_CPU/1000.0 * __ms) != F_CPU/1000.0 * __ms)\ 
          __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1000.0 * __ms)+1);\ 
    else __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1000.0 * __ms)) 
  #define [B]Delay_s[/B](__s) \ 
    if((unsigned long) (F_CPU/1.0 * __s) != F_CPU/1.0 * __s)\ 
          __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1.0 * __s)+1);\ 
    else __builtin_avr_delay_cycles((unsigned long) ( F_CPU/1.0 * __s))

and then...

...
      lcd_e_port_high();                              // Read High Nibble First 
      [B]Delay_ns[/B](500); 
 
      data=lcd_db4_pin_get() << 4 | lcd_db5_pin_get() << 5 | 
           lcd_db6_pin_get() << 6 | lcd_db7_pin_get() << 7; 
 
      lcd_e_port_low(); 
      [B]Delay_ns[/B](500); 
 
      lcd_e_port_high();                              // Read Low Nibble 
      [B]Delay_ns[/B](500); 
 
      data|=lcd_db4_pin_get() << 0 | lcd_db5_pin_get() << 1 | 
            lcd_db6_pin_get() << 2 | lcd_db7_pin_get() << 3;

These are idle waiting loops. You prove the opposite of what you were trying to prove.

Are you an engineer or a ball buster?

the point I'm trying to make here is that it is better to learn some good practices early.

So far the code posted is excellent. You biatch about "bad programming habits" in unwritten code based on false assumptions yet your pretended excellence at coding is nowhere to be seen.

[eclipse]

Put some ads on the forum, get some money rolling, plus member donations which can go into an active projects piggy bank as a appreciation/beer money for the author/contributors is other way

[Teleno]

I don't mean to sound offensive but frankly that is pretty crappy programming. Let's take an example; for LCD use it's rather nice to use a ready-made library (such as http://community.atmel.com/projects/hd44780-library ) and focus efforts on the actual detector implementation. Programming is not necessarily as much about writing code to bit-bang displays and toggle IOs at the same time, as it is about avoiding writing all those lines with a library like that, for example.

Using this kind of library which uses no hardware timers but counter based delay loops, the cpu's practically wasting time in those necessary delays to run a hd44780 display, just decrementing and jumping. If we want to do similar counter-delay based debouncing for switches, that's all right too. All these delays will be skipped by a timer ovf interrupt, and not hold back the actual detector timing itself. The detector can run however it wants regardless of how we time the LCD, button debouncing, and bleepy beeps for the speaker.

We can also write a cute little menu system that just jumps from one menu loop to another in order to update different parameters for ground testing. If we want to add some co-dependency into parameters, even complex kind, it's a breeze compared to having to think where it'll be squeezed or whether those parameters will be saved in some temp registers while waiting for the next pause in processing. With a library like that, we can just tell the thing to write a string of text on the screen. How's that for convenience?

Look, the point I'm trying to make here is that it is better to learn some good practices early. It makes reusing other people's code, and your own, much easier (or in this case possible at all). If after all this it still sounds like a damn good idea to be writing a cycle critical timing system that intersperses one character at a time display updates on the LCD and handling any kind of user interface together with the odd chance of getting a mosfet-burning halt, I'm frankly at a loss of words. And that burning mosfet won't be an example of how unreliable microcontrollers are, it'll be an example of how poor programming burns fingers.

Yep. I'll write something up this week/end, if I have the time, but frankly it's not really motivating - If the above doesn't sound convincing, a decent example on why people are generally taught to do things the way they are done, I'm not sure what it takes.

If everything that thing ever needs to do is just put out some pulses, read an ADC, and write a few numbers on the screen, it'll be faster to just write a chain of delay_us(x) and port=stuff. But if there is a menu that spells out delay names and numbers, and does button toggled stuff, it'll be slower to implement and a pain in the *** to decide to change anything, _anything_, later on - let alone debug the thing. The whole point of replacing a shoddy RC timer with a shoddy program eludes the point of adding a microcontroller.

Still that offer for beers is open if you (or another geotech-ite) ever end up here on the cold side of hell. The soil's still frozen.

I've seen about 300 lines of self-serving crap but not a single line of code from Mr. THE Engineer. If the proof is in the pudding then you're candidate for a Pulitzer price.

[ivconic]

I don't mean to sound offensive but frankly that is pretty crappy programming. Let's take an example; for LCD use it's rather nice to use a ready-made library (such as http://community.atmel.com/projects/hd44780-library ) and focus efforts on the actual detector implementation. Programming is not necessarily as much about writing code to bit-bang displays and toggle IOs at the same time, as it is about avoiding writing all those lines with a library like that, for example.

Using this kind of library which uses no hardware timers but counter based delay loops, the cpu's practically wasting time in those necessary delays to run a hd44780 display, just decrementing and jumping. If we want to do similar counter-delay based debouncing for switches, that's all right too. All these delays will be skipped by a timer ovf interrupt, and not hold back the actual detector timing itself. The detector can run however it wants regardless of how we time the LCD, button debouncing, and bleepy beeps for the speaker.

We can also write a cute little menu system that just jumps from one menu loop to another in order to update different parameters for ground testing. If we want to add some co-dependency into parameters, even complex kind, it's a breeze compared to having to think where it'll be squeezed or whether those parameters will be saved in some temp registers while waiting for the next pause in processing. With a library like that, we can just tell the thing to write a string of text on the screen. How's that for convenience?

Look, the point I'm trying to make here is that it is better to learn some good practices early. It makes reusing other people's code, and your own, much easier (or in this case possible at all). If after all this it still sounds like a damn good idea to be writing a cycle critical timing system that intersperses one character at a time display updates on the LCD and handling any kind of user interface together with the odd chance of getting a mosfet-burning halt, I'm frankly at a loss of words. And that burning mosfet won't be an example of how unreliable microcontrollers are, it'll be an example of how poor programming burns fingers.

Yep. I'll write something up this week/end, if I have the time, but frankly it's not really motivating - If the above doesn't sound convincing, a decent example on why people are generally taught to do things the way they are done, I'm not sure what it takes.

If everything that thing ever needs to do is just put out some pulses, read an ADC, and write a few numbers on the screen, it'll be faster to just write a chain of delay_us(x) and port=stuff. But if there is a menu that spells out delay names and numbers, and does button toggled stuff, it'll be slower to implement and a pain in the *** to decide to change anything, _anything_, later on - let alone debug the thing. The whole point of replacing a shoddy RC timer with a shoddy program eludes the point of adding a microcontroller.

Still that offer for beers is open if you (or another geotech-ite) ever end up here on the cold side of hell. The soil's still frozen.

Makes a lot of sense.
Sort of "PI_MD_timings" library is hell of idea!
Actually whole of the code for "PI with all possible jingle&bells" can be written in few libraries.
Sort of "modular" programming. The most advanced one. And fastest one too. "Objective" actually.
Some of critical functions maybe have to be written in assembly, but if put in separate library: no sweat for future implementation.
Just exactly as it is done with LCD (and many other) existing libraries.
...
"...but frankly it's not really motivating..."

Don't know what to say?
Main motif in todays world is money.
How to make money from open project?
Write code, put it on Github and project various "shields" which will be later sold on market.
Contact Adafruit and expose them your work.
They will produce, you will get your share.
Second motif?
Enthusiasm and great "heil" and glory among us here, of course!

[Davor]

... and as soon as it thaws, cohorts oh mosquitoes fly out...

[ODM]

I don't mean to sound offensive but frankly that is pretty crappy programming. Let's take an example; for LCD use it's rather nice to use a ready-made library (such as http://community.atmel.com/projects/hd44780-library ) and focus efforts on the actual detector implementation. Programming is not necessarily as much about writing code to bit-bang displays and toggle IOs at the same time, as it is about avoiding writing all those lines with a library like that, for example.

Using this kind of library which uses no hardware timers but counter based delay loops, the cpu's practically wasting time in those necessary delays to run a hd44780 display, just decrementing and jumping. If we want to do similar counter-delay based debouncing for switches, that's all right too. All these delays will be skipped by a timer ovf interrupt, and not hold back the actual detector timing itself. The detector can run however it wants regardless of how we time the LCD, button debouncing, and bleepy beeps for the speaker.

We can also write a cute little menu system that just jumps from one menu loop to another in order to update different parameters for ground testing. If we want to add some co-dependency into parameters, even complex kind, it's a breeze compared to having to think where it'll be squeezed or whether those parameters will be saved in some temp registers while waiting for the next pause in processing. With a library like that, we can just tell the thing to write a string of text on the screen. How's that for convenience?

Look, the point I'm trying to make here is that it is better to learn some good practices early. It makes reusing other people's code, and your own, much easier (or in this case possible at all). If after all this it still sounds like a damn good idea to be writing a cycle critical timing system that intersperses one character at a time display updates on the LCD and handling any kind of user interface together with the odd chance of getting a mosfet-burning halt, I'm frankly at a loss of words. And that burning mosfet won't be an example of how unreliable microcontrollers are, it'll be an example of how poor programming burns fingers.

Yep. I'll write something up this week/end, if I have the time, but frankly it's not really motivating - If the above doesn't sound convincing, a decent example on why people are generally taught to do things the way they are done, I'm not sure what it takes.

If everything that thing ever needs to do is just put out some pulses, read an ADC, and write a few numbers on the screen, it'll be faster to just write a chain of delay_us(x) and port=stuff. But if there is a menu that spells out delay names and numbers, and does button toggled stuff, it'll be slower to implement and a pain in the *** to decide to change anything, _anything_, later on - let alone debug the thing. The whole point of replacing a shoddy RC timer with a shoddy program eludes the point of adding a microcontroller.

Still that offer for beers is open if you (or another geotech-ite) ever end up here on the cold side of hell. The soil's still frozen.