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

smeezekitty:

gizmoDave:
#1 Yes Arduino power on the bread board vs voltage from the RC receiver on final install voltage is 3.8Vdc

The voltage can cause the clock to change quite significantly but 30% seems excessive. 10-15% is common of the voltage range of 1.7-5.

Would installing a transistor between VCC & Reset force the clock to run at the same on both voltages?

#2 ATtiny13 @4.8MHz boards.txt located at:
C:\arduino-1.0.1-windows\arduino-1.0.1\hardware\arduino

attiny13at4.name=ATtiny13 @ 4.8MHz (internal 4.8 MHz clock)

attiny13at4.bootloader.low_fuses=0x69
attiny13at4.bootloader.high_fuses=0xff
attiny13at4.upload.maximum_size=1024
attiny13at4.build.mcu=attiny13
attiny13at4.build.f_cpu=600000
attiny13at4.build.core=core13

FWIW This has the clock/8 fuse set so it is running at 600KHz and not 4.8MHz.

Thanks, I will look up the proper fuse setting for the 4.8MHz setting

gizmoDave:
Would installing a transistor between VCC & Reset force the clock to run at the same on both voltages?

???

Thanks, I will look up the proper fuse setting for the 4.8MHz setting

http://www.engbedded.com/fusecalc/

smeezekitty:

gizmoDave:
Would installing a transistor between VCC & Reset force the clock to run at the same on both voltages?

???

Just asking as a light set I purchased using an ATtiny13 has a component resembling a resistor (SMD 0603 style ) with code E0l or E01 installed between VCC & reset pins. That number seems to belong to a transistor but my electronics searching often turn up bum results.

Thanks, I will look up the proper fuse setting for the 4.8MHz setting

AVR® Fuse Calculator – The Engbedded Blog

Thanks I will check out the link

Actually that is a resistor.
Some microcontrolers experience spurious resets without an external pull up resistor.
If it randomly resets, try a pull of resistor between 2k and 68k.

John, I changed the low fuse to 7A and now the timing is relatively close for both 9.6 MHz and 4.8MHz; it takes only 7 sec for a 10 sec delay to finish (approx 40% fast). The analogRead is still exhibiting the same end-biased behavior as before; the read goes from 0-1023 in approximately 25% of the rotation of the POT.

In an article on Instructables (Make an Attiny13 based IR proximity sensor for $2.42) the author says that you need the command:

analogReference(0);//analogread won't work on Atiny13 w/o this line. Won't work on others WITH it prob'ly.

The article references your core13 but I'm not sure how since the analogReference command is not supported in your core. I appreciate your interest in this platform. Let me know if there is anything else I can test.

Thanks, Mark

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

Here is the sketch that generates the error during verification

int duration;

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

void loop()
{
  duration = pulseIn(PB2, HIGH);
  digitalWrite(PB0, LOW);
  if (duration < 1300)
  {
    digitalWrite(PB0, HIGH);
  }
}

malukens:
John, I changed the low fuse to 7A and now the timing is relatively close for both 9.6 MHz and 4.8MHz; it takes only 7 sec for a 10 sec delay to finish (approx 40% fast).

The delay being spotty is a well know problem.
I will try to find a small solution but for now you can use the millis() wait loop work around if you can afford a bit more flash.

The analogRead is still exhibiting the same end-biased behavior as before; the read goes from 0-1023 in approximately 25% of the rotation of the POT.

I will check it out soon (not sure when I will get to it though).

In an article on Instructables (Make an Attiny13 based IR proximity sensor for $2.42) the author says that you need the command:

analogReference(0);//analogread won't work on Atiny13 w/o this line. Won't work on others WITH it prob'ly.

analogReference is just a stub so I think this would just increase code size with no other effect.

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

Here is the sketch that generates the error during verification

int duration;

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

void loop()
{
  duration = pulseIn(PB2, HIGH);
  digitalWrite(PB0, LOW);
  if (duration < 1300)
  {
    digitalWrite(PB0, HIGH);
  }
}

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.

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.