Shop our Airplanes Products Drone Products Sales
Thread Tools
Feb 04, 2013, 06:23 AM
RC beginner
sorry for the delay getting back. unfortunately i dont have internet access to rcgroups on weekends.

my photo and wiring description in post #1 are correct. for isp programming we are stuck with sck/miso/mosi pinout defined in the datasheet. for bootloader programming and user applications we are free to use these pins as we see fit. in my case they were chosen based on easy connection to a7105 modules.

as far as fuses you are right about first digit in a 16 bit number being most significant. as you can see by decoding bit functions in datasheet tables 87-88 the chip is set for 8mhz internal oscillator. this has major advantages not the least of which is ability to fine tune for more accurate baud rates than possible with 8mhz or 16mhz crystal. also note that "save ee" option is enabled. i never quite understood why the "tarduino" crowd want to destroy ee data every time a program is loaded. i suppose they had something in mind when making this choice... or maybe not.
Sign up now
to remove ads between posts
Feb 08, 2013, 09:25 PM
Registered User
midelic's Avatar
See attached .asm.Tell me is it blinking or not?
Anyway thank you...........!.It was a good exercise.Good working delay routine tool and avr studio will calculate the time delay for me on the other project.
Last edited by midelic; Feb 09, 2013 at 08:08 AM.
Feb 11, 2013, 12:46 PM
RC beginner
you program worked perfectly. this is lucky because even a blink program is hard to get running first try considering you didnt even have a mega8. the same hex file does run fine on my mega64/128 too so you should have tired that.

seeing your spi code last week i was convinced you were clueless because the avr dont have an "A" register. it looked like you were confusing these with old motorola or intel microprocessors intead of modern microcontroller. now i see you like to use those defines for some odd reason which is perfectly valid but did throw me for a loop. you did much better than i expected.

ok..... was that kissy-kissy positive enough? whos next? jake you say? hmmm... he is not doing so well. lol!
Feb 11, 2013, 01:02 PM
Registered User
midelic's Avatar
I told you it was only a sample code.Of course it has no def on registers or routine calls defined.I was interested only an opinion on the code for sending SPI signals.If it was only that sample the avr studio simulator would spit error warnings all over.I know that defs is too general but hey....I'm at the beginning with avr asm.I don't have any M64/128 free.I ordered Atmega8 locally,will arrive in 1-2 days.
I finished only the Tx code binding part.I'll test it this week end.
Last edited by midelic; Feb 11, 2013 at 01:21 PM.
Feb 11, 2013, 01:38 PM
RC beginner
Originally Posted by jakestew View Post
Not sure what you're asking here... You can blink a LED in three lines in C.

There's certainly sometimes an advantage to directly manipulating the hardware with asm vs. telling it what to do with a programming language. But for the most part asm is just foolish pride. Writing in asm is saying that you know how to manipulate the hardware better than the c compiler writers.

When I write a "for" loop I don't sit and think "maybe I can implement a better for loop in asm than some expert compiler programmer could." Microchip makes the chips and the compiler, so how can I hope to manipulate their hardware better than they know how to?
obviously spoken by someone who has little understanding of these chips and their use, be it pic, avr, etc whatever language is used. "foolish pride". lol! you should know that ive done far more programming in c and anly recently discovered the advantages if asm. not only more control and less hassle with tool issues but the abilty to use chips that cost 55 cents instead of $5. yeah... the difference IS the great.

Originally Posted by jakestew View Post
Here's a PIC blinky program for you in C...

PORTA = 0b000001; // Turn on LED
__delay_ms(500); // Wait 1/2 sec.
PORTA = 0b000000; // Turn off LED

Three lines, beat that. Where do you think you can write that better in asm? I just don't see how I can write to the GPIO port or calculate the delay in NOPs any better than the chip manufacturer's compiler writers could. I'm happy to compile that and see if you can beat it.
3 lines? are you serious? that does not even vaguely resemble a program and will not compile at all under any toolset. wheres "main"? wheres the "return"? we doe neeeed no steeenkin brackets! obviously a snip you dug up from some book on beginner programming.

also note that your program does not flash the led continuosly like midelics and everyone knows the classic bliniky should. it dies before getting started.

by the time you add in the source for the startup module (google is your friend), library routines (_delay_ms is not a keyword), and any macros in the include files your "program" will be, not 10x bigger like i said, but 100x or 1000x times at least.

and it looks like youve carefully chosen a platform that you knew neither i nor midelic have operational a this time. if you want to demontrate your point you will have to use a compiler we all have access too (iar/codevision demos, gcc, etc). not one peculiar to an oddball device either but a chip we can test your binary on. namely mega8. mega64. mega128, tiny13 (good luck finding a c compiler for that), or any other common avr. so you might also want to investigate the usage of "naked" compiler directive. and dont forget to include the hex which im now revising my prediction about it being 10x bigger. now i say 1000x or 10000x times if youre lucky. if i dont hear from you by tommorrow ill show you what a small c program actually does look like.

btw heres what youre competing against:

com r23
out 23,r23

this is a complete program, not a snip or fragmant. downloaded to a mega128 or mega8 it will flash the led continuosly at about the same rate as midelics code. notice the source file is only 17 bytes. we dont count lines here because a line can be 1000 characters long and a pain to count anyway. the reason its so small is because there is no need for include files at all (hear that midelic) the binary is 4 bytes btw. and the command line to assemble is "avrasm t.asm t.hex". try compiling a c programm from the command line. i can do it but only because i am a c expert. forgive my foolish pride. lol!
Feb 11, 2013, 02:30 PM
Registered User
midelic's Avatar
In fact this one of the reasons I choose asm.To keep me close to hardware.IMO the farthest from hardware instructions the more difficult to understand how any programming language really works.
Can be used one of the A7105 from a micro board(I have one Syma X1 i want to kill) for a TX module?or only Rx?
Last edited by midelic; Feb 11, 2013 at 02:55 PM.
Feb 11, 2013, 02:51 PM
RC beginner
i agree. unfortunately that theory breaks down for really big and complicated programs. at that point c is by far the best tool for the job and also the output size difference quickly shrinks to almost nothing. imo asm is best when you talk few hundred or even couple kbytes. but when you get up in the tens of kbytes high level language is a necessity. btw there are high level alternatives to c, python and basic compilers like bascom being couple examples.

even for massive avr programs in the hundreds of kbytes it may be necessary to poke a little asm into the c for those really time critical loops.
Feb 11, 2013, 05:23 PM
Registered User
3 lines? are you serious? that does not even vaguely resemble a program and will not compile at all under any toolset. wheres "main"? wheres the "return"? we doe neeeed no steeenkin brackets! obviously a snip you dug up from some book on beginner programming.
Come on Dave, I know you don't need me to put that code inside a "while(1){};" loop. There's your program!

"_delay_ms" is a macro that works in Microchip's compiler. Pretty darn basic. Not hard to count up the NOPs based on the instruction clock either.

If you want a good comparison check out the googlium pic tutorials. They do each example lesson in assembly, then C, then compare the two in terms of lines and memory.

Even in these very simple lessons, 98% of the time the C is significantly less lines and slightly more memory than asm. It's *nowhere* near the 10x, 100x, or 100x that you suggest.

Unless you're a super genius trying to write all the different simple operations in asm rather than using what the compiler writers have come up with for C it is a losing battle. Even if you're smart as a whip and know your processor front to back all you end up doing is wasting many hours of your life to shave off a few bytes of program memory. Then repeat that learning curve and wasted time over every different piece of silicon, and every program you write, and youend up wasting countless hours of your life just to satisfy your PRIDE.

If you aren't particularly gifted at computer-like thinking and memorizing every instruction set for every processor then you end up spending a lot more time just to write a crappier asm program that doesn't even hold a candle to what the chip manufacturer's optimizing compiler produces.

None of that analysis even takes into account code readability, portability, scaleability to larger programs, or more advanced program flow or data structures. Asm completely breaks down in those respects. If you want to be closer to the hardware then you might as well work with a FPGA then write your program in asm. Have fun spending your whole life reinventing stuff that's been done a thousand times before by thousands of designers/engineers/programmers. Hopefully your pride is worth dissing all the people that have already dedicated their careers to solving these low-level problems and writing compilers so that others don't have to slog through learning the best way to implement simple structures directly with processor instructions.

More power to you for writing assembly, but at some point it obviously becomes foolish pride. It's easy enough to throw sections of assembly into your C code, so unless you think you can rewrite EVERY line of C in assembly better than the compiler programmers... you're just wasting your own time.
Feb 11, 2013, 05:30 PM
RC beginner
ok.. so we pretty much agree now your actual source file is at least couple orders of magnitude bigger than my 17 byte example. macros are simply a way to hide code. and anyway thats not a macro. its a library routine. basically another way to hide the real code.

also as i tried to explain, even in a while loop your "program" will not blink or do anything else. you need at least two delays. once you fix that lets see a hex or bin file so we can decide how big that really is. again for comparison with my 4 byte example.

and someday maybe an avr version so we can see if it actually can ever be shown to work.

btw your theory that delays like that are implemeted with nops shows pretty much exactly your level of competence here.
Last edited by dave1993; Feb 11, 2013 at 05:43 PM. Reason: nops.... lol!
Feb 12, 2013, 02:50 PM
Registered User
Dave, Jake, Midelic...I love this I'm really curious about what programming tools each of you are using for Atmel AVR Chips.

You guys really need to load Atmel Studio 6 C/C++ Compiler(it's free) and give it a whirl. It's not limited trial software. There is no cost. It's a powerful development environment that uses WinAVR as the C/C++ Compiler/Linker etc.

OK...let's settle this "C" vs. "ASM" argument once and for all.

I'm assuming that you are using an ATMega 8 with your LED on Pin C3.

First let's look at Medelic's Blink ASM Code without the first 4 lines that set the Stack Pointer register to point at the end of memory. Those first 4-lines of code will be executed only once and will be different based on the chips RAM size. So we're left with 16 lines of executable code. Two bytes per ASM instruction...that's 32 bytes of program space.

Medelic's ASM Code(21 lines of Source...16 lines of executable code...32 bytes of program space):
rcall DELAY
rcall DELAY
rjmp Loop
ldi A,0x7d
ldi B,0x7d
ldi C,0x7d
dec C
brne loop3
dec B
brne Loop2
dec A
brne Loop1

Now here's an equivalent "C" program that will blink the same LED at rate of 1 second(1sec on...1sec off).

The C Program is all of 14 lines of source code including those pesky braces:
#ifndef F_CPU
#define F_CPU 8000000UL // or whatever may be your frequency
#include <avr/io.h>
#include <util/delay.h> // for _delay_ms()
int main (void)
DDRC |= 1<<3; // initialize port C3
while(1) // Loop Forever
PORTC ^= 1<<3; // Toggle Port C3
delay_ms(1000); // wait 1000 milliseconds

Here is the resulting ASM code from the C Complier using the Level 1 optimization. I left in the source lines from the C program...but I count 15 lines of ASM Code...30 bytes of program space:
int main (void)
DDRC |= 1<<3; // initialize port C3
sbi 0x14, 3
while(1) // Loop Forever
PORTC ^= 1<<3; // Toggle Port C3
ldi r25, 0x08
in r24, 0x15
eor r24, r25
out 0x15, r24
ldi r18, 0xFF
ldi r19, 0x69
ldi r20, 0x18
subi r18, 0x01
sbci r19, 0x00
sbci r20, 0x00
brne .-8
rjmp .+0
rjmp .-26

So.....what are the take aways for this specific example of "C" vs "hand-made ASM".

1. The C compiler actually generated shorter code.

2. The C Compiler allows you to compile the same program for different chips simply by selecting the chip from a simple dropdown(ATMega8, Mega64, Mega128)...then hit the "rebuild button".

3. The C Compiler lets you set accurate delays down to a Millisecond resolution. In hand-crafted ASM you would have to calculate every delay counter by hand.

4. In order to save power, if you decide you must run at half the Clock Speed from 8 down to 4 MHz, in hand-crafted ASM you would have to parse through all your ASM delay code, recaculate and change every single counter. Using a C compiler you would change one line of source code...#define F_CPU 8000000UL would become #define F_CPU 4000000UL...then click the "rebuild button" and you would be good to go.

5. In the C code example, the C Compiler did burn up a single byte of RAM space. The hand-crafted ASM program uses RCALLS, thus uses 2 bytes of the RAM STACK for return addresses. As a general rule a compiler will use the relative offset RJMP(2 clock cycles) instructions where it can. On the other hand, an ASM handcoder usually doesn't take the time to do RJMPS. Instead he sticks to RCALL(3 to 4 clock cycles), and RET(4 to 5 clock cycles) instructions which are twice as slow and burn RAM by pushing return addresses onto the stack..

I know these results are surprising. I confess, I too originally bought into the misconception of the overhead of higher level languages. That is, until I started looking at the ASM output files(.lss) being generated.

The moral of the story's very hard to beat an Optimizing "C" compiler in generating compact efficient code.

Seriously guys...install Atmel Studio 6, and you'll never look back.
Last edited by RJKIRK; Feb 12, 2013 at 03:33 PM.
Feb 12, 2013, 03:38 PM
RC beginner
hi rj,

what about my 2 line program that does exactly the same as your 14 line one. 7x bigger? cant be! maybe we dont want to talk about lines after all. so what about the 30 bytes actual "true" code that it generates? let me see.... 30 divided by 2... unlucky number!

as far as as6 ive had that on my desktop since it was released last year but really havent used it yet. like many still reeling from bad experience with as5. back when i was young and foolish many hours were spent on as4. i though the simulator was the bees knees. now that im grown up and smart the original atmel assembler is my main tool. all 105 kbytes of it. how much disk space does your (and my) as6 take? let me count the kbytes on my fingers... oh wait, not enough. let me count megabytes. oops.. still no good. how many fingers for gigabytes... well almost!

"real men use assembler" lol!

Last edited by dave1993; Feb 12, 2013 at 04:12 PM. Reason: give em some hex to chew on... not much im afraid.
Feb 12, 2013, 04:04 PM
Registered User
Which two line program is that?
What chip does it run on?
What does your two line program do?

The guys over at AVR Freaks hate Studio 4 and 5. But the concensus is the Studio 6 has eliminated most of the bugs and ugliness.
Feb 12, 2013, 04:15 PM
RC beginner
it was only a couple posts before yours. and i did just put up the hex so you can try it yourself. really good idea to read at least a page or so back before jumping to the end and making noise. it WAS very small so maybe understandable:

Originally Posted by dave1993 View Post

com r23
out 23,r23

this is a complete program, not a snip or fragmant. downloaded to a mega128 or mega8 it will flash the led continuosly at about the same rate as midelics code. notice the source file is only 17 bytes. we dont count lines here because a line can be 1000 characters long and a pain to count anyway. the reason its so small is because there is no need for include files at all (hear that midelic) the binary is 4 bytes btw.
freaks????? yeah right... that where to go to get help. lol!
Feb 12, 2013, 04:17 PM
Registered User
What chip are you running that on?
Feb 12, 2013, 04:26 PM
Registered User
midelic's Avatar
Dave I have some doubts.Can I ask you about some asm snippet code regarding the loading the A7105 control registers,........... if I wrote code correctly skipping the (oxff) values from the table?Are you in a good mood for that?It is only a sample not all code.

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Mini-HowTo TH9X Turnigy FlySky IMax modify module to SMA and 1W booster DIY FPV rotaryboots Radios 5 Feb 03, 2015 04:46 AM
Sold iMAX/Turnigy/FlySky TX module & RX John Kim Aircraft - General - Radio Equipment (FS/W) 0 Jan 12, 2011 12:33 PM
For Sale iMAX/Turnigy/FlySky TX module & RX John Kim Aircraft - General - Radio Equipment (FS/W) 2 Dec 09, 2010 11:15 AM
For Sale Turnigy/iMAX/FlySky TX module & RX John Kim Aircraft - General - Radio Equipment (FS/W) 0 Oct 27, 2010 11:03 AM