Hello, On Mon, 10 Dec 2012 17:34:36 +0100 Georg-Johann Lay <a...@gjlay.de> wrote:
[] > Besides that, using design-pattern "delay" for anything else than > short delays to wait for, say, parasitical capacities / > inductivities, can be considered as a design flaw. But that's a > different story... > > Sorry, I cannot help you with dreaded [tm] languages like C++ ;-) > > Maybe __builtin_avr_delay_cycles is too limited with the const > delays. Using variable delays is possible if the requirement of > cycle-exactness is dropped. What I'm trying to do is implement cross-MCU metaprogramming library which would provide users inventory of basic primitives and patterns and allow to freely combine them in any ways, while maintaining clean, consistent, scalable syntax/API and achieving close to assembly efficiency (all that again across number of CPUs/MCUs). So, there would be all (and more) of: StaticDelay::delay() for cycle-perfect constant delays DynamicDelay::delay() for dynamic loop delays TimerDelay::delay() for timer-based delays Then user can superimpose physical-timedness on top of those primitives: TimedDelay<FrequencyEncapsulator, StaticDelay>::delay_ms() Where FrequencyEncapsulator is an entity which knows the current frequency, and can be anything from static number to a routine to query hardware for current frequency in effect. Such magic are simply not doable in "classical" C at all. Now if we assume that inlining is C (as in C99, how many people think of inlining as C feature vs GCC extension?) thing after all, some subset of that magic might be doable, but syntax would be more cumbersome and some limit would be hit soon for sure (C++ does aggregate type inference/management, which C doesn't). So yep, I reached for C++ after not touching it seriously for around 10 years... > > So, I started another try on ldi-based approach, and just got lucky > > that my test code had "good" value of literal integer constant. > > Because it turned out that "M" asm constraint is very picky > > regarding value it gets. One would think that casting to uint8_t > > would be the best way to get a value suitable for it, but actually, > > that will throw "error: impossible constraint in ‘asm’" for any > > value >=0x80. Fortunately, I found that (& 0xff) does the trick, so > > mission accomplished. > > The question is why you use "M" in the first place and not "n"? Googling led me to http://www.nongnu.org/avr-libc/user-manual/inline_asm.html , and after checking that this list is also hosted on nongnu.org, I thought it's the authoritative manual. And it doesn't list "n". Is there more up-to-date avr-gcc manual? Thanks for all other suggestions! My current implementation is at https://github.com/pfalcon/PeripheralTemplateLibrary/blob/master/include/delay_static_avr.hpp (not yet cycle-perfect, but that's doable, I have that for MSP430). -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
