ATTiny84 and SoftwareSerial issue

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I am using SoftwareSerial on my ATTiny84. In the below code, I print "Hello world" via the TX pin, however it displays half wrong in the Serial Console:

 

?????world

 

Here is my code:

 

#include "SoftwareSerial/SoftwareSerial.h"
#include <avr/io.h>
#include <util/delay.h>

#define RX		PORTA1
#define TX		PORTA2

SoftwareSerial myserial(RX, TX);

void setup()
{	
	pinMode(RX, INPUT);
	pinMode(TX, OUTPUT);
	PORTA |= (1<<PORTA6);
	myserial.begin(9600);
}

void loop()
{
	PORTA = (1<<PORTA6); // high
	_delay_ms(500);
	PORTA &= ~(1<<PORTA6); // low
	_delay_ms(500);
	myserial.println("Hello world");
}

Here is my fuse settings:

 

SELFPRGEN = [ ]
RSTDISBL = [ ]
DWEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BODLEVEL = DISABLED
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_4MS

EXTENDED = 0xFF (valid)
HIGH = 0xDF (valid)
LOW = 0xD2 (valid)

Thank you in advance for the help.

This topic has a solution.

"When all else fails, read the directions"

Last Edited: Sat. Oct 18, 2014 - 05:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(This should, I believe, be in the Arduino forum.  Does a moderator agree?)

 

Well, you're running at 8 MHz (nominal) from the internal oscillator.  The internal oscillator is factory-calibrated at 3V and 25C to 8 MHz, +/- 10%.  Those are the specs, but chances are that any given device will actually be much closer, say +/- 2%.

 

Serial comms requires something like 2% to 3.5% accuracy, depending upon the conditions.  While your device might meet that requirement, it is for 3V and 25C.  What voltage are you running at?

 

The SoftwareSerial library will also result in some inaccuracy.  I haven't poured over the source code, but chances are that it will be at least as far off from a perfect 9600 baud as a hardware USART, which at 8 MHz is about 1% fast.  If you're running your t84 at 5V, the oscillator will run faster than at 3V, something like 0.7% faster.  If your t84 is already on the plus side of that +/- 10% calibration spec, it will likely all add up to '?????world'.

 

There are ways you can compensate for this.  The internal oscillator can be further calibrated by the user.  Lots of ways to do so.  Before you get into it though it would be a good idea to determine for sure whether or not this is the problem.

 

Do you have an oscilloscope?  A logic analyser?  Write a sketch which pumps out an endless stream of upper-case 'U'.  This shows up as an alternating stream of ones and zeros.  Put your oscilloscope on the TX pin and measure the frequency.  For 9600 baud you should see 4800 Hz.  You probably won't.  It will be faster or slower.  How much?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you have got "world" correct,    your 8MHz won't be far wrong!

 

I suspect that you just want to ensure that you get a good 'start bit',   so change your setup() to:

void setup()
{	
	pinMode(RX, INPUT);
	pinMode(TX, OUTPUT);
        digitalWrite(TX, HIGH);
        delay(10);                //steady high level before first start bit
	PORTA |= (1<<PORTA6);
	myserial.begin(9600);
}

Untested.     I guess that you don't have an oscilloscope.    To be honest,   I would think that the SoftSerial constructor() would have done the pinMode()s and delay().    i.e. you could have just said:

void setup()
{	
	DDRA |= (1<<PORTA6);        //output
        PORTA |= (1<<PORTA6);       //high
	myserial.begin(9600);
}

I guess you have an LED on PA6 pin.    I have no idea what digital# PA6 might be.    However,   you could look it up.     Then use pinMode() and digitalWrite() when you want to light your LED.

 

David.

Last Edited: Sat. Oct 18, 2014 - 08:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I tried david.prentice's suggestion but it made no difference. As guessed, PORTA6 is hooked up to an LED.

 

joeymorin suggested this should be in the Arduino forum, however I am not using an Arduino to program my Attiny, I am using an AVR Dragon. I am however using the Arduino libraries. I have used SoftwareSerial with my Attiny's and programmed them with the Arduino ISP in the past and never had an issue with serial. In my limited experience, when I get garbage in the Serial Monitor, its usually a timing issue e.g. Fuse settings. So I suspect it is these settings. I maybe wrong of course.

I don't have an oscilloscope or a A logic analyzer sad.

 

I did observe the following. When testing with a battery, my input voltage is 6v. The output voltage on PORTA6 (LED) reads 5.2v, but the LED is very dim (without a resistor!). This is odd as if the amps is too low. What should the amps be on an Attiny output pin?

 

 

 

To rule out the Software Serial library, is there another Serial library I can use.

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your first job is to buy proper resistors for your LEDs.     (unless they have internal ones)

 

Then you buy a proper 3.3V or 5V power supply.     Quite honestly,   this could just be an Arduino or a USBASP.

 

Yes,   you should read your fuses.    But if the SoftSerial is not working,   you can't see the output!

 

I suspect that everything would be better when you learn Ohms Law.   i.e. buy some resistors.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

 

I am sorry but I don't see how Ohms law and buying resistors helps solving my problem. The point I was making is that if I normally hooked up the LED directly to PORTA6 and no pull down resistor, the LED would of course burn out. But not in this case for some reason. The LED is dim with and without a resistor.

 

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I suspect that you just want to ensure that you get a good 'start bit',   so change your setup() to:
Were that the case, only the first "Hello world" would be broken.  Note that it is printed with each pass through loop().

 

PhillyNJ wrote:
I am however using the Arduino libraries
You seem to be using more than just the Arduino libraries.  You seem to be using at least the build environment as well if not the IDE.  I see setup() and loop(), and I don't see main().  I suggested the Arduino forum so that a) you might get more relevant responses, and b) others in your situation might more easily find a solution in the future.  In any event it makes no difference to me which forum this is in.

 

If you have an Uno, you can use it to (fairly accurately) measure the baud rate coming from your t84.  You could probably find an existing solution just by googling 'arduino frequency meter'.

 

You can also do a "poor man's" calibration.  Modify your existing "Hello world" sketch to write to the OSCCAL register with each pass, and also to print it's new value.  You will probably find that one or two ranges of values gives good results, and values lower or higher than that range will show corruption.  Choose a median value in one of the ranges.  That's your new calibration.  Now you can use it in setup().  Note that this value will be different at different voltages and temperatures.

 

#include "SoftwareSerial/SoftwareSerial.h"
#include <avr/io.h>
#include <util/delay.h>

#define RX		PORTA1
#define TX		PORTA2

SoftwareSerial myserial(RX, TX);

void setup()
{
    OSCCAL = 0;
    myserial.begin(9600);
}

}
void loop()
{
    _delay_ms(1);
    myserial.print("OSCCAL = ");
    myserial.println(OSCCAL);
    OSCCAL++;
}

Untested.

 

PhillyNJ wrote:
I did observe the following. When testing with a battery, my input voltage is 6v. The output voltage on PORTA6 (LED) reads 5.2v, but the LED is very dim (without a resistor!). This is odd as if the amps is too low. What should the amps be on an Attiny output pin?
You have possibly burned out the LED and/or the t84's output driver.  With no resistor and 6V Vcc, pin current could climb above 100 mA.  Why wouldn't you use a resistor?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I figured it out and it was right there in the code. I modified the code as follows and all is working:

 

#include "SoftwareSerial/SoftwareSerial.h"
#include <avr/io.h>
#include <util/delay.h>

#define RX		PORTA1
#define TX		PORTA2
#define LED		PORTB0

SoftwareSerial myserial(RX, TX);

void setup()
{	
	DDRA |= (1<<TX);
	DDRA &= ~(1<<RX);
	DDRB |= (1<<LED);	
	myserial.begin(9600);
}

void loop()
{
	PORTB = (1<<LED); // high
	_delay_ms(500);
	PORTB &= ~(1<<LED); // low
	_delay_ms(500);
	myserial.print("");
	myserial.println("U this is a long text world\n\r");
}

 

The issue I was having with the LED was I was not setting the Data direction correctly (ugh). With the above code, all is working. I moved the LED to PORTB0 and all works fine. Strange.

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest that you tidy up your sketch.   i.e.   I bet that the

SoftwareSerial myserial(RX, TX);

is expecting digital#  rather than a PORTA bit number.

I also guess that SoftwareSerial() constructor would set the pinMode() and quiescent TX level.

 

Yes,   you can write a regular statement like:

	PORTB &= ~(1<<LED); // low

but I would try to use the Arduino methods.

 

And you seriously want to sit down with a textbook on Ohms Law and a catalogue from the resistor shop.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David -

 

Thanks you for taking the time to help me out. I will take your advice into consideration. In regards to Ohms Law, I am struggling understand its relevance, as the cause of the issue was not setting the Data Direction.

"When all else fails, read the directions"

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Philly,

 

Irrespective of the data direction issue, operating an led without a current setting/limiting resistor is foolhardy. Please do not call into question the knowledge of engineers who have been working with these and other non-obvious components for decades.

 

LEDs are non-linear in their transfer function. As the diagram below illustrates, the higher the voltage across an led, the much higher the current that can flow... does. (The artist got the slope for the green led wrong)

 

So if there is no resistor between the led and the output pin of your Tiny84, then it is left to the Tiny84's internal circuitry to limit the current and the data sheet says...

 

It would be a real pity, but maybe a salutary lesson, if your Tiny84 dies for the lack of a 330 ohm resistor.

 

Best of luck.

 

Ross

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bugger...

I was about to look at the green LED as a microwave oscillator

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Ross for your help and guidance. As a note, I do have a pull down resistor on the LED. It was a bad idea to pull the resistor out to see if the LED was still dim (point taken!). 
 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you solved the '?????world' problem?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the issue was caused by not setting the Data Direction for the port in which the LED was being used. The result of not setting my DDR was:

  1. the LED being very dim
  2. the Serial output to be ?????world

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PhillyNJ wrote:
Yes, the issue was caused by not setting the Data Direction for the port in which the LED was being used.

Rubbish.  One cannot have anything to do with the other.

 

In your original code you were using:

#define RX		PORTA1
#define TX		PORTA2

SoftwareSerial myserial(RX, TX);
.
.
.
    pinMode(RX, INPUT);
    pinMode(TX, OUTPUT);
.
.
.
    myserial.begin(9600);

As mentioned by David, SoftwareSerial expects RX and TX to be Arduino digital pin numbers, not port bit numbers.  Furthermore, the library absolutely does set the data direction of RX and TX via pinMode().  It also makes use of digitalWrite() and other Arduino functions.

 

Are you using modified version of the Arduino libraries?  Have you identified which Arduino digital pin numbers map to which ports/bits on the t84?

 

Your second version of setup() does more than set the data direction of the LED's pin on PA6:

	DDRA |= (1<<TX);
	DDRA &= ~(1<<RX);
	DDRB |= (1<<LED);

You are also now explicitly setting the direction of TX and RX.

 

Unless:

  • you are using modified Arduino libraries
  • and/or PORTA maps to Arduino digital pins 0 through 7

... then this could not have been enough to solve your serial problem.

 

Either way, changing the direction of the LED's pin most assuredly had nothing to do with getting serial working.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

 

As mentioned by David, SoftwareSerial expects RX and TX to be Arduino digital pin numbers, not port bit numbers.  Furthermore, the library absolutely does set the data direction of RX and TX via pinMode().  It also makes use of digitalWrite() and other Arduino functions.

 

Are you using modified version of the Arduino libraries?

 

No, not directly. In my final code I am only using the SoftwareSerial code which does use Arduino Libraries. The rest of the code is AVR-C.

 

joeymorin wrote:

Have you identified which Arduino digital pin numbers map to which ports/bits on the t84?

 

Yes. From the data sheet, PORTA is ADC, which is what I am using for RX/TX. Is this correct?

 

Attiny84 Pinout

 

joeymorin wrote:

You are also now explicitly setting the direction of TX and RX.

 

Yes. I am setting TX in output and RX for input.

 

I have taken a pretty good betting on this thread. I have thick skin and I am here trying to learn, so I can take the beating knowing that I can learn by the beating smiley. If you want, I can put together video recreating the original issue. If I can't recreate it, than I will fall on the sword. However, if I can recreate the issue, maybe the posters on this thread can explain what (and why) I got it wrong. Fair? And again, its not to challenge all the years of experience, but rather learn from all the experience. I am all about learning.

 

 

"When all else fails, read the directions"

Last Edited: Sun. Oct 19, 2014 - 11:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PhillyNJ wrote:
No, not directly. In my final code I am only using the SoftwareSerial code which does use Arduino Libraries. The rest of the code is AVR-C.
If you're using SoftwareSerial unmodified, then you're also using at least wiring_digital.c.  Is it modified?  How exactly are you building your code?  Makefile?  Studio?

 

Quote:
Yes. From the data sheet, PORTA is ADC, which is what I am using for RX/TX. Is this correct?
Not quite.

 

By mappings I was referring to the way in which Arduino abstracts away the PORT/BIT definitions in favour of 'pin numbers'.  The Uno (ATmega328P) for example has the following mappings:

PIN     PORT/BIT
----------------
0       PORTD0
1       PORTD1
2       PORTD2
3       PORTD3
4       PORTD4
5       PORTD5
6       PORTD6
7       PORTD7

8       PORTB0
9       PORTB1
10      PORTB2
11      PORTB3
12      PORTB4
13      PORTB5

14      PORTC0
15      PORTC1
16      PORTC2
17      PORTC3
18      PORTC4
19      PORTC5

I haven't used the Arduino IDE for anything serious in quite some time, and I don't have the latest version.  I expect support for tinies still isn't native and requires adding new Arduino 'cores' to support them.  The supplementary cores I've used in the past are called Arduino-Tiny (http://code.google.com/p/arduino-tiny).  The pin mappings for the t84 are provided by pins_arduino.c for that core, and are:

// ATMEL ATTINY84 / ARDUINO
//
//                           +-\/-+
//                     VCC  1|    |14  GND
//             (D  0)  PB0  2|    |13  AREF (D 10)
//             (D  1)  PB1  3|    |12  PA1  (D  9) 
//                     PB3  4|    |11  PA2  (D  8) 
//  PWM  INT0  (D  2)  PB2  5|    |10  PA3  (D  7) 
//  PWM        (D  3)  PA7  6|    |9   PA4  (D  6) 
//  PWM        (D  4)  PA6  7|    |8   PA5  (D  5)        PWM
//                           +----+

So you see PA1 is mapped to Arduino digital pin 9, and PA2 is mapped to Arduino digital pin 8.  Mind you, this is specific to the Arduino-Tiny cores, and may be different with a different core which also supports the t84.

 

All of this is important because Arduino libraries like SoftwareSerial expect Arduino digital pin numbers, not PORT/BIT macros.  The fact that you report that your posted code works with RX defined as PORTA1 and TX as PORTA2 is suspicious.  PORTA1 is defined as 1 and PORTA2 is defined as 2, so passing those to the SoftwareSerial constructor would, in an unmodified library, specify pin 1 for RX and pin 2 for TX.  Those correspond to PB1 and PB2, not PA1 and PA2.

 

I can only conclude that you're using a different 'core', or that you are using modified versions of wiring_digital.c, or both.  Either way, it's hard to make any further comment until we know precisely what your build process is.

 

Quote:
I have taken pretty good betting on this thread. I have thick skin and I am here trying to learn, so I can take the beating knowing that I can learn by the beating smiley. If you want, I can put together video recreating the original issue. If I can't recreate it, than I will fall on the sword. However, if I can recreate the issue, maybe the posters on this thread can explain what (and why) I got it wrong. Fair? And again, its not to challenge all the years of experience, but rather learn from all the experience. I am all about learning.
I'd say you're taking things too personally.  You asked for help and got it.  How the help you got actually solved your problem is of importance because someone else may in the future read this thread looking for help and wonder, as we are now, why making an LED's GPIO pin (PB0, which is Arduino digital pin 0) an output could have any impact on the serial TX pin located clear across the other side of the chip.

 

If you'd like to post details concerning your use of the Arduino libraries, how those libraries reconcile pin-to-port-and-bit mapping, and how you are building your code, then we might all get a better understanding.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many thanks to Joey for actually looking up a 'typical third-party Tiny' Arduino core.

 

I still advise that you stick to Arduino digital# pin numbers and methods.

All the same,   I suspect that your PORTA1 statements would be referring to different pins.

 

Far from anyone wanting to beat someone up,   you have actually posed an interesting question !!!

 

If you reveal which 'third-party Tiny Arduino core' you are using,   I will try it for myself on a real Tiny84.

 

The beauty of the Arduino success lies in its 'official releases'.     I can run a sketch written by a Brazilian on hardware made by an Italian company in the middle of Outer Mongolia!

This means that the whole world can help each other.    And often through this forum.

 

Unfortunately,   the 'Tiny Arduino variants' are not official.     So worldwide help is more luck than judgement.

 

Please post a link to your third-party Tiny core.    

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OT... today I fired up the Iteaduino Tiny running the DigiSpark core on the Tiny85. At something like $6 it is an interesting trinket.

 

Ross

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This thread interested me.    So I installed Arduino-Tiny core from https://code.google.com/p/arduino-tiny/downloads/detail?name=arduino-tiny-0100-0018.zip

 

Then 'corrected' the initial sketch to use conventional Arduino pins and methods:

#include "SoftwareSerial.h"

#define RX		9    //PORTA1
#define TX		8    //PORTA2
#define LED             4    //PORTA6

SoftwareSerial myserial(RX, TX);

void setup()
{	
    pinMode(LED, OUTPUT);
    myserial.begin(9600);
}

void loop()
{
    digitalWrite(LED, HIGH);
    delay(500);
    digitalWrite(LED, LOW);
    delay(500);
    myserial.println("Hello world");
}

It ran perfectly.    Yes,   my Tiny84 is running on its internal 8MHz RC.    And being programmed and powered (3.3V) by my STK500.    It also works at 5.0V.     It does not work at 2.5V because my Brown-Out-Detector is set for 2.7V

 

David.

 

p.s.   My STK500 CTRL is on com7 and SPARE is on com3.     I have to tell the Arduino IDE that I am using Serial Port: COM7 for the "Upload with Programmer" to work.    Which means that I use a different Terminal for the 'Output'.

Does anyone know how I can set a different COM# for the Programmer and Output ?

 

Alternatively,   I could install a Bootloader.    And just use a single COM port.

Last Edited: Mon. Oct 20, 2014 - 10:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again to everyone for their help and guidance. I still need to digest all the responses, but I want to at least provide some answers about my configuration before I head to work today.

I am only using the Arduino Libraries because I needed an easy-to-use serial library e.g. SoftwareSerial. I installedvisual macro for Atmel Studio which installs all the Arduino core libraries. As the for compiler, I am using the built in compiler with Atmel Studio. 
I am curious, joeymorin suggests that PORTA1 for example is not what I think. He suggests, if I have read correctly, that the Arduino Core , or the third party library has remapped the ports. Also David advises the same. that is stick to the Arduino syntax. However, my code works when I use PORTA1, PORTA2 etc.. I think I need to put together a comprehensive example and post it.  

Its important to know that I wanted to use AVR-C code rather than using the Arduno Syntax. The Arduino code hides a lot of the details which I am interested in learning. So basically, I want to learn AVR low-level programming, moving and shifting bits in resistors. 

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well,    I am totally amazed that you could get any comms on PA1, PA2 pins when your SoftwareSerial(1, 2) is using PB1, PB2 pins.

 

By "visual macro" I assume that you mean the irritating SPAM provider when you start up AS6.2.

 

Now that I know what your third-party is,   I can see how they map Arduino digital# pins.

 

Yes,    you can mix and match Arduino libraries with regular C code.    But you need to do it consistently !

 

There is no 'remapping' of ports.     All Arduino code uses digital# and analog# to reference hardware pins.    It uses a software lookup table.     It is not like Cypress or NXP that do re-routing in hardware.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PhillyNJ wrote:

So basically, I want to learn AVR low-level programming, moving and shifting bits in resistors. 

 

 

laugh Actually it is more commonly thought that we move electrons in resistors and bits in registers, but hey let's start a new trend.

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried my posted sketch on my laptop (which has Visual Micro)

 

It uses exactly the same "Arduino-Tiny" core.    So it behaved exactly the same.   i.e. RX, TX on digital#8,9.

If I used your digital#1,2 then nothing happens.

 

Oh,   and the "Visual Micro" works quite smoothly.

 

I ended up by installing a bootloader in the Tiny84.    So I did not need the complication of the STK500.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

 

what happens if you try the following code that I posted that does not use the pin numbers but rather port #s?

 

#include "SoftwareSerial/SoftwareSerial.h"
#include <avr/io.h>
#include <util/delay.h>

#define RX		PORTA1
#define TX		PORTA2

SoftwareSerial myserial(RX, TX);

void setup()
{	
	DDRA |= (1<<TX);
	DDRA &= ~(1<<RX);
	
	myserial.begin(9600);
}

void loop()
{
	
	myserial.println("Hello World\n\r");
}

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have already told you that I tried your code.    I had to alter the #include ""SoftwareSerial/SoftwareSerial.h" to "SoftwareSerial.h"  in order to find "SoftwareSerial.h"

 

Joey has explained how Arduino constructors and methods use the digital#.  

 

On both my desktop and my laptop,    I was using "Arduino-Tiny" core from the link that I posted earlier.     Arduino-Tiny digital#8,9 correspond to physical PA1, PA2 pins.     It is not "official" but is the first result from Google,   and used by the most Tiny 'enthusiasts'.

 

You are probably using an uncommon third-party Tiny core.    Perhaps one from the list on my link page.

Perhaps your core maps digital#1,2 to PA1, PA2.    Perhaps it doesn't.

 

Please tell us which core and where you got it from.  e.g. post a link.

 

I think that you might now understand why the whole world goes wrong when you have unofficial third-party software !

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

 

You are probably using an uncommon third-party Tiny core.    Perhaps one from the list on my link page.

 

Yes, you are correct. I had some time to investigate. I am using an older version from http://arduiniana.org. The latest version of this library can always be found at http://arduiniana.org.

 

david.prentice wrote:

I think that you might now understand why the whole world goes wrong when you have unofficial third-party software !

 

I think so laugh. Thanks for all the help.

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see anything on that page that looks like a Tiny core.

 

Do you you mean this?:

http://arduiniana.org/2011/01/newsoftserial-11-beta/

 

That's the SoftwareSerial library, not a Tiny core.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My SoftwareSerial Library is very outdated - I cant remember when I downloaded it. And its not tiny core. If you want I can zip the .ccp and .h on which I am using.

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well,    I tried both of your links.     One had several messages.    The other had a regular Arduino library.

 

Nowhere could I find a Tiny core of any description.

 

Perhaps you have provided the wrong link(s) or perhaps I have to subscribe to the website.

 

I recommend that you download and install the "Arduino-Tiny" core.     But I have no experience of any of these 'third-party' cores.     Over the years,    several forum members seem to have used Tinys with unofficial third-party cores.     With luck,   we may hear from these members that have the Tiny experience.    They may know something better than "Arduino-Tiny".

 

All the same,    until Arduino makes anything official,     I would be very wary.     After all,    what advantage is there in using a Tiny84 instead of a Mega328P ?    Oh,   and if I was Italian,    I would never release anything for Tinys.

 

If you want something breadboardable,    there are plenty of cheap Chinese Pro-Mini clone boards.     And you end up with an Arduino project that can be reproduced reliably anywhere in the world.

 

If you are at the stage of creating a commercial pcb,    a MLF-32 is not much bigger than a MLF-20 or a TQFP-32 is about the same as a SOIC-14.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you David - This is slightly off topic, but if I didn't want to use the Arduino Libraries and needed a serial library, what would you recommend?

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A serial library or a software-serial library?

 

Actually, in either case, the "Projects" section here is stuffed full of them. If it's software-serial you are looking for look for contributions by user "danni" as that's usually a guarantee of quality.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You would be stuck in the Dark Ages.    Just like old times.    i.e.  you can read / port Atmel app notes like AVR294 and AVR303.    Or googling for "AVR Soft UART".      I like danni's Soft UART.

 

All of these will require work on your part.

 

Whereas Arduino libraries are pretty painless.

 

What I don't understand is why you can't say which Tiny core you are using.    And why you want to use different numbers in the constructor().

 

I would recommend that you use a 'common' third-party core like "Arduino-Tiny" and then obey the documentation.

 

But my main recommendation would be to choose a ATmega328P and then use 'official' Arduino libraries on your own custom hardware.

 

Having got a prototype working,    you might want some advice on building/selling your first 10000 units as cheaply as possible.

 

David.

 

p.s.   I have found a third-party that maps PA1 to digital#1.

// ATMEL ATTINY84 / ARDUINO
//
//                           +-\/-+
//                     VCC  1|    |14  GND
//             (D 10)  PB0  2|    |13  AREF (D  0)
//             (D  9)  PB1  3|    |12  PA1  (D  1) 
//                     PB3  4|    |11  PA2  (D  2) 
//  PWM  INT0  (D  8)  PB2  5|    |10  PA3  (D  3) 
//  PWM        (D  7)  PA7  6|    |9   PA4  (D  4) 
//  PWM        (D  6)  PA6  7|    |8   PA5  (D  5)        PWM
//                           +----+

and I found it from http://highlowtech.org/?p=1695

However,   I did not find the necessary core files to go with it.

 

So,    I have no doubt that 'my' example would work with your 'core' providing you #define TX 2 etc to correspond with that mapping scheme.

 

The whole thing looks a complete nightmare.     The beauty of Arduino digital# is that sketches and shields will be interchangeable.     If the scheme is random,    you have complete chaos!

Last Edited: Tue. Oct 21, 2014 - 08:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
and I found it from http://highlowtech.org/?p=1695

However,   I did not find the necessary core files to go with it.

There's a download link for ATtiny master.zip about a third of the way down the page.  Seems to be a very minimal core, with only boards.txt and pins_arduino.h files.

 

As you discovered:

// ATMEL ATTINY84 / ARDUINO
//
//                           +-\/-+
//                     VCC  1|    |14  GND
//             (D 10)  PB0  2|    |13  AREF (D  0)
//             (D  9)  PB1  3|    |12  PA1  (D  1) 
//                     PB3  4|    |11  PA2  (D  2) 
//  PWM  INT0  (D  8)  PB2  5|    |10  PA3  (D  3) 
//  PWM        (D  7)  PA7  6|    |9   PA4  (D  4) 
//  PWM        (D  6)  PA6  7|    |8   PA5  (D  5)        PWM
//                           +----+

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David - I believe I am using https://code.google.com/p/arduino-tiny/.

 

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But... that's the one I first mentioned two pages ago, the one where the mapping couldn't possibly work as you've described.

 

I'm not saying it's definitely not the one you're using, but I wonder how you came to that conclusion.  Did you find the 'cores' directory in which it is located?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes - the cores directory is located here C:\Sandbox\arduino-1.0.6\hardware\tiny\cores\tiny

 

Attiny Core

"When all else fails, read the directions"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The more I look,   the more horrified I become!

 

I thought that I had better replace my official Arduino v1.0.5 with the current v1.0.6

 

No,   it still has no official support for Tiny cores.

However,    I did discover https://github.com/TCWORLD/ATTinyCore which seem to have 'more' variants than the https://code.google.com/p/arduino-tiny/ that Joey and I know and love.

 

I suspect that this may account for the CRAZY INCONSISTENCY between the variants/tinyxxxx/pin_arduino.h digital# scheme.

It also shows that Googling "Arduino Tiny Core" or "Arduino ATtiny Core" get different results.

 

Perhaps an expert might comment on which variety of third-party people should go for.

 

Admittedly,   the ATTinyCore distribution seems to follow the current Arduino variants/board/pin_arduino.h scheme.

 

But I really don't want to go delving into every line of source code.    i.e. which files are identical and which files are full of bugs. 

 

David.

 

p.s.  just tried my "hello_t84.ino" sketch with a "Optiboot ATtiny84 @ 8 MHz  (internal osc)" board selection from the ATTinyCore distribution.

And it uses the PA1=digital#9 mapping

Last Edited: Wed. Oct 22, 2014 - 01:27 PM