VirtualWire current state as of January 2016?

[Pinus]

Hello everyone.

In the last few days I have been experimenting with Digispark connected to FS1000A RF 433MHz modules and various libraries.

I have tried library arduino-libs-manchester-master, and ManchesterRF-master. They did not work, either with Digistump IDE1.5.8C, or Arduino 1.6.6. One had compiling issues, the other did compile and then was not doing anything. Do not remember which one was doing what, since I am not going to debug them. I would rather write a new one myself, if I had to. I do not like debugging other people software, even if I did earn money as a student (in the eighties), modifying software written by others for customers not able to contact original programmers any more.

I have then tried latest VirtualWire V1.27 and, after declaring TX and RX pins, as well as declaring LED pin as output and RX TX, respectively as INPUT and OUTPUT (by pinMode), it works in transmission with a Digispark, and reception on an Arduino Uno. I know declaring pinMode on RX TX is not needed; it does look better, though. No reception on Digispark, either connected to USB, or connected only to a power supply and relying on LED pin1 to monitor data reception, in the latter case. Tested even directly connecting wires (cutting out RF modules) and using a third Digispark (to eventually exclude a malfunctioning one). No difference, clearly.

So, I suspect Digispark reception issue has to do either with clock speed, or interrupts, or both. Anything I read is more or less dated 2013 and seems to be no longer accurate, given new developments in libraries, IDE, AVR GCC, bootloaders, etc, etc.

Although I have over 30 years experience in programming and electronics, I was not born as a C language programmer (in my days as a student we did assembly and Pascal) and manage to write programs by looking for instructions on reference manuals. So far I have managed to write bug free software including satellite aiming, server side CGI scripts, JavaScript client side scripts, as well as some Arduino projects that do work fine. What I am trying to say is that I am willing to study, I am not waiting to be spoon fed. Certainly I do not know everything, especially C and AVR related. Actually I do know nothing about AVR hardware. I do have datasheets, though.

So, my questions are:

1) Is currently Digispark still switching speeds between 16 and 16.5 MHz, depending on whether it is connected to a USB, or not? If so, is this bootloader dependant and can be changed by upgrading bootloader to the current Micronucleus development? Is there a way to print out speed? I can connect a 1602 LCD and get the value, if needed, or just blink a led at different speeds, which is even easier. I do not know where to read that value, though.

2) Is there a problem with Digispark, using pin 0 as RX pin, VirtualWire V1.27 and INTERRUPTS? If so, where can I go study something about it?

Again, I am not willing to get spoonfed. I just need some references. I have just downloaded avr-libc-user-manual-1.8.0.pdf and I hope to find answers there, in case none is willing to help.

Thank you in advance, anyway, also for the incredible amount of work you have all done, so far.

[Pinus]

I have found one answer.

In order to read clock speeed, you can use: F_CPU

On Digispark it always returns 16500000. No difference, whether connected via USB, or not.

I have tested it right now, making blink LED on pin 1, depending on clock speed. It always blinks at the same speeed, therefore F_CPU does not change.

Now I still have to understand why Digispark does not receive with VirtualWire, though.

[Pinus]

I have been reading system libraries source code and I have noticed that someone assigned the exact same timings to both 16 and 16.5 MHz clock versions of Attiny85, therefore Digispark can not be used for precise timing, unless someone is willing to calculate exact timings and modify system libraries in the tiny core.

Possibly it might work by adjusting clock to either 16, or 8 MHz. I think 8 is a safer bet, since it has been given its own set of timing settings.  Will try that on a empty chip ASAP and report. Maybe someone will find this information useful.