es
where -O3 was smaller than -Os, but it's not common.
>
> --
> David VanHorn
> Hardware Engineer
> MobileFusion, Inc
> 2715 Sarah St
> Pittsburgh PA, 15203
> Phone: (001) 412-481-
> Cell: (001) 765-215-8521
> Fax: (00
On Mon, Apr 6, 2009 at 12:29 AM, John Myers wrote:
> I have an ISR in a library.
> I want to be able to compile the ISR with a generic target and not have the
> ISR name tied to a specific interrupt vector.
> I want to be able to add the library with the ISR to a project and then
> have the ISR f
Problem solved..
The LCD.C and LCD.H files I've been using are NOT part of the WinAVR
distribution!
This is my work PC, used by others, and someone switched out the fine coffee
normally served in this restaurant with Folger's Crystals.. Let's watch.
:-P
Sorry for the confusion..
I got suspiciou
Correction: The routine in question is lcd_putc not lcd_puts.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
> I know what *I* am missing - the source code! How is anyone supposed to
>> help you with your problem until you post the actual compilable code
>> snippet? We need a compilable code sample which demonstrates the problem,
>> along with the compiler flags you used and also the compiler version
I am still very puzzled over why the compiler balks wether I use signed or
unsigned chars to feed lcd_puts.
When I used "unsigned char" it balked. When I used "char", it didn't.
Now when I use int8_t or uint8_t, it balks.
___
AVR-GCC-list mailing list
A
On Fri, Mar 27, 2009 at 4:31 PM, Graham Davies wrote:
> David VanHorn wrote:
> "Ok, so that leaves me VERY confused."
> Maybe it would help to think about logic levels in simulation. The three
> basic levels are "low", "high" and "unknown".
>
>
> As you should be. Plain old "char" *is* either signed or unsigned
> depending on your choice of compiler. And in effort to build code that
> runs as expected better compilers have a compile time switch to control
> code generation when the signedness is specifically indicated.
Ok, that's on
>
>
>
>
> In C there are 3 char types. "char" "signed char" "unsigned char" so
> maybe "char" isn't signed?
Ok, so that leaves me VERY confused..
Correct me if I'm wrong, but "signed" variables use the high bit to indicate
negative by setting it to a 1, correct?
So, I can only see two options
nsensical to me..
--
David VanHorn
Hardware Engineer
MobileFusion, Inc
2715 Sarah St
Pittsburgh PA, 15203
Phone: (001) 412-481-
Cell: (001) 765-215-8521
Fax: (001) 412-481-0220
d...@mobilefusioninc.com
www.mobilefusioninc.com
**
>
>
> Actually, that may have been a fault in my test. When I started, I
> didn't have 32 in the constant, but something else. When I tried to
> reproduce the problem with 32 it always seems to generate the shift.
>
> Compiling with no -O option or with -O0 causes the helper function to
> be called
>
>
>
> The assembly above comes from the __udivmodhi4 helper function (found
> in libgcc.a), which is a helper function for performing a 32-bit
> divide.
>
Let me guess.. It was stuck on below the LCD routines in memory, and AVR
Studio didn't know that somehow?
Gak..
Ok.
I'm still puzzled as t
Well.. Still flogging the horse here.
I have the .S file, but I don't know how to interpret it.
I carved up the statement even further, and moved the declarations so all
the vars are in ram so I can watch them easily.
A = Raw_Data[0][Raw_Data_Index]; // Gives the expected result.
Bi
On Tue, Mar 10, 2009 at 2:44 PM, David Brown wrote:
> As I've told you before, if you think there is something odd about the
> generated assembly code, no one can give you more than very general guesses
> unless you post a minimal compilable code snippet.
Given that this is something that comes
OL R25Rotate Left Through Carry
+0630: 1796CPR25,R22Compare
+0631: F008BRCS PC+0x02 Branch if carry set
--
David VanHorn
Hardware Engineer
MobileFusion, Inc
2715 Sarah St
Pittsburgh PA, 15203
Phone: (001) 412-481-
Cell: (0
>
> F_CPU is always evaluated upon each invocation, so if you ever change
> it within one compilation unit, the next invocation of one of these
> macros will reflect this.
>
That's compile-time, he's looking for execution-time changes in processor
speed.
He didn't explicitly say so, but I think he'
>
>
> The C preprocessor is too basic to do this sort of thing. Functions like
> logarithms come from the math library the the preprocessor can't make
> use of libraries at compile time.
>
> This is a PERL script I use to generate sine tables to load onto a
> Mega48. It shouldn't be hard to adapt i
>
>
>
> Before you get that far, what do you want the logs for? And what base (if
> it matters)? And what speed and accuracy? If you need low speed and high
> accuracy, just use the standard C log function. If you need high speed and
> low accuracy and low code space, a find-first-one function
>
>
>
> The delay functions require a constant so the delay can be calculated at
> compile time. I would think that part of the problem is that you have to
> introduce more code to check the value of f_cpu and to calculate the delay.
> This pushes the delay calculation into run-time, plus it adds m
ing the table with a spreadsheet would be one way, though
icky.
I'm hoping there's a way to have the compiler generate it for me?
--
David VanHorn
Hardware Engineer
MobileFusion, Inc
2715 Sarah St
Pittsburgh PA, 15203
Phone: (001) 412-481-
Cell: (001) 765-215-8521
Fax: (001) 412-481
>
>
> Is there any workable combination of OS_main and the noreturn attribute,
> that would prevent the compiler from inserting the _exit function?
>
> In the ideal case six bytes would be saved.
>
> My main() never returns, yet when I apply noreturn I'm told that
> main() is returning a value.
D
On Mon, Mar 2, 2009 at 11:33 AM, David VanHorn wrote:
>> Yes, these ribbon cables appear to suffer from severe crosstalk at
>> times. I've also had reports from a friend about similar figures.
>> Just keep the ribbon cable short then. Put some isolating foil around
>&
>
>
>
> Yes, but the larger code is a more literal translation of your source
> code which the debugger can more easily map source code 1:1 to generated
> assembly.
Interesting
>
> -O0 is handy when learning C and wanting to see an assembly translation.
> Code should be debugged using the same
>
>
>
>
>
> Disable optimizations, -O0 I believe, and the source code debugger will
> more closely track the actual lines of code.
Ouch! That takes me from about 1.8k to over 7k.
>
> Also make sure you have specified -g in the compiler flags.
>
Where can I find a list of the compiler flags?
__
>
> Unless your "big iron" guys are similarly inexperienced (being a beginner
> is a good excuse for many mistakes), then they are incompetent. There is
> *no* excuse for a knowledgeable programmer using an inefficient and unsafe
> function in such a horribly unclear manner
I disagree, but I'm
>
>
>
> sprintf() only costs 2kB? Sure enough, this little program is 2132 bytes
> after strip:
>
Well, after I pulled all my sprintfs, the program went down by about that
amount.
474 cycles vs 8.
:)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
>
>
> Hey take it easy, I hardly meant to offend ! I was not "judging" your
> skills whatsoever (I am beginner too, I also used printf in my
> first days of programming...and gave up on it on the same day, as soon
> as I timed it with my oscilloscope and my eyes poped out when they saw
> how long i
>
>
> > has exactly the same effect as:
> >
> > A_String[i] = 0xff;
> > A_String[i + 1] = 0x00;
> > delay_about_1000_processor_cycles();
> > waste_about_2000_bytes_of_code_space();
>
> ROTF ! :-
>
As was earlier, and more gently pointed out by Dave, Sprintf was pretty
wa
>
> > I solved my problem by inserting the null with
> > memset((A_String+16), 0, 1); and the same for B_String.
>
> A_String[16] = 0;
>
> would be a much more efficient way of performing the same operation.
>
Interesting.. I would expect this to result in a loop writing out a bunch of
zeroes.
I
On Thu, Feb 26, 2009 at 8:11 PM, Bob Paddock wrote:
> > Raw_Data[0][Raw_Data_In_Index] = 0xAA;
> > Raw_Data[0][Raw_Data_In_Index++] = 0x55;
>
> Should the last one be Raw_Data[1]...?
>
:) It should, but that routine didn't need to "work", it just needed to
throw some junk data so the rest of
Well, I thought I should report back on my attempt to read these sensors.
I got past my sampling problem.
It's not pretty, but it works.
In my T0 ISR, where I do mS timers, I have it sampling the inputs, using T1
to count the period of four cycles of each input.
//
So I was using sprintf to create some data to send to the LCD, by way of
lcd_puts.
I had a pair of arrays, A_String[17], and B_String[17] which I filled
using two loops.
I hit some problems when I tried to consolidate this into one loop.
The symptom was that the second string wouldn't display, but
>
>
> If A/D-Converter and AnaComp are unused, you can use the ADC's input MUX
> and connect it's output with an AC input. The AC can then be used as input
> for InCapt of T1. So you can measure up to 7 lines in time slice mode (ICP,
> ADC0-ADC5).
>
Really?
Interesting.. That would largely solve
>
>
> I'd be surprised if either the original code or your modified code actually
> works - since TOV1 is 2, the conditional can never be true. The code you
> *really* want is:
>
>if (TIFRx & (1 << TOV1)) {
This section I'd not tested yet, and it may be pretty much irrelevant since
the pu
>
>
>
> Use an input capture I/O bit and let the hardware take a snapshot of the
> timer value when the edge is detected. Zero latency as long as it
> doesn't occur faster than you can reset the input capture..
>
I looked at that, but I have two inputs. I don't see any way to use that
hardware for
>
>
>
> I know that it's not adding much code, but can you remove (comment out)
> your debug statements, like above? I noticed there are more below, too.
Right, they are only there so I can actually scope it at the hardware level.
I've also run it in sim with studio, and it shows the same latency
:)
Interrupt latency.
I have an app on a Mega32L, running at 4 MHz.
I'm trying to measure the widths of pulses that could be as short as 5uS.
The theory was to detect the first rising edge, and zero T1.
Then on the second rising edge, grab the count from T1, which is running at
CK/1
The problem
I've done this in ASM, and as others have suggested, tweak with NOPS
till the bit timing is right.
For inbound data, you shouldn't sample too far from the middle of the bit.
The first low edge you see is the start bit, so delay half a bit time
after that, and sample every bit time after that for th
>
> Next you are counting on reading the state of PORTB to toggle its
> output. With many CPUs reading an output port reads the actual pin
> states not the value previously written. I don't recall the AVR acts
> that way, but there is an easier way to toggle an AVR output pin: Write
> a 1 to its in
> For instance I recovered chips sometimes by using UART traffic because
> I had no other hardware at hand: I took a RS232-UART converter, sent a
> big file from a terminal emulator (with no particular protocol, just raw
> byte sending) and I tried a few times to erase the chip until it worked ;-
What does the compiled code tell you?
I absolutely know that the following will toggle a given port:
ldi R16,$FF
out DDRx,R16 ;any given port that lives in I/O space, otherwise STS
loop:
out PORTx,R16 ;Similarly, PORTx must be in I/O space, otherwise STS.
ldi R16,$00
out PORTx,R16
ldi R16,$0
> Curious, what's the reason for this? Normally, you don't gain much by
> running an AVR at lower clock frequencies, compared to have it running
> as fast as possible (for the desired target voltage), and then put it
> to sleep once the job is done.
In my case, I needed to save power, so I would
I used the Fast PWM mode, 31kHz and a sinewave 600Hz modulation
frequency, sampled 8 to 32 times per cycle. IOW, I changed the PWM
pulse width 8 to 32 times per cycle of the modulation sine wave. The
modulation sine wave sampling rate seemed to make little difference in
the FFT of the output as
Although PORF should show something different, I would suspect
glitches in power or on the reset line.. The AVR is very sensitive to
even the shortest blips on reset.
The other thing to check, would be your clock. CKOPT fuse defaulted
with external crystal or resonator is a BAD idea.
I want to use ADC in AVR Atmega8 and using the 2.56V internal voltage for
the reference.
It said in datasheet we have to decouple the AREF pin with capacitor, but it
didn't said the value.
Does anyone know the value ?
Big enough is big enough.. :)
0.1uF is typically used. YMMV.
_
What I want to ask is - what's the current thinking within the avr-gcc
community with respect to documentation, and the task of making avr-gcc
approachable to newcomers? Is good newbie-friendly documentation seen as
a valued goal within the community?
I would welcome it, and I'd be interested
tmp.us=xx;
tmp1=tmp.x.h;
tmp.x.h=tmp.x.l;
tmp.x.l=tmp1;
Am I missing something here?
Why not pop to assembler, push the high, push the low, pop the high, pop the
low?
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mail
In general, if the chip has SRAM, then it can be supported in C.
-- Feel the power of the dark side! Atmel AVR
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Unless you have a specific reason not to, you should also program the CKOPT fuse.
Very squirrely and bad things happen if you don't know exactly what you're doing with it in the default state.
Non-deterministic execution.
___
AVR-GCC-list mailing lis
On 3/14/06, Timothy Smith <[EMAIL PROTECTED]> wrote:
can anyone explain in simple terms how i can calculate the time it willtake for the timer overflow interrupt to trigger using the prescaler? i
have had success in writing my own little programs to make variousled's blink etc but doing this in t
You have to have some sort of external reference, or there's no way to determine the xtal speed. Even comparing to the WDT osc is pretty sloppy, and of course that assumes a lot of code to make that determination.
If I were you, I'd put some flag in the program space like "CLK=4.00" as a const
What's the way to go in this situation? I thought of using a naked ISR andadding the necessary push by inline asm but what if I later change my code
and the compiler use different registers? I'm afraid to end up with brokencode.
First, can you not enable this int unless it's needed?
Second,
I've just downloaded the 20050214 version from several mirrors, and when I run them, the file tells me that it's corrupted. Am I doing something wrong here?
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo
53 matches
Mail list logo
