Ralph, many thx, that really brought back lots of early coding memories, some of them good .... but in those days you used to be grateful when a loop went around and stopped roughly when it should. Keep up the great work.

Oh how I enjoy the addition of a little assembler to my day. It reminds me of over 30 years S360/S370 bit banging. Thanks Ralph.

Thanks so much for doing this! Having dabbled with a few port-reads/writes in an ISR for an RTI-driven app, I thought I "knew enough", but you've filled-in gaps in my knowledge that I didn't even know that I had! Like many of the commenters below, I have fond memories of low-level coding. In my case, it was to test the hardware that I designed in my first day-job, now 40 years ago. Over the years, I "climbed the stack" and transitioned into higher-level languages, but unless I could relate what the code was doing to the hardware, I always felt that there was something missing. While I wouldn't dream of using assembler for anything other than ISRs or interfacing directly with (time-critical) hardware, I now feel less daunted by the prospect, for which you have my sincere gratitude.

1 year after your upload, and just finding this, I'm now getting flashbacks to hand assembly on an 8080, then 6502 and then 8086. I need to get a better life! Long live NOP, always worth it for padding loops!

I'm a very rusty coder, just starting to get into arduino, and you, sir, are an excellent resource. Thank you.

Thankyou Mr Ralph for the interesting as always. I have also dipped my toes into assembler at one point got bitten by a assembler shark and haven’t been in there since. 😉. I see lots of people asking why use Assembler you have responded on various comments it’s for speed. It is indeed and also as per some of your other videos Arduino can be quite convoluted in the background. They make things easy (Thankyou Arduino) with things like digital write and read but it’s convoluted. And have to cater for a lot of things. The real place where I’ve seen assembler shine is when your hardware testers on the slow edge with regards to hardware and you have to write a driver that bit bangs and the timing have to absolutely spot on.

I like it when people get into the roots of things and actually explain them. Great video. Great lesson. Thanks.

Hi Ralph, this is interesting stuff, one of my fond memories of the BBC micro was the ability to freely mix BASIC and assembler...cheers.

Back in the dark days of computing, learnt to assembler program on a Science Of Cambridge Mk14. First challenge was to build the Mk14 kit and get it working. Had to write the assembler on paper, convert this to hex codes and then input the codes via a keypad. Program was lost when the power was turned off to the Mk14! Making alterations to the assembler was a real pain, so had to learn to be very patient.

Thanks again for great content! I don't believe I often need to go that deep but man it's hard to find and to get your head around when you suddenly need to.

Thank you so much for this awesome tutorial. Assembly can be very amazing.

Dear sir, Thanks. Your lesson is very clearly structured. I understood everything. Your speaking style is very warm and easily understood.

You are a great teacher!

Great stuff indeed. Got me inspired to try some things on the ATtiny13A... Thank you Ralph!

the curate's egg - ahh, the memories flood back. Thanks for the nice intro to using asm with Arduino. Just what I need to bit-bang SPI receive on the Uno.

Over the years, I've received some funny looks after asking my programmer friends about assembly language. The basic gist of their sometimes rather snarky comments has been that it's simply not worth learning about. But as I enjoy understanding how things work, I greatly appreciate your taking the time to provide this brief example, which has been most instructive.

Thank you, perfect!

Lovely work Ralph. Very good explanation! 👍🙂

I've tried a lot, thank you.

back again :) re-watched a great reference video :)

I just popped in from the future where I was watching Ralph's video on FPGA logic routines. The demo was... wait for it...a blinking LED. Seriously, as you know, a blink sketch is a nice, uniform way to demo some idea or concept and not have to explain the part that isn't the part you want to explain.

Thanks Ralph. I like your presentation style, especially your choice of background music. That brought back all kinds of memories: In 1968, learning how to program delays on a PDP8, the only way it could do timing. In ca 1980, programming a mask programmed Mostek MK3870 as a dynamically tunable tone decoder for 5-tone signalling (selcall) for two way radios using a software "delay line" that could generate a range of delays with, AFAICR, 1uS resolution. Every cycle counts!

brill video jusy what i was looking for top stuff :) thank you

Very interesting, thanks for sharing!

Excellent video, Ralph. Your description of the volatile attribute was the clearest I have ever read. You don't have to apologise for the flashing LED in this context. For other viewers: you have just seen the "hello world" for bit banging. Imagine that, instead of an LED, pin 5 was connected to a device that required an accurately controlled pulse to, say, initialise a display or simulate a 2nd I2C data connection, this is the way you would produce that output. Now, if you tried produce that pulse, or stream of pulses, using classic Arduino IDE coding, you would find that it wouldn't work or only worked intimately because the timing would be off. I advise those really interested to re-run the video and copy the code from both files (you will have to stop and start the video). Make sure you get ALL of the comments, there is a ton of info in there. Well done, Ralph.

Thank you for a great video

Hi Ralph, Off the top, let me say how glad I am to see you back creating great content! I usually learn something interesting, and you almost always give me something to think about. Speaking of which, I'm afraid I have a few nits to pick with your assembler "delay_10ms" subroutine... First nit is that you didn't allow for the case of someone passing a zero count in r20. If that does happen, then the first decrement will set it to 0xFF, and your inner loop will then run 256 times, giving a total delay of about 2560mS -- or a bit over two and a half seconds. I know it's not an external routine, and you've got complete control over the values it's being called with, but still... (as a said, a nit). My second nit goes a bit deeper into your accuracy issues, and the delay calculations in your comments to the routine. From your video, you were obviously aware of the issue, but you got the math wrong in the comments. (Yes, I know you'd say "maths", but I'm Canadian so I don't add that extra "s"). At line 78 you say "At 16Mhz outer loop runs in: (loopCnt * 159,991) + 1 + 4 - 1 cycles = 159,995 cycles". Ignoring the fact that it takes the same number of cycles regardless of the clock frequency, the calculation is wrong. Yes, the inner loop does take 159,991 cycles, but the outer loop isn't run just once, it's run over and over again -- "loopCnt" times. So the setting of the inner loop counter (2 ldi instructions) at lines 65 & 66, the loop counter decrement (subi) at line 75, and the conditional branch (brne) at line 76 are all executed every time through the loop. Counting it out--- ldi r30 instruction : 1 cycle ldi r31 : 1 cycle (innerLoop, total) : 159,991 cycles subi r20 : 1 cycle brne delay_10ms : 2 cycles TOTAL: : 159,996 cycles -- all executed loopCnt times, less 1 cycle for the last brne execution where no branch is taken. So the correct calculation - with parentheses corrected - is: ((loopCnt * (159,991 + 1 + 4)) - 1) = (loopCnt * 159,996) - 1 Using your example of a 100mS delay in the comments from line 83 forward, the actual calculation would be (10 * 159,996) -1 +1[for the nop] +4[for the ret] = 1,599,960 +4 = 1,599,964 cycles, not 1,599,914 cycles. Still wrong, but very slightly less wrong. And BTW - the error could be adjusted to negligible with a few more no-operation instructions. Assuming the 16MHz clock, what you want is for the entire subroutine to take (loopcnt * 160,000) cycles. If you were to add 4 nop instructions to the outer loop, but outside of the inner loop, (i.e. after line 71 and before line 75), then your outer loop would take EXACTLY 160,000 cycles each time through. Do that as many times as loop count says, and you'd only be out by the overhead of the return process. Delete the nop for the "missing" cycle on line 80, and you'd be over by exactly 3 cycles no matter what delay was requested (well, except for zero - see my first nit). Offhand, I don't see a reasonable way to eliminate that last error, but I think a very small constant error of 3 cycles (less than 0.00025ms at 16MHz) sounds better than a variable (and obviously non-obvious) delay-dependant error. Of course you'll never be able to get 100% accuracy with this method. If for whatever reason your main routine needed the bit reset (LED off) to happen some exact number of cycles after you did the bit set (LED on) instruction, you'd need to count every cycle in between. That would have to include not only the instructions executed within the loop, but the ldi to set the delay count, and the rcall instruction to call the loop. But I see from the assembler manual (last - and nittiest possible - nit being picked here) that the rcall instruction takes 2, 3, or 4 cycles depending on which AVR processor you're running it on, so there's an inherent uncertainty of 2 cycles when calling a subroutine. Oh well. As you said, this was a demo - and a very fine demo at that! :)

Assembler, still relevant today! A very basic intro to assembler. hopefully you can ramp that up with more interesting examples in future. I'm keen on learning how to control and use all types of Arduino ports as some public libraries are just too large... maybe write a game in assembler?

Great video you sort of lost me I think just after "And welcome back" :-)

Really interesting - thanks Ralph! Did some PIC assembler years ago - we are so spoiled these days :)

Very informative video SIR

Wow Ralph, pic assembly that takes me back probably mid/late 90's. Pic 16c55 one time programmable, had to use I think the JW variant that was UV erasable took forever to develop code for it having to put it through the UV eraser every time!

Oh snap! It's getting intense boys!

For every single processor/MCU family I've ever used, I have gone trough an assembly language and It's architecture first (I know it takes time), then later make C language programs. That way I always know why It behaves the way it does.

This was GREAT!!! Everybody should be introduced to Assembler / Macro code, I cut my teeth on VAX11/32. Well done, clear and concise.

Great video. 😃

you did it again...great content. I will play with this.My cat says "Bacon Bacon Bacon!!"

Hi Ralph, good video. In the spirit of teaching, Assembly is a low level programming language that gets assembled by the assembler. And then linked by the linker.

Hi again, my Friend ! Assembler language reminds me when I first started programming those PICs. It evolved, for sure, but you lot me at « Assembler » ! Hahahaha !! (Just joking !). I guess, with old age and memory starting to fail a bit on the sides, one trends to keep it as simple as it gets with Arduino programmation. LOL. Once again, I like your way of explaining things. It makes it simple to understand and and I appreciate it very much. Have a great evening and stay healthy !

Thanks for this video. An exact 10ms delay routine use always a “timer-ISR”, I miss the example for this in assembler for 100 usek or 1000 usek. A 10ms Counter can take the 100usek ISR for calculating if it was 100 times called. Mixing code in assembler with C++ code is a good way to solve timing problems. C++ compiler are not so good in optimizing code for cycle reduction.

Would this general calling setup and assembler syntax style work in the Arduino IDE for ARM-based Arduinos like the MKR series? Obviously the specific instructions and registers and I/O would need to be the ARM ones, but other than that is the overall principle the same? Thanks for the great video. Flashbacks for me to PDP11/10 assembler in the 1970s and Z80 in the 80s.

Great video. Although it did start a series of flash-backs to writing assembler for Motorola 6800 and 6809s. At the time there was no added work. Having to consider a 16 bit number as two 8 bit numbers was just the natural way. All this changed when we started writing C, under OS9. OH! There's another flash back to coding in "machine language" using the op codes printed on a folded card. Never got into microcoding.

Cheers for that - I wrote a $h!t load of 6502 / 68000 / 8088 assembler back in the day for industrial electronic uses, how we could have used a friendly higher level langauge compiler back then! I was telling my Prof that C was the language of the future (according to Byte) but he would 'ave none of it, and so we toiled on with Assembler. But handy to know how to incorporate it into Arduino code, thanks for the overview.

My C sucks and in my Diploma of electronics and comm eng i have been only familiarised with assembly on micropcontrollers and microp processors like 8085 and 8051 else i wouldn't have been able to make heads and toes from this video But i understood it really well its a personal achievement to actually understand a geeky video online... Really loved your explanation it was to the point and really amazing....... I am so dumb

Excellent! WTG Ralph - BTW, What is exactly the IDE you are using in this video? As far as the NEW Arduino IDE I can say that it takes a very long time to start-up - don't know really why it doe that? BUT I was thinking to move to a better Arduino IDE based alternative - I would be happy to know what is the one you are using? As always, Thanks for the videos!

Z80 in the 1980s was my start in assembly, looking up in z80 user manual to find the Hex code and entering in to ram on my kit built Talking electronics computer, you can still buy the kit last I heard.

Great stuff, thanks. Got it as a UKposts recommendation. So far I've managed to avoid assembler even though I've been doing audio-related stuff, timing obviously important. Couple of questions maybe you can help with, save me trawling: I'm using PlatformIO (on VSCode, on Ubuntu). Are there any differences I should be aware of for ASM in this environment? The other thing - obviously there will be significant differences when targeting different boards (ESP32, Arduino Due), but in practice, ballparky, how similar will the ASM be? (I've only glanced at the instruction sets - eek!)

for a sunday morning, THAT HAS BEEN MOST INFORMATIVE+INSPIRATIONAL, you have demonstrated to come from arduino sketch to call an assembler routine, how does on do the reverse, from assembler to arduino sketch ??? thanks in advance for reading and answering !!!

Hi Ralph, if you want to calculate accurate timing for Arduino timers try, RTM TimerCalc . It also produces the assembly code for Arduino.

Hey Ralph! In the asm part, you did not safe registers before used. This can work, depending what the gcc produced for the C part of your sketch, but it also can make things utterly fail. So it might be wise to safe registers (push) before using in asm, an restore (pop) them again when done in asm. At least for the registers you do use in the asm section. Best wishes from Berlin!

good video.

Hi., Very informative video. I am assembly language programmer and I have assembly codes written in AVR studio. I would like to include those routines in arduino IDE. If not please let me know where I can find Arduino Assembler. Thanks

Doesn't the clock circuit in the micro divide the crystal freq in half?

How do you ensure that the registers you use are not used by the compiler generated functions? Does the compiler guarantee registers it won't touch? I enjoy seeing the assembler stuff. I was on the design team for the Magnavox/Philips Odyssey w, and the cartridges were usually 2k ROMs, programmed in Intel 8048 assembler. I did three or four of them.

erm. I know it's not the point, but your microsecond perfect blink is being looped by the compiled skeych - a bunch of extra code that you have very little control over and is adding unknown time to that second. Even without taking any interupts into account.

What IDE are you using? It looks like Eclipse. I have not seen videos showing Eclipse used for Arduino boards.

which ide were you using in this excellent video?

Hi, mi name is Julian from argentina, I have found intresting this helpfully info because I am try to build a floppy emulator for my tandy 1000and assembler is the best option for the r/w realtime routines. thanks to share!

Hi Ralph, SBI PINB,5 will toggle PORTB, PIN5. Call it twice to flash the LED. No need to SBI and CBI PORTB in your blink function. Saves typing! ;-) Cheers, Norm.

I wish AVR's had something like the DWT counter in Cortex processors. Really nifty little thing for figuring out exactly how long something took without the need for cycle stealing interrupts :)

Anyone know how I would shift a bit over a certain amount of times using multiple led's?

is there any way to get the Arduino IDE to make an assembler listing of the entire sketch?

04:59:22.998 -> That's a blink:241 04:59:24.002 -> That's a blink:244 04:59:25.006 -> That's a blink:247 04:59:26.002 -> That's a blink:250 04:59:27.022 -> That's a blink:253 Notice it is off a little assuming the goal was to make it once per second. Which variable do I vary in the routine to change that?

So I was looking forward to reading all of those comments in the code, but I can't seem to find a github link to download it...

Wow, the way it took hours of coding to make that LED blink, so almost precisely. It would be interesting to see a pro/con table in your mindset for Assembler usage/value vs A Higher level language. Personally, I was happy to leave assembler behind for such fancy things as Cobol and Fortran pre 1980. Even BASIC on my C64 made my heart thump in those days, now it's more about the fastest way to achieve my goal(within limitation) as I'm not Government employed or production orientated. A Canted view perhaps , but still a very interesting and well presented video, but like skydiving videos, I doubt I'll try it. 😉

great video as usual. Calling assembler prices is a bit of a stretch. The crystals is not that prices, it can still be a few hertz of but we do know how many clock cycles a given instruction takes. It can bring up a discussion on the difference between precision and accuracy and "what is necessary". Let's not open that can of worms. With assembler everything is just more complex and you really do need to plan ahead. Variables, registers, addresses and such do need some constitution. The higher the level of program language, the easier to is to handle those issues, in most cases you don't even think about it. As i remember, the "word" size is one of the earliest measures, earlier than byte. It had an odd size, by today's standard, I think it was 14 or 15 bit long.

"I used to write PIC assembler". The first step to recovery is admitting that you have a serious problem. I feel your pain. Once Arduino came along, my PIC programming days pretty much ended. I thought I recognized your name from the piclist. I used to post on there a lot, but it's been quite some time. PICs are great, but the risc assembler sets the standard for coding ugliness. AVR assembler is so much nicer.

The Serial communications will affect your delay.

You don't need the “volatile” qualifier, as the counter is not modified in the background: it is modified by a function your C++ code calls explicitly. The compiler assumes that any external function can potentially have side effects, such as modifying externally visible global variables. You would need to declare the function with __attribute__((pure)) in order for the compiler to assume it has no side effects. Only then would you need the “volatile” qualifier. And you don't need __attribute__((used)) either: the compiler can only optimize-out a global variable if it has internal linkage, i.e. the “static” qualifier. It cannot optimize-out a global variable with external linkage. The linker can, but it also can see that the counter is used by the assembly code.

What assembler do you use here?

Great video, thank you for explaining to me the uint16_t I have seen this in other people's code and have been frightened of it as the internet doesn't help

I know this is an example on how to use assembler. But just to nitpick on you saying "blink exactly every second": this sketch does not do it, assembler or not. You still have Arduino's standard timer interrupt and the whole (invisible) Arduino outer loop (which calls the sketch's "loop()") "using up" clocks. But you are definitely a little bit closer to "exactly 1 second", because you replaced the overhead heavy digitalWrite with an assembler instruction ;) .

You must work somewhere as a programmer I'm guessing in C/C++ and you're used to using the debugging mode where asm code is referenced as you step through the code. If I could I'd be doing all my coding in a professional grade enterprise IDE where you only have to specify a target platform.

Interesting... I generally die a little inside every time I have to do work in assembly lol.

Flashing LEDs Oh the Excitment....

C++ only mangles function/member names, not variable names. That's why you need the extern "C" for blink() and start(). I think the use of asm("counter") is an unnecessary concept for beginners.

i know you know best (i am talking to compiler ..not to my wife).::::-----)))

You would use gcc-avr plus associated libraries. __asm__ __volatile__( "addb $1, %0 " "adcb $0, %1 " "ret " :"=m"(COUNTER_LO),"=m"(COUNTER_HI) : "m"(COUNTER_LO), "m"(COUNTER_HI) : );

are you related to Francis Bacon

All in all it gives me a little idea of why: 𝘷𝘰𝘪𝘥 𝘭𝘰𝘰𝘱() { 𝘥𝘪𝘨𝘪𝘵𝘢𝘭𝘞𝘳𝘪𝘵𝘦(𝘓𝘌𝘋_𝘉𝘜𝘐𝘓𝘛𝘐𝘕, !𝘥𝘪𝘨𝘪𝘵𝘢𝘭𝘙𝘦𝘢𝘥(𝘓𝘌𝘋_𝘉𝘜𝘐𝘓𝘛𝘐𝘕)); 𝘥𝘦𝘭𝘢𝘺(1000); } Compiles to more bytes (960) than the origin (924). Somethings is happening under the skin :-)

Meh! I thought you were going to present an assembly compiler running inside an arduino.

You mother use Assembler 😂😂😂

Assembler is for old sad gays😂😂😂😂