ATTiny85 Internal Pullup on B.5?

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

This is going to be an odd question, but those are the only kind I know how to ask....

 

Is the internal mechanism to enable or disable the internal pull-ups still available on PORT B.5?

 

I fully understand the following...

 

- B.5 has its own hard wired internal 50k pull-up.

- B.5 is enabled as a reset pin by default.

- I can set the reset disable fuse, and then require HV programming.

- I can use B.5 for ADC as long as it is held above 2v.

 

But I still want to know if the fabric still contains the internally switchable weak pull-up on B.5

I have a use for being able to toggle another 50k on top of the built in 50k pull-up if I can.

Consider that function to be "an extremely weak output".

 

So that's it, just wondering if anyone knows the answer.

 

Cheers,

Brad

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

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

I don't see anywhere that says it wouldn't be available.  Page 60 of the ATtiny85 datasheet has;  

 

• Port B, Bit 5 – RESET/dW/ADC0/PCINT5
• RESET: External Reset input is active low and enabled by unprogramming (“1”) the RSTDISBL Fuse. Pullup is
activated and output driver and digital input are deactivated when the pin is used as the RESET pin.

Pretty sure that if the pullup can be activated when the pin is used for RESET it would also be there for when the pin is designated an I/O or ADC0 pin.  Can't test this as I don't have an ATtiny 85.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Thu. Mar 1, 2018 - 11:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will do some tests tomorrow and report my results.

The goal will be to toggle the internal pull-ups at various audio rate frequencies to generate music.

 

If I understand the hardware, then enabling the software controlled pull-up will be like placing another 50k resistor in parallel with the hard wired 50k resistor already pulling up the reset line on the B.5 reset pin.

 

If that works, I can then amplify the slight change in voltage with a simple transistor amp, and then send the signal to a computer speaker input, allowing the "input only" pin to act as an audio output source in my project.

 

Thanks,

Brad

 

 

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

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

then enabling the software controlled pull-up will be like placing another 50k resistor

Note that internal pullups are generally very poor in terms accuracy/drift, etc. 

When in the dark remember-the future looks brighter than ever.

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

There is only one pullup on PB5.  When RSTDISBL is left unprogrammed, that pull-up is enabled and cannot be disabled by software.  When RSTDISBL is programmed, the pull-up become software controllable just like any other pull-up.  The only difference is that it has a slightly higher value than the pull-ups on the other I/O pins.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Mar 2, 2018 - 08:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the clear answer, Joey.

 

That is my "worst case scenario", but at least I can forget about doing the pull-up oscillation tests now.

I may still try twiddling some of the ADC registers to see if there is a noticeable noise on the pin I can exploit.

If there is, I may be able to amplify it enough to create an audio signal.

 

I will find a way to complete this project... I am obsessed!

 

Brad

 

 

joeymorin wrote:

There is only one pullup on PB5.  When RSTDISBL is left unprogrammed, that pull-up is enabled and cannot be disabled by software.  When RSTDISBL is programmed, the pull-up become software controllable just like any other pull-up.  The only difference is that it has a slightly higher value than the pull-ups on the other I/O pins.

I Like to Build Stuff : http://www.AtomicZombie.com

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

I may still try twiddling some of the ADC registers to see if there is a noticeable noise on the pin I can exploit.

Hmmm... that's an interesting idea.

 

My tests with that ADC show that you can affect the pin capacitance by selecting its MUX.  The difference is a few pF, and is the result of switching in the ADC's S/H cap.

 

You could theoretically affect the pin' charge by wiggling the MUX back and forth between ADC0/PB5 (MUX0) and GND (MUX13) at a desired frequency.

 

The pull-up will tend to charge the pin towards Vcc, while the S/H cap (after being charged to the potential of ground by connecting it to MUX13) will, when switched to ADC0/PB5 by selecting MUX0, rapidly deplete the charge on the pin as it takes up of that charge itself.  The resultant waveform is likely to have a very small amplitude, and will perhaps be swamped by other noise in the pin (which is likely to be mostly digital).

 

Some quick math:

Average reset pull-up value: 45K

Max pin capacitance: ~10pF

'Typical' trace capacitance: ~10pF

Total capacitance: ~20pF

 

So the TC of the RC filter formed by the pull-up and the pin/trace capacitance will be in the neighbourhood of 45E3 * 20E-12 = 900ns, or nearly 1us.

 

Now the S/H cap has a value of around 14pF, or approximately the same order as the pin/trace capacitance.  So the charge on the S/H cap (when connected) will tend to combine with the pin/trace charge such that the equilibrium voltage will be about Vcc/2.  Although, not really, since the the other leg of the S/H cap is itself tied to Vcc/2 (not GND), and the pull-up is acting as well.

 

The path from the pin to the S/H has a resistance of between 1K and 100K (process variation), so the TC of that portion of the resultant filter (when the S/H is connected) will either a bit shorter or a bit longer than that of the pull-up/pin-capacitance.  The resultant waveform is likely to be a short negative spike only a few us wide, and with minimal amplitude.

 

It would be interesting to simulate this, but I've got a deadline at the moment.  If I have time in the next few days I'll give it a go, but you can probably just rig up a test on a real device faster.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

How about using no pins at all?

 

Here is an example of making music under program control, that is simply picked up by a nearby radio...I saw this for an AVR at some point, but couldn't locate it...here is the original old school:

 

https://www.youtube.com/watch?v=fgYhVnmeWrk

When in the dark remember-the future looks brighter than ever.

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

Well, it's official... you can indeed get audio out of PINB.5 without setting the reset disable fuse!

I now have audio playing on my computer speaker, directly from PINB.5.

I did need a single transistor to amplify it, but it does sound good, like any other pin.

Thanks Joey for sparking my continued interest in exploiting the ADC noise... I knew there would be a way.

 

Here is the amplifier schematic...

 

 

And here is a very basic test to pulse the pin.

Sorry C people, I don't roll that way.

 

////////////////////////////////////////////////////////////////////////////////////////////////////////
////////// ADC PULSE TEST
////////////////////////////////////////////////////////////////////////////////////////////////////////

// REQUIRED INCLUDES
#define __SFR_OFFSET 0
#include <avr/io.h>

.global main
main:

// SETUP  ADC
ldi r18,224
out ADCSRA,r18

; PORTB.5 AUDIO TEST
LOOP:
inc r20
sbrc r20,0
ldi r21,0
sbrs r20,0
ldi r21,128
out ADMUX,r21

; DELAY
ldi r17,20
dly:
dec r16
brne dly
dec r17
brne dly
rjmp LOOP

The transistor is actually optional, but at the expense of a huge reduction in level.

The capacitor is a simple low pass filter, and with the transistor, the output is decent enough for digitized audio.

 

I am glad to finally crack this puzzle, and will soon be diving back into the AVR insanity.

Just been hiding in the shadows to see what this takeover brings.

Seems these Microchip folks are an ok bunch.

 

Oh yeah, almost forgot to explain why I need something so bizarre form an ATTiny.

This is why...

 

https://www.youtube.com/watch?v=miefLPwZgOg

 

Now I do not have to use my HV fuse fixer hack each time I program the thing!

This project is going to the next level.

 

Later,

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Fri. Mar 2, 2018 - 08:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Brad, love the ball, Amiga Forever!

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

Thanks, yeah... I am a Commodore Fan Boy to the end!

 

Actually, my real baby is the VIC-20.

Have been doing an expansion system for it lately.

Everything made from 1980's style 7400 logic...

 

https://www.youtube.com/watch?v=EIghk1BUG98

 

 

Of course, that is an AVR being used temporarily to load the 6502 program into the memory.

I use AVR and XMega a lot, both for hobby and production work.

 

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Fri. Mar 2, 2018 - 08:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
Thanks Joey for sparking my continued interest in exploiting the ADC noise...

You sparkies are weird -- at least to this old bit-pusher.

 

[style question: 

ldi r18,224

As you have the chip-include file and you use the definitions for the register names, why don't you use the bit names as well?  Or at least a hex constant.  Or can you really look at decimal 224 and know exactly which bits are set?]

 

I thought the gate to the S/H was only opened during one clock of the conversion.  But y'all have figured out that just setting the mux causes a wiggle, eh?  If it were the S/H during the conversion clock then I'd think you could hold the gate open longer by slowing down the ADC clock.  But I'm very probably missing what is going on here.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Being a child of the 60's, I love being called a sparky!

Now if I could only look and feel young again.

 

Yep, I have always resisted HEX, and can absolutely see the bits in a decimal number.

I am comfortable right up to 16 bits.

 

This exploit is very specific, and the magic toggle settings of mux are 0 and 128 for the optimal output.

Other values do work, but with a lower volume level. perhaps there are better values to be found.

 

I am very happy with these results, and plan to add sound to my Quark-85 Core very soon.

Can't wait to chase the beam with some AVR assembly.

 

Brad

 

theusch wrote:

AtomicZombie wrote:
Thanks Joey for sparking my continued interest in exploiting the ADC noise...

You sparkies are weird -- at least to this old bit-pusher.

 

[style question: 

ldi r18,224

As you have the chip-include file and you use the definitions for the register names, why don't you use the bit names as well?  Or at least a hex constant.  Or can you really look at decimal 224 and know exactly which bits are set?]

 

I thought the gate to the S/H was only opened during one clock of the conversion.  But y'all have figured out that just setting the mux causes a wiggle, eh?  If it were the S/H during the conversion clock then I'd think you could hold the gate open longer by slowing down the ADC clock.  But I'm very probably missing what is going on here.

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Fri. Mar 2, 2018 - 08:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought the gate to the S/H was only opened during one clock of the conversion.

The gate is open so long as a the ADC is enabled, and a conversion is >>not<< underway.  When using free-running mode, this means that the gate is open for only 1.5 ADC clock cycles, but in any other mode the selected MUX is gated to the S/H cap for as long as you want it to be.

 

the magic toggle settings of mux are 0 and 128 for the optimal output.

Curious.  The difference is the reference, not the channel.  You're keeping the channel set to ADC0/PB5, but you're toggling the reference from Vcc to Vbg.  I'm curious how that results in a change on ADC0/PB5.  Maybe a differential load on Vcc (I would expect a greater effect from toggling an output)?

 

Can you post a scope trace of the output on PB5 (without your filter in place)?  Maybe with a parallel trace of Vcc...

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

avrcandies wrote:
Here is an example of making music under program control, that is simply picked up by a nearby radio...I saw this for an AVR at some point, but couldn't locate it...here is the original old school:

 

Saw that demo'd on an IBM 1130 back in the mid 70's while visiting the CS dept. of the university I later attended.  

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

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

I sure will.

 

Once I get some basic music playing, I will capture some waveforms.

Going to resurrect the original thread for this thing and post there.

A project is never dead!

 

Brad

 

joeymorin wrote:

I thought the gate to the S/H was only opened during one clock of the conversion.

The gate is open so long as a the ADC is enabled, and a conversion is >>not<< underway.  When using free-running mode, this means that the gate is open for only 1.5 ADC clock cycles, but in any other mode the selected MUX is gated to the S/H cap for as long as you want it to be.

 

the magic toggle settings of mux are 0 and 128 for the optimal output.

Curious.  The difference is the reference, not the channel.  You're keeping the channel set to ADC0/PB5, but you're toggling the reference from Vcc to Vbg.  I'm curious how that results in a change on ADC0/PB5.  Maybe a differential load on Vcc (I would expect a greater effect from toggling an output)?

 

Can you post a scope trace of the output on PB5 (without your filter in place)?  Maybe with a parallel trace of Vcc...

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

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

 

Dang, anyone know how to fix the image posting function in this forum?

It shows only part of the box and then does not allow saving after selecting an image.

It worked an hour ago on the computer at work, but not on any system here.

 

Is there a way to use [IMG] tags like before?

 

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Sat. Mar 3, 2018 - 12:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brad,

 

I "simply" click on the image filename, Control-C and then Control-P paste it into the message editor box.

 

Cheers,

 

Ross

 

Ross McKenzie ValuSoft Melbourne Australia

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

Wow! All this time I have been uploading and linking to the images from my own site.

That is a LOT easier, thanks!

 

Ok, here is the waveform directly from the pin...

 

 

It is certainly a square wave, but seems to be wandering a bit.

Most likely due to my ugly scoping method, and low amplitude.

 

Here is the waveform at the output of the transistor...

 

 

looks like a nice pulse wave, not much different than using a real IO pin.

 

So there ya have it... you CAN use PINB.5 as an output without locking yourself out of ISP programming.

Any NPN transistor can bring the output up to a very workable level.

 

You only need to setup the ADC like this...

 

ldi r16,224
out ADCSRA,r16
clr r16
out ADMUX,r16

 

and then do this to make a pulse...

 

cbi ADMUX,7
sbi ADMUX,7

 

Tested on several Tinys so far and working the same!

 

Now I can continue the madness.

I sure missed this place.

 

Cheers Freaks!

Radical Brad

 

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Sat. Mar 3, 2018 - 01:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is that really what the bare pin looks like? It's 200mV p2p! Which is more than the output of the transistor!
Did you maybe leave the transistor in the mix and just put the probe on the base? What does it look like with only the probe on the pin? I'm wondering too what a parallel trace of Vcc would look like? I'm also wondering if this would work on any ADC input with its pull-up enabled.
Still baffled how switching references does this.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Yeah, just noticed that the pin drove harder than the transistor output!

I will redo the tests properly when I have some time. probably had the speakers plugged in as well.

No need to be baffled... the laws of physics often break down in my lab.

 

Brad

 

 

joeymorin wrote:
Is that really what the bare pin looks like? It's 200mV p2p! Which is more than the output of the transistor! Did you maybe leave the transistor in the mix and just put the probe on the base? What does it look like with only the probe on the pin? I'm wondering too what a parallel trace of Vcc would look like? I'm also wondering if this would work on any ADC input with its pull-up enabled. Still baffled how switching references does this.

I Like to Build Stuff : http://www.AtomicZombie.com

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

No need to be baffled... the laws of physics often break down in my lab.

smiley

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

I didn't have much luck capturing anything with my 300MHz modern scope, so I wend old-school.

Call my crazy, but I prefer an old 20MHz CRT anytime I am looking at audio signals.

 

Here are the captures...

 

 

What is odd is that the output of the transistor is mot much higher than the PIN.

But you cannot get audio directly from the pin. With a series .1 uf, there is some slight audio.

The transistor must be acting as a buffer, because the audio is very clean and loud using the transistor.

 

Here is a capture of VCC...

 

 

There is no noticable voltage shift on VCC or any of the other pins.

I set the other pins as IN / OUT and probed them all.

Only the ADC pin has the expected waveform.

 

In all captures, I was toggling ADC MUX at 1000 Hertz.

 

So although I am not sure how my exploit fully works, it certainly does work well!

I am now going to continue my Quark-85 thread, and post a schematic ans code.

If anyone has a Tiny85 and would like to try this, that would be cool.

 

Later,

Brad

 

I Like to Build Stuff : http://www.AtomicZombie.com

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

Thanks for the effort!

 

I set the other pins as IN / OUT and probed them all.

Only the ADC pin has the expected waveform.

What I had wondered is if the other ADC pins would exhibit the same signal, but that would require that you change the values of ADMUX that you're writing.  For example, to examine ADC1/PB2 instead of /RESET/ADC0/PB5, you'd toggle ADMUX between 1 and 129 (instead of 0 and 128).  You would also want to enable the pull-up on PB2 with sbi PORTB, 2 and you'd probably want to disable the input buffer with sbi DIDR0, 2.  This would set up the same (or similar) conditions on ADC1/PB2 as you have on /RESET/ADC0/PB5 when RSTDISBL is >>not<< programmed.

 

Basically, I'm curious if the result you've seen is due to a peculiarity of /RESET/ADC5/PB5, or if it's due to a peculiarity of the ADC's handling of Vbg.  With other AVR (like the m328p), Vbg is disabled if no peripherals which use it are enabled (BOD, AD, ADC).  For the ADC, it is sufficient for it to be enabled, even if it is not used as a reference, nor as a MUX.  The datasheet for the t85 isn't nearly to clear.  I wonder if Vbg is actually enabled/disabled based on whether or not it is selected as the reference (or MUX), and I wonder further if that toggling of the enabled state of Vbg could somehow backfeed into the MUX?

 

Some additional testing to figure out what's going on might include enabling BOD via fuses, ensuring that Vbg remains enabled regardless of the needs of the ADC.  Does your signal still appear?

 

How did you arrive at the values of 0 and 128 for ADMUX?  Lucky guess?  Trial and error?  Thorough testing of all values?

 

I note that you've enabled the ADC for free running mode (at ADCclk = SYSclk/2!), and I wonder if that has an effect on the result?  I expect enabling is required, but ongoing conversions are likely unnecessary.

 

I'm quite curious, because this is all an unexpected result, but I expect you just want to get on with QUARK85 rather than satisfy my curiosity ;-) ... Perhaps when I have some time in the future I'll run some experiments.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Thanks, I would certainly enjoy digging into this to see what is really going on under the hood.

I have not fully posted the entire QUARK-85 project due to lack of good audio support, but will be doing so now.

Other pin sharing attempts have only worked on 50% of monitors tested. This works 100%.

 

The T85 can now do full RGB (8 colors) as well as sound, so diverse demos can be made.

Before this exploit, I had either 4 colors with sound, or 8 colors and no sound.

 

Would you be willing to put one together and be the first to duplicate my system?

I could even send you some parts if you don't have them on hand.

From there, you could try various things to see what is happening with the ADC Exploit.

 

Parts required are very minimal...

 

ATTiny85, 40MHz clock, VGA connector, Audio connector, 5 resistors, 2 capacitors, 1 transistor.

 

The result is now a 204x240 VGA display with 8 colors, and 3 independent audio voices.

The purpose of the project is do flex one's Assembly muscle to make creative demos.

I think it is important to learn how to talk to the bare metal, as the art is dying.

Hopefully this project will inspire others to give it a go when I get around to posting it in full.

 

Brad

 

joeymorin wrote:

Thanks for the effort!

 

I set the other pins as IN / OUT and probed them all.

Only the ADC pin has the expected waveform.

What I had wondered is if the other ADC pins would exhibit the same signal, but that would require that you change the values of ADMUX that you're writing.  For example, to examine ADC1/PB2 instead of /RESET/ADC0/PB5, you'd toggle ADMUX between 1 and 129 (instead of 0 and 128).  You would also want to enable the pull-up on PB2 with sbi PORTB, 2 and you'd probably want to disable the input buffer with sbi DIDR0, 2.  This would set up the same (or similar) conditions on ADC1/PB2 as you have on /RESET/ADC0/PB5 when RSTDISBL is >>not<< programmed.

 

Basically, I'm curious if the result you've seen is due to a peculiarity of /RESET/ADC5/PB5, or if it's due to a peculiarity of the ADC's handling of Vbg.  With other AVR (like the m328p), Vbg is disabled if no peripherals which use it are enabled (BOD, AD, ADC).  For the ADC, it is sufficient for it to be enabled, even if it is not used as a reference, nor as a MUX.  The datasheet for the t85 isn't nearly to clear.  I wonder if Vbg is actually enabled/disabled based on whether or not it is selected as the reference (or MUX), and I wonder further if that toggling of the enabled state of Vbg could somehow backfeed into the MUX?

 

Some additional testing to figure out what's going on might include enabling BOD via fuses, ensuring that Vbg remains enabled regardless of the needs of the ADC.  Does your signal still appear?

 

How did you arrive at the values of 0 and 128 for ADMUX?  Lucky guess?  Trial and error?  Thorough testing of all values?

 

I note that you've enabled the ADC for free running mode (at ADCclk = SYSclk/2!), and I wonder if that has an effect on the result?  I expect enabling is required, but ongoing conversions are likely unnecessary.

 

I'm quite curious, because this is all an unexpected result, but I expect you just want to get on with QUARK85 rather than satisfy my curiosity ;-) ... Perhaps when I have some time in the future I'll run some experiments.

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Sun. Mar 4, 2018 - 07:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would you be willing to put one together and be the first to duplicate my system?

Of course!

 

I still have a 36 MHz oscillator kicking around here from your last burst of activity...  now I just have to find it... lots more at the the local shop if I can't find it.

 

Oh, I see you're up to 40 MHz now?  The local shop doesn't have a 40 MHz oscillator, only 40 MHz crystals...

 

The T85 can now do full RGB (8 colors) as well as sound, so diverse demos can be made.

Before this exploit, I had either 4 colors with sound, or 8 colors and no sound.

What do you do for input?  Didn't you once use an ADC input for resistor ladder / joystick input?  I'd guess that won't be possible with the ADMUX sound technique...

 

Now that I think of it, how the heck can your ADMUX exploit work at all?  Since you've got the ADC in free running mode, it means that the REFS and MUX bits are latched only at the beginning of each sample.

 

OK, I see, with your /2 ADC clock, and I assume a 40 MHz sys clock, that's a 20 MHz ADC clock.  At 13 ADC cycles per conversion, latching occurs every 26 cpu cycles, but your 1 kHz test tone toggles only every ~10000 cpu cycles.

 

Hang on, a look at your delay loop shows that it burns 15,408 cycles per half-period of your test signal.  If you're 'toggling ADMUX at 1000 Hertz' then that implies 15.408 MHz.  Did you mean toggling at 2 kHz for a 1 kHz signal?  That would imply 30.816 MHz.  So what speed are you actually running at?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Very impressive video - both from a content-on-YouTube and a signal-to-the-screen point of view.

Sean.

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

Thanks for the comments!

 

Yes, I have done more overclocking tests on the T85, and found it gets unstable around 46MHz at 5 volts.

All of the ATiny variants I have tested worked perfectly fine at 40MHz.

My test involve full speed toggle of all IO pins, reading of all SRAM and Program Memory.

I usually let the test run for a month or longer.

So now I consider the "safe" overclock for any Tiny to be 40MHz.

 

I have also greatly improved the video quality and optimization off the routines.

I now have 2 of those rotating Boing Balls moving around and changing colors.

On top of that, there are two other Sprites being drawn in front of the Boing Balls.

If that's not enough, I am also making 3 channel sound, and drawing a rainbow in the background.

Sprites are fully alpha aware, and can be any size that program memory permits.

 

All of this from a 512 Byte, Ting85 with 4.5 IO Pins. (I now count the ADC Exploit as half a Pin!).

 

There is no longer any input. I have decided to re-brand this project as... Quark-85 Demo Kube.

 

I promise to post a new video demo along with the full schematic, BOM, and some hex files this week.

I can send you the 40MHz osc and the 3 required ~420 ohm resistors if required.

Thanks for the offer to test this out, it is much appreciated!

 

Cheers!

Brad

 

 

 

I Like to Build Stuff : http://www.AtomicZombie.com

Last Edited: Mon. Mar 5, 2018 - 12:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good grief Sean!! Where have you been hiding all these years?smiley

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The only thing I might have trouble with is the 40 MHz can.  I'll try the local shop, but I might just try using another t85 to generate a 40 MHz clock via PCK and OSCCAL.  It won't be spot on, and there will be significant jitter, so it might not work, but it will be fun to try :)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

I should be able to re-time the VGA for my original 36MHz target.

It has been optimized a lot since then, so I think there may be hundreds of free cycles per line free now.

I only went to 40MHz because Digikey had no 36MHz thru-hole parts in stock, but an endless supply of 40MHz...

 

I also did a week long course at our local College for kids, and had them make a retro video game using an ATmega328.

The system did Atari VCS like graphics, and the kids did everything... soldering, some assembly programming, etc.

Of course, I overclocked the AVR from 20MHz all the way to 40MHz!

 

Here is one of the boards that the 10-12 year olds put together. Not bad for first time hackers!...