Thank you foe this excellent overview. It seem like a great first step to understand how to use Studio 7 and how assembly code relates to the processor.
WARNING: Before sending code to a Teensy or Arduino, read my experience. The Teensy is an Arduino look-alike, and has the following properties. It is powered from a USB connection, which can also load code to it. If it is so programmed, it can also send messages to the host PC via USB, so that it can request parameter changes etc. The Teensy uses an ATMega32U4, and has an LED on it and a single button, and 29 legs for power, I/O, etc. When supplied, it has a user program that blinks the LED. It also has a boot loader program that communicates with a little piece of software on the PC called the Loader. When it is plugged into the USB, it runs the user program (winks the LED), and when the button is pressed, it switches to running the boot loader, and the Loader on the PC visibly reacts to it, showing that it is ready to communicate. If a user program causes the Teensy to lose functionality, it can be recovered by pressing and holding the button while it is plugged in, which restores the boot loader. I wrote an assembly level program on it, and asked the two questions you see in my other posts, but as I did not get an answer, I pressed ahead in the fond belief that the Teensy's boot loader would be protected somehow (by fuses), and could not be overwritten. I now believe that was a poor assumption, as my Teensy now appears to be bricked. The program I wrote sends a varying mark-space signal to the LED that goes from (1 period ON, 255 periods OFF) to (255 periods ON, 1 period OFF), then (always ON). It does this over the space of 1.5 seconds, and the eventual application was to be a soft start for an electric motor. I don't know the internals of the Teensy, but most processors I have previously worked with are only capable of one thing when switched on. They execute the instruction at memory location zero. If it is not a jump, they continue with the instructions in sequential addresses. As I said, I don't know how the Teensy works, but I think it must start off by executing a part of the boot loader that tests to see if the button is depressed, and if not, will cause it to jump to the user program. If the button is pressed, it causes a reset that takes operation back to mem-0, but as the button is still pressed, it goes into the boot loader functionality. My belief is that, even though I omitted the assembler directive ".ORG $0", the assembler caused the program to start from memory address 0, and has consequently overwritten the boot loader, which means I can no longer transfer software to it. The symptoms are that when the Teensy is plugged in, it runs my program. The LED comes on at zero brightness and increases to full brightness over a period of 1.5 seconds. If I press the button, it re-starts my program instead of communicating with the host-based loader. If I disconnect it, and hold the button while reconnecting it, my program runs as soon as it is released. Bye bye Teensy. Be warned! ==================Further information =================== The Teensy is developed and supported by the folks at PJRC.com, but since its initial design, it has been cloned, and the Chinese clones sell much cheaper, taking market from PJRC. For whatever reason - possibly in aqn effort to improve their product, or possibly as a reaction to being cloned, PJRC have re-designed the boot loader so that it can't be cloned, and so that it can't be overwritten. They say this has been tested, and works. Unfortunately, the Teensy is an American product, and when the postage from America is taken into account, I can buy 2 1/2 cloned Teensys from China for the price of one from America. Ya pays yer money; ya takes yer choice. If you are already in America, the real deal will work out as a much better deal than it does in Europe.
You explained so much information in such a systematic way. I didn't know so many things although I have already graduated from an equivalent course. I am jealous of the students that got to learn this in person from you. I do not understand one thing yet though. Why is it called "Solution"? Is there some ideology behind that?
Thought this was an excellent introduction to using Studio 7. Only wish I was in Mr. Santos' course. Are any other lectures or lab sessions on CZcams from this course?
It would be nice if Studio-7 had definition files to simulate all processors - otherwise, finding one equivalent to the target processor is a bit hit-and-miss. My target is an ATMega32U4, and I initially chose a 32HVB for the simulator, but the build failed because 32HVB doesn't have a PORTD. I found this by examination of the definition file. You might make some notes about how to choose a simulator chip.
Mr Santos first at all thanks for your brilliants classes (videos tutorials). I'm using ATmega32U4 like my target device (not Simulator on Atmel Studio 7...wish simulator devices do you recommend for this particular devices..Thanks
You don't have to. It allows you to check and verify the operation in software, contents of various registers as the code runs and also keep an eye on how much time it was taking to execute up to a particular instruction line. That could help in precise timing control. When you are dealing with waveforms then this kind of simulation will help see potential bugs caused by timing issues. Also nothing blows up in case you are a DIY hobbyist and connect hardware the wrong way.
This is a complicated piece of software to use, and I'd be totally lost without this video. During setup, under Project properties, should I select something other than "Erase entire chip" if I am using a Teensy board, which has a USB interface and a boot loader? I don't want to erase that - or would it be protected by a fuse? Similarly, do I want the assember directive .ORG $0 Would that cause it to overwrite my boot loader? I don't actually know where that is, but it would sem reasonable to put it, or a jump to it, at $0.
This is one of the best training series I have seen. Well done.
very useful tutorial, the instructor has the right knowledge.
thanks for sharing your knowledge.
Alfredo (Argentina)
Thank you foe this excellent overview. It seem like a great first step to understand how to use Studio 7 and how assembly code relates to the processor.
This is superb, watching in 2020 and quite thankful. You have re-invigorated my asm coding bug.
WARNING: Before sending code to a Teensy or Arduino, read my experience.
The Teensy is an Arduino look-alike, and has the following properties. It is powered from a USB connection, which can also load code to it. If it is so programmed, it can also send messages to the host PC via USB, so that it can request parameter changes etc. The Teensy uses an ATMega32U4, and has an LED on it and a single button, and 29 legs for power, I/O, etc. When supplied, it has a user program that blinks the LED. It also has a boot loader program that communicates with a little piece of software on the PC called the Loader.
When it is plugged into the USB, it runs the user program (winks the LED), and when the button is pressed, it switches to running the boot loader, and the Loader on the PC visibly reacts to it, showing that it is ready to communicate. If a user program causes the Teensy to lose functionality, it can be recovered by pressing and holding the button while it is plugged in, which restores the boot loader.
I wrote an assembly level program on it, and asked the two questions you see in my other posts, but as I did not get an answer, I pressed ahead in the fond belief that the Teensy's boot loader would be protected somehow (by fuses), and could not be overwritten. I now believe that was a poor assumption, as my Teensy now appears to be bricked. The program I wrote sends a varying mark-space signal to the LED that goes from (1 period ON, 255 periods OFF) to (255 periods ON, 1 period OFF), then (always ON). It does this over the space of 1.5 seconds, and the eventual application was to be a soft start for an electric motor.
I don't know the internals of the Teensy, but most processors I have previously worked with are only capable of one thing when switched on. They execute the instruction at memory location zero. If it is not a jump, they continue with the instructions in sequential addresses. As I said, I don't know how the Teensy works, but I think it must start off by executing a part of the boot loader that tests to see if the button is depressed, and if not, will cause it to jump to the user program. If the button is pressed, it causes a reset that takes operation back to mem-0, but as the button is still pressed, it goes into the boot loader functionality.
My belief is that, even though I omitted the assembler directive ".ORG $0", the assembler caused the program to start from memory address 0, and has consequently overwritten the boot loader, which means I can no longer transfer software to it.
The symptoms are that when the Teensy is plugged in, it runs my program. The LED comes on at zero brightness and increases to full brightness over a period of 1.5 seconds. If I press the button, it re-starts my program instead of communicating with the host-based loader. If I disconnect it, and hold the button while reconnecting it, my program runs as soon as it is released. Bye bye Teensy. Be warned!
==================Further information ===================
The Teensy is developed and supported by the folks at PJRC.com, but since its initial design, it has been cloned, and the Chinese clones sell much cheaper, taking market from PJRC. For whatever reason - possibly in aqn effort to improve their product, or possibly as a reaction to being cloned, PJRC have re-designed the boot loader so that it can't be cloned, and so that it can't be overwritten. They say this has been tested, and works. Unfortunately, the Teensy is an American product, and when the postage from America is taken into account, I can buy 2 1/2 cloned Teensys from China for the price of one from America. Ya pays yer money; ya takes yer choice. If you are already in America, the real deal will work out as a much better deal than it does in Europe.
thanks alot for giving me such undrstandable steps for execute this software, once again thank you so much
This video helped me to understand some basics - Greetings from Poland ;)
You explained so much information in such a systematic way. I didn't know so many things although I have already graduated from an equivalent course. I am jealous of the students that got to learn this in person from you.
I do not understand one thing yet though. Why is it called "Solution"? Is there some ideology behind that?
Thought this was an excellent introduction to using Studio 7. Only wish I was in Mr. Santos' course.
Are any other lectures or lab sessions on CZcams from this course?
Excellent tutorial, thank you
It would be nice if Studio-7 had definition files to simulate all processors - otherwise, finding one equivalent to the target processor is a bit hit-and-miss. My target is an ATMega32U4, and I initially chose a 32HVB for the simulator, but the build failed because 32HVB doesn't have a PORTD. I found this by examination of the definition file.
You might make some notes about how to choose a simulator chip.
Mr Santos first at all thanks for your brilliants classes (videos tutorials). I'm using ATmega32U4 like my target device (not Simulator on Atmel Studio 7...wish simulator devices do you recommend for this particular devices..Thanks
Greetings from South Africa. Please come teach at Wits
Do I need to use the simulator if I have the board? I feel like I can skip that step.
You don't have to. It allows you to check and verify the operation in software, contents of various registers as the code runs and also keep an eye on how much time it was taking to execute up to a particular instruction line. That could help in precise timing control. When you are dealing with waveforms then this kind of simulation will help see potential bugs caused by timing issues. Also nothing blows up in case you are a DIY hobbyist and connect hardware the wrong way.
Does this work on Atmel Studio 6.2?
Thankyou.
AYUDARA MUCHO. SALUDOS
This is a complicated piece of software to use, and I'd be totally lost without this video.
During setup, under Project properties, should I select something other than "Erase entire chip" if I am using a Teensy board, which has a USB interface and a boot loader? I don't want to erase that - or would it be protected by a fuse?
Similarly, do I want the assember directive
.ORG $0
Would that cause it to overwrite my boot loader? I don't actually know where that is, but it would sem reasonable to put it, or a jump to it, at $0.
yo please keep your mouth away from the mic