AVR Freaks

AVR GCC forum :: RE: Can i make this code work using GCC or start over?

Author: themanix
Subject: RE: Re: Can i make this code work using GCC or start over?
Posted: Feb 09, 2010 - 11:54 AM (GMT 1)
Topic Replies: 6

I do not know Arduino at all, I know very little C and I barely know AVR, but the question is WHY?

WHY it is done that way? looks a bit over done to me..

anyways, I do not want to make this thread in an endless debate about Arduino ... just curious

Off-topic forum :: RE: Quick endianness question, AVR vs 8051?

Author: Jepael
Subject: Re: RE: Quick endianness question, AVR vs 8051?
Posted: Feb 09, 2010 - 11:49 AM (GMT 1)
Topic Replies: 3

david.prentice wrote:

It is a bit of a mixture.

I just came across the Keil compiler site that explained it too. Some things like return addresses in stack are stored lo-hi order (CPU architecture forces it like this) but 16 and 32 bit variables are stored in hi-lo order to memory (compiler just happens to do that instead of the other way because it does not make any difference).

david.prentice wrote:

In practice you access sfr's by name. And does it really matter how a 3 byte instruction is actually stored in memory?

I really don't care as this problem has nothing to do with sfr's or instructions, the code just does not work on AVR (or any other little endian arch).

clawson wrote:

Endianness only rears it's head when you try to break large objects.

Yeah that's what the original code did. Standard cryptography algorithm using 32-bit integers but data input and output is purely optimized for the '51 and a compiler using hi-lo order.

What a mess to fix that. Now I don't know if 8-bit data is input and output in wrong order or is it the 32-bit block algorithm processing it in wrong order.

As it is a standard algorithm, I may be able to just find a black box routine that does it right on little-endian machine.

AVR GCC forum :: RE: How do YOU cut down on program size?

Author: danni
Subject: RE: Re: How do YOU cut down on program size?
Posted: Feb 09, 2010 - 11:48 AM (GMT 1)
Topic Replies: 9

Kagetsuki wrote:

I've cleaned out and simplified my code as best I can, but with full functionality I'm still running at about 1.6K.

Why not post the complete code?

Then it would esay to see, if it can be squeezed enough.
Maybe, some compiler switches are sufficient already.

Peter

AVR forum :: RE: Which board or kit to purchase for keyboard project

Author: Lizardbones
Subject: Re: RE: Which board or kit to purchase for keyboard project
Posted: Feb 09, 2010 - 11:37 AM (GMT 1)
Topic Replies: 2

Huh. The Teensy seems to do everything I would want, and the site you linked to has a sample application that does about 90% of what I was aiming to do...including the ability to send ctrl, alt and shift.

Thank you.

No kidding, I searched for a few weeks on Google with different variations of "microcontroller", "usb", "keyboard", "AVR", "Atmel", etc. and got generic information, but nothing as simple and direct as your one post. The Olimex board looked like it would do the trick (and it probably would), but again, lack of experience can be a frustrating barrier when you have a single goal in mind.

AVR GCC forum :: RE: Patches to support xmega16a4?

Author: clawson
Subject: RE: Patches to support xmega16a4?
Posted: Feb 09, 2010 - 11:27 AM (GMT 1)
Topic Replies: 1

Eric includes all the packages he applies in the WinAVR distribution. So if nowhere else you should be able to find them there.

Code:

C:\WinAVR-20100110>dir *.pat* /s

 Volume in drive C is ACER

 Volume Serial Number is C6B0-75D7

 Directory of C:\WinAVR-20100110

19/01/2010  18:08               576 40-binutils-2.19-wrong-arch.patch

19/01/2010  18:08               493 41-binutils-2.19-avr25-wraparound-reloc.patc

h

19/01/2010  18:08             1,657 42-binutils-2.19-bug-9841.patch

19/01/2010  18:08            22,161 50-binutils-2.19-xmega.patch

19/01/2010  18:08            11,578 51-binutils-2.19-new-devices.patch

               5 File(s)         36,465 bytes

 Directory of C:\WinAVR-20100110\source\avr\binutils\2.19

19/01/2010  18:08            16,260 30-binutils-2.19-avr-size.patch

19/01/2010  18:08           168,711 31-binutils-2.19-avr-coff.patch

19/01/2010  18:08             1,301 32-binutils-2.19-new-sections.patch

19/01/2010  18:08             4,881 33-binutils-2.19-data-origin.patch

19/01/2010  18:08             1,113 34-binutils-2.19-as-dwarf.patch

19/01/2010  18:08               982 35-binutils-2.19-dwarf2-AVRStudio-workaround

.patch

19/01/2010  18:08               576 40-binutils-2.19-wrong-arch.patch

19/01/2010  18:08               493 41-binutils-2.19-avr25-wraparound-reloc.patc

h

19/01/2010  18:08             1,657 42-binutils-2.19-bug-9841.patch

19/01/2010  18:08            22,161 50-binutils-2.19-xmega.patch

19/01/2010  18:08            11,578 51-binutils-2.19-new-devices.patch

              11 File(s)        229,713 bytes

 Directory of C:\WinAVR-20100110\source\avr\gcc\4.3.3

19/01/2010  18:08               392 20-gcc-4.3.3-libiberty-Makefile.in.patch

19/01/2010  18:08               924 21-gcc-4.3.3-disable-libssp.patch

19/01/2010  18:08               339 23-gcc-4.3.3-ada-Makefile.patch

19/01/2010  18:08               629 30-gcc-4.3.3-param-inline-call-cost.patch

19/01/2010  18:08             1,656 40-gcc-4.3.3-bug-10768-by-adacore.patch

19/01/2010  18:08            11,119 41-gcc-4.3.3-bug-11259_v3.patch

19/01/2010  18:08             1,606 42-gcc-4.3.3-bug-spill-v4.patch

19/01/2010  18:08             2,209 43-gcc-4.3.3-bug-35013.patch

19/01/2010  18:08             1,348 44-gcc-4.3.3-libgcc16.patch

19/01/2010  18:08             2,914 45-gcc-4.3.3-bug-33009.patch

19/01/2010  18:08               445 46-gcc-4.3.3-andsi3-wrong-attribute.patch

19/01/2010  18:08             7,348 47-gcc-4.3.3-bug-18145-v4.patch

19/01/2010  18:08            10,560 50-gcc-4.3.3-mega256-v2.patch

19/01/2010  18:08            33,036 51-gcc-4.3.3-xmega-v13.patch

19/01/2010  18:08            24,718 52-gcc-4.3.3-new-devices.patch

19/01/2010  18:08             7,276 60-gcc-4.3.3-osmain.patch

19/01/2010  18:08            16,365 61-gcc-4.3.3-builtins_v6.patch

19/01/2010  18:08             6,084 62-gcc-4.3.3-ada-mlib.patch

19/01/2010  18:08             3,458 63-gcc-4.3.3-ada-freestanding.patch

19/01/2010  18:08             2,645 64-gcc-4.3.3-ada-timebase.patch

19/01/2010  18:08             1,312 65-gcc-4.3.3-ada-gnat1_print_path.patch

19/01/2010  18:08             3,026 66-gcc-4.3.3-ada-optim_static_addr.patch

              22 File(s)        139,409 bytes

_________________

AVR studio 4 forum :: RE: EEPROM read/write problem with Atmega88P

Author: clawson
Subject: RE: EEPROM read/write problem with Atmega88P
Posted: Feb 09, 2010 - 11:25 AM (GMT 1)
Topic Replies: 1

I'll bite - if this is avr-gcc/AVR-LibC why are you reinventing the EEPROM routines that are in <avr/eeprom.h> and that work very well?

http://www.nongnu.org/avr-libc/user-man ... eprom.html
_________________

AVR forum :: RE: AVR vs 6502

Author: clawson
Subject: RE: Re: RE: Re: RE: Re: RE: Re: RE: Re: RE: Re: RE: Re: RE:
Posted: Feb 09, 2010 - 11:15 AM (GMT 1)
Topic Replies: 66

Quote:

Most C afficionados sincerely do believe that asm is hard and C is easy

For me it's not a question of "hard" vs "easy" but more vs less typing. You can achieve in one line of C what you'd need to type 10 lines of Asm to do (the output of the C compiler will show this regularly). THAT is why I switched to using C in about 1995 after having done Asm (mainly Z80) for 15 years. In my time I've written a WYSIWYG word processor/spreadsheet in Z80 Asm: http://web.ukonline.co.uk/cliff.lawson/anne.htm and http://toastytech.com/guis/pcw.html as well as some of the Sinclair Spectrum operating system so I've done more than my share of Asm but if I had the time again and the tools had been available at the time I'd have done the word pro in C (maybe not the Spectrum - that did need hand optimised Asm)
_________________

AVR forum :: RE: Atmega for GPS

Author: clawson
Subject: RE: Atmega for GPS
Posted: Feb 09, 2010 - 11:08 AM (GMT 1)
Topic Replies: 1

So what have you set the CKSEL and CKOPT fuse bits to?
_________________

AVR forum :: RE: M-Bus and AVR

Author: clawson
Posted: Feb 09, 2010 - 11:07 AM (GMT 1)
Topic Replies: 3

Bjorn,

You do realise that the two previous posts in this thread were in 2005 and 2006 don't you?

Cliff
_________________

Off-topic forum :: RE: Tell me difference between Windows 7 and Windows 7 Upgrade

Author: sprinkmeier
Subject: Re: RE: Re: RE: Re: RE: Re: RE: Re: RE: Re: RE: Re: RE: Tell
Posted: Feb 09, 2010 - 10:54 AM (GMT 1)
Topic Replies: 55

clawson wrote:

Quote:

this is a trivial restriction

You're not a commercial programmer are you?

Actually I am.

clawson wrote:

The GPL V2 licence used in Linux is it's largest barrier to widespread commercial use.

I was talking about license restrictions form the end user perspective. My point was that 99+% of end-users of the GPL will never be constrained by it in any way, while 99% of end-users of commercial software probably will be restricted in some way (can't copy, crippled functionality, etc...)

As for 'commercial use', the GPL is little or no barrier to most 'commercial users' who never mod the code, or mod the code but keep the binaries in-house.

So that leaves the 'commercial users' who actually mod the code AND release binaries.
If they don't like the GPL they can opt for one of the other OSS licenses, the L-GPL, Apache, BSD etc, negotiate for dual-licensing, or get a commercial library that does the same thing.
No one is forcing anyone to use GPL code.
If you use GPL code the upside is that it's 'free as in beer', the downside is that you have to share mods/improvements (of course, so do all other users of the code, so you get their improvements too).

Whatever license you choose there'll be upsides and downsides. That's life.

BTW, I'm watching my PVR (GPL inside) on my TV (GPL inside) while posting this through my gateway (GPL inside)... Apparently the manufacturers of all these devices thought the GPL was a good deal.

clawson wrote:

It's rather ironic that Linus Torvalds himself does not actually agree with the interpretation of GPLV2 as seen by Stallman and the FSF. He's all for commerial use of Linux and does not see dynamically loaded kernel modules as tainting the kernel for the purposes of GPL but the Stallman mafia do and they persue this with a vengeance ensuring that Linux remains in the realms of the beardy nerd alone.

Linus and Stallman can disagree, just as I'm sure Steve Jobs and Bill Gates do. So What?

AVR32 Linux Forum :: RE: fsck rootfs on SD card

Author: PaoloArea
Posted: Feb 09, 2010 - 10:52 AM (GMT 1)
Topic Replies: 9

Does is not dangerous for the life of SD card the use of EXT3 file system?

AVR studio 4 forum :: RE: EEPROM from atXmega128A1 in Studio4

Author: david.prentice
Subject: RE: EEPROM from atXmega128A1 in Studio4
Posted: Feb 09, 2010 - 10:51 AM (GMT 1)
Topic Replies: 1

The xmega eeprom should program just the same as any other AVR.

Your assembler / compiler generates a project.eep file. This is just a regular Intel Hex file, the same as any program file.

You read and write to the eeprom in the Program tab of the Studio Programming dialog.

The 'User Signature' area is something completely different. You can read / edit / write this area in the Advanced tab.

David.

AVR forum :: RE: PWM Channels

Author: clawson
Subject: RE: Re: RE: PWM Channels
Posted: Feb 09, 2010 - 10:47 AM (GMT 1)
Topic Replies: 18

Quote:

Or would each channel's signal go to a different PCINT pin?

Each servo would have it's own pin (not sure why you mentioned "PCINT" that's irrelevant) driving it's own 1ms..2ms width pulse every 20ms.

As for splitting PPM - read about how the decoder in the Rx does this on pages 4/5 of this:

http://www.omegaco.demon.co.uk/mectnpdf/mectn005.pdf

In particular fig 30 on page 5. You could decode E rather than F,G,H,I individually.
_________________

AVR GCC forum :: RE: bit shifting

Author: clawson
Subject: RE: Re: bit shifting
Posted: Feb 09, 2010 - 10:35 AM (GMT 1)
Topic Replies: 6

Quote:

byteVal * 256 = new byteVal

What language is that? - clearly not C, the use of the 'new' operator hinted at C++ but that also would not allow the expression on the left?
_________________

AVR forum :: RE: XMEGA JTAG interface current consumption

Author: ifor
Subject: RE: XMEGA JTAG interface current consumption
Posted: Feb 09, 2010 - 10:22 AM (GMT 1)
Topic Replies: 1

You can disable the jtag interface in software so you should be able to mesure the curent yourself. After a reset the interface will be re-enabled. All the nessasary code is in AVR1010 the low power app note.