Using a single AVR pin for read and write

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

Hi,

 

I have this Attiny85 which is required to do multiple tasks. Is it possible to read analog values from three analog input pins and then make them to write digital output?

The requirement is ADC1, ADC2 and ADC3 (PB2, PB4, PB3) pins should read analog values from ADXL335 accelerometer. Once the values are stored into variables, it should convert and write digital values into HT12E encoder (which requires 4 digital output pins) - can be any 3 from PB0 through PB3.

 

So, it is possible to read analog values and instantly write digital values into the pins. If possible, is there a delay required between reading and writing? Kindly help.

 

Thanks,

Praveen

Robot building is all about sharing & learning
-----------------------------------
www.robotplatform.com

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

Well, depends on what you mean by "instantly". Not sure about Tiny85 but some of the MCU's have a disable bit for the logic I/O circuitry attached to an analog input pin. So, at most, you might have two or three writes to change a pin from analog to digital. 

 

HOWEVER, you may have a lot of problems with the other digital device on that pin. CMOS inputs are not happy when the voltage at the input stays in that "no-mans land" between Vin(high) and Vin(low). Your HT12E may  behave strangely, at best. 

 

My recommendation: use a different chip that has enough I/O pins. You are asking for many headaches doing what you are trying. Yes, it MIGHT work. But, I would not spend my precious time and energy trying to make it happen!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Thanks for the feedback. Never thought about this:

CMOS inputs are not happy when the voltage at the input stays in that "no-mans land" between Vin(high) and Vin(low)

The reason for tiny85 is that I have around 200-250 tiny85 lying around and size fits perfectly in a board I am designing.

 

-Praveen

Robot building is all about sharing & learning
-----------------------------------
www.robotplatform.com

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

So you read the xyz Gs, then send keypresses to a 4 key keyfob chip, which sends them off thru the air? OK, heres a keyfob with 4 buttons. Here is the xy and z Gs I measured.... z is 1.0G, x and y are 0.0 G. What buttons do I press in what sequence to send this again? Plan B might be: read the a/ds, send thru the serial to a pc. Works great? Now put a transmitter and receiver where the serial cable was. Still works? Good! You are done!

 

 

Imagecraft compiler user

Last Edited: Thu. Jun 9, 2016 - 04:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or how about ADXL345, read via I2C to save a pin?

 

David

 

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

@bobgardner,

 

I am only sending 4 bits. This is for a gesture controlled robot which takes inputs as Front, Back, Left and Right. Four buttons are sufficient for that. Yes, it definitely does not give G's, but just 1's and 0's.

 

@David,

Thanks, this is another option in mind. If I do not succeed with 335, will disable Reset pin and use all 6 pins of tiny85 and that should hopefully work. 2 for inputs and 4 for outputs.

 

I have checked many online resources and every other link uses an encoder and a decoder circuit for these cheap RF transceivers. Is it not possible to just use a microcontroller to receive inputs and send an encoded signal to a transmitter and then get the output on the other side? Haven't thought much before writing. This should work I guess... And also, I can use the complete power of accelerometer to send exact tilt angle.

 

-Praveen

Robot building is all about sharing & learning
-----------------------------------
www.robotplatform.com

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

Remember debugging/programming is a pain if Reset has been 'repurposed'.  

 

David

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

How did we go from 3 inputs to 2?  Which axis got dropped?

 

 

Jim

 

FF = PI > S.E.T

 

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

Is it not possible to just use a microcontroller to receive inputs and send an encoded signal to a transmitter and then get the output on the other side?

 

This was easy. I connected it to an atmega32u4 board and transmission was successful while I could send entire string. Should try on attiny85. If I succeed, I can easily do off with just 4 pins; 3 analog and one timer pin.

Robot building is all about sharing & learning
-----------------------------------
www.robotplatform.com

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

How did we go from 3 inputs to 2?  Which axis got dropped?

SDA and SCL, using ADXL345 digital accelerometer.

Robot building is all about sharing & learning
-----------------------------------
www.robotplatform.com

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

Nice! 1+
 

 

FF = PI > S.E.T

 

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

Thanks for all the suggestions. I was able to make attiny85 transmit ADXL335 values through air.

 

For those who are interested, I connected ADXL to analog inputs 1,2,3 and digital output PB0 to RF Transmitter. Used VirtualWire library on Arduino IDE, created a hex file and dumped it into attiny85. Three values from ADXLxxx are concatenated and sent as a single HEX string. Well, the transmitter part was done.

For the receiver part, I used another Atmega32U4 with Arduino Leonardo bootloader, used the same VirtualWire library to receive the inputs through RF receiver, decoded the HEX values..... and..... it worked. The only issue is that sometimes the values are weird and shows junk characters while other times an increase in angle shows a decrease in analog values. Working it out yet...!

 

Thanks again.

 

-Praveen

Robot building is all about sharing & learning
-----------------------------------
www.robotplatform.com

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

sometimes the values are weird and shows junk characters

That is to be expected if you are using the little inexpensive transmitters & receivers.

 

Bluetooth and XBee, etc., put the data in a packet and handle some error detection and error correction for you.

If you use the little cheap modules YOUR code has to do the error detection and correction work.

 

A simple method is to put your data in a "packet", and add both a start of packet character, and a checksum byte at the end of the packet.

The Start of Packet character can be anything, but preferable a byte not used by the data stream.

If that is a problem, the consider having the data go from 0-254 dec, and use 255 dec as the start of packet character.

 

The Checksum is the sum of the data bytes, 8-bit, ignoring any carry out.

 

The receiver calculates its own checksum and compares them.

If they match the data is considered good, otherwise there was a data error.

 

The data transmission scheme can be as complex as you wish.

You can change the checksum to a CRC code, for improved error detection.

You can transmit the data packet several times for each data set and compare them at the receiver end.

You can add a sequential data set number to the packets.

You can add handshaking, i.e. the receiver sends and Acknowledge or Not-Acknowledge after each data set, and the transmitter resends the packets if needed.

etc.

 

Low power, cheap RF transmitters are very prone to data errors, and its up to you to recognize them and either ignore them or correct them, etc.

 

JC