Wallace White [EMAIL PROTECTED] wrote:
What setup are folks using to debug bootloaders, specifically with
the JTAGICE mkII? Or are they?
Debug it as a standalone application (i.e. use a relocated .text
instead of .bootloader section).
Alas, on the ATmega128, you'll run into the additional
Larry Barello [EMAIL PROTECTED] wrote:
target1:
MCU=mega128
SRC=this.c that.c ...
ASRC=this.S that.S ...
target2:
MCU=mega16
... etc.
But this doesn't work.
That cannot work that way. Makefiles do only parse *all* their macro
definitions first, then
As Vesa Jääskeläinen wrote:
I have been debugging why Ethernut brakes in certain situations with
gcc. And found an optimizer bug.
I can't seem to find one.
We can see that one compare is missing and this causes functional
change to code.
Which one is missing do you think? The full
Radu Ciurlea [EMAIL PROTECTED] wrote:
I tried to update count from main() and it doesn't seem to work.
Please RTFAQ. This is FAQ #1: you need to declare that variable
`volatile'.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
In article [EMAIL PROTECTED] you write:
The compilation works fine but I
can not capture the GCC console messages (make.exe all error.txt)
Error messages usually go to standard error output.
If you're using an MS-DOS derivative and its command.com, you lose.
You cannot redirect standard error
Moderator's note: This looks close to promotion to me, given the
`reuqirements' listed above (*). As the originator is obviously not
subscribed to the list, it turned out as a moderation request to me.
(*) Disclaimer: I didn't verify the referenced web site though.
If any member of the list
Jeff Barlow [EMAIL PROTECTED] wrote:
How about just byte vs word addresses? 0xFC00 = 2 * 0x7E00
ISTR AVR Studio displays all code addresses as 16-bit units
(``words'').
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC:
Haase Bjoern (PT-BEU/EMT) * [EMAIL PROTECTED] wrote:
IMO, in order to resolve the issue, one would need to teach gcc how
to place 3-Byte objects in registers.
Which would be kinda neat in order to support the ATmega256's 24-bit
(code) address space, btw.
IMO this would require substantial
juan antonio jimenez martinez [EMAIL PROTECTED] wrote:
(Please don't type in all caps, it's considered to be shouting.)
..., HOW CAN I SPECIFY WHICH MAKE.EXE MUST USE AVRGCC
The simplest way is to rename the GNU make that comes with WinAVR, say
into gmake.exe, and then always call gmake.
--
Torsten Mohr [EMAIL PROTECTED] wrote:
Still i wonder why uisp finds a device similar to ATmega103-old.
Don't know much about UISP, but are you sure you unprogrammed the
M103C fuse in the ATmega128? Perhaps that's the problem.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
Torsten Mohr [EMAIL PROTECTED] wrote:
Why can't i correctly program the ATmega128?
Perhaps you'd give AVRDUDE a try?
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't
Kitts [EMAIL PROTECTED] wrote:
Something like this...
length = strlen_P(PSTR(some string));
Yes, exactly that way.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't
Torsten Mohr [EMAIL PROTECTED] wrote:
I added a new programmer in avrdude.conf:
programmer
id= dapa;
desc = What 'uisp' understands as 'dapa';
type = par;
vcc = 3;
reset = 16;
sck = 1;
mosi = 2;
miso = 13;
;
Btw., please take a moment, and fill out a patch
Torsten Mohr [EMAIL PROTECTED] wrote:
i wonder if anybody ever successfully used an ATMega128?
Sure. The author of AVRDUDE, Brian Dean even sells his Mavric
board that works with an ATmega128.
Now i got the problem that the program does not do what i
expect it to do:
I quickly plugged it
Anton Erasmus [EMAIL PROTECTED] wrote:
Is there some way to change it so that the default
reply to address is the list address ?
It is really not recommendable. I've been using one list with that
policy in the past (the XFree86 developer's list), and I have seen
quite more than a single
Torsten Mohr [EMAIL PROTECTED] wrote:
I only programed the ext. fuse bits to 0xff. Is that ok?
Probably yes, at least for a start. The remainder is upon your
requirements, after all, that's why they are fuse bits at all. ;-)
Regarding the interpretation of the fuse bits i'm a bit unsure,
Matt McLellan [EMAIL PROTECTED] wrote:
asm(lds r16, array[element]::);
That gives me the following error:
Error: garbage at end of file
Sure, assembler is not C. ;-)
You'd need to compute the address yourself in assembler.
I've also tried passing it as an arguement, but can't
seem to
Colin Paul Gloster [EMAIL PROTECTED] wrote:
sed s/\([0-9]*\)\(: error: \)/(\1) \2/g
But don't forget that you gotta catch stderr, not stdout.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an
Torsten Mohr [EMAIL PROTECTED] wrote:
Can i really DISABLE SPI programming by fuse bit SPIEN?
You can. But read the text carefully: you cannot do that while using
ISP programming. ;-) So it's not a shoot-into-your-foot (SIYF) fuse.
The only real SIYF fuse they ever invented is the reset
(Btw., please subscribe so you'll see people's responses.)
Andrew McNabb [EMAIL PROTECTED] wrote:
avr-gcc -mmcu=3Datmega8 -lm -L/usr/avr/lib sound1.o -o sound1
sound1.o: In function `__vector_8':
sound1.c:(.text+0xac): undefined reference to `sin'
make: *** [sound1] Error 1
Order is
Torsten Mohr [EMAIL PROTECTED] wrote:
Is it a bug that the stack is set to 0x10ff in __init?
It's some historic heritage that the stack is initialized twice.
I think this used to be intented for a transitional period, but
eventually never got removed.
It should probably only be initialized in
[EMAIL PROTECTED] (Joerg Wunsch) wrote:
Shouldn't the startup code also refer to the symbol __stack?
The code in .init2 explicitly uses __stack, but that gets already
compiled into the object file itself, rather then deferred to the
link stage. That looks like a bug to me.
I think the bug
Russell Shaw [EMAIL PROTECTED] wrote:
At strategic points you could do:
size_t freespace = alloca(0) - sbrk(0) + 1;
sbrk() is not a documented interface for avr-libc (not even
an existing one I believe).
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
[EMAIL PROTECTED] (Joerg Wunsch) wrote:
It took me 176 µs on an ATmega128 clocked with twice your system
clock.
It occurred to me after posting that that I've been measuring with
currTime still being 0. I've set currTime to different other values,
and yielded times between 60 and 70 µs
In article [EMAIL PROTECTED] you write:
The second thing is that the jtag box work fine under linux, but I
must change some things in avarice for that. There is one misterious
thing for the programm counter in avarice where porg counter is
calculated with pc/2+1 I think correct is pc/2.
Not
In article [EMAIL PROTECTED] you write:
is there any linux tool which is able to program in high
voltage/parallel mode with stk500 board? uisp did not support this,
right?
Nor does AVRDUDE. You might try asking on the AVRDUDE mailing list,
I've got no idea how much work it would be to support
Torsten Mohr [EMAIL PROTECTED] wrote:
With 16 bit pointers i can only download 64kByte programs at
maximum.
Code pointers are word-aligned, so you can divide them by two. That's
why GCC currently can handle the ATmega128 at all.
--
cheers, Jorg .-.-. --... ...-- -.. .
E. Weddington [EMAIL PROTECTED] wrote:
../../../../libm/fplib/modf.S:80: relocation truncated to fit: R_AVR_13_PCREL
__addsf3
This message rings a bell. Unfortunately I can't remember everything
about it.
ISTR there once was a bug in GCC.
I agree that updating the tools is the first option
Torsten Mohr [EMAIL PROTECTED] wrote:
It does not make sense to me to download the .data section into
flash memory.
It makes a lot of sense to me though.
After all, .data contains the *initialized* variables. Somehow, the
initialization data need to be passed down. If not by ROM, how else?
Torsten Mohr [EMAIL PROTECTED] wrote:
to have the data that belong into .data somewhere in flash makes
sense, but the address of the section .data pointed to 0x800100.
That's the RAM address, where the offset 0x80 is a hack to map the
different address spaces of the AVR into a single flat
Torsten Mohr [EMAIL PROTECTED] wrote:
I do not use avr-objcopy. I directly download parts of the ELF
file.
In that case, have a look at AVaRICE. It is also able to read the ELF
files directly, and download them to the target through a JTAG ICE.
--
cheers, Jorg .-.-. --...
In article [EMAIL PROTECTED] you write:
However, when the strings are a variety of sizes, space is wasted. Is
there some way to declare the array instance so I can use the type
definition one would normally use in ram, ie:
It's even described in the FAQ:
jeffrey traer bernstein [EMAIL PROTECTED] wrote:
okay here's another stab in the dark.
Why don't you simply look at the generated assembly code?
... is it the data i.e. the address stored in the .data section?
That entire construct is inlined completely by both, IAR and GCC.
--
cheers,
Peter Bosscha [EMAIL PROTECTED] wrote:
Typically in our situation, parts of the structure change but other
parts stay the same (this is configuration data for a PLC-like
device). When downloading the entire structure from a PC, quite a
bit of eeprom memory already contains the correct
Bob Paddock [EMAIL PROTECTED] wrote:
I do not want trigraphs, how do I make the warning go away?
-Wno-trigraphs
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have
As Royce Pereira wrote:
I wish there were a better way to use program ATtiny12 etc than
keeping 2 copies AVR-GCC. Also Bruce's method is stuck with gcc
2.95. I'd like a command line option or the -mcu option to do the
job!
I don't think Bruce's method is limited to GCC 2.95, it's only that
As Haase Bjoern (PT-BEU/EMT) * wrote:
IIUC 4.x.x does very much the same as 3.x.x . There is one single
place pointed out by Paul Schlie some time ago where you could
switch of the promotion rules, however.
I didn't mean the promotion rules but the abysmal code generation
that occasionally
Jim Brooks [EMAIL PROTECTED] wrote:
When I checked the bin directory of WinAVR however, there was no
libtool. Can I use the PC GCC libtool?
Dunno, perhaps you can, but why do you want? I personally think
libtool is a horrible GNUism, and it's not needed at all to create a
simple library.
Lars Noschinski [EMAIL PROTECTED] wrote:
I'm looking at some assembler code avr-gcc spit and I'm a bit
puzzled.
Actually, you're looking at the disassembler output it seems.
Just call the compiler with any options you'd normally use, replace
the -c by a -S, and change the -o outfile option
suzet war [EMAIL PROTECTED] wrote:
so, the questions is, what can i do so taht WinAVR can recognize it
and compile the code without error?
should i put the header file of my particular hardware in the
WinAVR/include folder?
Rather not. Either put it into your application's directory, then
Larry Barello [EMAIL PROTECTED] wrote:
I'll take Dean's suggestion and declare the bit-field as uint32_t
and see what happens; that would be the cleanest way to do this.
See my posting, it's sufficient to declare the missing 13 dummy bits,
so the bitfield struct is 32 bits long.
--
Jorg
masoud sabzali [EMAIL PROTECTED] wrote:
I'm using ATMega128 micro and i want to know if Stack Pointer is
capable to address external memory?
Sure, though it's not recommended as external RAM is slower than
internal.
Is there any way to use external memory to place stack frame?
Please read
Henrik Maier [EMAIL PROTECTED] wrote:
I am missing a method to check during compile time against a
particular version of avr-libc.
http://lists.nongnu.org/archive/html/avr-libc-dev/2005-08/msg00080.html
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
Henrik Maier [EMAIL PROTECTED] wrote:
Thank you Joerg for the hint. I am obviously not subscribing to
right list as I consider myself as a user rather lib developer.
Sorry, I should probably have Cc'ed the original mail into this list
as well, as I'm clearly interested not only in developer's
User Tomdean [EMAIL PROTECTED] wrote:
I want to force the use of X and Z with global variables.
You can effectively only use r2 through r15 for global variables.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Vincent Trouilliez [EMAIL PROTECTED] wrote:
But for the life of me, I can't see anywhere in the rest of the
interrupt section, a single word to explain what the difference
between the two macros is, and their respective purpose/goal.
You can't?
Hmm, just compare the descriptions of both
=?utf-8?q?Bj=C3=B6rn_Haase?= [EMAIL PROTECTED] wrote:
You can effectively only use r2 through r15 for global variables.
You will run into problems even for the higher register numbers of
r2 through r15 in case that you are calling a function with many
parameters.
ISTR someone reported that
Russell Shaw [EMAIL PROTECTED] wrote:
The only fix that is needed is to state prominantly in the first few
few paragraphs what the difference is, and all confusion will
disappear.
Nope, I rather did what we (avr-libc-dev) agreed quite some time ago:
deprectated INTERRUPT completely, and
Vincent Trouilliez [EMAIL PROTECTED] wrote:
So no need to regresss feature wise by removing this macro, all the
user need is a concise but clear information, at the right place in
the document.
Don't worry. My personal guess is there are probably a dozen or so
legitimate users of
As User Tomdean wrote:
This is warning about using Z and X, but, not Y.
Maybe you could really use Y as a global reg variable, but I'd rather
avoid that. It severely restricts the compilers freedom of choice to
generate decent code for the remaining program. If you're linking
against
As Royce Pereira wrote:
Just asking - why not have the 2nd case i.e SIG_XXX(void) convention
for both cases - one case with the 'interrupt' attribute and one
without?
If you'd use __attribute__((signal)), that's just it: SIGNAL() is only
a helper macro that shortcuts the function declaration
Patch URL:
https://savannah.nongnu.org/patch/?func=detailitemitem_id=3750
Almost unnoticed went that patch that has been contributed by Ted
Roth, at a time when he had already `retired' from the project.
My only concern about it is that it would constitute an API change for
the stdio API, so
Ernst Stippl [EMAIL PROTECTED] wrote:
Is there a way to instruct the compiler to flag the 1st and 2nd
assignment as wrong because they mix types?
Not in C, as in C, an enum constitutes an int, per definitionem.
In C++, the compiler would reject the assignment.
--
cheers, Jorg
David Kelly [EMAIL PROTECTED] wrote:
As I understand Ted's patch what one gains is control over more than
one possible FILE for get() and put(). That would be fairly
important for devices with more than one UART.
Yes, that's the case. And I must say, the new API is well-thought: by
passing
Col [EMAIL PROTECTED] wrote:
Why not depreciate both of them and start with something new?
Because there's no need to annoy all those users of SIGNAL() out there
(which would effectively be all AVR-GCC/avr-libc users).
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
(Accumulated followup to several replies.)
As Dmitry K. wrote:
It is possible to facilitate transition to a new variant:
1. To change the order of arguments 'put' as:
int (*put)(FILE *, char) -- int (*put)(char, FILE *)
It would allow to leave the asm program 'put' without
Lars Noschinski [EMAIL PROTECTED] wrote:
I've some trouble debugging my avr applications (which use the
avr-gcc toolchain) under Linux. I tried to run AVRStudio4 using
wine, but failed at the install. VMLAB seems to run fine, but I
cannot generate coff files. As WinAVR seems to be able to
Chinmay Pendharkar [EMAIL PROTECTED] wrote:
Is there a way to access both types of memories using a singular
function which will intelligently judge on which of the two
libraries is to be used?
Only using C++, and virtual base classes -- which naturally will
impose a run-time cost.
This
Gary Bi [EMAIL PROTECTED] wrote:
Another quick question: does anyone know which version
of avr-gcc can support C code compiling for
ATmega165/Atmega325, I have next version:
Currently only with patches. ATmega165 support is in binutils-2.16
natively, but everything else (both MCU types for
As Joerg Wunsch wrote:
-in stdio.h:
#define STDIO_SETUP(stream,buf,put,get,flags) FILE stream={buf,\
0,\
flags,\
sizeof(buf),\
0,\
put,\
get}
That might basically
As Bernard Fouche wrote:
Errm, you'd still need to supply a dummy implementation for malloc()
anyway when using the floating-point versions. ...
Now why not have an alloca(3) in libc? Sure it is not the best way
to manage dynamic memory but vfprintf/scanf are typicall
applications where it
As Bernard Fouché wrote:
(about [not] malloc()ing the FP conversion buffer)
Of course, if there's consensus among the users that this is not
needed, and an additional 40 bytes on the stack are no big deal for
the floating-point versions, we could easily drop that completely, and
always
Dmitry K. [EMAIL PROTECTED] wrote:
Sounds great - any chance you have a patch that we can
try and see how this works for us ?
OK, after a few of days. Now it is only a quick realization for
comparison purpose.
Oh, you did that work independently from the currently running
discussion about
Wolfgang Wegner [EMAIL PROTECTED] wrote:
The problem is that the variables are sorted top-down by gcc (or
the linker), so my placeholders do not work. I can of course
manually fill these, but I think there has to be a better way.
There's no guarantee for any particular order. The only
:
Changes by: Joerg Wunsch [EMAIL PROTECTED]05/09/06 18:49:15
Modified files:
. : ChangeLog NEWS
doc/examples/twitest: twitest.c
include: stdio.h
libc/stdio : Files.am clearerr.c fclose.c fdevopen.c feof.c
Vincent Trouilliez [EMAIL PROTECTED] wrote:
Oh, that's interesting... because as soon as I compile my small
programs, I rush to check to have a look at the assembler output,
...
At the assembler output (filename.s), or at the disassembler output
(filename.lss)? I guess it's the latter.
-
Torleif Sandnes [EMAIL PROTECTED] wrote:
Your problem may be that you are compiling with optimization on.
Try to use -O0 instead of -Os, -O1 or whatever you are using.
But of course, he'll debug an entirely different program then.
My own experience says that it's best to get used to the
Wolfgang Wegner [EMAIL PROTECTED] wrote:
... but at the moment, the combination WinAVR - AVRstudio is
unusable for debugging.
But you're using ELF/DWARF-2 as debugging format, aren't you?
--
Jorg Wunsch Unix support engineer
[EMAIL PROTECTED]
Wolfgang Wegner [EMAIL PROTECTED] wrote:
command[0x01, 1]: 01
USB daemon died
Hmm, please talk offline with me about that, I'd be interested in
finding the actual problem here.
Obtw., I never managed it on Linux to access these USB devices without
being root (even chmod of /proc/bus/usb/...
Wolfgang Wegner [EMAIL PROTECTED] wrote:
um, no - I was using coff/stabs because I understood the manual such
that elf/dwarf was still experimental. Sorry for that!
It's still somewhat experimental, but probably has less bugs than our
COFF conversion, and AVR Studio doesn't understand stabs
David Brown [EMAIL PROTECTED] wrote:
..., and it will also change multiply by constant into a series of
shifts and adds. The target chip has a hardware multiplier and
divider, but they are slower than the shift-and-add sequences.
Unfortunately, AVR-GCC also does this, even though the
Russell Shaw [EMAIL PROTECTED] wrote:
When you use gdb on code that has been optimized with -O2, the
source highlighter bar jumps all over the place making it hard to
follow the code.
Sure. Get used to it...
With -O0, the bar follows every source line as you'd imagine.
Sure. No
As the impending switch to avr-libc 1.4 allows us to make API changes,
I'd like to get people's opinions on the following:
. I'd like to get avr/signal.h and avr/interrupt.h to eventually
be merged. As a next step, we could deprecate one of those, and
issue a #warning if it gets included.
As E. Weddington wrote:
If so, what to do with timer_enable_int() and enable_external_int(),
should I start a compat/deprecated.h for these?
- We should define the compat/* include directory as for
compatability includes only. I would take this as meaning
compatability with other
As Wojtek Kaniewski wrote:
#include avr/generic/uart.h
supposedly providing a generic uniform UART view for as many as
possible AVRs.
Consequently, why not move avr/io.h to avr/generic/io.h? It's
there to provide generic access to SFR's regardless of MCU used ;-)
Not really. avr/io.h
As Wojtek Kaniewski wrote:
How about...
#define VECTOR(signame) \
void SIG_ ## signame (void) __attribute__ ((interrupt)); \
void SIG_ ## signame (void)
I don't know. I'm more inclined to use ISR(), but I'd rather like to
see other people's opinions on this.
Obtw., of course,
As Wojtek Kaniewski wrote:
What about the SIG_ prefix? If we'll move to something else than
SIGNAL(), I think that it should be dropped or somehow hidden from
the users.
Very good point. I've been thinking about adding a second set of
vector names anyway. Our names are completely
Oh well, yet another mass followup. Sorry if that's messing up your
thread displays. ;-)
As Szikra Istvan wrote:
I'd prefer those functions to be in util/* than avr/generic/*.
Me too and, if it avr specific than rather avr/util/* than
avr/generic/*
As that still has the problem of adding
Is anyone working on a port for ATMega64x, ATMega128x and ATMega256x
devices?
Yes and no.
Patches for the 640/1280/1281 are reasonably complete, support to
avr-libc has been added by Anatoly Sokolov recently.
Regarding the mega256x support, the issue has been discussed here a
number of times.
Chip Webb [EMAIL PROTECTED] wrote:
OK, thanks. The 640/1280/1281 patches are a help. I was working on
my own versions in spare time and will try to sync up with
Anatoly's. Have binutils and gcc have also been updated as part of
the patches?
Anatoly supplied GCC and binutils patches, but I
[EMAIL PROTECTED] wrote:
I would like to display a code version (date/time or incremental
number) during init on an LCD display.
If you're using CVS, you can get the date of the last checkin of
a particular module by
const char foo[] = $Date$;
CVS will replace that by something like
const
[EMAIL PROTECTED] wrote:
I am in tunning phase so I am looking for something more dynamic
than CVS, i.e. the compilation/link time ...
Well, it's up to you to run a cvs commit -f whenever you need. ;-)
Anyone, someone pointed out to me offline that of course, the
compiler supports the ANSI
Larry Barello [EMAIL PROTECTED] wrote:
Well, duh, it didn't work since the second call to
fdevopen() (task 2) failed miserably.
Can you explain `failed miserably' in some more technically
descriptive phrase?
So, the question is: what would it take to extend the current stdio
facility to
David Kelly wrote:
We may make a FreeBSD user out of you yet.
:-)
Joerg included a/the patch for binary constants in the FreeBSD Ports
version of avr-gcc, which he maintains.
Just for the record, I meanwhile filed it for official inclusion:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--
I think I found a bug in avr-gcc:
Every function called main() gets the stack-setup-code, even when it
is inside a namespace.
ISTR there's currently work underway to make main() a normal function.
That should solve your issue as well.
--
cheers, Jorg .-.-. --... ...-- -.. .
Jahagirdar Gopal-AGJ005 [EMAIL PROTECTED] wrote:
I wanted to know is there any Linux based JTAG debugger available so
that I can set/clear break points, set watch points etc. such as
GDB. I am using avr-gcc to build the image and avarice to program
the device.
So you've already got
Vincent Trouilliez [EMAIL PROTECTED] wrote:
struct menu {
.;
.;
int (*fp)()[]; //table to store all the pointers
};
Better declare them in a prototyped fashion:
int (*fp)(void)[];
//definition for a menu
const struct menu __ATTR_PROGMEM__ menu_foo = {
Vincent Trouilliez [EMAIL PROTECTED] wrote:
What's the trick ?
None. You cannot have two arrays with unspecified size within the
same object. The compiler needs to be able to compute the offset of
each struct element at compile-time, and this offset needs to be the
same for each instantiated
stevech [EMAIL PROTECTED] wrote:
Unspecified array sizes are a basic no-no on a microprocessor
platform. The compiler strategies have to be simple and explicit,
unlike elegant situations on multi-megabyte big computers.
I disagree. Vincent was going to put a table of initialized structs
into
Thiagraj Peri Natraj [EMAIL PROTECTED] wrote:
configure: error: no termcap library found
Presumably, termcap is needed in order to get the readline support
running.
What environment is that, Linux?
/usr/bin/install: cannot create regular file
Permission denied.
I donot have root access.
(Please don't post the same message four(!) times!)
kchoo [EMAIL PROTECTED] wrote:
I am using winavr to compile a simple c code with the
compiler option dwarf2 enabled.
CFLAGS = -ggdwarf-2,
but I failed to generate extcoff file.
The COFF converter is incompatible with DWARF-2
I have been advised to use CVS when developing programs, but it seems
awkward to set up the server side.
Don't use CVS server. If you need remote CVS, use CVS-over-ssh. If
you're living in a Unix world, it's pretty safe to share the CVS
repository over NFS, and use local CVS access, as CVS
Timothy Smith [EMAIL PROTECTED] wrote:
my apologes for not giving this to start with
%avr-gcc -g -mmcu=atmega32 -Os -c BarGimp.c
%avr-gcc -g -o BarGimp.out BarGimp.o
Make this:
avr-gcc -mmcu=atmega32 -o BarGimp.out BarGimp.o
and it will work. The linker needs to know as well which CPU
Patrick Blanchard [EMAIL PROTECTED] wrote:
2. I am attempting to merge pstang's AVRlib with the makefile from
AVR-libc. What and how is the best way to proceed in your opinion?
The Makefile template that ships in avr-libc's demo project is just a
simple suggestion. Everything else should work
Patrick Blanchard [EMAIL PROTECTED] wrote:
(Dave already answered the questions about specified-width integer
types as the C99 standard calls them.)
I cannot find a good teaching reference for this 'linking' part of
the makefile, so I'm stuck here...
Oops, that's nothing about linking but the
Timothy Smith [EMAIL PROTECTED] wrote:
also, is there a more elegant way of doing time delays?
Yes, use a hardware timer. ;-) That's what they are made for.
Otherwise, have a look at the functions in avr/delay.h.
--
Jorg Wunsch Unix support engineer
Russell Shaw [EMAIL PROTECTED] wrote:
They probably did it for their larger non-avr CPUs, then used it as
a selling point for their smaller CPUs, even if not all of it is
very practical.
They bought the library from P J Plauger.
--
cheers, Jorg .-.-. --... ...-- -.. .
On Fri, 2005-10-07 at 17:52 +1000, Timothy Smith wrote:
the timer stuff is still a little confusing, all the abreviations
are unintuitive.
You mean the bit names?
They come straight from Atmel's datasheet. Usually, with a bit of
phantasy, you could guess what they mean.
/* tmr1 is
Razvan Turiac [EMAIL PROTECTED] wrote:
Attached are a simple C source (I have isolated the
problem), and the generated assembeler file.
The problem is in function wait.
You should have explained what you think the problem is... But my
crystal ball told me you might mean this:
.L4:
Jamie Morken [EMAIL PROTECTED] wrote:
If the rstdisbl fuse is programmed on an AVR,
is there any way to unprogram this bit over the
SPI ISP interface?
Obviously not, as ISP needs /RESET.
is it better to use the full swing crystal
oscillator or the low power crystal oscillator
setting when
1 - 100 of 583 matches
Mail list logo
