core13: An Arduino core for the Attiny13 *testers wanted*

smeezekitty:

gizmoDave:
testing pulseIn this morning with Ver1.16 and getting error that I think states there is an argument in wiring.h it can't process

C:\arduino-1.0.1-windows\arduino-1.0.1\hardware\arduino\cores\core13/wiring.h: In function 'void loop()':
C:\arduino-1.0.1-windows\arduino-1.0.1\hardware\arduino\cores\core13/wiring.h:76: error: too few arguments to function 'long unsigned int pulseIn(unsigned char, unsigned char, long unsigned int)'
SwitchRC_AUX:10: error: at this point in file

On core13, pulseIn requires a time out argument.
You could set this to 0xFFFFFFFF which is the maximum of a 32 bit number. This would set the time out to about 1.2hours.
Sorry for the inconvenience.

I have searched several C++ tutorials and numerous posts that refer to timeout but have found nothing that references timeout in relation to pulseIn

in this case, 'timeout' is a variable which you pass to pulseIn to say how long it should wait for a pulse to be detected before giving up.

The error "too few arguments to function" is generic and means that a function (in this case pulseIn) requires you to give it more values than you have.
For example:

void functionWithThreeArguments(int arg1, byte arg2, float arg3){
   //Whatever...
}
...
  functionWithThreeArguments(someVariable); //This is not valid as only 'arg1' is given a value, not the other two.
  functionWithThreeArguments(someVariable, aSecondVariable); //This is not valid as only 'arg1' and 'arg2' are given values, not the other.
  functionWithThreeArguments(someVariable, aSecondVariable, aThirdVariable); //This is valid as the compiler knows what to put in each of the three arguments. 
...

Ok I understand that as written the 3 variables must be provided, but are three really needed? Can I rewrite the line in wiring.h to only require one argument & accompanying variable? Does the variable have to be listed as a # define statement?
I read a couple of C++ tutorials over the weekend and generated more questions than answers.

You could but the time out parameter could be very useful to prevent the code from blocking for very long periods of time or infinity.

Time out was the one parameter I was going to try figure out how to keep.
Where can I find a good C++ for dummies type tutorial?
I am not opposed to learning a bit about programming but I don't have
a lot of free time to spend scrounging through the endless list of tutorials that my
search engine produces.

gizmoDave:
Where can I find a good C++ for dummies type tutorial?
I am not opposed to learning a bit about programming but I don't have
a lot of free time to spend scrounging through the endless list of tutorials that my
search engine produces.

Its easier said then done to find a good tutorial. Most people pick up the more slightly more advanced stuff by doing and learning.

Thats just sweet, someone asks a question and gets a non answer, what gives???
I am a user attempting to learn to use a product that is delivered with no standardized instructions. I have spent over 20 hours of time reading tutorials that do not explain how to use this product, Best I can find states there are many ways to code a function and that some are better than others.
I have managed to get Attiny 13A standalone to work, I have programmed a chip with the following and it does not work as expected.

int duration;

void setup()
{
  pinMode(PB5, INPUT);  
  pinMode(PB0, OUTPUT);
}

void loop()

{
  duration = pulseIn(PB5, HIGH, 0xFFF);
  digitalWrite(PB0, LOW);
  if (duration < 1500)
  {
    digitalWrite(PB0, HIGH);
  }
}

The MCU does not generate a change in the state of the output pin based on input from the radio control receiver signal pin.
I have verified that the RX is outputting a pulse width of 1500us at center with a span from 1048us low to 1952us high.
I have powered the MCU using RX power and separate power for the MCU and RX with no change.
The only way that the code generates a state change is by completely disconnecting the signal from the input pin.
I have altered if (duration < 1500) using values from 1 to 2000 with no change, I have substituted < for > and the input from the RX still produces no change, removing the signal input produces a reversed effect on the output pin.
I have attempted several different input and output pins with no change in results
I have no clue at this point if the problem is hardware, software, or operator related.

[/quote]
Its easier said then done to find a good tutorial. Most people pick up the more slightly more advanced stuff by doing and learning.

[/quote]

gizmoDave:
Thats just sweet, someone asks a question and gets a non answer, what gives???
I am a user attempting to learn to use a product that is delivered with no standardized instructions. I have spent over 20 hours of time reading tutorials that do not explain how to use this product, Best I can find states there are many ways to code a function and that some are better than others.

Settle down. Their are no standardized instructions because I suck at writing them.
Debugging embedded code is not an easy task. Especially time-critical code.
Ensure you are using a sufficient clock speed.
When working with uS, you want as much speed as you can get.
9600000 will give you 27uS granularity while 1200000 will only provide a lousy 213uS granularity.

There is also a high likely-hood of a core bug.
Having no serial support on the '13 makes this problem even harder.

Also, try this version of pulseIn

unsigned long pulseIn_new(unsigned char pin, unsigned char stat, unsigned long timeout){
	while(digitalRead(pin) != stat){if(micros() - st > timeout){return 0;}}
	unsigned long st = micros();
	while(digitalRead(pin) == stat){if(micros() - st > timeout){return micros()-st;}}
	return micros()-st;
}

Which may correct a possible bug.

The MCU does not generate a change in the state of the output pin based on input from the radio control receiver signal pin.
I have verified that the RX is outputting a pulse width of 1500us at center with a span from 1048us low to 1952us high.

Ok this is doable but should be easier at a higher clock rate.

I have powered the MCU using RX power and separate power for the MCU and RX with no change.

The power source should have little effect since this is most likely a software bug.

I have no clue at this point if the problem is hardware, software, or operator related.

Probably software with the possibility of a mixed issue.

Ensure you are using a sufficient clock speed.
When working with uS, you want as much speed as you can get.
9600000 will give you 27uS granularity while 1200000 will only provide a lousy 213uS granularity.

you mentioned in an earlier post the board was running slow so I attempted to start from scratch with ATTiny13 standalone
which is supposed to run faster "attiny13.build.f_cpu=9600000L" but I can not get Bootloader to run this board.txt file
error produced

avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13
***failed;
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0x3f
avrdude: verification error; content mismatch

Other boards.txt files load fine but are all set for lower clock speeds and may be contributing to the problem running my sketch.

This

attiny13at9m.name=ATtiny13 @ 9.6 Mhz
attiny13at9m.bootloader.low_fuses=0x7A
attiny13at9m.bootloader.high_fuses=0xff
attiny13at9m.upload.maximum_size=1024
attiny13at9m.build.mcu=attiny13
attiny13at9m.build.f_cpu=9600000
attiny13at9m.build.core=core13

should make it run at 9.6MHz. If this gives errors then I am at a loss.
It would be kind of nice if Arduino would develop something easier then boards.txt.

smeezekitty:
This

attiny13at9m.name=ATtiny13 @ 9.6 Mhz

attiny13at9m.bootloader.low_fuses=0x7A
attiny13at9m.bootloader.high_fuses=0xff
attiny13at9m.upload.maximum_size=1024
attiny13at9m.build.mcu=attiny13
attiny13at9m.build.f_cpu=9600000
attiny13at9m.build.core=core13



should make it run at 9.6MHz. If this gives errors then I am at a loss.
It would be kind of nice if Arduino would develop something easier then boards.txt.

That one loads fine.
Now I'm off to figure out "unsigned long pulseIn_new"

Now I'm off to figure out "unsigned long pulseIn_new"

Simply put it at the top of your source file and replace all uses of pulseIn with pulseIn_new.
The new version might fix a possible bug. If it works better I will merge it with the core in the next version.
Please understand this is prealpha software and in the early testing stages so tons of bugs is to be expected.

I'm really looking forward to try this new core, but how should I connect the attiny13 to the arduino? is there some kind of connection diagram out there? and do I need to use arduinoISP to program it, an arduino with the 328p installed(or not installed), or can I use a FTDI breakout.

If someone have the answer it would be great! :smiley:

hansibull:
but how should I connect the attiny13 to the arduino? is there some kind of connection diagram out there?

Wire it just like this. http://hlt.media.mit.edu/?p=1229 But ignore the instructions about installing the 45/85 core.

and do I need to use arduinoISP to program it

Yes.

, an arduino with the 328p installed(or not installed), or can I use a FTDI breakout.

Yes. Use an Arduino with the Atmega installed and the arduinoISP loaded. An FTDI board will not work since the attiny13 does not support serial.

Hi,
I just wanted to test your core13 sources on my platform here.
I run Ubuntu 12.10 with Arduino 1.0.1 and installed your version 16 (core13_016.zip).
As a programmer I use USBtiny and got that programmer into boards.txt.
It compiles well with no errors.

However, I get the following error from avrdude while uploading the blink sketch:

avrdude: Expected signature for ATtiny13 is 1E 90 07

  • Double check chip, or use -F to override this check.*

Do I have burn some fuses beforehand ?

When I run avrdude with 'avrdude -c usbtiny -p t2313' I get the following answer:

avrdude: Device signature = 0x1e910a
avrdude: safemode: Fuses OK

What does that 'device signature' mean and why is it different from the 'expected signature' ?

Thanks for your help.

Regards
AgeBee

An attiny2313 is not an attiny13. Thus their unique device signatures don't match.

AgeBee:
Hi,
I just wanted to test your core13 sources on my platform here.
I run Ubuntu 12.10 with Arduino 1.0.1 and installed your version 16 (core13_016.zip).
As a programmer I use USBtiny and got that programmer into boards.txt.
It compiles well with no errors.

However, I get the following error from avrdude while uploading the blink sketch:

avrdude: Expected signature for ATtiny13 is 1E 90 07

  • Double check chip, or use -F to override this check.*

"Tom Carpenter" is correct. The attiny2313 is not an attiny13.
Also, core13 will only work on 8 pin devices.
Google Code Archive - Long-term storage for Google Code Project Hosting. probably will work with an attiny2313.

Also I have been out of down and had two(!) computer failures so support and development is delayed.

Hello,

I've just started using the arduino and successfully uploaded the blinker to my attiny13a following:

and
http://hlt.media.mit.edu/?p=1229

I've ran into the default fuses problem and fixed it by "installing bootloader" in the IDE but now I have a question that wasn't answered around here:

Can you use all the pins on this device (the reset pin, too) without a bootloader?! (my reading from various forums says NO, not without setting the fuse so the pin is no longer RESET and needing a high-voltage programmer to reprogram the device)

Can you help me understand if and how this works?

mrares:
Can you use all the pins on this device (the reset pin, too) without a bootloader?! (my reading from various forums says NO, not without setting the fuse so the pin is no longer RESET and needing a high-voltage programmer to reprogram the device)

"Burn Bootloader" as far as ATtiny13 and other chips burned using a programmer are concerned, is a euphemism. There's no bootloader (and no need for one either) - all this Arduino IDE function does is to burn proper configuration fuses so the MCU operates using the right clock frequency and so your time-dependent programs, such as the LED blinker, work properly. There are plenty of other configuration variables set by the config fuses but the timing is probably most important from the practical stand point - most others are left on defaults.

You cannot use the Reset pin if you're planning to re-flash the MCU using an ICSP programmer. Unless you have a high-voltage programmer, just consider ATtiny13 a 5xI/O MCU - makes development easier.

Got it! Once reading the spec of the attiny13a it looks like with a bit of elbow grease and a 12V power supply one can reset the fuses off a chip with the help of an Uno and a custom sketch.

Is it possible to write the fuses from within the code on the chip? (eg: set the reset pin enabled or disabled from your sketch, say... on a spi command received)