-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with controlling I/O pins directly on the ATtiny167 #778
Comments
That's what I thought I was doing! That timer behavior is unique to the timer on the 167, but the behavior intended is for that register bit to be set when analogWrite is called on the pin and cleared when digitalWrite is called on it, and not set any value by default. Which version are you seeing this behavior in? It should absolutely not be setting that register on statup |
1.5.2 - I think that's the latest? |
Have you tested with the 2.0.0-dev version? (from github) That is where all current development is happening. I feel like I remember writing the code that would fix this, but it's only in 2.0.0-dev versions |
OK I'll try that, thanks! |
Sorry, same behaviour with 2.0.0-dev version. ie direct PORTB toggling only works on ATtiny167 if I do this first:
|
So wait a minute, you're saying that on startup, TCCR1D is not starting up as 0? What value is it starting up as? And it's doing this on 2.0.0? I searched the source code and don't see an obvious route towards things going wrong here though it's obviously a bit confusing since there are two parts with a TCCR1D, when the only thing the registers have in common is the name and it's set upon startup? I'd expect it to potentially get set wrong with digitalWrite/analogWrite if there was going to be a bug there |
Running:
prints 17 (0b00010001). |
By the way, I get these warnings when I upload the program (with USBtinyISP - FAST):
|
Well at least you can upload. I can't make any of my upload tools work on a known good tiny841. |
No, I just downloaded a .ZIP of 2.0.0-dev and put it into my Arduino/hardware folder. Unless it's picking up avrdude from somewhere else... |
That has nothing to do with whether, for some other purpose, you may have updated avrdude. For example, you may have installed MegaCoreX through the board manager, which uses AVRdude 7.1. that may be enough to cause it toi use 7,1 with this because the 2.0.0-dev wasn't installed by board manager and hence there is no concept of a "correct toolchain" or "correct avrdude version" , as far as the IDE is aware. So it just uses whatever it's got hanging around. If a board manager has updated one of those, it may use the updated version! (I don't know the algorithm here). verbose output enable during compiling (I do need to make that mandatory here don't I? Though I was reserving my decision until I saw what the 7.1 output was like. |
verbose output while compiling, it will show you the actual commandline it invokes. |
I assume you mean verbose output during upload:
|
Verbose compiling output:
|
Yeah - hypothesis confirmed. I've pushed fixes for all those warnings - every one of them was a legitmate defect in the avrdude.conf. The issue with it not recognizing the tinyisp is because they changed that in the new avrdude and I need to adjuist programmers.txt to accounr for it, and find the thread where this headache-inducing subject of the various subspecies of usbtinyisp was discussed |
Sorry to add to your workload! |
By the way - I generated those listings without a USBtinyISP plugged in (I left it at home) so that probably explains the "unable to open programmer" error. |
Oh.... So we don't actually KNOW tjhat there's a problem with the tinyISP ? |
Try latest, I checked in a bunch of PWM adjustments, and added to part specific documentation tables. No resolution to any avrdude 7.1 problems, we are skipping 7.2 and doing 7.2 - when I can fucking get binaries. |
I was puzzling about why the following program didn't flash an LED on PB0 on the ATtiny167:
I finally tracked it down to the fact that the ATTinyCore assigns the PWM pins to Timer/Counters, so they are disabled for direct I/O. I solved it by turning off the PWM outputs on PB0 to PB3 in
setup()
with:I've never come up against this problem before with ATTinyCore (or DxCore). Is this something I should be on the lookout for with other processors, or does it only affect the ATtiny87/167?
Wouldn't it be possible to only reassign the I/O pins on the first call to
analogWrite()
to avoid this problem?Thanks, David
The text was updated successfully, but these errors were encountered: