Is WINAVR crap or what?

AVR Studio with the Gnu toolchain works fine, and is free.

Cheers

Phil Hobbs

AVR studio up and running in minutes.

Outstanding issues are with the differences between HiTech C and WINAVR.

Having to use fdevopen to tie putch to printf makes sense but not needed for the PIC. But having to put a dummy argument in putch to make the compiler happy?

At least with printf running I can start debugging.

The stream argument isn't always a dummy argument. You could have 2 UART ports, and a single uart_putc() function that uses the stream parameter to determine which port to send the data to.

Not bad for FREE !

Glad to hear that you got something working.

Now you can focus on your project and not worry about the compiler.

Which ATmega are you using ?

hamilton

Not for me. I had trouble with AVR Studio 4 on XP, along with many other programs. But I don't care, WinAVR and Makefile work fine for me.

At90USB162/Atmega32u2/At90usb646.

Is this yours?

ATMega8A.

I'm providing my Bro in law with remote support on his project, I've not even seen the target system. Weather has stopped me going over to help in person. Thank god for webcams and the internet.

I have seen that you (linnix) know about ATmegas.

I was wondering about what Raveninghorde might be using.

It seems that getting a project (product) running gets lost in the choice of tools.

For as long as WINAVR and AVRstudio have been around, it would seem that more people would know about it.

makezine.com has lots of hits using this combination.

FREE is good. ;-)

hamilton

Thanks for the info.

hamilton

Yes, "Anda" and many others are using my boards. See her post above.

There are tons of examples available on Atmel and other sites. Check out the Atmel USBKEY, but with different chips.

And we do. Most of us are hanging around comp.arch.embedded.

I don't have it yet. I hear that people are using this to jail-break PS3. Is that right?

ny

hat

Yes, and there are long stories behind it.

We developed them for a customer's digital security key, similar to the "X.509 thread" in CAE. However, some hackers got hold of it and turn them into PS3 unkey, since Sony stopped supporting Linux. They were trying to re-enable Linux on their PS3, which is still in progress. Other PS3 users start using them to backup their blue-ray disc onto the hard drive. Some are running their games on broken blue- ray drive, which is the most fragile part of the PS3.

The way Sony (QA/QC people) and the hackers do are very interesting. I will follow up with another post with details. I need to go do something else first.

I've been googling and I am getting conflicting info.

Char is 8 bit short 16 bit int ? bit long 32 bit

I'm seeing int defined as both 16 and 32 bit and in one place int not used at all just short and long.

I've seen int as 8 bit and 16 bit on the PIC.

So in WINAVR what size is int?

Don't use any ambiguous data types.

All the more reason to dump C, by the way.

I was taught to use (u)intnn_t types (nn = 8, 16, 32, u = unsigned), which are absolutely unambiguous. (u)int8_t is equivalent to char, 16 to short and 32 to int, when C is compiled for 32-bit systems (~386).

Long is supposed to be twice an int, which in principle should be 32 bits on a 16-bit system (like 8086's FAR PTR), or 64 bits on a 32-bit system (386-pentium). But that's also 128 bits on a 64-bit system.

If you have no choice and need to find out what it is, disassemble the object code and find out. Or an easier way, if your tool produces such (gcc produces a listing showing memory fields and assembly as compiled, intermingled with the code and comments which produced it).

Tim

Got it.

I kept coming across them while googling but they are new to me.

I'm normally a PIC programmer and I've just tried unit16_t in Hi Tech PICC and the inttypes.h file doesn't seem to exist. So I've created it.

By the way what would you use for embedded programming if not C?

My recollection (dating back to K&R C) is that "int" is intended to refer to a particular machine's "natural" integer size. On most CPUs there's... well, a natural choice for what "int" should be. On some architectures it may be that there are two integer sizes which are supported about equally well... in those cases it's probably up to the compiler writer to make a choice (or to provide the programmer with a compile-time switch to select the size of a native "int").

Yup.

If you want to be certain of what you're getting, it's better to avoid the "native" C data types in your code, since they're architecture- and compiler-specific. Instead, code with explicitly-sized integer types, such as those defined by the ISO C99 include file... e.g.

int_64_t foo; uint_32_t bar; intmax_t bazIsReallyLong; It's then up to the compiler writer to provide you with a file which gives you these explicit types, or simply doesn't define them if the architecture cannot support them (at which point you code won't compile, and you'll know you're asking for something that isn't possible in that environment).

I have seen the *_t in may code segments.

What does the _t convey ??

Thanks

hamilton

Assembly. If it's too big for that, I don't have any preferred alternatives, so I put up with C.

There are some other options out there. I seem to recall there's a few GNU compilers for other languages on embedded systems.

Tim

An int must be at least 16 bits in a conforming implementation.

The compiler should have a "limits.h" header. If it doesn't then it's either rather out of date or not really C. Anyhow, limits.h shows the number of bits in a char and also the numeric limits for each implementation's integer types, from which the number of bits can easily be derived. Since sizeof char is 1 by definition, other types will be integral multiples of (usually) 8 bits.

Nowadays, char is almost universally 8 bits (on any architecture you're likely to run across), shorts are 16, and longs are 32. An int will typically be 16 bits on an 8-bit machine and 32 bits on a 32-bitter. As was mentioned, an int was intended to be a natural signed integer type for a given architecture. We also get long long (usually 64 bits). Often ints and shorts or ints and longs will be the same length, btw.

Newer compilers will include "stdint.h" where the uint16_t types and so on are defined. The "_t" suffix is shorthand for "type." Names beginning with "int" or "uint" and ending with "_t" are reserved.

Crusty old fogies tend to use char and int, or their unsigned relatives, out of habit but where size is important (e.g., embedded applications) it's better to get accustomed to the named types, like uint16_t.