Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #76134

Re: Parsing a rotated stream of 64 bits

Show all headers | View raw

On 15/11/15 02:57, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>

>> Just to get you started with the AVR, beyond what I wrote earler:
>>
>> <https://en.wikipedia.org/wiki/Atmel_AVR>
>>
>> It's an 8-bit microcontroller architecture, made by Atmel.  The main
>> product page is here:
>>
>> <http://www.atmel.com/products/microcontrollers/avr/default.aspx>
>>
>> (There is also an "AVR32" made by Atmel - it shares little with the AVR
>> except the name.  Although the main compiler for the AVR32 is also gcc,
>> it is outside the main gcc tree and maintained entirely by Atmel.
>> Basically, the AVR32 is a dead-end architecture, since Atmel also make
>> ARM microcontrollers - a shame really, since it was quite a nice cpu.
>> So here we are only discussing the 8-bit AVR devices.)
>>
>> Pick a device if you want to see the datasheet and read about the cpu:
>>
>> <http://www.atmel.com/devices/ATMEGA3250.aspx?tab=documents>
>
> Apparently pozz is targeting the tiny4314 rather than the mega3250.
> But I can make those adjustments.

Indeed.  I just used the Mega3250, as it's a chip I have used on a 
couple of projects.  (I once used a Tiny that has no ram at all - just 
the 32 8-bit registers.  Even then, I wrote the code in C using avr-gcc.)

>
>> Regarding the compiler, the gcc source supports the AVR (and a couple of
>> dozen other architectures), but any given binary build is for a specific
>> host-target combination.  So the gcc that you no doubt have installed on
>> your system from before cannot target the AVR.  You can always download
>> the gcc source and build it yourself, but probably you will do better to
>> simply download the ready-build packages from Atmel:
>>
>> <http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx>
>
> I ended up using apt-get for gcc-avr (yes they switched the name),
> which I think is enough for my original purposes.

Yes, that will be good enough for what you want at the moment.

Like many embedded gcc targets, there are two ways to get the compiler - 
you can use the mainline gcc, or you can use the manufacturers fork. 
(In each case, you can get the source or use pre-built binaries, such as 
via apt-get or yum.)  The mainline version will give you the latest gcc 
features - the newest standards, the latest warnings, etc.  The forked 
version will give you the latest device support, the newest device 
headers, and workarounds for hardware bugs that might have been found. 
Changes done by the manufacturer in their fork will get passed back to 
mainline, but it can take some time before these are eventually in place 
in mainline releases.  And changes in mainline make it to the 
manufacturer's fork when they rebase.  (The same applies to the 
libraries involved.)

In general, for actual embedded development work, it is usually best to 
get the manufacturer's package of gcc, libraries, headers, and other 
utilities, examples, and documentation.  But in your case, it does not 
matter significantly - use whatever is most convenient.

>
>> That gets you the compiler, binutils (assembler, linker, etc.), the
>> library (avrlibc), device headers, etc.  The avrlibc project home page
>> is another source of useful information:
>>
>> <http://www.nongnu.org/avr-libc/>
>
> Is there by chance an emulator, hopefully one that can report
> simulated timings?  I'm pretty much flying blind in terms of
> performance results.

There is an open source AVR simulator, which is probably available in 
your apt-get repositories, and can work with the avr port of gdb.  I 
haven't used it myself.

There is also the full AVR Studio from Atmel with a simulator for the 
chips and many of their peripherals as well as the cpu.  It is a /big/ 
package - an MSVS IDE, pre-packaged gcc compiler, wizards, debugger, 
power estimator, everything you could wish for for AVR development, 
except support for anything other than Windows.  I haven't used it for a 
decade or so.

But performance calculations on the AVR are quite simple. 
Register-to-register instructions are all single cycle.  Accessing 
memory (read or write) takes another cycle.  Multi-byte instructions 
take an extra cycle per extra instruction word (the instruction memory 
is 16-bit wide, and on a separate bus from the data bus).  Branches take 
2 cycles when taken, 1 when not taken IIRC.

>
>> Once you have the tools installed, a typical command line to
>> compile a C file and look at the generated assembly would be:
>>
>> avr-gcc -mmcu=atmega3250 -c -Os -std=gnu11 -Wall -Wa,-adchls=test.lst test.c
>>
>> -mmcu=atmega3250 specifies the device (the format here may be
>> different in newer avrgcc builds - it's a while since I used a new
>> version, since I make a point of never changing toolchains in a
>> project and I haven't had any recent AVR projects).  [snip]
>
> The -mmcu=atmega3250 was the key piece of information I needed
> (ie, beside knowing about avr-gcc as the compiler to use).  Like
> I said I ended up using -mmcu=attiny4313, but same diff.  Also in
> the compiler I got it was -S to generate assembly, but that was
> no problem since I'm used to it with gcc generally.

"-S" asks gcc to generate an assembly file rather than to run the 
assembler directly, while "-Wa,-ahdl=test.lst" ask it to run the 
assembler but output an assembly listing file (with different options 
for things like macro expansion and other details).  Often the 
difference doesn't matter - but the "-Wa,-ahdl" method is neater when 
you want a listing file in addition to the normal object file.

You might like the -fverbose-asm flag too.


>
> Double thanks, this was great.
>

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-10-27 23:54 +0100
  Re: Parsing a rotated stream of 64 bits Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-27 17:37 -0700
  Re: Parsing a rotated stream of 64 bits Bartc <bc@freeuk.com> - 2015-10-28 01:27 +0000
  Re: Parsing a rotated stream of 64 bits Nobody <nobody@nowhere.invalid> - 2015-10-28 05:13 +0000
  Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-10-28 09:17 +0100
    Re: Parsing a rotated stream of 64 bits supercat@casperkitty.com - 2015-10-28 06:22 -0700
      Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-10-28 16:07 +0100
        Re: Parsing a rotated stream of 64 bits supercat@casperkitty.com - 2015-10-28 08:41 -0700
          Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-10-28 23:29 +0100
            Re: Parsing a rotated stream of 64 bits supercat@casperkitty.com - 2015-10-28 17:50 -0700
              Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-10-29 13:56 +0100
          Re: Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-10-29 09:48 +0100
    Re: Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-10-29 09:34 +0100
      Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-10-29 13:57 +0100
  Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-10-28 09:21 +0100
  Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 23:44 -0700
    Re: Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-10-29 09:28 +0100
      Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 09:18 -0700
        Re: Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-11-09 09:27 +0100
          Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 14:00 -0800
            Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-11-11 10:48 +0100
              Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 05:56 -0800
                Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-11-13 16:32 +0100
                Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 17:57 -0800
                Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-11-15 23:43 +0100
                Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-17 08:42 -0800
            Re: Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-11-13 14:58 +0100
              Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-15 12:02 -0800
                Re: Parsing a rotated stream of 64 bits pozz <pozzugno@gmail.com> - 2015-11-16 10:16 +0100
                Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-17 10:49 -0800
                Re: Parsing a rotated stream of 64 bits David Brown <david.brown@hesbynett.no> - 2015-11-17 23:34 +0100
                Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 16:04 -0800
    Re: Parsing a rotated stream of 64 bits Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-29 03:56 -0700
      Re: Parsing a rotated stream of 64 bits Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:42 -0700
  Parsing a rotated stream of 64 bits asetofsymbols@gmail.com - 2015-11-16 03:03 -0800

csiph-web