Hi All,
I just committed a patch to HEAD and 1.6 branch to add support to a bunch of
new devices.
Two things:
- New policy: There are a bunch of new devices coming out from Atmel that have
an 'A' suffix. In most cases, these are the same devices without the 'A'
suffix, except that they are
As Bob Paddock wrote:
That would be worth a bug report, I'd say.
MCUCR in the Mega162:
SRE SRW10 SE SM1 ISC11 ISC10 ISC01 ISC00
MCUCR in the Mega325:
JTD - - PUD - - IVSEL IVCE
Ah, I see... OK, that's multiple generations of AVRs between both, so
the contents of MCUCR gradually shifted.
On Saturday 14 July 2007 08:55, Joerg Wunsch wrote:
[...]
The question now is, what to chose for the name of TCCR0B when it's
defined as the union/bitfield sketched out above? If we call that
TCCR0B, the old way of handling TCCR0B like
TCCR0B = _BV(CS00) | _BV(CS02);
would be
As Bob Paddock wrote:
(About MISRA and bit-fields.)
A *signed* integer requires two bits, one for the value, the other
for the sign of the value. Don't see that as an issue,
as it would not make sense to have a signed register bit for I/O.
Sure, that way, it makes sense. I'm pretty sure we
As Bob Paddock wrote:
Atmel sometimes transfers bits from one register
to another (for example, SE is moved from MCUSR to SMCR).
What is even worse is when they use the same register name
for completely different functions, which I've ran into
when moving code from one device to an other.
On Sunday 15 July 2007 15:22, Joerg Wunsch wrote:
When concerned about software safety, I'd even prefer them if the code
grew (because of becoming a read/modify/write operation rather than an
assignment), as it helps preventing fatal errors. Obviously, unless
the code size growth or slower
As Dmitry K. wrote:
TCCR0B = _BV(CS00) | _BV(CS02);
would be rewritten as
TCCR0B_.byte = _BV(CS00) | _BV(CS02);
A small note: the above expressions are *different*.
No, they aren't. The .byte union member simply access the entire
8-bit IO register the same way as the current
As Eric Weddington wrote:
There are new devices that need support:
AT90PWM216
AT90PWM316
ATmega48P
ATmega88P
ATmega168P
ATmega328P
AT90PWM2B
AT90PWM3B
And possibly ATA6289, though I would have that as a lower priority.
Note that this issue came up because IAR recently announced support
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Joerg Wunsch
Sent: Friday, July 13, 2007 3:55 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] New device support
As Eric Weddington wrote:
There are new devices that need
As Bob Paddock wrote:
union tccr0b {
uint8_t byte;
struct {
uint8_t cs0: 3;
uint8_t wgm02: 1;
uint8_t : 2;
uint8_t foc0b: 1;
uint8_t foc0a: 1;
} bits;
};
MISRA-2004 rule 6.4: Bit fields shall only be
Joerg Wunsch schrieb:
Rule 6.5: Bit fields of type signed int shall be at least two bits
long.
That makes no sense at all to me (but that's not surprising with
MISRA, I'd say ;-).
*signed* ints do need two bits at least, one for the sign and one for
the number. I read rule 6.5 as
On Saturday 14 July 2007 15:24, Joerg Wunsch wrote:
As Bob Paddock wrote:
Rule 6.5: Bit fields of type signed int shall be at least two bits
long.
That makes no sense at all to me (but that's not surprising with
MISRA, I'd say ;-). I don't see any value in that requirement,
and
it's
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Joerg Wunsch
Sent: Saturday, July 14, 2007 2:04 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] New device support
As Eric Weddington wrote:
provided we are granted the right
13 matches
Mail list logo
