I have a problem with ATtiny: the blink code seems to slow down when a serial device is connected (physical pins 2 and 3, RX & TX) and the Serial.begin (9600); is in the setup(). In fact, here is the code:

Code:

int led = 13;

void setup() {               
  Serial.begin (9600);
  pinMode(led, OUTPUT);     
}

void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

The LED blinks about 3 times slower than expected. But If I either disconnect the serial device, or leave it connected but comment out the Serial.begin, then the blinking rate is OK. If that matters, the ATtiny 4313 is running on two AAA batteries at 1 MHz (8 MHz internal oscillator, internally divided). I don't have this problem with Nano or Pro Mini. I have seen posts related to problems with software serial on tinys, and with serial speeds above 9600 at 1 MHz. None of that seems to apply here, does it?

That's it! Thanks hiduino. And thanks Coding for the tiny cores update!

I have run into a problem trying to declare a pin as INPUT_PULLUP - the following compiles fine on Nano or Pro Mini, but throws 'INPUT_PULLUP' was not declared in this scope when compiled for ATtiny 4313:

Code:

pinMode (4, INPUT_PULLUP)

Other modes (INPUT, OUTPUT) compile fine. Trying pinMode (4, 2) gets the code compiled, but the code does not seem to work properly. Looking at the datasheet, ATtiny 4313 seems to have the pull-up resistors the same way the 328p does...

I am using Arduino IDE 1.0.4 with avr-gcc updated from WinAVR2010, and with ATtiny cores from Arduino-Tiny

That was the problem - renamed vector. Now it works for me, too. Thanks HiDuino! (Took me a few days to gain control over burning fuses through ISP)

iotn4313  that comes with WinAVR20100110 has named registers differently from both the chip datasheet and from the so-far used nomenclature for other MCUs, 328p most notably; PCINT_A/B/D instead of PCINT0/1/2, WDCR-WDCSR, EIFR-GIFRand such... Extra bits in come registers - PCIE5, PCIF5 in GIMSK and GIFR... Some possible typos - BPDSE/BODSE... The iotn4313.h remains the same in avr-gcc 4.8, which makes me wonder about my view of the datasheet - i/o header relationship. I'll try to get in touch with gcc avr development crew to gain the insight.

I now have a problem turning the watchdog off on either the 4313 or the 328p, but I'll start a separate thread on the issue, as soon as I put a sample code together.

EDIT: Never mind the note on having problem turning the WDT off - the sample code from the datasheet works fine.

Something related to Internet Explorer is definitely broken. I am using IE10 on Win 7 x64, and since a few days ago I have the same problem as Tom Caprenter described above - I can browse forums fine anonimously, but if I log in - then I get only a blank page. Two computers at home exhibit exactly the same behavior, and I am not aware of any other web site or forum with this problem.

I have installed Chrome to post this message and to reply to folks who have responded to my questions. Chrome accesses the Forum fine so far, but I'd go back to IE if I could.

The following code works on Nano and Pro Mini, but not on bare-bones Attiny4313 with LED attached to pin 16 (D13). Can anyone see why? The LED on 4313 comes on and never turns off. Can anyone try it on any other tiny? I should mention that the Samples => Blink code works fine on 4313.

The code  below that I have the problem with is essentially "blink", except that the delay has been replaced by the watchdog timer, which toggles the state of the LED on every time-out, when the interrupt service routine is called.

To make the code work across the MCUs, I have renamed the MCUR to MCUSR and WDTCR to WDTCSR in iotn4313.h I hope that did not affect the functionality...

Code:

byte LED = 13;
boolean LEDon = true;

void setup()
{
   pinMode (LED, OUTPUT);
   digitalWrite (LED, LEDon);

   // Set up and turn on the watchdog timer.
   MCUSR &= ~(1<<WDRF);               // Clear the watchdog reset flag
   WDTCSR |= (1<<WDCE) | (1<<WDE);    // Set WDE and WDCE - must be done in one operation; writing 1 to WDE starts the timed sequence
   WDTCSR = B00000110;                // Set the watchdog timeout prescaler to 1 s; must be done within 4 cycles from writing 1 to WDE
   WDTCSR |= _BV(WDIE);               // Enable the watchdog timer interrupt.
}



ISR(WDT_vect)   //  Watchdog Interrupt Service.
{
   LEDon = !LEDon;
   digitalWrite (LED, LEDon);
}



void loop()
{
}

With this code the LED on Nano or on Pro Mini blinks at 1 s rate, but on Attiny4313 it comes and stays on, never blinking.

I am using Arduino IDE 1.0.4 with WinAVR updated to the 20100110 (gcc-avr 4.3.3).

Thanks John!

The ATtiny4313 seems to be implemented in the most recent WinAVR (2010-01-10) - not the one that comes with Arduino, but the latest in SourceForge. io.h does contain

Code:

#elif defined (__AVR_ATtiny4313__)
#  include <avr/iotn4313.h>

and there is iotn3413.h The registers seem there, just some (vaguely straightforward) footwork needed to modify Nick's code and reference chip-appropriate registers.

Atmel has published app notes on migration from 2313 to 4313 here: http://www.atmel.com/Images/doc8283.pdf. From the first brief reading it seems straightforward, but there are a few things I don't completely understand, like brown-out register bits 0 and 1: the Atmel papers refer to them as BODSE and BODS, and AVR io file has them as BPDS and BPDSE. Typo or my superficial understanding?

Hey Nick,

After running your sleep code successfully on Pro Mini and Nano boards, I endeavored into ATtiny-based solution (4313 in particular). The code won't compile, complaining about WDTCSR, PCIFR, PCIF0, ..., BODS, BODSE not declared. Do you know where are these declared, so I can try updating for ATtiny 4313?

That did it! I successfully uploaded the blink example; the led attached to pin 16 is happily blinking. Thank you!

I am also trying to use Attiny4313 with Arduino IDE 1.0.4. After updating Winavr to 4.3.3 (avr-g++ --version confirms it), the first error message disappeared, but now I get: avrdude: AVR Part "attiny4313" not found., and a long Valid parts are: list. Indeed, there is no 4313 in the avrdude.conf. What did I miss?

Hi all,

Does anyone know if those 1602 LCD displays have a sleep mode?

I am using HD44780-based 16x2 LCD display with PCF8574-based I2C interface, on a battery-powered instrument, where battery life is important, and where the instrument should go low-power if the keypad is idle for 30 s. I am putting the Atmel chip to sleep with Nick's approach described here: http://arduino.cc/forum/index.php/topic,132947.0.html. The lcd.off() command turns the display off, but the LCD module then still consumes 5.5 mA, while the rest of the circuit, including Arduino, uses about 0.1 mA while in sleep.

The only thing that comes to mind is powering the LCD logic from an Arduino digital output. Arduino can digitalWrite LOW to the LCD power line before going to sleep, and HIGH on wakeup, but that would cause LCD startup, and would require initializing the LCD (?) on every wakeup... Does anyone have a better idea?

I hope you don't mind me jumping in - we manufacture microprocessor-based scoring machines and related fencing equipment, and I, of course, have an arduino-powered one in my club 

There are two issues here:

- Yes, there are 3 wires going to each fencer, but one (line C) has to be connected to the ground, as well as to the guard, and to the blade. That implies that there are only 2 wires per fencer to write to / read from. That's good news.

- It is a bit more complicated than treating a fencing "sword" as a switch. The rules (referenced above) require that, for foil for example, you register a touch only when the LB-LC resistance rises above 500 ohm, or you'll be detecting off-target touches quite often with dirty-but-idle foil tips (then you also look up the LB-RA resistance to decide if it is on-target - below 200 ohm - or off-target touch - remember, line A is lame, foil fencer's conductive vest). Different resistances play similar role in epee and saber, both when detecting the touch, and, in epee, checking if it was on the fencing piste instead of the opponent's foot.

Here is my advice. If you want to follow the rules, you might be better off connecting both A and B lines to analog ports, with voltage dividers, so you can detect grounding at either line, and get anti-blocking feature (detecting valid touch in foil even when the opponent touches his foil to the lame, which used to ground lames in the past.) Reading the analog values for each of the four lines (RA, RB, LA, LB), and setting up a look-up table of voltage brackets, will easily tell you which light(s) to turn on. You may also add decoupling capacitors to address the issues that sometimes arise from long wires (about 220 ft, not shielded, not twisted)...

I've classified the WiFi modules/shields into two categories: those with TCP/IP stack, and those without. Pros and cons:

• WITH TCP/IP stack: If the TCP/IP stack is on the WiFi module, you typically communicate with the module through a serial port, using simple and well doccumented AT commands. This is a good thing, since it keeps your Arduino safe from wifi hangups, given available serial port on Arduino (software or hardware serial made no difference in my tests). Also, the TCP/IP stack on the WiFi module means it does not have to be loaded into the Arduino, therefore the uploaded code, not pulling a WiFi library along, takes much less memory. Good examples are WIZnet wifi modules and shields based on it, like those by SainSmart and dfrobot. Another module is RowingNetworks RN-131 and 171, and shields based on those, like WiFly; the Rowing Networks got last year acquired by Microchip, and only the time will tell if Microchip will keep supporting these modules.
  Some modules in this class also have SPI port and connecting this way circumvents the module's TCP/IP stack so you get all the advantages of high-speed communication  and ability to mess up the reliability, like described in the next point 
• No TCP/IP stack on the WiFi module: means TCP/IP stack has to be provided to you in a form of an Arduino library (it seems that every WiFi module currently requires it's own library). Now you have a complete access to all aspects of the TCP/IP communication, for the expense of large memory demand on your arduino. Good examples are Microchip ZG2100 and MRF24WB0Mx modules and shields based on them, like AsyncLab WiShield and its clone Cu head. Here the problem is that Async labs closed the shop a few years ago and there is only a 3-years old library update by RuggedCircuits. In the meantine, module's manufacturer Microchip has updated the TCP/IP stack and is giving it out free, but there is non-trivial task of turning it into an Arduino library... These libraries have shown to be rather sensitive to timing issues, so adding anything to them without understanding the TCP/IP stack may make your WiFi shield's operation unreliable
• Shields with WiFi module + microprocessor: Those your arduino sees like the first kind above, but they are actually the second. The good example is the "official" arduino WiFi shield, which is reported as reliable, but is often out of stock (right now, for example ).

I personally prefer a communication module that communicates through UART, and those that have good industrial-strength tech support regarding the sensitive TCP/IP stack, so given the choice, I vote for the first kind.

To my experience, the major problem in making the Cu Shield to work is actually the router (or access point. I'll be reffering to it as "router"). Namely:

Physical Connection:
- the connection between the Cu Shield and arduino is mostly trivial; if you have Uno, it's just piggyback, and there is nothing not to work. If, like me, you have all the physically incompatible arduinos (I own Nano, 5V Mini Pro and Mega), connection is still simple - just 8 wires. Since wiring has been described in other places, let's assume you connected everything rigth (GND, +5V, SS, SCK, MISO, MOSI, pin 2, and pin 9).

Software:
Let's assume you are not using Mega. If so, download the WiShield library - the latest (ver 1.3.1) seems to be the one from Rugged Circuits, and it is compatible with Arduino IDE 1.0.x. The link to the library is at http://ruggedcircuits.com/html/yellowjacket.html, scroll down to Software... Unzip and save the library in your user-provided libraries folder (on my PC, it is at My Documents => Arduino => libraries

Test:
Start the Arduino IDE, and load the SimpleServer example (File => Examples => WiShield => SimpleServer. Now pay attention: set the IP Address to what you want for your WiShield. Provide router's SSID, and select the security model currently running on your router (none / WEP / WPA / WPA2 - "none" is the least secure, and WPA2 the most secure of the four); provide passphrase (if WPA/WPA2) or the key (if WEP). Upload and look at the LED on the WiShield. IT TAKES TIME! In my tests, it takes 3 - 7 seconds for the LED to light up for none or WEP security, and some 30 s for WPA or WPA2. If the LED is lit, open the web browser on the PC, and type in WiShield's IP address (the one you used in the Arduino sketch). If everything is OK, "Hello World!" will be displayed.

Troubleshooting:
You are reading this probably because the "Hello World" from the end of the previous paragraph did not come up, right . Well, let's do some simple checks:

• Did you think it would work right away so you have connected to your Arduino things other than WiShield? If so, disconnect everything other than WiShield. Check wiring.
• Make sure everything is at default - all eight wires where the manuals say they should go (yes, you may connect the reset too, but that is not necessary for these tests), LED jumper on WiShield in place, Int jumper in "Pin 2" position.
• Open Blink example (File => Examples => Basics => Blink). Change line 10

Code:

int led = 13;

to

Code:

int led = 9;

. Upload. LED on WiShield blinking? Yes? Good! You can breathe now, you did not burn $100 worth of gadgets Load back the SimpleServer example, and read back the first sentence from the top of the post - it is probably the router issue.[/li]

You think it's the router? Well, you mightvery well be right! First double-check all the router settings (are you by any chance running the WiFi isolation? Is the IP address you want for the WiShield in use? Have you reserved it for another device? Is the IP address in the router's allowed range? (My router defaults to 192.168.2.1 to 192.168.2.100; assigning 192.168.2.101 to WiShield won't work unles I change that default range). All that checked, go check http://asynclabs.com/forums/viewtopic.php?f=13&t=13, there is a list of access points verified to work with CU head's MRF24WB0Mx, and those that are verified not to work.

Jerry,

From the schematic at http://ruggedcircuits.com/AM040/am040.pdf, it seems that the Hibernate (pin 20) of the Microchip WiFi module IS connected to the Atmega328 onboard, and it seems it is connected to D8. Try something like:

Code:

    pinMode (8, OUTPUT);
    digitalWrite (8, HIGH);

to Hibernate the WiFi, and:

Code:

    digitalWrite (8, LOW);

to wake it up. Let us know how did the module behave.