next topic »

[Reply #105 on:]

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.

[Reply #106 on:]

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.

[Reply #107 on:]

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.

[Reply #108 on:]

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:

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:

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]

[Reply #109 on:]

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:

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.

[Reply #110 on:]

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.

[Reply #111 on:]

This

Code:

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.

[Reply #112 on:]

This

Code:

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"

[Reply #113 on:]

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.

[Reply #114 on:]

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!

[Reply #115 on:]

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.

[Reply #116 on:]

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

[Reply #117 on:]

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

[Reply #118 on:]

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.

[Reply #119 on:]

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?