Re: [avr-gcc-list] avr-libc _delay routines
On Fri, May 12, 2006 at 09:11:20AM -0700, Micah Carrick wrote:
void delayms(uint16_t millis) {
while ( millis ) {
_delay_ms(1);
millis--;
}
}
Is this function used because of the limitation of _delay_ms()? I read
that it's max is The maximal possible delay is 262.14 ms / F_CPU in
MHz. Does that mean that at 8 MHz, the max delay is 32 mS?
Yes, people just need delays longer than a few milliseconds.
Wouldn't the function above actually delay longer than millis mS
since the while and declaration take up clock cycles?
This is of course true. If your code can accommodate busy-waiting
for milliseconds at a time, then the extra few instructions in the
outer loop probably aren't a big deal.
-Matt
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Using PORTB with variables, PORTB = var
On Sat, Apr 22, 2006 at 07:29:10PM +1000, [EMAIL PROTECTED] wrote:
This example doesn't, and I don't know why... I know it's specific
to C, so that's why I'm asking here...
When asking a question like this, it would be useful for you to
describe exactly what you are seeing and what you expected to
see. Here is my interpretation of what you are probably seeing: in
less than half a second, a lit LED shifts across your output port and
then nothing else ever happens again.
I would like to keep the functions if possible, I'm thinking it has
something to do with scope perhaps?
You can do what you seem to try to be doing using functions. The
only scope problem I see is using a globally scoped variable
unnecessarily...
I am new to C by the way, if it isn't evident already (:
Great, you can learn the right way to do things from the start
without fighting bad habits!
Here is how I would implement your program. I apologize in advance
since I don't have a board available to try the code on. I hope that
the main ideas are apparent, even if I didn't squash all the bugs.
-Matt
void blink(volatile uint8_t * port, uint8_t mask) {
*port = ~ mask; // LEDs on
sleep(500); // milliseconds
*port = 255;// LEDs off
}
void change(uint8_t * var) {
*var = 1;
if (0 == *var) {
*var = 1;
}
}
int main() {
uint8_t led_mask = 1;
DDRB = 255; // PORTB as outputs
PORTB= 255; // LEDs off
while (1) {
blink(PORTB, led_mask);
change(led_mask);
}
return 0;
}
/* Changes
1) Don't use global variables (a common exception to this rule is to
communicate with an interrupt routine). [In my team you would lose
a hand for doing this.]
2) Don't assign a 16 bit signed integer value to an 8 bit unsigned
location (the port). [This would cost you your other hand ;-) ]
3) Don't write non-reentrant functions, that depend on and modify
global data.
4) Don't blink the LEDs faster than you can see them.
5) Don't keep shifting a variable the same way forever, since it will
end up all zeros.
6) Do keep programming AVRs in C!!
*/
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Newbie, downloadable access to list archive
On Tue, Nov 08, 2005 at 08:13:42PM +0200, Mark Elkins wrote: ...But this is all off the subject - Has **anyone** got a complete archive of the mailing list that I can download??? From the silence I guess that a compressed archive of the mailing list isn't available. The searchable online archive works fine though so I would start reading that: http://lists.gnu.org/archive/html/avr-gcc-list/ -Matt ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] makefile for ubuntu
On Wed, Oct 12, 2005 at 12:58:33PM -0700, Cullen Newsom wrote: Does anyone want to tell me all the undocumented* tricks to getting a working dev environment for avr-gcc on ubuntu with the stk200 and either it's programmer, or with avrisp? Anyone have a makefile that might work? I found setting up Ubuntu for AVR development straightforward because Ubuntu shares Debian's packages. The development board and programming cable I use aren't exactly the same as an stk200 but uisp still programs fine if I tell it that a stk200 is attached. (Sorry I don't have information about using other programming software.) Here is the set-up I use: 1) Open synaptic package manager. 2) Add Universe packages. 3) Select avr-libc, binutils-avr, gcc-avr, and uisp. 4) Apply changes. 5) Create a makefile that can generate hex files. Possible options are mfile (http://www.sax.de/~joerg/mfile/), or the Makefile included in WinAVR (http://sourceforge.net/projects/winavr/) 6) Once you have a hex file, you can program it like this: uisp -dprog=stk200 -dpart=atmega128 -dlpt=$(PARPORT) --erase --upload if=$(PRG).hex Where $(PRG) is your base program name and $(PARPORT) is your parallel port. In my case I didn't bother to create a /dev/parportX device so I just run run uisp sudo and program directly to 0x378 which is the common location for the first parallel port. It would be a good idea to make a parallel port device at some point so I can make it writable by normal users... I think I could have made a compiler out of papier mache'... You may want to make sure someone isn't already working on this so you don't duplicate effort! -Matt ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
On Wed, Sep 07, 2005 at 11:27:21PM -0600, E. Weddington wrote: Joerg Wunsch wrote: . 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. But which of the names to retain? I tend to keep avr/interrupt.h as this sounds more logical, but then, interrupt handlers are usually introduced with SIGNAL() for us... I don't have a good answer either. :-/ My suggestion would be to change INTERRUPT to be the same as SIGNAL, and then deprecate SIGNAL. After this the avr/interrupt.h file could be used and all naming would be completely obvious. Developers that actually need to use INTERRUPT could just use the new low overhead interrupt routine suggested by James A.R. Koehler: http://lists.gnu.org/archive/html/avr-gcc-list/2005-08/msg00150.html -Matt ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] AVR-GCC question
On Mon, May 23, 2005 at 01:55:21PM -0400, Trampas wrote: Additionally you could have the compiler implement polymorphism while keeping C code. For example you could at compile time check variables types and conditionally create code. I believe that the Linux kernel actually uses compile time object oriented behavior like you are describing. This is a cool idea because there is no performance penalty once the code is compiled. I would argue that there is a big difference between 'static OOP' and 'dynamic OOP'. It seems like few OO languages allow dynamic OO behavior where classes and objects can change at run time, Ruby is an example of a language that does do this. All of the static OO behavior for a program can be known at compile time and so should be implementable with some type of meta front-end like you have described. -Matt - Where did the universe come from? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
