Atmel Toolchain For Linux supporting ATtiny104

Go To Last Post
71 posts / 0 new

Pages

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

Okay, so I gave a vanilla build a try, not cherry-picking the one target I am interested in...

 

After ~ 1 hour occupying 8 cores in a parallel build, my PC freezes at "100%" build completion:  The llvm link stage stops with an error, after it consumed more that 15 Gigabytes of swap space:

[100%] Building CXX object tools/dsymutil/CMakeFiles/llvm-dsymutil.dir/MachODebugMapParser.cpp.o
[100%] Building CXX object tools/dsymutil/CMakeFiles/llvm-dsymutil.dir/MachOUtils.cpp.o
[100%] Linking CXX executable ../../bin/llvm-dsymutil
collect2: fatal error: ld terminated with signal 9 [Killed]
compilation terminated.
tools/opt/CMakeFiles/opt.dir/build.make:417: recipe for target 'bin/opt' failed
make[2]: *** [bin/opt] Error 1
make[2]: *** Deleting file 'bin/opt'
CMakeFiles/Makefile2:15265: recipe for target 'tools/opt/CMakeFiles/opt.dir/all' failed
make[1]: *** [tools/opt/CMakeFiles/opt.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
collect2: fatal error: ld terminated with signal 9 [Killed]

And during that 1 hour, I saw all build targets passing by like PowerPC, MSP430, Sparc, AArch64 [insert non-AVR target here], but no AVR-related stuff.  AVR-related files are present in the sources, so it should also build the avr parts. No?  Need source hacking where?

 

Maybe just building on one core would finish a build (very likely still without AVR support), taking expected 6-8 hours to finish on AMD64 (under the assumption that the 8-core build actually used 8 cores to compile, and not 1 to compile and 7 to mine Bitcoins).

 

If an 8-core, AMD64 with 30 Gig of combined RAM + swap-space is not enough to build that, I am out...

avrfreaks does not support Opera. Profile inactive.

Last Edited: Tue. Dec 12, 2017 - 11:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@joeymorin:

Sometime in August or so this year I had a thread where someone posted a link to how to build the avr-gcc toochain for Windows. BUT, the build was done on Linux. AND as a first step the toolchain was built for Linux (I assumed it was because avrlibc also needs to be built..).

 

Sorry,  details have been swapped out. I can't even recall if I actually tried it, but I think so...

 

Either search through my (not so many) threads - I'm fairly sure it was in a thread I started. Or ask me and I'll hunt it down!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I decline to help as I have zero education, training, mentoring, and practice in compiler development (that's not a part of who I am)

I have done turnkey on building toolchains but I know enough to get myself wrapped around the axle.

I had a hope that AVR clang was far enough along.

Might inquire at http://lists.llvm.org/mailman/listinfo in cfe-users or maybe cfe-dev

given http://lists.llvm.org/pipermail/cfe-dev/2017-October/055649.html

and (for LLVM 4) http://lists.llvm.org/pipermail/llvm-dev/2017-February/110042.html

 

Edit: LLVM 4

 

 

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

Last Edited: Tue. Dec 12, 2017 - 11:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If an 8-core, AMD64 with 30 Gig of combined RAM + swap-space is not enough to build that, I am out...

Oy.

 

Best machine I have at the moment is a 2-core i3 with HT for 4 apparent cores, 8GB RAM + 8GB swap on a single slowish SATA (although I can add a fastish 4TB via eSATA).

 

In the cobbler's house, the children go shoeless ;-)

 

My brother has access to embarrassing amounts of compute power on which could be deployed an arbitrary OS/build environment.  How does 28 v4 cores (56 apparent) and a half TB of RAM sound?  Although, I don't think his employer would approve :)

 

It was thoughtful of you to try.

 

I know enough to get myself wrapped around the axle.

That's how I feel most of the time.  Consequently, I get wrapped around axles on a regular basis ;-)

 

Either search through my (not so many) threads - I'm fairly sure it was in a thread I started. Or ask me and I'll hunt it down!

I think I'll postpone for now.  I've heard from the 3rd party and they've selected an t40 instead of the t104 (in case >>his<< client [4th-party?] succumbs to feature creep).  Same kind of core, so same kinds of issues, but 4K/256B flash/SRAM, so much less pressure.  Further, the 3.5.4 toolchain available as a pre-built tarball already has support, no DFP necessar.  Same issue with __flash, but PROGMEM (though I share @SprinterSB's reservations) will suffice for this project.

 

I'd already taken a quick kick at an assembler-only version for the 104, although I haven't tested it.  Porting that to t40 will be a simple side-step if necessary, but I'm sure the 3rd party will prefer the C.

 

Thank you all.

"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: Tue. Dec 12, 2017 - 05:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> t40 [...] Same kind of core, so same kinds of issues, but 4K/256B flash/SRAM

 

Different core.  At least it's not a waste NOT to use SBIW or reg+const addressing as they are not available :o)

 

ATtiny40 has another feature, exotic in the realm of AVR: LDS / STS range don't cover all of RAM, i.e. there are parts of RAM that can only be addressed indirectly.  Moreover, besides the known addressing modes, memory can be accessed via RAMAR / RAMDR.

 

avr-gcc does NOT set -mabsdata per default for ATtiny40, i.e. any data in static storage will be accessed indirectly.  If static storage doesn't exceed 128B (the range from 0x40..0xbf covfefed by LDS / STS), then you can just -mabsdata.  The upper 0x80 B can be used for stack and heap.  If static storage exceeds 128 B, then you can use attribute absdata to assert that specific objects are accessible vis LDS / STS, cf. "absdata" in http://gcc.gnu.org/onlinedocs/gc...

 

avr-gcc does not support RAMAR / RAMDR addressing.  Also note that the function which transforms between RAMAR/RAMDR addresses and LD*/ST* addresses in NOT a linear function (as opposed to trafo from/to LD*/ST* addresses and IN/OUT addresses which IS linear).

 

avrfreaks does not support Opera. Profile inactive.

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

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

Last Edited: Tue. Dec 12, 2017 - 07:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would tiny416 be an alternative to tiny40?

Possibly.  It's an alluring device.  The requirements for this project are minimal, though.  10 outputs, 1 ADC input.  No other peripherals currently needed.  That's why the t104 was attractive, and the price was right ($33/qty100 for 14SOIC from Digikey).

 

Oh ... tiny416 is only in 3.6.1

3.6.1 is in the repo with Ubuntu 17.04, and it's supported by the same DFP I added to get the t104 going.

 

The deal-breaker for the 3rd party would likely be the price:  $72.50/qty100 for 20SOIC from Digikey   v.s.   the t40:  $52.20/qty100 for 20SOIC.

 

Different core.  At least it's not a waste NOT to use SBIW or reg+const addressing as they are not available :o)

I see.  Similar core?  Or, not similar core, but similar issues w.r.t. GCC's support for __flash?  I made my statement based on the fact that test code I posted results in the same error messages w.r.t. elpm/sbiw/r0-15.

 

ATtiny40 has another feature, exotic in the realm of AVR: LDS / STS range don't cover all of RAM, i.e. there are parts of RAM that can only be addressed indirectly.  Moreover, besides the known addressing modes, memory can be accessed via RAMAR / RAMDR.

I've browsed that section of the t40 datasheet.  I was struggling to understand why the added complexity is needed.  I wondered if there was some performance benefit I hadn't discovered, or if it were a consequence of the reduced core.  I suppose it's because only the 16-bit LDS/STS are supported by the core (and those are faster at 1 cycle, too).  I'd guess there are no 32-bit instructions at all...?  That would stand to greatly simplify the silicon, I suppose.  And we don't have a need for the 'RAM Interface' on the t104 because all 32 bytes of RAM are accessible to the 16-bit LDS/STS.

 

I note that the t416 has a 2-cycle STS (but a 3-cycle LDS?), so that's probably the 32-bit version?  Therefore, no need for the RAM Interface to reach all 256 bytes of RAM.

 

I note also in the t416:

1. Cycle time for data memory accesses assume internal RAM access, and are not valid for accesses
through the NVM controller. A minimum of one extra cycle must be added when accessing memory
through the NVM controller (such as Flash and EEPROM), but depending on simultaneous
accesses by other masters or the NVM controller state, there may be more than one extra cycle.

That would complicate applications which rely on cycle-counting.  AtomicZombie might have some words to say about that ;-)

 

avr-gcc does not support RAMAR / RAMDR addressing.

I would pity the soul saddled with that task.

 

Also note that the function which transforms between RAMAR/RAMDR addresses and LD*/ST* addresses in NOT a linear function (as opposed to trafo from/to LD*/ST* addresses and IN/OUT addresses which IS linear).

Of course.  Why would it be easy? ;-)

"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

joeymorin wrote:
3.6.1 is in the repo with Ubuntu 17.04, and it's supported by the same DFP I added to get the t104 going.
Ah ... I see post #12.

joeymorin wrote:
The deal-breaker for the 3rd party would likely be the price:  $72.50/qty100 for 20SOIC from Digikey   v.s.   the t40:  $52.20/qty100 for 20SOIC.
Flipped the other way when I compared both at Microchip (assumption is microchipDIRECT)

Apparently Digi-Key has a tiny40 sale on; no other distributor comes close.

 


https://packages.ubuntu.com/search?suite=all&section=all&arch=any&keywords=gcc-avr&searchon=names

http://new.microchipdirect.com/product/search/all/attiny40?facet=on&facet=true&fq={!tag=PT}PackageType_s:(%22SOIC+300mil%22)&facet.field=PackageType_s&start=0&rows=10

http://new.microchipdirect.com/product/search/all/attiny416?facet=on&facet=true&fq={!tag=PT}PackageType_s:(%22SOIC+300mil%22)&facet.field=PackageType_s&start=0&rows=10

https://www.digikey.com/product-detail/en/microchip-technology/ATTINY40-SUR/1611-ATTINY40-SURCT-ND/6833161

https://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyATTINY40-SUR

 

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

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

Hello

Yesterday i found this: http://www.jan-grosser.de/art/19...
That exact the problem that the attiny 102/104 def.inc file dont run in avra, and only run in "wine avrassembler2.exe ....."

 

The DFP-Pack are avrassembler2  ?

Have anyone the tn102def.inc / tn104def.inc from the avr-studio7 for test in avra ?

 

 

 

 

 

 

Tests with the arva-compiler:

 

The "pragma" in the tn102def.inc for the attiny102:

#pragma partinc 0
; ***** SPECIFY DEVICE ***************************************************
.device    ATtiny102
#pragma AVRPART ADMIN PART_NAME ATtiny102
.equ    SIGNATURE_000    = 0x1E
.equ    SIGNATURE_001    = 0x90
.equ    SIGNATURE_002    = 0x0C
#pragma AVRPART CORE CORE_VERSION AVR8L_0

 

 

 

Error from avra-compiler: (avra test.asm)

 

Pass 1...
tn102def.inc(27) : PRAGMA directives currently ignored
tn102def.inc(30) : Error   : Unknown device: ATtiny102
tn102def.inc(31) : PRAGMA directives currently ignored
tn102def.inc(36) : PRAGMA directives currently ignored
tn102def.inc(607) : PRAGMA directives currently ignored
tn102def.inc(608) : PRAGMA directives currently ignored
tn102def.inc(609) : PRAGMA directives currently ignored
Warning : No .DEVICE definition found. Cannot make useful address range check !

 

 

 

 

With   wine avrasm2.exe -fI test.asm:

 

wine avrasm2.exe -fI test.asm

AVRASM: AVR macro assembler 2.1.57 (build 16 Aug 27 2014 16:39:43)
Copyright (C) 1995-2014 ATMEL Corporation

test.asm(2): Including file 'tn102def.inc'

"ATtiny102" memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x00000a     10      0     10    1024   1.0%
[.dseg] 0x000040 0x000060      0      0      0      32   0.0%
[.eseg] 0x000000 0x000000      0      0      0 9999999   0.0%

Assembly complete, 0 errors. 0 warnings

 

 

 

 

_____________________

test with the Atmega8 files asm 1+2:

 

m8def,inc from AVR-Studio (Asm1 ?):

;***** Specify Device
.device ATmega8

Run without error in avra-compiler

 

 

 

m8def.inc from the DFP-package it the same as the toolchain (Asm2 ?):


#pragma partinc 0
; ***** SPECIFY DEVICE ***************************************************
.device ATmega8
#pragma AVRPART ADMIN PART_NAME ATmega8
.equ    SIGNATURE_000    = 0x1e
.equ    SIGNATURE_001    = 0x93
.equ    SIGNATURE_002    = 0x07
#pragma AVRPART CORE CORE_VERSION V2E

Error from avra-compiler:

 

Pass 1...
m8def.inc(44) : PRAGMA directives currently ignored
m8def.inc(48) : PRAGMA directives currently ignored
m8def.inc(53) : PRAGMA directives currently ignored
m8def.inc(690) : PRAGMA directives currently ignored
m8def.inc(691) : PRAGMA directives currently ignored
m8def.inc(692) : PRAGMA directives currently ignored
m8def.inc(693) : PRAGMA directives currently ignored
m8def.inc(734) : PRAGMA directives currently ignored
Pass 2...
m8def.inc(44) : PRAGMA directives currently ignored
m8def.inc(48) : PRAGMA directives currently ignored
m8def.inc(53) : PRAGMA directives currently ignored
m8def.inc(690) : PRAGMA directives currently ignored
m8def.inc(691) : PRAGMA directives currently ignored
m8def.inc(692) : PRAGMA directives currently ignored
m8def.inc(693) : PRAGMA directives currently ignored
m8def.inc(734) : PRAGMA directives currently ignored
done

 

Used memory blocks:
   Code      :  Start = 0x0000, End = 0x0008, Length = 0x0009

Assembly complete with no errors.   (??????????)

 

 

 

 

Last Edited: Wed. Dec 13, 2017 - 07:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apparently Digi-Key has a tiny40 sale on; no other distributor comes close.

Something to pass on.  Thanks.

 

That exact the problem that the attiny 102/104 def.inc file dont run in avra, and only run in "wine avrassembler2.exe ....."

You've noticed that this thread is about the Atmel toolchain... as in AVR GCC... yes?

"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

Sort-of related, so rather than starting a new thread...

 

A quick search of previous threads didn't reveal anything, but I have a nagging and possibly false memory of this being asked before.

 

In the datasheet for the t102/104:

For a write operation, the low byte of the 16-bit register must be written before the high byte. The low byte is then written into the temporary register. When the high byte of the 16-bit register is written, the temporary register is copied into the low byte of the 16-bit register in the same clock cycle.

This is the opposite of every other mega or tiny I've ever come across.  Is this accurate?

 

If it is, the Atmel toolchain 3.6.1 (gcc 4.9.2) got it wrong:

  OCR0A = 0x1234;
  40:	44 e3       	ldi	r20, 0x34	; 52
  42:	52 e1       	ldi	r21, 0x12	; 18
  44:	57 bd       	out	0x27, r21	; 39
  46:	46 bd       	out	0x26, r20	; 38

Note the high byte is written first.

 

Is this simply the work of an over-zealous technical writing intern who said to himself "that can't be right..."?  Looks like it, as a contrary passage appear later:

Accessing the low byte triggers the 16-bit read or write operation: When the low byte of a 16-bit register is written by the CPU, the high byte that is currently stored in TEMP and the low byte being written are both copied into the 16-bit register in the same clock cycle. When the low byte of a 16-bit register is read by the CPU, the high byte of the 16-bit register is copied into the TEMP register in the same clock cycle as the low byte is read, and must be read subsequently.

 

Note:  To perform a 16-bit write operation, the low byte must be written before the high byte. For a 16-bit read, the low byte must be read before the high byte.

The code examples which follow in the datasheet also use the traditional write-high-first approach.

 

I don't have real hardware yet or I would just test this myself.

 

Anyone from Microchip reading this?  Either way, one of them is a datasheet errata.

"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

There is no special-casing, cf.

 

https://gcc.gnu.org/viewcvs/gcc/...

 

It may also be the case that SP handling introduces glitches as it uses classic scheme:

 

https://gcc.gnu.org/viewcvs/gcc/...

https://gcc.gnu.org/viewcvs/gcc/...

 

Test case:

/* avr-gcc sfr.c -mmcu=avrtiny -S -Os */

#define SFR (*(__UINT16_TYPE__ volatile*) (0x2 + __AVR_SFR_OFFSET__))

extern __UINT16_TYPE__ volatile b __attribute__((absdata));

void fun (__UINT16_TYPE__ volatile *sfr)
{
    SFR = SFR;
    *sfr = *sfr;
    b = b;
}

extern void f (int*);

__attribute((signal,externally_visible))
void __vector1 (void)
{
    int a [10];
    f (a);
}

__attribute((interrupt,externally_visible))
void __vector2 (void)
{
    int a [10];
    f (a);
}

Apart from this, relying on TEMP register is fragile: If an ISR also use TEMP, then it will clobberes by the ISR, e.g. for SP.  Or is there a individual TEMP for each 2-byte SFR? Even better, 2-byte SFRs should be handled like SP, i.e. the first access inhibits interrupts for 1 cycle.

 

IMO support should know the definite answers.  The original tiny support was supplied by Atmel, so there must be knowledge there.

avrfreaks does not support Opera. Profile inactive.

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

There is no special-casing, cf.

Ah.  Shows how often I've worked with Xmega.  So it seems there's a copy/paste error into the t102/104 datasheet from an xmega datasheet w.r.t. 16-bit accesses, but only in one place...?

 

Your cf to avr.c and avr.md are a little over my head :)

 

Larryvc pointed me to the t1616 'xtiny', for which the current toolchain does in fact generate xmega-style write-low-first code.

 

Apart from this, relying on TEMP register is fragile:

Noted in datasheets:

Interrupts can corrupt the timed sequence if an interrupt is triggered and accesses the same 16-bit register during an atomic 16-bit read/write operation. To prevent this, interrupts can be disabled when writing or reading 16-bit registers.

I wouldn't expect the toolchain to handle that for me, though.

 

Or is there a individual TEMP for each 2-byte SFR?

Individual TEMP for each peripheral:

The TCNT0, OCR0A/B, and ICR0 are 16-bit registers that can be accessed by the AVR CPU via the 8-bit data bus. The 16-bit register must be accessed byte-wise, using two read or write operations. Each 16-bit timer has a single 8-bit TEMP register for temporary storing of the high byte of the 16-bit access. The same temporary register is shared between all 16-bit registers within each 16-bit timer.

.

.

.

Not all 16-bit accesses uses the temporary register for the high byte. Reading the OCR0A/B 16-bit registers does not involve using the temporary register.

 

 

Note, I've found other instances in the same datasheet that refer to the xmega-style write-low-first rule.

"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

> So it seems there's a copy/paste error into the t102/104 datasheet from an xmega

> datasheet w.r.t. 16-bit accesses, but only in one place...?

 

Only the hardware support has such profund knowledge and whether something is a feature, a silicon bug or an erratum in the manual.

 

> the t1616 'xtiny', for which the current toolchain does in fact generate xmega-style write-low-first code

 

xtiny is xmega.  The "tiny" only refers to the footprint.

 

avrfreaks does not support Opera. Profile inactive.

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

joeymorin wrote:
I wouldn't expect the toolchain to handle that for me, though.
It might though would be in the compiler manual either within it, or, in the implementation defined part.

Embedded C does have a recommendation for atomic that's linked to an IO requirement.

 

avr-libc  2.0.0

Standard C library for AVR-GCC

atomic.h File Reference

http://www.nongnu.org/avr-libc/user-manual/atomic_8h.html

CodeVisionAVR Documentation

http://hpinfotech.ro/cvavr_documentation.html

(unzip 6MB, PDF, page 193)

4.14.1 Bit level access to the I/O Registers

(by macros)

(page 194)

(note states XMEGA I/O registers are atomic otherwise it's first 32 I/O registers are atomic)

IAR Systems

User Guides: IAR Embedded Workbench for Atmel AVR

https://www.iar.com/support/user-guides/user-guides-iar-embedded-workbench-for-atmel-avr/

http://ftp.iar.se/WWWfiles/AVR/webic/doc/EWAVR_CompilerReference.pdf (4.6MB)

(page 215)

PROTECTING SIMULTANEOUSLY ACCESSED VARIABLES

(volatile attribute may result in atomic though the __monitor attribute is atomic)

C - Project status and milestones

http://www.open-std.org/JTC1/SC22/WG14/www/projects

...

TR 18037: Embedded C

http://www.open-std.org/JTC1/SC22/WG14/www/projects#18037

(366 KB PDF, page 91)

C.4  Atomic operation

 

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

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

gchapman wrote:

joeymorin wrote:
I wouldn't expect the toolchain to handle that for me, though.
It might though would be in the compiler manual either within it, or, in the implementation defined part.

Perhaps, but remember that Joey and many others, myself included, are using the "infinite-value" toolchain... ;-)  Would like to know if this is the case though.

"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

The reason I wouldn't expect the toolchain to do it for me is that it won't be needed in every case.  It would only be an issue if more than one thread of execution makes an access to a 16-bit register belonging to a peripheral, e.g. main thread reads TCNTn[H:L], interrupt thread writes OCRnA[H:L].  Unless that is the case, unsolicited atomic protection performed by the toolchain would be superfluous and inefficient.  I wouldn't want it doing that for all uint16_t in SRAM, either.  That should be the developer's call.

"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

The reason I wouldn't expect the toolchain to do it for me is that it won't be needed in every case.

 

The reason for why gcc doesn't do it is the same for why 2-byte values are not accessed atomically:

/* Limits of sig_atomic_t */
/* signal.h is currently not implemented (not avr/signal.h) */

/** \ingroup avr_stdint
    largest positive value a sig_atomic_t can hold. */

#define SIG_ATOMIC_MAX INT8_MAX

/** \ingroup avr_stdint
    smallest negative value a sig_atomic_t can hold. */

#define SIG_ATOMIC_MIN INT8_MIN

Only 1-byte aligned 1-byte values can be accessed atomically, and there is no support for C++'s std::atomic or C's stdatomic.h.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
xtiny is xmega.  The "tiny" only refers to the footprint.
Thank you for clarifying that.

"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

and they can do 5V! That's more than an XMega can do! (It's kind of handy, and many of the ARM's at least tolerate 5V).

Pages