Go Down

Topic: core13: An Arduino core for the Attiny13 *testers wanted* (Read 49970 times) previous topic - next topic

smeezekitty

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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

gizmoDave

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.

smeezekitty


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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

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.
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.
Code: [Select]

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
Code: [Select]
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]

smeezekitty




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
Code: [Select]

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.
Quote

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.
Quote

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.
Quote

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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

gizmoDave

Quote
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
Quote
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.

smeezekitty

This
Code: [Select]

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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

gizmoDave


This
Code: [Select]

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"

smeezekitty

Quote

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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

hansibull

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! :D

smeezekitty


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.
Quote

and do I need to use arduinoISP to program it

Yes.
Quote

, 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.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

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.


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

Tom Carpenter

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

smeezekitty

#118
Nov 22, 2012, 04:18 am Last Edit: Nov 22, 2012, 04:19 am by smeezekitty Reason: 1

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.
http://code.google.com/p/arduino-tiny/ probably will work with an attiny2313.

Also I have been out of down and had two(!) computer failures so support and development is delayed.
Avoid throwing electronics out as you or someone else might need them for parts or use.
Solid state rectifiers are the only REAL rectifiers.
Resistors for LEDS!

mrares

Hello,

I've just started using the arduino and successfully uploaded the blinker to my attiny13a following:
http://tekstop.wordpress.com/2011/12/30/programming-attiny13-using-arduino-isp-and-all-the-hacking-involved/
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?

Go Up