Nabble - AVR - General

Re: Si Prog 2.2 Schematic

2009-12-12T10:13:46Z

Bill Rochat <bill@...> wrote:

> The schematic for said programmer may be found at:
>
> http://www.lancos.com/siprogsch.html

Then I wonder what the OP meant by distinguishing between the "siprog
2.2" and the "original siprog" programmer. This one is basically the
only schematic I know of, now that I'm looking at it.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Si Prog 2.2 Schematic

2009-12-12T00:27:56Z

The schematic for said programmer may be found at:

http://www.lancos.com/siprogsch.html

Bill Rochat
R&R Technologies, Inc.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Si-prog 2.2

2009-12-11T23:46:57Z

Mateusz Ka <twinsjg@...> wrote:

> I have question about si porg 2.2 programmer
> that averdude support that programer or just basic si prog.

Sorry, I don't have the slightest idea. Do you have any
reference for it, e.g. where one could find the schematic
of that programmer?

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

help

2009-12-11T16:27:44Z

On start sorry for my english .I have question about si porg 2.2 programmer that averdude support that programer or just basic si prog. I try to program atinny2313 and ther is some problem
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.

i google it but i didn't find anything. Thank for help .
TWin

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Si-prog 2.2

2009-12-11T16:26:05Z

On strat sorry for my english .I have question about si porg 2.2 programmer that averdude support that programer or just basic si prog. I try to program atinny2313 and ther is some problem
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.

i google it but i didn't find anything. Thank for help .
TWin

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

RE: Expanding the ATxmega support in the toolchain

2009-11-23T16:03:35Z

Note that these header files are never trivial. There are automatically generated from the XML device files that are shipped with AVR Studio. If AVR Studio doesn't have the XML files, then we don't have the header files for them. Adding support for a device requires more than just adding a header file.

Support for a fair number of those devices are already done. Some won't be done by the next release.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Expanding the ATxmega support in the toolchain

2009-11-22T23:17:28Z

Weddington, Eric wrote:
> 1. The "architectures" that are listed in the toolchain have absolutely nothing to do with the architectures or families of chips. They are just convenient categories or groups to put chips in that have similar features that the toolchain needs to know about.
Right, they're for things like different instruction availability,
memory sizes, etc. I'm just not seeing any differences between the
architectures as defined in binutils except for the name. Are there
differences buried inside gcc (which I haven't had time yet to look at)?

> 2. Let me know the exact chips you're interested in having support for, and I'll take care of it for you.
Ideally all of the chips they list as available at this point:

64,128,192,256 A1
64,128,192,256 A3
16,32,64,128 A4

The peripherals are identical in each of the A lines, so the headers
should be trivial if they don't already exist, it's just specific
references to most of those combinations that seem to be missing in the
latest patches I can find.

I'm using the 16A4 in lieu of the 128A4 right now because I couldn't
easily find a source of small quantity of the right package. A later
stage of this contract will likely involve an A1 chip.

Thanks,
Omega
aka Erik Walthinsen
omega@...

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

RE: Expanding the ATxmega support in the toolchain

2009-11-22T18:43:21Z

1. The "architectures" that are listed in the toolchain have absolutely nothing to do with the architectures or families of chips. They are just convenient categories or groups to put chips in that have similar features that the toolchain needs to know about.

2. Let me know the exact chips you're interested in having support for, and I'll take care of it for you.

3. And for support for the ATxmega16A4, I already have it done. The next release of WinAVR will be roughly mid-December. If you need the patches to build a Linux toolchain, I can send them on to you.

Eric Weddington

> -----Original Message-----
> From: avr-chat-bounces+eric.weddington=atmel.com@...
> [mailto:avr-chat-bounces+eric.weddington=atmel.com@...]
> On Behalf Of Erik Walthinsen
> Sent: Sunday, November 22, 2009 5:51 PM
> To: avr-chat@...
> Subject: [avr-chat] Expanding the ATxmega support in the toolchain
>
> I've got boards ready to populate for a [paid] prototyping
> project that
> are going to be getting ATxmega16a4's (for lack of anybody selling
> 64a4's...). The problem is, even the WinAVR patches don't
> seem to show
> any support for anything other than the 64a1 and 128a1.
>
> I'm going to be adding support for the 16a4, and probably every other
> chip actually nominally available at this point, and submitting the
> patches soon (since this is the next roadblock for me to blast through
> on this contract).
>
> However, I'm *royally* confused by the presence of the avrxmega2-7
> "architectures". There seems to be no correlation between the arch
> number and the chip it's supposed to represent, as per the table at
> http://www.nongnu.org/avr-libc/user-manual/using_tools.html Further,
> the table refers to a number of chips that don't even exist
> (the D* series).
>
> From my understanding of both Atmel's very clearly stated goal, and a
> lot of time reading the datasheets, there should be *1* "architecture"
> for all the existing chips, that would be the atxmegaA. The
> only other
> that might make sense could be a <=64KB variant.
>
> Anyone able to shed light on what's up with these architectures and
> whether they actually mean anything, or would it make sense
> to collapse
> them down as part of adding full support to all the current chips?
>
> TIA,
> Omega
> aka Erik Walthinsen
> omega@...
>
>
> _______________________________________________
> AVR-chat mailing list
> AVR-chat@...
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Expanding the ATxmega support in the toolchain

2009-11-22T16:50:39Z

I've got boards ready to populate for a [paid] prototyping project that
are going to be getting ATxmega16a4's (for lack of anybody selling
64a4's...). The problem is, even the WinAVR patches don't seem to show
any support for anything other than the 64a1 and 128a1.

I'm going to be adding support for the 16a4, and probably every other
chip actually nominally available at this point, and submitting the
patches soon (since this is the next roadblock for me to blast through
on this contract).

However, I'm *royally* confused by the presence of the avrxmega2-7
"architectures". There seems to be no correlation between the arch
number and the chip it's supposed to represent, as per the table at
http://www.nongnu.org/avr-libc/user-manual/using_tools.html Further,
the table refers to a number of chips that don't even exist (the D* series).

From my understanding of both Atmel's very clearly stated goal, and a
lot of time reading the datasheets, there should be *1* "architecture"
for all the existing chips, that would be the atxmegaA. The only other
that might make sense could be a <=64KB variant.

Anyone able to shed light on what's up with these architectures and
whether they actually mean anything, or would it make sense to collapse
them down as part of adding full support to all the current chips?

TIA,
Omega
aka Erik Walthinsen
omega@...

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

New AVR Dragon software (Studio 4.18rc4) won't cooperate

2009-11-21T09:41:34Z

AVR Studio 4.18 comes with AVR Dragon software which removes the 32k
debugging barrier. So I happily installed AVR Studio 4.18 Release
Candidate 4 from http://www.atmel.no/beta_ware/ on a Windows machine
and updated my 2 Dragons.

The result was: they cooperated neither with avrdude nor with avarice
any more, reporting wrong device IDs (avarice: 0xffff for both
ATmega32 and ATmega644, avrdude: 0x70febb instead of 0x139307 for an
ATmega8). I had to reinstall an older version of AVR Studio and
downgrade the Dragons using it to get them into a usable state again.

Did anybody encounter the same issue? Or is an updated version of
these tools available or planned?

Heike

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Fwd: Re: avrdude high-voltage programming]

2009-11-11T07:29:31Z

Thanks for your advice Markus, I have solved the problem.
I had a very unpleasant hardware fault on my STK500. Quite why it
appeared to work under AVR studioa nd not under AVRDUDE is still a
mystery - but that's life.
Although I bought it new, from a reputable shop, once I started really
looking closely I noticed that it had been soldered in some places. The
high voltage generator had all 4 transistors blown, so I had to replace
them.
Allworks fine with AVRDUDE now.

Robert

EDIT: I have never even touched the HV programmer, but from the Invalid
device signature i got the idea, that this might help.

2009/11/10 markus järve <markus.dnd@... <mailto:markus.dnd@...>>

looks like problem i had with AVRISP2. What i did was to change SCK
on avrdude.

$ sudo avrdude -c avrispmkII -P usb -p m88 -F -u -t

i did set it on 4 and it started to work like charm.

Maybe usefull

Cmc

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

avrdude high-voltage programming

2009-11-10T04:48:30Z

I am currently working on several Attiny projects. One of these needs an
extra I/O so I must use the RESET pin. This necessitates the use of
high-voltage serial programming.
I am completely unable to get AVRDUDE to talk to my STK500v2 in hvsp mode.

*************************************************************************
avrdude -p t13 -c stk500hvsp -P /dev/ttyS1 -B 15 -t -F

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny13 is 1E 90 07
avrdude>
*************************************************************************
This is AVRDUDE version 5.8 on OpenSUSE 10.2

Using the same PC and STK500, over the same serial port but driven from
AVR Studio on Windows XP running in a VMware virtual machine, I can
succesfully program, read & write the part. This seems to exonerate the
hardware. Also the same combination of PC, STK500 and Tiny13 programs
fine in 'normal' mode (P stk500v2).

Has anyone experience of the high-voltage serial mode or can see what I
am doing wrong?

Many thanks,

Robert von Knobloch

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Avrdude for the Axon

2009-10-26T22:21:14Z

Koh Wei Jie <weijie90@...> wrote:

> Does anyone know how to get the Axon working on Linux?

The bootloader they are using does not appear to speak any
of the protocols AVRDUDE talks.

http://www.societyofrobots.com/axon/axon_getting_started_bootloader.shtml

There's a link to a Linux/MacOS control software for it on that page.
No idea how well it works, no idea whether that protocol could be
integrated into AVRDUDE. After all, it would require someone to
actually do it. The author of the bootloader, Peter Dannegger,
doesn't appear to be interested in AVRDUDE and/or non-Windows systems
at all.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Avrdude for the Axon

2009-10-26T19:45:36Z

Hi,

Does anyone know how to get the Axon working on Linux? http://www.societyofrobots.com/axon/

I tried this:

avrdude -p atmega640 -P /dev/ttyUSB0 -c stk600 -U flash:w:Axon.hex

avrdude: stk500_2_ReceiveMessage(): timeout

...

Thanks!

Koh Wei Jie

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T13:26:45Z

On Fri, Oct 23, 2009 at 01:01:49PM -0700, Matthew MacClary wrote:
> On Fri, Oct 23, 2009 at 12:20 PM, Joerg Wunsch <j@...> wrote:
> > Curious question from a non-MacOS but Emacs user: why -nw? ?Is the
> > windowing version not supported? ?(I use emacs -nw when being logged
> > into a remote side through ssh, but would always prefer the graphical
> > front-end otherwise.)
>
> There are two parts to this answer first: I seem to remember that at
> least on older versions of MacOS emacs was included, but the GUI
> didn't run.

I have the XCode development and X11 installed. Emacs is present and
runs in Terminal.app. Perhaps if X11 was running emacs could run GUI.

On MacOS X I prefer BBedit. Also keep a Terminal.app window open from
which to run Make and svn. SVN runs from within BBedit but for some
reason (that I've forgotten) I haven't bothered to teach BBedit about my
svn server.

Using svn from command line invokes vim to edit commit comments. :-)

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T13:01:49Z

On Fri, Oct 23, 2009 at 12:20 PM, Joerg Wunsch <j@...> wrote:
> Curious question from a non-MacOS but Emacs user: why -nw? Is the
> windowing version not supported? (I use emacs -nw when being logged
> into a remote side through ssh, but would always prefer the graphical
> front-end otherwise.)

There are two parts to this answer first: I seem to remember that at
least on older versions of MacOS emacs was included, but the GUI
didn't run. Also if the OP needed to install emacs then I would put
the chances of success for getting the console version running at 98%
and changes for gui version at 80% just because of added complexity
from toolkit and X server version compatibility and pre-requisites.

Second part of the answer is that I never used the Emacs GUI. It does
work fine and has many innovative features. However, I learned emacs
mostly from the console and started aliasing emacs to 'emacs -nw'
years ago so that I wouldn't accidentally try to start up a remote X
gui.

I find the console emacs to be slightly lower latency and it works on
every platform I have tried it on with minimal configuration and no X
server to setup. For example you can run emacs -nw under Cygwin fast
and easy, but running an X server is slower and less reliable. Since I
never touch the mouse when editing text, I don't miss any mouse
related GUI features. Also it is very fast to type ^Z to get to the
console and do other tasks or switch to a backgrounded emacs session
with a different working directory related to a completely different
project.

A guess a final point is that for a Mac user the command line editor
might look cool and unixy, but the emacs GUI might just look ugly.
(Maybe there is a nice carbon GUI available now for Mac I wouldn't
know.)

Probably more info than you wanted...

-Matt

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T12:20:39Z

Matthew MacClary <macclary@...> wrote:

> Emacs (emacs -nw) is a great editor for the Mac.

Curious question from a non-MacOS but Emacs user: why -nw? Is the
windowing version not supported? (I use emacs -nw when being logged
into a remote side through ssh, but would always prefer the graphical
front-end otherwise.)

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T09:14:00Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 23.10.2009 um 17:43 schrieb Ruud Vlaming:
>> Anyone know a good editor with make/avrdude integration for mac?
> I make use of eclipse.
> http://www.eclipse.org/cdt/
>
> It took me a while to get used too, but it works fine now.
> Of course avrdude is not integrated, but it is easy to define
> it as 'external tool', and after that, you don't notice the
> difference. I also let eclipse call the avr-gcc build by my own
> toolchain installer. You can fine-tune everything.

I'm using Eclipse with the AVR Eclipse Plugin (http://avr-eclipse.sourceforge.net
).

Timo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)

iEYEARECAAYFAkrh1k0ACgkQDH/BX4067fI5gACePMDQDq2kzT0HAds1etooHPN5
M5MAoL9xAv+qlr1J/K9sgdtO3lHFfBoo
=Q5Kn
-----END PGP SIGNATURE-----

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T08:43:21Z

On Wednesday 21 October 2009 21:44, Halvor Platou wrote:

> Anyone know a good editor with make/avrdude integration for mac?
I make use of eclipse.
http://www.eclipse.org/cdt/

It took me a while to get used too, but it works fine now.
Of course avrdude is not integrated, but it is easy to define
it as 'external tool', and after that, you don't notice the
difference. I also let eclipse call the avr-gcc build by my own
toolchain installer. You can fine-tune everything.

The only thing what is not possible, is to let it generate my
own code style. ;-) But that is kind of akward too i guess :?

Ruud

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T08:12:35Z

Emacs (emacs -nw) is a great editor for the Mac. It provides quick
access to make and avrdude.

-Matt

On Fri, Oct 23, 2009 at 7:57 AM, Peter Loron <peterl@...> wrote:

> http://www.obdev.at/products/crosspack/index.html
>
> Also, I know folks are using both XCode and Eclipse on the mac for AVR work.
>
> Google is your friend.
>
> -Pete
>
> On Oct 21, 2009, at 12:44 PM, Halvor Platou wrote:
>
>> Hello,
>>
>> Anyone know a good editor with make/avrdude integration for mac?
>>
>>
>> _______________________________________________
>> AVR-chat mailing list
>> AVR-chat@...
>> http://lists.nongnu.org/mailman/listinfo/avr-chat
>
>
>
> _______________________________________________
> AVR-chat mailing list
> AVR-chat@...
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: Mac AVR development

2009-10-23T07:57:24Z

http://www.obdev.at/products/crosspack/index.html

Also, I know folks are using both XCode and Eclipse on the mac for AVR
work.

Google is your friend.

-Pete

On Oct 21, 2009, at 12:44 PM, Halvor Platou wrote:

> Hello,
>
> Anyone know a good editor with make/avrdude integration for mac?
>
>
> _______________________________________________
> AVR-chat mailing list
> AVR-chat@...
> http://lists.nongnu.org/mailman/listinfo/avr-chat

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Mac AVR development

2009-10-21T12:44:59Z

Hello,

Anyone know a good editor with make/avrdude integration for mac?

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-21T04:38:58Z

On Sun, Oct 18, 2009 at 11:17:26AM +0200, Heike C. Zimmerer wrote:
> do nothing if they match, do a full erase/write if they differ, and do a
> write-only if the cell contains 0xff, I could go on without increasing
> the time needed for powering down. Of cause, this only works if 0xff in
> a cell means it doesn't need to be erased.

Have you noticed that the datasheet specifies a wide margin for the
programming times of eeprom cells? (or only a max, no min?)

Internally writing an eeprom/flash cell seems to work like:

for (i=0;i<MAX;i++) {
program_cell_1_cycle (addr, value);
if (read_cell (addr) == value)
break;
}
if (i == MAX) return ERROR;
n = i;

for (i=0;i<n;i++) {
program_cell_1_cycle (addr, value);
}

In the old days you had to execute this algorithm for programming
certain chips.

A normal cell may require say 33 loops in the first loop, so 99
times through the second loop for a total of 132 programming cycles.

If you try to program 0x55, it may still read as 0xff for 30 cycles,
switch to 7f, 5f, 57, 55 over the next three cycles.

So if programming a location failed because of a powerdown, it might
still read as 0xff after 28 cycles. Then power goes down. Next time
you start up, you read 0xff, and conclude that it's still empty. This
algorithm would then find that after 7 cycles the correct value of
0x55 is present, and then run the second loop 21 times. In the end
your location got only 56 cylces of programming instead of the
intended 132. (in the short run, your cell WILL read as 0x55 for a
while. But it may creep back to another value between 0x55 and 0xff
over time or under different circumstances!)

Anyway, I'm not sure it still works like that. Maybe that the AVR
guarantees writing of the location once you start it. Maybe you can
provide the environmnent where you won't initiate an eeprom write
when power is going down "soon".

Roger.

--
** R.E.Wolff@... ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-18T10:13:41Z

j@... (Joerg Wunsch) writes:

> Yes, you can. Programming flash or EEPROM cells always goes from '1'
> to '0', so a cell containing all '1' is erased.

Thanks.

Heike

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

RE: AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-18T09:07:00Z

> -----Original Message-----
> From: avr-chat-bounces+eric.weddington=atmel.com@...
> [mailto:avr-chat-bounces+eric.weddington=atmel.com@...]
> On Behalf Of Bob Paddock
> Sent: Sunday, October 18, 2009 7:16 AM
> To: avr-chat@...
> Subject: Re: [avr-chat] AVR EEPROM cell: Does 0xff mean it it
> is erased?
>
> > IIRC only Freescale HC12 flash erases to 0. At least thats
> the only I have
> > encountered.
>
> Some serial EEPROMs, at least old Xicor ones, erased to 0xFF but as
> shipped from the factory they contained a "checker board"
> pattern. Looked more
> like junk when doing a read, because the rows and columns were
> physically different
> than what you would logically expect.

Wow. That's a bit strange.

> I asked the Xicro factory about that, and they set it was to
> expedite their
> test times. Ever since I've never made the assumption a new
> factory part
> comes in the erased state, unless that is explicitly mentioned in the
> data sheet,
> of any programmable part.

Very good point.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-18T07:16:14Z

> IIRC only Freescale HC12 flash erases to 0. At least thats the only I have
> encountered.

Some serial EEPROMs, at least old Xicor ones, erased to 0xFF but as
shipped from the factory they contained a "checker board" pattern. Looked more
like junk when doing a read, because the rows and columns were
physically different
than what you would logically expect.

I asked the Xicro factory about that, and they set it was to expedite their
test times. Ever since I've never made the assumption a new factory part
comes in the erased state, unless that is explicitly mentioned in the
data sheet,
of any programmable part.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-18T07:06:26Z

On Oct 18, 2009, at 7:55 AM, Joerg Wunsch wrote:

> "Heike C. Zimmerer" <lists@...> wrote:
>
>> can I safely assume that if an EEPROM cell contains 0xff, it doesn't
>> need to be erased before writing to it?
>
> Yes, you can. Programming flash or EEPROM cells always goes from '1'
> to '0', so a cell containing all '1' is erased.

IIRC only Freescale HC12 flash erases to 0. At least thats the only I
have encountered.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-18T05:55:33Z

"Heike C. Zimmerer" <lists@...> wrote:

> can I safely assume that if an EEPROM cell contains 0xff, it doesn't
> need to be erased before writing to it?

Yes, you can. Programming flash or EEPROM cells always goes from '1'
to '0', so a cell containing all '1' is erased.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

AVR EEPROM cell: Does 0xff mean it it is erased?

2009-10-18T02:17:26Z

Hello,

can I safely assume that if an EEPROM cell contains 0xff, it doesn't
need to be erased before writing to it?

Most newer AVRs offer the possibility to split erase and write to EEPROM
into two separate tasks, each of them taking about half the execution
time. Now let's assume I write some state data (12 bytes each) into
consecutive locations (ring buffer) every, say, 5 minutes. Under normal
conditions, there's no need to separate the tasks, but I do it anyway
(for reasons explained later) and I can make sure the next location
has been previously erased when it is written to.

However, when an external power down interrupt occurs, I need to write
the same data as fast as possible. Under normal circumstances, I know
where to write to and I know the area has been erased before so I can
use the faster write-only cycle and skip erase.

Things change when the power down INT occurs while the main program is
writing a record (i.e., the INT falls exactly into a small time slot of
22 ms every 5 minutes). Then I don't know which part of the record
already has been written out (I could keep track of but currently I hope
I don't need to) and I need to write to the same area again.

I can safely assume at most 4 of the 12 bytes will differ from what the
main program was just trying to write, so - my idea which needs to be
verified - if I compare the contents of the cells against the new data,
do nothing if they match, do a full erase/write if they differ, and do a
write-only if the cell contains 0xff, I could go on without increasing
the time needed for powering down. Of cause, this only works if 0xff in
a cell means it doesn't need to be erased.

Then there was this problem with earlier AVRs where an erased cell would
read 0x0 at low voltages, but - if I remember correctly - read 0xff when
previously having been written to with 0xff. I don't know for sure if I
remember this correctly. This may indicate that there is a difference
between being erased and being written to with 0xff.

Does anybody know more about that? As an illustration, I include the
current untested draft of the EEPROM write function:

----------------------
/*C
void eeprom_write_byte_fast(uint8_t *eeaddr, uint8_t data);

/# Write a byte to a (most possibly) erased ee-cell (faster than normal
write if the area has been erased previously).

If the cell is not yet erased, add erase cycle. If the cell already
contains the target data, return immediately. #/
*/
.global eeprom_write_byte_fast
eeprom_write_byte_fast:
sbic _SFR_IO_ADDR(EECR),EEPE
rjmp eeprom_writeNE_byte ; eeprom not yet ready
out _SFR_IO_ADDR(EEARH),r25
out _SFR_IO_ADDR(EEARL),r24 ; set addr
sbi _SFR_IO_ADDR(EECR),EERE ; get current contents of the cell
in r23,_SFR_IO_ADDR(EEDR)
cpi r22,r23 ; already same?
breq ewRet ; yes. Nothing to do.
out _SFR_IO_ADDR(EEDR),r22 ; set data
ldi r20,1<<EEPM1|1<<EEMPE ; assume write only
cpi r23,0xff ; is cell really erased already?
breq ewWriteNow ; yes
ldi r21,1<<EEMPE ; No. Do a full erase/write cycle
ewWriteNow: in r21,_SFR_IO_ADDR(SREG) ; save INT flag
cli
out _SFR_IO_ADDR(EECR),r20
sbi _SFR_IO_ADDR(EECR),EEPE ; start writing
out _SFR_IO_ADDR(SREG),r21 ; restore INT flag
ewRet: ret
----------------------

Thanks,

Heike

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

RE: ATA8741/2/3

2009-10-09T03:54:21Z

> -----Original Message-----
> From: avr-chat-bounces+eric.weddington=atmel.com@...
> [mailto:avr-chat-bounces+eric.weddington=atmel.com@...]
> On Behalf Of Ruud Vlaming
> Sent: Friday, October 09, 2009 1:11 PM
> To: avr-chat@...
> Subject: [avr-chat] ATA8741/2/3
>
> Today i saw an interesting device on Atmels website,
> the ATA 8741,8742,8744 series. They seem new,
> but i cannot see actually how new they are.
> It is an avr core (tiny44) with UHF capabilities. Does
> someone already has some experience with it?

I think that they were just recently announced, like within the last week or so. I doubt anyone has had any experience with them.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

ATA8741/2/3

2009-10-09T00:41:03Z

Today i saw an interesting device on Atmels website,
the ATA 8741,8742,8744 series. They seem new,
but i cannot see actually how new they are.
It is an avr core (tiny44) with UHF capabilities. Does
someone already has some experience with it?

Ruud

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: int to char *array[ ].

2009-10-04T05:58:32Z

On Oct 4, 2009, at 1:41 PM, markus järve wrote:

> Hello.
>
> I am having problem due to my limited knowledge of C.
>
> I have function readADC wich wil return value in integrer.
> Sadly the function LcdStr (wich is from Fandi Gunawan library for
> nokia 3310 lcd) accepts only char array pointers.
>
> So, i need to make int 123 into char *array[3] = 1, 2, 3
>
> I have been stuck on it for a day and have ran out of ideas. Maybe
> someone could point me to the right direction or help me figure it
> out.

Don't you need to use integer -> ascii conversion?
Like

char array[4];
snprintf (array, sizeof(array), "%d", readADC());

I set array to be 4 elements length, because snprintf will put
terminating zero in the last byte, but that shouldn't matter for
LcdStr, If it accepts char*.

Cheers,
Piotr

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: int to char *array[ ].

2009-10-04T05:52:32Z

On Sun, 4 Oct 2009, markus järve wrote:

char *array[3];

for (i = 0; i < 3; i++)
arrary[i] = readADC();

or perhaps..

char *array[3];

for (i = 0; i < 3; i++)
arrary[i] = readADC() + '0';

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

signature.asc (195 bytes) Download Attachment

int to char *array[ ].

2009-10-04T04:41:59Z

Hello.

I am having problem due to my limited knowledge of C.

I have function readADC wich wil return value in integrer.
Sadly the function LcdStr (wich is from Fandi Gunawan library for nokia 3310 lcd) accepts only char array pointers.

So, i need to make int 123 into char *array[3] = 1, 2, 3

I have been stuck on it for a day and have ran out of ideas. Maybe someone could point me to the right direction or help me figure it out.

Cmc

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Re: AVR Dragon JTAG programing

2009-09-27T14:16:39Z

David Lautenschlager <davidlautenschlager@...> wrote:

> Can the AVR Dragon be used to JTAG program the mega1281?

Yes, no problem at all.

The only thing that's still not supported for the AVR Dragon is
programming Xmega devices, neither by JTAG nor by PDI.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat