I am writing a sketch for ATtiny85. I have one pin left and I would like to use it to send UART communication only. And I would prefer not to tweak the library.
Perhaps not. The library initializes the pin, and that might interfere with the RESET pin.
It depends on the code in the library, can you give a link to the source code ?
An other option would be to assign both RX and TX to the same pin and ignore the RX. That is probably just as dangerous as connecting RX to RESET.
There are many libraries, there is probably a library for TX only.
Why the ATtiny85 ? Can you use a small board with a ATmega328P ?
My project must be really tiny (DCC decoder). On the other hand, I need TX for debugging. I haven't implemented the idea yet - stuck on this problem. But if you want to get a general idea, you can see current version here MPED-DIY/turnout.ino at main · marko-pi/MPED-DIY · GitHub. Currently debugging works for ATmega only. I would sacrifice one LED pin for for RX capability at ATtiny.
If memory serves, you can disable the !RST function of pin 5. It's inconvenient though since you don't have a way to force a reset from outside this way, which gets in the way of programming the Tiny - i.e., you lose ISP programming functionality along with pin 5's special function. AFAIK...YMMV..check datasheet and all that.
Why not switch to a different, more powerful & pin-rich uC with a smaller footprint? I find QFN to be surprisingly easy to hand-solder with a 1mm tip and have etched several PCB's for QFN etc. chips. You can go pretty small that way, especially if you place components on both sides of the board, as I do whenever things really need to shrink.
With the plethora of cheap, powerful and fancy uC's we have access to these days, why settle for the Tiny85...? (Yes, it's cute, I still like it too).
I use the NmraDcc library that is tested on ATmega and ATtiny chips. I don't want to start programming everything from the scratch. The fact that I have already designed PCB (also shared on github) makes me even more reluctant to change.
By the way my PCB is one-side 1.0mm because I want the decoder to be thin.
I want to make this an attractive project for other users - so no complications with disabling RESET or tweaking existing libraries. Maybe what I want is simply too much, but why not at least give it a try?
I wonder what will give the most headaches. Trying to use pin 5 on ATtiny85 and the problems that come with it, or migrating to e.g. a ATtiny1607 in 20-pad VQFN package, miniaturizing your PCB further while providing much more possibilities for connectivity to the outside world.
One thing I do know is that in the projects I did with ATtiny85, I always made sure to keep pin 5 dedicated to !RST. When I made those design decisions, I read up on it and decided against trying to multi-function that particular pin. It just wasn't worth the trouble.
Minimal bit-bang send serial 115200 or 38400 baud for 1 MHz or 230400 baud for 8/16 MHz ATtiny clock.Perfect for debugging purposes.Code size is only 76 Bytes@38400 baud or 196 Bytes@115200 baud (including first call)
TinySerialOut is a bit like the SoftwareSerial libray, but taylored for ATtinys and simpler and more lightweight.Basic functions are: writeBinary(), writeInt() etc.writeString()Serial.print(), Serial.println()Default TX pin is PB2 on an ATtiny85, PD6 on ATtiny88 and PA1 on an ATtiny167.Contains the OpenWindowAlarm example.New: ATtiny88 support.
VQFN ain't scary - it's a healthy challenge You could go for a Mega328 in QFN, keep all the libraries and live a happy life
Your one pin serial solution sounds appropriate.
ATtinySerialOut uses 320 bytes of memory, which is still much less than SoftwareSerial which uses 480! (Which means I could not make it with SoftwareSerial anyway.)
Ok, so you'd need to change two #defines in the cpp as well. Have you checked if the pin is somehow hardcoded anywhere else? A quick glance suggests the #define labels are used consistently, but I haven't checked each and every line.
I mean, if you want this to work on a particular pin, why not just modify that library?
Well, what I am currently doing is that I copied ATtinySerialOut.cpp and ATtinySerialOut.h to the project directory, edited one line in ATtinySerialOut.h and uninstalled the library.
But if someone knows about another library that is more flexible (arbitrary TX pin), I am totally in.
Essentially, messing up with libraries is just pain in the ass. Each operating system holds libraries in different locations. Its location is generally difficult to find. It is just a mess.
This is about ATtiny85...all pins are available to @pygmalion in the PCB he designed and linked to - in fact, part of the problem is that all pins are used. Which happens quickly with a tiny85.
So his question was more about "can you use a non-existent pin for rx if you don't need rx anyway". I never tried; I suppose it wouldn't hurt to give it a shot.