Go Down

Topic: [ATTINY85]Nothing but junk appears on my serial monitor... :( (Read 8251 times) previous topic - next topic

cjdelphi


I just tested with 3.3 volts from arduino duemilanove and i get the same junk letters...with this code for example which uses the previous core i get this "ðððððððúððððððððûðððððððððððððððøððúððððððøððúððððððððð" in straight line.

Is there any problem that windows isn't in english language? I think i have tryied everything...


You need 5v...... 3v is no good for softserial!

cjdelphi

People read my post and read something I never said, I was making sure you used 5v! And not 2aa batteries ...

Then
a. You switch to 3v?.
B. What I typed was " nonsense "


I was trying to help you by making sure you used 5v
.

Fair enough if you're a non english speaker... but what's the excuse for the rest who posted!

Spyrakos88

#17
Feb 27, 2014, 10:43 am Last Edit: Feb 27, 2014, 11:05 am by Spyrakos88 Reason: 1
Ok here is the results with tiny tuner. I upload the sketch "Interactive_to_Serial_with_Details"

here is the instructions from the sketch

ATtiny85 Instructions...
 
 - Note: This Sketch is too large to fit on the ATtiny45 processor.  Use the
   Interactive_to_Serial example instead.
   
 - Select the correct board / serial port
 
 - Upload this Sketch to the processor
 
 - Connect PB3 / Pin 3 to receive on the serial converter
 
 - Connect PB4 / Pin 4 to transmit on the serial converter
 
 - Start your favorite terminal program, open the correct serial port, change
   the baud rate to 9600
   
 - Reset the processor.  A welcome message should be displayed.
 
 - Continue sending single 'x' characters (no carriage-return; no line-feed)
   until the calibration finishes

All good until i reset the processor. When i reset i receive nothing but junk letters no welcome message.. i send  the "x" characters the rx led is blinking when i send them but i still receiving this.

I think that the attiny i bought is crap.

Edit: I see that we can use external crystals with attiny85 which are extremely cheap. I think i will try them thanks.


Paul__B


I think that the ATtiny I bought is crap.


Whilst that is always possible, the general feeling here is that nearly all faults are the result of just not getting everything quite right.  (Digital chips mostly work, or do not work.)  The problem is figuring out just what it is that is not quite right.

May I suggest you write a sketch to toggle a LED every ten seconds, and run it for a minute or two to see just how far out of step it gets over that period.  This will demonstrate the success - or otherwise of the calibration.  I do not quite understand what the calibration process does, so it may be necessary to add code to the sketch (and indeed any sketch) to implement the actual calibration.

Spyrakos88

I just did what you said! The results...

The chip is not crap.. It needs tune for sure... I updated the blink example and instead of 1 second (1000ms) delays 10 seconds!!!It is tuned one zero ahead!! I need to learn how i can tune this thing...

fungus


I think that the attiny i bought is crap.


The internal oscillator isn't guaranteed to be accurate. It says so in the datasheet.

Worse: It *is* guaranteed to vary with voltage and temperature.

Even if you set it up 'perfectly', it might work on hot days but not on cold days. If you run off batteries it will vary as the battery drains, etc.

Do a search for "software serial doesn't work" on this forum. See how many millions of messages there are. Ask yourself why.

Advanced Arduino

Coding Badly

I do not quite understand what the calibration process does...


Measure the time (in CPU cycles) of a single 'x' character sent at 9600 baud.  If the processor is running fast, the time measured is too big.  If the processor is running slow, the time measured is too small.  After each character OSCCAL is adjusted to bring the measured time closer to the wall-clock time (actually, the serial converter's time but we assume it is accurate / matches a wall-clock).  The end result is a tuned processor with the corresponding OSCCAL value sent to the serial terminal.

Quote
...so it may be necessary to add code to the sketch (and indeed any sketch) to implement the actual calibration.


It is.  The OSCCAL value is not sticky.  It has to be set at run-time.  The top of setup should be this...
Code: [Select]
void setup( void )
{
  OSCCAL = 0x63;

...where 0x63 is the value from Tiny Tuner.

Coding Badly

Even if you set it up 'perfectly', it might work on hot days but not on cold days. If you run off batteries it will vary as the battery drains, etc.


I don't think that's correct.  I recall serial communications should be reliable over the entire envelope.  I'll check later today if I remember.

fungus

#23
Feb 28, 2014, 11:01 am Last Edit: Feb 28, 2014, 11:19 am by fungus Reason: 1

Even if you set it up 'perfectly', it might work on hot days but not on cold days. If you run off batteries it will vary as the battery drains, etc.


I don't think that's correct.  I recall serial communications should be reliable over the entire envelope.  I'll check later today if I remember.



That's going to depend on your baud rate. You *could* tune it to a particular baud rate I suppose...

The point is that SoftwareSerial is still hit/miss after many years of development.

A better solution is needed (IMHO). People only ever want SoftwareSerial  to print stuff in the serial console and there has to be a better way to achieve that than SoftwareSerial (ie. try to emulate the timing of signals designed by a telephone engineer in the 1960s).

eg. signals that are based on an 8MHz frequency, or signals that measure the pulses starting at the rising edge of each bit not some time in the past...

Either that or drop the baud rate down to something that's foolproof. 1200 baud if necessary.

Advanced Arduino

Paul__B


That's going to depend on your baud rate. You *could* tune it to a particular baud rate I suppose...



Either that or drop the baud rate down to something that's foolproof. 1200 baud if necessary.


This seems to be a common "urban" mythology.  Since we are talking of proportional variations, the actual baudrate is irrelevant.  If 10% error at 57.6 kbaud causes problems, 10% error at 1200 will cause just the same problems.

The only reason a lower baudrate will work more reliably is where there is an error caused by the divisor used to derive the baud clock from the current crystal frequency, and in that situation, it is possible to use OSCCAL to deliberately move the clock frequency to better suit the divisor.

Erni

I did an experiment with SoftwareSerial

ATtiny85V - 10 @ 8MHz
10 kOHM resistor from reset to VCC
0.1 uF from VCC to grnd

Tuned at 21 degree Celcius, and 5V (USB power)
Test sketch below:
Serial @ 9600

I started it at 21 degree and then put it in my frezer at -18 degree for half an hour.
Result: nothing - no garbled text it just continued to write flawlessly.

Then I stuck it on a room heater for another half hour at 30 degree, and it just kept on without failure

Lastly I borrowed my wife's hairdryer,the temperature now +50 degree and still no errors.

Next step was to try to lower VCC

At 1.9V the text began to be garbled
Under 1.8V it stopped and resat
At 2V No problems at all.

So not bad, atleast it is good enough for me.
I can only guess that the problems with SoftwareSerial that is reported is because of lack of tuning.

Code: [Select]
#include <SoftwareSerial.h>

SoftwareSerial mySerial(3,4 ); //rx=3,tx=4 setup of software serial
unsigned int x=0;

void setup() {
  OSCCAL = 0x68; 
  mySerial.begin(9600);
  x=0;
}

void loop() {
  x++;

  mySerial.print("Test= "); 
  mySerial.println(x);
  delay(500);
}

fungus


If 10% error at 57.6 kbaud causes problems, 10% error at 1200 will cause just the same problems.


Sure ... if your serial implementation is bone-headed enough to only change the master clock frequency instead of tuning the number of "cycles-per-bit".

Changeing cycles-per-bit at 1200 baud could give you very fine tuning.
Advanced Arduino

fungus

#27
Feb 28, 2014, 04:43 pm Last Edit: Feb 28, 2014, 05:03 pm by fungus Reason: 1

So not bad, atleast it is good enough for me.


Did you measure the difference it made? eg. Flash a LED at a fixed interval and time it.


I can only guess that the problems with SoftwareSerial that is reported is because of lack of tuning.


No, the problems with SoftwareSerial are:
a) Tuning is very difficult
b) It's a stupid way to solve the problem of "printing some text for debugging".

(surely you see the madness of trying to use a protocol that requires precise timing on a chip that has no precise clock source...)
Advanced Arduino

fungus


Tuned at 21 degree Celcius, and 5V (USB power)


Hate to bring some real engineering practice into it but the datasheet has a whole section dedicated to internal oscillator accuracy (section 22.9 "Internal Oscillator Speed")

Variation is about 5% between 3V and 5V Vcc  (eg. when powered with 3xAA batteries).

Variation is about 5% for every 20 degrees difference in temperature (a difference easily possible from summer to winter).

5% variation is enough to make it fail.
Advanced Arduino

Coding Badly

The only reason a lower baudrate will work more reliably is where there is an error caused by the divisor used to derive the baud clock from the current crystal frequency, and in that situation, it is possible to use OSCCAL to deliberately move the clock frequency to better suit the divisor.


And longer cables (more capacitance) where the rise-fall times are "long".

Go Up