Impossible Graphics Power from an ATiny85!

Go To Last Post
179 posts / 0 new

Pages

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

AtomicZombie wrote:
I can now get back to figuring out why my interrupt is 6x too slow.

 

I see no writes to the MCLKCTRLB mentioned in #145 ?

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

Who-me wrote:
Not the same area as a change in period ?
Yes

Who-me wrote:
The ΔtCLCL Change in period from one clock cycle to the next, is hard to fathom on Static CMOS parts.
Excessive return current under the MCU will affect its oscillators.

ESD/EFT/lightning suppression is ideally at the edges of the PCBA and away from the MCU; that's not the case on small PCBA.

So, the MCU should have some jitter tolerance for its main clock.

Who-me wrote:
I wonder if it is a cut/paste legacy from a part that does have PLL ?
Odd is 20% max is new; IIRC, XMEGA is 10% max and XMEGA have PLL.

 

"Dare to be naïve." - Buckminster Fuller

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

I have to remember to tell that a google  of "frequency tripler circuit" could solve your 70-100 MHz problem ;)

(you can make all odd multipliers, so something like 16*5=80 would be a nice one )

 

Perhaps you have to gain the output.

 

And I the first ARM7 layout I made, I put the clk to the clk-input direct, it worked fine but made a lot of RF noise, that chip (2138) wanted a AC coupled input! 

 

add: this is a 10MHz crystal osc with 90MHz output:

 

https://www.eeweb.com/extreme-ci...

 

Last Edited: Sat. Mar 17, 2018 - 06:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Correct, I did not write to MCLKCTRLB. as per my understanding of the following...

 

 

My understanding is that if you want the prescaler, then you write to PEN and PDIV.

For no prescaler, don't write either.

 

I didn't read anything about it being enabled on startup, but I will try writing zero and see what happens.

 

Thanks,

Brad

 

Who-me wrote:

AtomicZombie wrote:
I can now get back to figuring out why my interrupt is 6x too slow.

I see no writes to the MCLKCTRLB mentioned in #145 ?

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

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

Note that the reset value of MCLKCTRLB selects division by 6.

 

 

 

And also that to change these registers, they have to be unlocked first:

 

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

Thanks, I missed that one.

 

I also found that this would not work...

 

// ENABLE EXTERNAL CLOCK ON PORTA.3
ldi r16,216
ldi r17,3
ldi r18,0
out CPU_CCP,r16
sts CLKCTRL_MCLKCTRLA,r17
sts CLKCTRL_MCLKCTRLB,r18

 

Yet this does...

 

// ENABLE EXTERNAL CLOCK ON PORTA.3
ldi r16,216
ldi r17,3
ldi r18,0
out CPU_CCP,r16
sts CLKCTRL_MCLKCTRLA,r17
out CPU_CCP,r16
sts CLKCTRL_MCLKCTRLB,r18

 

Seems that "4 instruction cycles" actually means "4 clock cycles).

Assuming that the sts write actually happens on cycle #2, then it would be cycle #5 where it occurs... one too slow.

 

The speed just went up on my pin toggle, and I will measure it when I am back in my lab.

 

Thanks for the help, it's so much fun decoding a new chip like this.

Brad

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

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

Good news and bad news regarding the overclocking of the Tiny-1614.

 

The Bad...

Seems I fooled myself due to the /6 prescaler enabled by default.

It will indeed clock in at 60 MHz, even 80 MHz, but internally only to 36 MHz.

 

The Good...

36 MHz is still damn fast! Not as good as the Tiny-85, but as good as the Mega-328.

ST also takes half the time (only 1 cycle), and that is the best instruction to be faster!

 

With ST only taking one cycle, the Tiny-1814 is actually a lot faster than the Tiny-85, even at slower clock speeds.

Most cycles are eaten by ST in video generation and writing Sprites, so this is really good news.

 

The T-85 did 204 pixels at 40 MHz, but I am now getting 230 Pixels at 36 MHz from the T-1614.

Seems I can get a lot more Sprite bandwidth as well, and will test that soon.

 

I am going to start a new thread for Quark-1614 soon, and keep this one going for Quark-85.

Have some new Zeners to try and see if I can share Color and Sync without so much bleeding.

 

Later, and thanks for the help.

Brad

 

 

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

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

Quark-85 now has an extra pin for sound without requiring any HV programming.

 

Using a common 4.3v Zener (BZX79-C4V3) like this...

 

 

This now leaves one free IO for PWM sound output, offering a lot more versatility for sound effects.

 

I will update the code soon, but here is how this works...

 

PINS B.0,1,2 are normally floating and pulled up externally.

When it comes time for Sync, B0,1 are set low, and enabled.

When Sync if over, PINS B.0,1,2 are set back to floating.

 

When it comes time for Color, B.0,1,3 are set to high, but not enabled.

To set Color Bits, DDRB is sent pixel data to toggle individual IO lines.

This setting of DDRB does not disturb the SYnc or Sound PIN.

When the Zener sees the positive voltage, it passes .68V to the Analog Color lines.

The 1K pullup on Sync does not make it past the diode.

 

Sound PIN B.4 is driven by PWM, mixed as 4 independent channels.

PIN B.5 is used for programming, and B.3 is the clock input.

 

I am going to leave this one as Quark-85 Demo Kube, and just create multimedia demos on it.

The Tiny 1614 based version Quark-1614 will evolve into a Game System.

 

Brad

 

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

Last Edited: Sun. Mar 18, 2018 - 06:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:

With ST only taking one cycle, the Tiny-1814 is actually a lot faster than the Tiny-85, even at slower clock speeds.

Most cycles are eaten by ST in video generation and writing Sprites, so this is really good news.

 

Is it LD and ST or only ST

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

According to datasheet, not LD. But SBI/CBI are also 1 cycle and these are also important instructions to speed up.

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

AtomicZombie wrote:
The Bad...

Seems I fooled myself due to the /6 prescaler enabled by default.

It will indeed clock in at 60 MHz, even 80 MHz, but internally only to 36 MHz.

 

That's a little more as expected. Usually, newer parts reflect better process control, and less margin to typical...

Did you lower the Vcc a little, to check the margin on the 36MHz ?  What is Icc at that speed ?

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

Not yet.

I am going to convert the Quark Engine completely, using 36MHz @ 5V, and then see what happens with lower voltage.

As with the Atmega328, 38MHz is the bleeding edge, sometimes working at even 40 MHz, which is why I chose 36 MHz.

 

So far, the XMega holds the overclock record, all variants reaching 68MHz / 212% overclocking speed.

Next in line is the Tiny-85 and ATmega88, reaching 40 MHz / 200%.

Tiny-1614 seems good at 36 MHz / 180% along with ATmega328.

 

The only silicon on my bench that beats XMega for raw IO / SRAM speed is FPGA. Not ARM, not PIC32, not STM.

I wonder if that SAM thing would be any good? I might have to try that next.

 

Brad

 

Who-me wrote:

AtomicZombie wrote:
The Bad...

Seems I fooled myself due to the /6 prescaler enabled by default.

It will indeed clock in at 60 MHz, even 80 MHz, but internally only to 36 MHz.

 

That's a little more as expected. Usually, newer parts reflect better process control, and less margin to typical...

Did you lower the Vcc a little, to check the margin on the 36MHz ?  What is Icc at that speed ?

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

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

AtomicZombie wrote:
The only silicon on my bench that beats XMega for raw IO / SRAM speed is FPGA. Not ARM, not PIC32, not STM.

I wonder if that SAM thing would be any good? I might have to try that next.

Likely to be similar.

What MHz versions did you check ?

At some point, sheer MHz has to compensate for the lower efficiency - but higher MHz Cortex etc, (> 120MHz) also tend to come with many more pins, and more digits in the price too...

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

Returning to the use all pins part of this topic.  Some years ago I built this programmer attachment for a Dragon when I needed to program 325 tiny85s in a music boxes.  This had the SPI attached SD card reader. It was easier and more reliable to HIV program them by  making a PCB board an filing it to the SD thickness and shape.      The programmer ran in batch mode and did not even need to be power cycled as the SD card can be hot inserted.  There was one line that needed the probe pin. Clip the pin insert the card, program,verify, unclip pin.  Rinse repeat.  Simple and effective. For use with other AVRs, In SPI mode the programmer can fit into the adapter sleeve.

Tiny 85 Dragon SD Port interface

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

My electronics workbench is now going on vacation until winter.

Seeing as how spring is almost here, my main website now gets my focus.

 

I shall trade in my soldering iron for a welder for the next 6-8 months.

Might need a few AVRs for the various HomeSteading projects I am doing, but nothing this complex.

Can't imagine counting cycles to auto shut the greenhouse flaps, or trigger the deer scare alarm!

 

It has been fun... see y'all again when the snow buries me alive in December!

 

Cheers!

Brad

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

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

Really nice project and i am really honestly impressed by your assembly skills. But nowadays, its not really useful anymore in professional work. 
You can do pretty much same thing or much better, even with basic open sourced arduino librarys and a ili93xx supported display, with much higher resolution then 200x240 via VGA and in a fraction of time that i assume it took you to do what you did. My first project when i started with my job, was an arduino with atmega328 running TFT with 480x320 at 45-50fps, via ILI9341 interface(pararell). Took me maybe few hours of codins and was done. While running at 8MHz.

And now i work with STM cortex m1 or m3 MCUs, i mean, those thing run something like 1024x720 TFT display, at 60FPS without any problem and PCU costs like 4 or 5€ even in small quantities.

But i really wonder where you find the will to try to do so much, with so little.

Last Edited: Wed. Dec 23, 2020 - 11:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and, nowadays, it's getting harder to find VGA (analogue) displays ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess assembly was king of programming back when memory was limited, but now even the biggest project at our company take like... maybe half of memory on a mid tier stm32 MCU. But its still almost necessary to be able to read assembly and understanding what is happening  when debugging cycle after cycle, so you can find out what you did wrong when writing C.

Perhaps with some expensive or really good compilers on the market, assembly debugging is no loner a thing, but i still work with GCC GNU one and its a real handy skill to have.

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

But nowadays, its not really useful anymore in professional work

That's a rather myopic view, in my opinion..  The usefulness is not about the displays or pixels, or MHz,  it's about learning to thoroughly think through and creatively solve a complex problem.  Almost anyone can generically slather together a mishmash of libraries.   And yes, that is often good enough to make most people decently happy. Those guys might be a dime a dozen, but not be the problem-solvers needed when facing the toughest problems; you need people that aren't gonna go grab a library for a solution or give up.    So doing these kinds of projects is not simply about the project itself, but mentally preparing & exercising oneself to overcome other future hurdles.  Now this prepared person can say, yeah I can see myself writing that voice decoder.  I'd certainly hire this guy over someone who may think the only solution is to dig up a library.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

TBH, if you want to get most out of already existed library, you still have to dig way down to basic functions and clear it up for your specific usage. If you just start throwing in library's all over the place, you can fill even 1MB memory in a flash(pun intended). What i wanted to say that when a customer wants something done, you don't go starting from scratch in assembly and tackle any problem you encounter head on. Nobody is gonna pay for that. You need to get thing working fast and efficiently. I would love to have time to go play with assembly and optimize every single line of execution perfectly, but in real world, you don't have time for that. It is just not worth it in real world, when difference between MCU with 256kb and a 1024kb memory is like 0.05€.  And raising or even overclocking MCU frequency is a biiiiiig nononono. When you try to get a product EMI certified, you should be aiming for lowest frequency possible. 

All in all, its all about final product specifications. If you working on hobby project or something for yourself, then sure, assembly is nice way to take it slow and really enjoy getting into dirt.

But for all of projects i did for my costumers, going with assembly instead of C, would be like if you went to build the house, but instead of just buying bricks and cement, you would buy land with clay and make your bricks from scratch. Making a customer electronics with fullHD display and fluid GUI, a BLDC driver for robotics, medical sensors, long distance communication devices, metering, ... all of that, programming in bare assembly would take EONS.

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

Wonder how you would approach the problems outlined in this current thread?...
.
https://www.avrfreaks.net/forum/need-some-help-understanding-how-move-interrupt-vector

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

I never give advice to other people on their problems, unless i am totally familiar with project and system around it. And i never had the need to move int vectoring, so i cant comment on it.

But I would NEVER EVER use a atmega32u4 in a application, where i need to sense something so precisely, that even a 1 or 2 execution's would matter.

Last Edited: Wed. Dec 23, 2020 - 01:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

why would one bother to climb Mt Everest today.  You can much more easily buy a plane ticket and in no time at all be at a much higher altitude.

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

Klemko wrote:
You can do pretty much same thing or much better, even with basic open sourced arduino librarys and a ili93xx supported display

 

This is a demo, to show off the author's skills to those who are able to appreciate such things. It's art, not "professional work". 

The ILI93xx display driver is doing all the real work in your example, while here the tiny85 is doing everything, even audio.

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

Yea and i said that it is a really impressive work he did, i just wanted to warn any newbie(like myself few years ago) that would see this article and think that this is 100% best way of how things are done.

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

Really good example. If your ultimate goal is to get to high altitude fast and efficiently, get on a plane (analogy for using a piece of engineering/code, someone else made and is sharing with you). If you wanna do it all yourself and suffer in progress and take al lthe tiem oyu need, so that final result is more "deservable", then hike to top of mount everest. Maybe even make your own shoes. Good analogy for assembly vs C :P

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

"Dare to be naïve." - Buckminster Fuller

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

Klemko wrote:
i just wanted to warn any newbie(like myself few years ago) that would see this article and think that this is 100% best way of how things are done.

 

Well, that depends on what "best" means for each person, on what you wish to accomplish.

Pages