## Impossible Graphics Power from an ATiny85!

166 posts / 0 new

## Pages

Who-me wrote:
sadly there is a blind-spot left here, as Microchip do not make 5V oscillators...
Do any 5V Microchip cPLD have a PLL?

PLL are common in FPGA (and some cPLD?)

Brad could create his proof-of-concept (breadboard or protoboard) with a PLL in order to determine a clock frequency he requires then locate an oscillator can or IC for the first prototype (PCBA)

Lattice Semiconductor

iCE40 LP/HX/LM

http://www.latticesemi.com/Products/FPGAandCPLD/iCE40.aspx

(Phase-Locked Loops, 0 to 2)

due to

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

AtomicZombie wrote:
There is a much larger selection of xtals than 5v clocks available.
Yea ... roll-your-own 5V clock.

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

AtomicZombie wrote:
I have ordered a few Tiny1614's, ...
in SOIC150.

Consider a SMT protoboard from Alberta's BusBoard?

BusBoard Prototype Systems

Surface Mount Prototyping PCBs

http://busboard.com/surfacemountpcbs

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

gchapman wrote:
Do any 5V Microchip cPLD have a PLL?

Sadly, no, the ATF series have no oscillators at all (tho you can build a ring oscillator)

The newly added Microsemi parts are all 3v3 max.

gchapman wrote:

PLL are common in FPGA (and some cPLD?) Brad could create his proof-of-concept (breadboard or protoboard) with a PLL in order to determine a clock frequency he requires then locate an oscillator can or IC for the first prototype (PCBA)

Sure - For experiments around Clocks, there is also this solution of Si5351A - low cost, reasonable performance i2c PLL (but 3v3 out)

or, the lowest-part-count way to 'make a xtal work' as an external oscillator, looks to be the NJU6368A (15pF/15pF internal) or NJU6368P (0pF) in SOT23-6

Last Edited: Thu. Mar 15, 2018 - 01:04 AM

Who-me wrote:

andrewm1973 wrote:

At least in the parts I have done it with (2313 and  M644) the ext clock input does not need to be HC/TTL levels.  A low level AC signal will do.  The XTAL-IN pin is an analog-ish input.

That's true of the xtal amplifier, but the new tiny's lack any amplifier, they need a CMOS logic drive signal.

Some brands of MCU have a CMOS/TTL select bit for the port pins..

Sure 3.3V high probably works, (breaks worst case, but will be above typical),  but at higher MHz symmetric & higher drive is going to give better over-clocking results.

I would like to see MCUs spec'd to accept clipped sine drive from GPS Oscillator modules, (best precision, lowest price) but the IC vendors seem to miss this use case. Lower RFI is another bonus...

10.2.1 "figure 10.1" in the datasheet looks like you can select the main CPU clock to come from the 32Khz xtal osc.  No reason that the clock input of that osc should not cope with being driven by a 40Mhz AC signal AFAICT

andrewm1973 wrote:

10.2.1 "figure 10.1" in the datasheet looks like you can select the main CPU clock to come from the 32Khz xtal osc.  No reason that the clock input of that osc should not cope with being driven by a 40Mhz AC signal AFAICT

?? Err, actually, there are quite a few reasons....

The 32kHz MCU Crystal oscillators always also include a buffer to square up the sine wave.

That buffer must also be super low power. This means the 32kHz pathways are very frequency limited (usually sub 100kHz) - no chance of 40MHz being close to working.

Last Edited: Thu. Mar 15, 2018 - 02:16 AM

Who-me wrote:
or, the lowest-part-count way to 'make a xtal work' as an external oscillator, looks to be the NJU6368A (15pF/15pF internal) or NJU6368P (0pF) in SOT23-6
Thanks for the part information.

Would save some current if the DSC60XX can function for this application.

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

Who-me wrote:

andrewm1973 wrote:

10.2.1 "figure 10.1" in the datasheet looks like you can select the main CPU clock to come from the 32Khz xtal osc.  No reason that the clock input of that osc should not cope with being driven by a 40Mhz AC signal AFAICT

?? Err, actually, there are quite a few reasons....

The 32kHz MCU Crystal oscillators always also include a buffer to square up the sine wave.

That buffer must also be super low power. This means the 32kHz pathways are very frequency limited (usually sub 100kHz) - no chance of 40MHz being close to working.

Best I can do on my desk here at the moment is 4Mhz into the 32Khz OSC input.  8mhz internal making a 4Mhz out, going through a small cap to to the TOSC pin when set up to be a 32Khz xtal.

Seems to work with very brief testing.  Granted it is not 40Mhz, but a good order of magnitude above 100Khz.  Maybe the big thing about "low power" has more to do with the amplifier and output pin.......

Who-me wrote:
I wonder which solution has lowest total Icc ?
Does that really matter? ... oh ... 9V battery

There are 8.4V and 9.6V NiMH but a battery and charger may be an estimated 10USD minimum.

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

gchapman wrote:
Thanks for the part information.

Would save some current if the DSC60XX can function for this application.

Another idea around the DSC60XX, that uses fewer added parts than AC+Prebias, would be a series rectifier (slow diode) in the DSC60XX GND pin,  to lift it 600~700mV to better drive the 5V 50% threshold.

Acquiring a 5V clock ranging from 1MHz to 150MHz is no problem...

https://www.digikey.ca/products/...

I use these a lot, especially when needing some "magic" frequency.

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

Last Edited: Thu. Mar 15, 2018 - 02:06 PM

How does it work?
Do you have a SG-Writer or ?

You just enter the desired value in your order notes, and 2 days later, the oscillator is sitting on your desk.

sparrow2 wrote:

How does it work?
Do you have a SG-Writer or ?

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

AtomicZombie wrote:
You just enter the desired value in your order notes, and 2 days later, the oscillator is sitting on your desk.
Which is fine, but (at least one) datasheet says:

The ECS-P143 (3.3V) and ECS-P145 (5V)

14 pin dip DIP is a twice programmable

crystal controlled oscillator. The standard

14 pin DIP footprint is ideal for existing PC

boards.

So other than getting someone else to do it for you before it's shipped, how is the programming achieved?

 "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]

If you need production, the programmer was a simple serial type unit (seen one once).

www.ecsxtal.com/store/pdf/progra...

I just use them as a convenience. Usually there is a source if I want to dig later on.

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

Wow, ATTiny-1614 seems to be new ground when it comes to information.

Besides the datasheet, there is not much info out there, or examples of projects using the 14/16/17 series.

Even better, there seems to be ZERO information on coding the new registers / functions in assembly.

This is the place I like to be standing as I take on a new micro-controller!

Getting into fun things like this...

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


Nothing like taking 40 lines of mind-numbing C banter, and cleansing it back into 6 lines of assembly.

Programming the CCL should be a lot of fun, and a steep learning curve!

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

Last Edited: Thu. Mar 15, 2018 - 04:29 PM

Not sure where the 40 lines of mind-numbing C banter came from. One cycle* shorter.  To be fair, one more ldi is needed for the zero reg.

C source

#include <avr/io.h>

int main(void) {

_PROTECTED_WRITE(CLKCTRL.MCLKCTRLA, CLKCTRL_CLKSEL_EXTCLK_gc);
CLKCTRL.MCLKCTRLB = 0;
}


.lss output

int main(void) {

_PROTECTED_WRITE(CLKCTRL.MCLKCTRLA, CLKCTRL_CLKSEL_EXTCLK_gc);
94:	93 e0       	ldi	r25, 0x03	; 3
96:	88 ed       	ldi	r24, 0xD8	; 216
98:	84 bf       	out	0x34, r24	; 52
9a:	90 93 60 00 	sts	0x0060, r25	; 0x800060 <__TEXT_REGION_LENGTH__+0x700060>
CLKCTRL.MCLKCTRLB = 0;
9e:	10 92 61 00 	sts	0x0061, r1	; 0x800061 <__TEXT_REGION_LENGTH__+0x700061>
}


_PROTECTED_WRITE is a macro in xmega.h written by Joerg Wunsch.

/* Copyright (c) 2012 Joerg Wunsch

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.

* Neither the name of the copyright holders nor the names of
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE. */

/* $Id$ */

/*
* This file is included by <avr/io.h> whenever compiling for an Xmega
* device.  It abstracts certain features common to the Xmega device
* families.
*/

#ifndef _AVR_XMEGA_H
#define _AVR_XMEGA_H

#ifdef __DOXYGEN__
/**
\def _PROTECTED_WRITE
\ingroup avr_io

Write value \c value to IO register \c reg that is protected through
the Xmega configuration change protection (CCP) mechanism.  This
implements the timed sequence that is required for CCP.

Example to modify the CPU clock:
\code
#include <avr/io.h>

_PROTECTED_WRITE(CLK_CTRL, CLK_SCLKSEL0_bm);
\endcode
*/
#define _PROTECTED_WRITE(reg, value)

/**
\def _PROTECTED_WRITE_SPM
\ingroup avr_io

Write value \c value to register \c reg that is protected through
the Xmega configuration change protection (CCP) key for self
programming (SPM).  This implements the timed sequence that is
required for CCP.

Example to modify the CPU clock:
\code
#include <avr/io.h>

_PROTECTED_WRITE_SPM(NVMCTRL_CTRLA, NVMCTRL_CMD_PAGEERASEWRITE_gc);
\endcode
*/
#define _PROTECTED_WRITE_SPM(reg, value)

#else  /* !__DOXYGEN__ */

#define _PROTECTED_WRITE(reg, value)				\
__asm__ __volatile__("out %[ccp], %[ccp_ioreg]" "\n\t"	\
"sts %[ioreg], %[val]"			\
:					\
[ccp_ioreg] "d" ((uint8_t)CCP_IOREG_gc),	\
[val] "r" ((uint8_t)value))

#define _PROTECTED_WRITE_SPM(reg, value) \
__asm__ __volatile__("out %[ccp], %[ccp_spm_mask]" "\n\t" \
"sts %[ioreg], %[val]"               \
:                                    \
[val]          "r" ((uint8_t)value))
#endif /* DOXYGEN */

#endif /* _AVR_XMEGA_H */


EDIT: * We all know you like cycles ;)

EDIT2: To be fair...

"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 15, 2018 - 06:49 PM

AtomicZombie wrote:
Nothing like taking 40 lines of mind-numbing C banter, and cleansing it back into 6 lines of assembly.

:)

When you get to the overclocking stage, can you record the Icc values for Tiny85, Tiny1614 ?

Tiny1614 may be slightly lower, or that may be because peripherals look to all go into a separate Icc basket in newest data ....

I was, a proponent for Atmel Start, for getting projects up and running quickly, and afterword gutting them to get only the necessary code out of them.

Your thread has changed the way I have been thinking and find that the more direct approach is more to my liking and less wasteful of my time.  I'm not saying that you have converted me to using assembly, but you have definitely redirected me back to writing much more efficient code.

Thanks for that, I really do appreciate the nudge, going back to the 80's, well almost.

Larry

"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

Hey thanks!... glad to be a defender of the faith.

Originally, I dug into assembly because I knew C or Basic would have zippo chance of doing much with video. I will admit that back then, I would often whip up something quick in C, especially if a lot of math was being used.

But then things changed.

After about year 3 of doing these crazy assembly gigs, I soon found myself using it for everything. I am often handed partially completed projects in my R&D job, and they are always written in C. These days it takes me less time to actually start over in assembly than to decode the ENDLESS ENDLESS ENDLESS misdirection, renaming, headers, and all that other stuff that to be honest just pisses me off looking at now!

This is how the flow often goes when someone drops an almost done product on my desk...

1) I read mostly the comments to figure out what the original goal was.

2) I start then attempt to read through this supposedly "portable" language to see what the code is doing.

3) After a few hours I begin to feel angry, and wonder... who the hell wants to code like this? Why type so damn much?

4) I then delete everything except for the comments and start talking to the uC the way it was meant to be.

For me, the compiler is still useful though, and I often use it as a tutor.

I might take a very complex formula, let GCC chew on it, and then look at the LSS output.

From there, I learn a few things, and then take it to the next level... usually 10x less code.

That optimized routine as now in my library, cut down to the minimum

Assembly is really the true portable language, and I find C to be the worst for portability.

Once you hit a certain "level", you can even convert one assembly to the next almost on the fly.

With C, I can spend an entire freakin' day just trying to figure out what goofy name they gave the damn registers.

I am not against high level language, I just think it has no business on an 8 bit micro.

Leave C for Visual Studio projects.

Hmmm.. might as well use Basic.net then... just as fast in the end, and more portable.

Should I duck for cover now!?

larryvc wrote:

I was, a proponent for Atmel Start, for getting projects up and running quickly, and afterword gutting them to get only the necessary code out of them.

Your thread has changed the way I have been thinking and find that the more direct approach is more to my liking and less wasteful of my time.  I'm not saying that you have converted me to using assembly, but you have definitely redirected me back to writing much more efficient code.

Thanks for that, I really do appreciate the nudge, going back to the 80's, well almost.

Larry

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

I like to think of myself a "reasonably competent" with ASM.  But I really quite like C.

I am very glad that it is easy to mix C and ASM so I can use C for the parts that will be easier in C and don't need the size or speed advantage of ASM.

In a game, I'd prefer my life counter that only has to run when the action is over to look like this

lives--;

rather than

ld r16, lives

dec r16

st lives, r16

And perhaps when you consider the bigger picture and that the C will always look like

lives--;

if (0 == lives) gameOver = TRUE;

you could say "ASM will (may) win that race by one instruction" it doesn't really matter in this case.

I find that in most cases I can take well written C code and regularly beat it by either 10..40% in either speed or size with ASM.  Unless it needs that speed/size I find it is not worth the time extra to write AND comment the ASM.

An extreme case of the time advantage of C would be my Bresenham code.  The C version took minutes, then ASM version took months.  While the ASM version beats the C version by 40% to 90% in speed depending on case it took MONTHS to write.

AtomicZombie wrote:

Testing will be done at 25, 30, 32, 36, and 40 MHz.

If I get to 40MHz, I will ask Mr. Scott to keep going into warp 50 and beyond.

What is the MHz range / choices this can work over ?

Looking more into that nice Wide Vcc (1.6~5V) KC5032A SMD Oscillator, I can find stocks of

50MHz

48MHz

44MHz

40MHz,

32.768MHz

32MHz

30MHz

29.4989MHz

27Mhz,

25MHz

Further to my above comment about mixing C and ASM.  I can't see how this is easier to maintain or write

// RESET BALL 1
clr r17
sts VARMEM+0,r17
ldi r16,10
sts VARMEM+3,r16
sts VARMEM+4,r17
ldi r16,0
sts VARMEM+5,r16
sts VARMEM+6,r17

than

typedef struct {
uint8_t  frame;
uint16_t somethingElse;
uint8_t  x;
uint8_t  dX;
uint8_t  y;
uint8_t  dY;
} BallStruct;
.
.
.
ball[0].frame = 0;
ball[0].x     = 10;
ball[0].dX    = 0;
ball[0].y     = 0;
ball[0].dY    = 0;

You can still access the vars as fast as you want in ASM so no loss there.  The C is a lot more self explanatory and does not need comment where as the ASM would need to look like this

// RESET BALL 1
clr r17
sts VARMEM+0,r17               ; +0 = frame
ldi r16,10
sts VARMEM+3,r16               ; +3 = x
sts VARMEM+4,r17               ; +4 = dX
ldi r16,0
sts VARMEM+5,r16               ; +5 = y
sts VARMEM+6,r17               ; +6 = dY

So someone reading doesn't have to make (wrong) guesses about the contents of the vars like I did.

One could also use defines for the numbers in the ASM to make it more self commenting.

Just my point of view:

The struct def. only really give meaning if STD are used!

So you either load Y or Z with the start then use displacement.

Incredible, absolutely awesome, congratulations!!! And assembly language rules!!!

I would certainly agree on that point.

The Ball Demo "User Code" was one of those hack and try bits of code.

I just kept adding more (not optimized) and trying things until it filled the memory.

I am usually a lot neater than that, and use #define a lot.

My final code would have done this instead...

#define     BALL_COLOR     VARMEM+12
#define     WHITE          15

ldi r16,WHITE
sts BALL_COLOR,r16

I used to do a lot of C + ASM mixing, and it certainly worked well.

Even Quark-85 started this way, with the User Loop as C.

It wasn't until I started looking at the LSS that changed my mind.

Some of the compiled ASM made me wonder... did the competition write the optimization routines??

Hey compiler monkey... what the hell were you thinking?!

Losing cycles to obviously inefficient code is like driving around with a hole in my gas tank.

... I wouldn't do that either.

When I first began doing stupid video tricks with AVR just for fun, I was often told 2 things...

1) You probably won't beat the C compiler most of the time.

2) If you did this for a living, you would probably use C instead.

I can now verify that both of those statements are totally false.

I can always beat the compiler, and I do program assembly for a living now.

The only time I hit the hi-level language is when doing FPGA projects.

Verilog is very well behaved though, and doesn't try to hide everything.

I can't imagine tackling FPGAs without a background in assembly.

ASM gives a certain feel for the hardware, especially when you count cycles.

andrewm1973 wrote:

Further to my above comment about mixing C and ASM.  I can't see how this is easier to maintain or write

// RESET BALL 1
clr r17
sts VARMEM+0,r17
ldi r16,10
sts VARMEM+3,r16
sts VARMEM+4,r17
ldi r16,0
sts VARMEM+5,r16
sts VARMEM+6,r17

than

typedef struct {
uint8_t  frame;
uint16_t somethingElse;
uint8_t  x;
uint8_t  dX;
uint8_t  y;
uint8_t  dY;
} BallStruct;
.
.
.
ball[0].frame = 0;
ball[0].x     = 10;
ball[0].dX    = 0;
ball[0].y     = 0;
ball[0].dY    = 0;

You can still access the vars as fast as you want in ASM so no loss there.  The C is a lot more self explanatory and does not need comment where as the ASM would need to look like this

// RESET BALL 1
clr r17
sts VARMEM+0,r17               ; +0 = frame
ldi r16,10
sts VARMEM+3,r16               ; +3 = x
sts VARMEM+4,r17               ; +4 = dX
ldi r16,0
sts VARMEM+5,r16               ; +5 = y
sts VARMEM+6,r17               ; +6 = dY

So someone reading doesn't have to make (wrong) guesses about the contents of the vars like I did.

One could also use defines for the numbers in the ASM to make it more self commenting.

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

The glory goes to the ATTiny85 though... it never ceases to amaze me what it can do.

Both ATTiny and XMega are overclocking demons!

Uwe60 wrote:

Incredible, absolutely awesome, congratulations!!! And assembly language rules!!!

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

And which place going to the Z80?

AtomicZombie wrote:

Hey thanks!... glad to be a defender of the faith.

Originally, I dug into assembly because I knew C or Basic would have zippo chance of doing much with video. I will admit that back then, I would often whip up something quick in C, especially if a lot of math was being used.

But then things changed.

After about year 3 of doing these crazy assembly gigs, I soon found myself using it for everything. I am often handed partially completed projects in my R&D job, and they are always written in C. These days it takes me less time to actually start over in assembly than to decode the ENDLESS ENDLESS ENDLESS misdirection, renaming, headers, and all that other stuff that to be honest just pisses me off looking at now!

This is how the flow often goes when someone drops an almost done product on my desk...

1) I read mostly the comments to figure out what the original goal was.

2) I start then attempt to read through this supposedly "portable" language to see what the code is doing.

3) After a few hours I begin to feel angry, and wonder... who the hell wants to code like this? Why type so damn much?

4) I then delete everything except for the comments and start talking to the uC the way it was meant to be.

For me, the compiler is still useful though, and I often use it as a tutor.

I might take a very complex formula, let GCC chew on it, and then look at the LSS output.

From there, I learn a few things, and then take it to the next level... usually 10x less code.

That optimized routine as now in my library, cut down to the minimum

Assembly is really the true portable language, and I find C to be the worst for portability.

Once you hit a certain "level", you can even convert one assembly to the next almost on the fly.

With C, I can spend an entire freakin' day just trying to figure out what goofy name they gave the damn registers.

I am not against high level language, I just think it has no business on an 8 bit micro.

Leave C for Visual Studio projects.

Hmmm.. might as well use Basic.net then... just as fast in the end, and more portable.

Should I duck for cover now!?

That's because it's always faster to write well written code than to read poorly written code. But then, that's what got me fired from my last programming job.

larryvc wrote:

I was, a proponent for Atmel Start, for getting projects up and running quickly, and afterword gutting them to get only the necessary code out of them.

Your thread has changed the way I have been thinking and find that the more direct approach is more to my liking and less wasteful of my time.  I'm not saying that you have converted me to using assembly, but you have definitely redirected me back to writing much more efficient code.

Thanks for that, I really do appreciate the nudge, going back to the 80's, well almost.

Larry

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

Ok Freaks, things have just become VERY interesting on my workbench this morning!

I have received my ATTiny-1614s from Digikey, and soldered one up for programming.

Although, I am simply testing IO toggles...

ATTiny-1614 is stable at 65 MHz!!!

*** note : I was fooled by the prescaler - see here : https://www.avrfreaks.net/commen...

This is damn amazing!

I tried 20,30,40, and then tossed a 65MHz clock I had in my parts box in there and it works perfectly.

That is the highest clock I have right now, and will certainly keep pushing until failure.

At the point I see instability, I will dial it back 10%, and call it safe.

Zoinks Scoob, my Quark Engine just climbed the ladder a few notches.

Should be possible to get over 400 x 250 resolution if this frequency holds up.

It also seems that ST is only a single cycle, as compared to the 2 cycles of the other Tiny85.

The new IO mapping of the XMega is a bit slower when running out of Virtual Ports, but not with this chip.

In fact, Virtual Ports are fully defined for all pins by default, so there is no reason at all to use STS for IO.

Just add this, and use IO ports in single cycles like any of the ATMegas...

// VIRTUAL PORT NAMES
#define DDRA	0
#define PORTA	1
#define PINA	2
#define DDRB	4
#define PORTB	5
#define PINB	6


I am going to lay off the forum for a bit now and get some testing done.

Looks like Quark-1614 is now real.

Say 'Ello to my little Friend!...

Cheers,

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

Last Edited: Sun. Mar 18, 2018 - 03:51 PM

Perhaps try with a tad lower voltage to see how close it is from not working :)

Perhaps they work like some of the ARM chips where IO get 1 voltage and the core get a lower.

Will do... 5v and 3.3v.

Seems the new Tiny16xx series has the same clocking ability of the XMegas.

I wonder why the de-rate them so much?

Having tested almost every XMega (size and package), and can say that all of them reach 68MHz (with a margin of safety).

I will be enjoying my video experiments if this Tiny1614 continues to work at these blazing speeds.

sparrow2 wrote:

Perhaps try with a tad lower voltage to see how close it is from not working :)

Perhaps they work like some of the ARM chips where IO get 1 voltage and the core get a lower.

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

AtomicZombie wrote:
Will do... 5v and 3.3v.
May you test 4.5V approx?

Reason : multiple 5V supplies through common cathode diodes (case is 2 USB VBUS and one boost converter) (1 USB for pyupdi, 1 USB UART, 1 internal power)

AtomicZombie wrote:
I wonder why the de-rate them so much?
Impressive 5V IO rise-time of 1.5ns so the dv/dt is high resulting in harmonics that "might" degrade ADC, DAC, and Analog Comparator specs.

Ground bounce could be an issue; does your SOIC-to-DIP adapter have a ground plane?

Also, CMOS power is proportional to square of power voltage and proportional to frequency.

Might overheat some of its transistors or the di/dt may upset some voltage regulators.

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

AtomicZombie wrote:

ATTiny-1614 is stable at 65 MHz!!!

This is damn amazing!

...

At the point I see instability, I will dial it back 10%, and call it safe.

Maybe back off 20%, to allow some device-device variation ?

I had better expand the list of MHz 5V SMD... :)

Who-me wrote:

What is the MHz range / choices this can work over ?

Looking more into that nice Wide Vcc (1.6~5V) KC5032A SMD Oscillator, I can find stocks of

50MHz

48MHz

44MHz

40MHz,

32.768MHz

32MHz

30MHz

29.4989MHz

27Mhz,

25MHz

Interesting, I find that nice KC5032AfffCM series tops out at 50MHz.

Expanding to others (5V capable), there is 60MHz , 64MHz, 80MHz, but at higher Icc, and also 65MHz,66.66Mhz,100MHz at higher prices.

Perhaps try a diode in series on each of VCC and GND pins on that oscillator module you have, and see if tests the same ?

That drops the OSC drive closer to 3.3v models, but keeps it symmetric to the 5V 1614  50% threshold.

AtomicZombie wrote:
It wasn't until I started looking at the LSS that changed my mind.

Some of the compiled ASM made me wonder... did the competition write the optimization routines??

Hey compiler monkey... what the hell were you thinking?!

https://www.avrfreaks.net/forum/...

and that has made me a better C programmer.  I now think about what I am writing from the compilers perspective as well.

I now call myself a competent ASM programmer and and average C programmer.

AtomicZombie wrote:
When I first began doing stupid video tricks with AVR just for fun, I was often told 2 things...

1) You probably won't beat the C compiler most of the time.

Yes, it is easy to always beat the compiler in code size OR code speed and often both.  What you can't compete with the compiler with is time to finished product.

I am just saying "I choose my battles".  If I don't need speed or compactness I write in C.

The video mode in T2K is way more advanced and "incredible" than that of Quark.  The ASM optimized routines for drawing lines and rotating/scaling sprites are pretty well optimized ASM.

BUT - the life counter when you die is still in C and still says  Life--;

AtomicZombie wrote:

ATTiny-1614 is stable at 65 MHz!!!

Awesome.  Now you have 2K or RAM and a USART and the CCL I expect at least 320x240-4Bpp and 3D spinning cubes rather than just flat balls bouncing around :)

AtomicZombie wrote:
It wasn't until I started looking at the LSS that changed my mind.

Some of the compiled ASM made me wonder... did the competition write the optimization routines??

Hey compiler monkey... what the hell were you thinking?!

Yeah, I feel like that sometimes, but I tend to whine about it here instead of moving to assembly. This leads to knowledgable answers that either increase my understanding of gcc code generation, like here: https://www.avrfreaks.net/forum/... (I learned about the -fno-tree-loop-optimize flag that I sometimes apply to individual functions) or even to the gcc developers improving code generation, like here: https://www.avrfreaks.net/forum/...

AtomicZombie wrote:

ATTiny-1614 is stable at 65 MHz!!!

That's impressive. Probably some peripherals won't be happy, but since the xtinies allow you to set the clock divisor from software, it should be possible to speed up or slow down the clock as needed, for example use maximum speed only when some complicated calculation is needed, then fall back to a lower speed.

El Tangas wrote:
... but since the xtinies allow you to set the clock divisor from software, ...
external clock characteristics, dtCLCL, change in period from one clock cycle to the next

16KB tinyAVR 1-series, 2% max

mega4809, 20% max

typo?

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

Well, I connected the project to my main station at home, and was thrown this...

unknown core architecture 'avrxmega3' specified with '-mmcu='

The second time I loaded, it just says "failed... requires user input, reload the file"

Did that, and the same thing.

Damn... had an extra 2 hours I could have used... almost have video up and running now!

Seems my Timer.B interrupt is running 6x too slow, but I am sure there is a simple answer.

The toolchain on the other hand.... ack!

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

If it's a problem to flip IO's at 65MHz then try to connect unused IO pin's to power and program them as output, then the power draw on VDD will be more stable and that is better for the core. (I assume the GND is better than VDD, else have some IO's low).

AVRISP mkII does not have UPDI; replacement is Atmel-ICE.

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

gchapman wrote:
external clock characteristics, dtCLCL, change in period from one clock cycle to the next

16KB tinyAVR 1-series, 2% max

mega4809, 20% max

typo?

I noticed those new limits, and both are rather weird specs for Static CMOS Parts, and read like some PLL tracking issue.

- but those parts do not have a PLL ?

If it's not a typo, maybe whatever issue they had, they have managed to improve in 4809 ?

I have Atmel ICE.

I just moved from one computer (work) to another (home).

Same version of everything.

As usual, I am using my monthly bandwidth to download Studio again to see if that helps.

Seems I have to fully reinstall about once per month.

Either the USB goes squirrelly, or something else is borked.

Hope this fixes it, as I will have almost no bandwidth left to do anything else on my satellite internet.

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

Last Edited: Fri. Mar 16, 2018 - 11:09 PM

AtomicZombie wrote:
The toolchain on the other hand.... ack!
tiny1614 is not in Atmel Studio 7.0.1188 though it first shows in 7.0.1645

http://www.microchip.com/avr-support/atmel-studio-7

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

AtomicZombie wrote:

Damn... had an extra 2 hours I could have used... almost have video up and running now!

Seems my Timer.B interrupt is running 6x too slow, but I am sure there is a simple answer.

6x too slow looks suspiciously like the default clock divider setting in the MCLKCTRLB register.

Yep, that was it!

I had a version on number out.

Mine was like 7.0.1649.0000000000000000000000000000000001 or something.

All it took was to download  another 866 megabytes of data on my 2gb / month satellite.

I should be ok as long as nobody tries to send my an email attachment over 100k for the rest of the month.

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

External clock certainly loads up fine...

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

Interrupt definitely fires up...

// SETUP TIMER.B : VIDEO INTERRUPT @ 1272 CYCLES
ldi r16,lo8(1272)
sts TCB0_CCMPL,r16
ldi r16,hi8(1272)
sts TCB0_CCMPH,r16
ldi r16,1
sts TCB0_CTRLA,r16
sts TCB0_INTCTRL,r16

Interrupt lands here as expected...

// VIDEO INTERRUPT ENTRY POINT (4)
.global TCB0_INT_vect
TCB0_INT_vect: ;4

// FREQ TEST : HALF OF INT SPEED
sbi PINA,1

// CLEAR INTERRUPT (2)
ldi r16,1 ;1
sts TCB0_INTFLAGS,r16 ;2

reti ;4

But it fires exactly 6 times too slow.

If I divide the CCMP value by 6, then it works as expected.

Seems to be some internal clock divide happening somehow.

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

Last Edited: Fri. Mar 16, 2018 - 11:57 PM

AtomicZombie wrote:
Seems I have to fully reinstall about once per month.

Either the USB goes squirrelly, ...

wrt USB, Windows 7 and 8.1 are fairly stable; Windows 10 1709 is arguably stable (1703 is stable)

If the current Microsoft Patch Tuesday Windows update was very recently installed then USB becomes an issue, try either uninstalling that Windows update (7, 8.1) or roll-back Windows 10 to the previous build, reboot, retry USB.

AtomicZombie wrote:
... or something else is borked.
IIRC, Atmel Studio installer has a repair option.

AtomicZombie wrote:
Hope this fixes it, as I will have almost no bandwidth left to do anything else on my satellite internet.

Here, there's UHF from rural WISP (Wireless Internet Service Provider)

Mouser Electronics

Bench Talk

The Origin and Need for Wireless Internet Service Providers (WISPs)

November 16, 2017

https://www.mouser.com/blog/the-origin-and-need-for-wireless-internet-service-providers-wisps

https://www.avrfreaks.net/forum/another-win10-rant-frustration-part-2?page=1#comment-2396741

Satellite Internet: Fast Internet Service from Viasat (formerly Exede)

https://www.exede.com/

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

AtomicZombie wrote:
All it took was to download  another 866 megabytes of data on my 2gb / month satellite.

I should be ok as long as nobody tries to send my an email attachment over 100k for the rest of the month.

Torby had a similar issue except with a Windows 10 update through a cellular modem (3G assumed)

Here, a relative few cities have zero price Wi-Fi as a part of civil infrastructure.

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

Who-me wrote:
- but those parts do not have a PLL ?
no PLL

Who-me wrote:
If it's not a typo, maybe whatever issue they had, they have managed to improve in 4809 ?
maybe; the megaAVR 0-series manual has

Main Clock Features: – Safe run-time switching

https://www.avrfreaks.net/forum/megaavr-0-series#comment-2406681

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

Seems I have to fully reinstall about once per month.

Had no choice but to do that on my Win 10 when I had to download a VMware package, it wouldn't load properly if one just selected to "run" the package.

An option, perhaps, would be to put it on its own HDD and back that up with Acronis True Image.

It then only take a few minutes to restore the drive if necessary.

(obviously put your other files on a separate drive.)

JC

Last Edited: Sat. Mar 17, 2018 - 02:35 AM

gchapman wrote:
maybe; the megaAVR 0-series manual has

Main Clock Features: – Safe run-time switching

Hmm, usually that comment refers to being able to change prescalers on the fly, and jump across Clock MUX, - ie means a small logic block avoids any glitches less than the CLK period.

Not the same area as a change in period ?

The ΔtCLCL Change in period from one clock cycle to the next, is hard to fathom on Static CMOS parts.  I wonder if it is a cut/paste legacy from a part that does have PLL ?

(or even, these part had a PLL, but it's faulty so removed from the docs )  That said, 20%/clk speed slew is rather fast for any PLL to hope to track but meaningless on true Static CMOS ?

Indeed, How can ANY external CMOS clock, with enable, hope to meet that strange 20% - you have to start somewhere, with an instant clock...