Show Posts
Pages: [1] 2 3 ... 5
1  Forum 2005-2010 (read only) / Syntax & Programs / Re: serial.write() in setup()? on: September 02, 2009, 12:10:54 am
My bad... turns out the radio transceiver was taking a little time to recover from sleeping to its awake state... and was not ready to receive the serial.write().  It shrugged it off...

Having the serial.write() in the loop() section meant when the radio finally woke up, the writes were happening.

Sorry Arduino for doubting yoU!
2  Forum 2005-2010 (read only) / Syntax & Programs / serial.write() in setup()? on: September 01, 2009, 11:34:41 pm
I've got a 0017 sketch that outputs to the UART (connected to a radio transceiver).  I just need a one-shot thing that reacts to a button press, and the last thing the sketch needs to do is serial.write().  So I'm thinking put the whole sketch in setup() and leave loop() empty.  But the serial.write doesn't work when it's coded in setup().  If I move the serial.write inside the loop() function it works.  Of course it loops too, so it gets written forever.

My question is, are there any constraints on what code can run in setup().  Like, are global interrupts turned off for that section?  

Is it normal that Serial.write() only works from loop() section?

Regards
Scott


3  Forum 2005-2010 (read only) / Interfacing / Re: initializing LCD library within setup() ? on: April 27, 2010, 04:30:55 pm
I was hunting for a home for this topic.  

Like so many things, microcontroller based products have some pretty tightly integrated hardware and software dependencies.

This is a perfect example.

I found the most responsive place is in the software development forum, it's byline includes the words "libraries"... and I think this is truly a bad library design issue.  

Technically this is not an interfacing issue, the library actually drives the module fine.

It's getting good traction over there...  consider the conversation shifted.
4  Forum 2005-2010 (read only) / Interfacing / initializing LCD library within setup() ? on: April 27, 2010, 10:51:31 am
Instead of this:

Code:
// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
// RS, E, D4, D5, D6, D7
LiquidCrystal lcd(53, 51, 41, 37, 39, 35);

setup() {
 // stuff...
 lcd.begin(24, 2);
 lcd.print("  Hello ");
}

loop() {
 // stuff..
 lcd.print (" Looping ");
}

How can I "prolong" and re-use the initializing of LCD hardware.  I'd like to do something like this:
Code:
// include the library code:
#include <LiquidCrystal.h>

setup() {
 // stuff...

 digitalWrite (LCDpower, HIGH);
 delay(2000);
 LiquidCrystal lcd(53, 51, 41, 37, 39, 35);  

 lcd.begin(24, 2);
 lcd.print("  Hello ");
}

loop() {
 // stuff..
 lcd.print (millis());
}

When I try, I get scope issues with lcd.print in the loop().

Is there a way to declare the lcd commands in loop() as "extern" or something?


The reason I'm doing this is sometimes I need to recycle power on the LCD because it gets garbled.  I've tried adding robustness to its power, cutting down noise,  etc and will continue on that front but in the meantime I need to hard boot the LCD without resetting the Arduino.

Thanks!
5  Forum 2005-2010 (read only) / Development / Re: initializing LCD library within setup() ? on: April 29, 2010, 02:57:25 pm
To close this thread, I just found out from another friendly forum member that lcd.begin() also initializes the LCD.   And I just tried it, no scope issues, etc...   Push a button and my garbled screen comes back to life the way it should.   Yeeaahhh!!

Thanks all
6  Forum 2005-2010 (read only) / Development / Re: initializing LCD library within setup() ? on: April 27, 2010, 04:06:44 pm
Quote
Whether creating a local variable performs some hardware initialization or not, I don't know. Since there is only one piece of hardware, if there is any hardware initialization going on, it is going to affect that piece of hardware.

Yes, the creation of the variable is what sends an initialization string to the LCD.

I'm counting on the fact it's the same hardware and that it doesn't care which instance of a variable caused it to initialize...  It just gets told stuff.

Like I said, this is working around some things, one is compiler scope, and the other is a questionable practice of having a variable declaration "side effect" of running code.  


7  Forum 2005-2010 (read only) / Development / Re: initializing LCD library within setup() ? on: April 27, 2010, 03:57:06 pm
The real problem is I have a long unshielded ribbon cable connection between Arduino board and LCD module in an automotive environment.  The LCD module was REALLY flaky until I added some cap's on the LCD end of that ribbon.  And using PWM to control its 12V sourced LED backlight driven at 150mA also made for some nice inductive coupling with the data lines in the same ribbon, causing jitters that showed up regularly as double printing of some characters on the LCD..  I could change "brightness" (duty cycle) and drive out the problem more dramatically, or scale it back.  Near full dim, or full brightness the problem is less severe.  Anything that is near square wave could make it go wonkers much more predictably.  So I changed out the LED resistors for ones more friendly with 5V and send 5V up the line instead of 12V, still using PWM near those data lines but much  better now.   Every once in a while it seems a glitch on the power line hits the LCD hard and it goes into goo-goo land (splatter all over the screen and subsequent prints show in alien patterns).  

Yes, rebooting the LCD is software patch that will get me by until I make and prove out a better connection between the two.

Things I need to do in the hardware area of the problem:
- make a low pass filter by adding a resistor, not just add caps at the LCD, maybe a couple hundred Ohms or so current limiting resistor in series with the power line going to LCD.

- get a better cable that shields the data lines from the LCD backlight power running up the same cable, and the environment.

It's interesting to note that the Arduino Mega board (providing my power for all LCD needs) keeps on running fine through all these events, so if there's a glitch on the Vcc 5 on the board, it's hitting the ATmega just the same but it survives.   ... so I'm pretty sure the problem is introduced between the Arduino and the LCD by virtue of that cable and the environment.

The concept of having an ability to reboot or control LCD power, and regenerate its display without having to reboot Arduino should not be foreign.  Somewhere in here is bad software modularity / design in the library.


8  Forum 2005-2010 (read only) / Development / Re: initializing LCD library within setup() ? on: April 27, 2010, 01:59:39 pm
I like stubborn.  I also like the idea of try in both places.

Maybe the trick is to "over-declare" the lcd stuff... like this.
This code compiles, but I wonder if it works "as expected" (not near my project to try it out now).

Code:
// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
// RS, E, D4, D5, D6, D7
LiquidCrystal lcd(53, 51, 41, 37, 39, 35);

void reinitializeLCD() {
  LiquidCrystal lcd(53, 51, 41, 37, 39, 35);
  lcd.begin(24, 2);
  lcd.setCursor(0, 0);
  lcd.print("reinitialized");
}
  
void padprint ( int num) {
  lcd.print(" ");
  lcd.print(num);
  lcd.print(" ");
}

void setup() {
   // set up the LCD's number of columns and rows:
  lcd.begin(24, 2);
  lcd.setCursor(0, 0);
  lcd.print("Hello voild");
  padprint(200);
}

void loop() {
  delay(4000);
  reinitializeLCD();
  lcd.print(millis());
}

If that actually works, I'm sad that I had to "work the system" to make it happen... .  But I'd still be happy if this will allow normal lcd prints and I can re-boot the LCD without having to bring the Arduino down to do it.
9  Forum 2005-2010 (read only) / Development / Re: initializing LCD library within setup() ? on: April 27, 2010, 01:44:10 pm
It's this line that executes (initializes the LCD to 4bit):

LiquidCrystal lcd(53, 51, 41, 37, 39, 35);

And it happens before setup().

I WISH lcd.begin() was the first thing that talked to the LCD.
You'd think that would be a more normal way to go.... alas, it's not.

Although this code compiles:
Code:
// include the library code:
#include <LiquidCrystal.h>

setup() {
 // stuff...

 LiquidCrystal lcd(53, 51, 41, 37, 39, 35);

 lcd.begin(24, 2);
 lcd.print("  Hello ");
}

loop() {
}

I'm not really sure if the LiquidCrystal lcd(53, 51, 41, 37, 39, 35) is actually inserted in that spot, inline with the code, or if it inserts before setup().  

The real problem is one of scope.  If I put LiquidCrystal lcd(53, 51, 41, 37, 39, 35) in the body of loop() I speculate I can use lcd commands from inside loop() too!  But when I call a function and it uses lcd commands, the compiler will again complain about scope.

I think the real fix here is to make lcd.begin() be the thing that does the initialization, not LiquidCrystal lcd(53, 51, 41, 37, 39, 35);

This way, we leave the global declaration of the liquidCrystal and just use lcd.begin() again in whatever routine feels like it needs to re-initialize the LCD.  

So, I guess I'm looking for a workaround until this can be fixed, something that will trick the scope gods in the compiler.  Or expose an access point into the LiquidCrystal lcd(53, 51, 41, 37, 39, 35) routine so I can call it from wherever it resides, and return from it.

I don't want to have to write my own init routine, that wheel has been invented already in the library, I just want to use it more than once per boot cycle of the Arduino!




10  Forum 2005-2010 (read only) / Development / initializing LCD library within setup() ? on: April 27, 2010, 12:45:39 pm
The reason I'm asking this is that sometimes I need to recycle power on just the LCD module because it gets a glitch and garbles.  I've tried adding robustness to its power source, cutting down on noise issues,  etc .. (and will continue on that front) but in the meantime I need to hard boot the LCD without resetting the Arduino.  

The way the LCD library works is that initialization of the module happens before setup();  I need to re-initialize the LCD module, by cycling its power (using a digital pin), from inside setup() or perhaps even loop();

So, instead of this:
Code:
// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
// RS, E, D4, D5, D6, D7
LiquidCrystal lcd(53, 51, 41, 37, 39, 35);

setup() {
 // stuff...
 lcd.begin(24, 2);
 lcd.print("  Hello ");
}

loop() {
 // stuff..
 lcd.print (" Looping ");
}


I need to "prolong" initializing of LCD hardware, and re-use it.  I'd like to do something like this:

Code:
// include the library code:
#include <LiquidCrystal.h>

setup() {
 // stuff...

 digitalWrite (LCDpower, HIGH);
 delay(2000);
 LiquidCrystal lcd(53, 51, 41, 37, 39, 35);  

 lcd.begin(24, 2);
 lcd.print("  Hello ");
}

loop() {
 // stuff..
 lcd.print (millis());
}

But when I try this, I get compiler scope issues with lcd.print in the loop().

Is there a way to declare the lcd commands in loop() as "extern" or something?





Thanks!
11  Forum 2005-2010 (read only) / Development / Re: Notes on Windows, avrdude, libusb, WinAVR, and AVR on: October 25, 2009, 12:50:05 am
I tripped over this post because somebody said you need a different USB driver for AVRISPmkII to work from Arduino IDE for burning bootloaders.

I think what the OP is saying here is that Arduino can't use the AVRISPmkII to burn bootloaders, like it should, as it's offered in that menu, and if you do magic on usb drivers it might.  

I'm going to ask, can't I just grab the bootloader file from the Arduino directory structure and blast it into a virgin chip using the native programming environment called AVR Studio 4?  (Forget about trying to do it from Arduino IDE if it can't handle it, as it seems it can't).

And the answer is yes: http://www.arduino.cc/playground/Learning/Burn168

Not every nail needs a hammer, but it seems my problem is solved.

FWIW, I think the whole bootloader thing for Arduino is getting a little old.  It's just as easy to skip that design concept and just have a little wee programmer buried in the Arduino IDE that zaps straight code into the little darlings.


Regards
Scott

12  Forum 2005-2010 (read only) / Development / Re: safe way to prevent millis() wrap? on: November 04, 2009, 12:32:15 pm
I just found MsTimer2 in the playground, this should also work for my case.

#include <MsTimer2.h>

//declare a software reset function, begins execution at address 0
void(* resetFunc) (void) = 0;

setup()
{
 // quiesce chip features, change I/O pins, and enable power saves
 // setup external interrupt buttons (low level interrupt)
 // sleep (power down mode)
 // wakes up here
 ...
 // setup the way I need things
 // do my job (transmit information - one shot)

  MsTimer2::set(1000, resetFunc);  // set fuse length 1s on "reset bomb"
  MsTimer2::start(); // light the fuse

}

loop()
{
 // listen for echo (if serial.Available() > 0) and act on it

 // ..when the time is right (as a background process) MsTimer2 calls reset
}


Much cleaner.  Pretty much exactly what I want but better! I don't even have to check for zero, that runs as a background task.  

using millis method for my program makes it:
Binary sketch size: 3860 bytes (of a 30720 byte maximum)

using MsTimer2 instead makes it:
Binary sketch size: 4214 bytes (of a 30720 byte maximum)

10% bigger!  Sure this uses much more code space that twisting millis, but I'm only using around 14% of my 328P, so I'm not needing optimization at this juncture.

It turns out the safest way to prevent millis() from wrapping is not to play that game at all.  


13  Forum 2005-2010 (read only) / Development / Re: safe way to prevent millis() wrap? on: November 04, 2009, 11:03:27 am
This compiles:


// whack-a-millis

void setup(){
}

void loop() {

  extern volatile unsigned long timer0_millis ;
  cli();
  timer0_millis = 0 ;
  sei();

  // Groundhog Day

}


If arduino provided a general timer library, I'd use that instead.    I'd prefer to have a countdown timer and set its value in milliseconds, and then check it for zero.

C.Badly, "There's an abundance of ready-to-use one-shot code available in this thread and in the this forum and in the Playground and in the examples and on the internet at-large."   You're a very elusive poster... holding secrets back... if you know stuff, post stuff / links.   Save me from shooting my foot off!  Thanks.
14  Forum 2005-2010 (read only) / Development / Re: safe way to prevent millis() wrap? on: November 03, 2009, 06:35:13 pm
No access, scope!  Agh.  Extern solves that.


But

cli();
timer0_millis = 0;
sei();

makes it a little more atomic, don't you think?
15  Forum 2005-2010 (read only) / Development / Re: safe way to prevent millis() wrap? on: November 03, 2009, 03:43:50 pm
/quote  So what I don't understand is why you want to prevent the wrap in millis() vs the easier solution where you could just accommodate in your logic for the fact that it does wrap.  /endquote

Where's the sport in that?

I think you'll agree the code I just posted above is about the easiest thing that can be done here with a one-shot use of a time, that happens to hinge on using millis(), a timer is already built in arduino base.

I'll agree that I'm not using millis() for the purposes it was intended to be used.  But so what?  I don't need to have running uptime in my application.  If arduino provided a general timer library, I'd use that instead.    I'd prefer to have a countdown timer and set its value in milliseconds, and then check it for zero.

This is the closest thing to that.



Pages: [1] 2 3 ... 5