virtualWire on attiny85

[XaKeRa]

Hello guys, I am trying to receiver&transmitter with two separated attiny85, but I don't know what to use and how to program it, I only used two atmega328P to accomplish the rf comunication.

These are the products I am using:

[url]http://www.robotev.com/product_info.php?cPath=1_30&products_id=235[/url]

[url]http://www.robotev.com/product_info.php?cPath=1_30&products_id=236[/url]

[From Yahoo]

There is some code here
http://arduino.cc/forum/index.php/topic,76396.0.html
and some here
http://www.electro-tech-online.com/code-repository/124454-arduino-pde-newer-ino.html

--
From Yahoo <tyt...@yahoo.com>

[Ty]

On Tuesday, October 16, 2012 8:24:16 PM UTC+10, Ty wrote:

There is some code here
http://arduino.cc/forum/index.php/topic,76396.0.html
and some here
http://www.electro-tech-online.com/code-repository/124454-arduino-pde-newer-ino.html

  Its not clear if you have already achieved this on the ATMega328p if not the above is relevent . If you have and want to use the attiny85 then better heads than mine will assist you I am sure.

[XaKeRa]

I already achieved it with ATMega328p, but I don't know how to make it work on attiny85

[From Yahoo]

Well you would have to look up the flash memory size of the 85 and see that it will fit first.
If it won't you would have to reduce the program size I would suggest.
The wiring would be to the rx and tx pins and whatever sensors to the other pins. You would probably have to change the code to use the pins on the 85.

You would have to compile that to a hex file (in arduino and save it) or by command line and then use avrdude to upload it to your chip.




On Tue, 16 Oct 2012 08:13:39 -0700 (PDT)

XaKeRa <dimitar...@gmail.com> wrote:

> I already achieved it with ATMega328p, but I don't know how to make it work
> on attiny85
>
> 16 октомври 2012, вторник, 13:31:47 UTC+3, Ty написа:
> >
> >
> >
> > On Tuesday, October 16, 2012 8:24:16 PM UTC+10, Ty wrote:
> >>
> >> There is some code here
> >> http://arduino.cc/forum/index.php/topic,76396.0.html
> >> and some here
> >>
> >> http://www.electro-tech-online.com/code-repository/124454-arduino-pde-newer-ino.html
> >> Its not clear if you have already achieved this on the ATMega328p if
> >> not the above is relevent . If you have and want to use the attiny85 then
> >> better heads than mine will assist you I am sure.
> >>
> >> On Tue, 16 Oct 2012 00:09:37 -0700 (PDT)
> >> XaKeRa <dimitar...@gmail.com <javascript:>> wrote:
> >>
> >> > Hello guys, I am trying to receiver&transmitter with two separated
> >> > attiny85, but I don't know what to use and how to program it, I only
> >> used
> >> > two atmega328P to accomplish the rf comunication.
> >> > These are the products I am using:
> >> > [url]http://www.robotev.com/product_info.php?cPath=1_30&products_id=235
> >> > [/url]
> >> > [url]http://www.robotev.com/product_info.php?cPath=1_30&products_id=236
> >> > [/url]
> >>
> >>
> >> --

> >> From Yahoo <tyt...@yahoo.com <javascript:>>
> >>
> >


--
From Yahoo <tyt...@yahoo.com>

[Ty]

Feel free to say thanks any time .

[XaKeRa]

20 октомври 2012, събота, 03:52:30 UTC+3, Ty написа:

Feel free to say thanks any time .

I want to upload it threw arduino IDE as ISP is it possible to program it this way ? 

[Mikael Nyberg]

Yes it is possible to program Attiny 85 with arduino IDE.
Look at this:
http://hlt.media.mit.edu/?p=1695

[r4z0r7o3]

I'm having a similar issue with getting this library to compile for an AtTiny85 (the digispark).  My code (5.6k compiled) works perfectly on a Arduino Uno, but when I try to build for the 85, it seems to be missing or having some different macro definitions:

C:\Users\...\VirtualWire.cpp: In function 'void vw_setup(uint16_t)':
C:\Users\...\VirtualWire\VirtualWire.cpp:263: error: 'TCCR1A' was not declared in this scope
C:\Users\...\VirtualWire.cpp:264: error: 'TCCR1B' was not declared in this scope
C:\Users\...\VirtualWire.cpp:264: error: 'WGM12' was not declared in this scope

I did a bit of goggling around, and see that some of the names are different for the 85: Here and Here

So, perhaps this is a simple case of just changing some of the macro names to use the Tiny85 ones?

What other info. would be needed to get VirtualWire working on the Tiny85?

[Mike McCauley]

On Monday, February 04, 2013 05:28:39 AM r4z0r7o3 wrote:
> I'm having a similar

> issue<http://digistump.com/board/index.php/topic,290.0.html>with getting

> this library to compile for an AtTiny85 (the digispark

> <http://digistump.com/#digispark>). My code (5.6k compiled) works

> perfectly on a Arduino Uno, but when I try to build for the 85, it seems to
> be missing or having some different macro definitions:
>
> C:\Users\...\VirtualWire.cpp: In function 'void vw_setup(uint16_t)':
> C:\Users\...\VirtualWire\VirtualWire.cpp:263: error: 'TCCR1A' was not
> declared in this scope C:\Users\...\VirtualWire.cpp:264: error: 'TCCR1B'
> was not declared in this scope C:\Users\...\VirtualWire.cpp:264: error:
> 'WGM12' was not declared in this scope

VirtualWire uses one timer. Perhps the timer name is different with ATTiny?

Cheers.

>
> I did a bit of goggling around, and see that some of the names are different
> for the 85: Here

> <http://arduino.cc/forum/index.php?PHPSESSID=be1d964188b03eab4ded4253bd7a93
> bf&topic=118586.msg906162#msg906162>and Here
> <http://arduino.cc/forum/index.php?PHPSESSID=be1d964188b03eab4ded4253bd7a93
> bf&/topic,97048.0.html>

>
> So, perhaps this is a simple case of just changing some of the macro names
> to use the Tiny85 ones?
>
> What other info. would be needed to get VirtualWire working on the Tiny85?

--
Mike McCauley mi...@open.com.au
Open System Consultants Pty. Ltd
9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au
Phone +61 7 5598-7474 Fax +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.

[r4z0r7o3]

On Monday, February 4, 2013 3:18:50 PM UTC-5, mikem wrote:

VirtualWire uses one timer. Perhps the timer name is different with ATTiny?

Cheers.
 

I did read this somewhere...found it...in the first 'HERE' link, it shows not working code ISR(TIMER1_COMPA_vect) and working code ISR(TIM1_COMPA_vect).  I got excited, then I remembered it wasn't complaining about different macros :(  Worse, some working code examples refer to some problematic macros for me like OCR1A but they don't appear to be having trouble with those :S 

This is what makes me think the issue must be on the Digispark Arduino IDE "glue" side.  I don't know much about the IDE setup, but their instructions do have you change both the programmer and board settings.  Where do the things like OCR1A come from?  I'm assuming they're macros, but either way, are they defined somewhere I just need to #include or something?

I'll try and hunt around in the files, but I really have zero-clue what I'm looking for.  Unf. the blessing of the Arduino IDE "glue" can also be it's curse :(

[r4z0r7o3]

Hmm, okay, I vaguely remember reading somewhere (dunno where) that the Tiny core used for digistump has timer0 and timer1 reversed (or something) but that you could still use timer0.  Anyway, in an act of frustration and total guessing (I have no idea what I'm messing with here or if will brick my digispark) I switched all the 1's with 0's:

// Speed is in bits per sec RF rate
#if defined(__MSP430G2452__) || defined(__MSP430G2553__) // LaunchPad specific
void vw_setup(uint16_t speed)
{
    // Calculate the counter overflow count based on the required bit speed
    // and CPU clock rate
    uint16_t ocr0a = (F_CPU / 8UL) / speed;

    // This code is for Energia/MSP430
    TA0CCR0 = ocr0a;                // Ticks for 62,5 us
    TA0CTL = TASSEL_2 + MC_1;       // SMCLK, up mode
    TA0CCTL0 |= CCIE;               // CCR0 interrupt enabled

    // Set up digital IO pins
    pinMode(vw_tx_pin, OUTPUT);
    pinMode(vw_rx_pin, INPUT);
    pinMode(vw_ptt_pin, OUTPUT);
    digitalWrite(vw_ptt_pin, vw_ptt_inverted);
}

#elif defined (ARDUINO) // Arduino specific
void vw_setup(uint16_t speed)
{
    // Calculate the OCR1A overflow count based on the required bit speed
    // and CPU clock rate
    uint16_t ocr0a = (F_CPU / 8UL) / speed;

#ifndef TEST
    // Set up timer1 for a tick every 62.50 microseconds
    // for 2000 bits per sec
    TCCR0A = 0;
    TCCR0B = _BV(WGM02) | _BV(CS10);
    // Caution: special procedures for setting 16 bit regs
    OCR0A = ocr0a;
    // Enable interrupt
#ifdef TIMSK1
    // atmega168
    TIMSK1 |= _BV(OCIE0A);
#else
    // others
    TIMSK |= _BV(OCIE0A);
#endif

So, for example ocr1a -> ocr0a, TCCR1A -> TCCR0A, TCCR1B -> TCCR0B, WGM12 -> WGM02, etc. (for each of the macros/symbols the compiler was complaining about).  To my utter shock and astonishment, the code compiles now.  However, this is all black-magic to me, so I'm not going to load it onto my digispark and risk bricking it (had to wait almost 6-mo. to get them!).

Anyone know how/why/if this could work or am I even on the right track?

In case it helps, here's all the Digispark-Arduino integration code on github: https://github.com/digistump/DigisparkArduinoIntegration

[r4z0r7o3]

Looks like I'm making some progress over on my Digispark forum post.  I even found some working code for the Tiny85 to use as reference.  I just don't understand the bits/bobs at this level to make much sense of what additions are needed in VirtualWire.  Any help here or there is greatly appreciated :D

[r4z0r7o3]

On Monday, February 4, 2013 3:18:50 PM UTC-5, mikem wrote:

VirtualWire uses one timer. Perhps the timer name is different with ATTiny?

Cheers

Mike,

I believe I've got it working, patches attached.  I added a private  _timer_calc() routine since that component of the code is common across different chips.  It's designed to cope with both 16bit and 8bit compare-match counters.  I believe the math is all correct, but you may want to double-check.  

I then divided up the #elif defined (ARDUINO) section with a #ifdef __AVR_ATtiny85__ sub-section.  Besides the 8bit compare-match counter, some macro names, the ATtiny85 is setup in a very similar way to the 328p.

I wrote up a modified version to blink some LEDs (obviously using MUCH slower timing), and it worked perfectly on both 328p and the 85.  The second patch just cleans up some whitespace issues and adds a few comments.  Let me know what you think, and/or if you need me to make any modifications.

Thanks!

[Mike McCauley]

Hello,

thanks for the patch.
There were problems with the ordinary Aruino version, which I have fixed, now
in new version 1.14 recently uploaded. I have not tested on ATTiny85


Cheers.

[r4z0r7o3]

Fantastic, downloading and testing now!

Yeah, no worries, these Digisparks are hard to get (for now). It was unexpectedly super successful kickstarter project.  The creator had to go scrambling for an assembler because his kitchen-table + wife weren't going to cut it :D  Anyway, he's reportedly getting set up with some major electronics distributors, so they should be easy to come by soon-ish.  From my experience so far, they're FANTASTIC 'lil  $8 USD Arduinos.  Anyway, I'll let you know if I find any problems in the new version.  Thanks again.

[r4z0r7o3]

BTW: Seems to be working great!

Thanks again.

[Sanjeet Raj Pandey]

Hey, r4z0r7o3

Is it possible to get your working code . I have been long trying and without success .

Thank you 

[Chris Evich]

Hi,

Sadly no, it's long-gone. However, it wasn't much more than the
VirtualWire example code. Also, when I tested it, the RX was running on
a real Arduino UNO, only the TX was on a ATTiny85. Note that this stuff
is extremely timing sensitive, it's really easy to mess it up (which
quickly results in one or both sides not working) :S It's also possible
I bunged something in the timing calculations, so certainly if you find
a bug I'd love to know about it.

[Sanjeet Raj Pandey]

Found it, this on compiles super on Attiny85 with virtualWire 

http://cosa-arduino.blogspot.de/2013/03/news-virtual-wire-interface.html

have fun

Sanjeet

[Chris Evich]

On 04/16/2013 05:38 PM, Sanjeet Raj Pandey wrote:
> Found it, this on compiles super on Attiny85 with virtualWire
>
> http://cosa-arduino.blogspot.de/2013/03/news-virtual-wire-interface.html
>
>
> have fun
> Sanjeet
>

Neat! I like that OO interface much better. Thanks for the link!

[Sanjeet Raj Pandey]

Your welcome Chris ,

 I tried flashing it on ATTINY85 and it does including VirtualWire :) . It does but i think bit rate has to be changed as max 2000 is allowed on RF Link and in code its 4000 . I will test later today whole system. 

Good Luck 

Sanjeet

[Chris Evich]

On 05/11/2013 07:17 PM, Mikael Patel wrote:
> Hi!
>
> Have you tested the Enhanced mode. This allow more advanced message passing
> with acknowledgement and retransmission. There is also support for message
> dispatching. Please see the example sketches.
>
> Cheers!
>
> Mikael
>

I really like your Cosa platform, and what you did to make VW code much
prettier :) While reading through the library, I spotted a typo & bug I
thought I'd share:

Comment typo:
https://github.com/mikaelpatel/Sketchbook/blob/master/VirtualWire/VirtualWire.cpp#L261
(should be "Disable interrupt...")

Overflow Bug:
https://github.com/mikaelpatel/Sketchbook/blob/master/VirtualWire/VirtualWire.cpp#L284
(millis() wraps after about 49 days uptime, method could return when no
message received.)

If millis() is <= start, an overflow occurred. When this happens, your
while condition should be ((ulong)-1 - start) + millis() is < ms.

This solution will also fail if the code waits more than 98 days, i.e.
two wraps. However, since the timeout (ms) parameter is the limiting
factor, so I don't think this will be a problem.

[Mikael Patel]

Hi Chris. Thanks for the feedback and taking the time to read the code. Peer reviewing is the best. Thanks for the github links and pointing to the problems. I have worked a lot on the Cosa version and I see now that the Arduino version could need an update with the latest features.

I think the underflow problem is also in some other parts of the Cosa source. Through it require a long uptime and in that type of applications there are many things to consider as well. Thanks for spotting this.

Cheers, Mikael

[Chris Evich]

Yep, sure thing. Yeah, it's a common and very easy mistake to make when
working with timers. I was thinking about the "internet of things"
class of devices in particular, where long uptimes could be the norm. I
saw you already worked in sleeping the device when idle, which is super
cool! It also means powering these internet things for a LONG time off
a few batteries + boost-converter is entirely possible.

Any interest in making Cosa work with the Digispark (digistump.com)?
Since I helped Mike fixup VW to support them, I already know the changes
that are needed (timer1 -> timer0 and different ISR name). Sadly
they're very space constrained, since 2k is needed for the USB
programming bootloader, only 6k is available for user-code. Still,
maybe some simple things would still fit?

[Mikael Patel]

I pushed an update to fix the overflow issue. Added a few handly functions to Cosa/RTC.

My Brother was one of the many KickStarter backers for the Digispark and actually handed me one last time we met. Have not come around to porting Cosa to it - yet. As Cosa with VWI is up and running on both ATtiny84/85 it is mainly the hardware resources allocated by the boot loader which are the "problems".

My focus right now is TWI slave support so that it becomes really easy to hook processors together. Especially ATtiny as slave units for more autonom "shields". Targets are ATtiny's running virtualwire, NRF24, LCD, keyboard, 1-wire bridge, etc.

Cheers, Mikael

[Chris Evich]

Cool! Yeah, exactly. Well someday anyway, if you every have a mind to,
take a look at the upstream VW library code. It's setup for Digispark
with the timer1->0 flip, and worked well in my testing. Though I'm not
sure if there are other parts of Cosa that would need tweaks, since I
haven't looked. Good luck with the rest of the project, it looks promising!

[Chris Evich]

Hey,

Actually I found if I hacked in a DIGISPARK macro, I can get your code
"working" on both Arduino and Digispark. I also found and fixed a bug
with the prescaler array. I was going to send you a pull-request,
however, your "Sketchbook" repo. conflicts with mine, but here are the
patches...

With some little tweaks to my code, I was able to use this OO version of
VW in my project with about 18 bytes to spare! I say "working" because
there's some weird refresh problem somewhere that's either causing my
Arduino Rx to print every message 3 times, or the digispark Tx to send
three messages :S

Anyway, I'll keep hacking on it and see if I can find the issue. Are
there any other fixes/improvements to the Cosa VWI that might eventually
get backported?

[Mikael Patel]

Great.

Thanks for the patches! I think I understand the bulk of the changes. Extending the prescale table is the most important. I will need to add this to may timer prescale test program.

There are several extensions to the original VirtualWire library in C. First with an OOP design it is easy to have additonal Codecs. I have added Manchester, B4B5 block coding and my own fixed bitstuffing Codecs. Each Codec has its own preamble and start symbol so it is actually possible to use multiple Codecs at the same time.

Cosa VWI includes support for a more advanced message header with addressing and message type and on top of this message acknowledgement and retransmission with a new retransmit function. There is a new send() function that uses a vector of buffers aka iovec. This is a neat trick to support protocol stacks. It is a pattern used in many of the different communication methods in Cosa.

You can find details in the online documentation and on the Cosa blog. There is a fair number of example sketches for VWI. These try to cover many of the issues that people ask about on the forum(s).

Cheers!

Mikael

> <0001-Removed-extra-whitespace-and-made-header-Arduino-IDE.patch>
> <0002-Added-Digispark-support-via-DIGISPARK-macro.patch>

[Mikael Patel]

A short followup: Without looking into the details on the Digispark I guess that it uses Timer0 for the USB communications link. The ATtiny has USI for hardware support for UART, SPI and TWI. Timer0 is used for clocking data on the TX side of USI. This has some implications on the Arduino code base as Timer0 is used for millis() and micros().

I just recently completed an USI based TWI driver for slave mode for Cosa. There is an interesting problem with many of the available application notes for USI as they all lack detection of the STOP signal when writing data to the slave.

The idea with the Cosa USI based TWI driver is to allow the same protocol style as for VWI over TWI between Arduino and ATtiny. This allow an addition level och scaling with shields interconnected with TWI much like the dtools research project.

Cheers, Mikael

24 maj 2013 kl. 23:03 skrev Chris Evich <evich...@gmail.com>:

> <0001-Removed-extra-whitespace-and-made-header-Arduino-IDE.patch>
> <0002-Added-Digispark-support-via-DIGISPARK-macro.patch>

[Chris Evich]

On 05/24/2013 06:33 PM, Mikael Patel wrote:
> A short followup: Without looking into the details on the Digispark I guess that it uses Timer0 for the USB communications link. The ATtiny has USI for hardware support for UART, SPI and TWI. Timer0 is used for clocking data on the TX side of USI. This

Both yes and no actually :) It does use it AFAIK during boot, with
Bluebie micronucleus https://github.com/Bluebie/micronucleus-t85 for ~5
seconds where it checks if it should program new user-code. However, it
switches into another mode for actually running the user-code. There,
timer0 is used for PWM (and probably other stuff) while timer1 is used
for delay(). Basically it's the opposite of Arduino from what I understand.

[Chris Evich]

On 05/24/2013 06:08 PM, Mikael Patel wrote:
> Great.
>
> Thanks for the patches! I think I understand the bulk of the changes. Extending the prescale table is the most important. I will need to add this to may timer prescale test program.
>

The tables were simply transposed, the one labeled 16bit contained the
8-bit prescaler and vis-versa. I triple-checked the ATtiny85 datasheet,
and the timer0 prescale definitely goes 1, 8, 64, 256, 1024 starting at
001 for no prescaling.

The 0 index in the 8-bit table I added as just a placeholder, because
TCCR0B of 000 actually means "No clock source (Timer/Counter stopped)"
(Table 11-6 in the datasheet). Which is why this should be checked as
an error in the code. It's also different from the main mCU clock
prescaler, which has a different table IIRC.

I'm guessing the 16-bit timer prescaler you have for the 16-bit timer is
correct. I originally wrote it from the AtMega328p datasheet, but it
doesn't hurt to double-check. It's possible I screwd it up or read the
datasheet wrong.

I also think there's a possible race-condition here:
https://github.com/mikaelpatel/Sketchbook/blob/master/VirtualWire/VirtualWire.cpp#L307

The PLL() method that runs from the ISR also modifies this value.
Because there is no synchronization happening between recv() and PLL(),
the value could change unpredictably before or after that line
(depending on when the interrupt fires). This could potentially lead to
an unpredictable state.

Unfortunately, I'm not smart enough to solve the problem or know for
sure if there is one :) My day-job involves much higher-level code, and
more power-hungry chips. In that world, such things involving parallel
processing/threading certainly are a problem, and would need to be
synchronized. I'm just assuming that applies here too.