next topic »

[Reply #15 on:]

spi lib doesnt work with the 84

Does it need to?  Who's using SPI with an 84 processor?  Please post if you're using SPI with an 84 processor.

[Reply #16 on:]

im using it to send out to shift registers , but I found it easier to just bitbang pins manually (not digitalWrite) and the speed difference is negligible and I can use any pins I want vs the USI needs to be on the same 2 pins as everything else the USI controls

if you need input, well thats a different ball  

[Reply #17 on:]

I set out to make a smaller core for the '84 processor and ended up with...

• An empty Sketch is 30 bytes less (332 vs 302)
• pinMode only is 44 bytes less (466 vs 422)
• digitalWrite only is 76 bytes less (522 vs 446)
• digitalRead only is 78 bytes less (512 vs 434)
• One of each is 122 bytes less (732 vs 610)
• analogWrite only is 166 bytes less (728 vs 562)
• All four functions is 42 bytes less (868 vs 826)
• Largish test Sketch that contains a mix of the four functions is 10 bytes larger (bad / confusing news)
• pinMode is approximately 16% faster
• digitalWrite is about 18% faster
• digitalRead is 23% to 25% faster
• analogWrite is about 22% faster
• A few fringe cases are considerably faster

In theory, this core is a bit more portable to other Tiny processors than the standard core.

I'm disappointed in the memory savings.  There are some changes that would probably make it bit smaller but the speed increase would diminish considerably.

Which is more important ... Faster or less memory?

[Reply #18 on:]

if you look at this link :
http://code.google.com/p/codalyze/wiki/CyzRgb
in the source code, they have an implementation of i2c master/slave using USI from tiny44 and tiny45.
Maybe it could be usefull for you to make wire library working on tiny.

[Reply #19 on:]

hm I am going to say memory because there is always the option to use an external clock and if one uses a oscillator package its only eating up one pin, adding memory not so easy ...

course in a perfect world, both!  ;D

[Reply #20 on:]

@Osgeld:

im using it to send out to shift registers , but I found it easier to just bitbang pins manually (not digitalWrite)

Would digital*Fast functions be useful to you?

@moustic:

Maybe it could be usefull for you to make wire library working on tiny.

Do you have a need for the Wire library to work on an ATtiny84 processor?  85 processor?  Any other tiny processor?

@Osgeld:

hm I am going to say memory because there is always the option to use an external clock and if one uses a oscillator package its only eating up one pin, adding memory not so easy ...

Good point.  Also, there seem to be more posts about "I'm out of memory" than "My application is too slow".  It seems that most "too slow" applications can be sped up using a different design.

course in a perfect world, both!  

Well, so far I've managed a bit of both.  

[Reply #21 on:]

I'm trying to have a I2C clock working with a tiny85.
I found this web site with this code.
I don't use it in arduino env, but I think It should be really easier if I could use arduino environement and librairies to develop on my tiny.

a great usage for tiny and i2c is to pilot an RGB led. (like BlinkM )

[Reply #22 on:]

Would digital*Fast functions be useful to you?

probably not enough to go out of your way for them, but if you want them I am not going to stop you

[Reply #23 on:]

I also have a version of the Arduino core files that work with many many chips including the tinys

http://www.arduino-avr.com

Mark

[Reply #24 on:]

including the tinys

The '84?  I don't see an entry in "pins_arduino.c" for it.

Have you tested tone / noTone on the '45?

[Reply #25 on:]

The second Arduino Tiny release is ready...
http://code.google.com/p/arduino-tiny/

Included is a "highly compatible" core for the ATtiny84, ATtiny45, and ATtiny85 processors: most of the functions are very similar or identical to the 0019 core.

New Features...

• Tiny Debug Serial has been added.  This is a small, very accurate, write only "software serial".  Obviously, it can be used for any serial communications but the intended purpose is to replace Serial for debugging.  Three baud rates are supported: 9600, 38400, and 115200 at two processor speeds: 8 MHz and 1 MHz.  The baud rate must be a constant: "Serial.begin(9600);" is OK; "Serial.begin(userselectedbaud);" is not.  Different combinations of baud rate and processor speed will produce different compile sizes.  If you're concerned with size, stick with 38400.  If you're concerned that the processor's clock is not accurate, stick with 9600.  On the '84 processor, the Serial transmit pin is PB0 / pin 0.  On the x5 processor, the Serial transmit pin is PB3 / pin 3.  Basically, the transmit pin is the first I/O pin in the upper-left corner.  If you'd like a baud / processor combination added please let me know.
• Three PWM pins are available for the x5 processor: two phase-correct and one fast.  This can be changed to one phase-correct and two fast with a compile switch in core_build_options.h.
• Pin assignment for the RESET pin.
• For the x5 processor, timer 1 is used for millis.  Timer 0 is available to the user or is used by tone / PWM.  Timer 1 is considerably different from the typical ATmega timers.  By making the more familiar timer 0 available to the user, the x5 processor should be much easier to use.  The timer assignments can be reversed through a compile switch in core_build_options.h.
• The core is now built over a "hardware veneer" that has made porting much simpler.
• There is a hardware veneer for the "user timer" (by default, timer 1 for the '84 processor and timer 0 for the x5 processor) that should make it easier to work with the timer.  For example, "UserTimer_SetToPowerup();" can be called to reset the user timer to power-up conditions; "UserTimer_ClockSelect( UserTimer_(Prescale_Value_8) );" can be called to set the clock prescale to 8.  The code is split between "UserTimer.h" and "core_timers.h".  If you find this veneer useful, please let me know.  I'll try to set aside some time to fill it out and document it.
• Tone makes use of all clock prescale values.  This adds some code but should make tone more accurate.
• Direct-to-hardware output is used on both tone timer output pins.  When output is to one of these pins, the sound quality is much better especially at 1 MHz processor speed.

Caveats...

• It's my understanding that delayMicroseconds does not work at 1 MHz processor speed.

Please take a moment to click a few checkboxes...
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1285276725
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1285316262
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1289721959

License...
GNU Lesser General Public License.

Comments, opinions, minor harassments, and success stories welcome.

[Reply #26 on:]

The next Arduino Tiny release is ready...
http://code.google.com/p/arduino-tiny/

Included is a "highly compatible" core for the ATtiny2313, ATtiny84, ATtiny45, and ATtiny85 processors: most of the functions are very similar or identical to the 0019 core.

Features for 2313 processor...

• All four PWM pins are supported.
• Pin assignment for the RESET pin.
• Both HardwareSerial (from the Arduino 0021 core) and TinyDebugSerial are available.  By default, Serial is an instance of HardwareSerial.  core_build_options.h includes a compile option to make Serial an instance of TinyDebugSerial instead.

Notes...

• TinyDebugSerial uses PA1 / pin 2.
• HardwareSerial is 342 to 498 bytes larger than TinyDebugSerial.
  

[Reply #27 on:]

You should use ISR for the interrupt service routines and not SIGNAL, because it is deprecated.

[Reply #28 on:]

Thank you for the comment!

The SIGNAL usage in HardwareSerial.cpp is very likely from when it was originally written (2006).  I suspect no one ever changed it simply because there wasn't much motivation.  Why change code that's working?

In regards to the Arduino Tiny core, the first goal was to make a "highly compatible" core.  To accomplish this goal, I tried to change as few things as possible; the code in HardwareSerial.cpp is almost identical to the 0021 version.

Oh, and I forgot to mention in the previous post...

Caveats

• In my testing, HardwareSerial did not work at baud rates above 9600 when the processor was running at 1 MHz.  This could be a problem with HardwareSerial, the fact that the oscillator was not tuned, or a bit of both.

[Reply #29 on:]

does this work with 16MHZ clocked tiny's?

[edit]in 22 it tosses up some errors about the delay function(s) not being set to use 16MHZ (or something, I will get details later) in 19 it came up with a bunch of compile errors due to serial, removing the serial functionality it will compile, but I have not exactly tested yet, 16MHZ attiny84 btw[/edit]