question to tiny4,5,9,10 datasheet

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

For a small new project I was looking at the new (16reg) AVR structure.
is it correct that the 16 registers aren't memory mapped?

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

That'd certainly be my reading of Figure 5-1 too.

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

ok that's sad, so no way to index into the registors then :( or did I miss something ?

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

'Tis the same in Xmega so I guess this is "the future" as far as Atmel are concerned. I think the only reason they mapped the registers to be visible in early AVRs was that there was no RAM so the indexing modes would not have made sense without it but maybe they think that as all devices now have RAM there's no need to now share the registers as if they were RAM too?

The merits of mapping the registers was recently discussed in another thread where it was also pointed out that it's the easy way to access machine registers in a C program so that facility is lost too.

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

ok
I didn't know that a XMEGA had problems with normal MEGA code.
It's just sad, now we have 3 pointers that point to everything, and then
they have removed the "main" place to get to and from :(

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

The Xmega groups SFRs together in memory.
You access as memory mapped structures.

To me, the concept of Register and Memory are separate.

To most Compiler models, it is separate too.

Using a register-pair as a memory pointer is well established. e.g. using X or Y or Z to access the base address of a SFR "structure". Then using offset addressing modes to access specific members.

What R0 or R16 "tricks" do you want to use?

David.

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

The main problem with mapping the CPU registers into SRAM memory space is that a bad pointer can cause some *seriously* bad system behavior. At least with random memory corruption you have a chance of recovering or detecting it (minus perhaps stack corruption) if it can't mess with the CPU registers.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

can cause some *seriously* bad system behavior

So all the traditional tiny and mega have been "seriously flawed" in this way have they? Wonder why anyone has ever dared use them with such a serious problem? :-)

OK, I can maybe understand the removal of RAM indexed access in the Xmega where development is likely done at a much more abstracted level and tricks like:

uint8_t access_r13 = (uint8_t *)0x000D;
some_asm_fn();
PORTB = *access_r13;

to save passing parms probably don't occur but the t4/5/9/10 really are "back to basics" micros that are far more likely to be programmed at the raw, bare metal level and every trick available is employed to squeeze the code and justify using such a crap, under-resourced micro just to hit a price point. In fact I imagine they are probably used more by asm than C programmers and as sparrow2's many previous posts prove they love their space/cycle saving tricks ;-)

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

Quote:

In fact I imagine they are probably used more by asm than C programmers and as sparrow2's many previous posts prove they love their space/cycle saving tricks

[full disclosure: I have no real Tiny10-family apps]

I'll stay firmly straddling the fence on this one. [I must stop doing that--it is very uncomfortable]

As the flash/program space is quite small in this family, one certainly can "whip up" the ASM app. And the gurus that think in op codes will be able to squeeze in "one more feature".

That said, by necessity the apps for that family will tend to be simple and straightforward. When threads have come up about the family here, I've fired up CodeVision with test programs. Generally the C will translate into WYSIWYG code sequences.

The usual caveats apply. If your algorithm can make great use of e.g. Carry that C has no concept of, then yes, ASM can/will be tighter. Similarly one might need e.g a 24-bit counter and CV doesn't have 24-bit arithmetic. So ASM would "win".

But for the simple app that the family might be used for, a trigger input and an A/D input and a timer and a calculated/manipulated output--I don't think there would be much if any of a C penalty.

The chip designers could have tossed us a bone with a GPIOR register or two, but nnoooo ...

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

the problem with C compared with ASM is that you need to use the structure that the compiler use!
it's correct that is you write a C program, and then optimize it in ASM it's the gain is small (0% to 20%-30%),
but if you use the optimal structure for the job the gain normally are way bigger about 1/2 size or 2x speed or what ever
sets the limit.
the reson for pointing to registors is that I often use store/load rutines that can take any register(s) as one of the parameters
to avoid like GCC that every thing has to go thru r24 (r25).

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

and I should add the reson for this is the sot23 house, and if written in C the program would be to big! (I don't need speed)
but with a lot of general code I hope that I can do it in ASM.

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

Quote:

the reson for pointing to registors is that I often use store/load rutines that can take any register(s) as one of the parameters
to avoid like GCC that every thing has to go thru r24 (r25).

That was brought up in the thread Cliff mentioned. I'd say that over the years the use of "pointer to register" for me was occasional to rare. It is useful in CodeVision apps with global register variables where a pointer to a variable is useful.

Quote:

the problem with C compared with ASM is that you need to use the structure that the compiler use!

I don't see how that can have a large impact--on an app of this size. 1/2k to 2k (Tiny20) of flash is 250 to 1000 program words.

What structure is the C compiler forcing you to use?

[comments below relate to CV "structure"; YMMV]
1) Preamble/prologue before main() is reached. The standard one does the stuff I normally want, but one is allowed to use whatever is desired.
2) Vector table? CV allows it to be trimmed.
3) Jump/call to main()? Hmmm--perhaps a couple words there but perhaps can be eliminated with 1).
4) Catch loop at the end of main()? One word of fat. I'll give you that one.
5) Call/return conventions? I'd have few if any functions in an app of this size.
6) ISRs? CV has no fat there AFAIK. Minimal ISR is "RETI". "Smart" register saving.

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

Oh. Well now I don't have to ask about that silly message the simulator gives me when I try to see the value of h.

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. 

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

Quote:
I don't see how that can have a large impact--on an app of this size

?
The smaller a program the bigger the compiler overhead are. unless you have to finetune the compiler , and then it's just as easy doing it in ASM. (at least for me).

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

The Tiny40 has got LOTS of memory but only 16 CPU registers.

Perhaps Sparrow2 can post us a subroutine that illustrates the virtues of mapped CPU registers.

I would certainly agree that sometimes an ASM sequence can dramatically improve on what the C compiler generates.

But Sparrow2 has shown some very impressive 'improvements' over the years. They have been mostly due to better algorithms rather than language.

David.

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

Quote:
What structure is the C compiler forcing you to use?

at least GCC:
have to go thru r24/r25
you can't force it to stay away from X, Y or Z if needed
just using bit's as flags is not optimal.
other than 8,16 and 32 bit variable is a problem (have not used the new 24), but again don't think they are optimal.
can't force it to use lib routine for + and - to save code space. (there again I need pointers to registors for that damn it).

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

Quote:
They have been mostly due to better algorithms rather than language.

Yes but they could not have been done in C! (or at least then you would not have gained anything).

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

Often my ASM code are in two parts depending of needed speed size etc.
High optimal ISR that use what ever is needed, and a slower interpeter like structure in "main" that do the MMI or what ever it needes to do.

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

Quote:

at least GCC: ...

Ahhh, comparisons are to the "infinite value toolchain". To go further will not come to any great revelations not already discussed over the years. A summary:

1) A machine-code guru (I've known maybe a handful over the years) will always be able to bet the crap out of any compiler in size/speed.

2) One of my early mentors had a saying: "Any program can be made one instruction shorter. Apply recursively." :) Applied vigorously it is usually some shortcuts.

3) Are you making 10, or 10 million? If the latter, then having the guru apply the time to fit into Tiny5 vs. Tiny10--I cannot argue. Even with more modest volumes I've spent time fitting "one more feature" into existing "full" apps versus going to the larger processor.

3a) But usually it isn't that tight. So as these are small apps I agree: "...then it's just as easy doing it in [whatever is familiar] ..."

4) IME this type of app, and I've done a few Tiny25 (but not Tiny10-family as I mentioned earlier), it tends to be very straightforward if not trivial. No tricks are needed. No fancy algorithms. But these are simple industrial timers and other similar controllers. Y'all might well work in different application areas.

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

your point 3 is the problem I can't get a sot23 with 2K flash!
(and I want to use a AVR).
I guess I will start with a Tiny13 and take it from there
I should add that the extra RAM and registors on the tiny13 make the program way smaller, so it can fit in 1K flash.(perhaps even written in C ;) )

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

Speed-em-up trick provided in the imagecraft compiler is a checkbox in the options that links in an alternate set of libraries that dont use r20,21,22 and 23, leaving these as 'global fast access variables'.

Imagecraft compiler user

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

Quote:

Speed-em-up trick provided in the imagecraft compiler is a checkbox in the options that links in an alternate set of libraries that dont use r20,21,22 and 23, leaving these as 'global fast access variables'.


That is really nice, Bob. But consider which AVR family is under discussion here, and

Quote:
As of August 15, 2011, we have header files and device selection for all known 8-bit AVR variants excluding the ones with only 16 registers and reduced instruction support (i.e. the Tiny10).

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

OK, but I might be confused by the use of 'small'... I think he means package dimension, not register set. He says he doesnt need speed, but talks of assembler cleverness which usually means faster. One can use the regular old c compiler to write tiny85 programs, and the speed-em-up trick I mentioned can be held in reserve like an ace up your sleeve until you run up against a performance bottleneck.

Imagecraft compiler user

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

Quote:

OK, but I might be confused by the use of 'small'

What part of the thread title, and all the discussion, does not make it clear that the discussion is about the brain-dead AVR Tiny series, and specifically those in SOT23 package?

BTW, it is interesting getting the quote above from the Imagecraft page.
https://www.imagecraft.com/devto... says

Quote:
ICCV8 for AVR supports all Atmel AVR devices.

A more detailed description of features is available in Acrobat PDF Format: ICCV8 for AVR Flyer Page.

(NOTE: If you are using an older tinyAVR without SRAM, or the original 1200, you are looking for the ICCtiny compiler.)

"all Atmel AVR devices" sounds pretty equivocal, doesn't it? But the flyer says

Quote:
ICCV8 for AVR supports all AT90S and ATMega devices
(except for 1200, which does not have SRAM), Tiny26,
AT94K FPSLIC and ATXMega.

So now the >>only<< Tiny supported is Tiny26? That doesn't sound right.

The ICCtiny page sends me back to the V7 page, which again says "all AVR devices".

The quote earlier about no support for the brain-dead models comes from lower on the ICCV8 page.

Gets us old guys confused.

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

I'm so glad that I'm using ASM ;)

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

Quote:

I'm so glad that I'm using ASM

Go for it. What kind of app are you trying to cram into that little insect?

Is the SOT23 package attractive because mere mortals can mount it onto a circuit board? Lessee, that would be about 3x3 mm. Many Tiny models are available in the 20M1 package, about 4x4 mm.

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

first of all at the moment I go for a tiny13 for the project! (basic because it needs to work fast and I can't programm it with my stk500, I have dip tiny13s for the prototype).
it should take some ADC's and do filtering, and then send the result to a mega324, the main reson for an extra chip is that it needs to have an other ground level,(and for this project it does not need to be sot23, but I have some other ideas where size matter).

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

I love these Tiny 10s! Cheap, tiny, and sot 23's are easy on my frypan. Yea, they're not very big, but that's rather the point. I also use Tiny 2313, 4313, 45 and 85. Haven't needed an A/D AND lots of pins yet

Megas, xMegas, ARM's are all really cool for bigger projects. That's what I love about this, WIDE range of processors and none of them are very expensive.

I lay out my really tiny boards so once I've programmed the chip and it's doing the job, I can snip off the programming pads and have an even smaller thing to put in the train :D

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. 

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

Dare I commit heresy and mention the LPC810? If you like small (resource) AVRs you might love this Cortex M0+. True the 4K+1K device is 8pin DIP so I guess that makes it quite physically big but you can do cool stuff like assigning any of the 3 UART or 2 SPI to any of the pins you like (clearly you pick a subset of the peripherals in the chip to actually connect to the pins) and while the IDE is Eclipse the chip itself does cool stuff like a MicroTraceBuffer which is like JTAG/dW with knobs on. The code is auto-profiled as you go so you can see which lines have been executed/tested and which paths are not yet taken.

I'll shut up now but it's the most fun I've had in ages! (the Xpresso board has the 20pin 16K+4K 812 device in fact)

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

main problems no ADCs, and not 5V power
(and only 2 UART's ;) )

what is the price nobody seems to sell them yet?

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

Quote:

what is the price nobody seems to sell them yet?

Next month $0.60.

Edit: sorry "next month" is now this month. ;-)

Oh and I've used the analog comparator (*) and voltage step generator to implement a simplistic ADC though it's true there are only 32 steps so I guess that makes it a 5 bit ADC.

(*) http://knowledgebase.nxp.com/showpost.php?p=21104&postcount=4