Re: Assembly Language FRC Robots????
 

I whole heartedly agree with all the other engineers in this thread, assembly languages are great and it is important for Software Engineers/Systems Engineers to understand them to really understand why your code does what it does. RPI's Computer Science and Computer Engineering curriculums both require a course that introduces programming at that level. The point of this class is not to learn an Assembly Language but rather to learn how the processor executes your code and learn that you should be grateful you don’t need to write code at that level very often.

I have some experience writing low level code for extremely low cost/power microprocessors however there is no reason to write in assembly for something as powerful as the cRIO. If you want to learn assembly as an academic exercise then I can see the benefits, however learning it and using it instead of C++/Java/LabView for FRC applications makes absolutely no sense. There may be something that you would want to write in assembly for the cRIO but I have not in my time in FIRST seen any reason to even inline assembly never mind writing robot code from scratch entirely in assembly.

One of the aspects of engineering that is often overlooked by students on CD is the importance of identifying your tool-set and using the correct tools. Assembly Programming is often a tool that is better left in the toolbox. You can always fashion a tool from stone and slowly scrape aluminum away to lighten your robot but I guarantee your team will be more grateful if you just throw it on the mill.

Re: Assembly Language FRC Robots????
 

::rtm::
You can use assembly to control hardware at a deeper level than C++ or Java. A great example, that is not related to FIRST but still considered very educationally challanging to try as a hobby or future profit, is to manually hard-code hardware accelerated software for the GPU/PPU (if one wish to make their own new 3D rendering software similar to OpenGL, DirectX, etc). Homebrew games (ie: Nintendo Wii/DS/3DS/GameBoy/GameCube/64/SNES/NES/etc.) are commonly made with an assembly syntax, whenever a high level language compiler is not available. Preatty much if you want the most of your hardware, assembly can let you make you own algorithms that is too trickly to program under C++/Java's syntax.

:yikes: ::safety:: ::ouch::
(Do not hack the cRIO, FIRST will frown apon it) :(

And as I've ment by "Similar difficulty", I ment learning assembly is similar to learning C++ or Java (but mostly C++). The main difference in assembly to C++ is you need to write out every individual steps from each line of C++ code, in the correct logial/mathematical order, and line up the jump conditions correctly.

(Should I mention self-modifing code.....)

Re: Assembly Language FRC Robots????
 

You have to realize how much abstraction the C++ library provides. Which is a good thing IMHO in this context. Not once, had I ever found a use for simple bit manipulation such as AND, OR, XOR, NOT... I only used them for conditional operations. I really never even used them to mask binary data or anything like that. I never had to shift any bits. The only practical usage of assembly in the context of FIRST is probably only mathematical functions. Which is more than enough to do bit manipulation on the C++ level. You still can use &, ~, |, ^, <<, >>... Which is And, Not, Or, Exclusive Or, Shift Left, Shift Right respectively. Now, can you tell me how in the world you will incorporate those operations into your project? Sure, I can find uses for bit shifting, probably not the other operations. I can force myself to use them, but where is it practical to mask bits or anything of those sorts.


Do you really have more control? I really doubt you, even I, can handle even making a motor move using Assembly. There might be system calls or something to directly write data to the speed controller, but even that probably takes up lots of time debugging and ect.


I know, I know, I just barely scratched the surface on Assembly, but you get the point.

Re: Assembly Language FRC Robots????
 

I think that there is agreement and understanding in this thread that Assembly programming has its uses, and it is in some cases necessary to use Assembly languages when you are pushing the limitations of your hardware. However what is important to note is that the topic of the tread you created is Assembly Language for FRC. C++, JAVA and Labview are all efficient enough for the application.

I don't know if the wording is just strange but your last sentence doesn't make sense to me. If something is to tricky to write in C++/JAVA how would it be easier to write it in Assembly?

You seem to make a statement here than contradict it immediately you say the difficulty is similar, and then you describe the difference as being much more complicated. It is a lot easier to write in a High level language than it is to write in a low level one.

Based on this post I assume the majority of your programming experience is from programming PCs and FRC programming. If you ever write code for a control system that doesn't have an established framework like WPILib you will quickly find out where Bit masking and bit-wise logic is useful. Any time you need to access a register you will use these tools. If you look at the code WPI provides I am sure you will find plenty of places where this was used.


I am sure you are a bright kid and a talented programmer but comments like this make you look arrogant. You are clearly implying that you believe you are more capable than he is and that if something would be a stretch for you then it would surely be impossible for others. Perhaps you believe this; perhaps it is just a case of your intent not coming through the text. Either way think before you make comments like that.

Re: Assembly Language FRC Robots????
 

First of all, I did not mean to offend anyone. Now, it is true, majority (actually all) of my work with assembly literally has been on a computer on protected virtual mode. I have seen codes for embedded control systems. I totally agree with you, those tools a essential for any assembly work.

I tend to sound arrogant, it is a personality flaw I have. I try to sound as nice as I can. The "even" should have been an "or", quiet possibly "and"

Re: Assembly Language FRC Robots????
 

This is a fine answer, but mostly to different questions. I asked about tasks that require assembly, not HW that requires it because you don't have a compiler that targets it. And it is a hard question, because IMO, if a HW vendor does a good job, they write the several pages of assembly functions for you and expose them with ANSI C entry points. Then none of their users ever need to use the inline assembly in order to make the HW do special things. The user just calls a function that makes the HW do the special things. They can call it from pretty much any language made since we went to the moon. Even better, when the vendor finds a bug or revs the HW, they can update the function to keep the user code working.

Similarly, if a HW vendor wants you to use their HW, they should IMO provide a backend to gcc or another compiler, along with mechanisms for getting code onto their HW, header files, etc.

Generally, C was designed for making OSes easier to write and more portable. It, and a few languages like it, were expressly given features so that they could write interrupt routines, treat code as data, and use assembly to call special CPU instructions unique to that HW. It was designed largely so that people would no longer have to write the OS in assembly. If this were a bad idea, C, UNIX, linux, and other OSes written in C would have died out and OSes written in assembly would be dominant.

-------------------------------------

Looking at the specific points ...
Deeper level:
There is truth to this. The PPC in the cRIO has a special register called the MSR -- the machine state register. This controls low-level features including the power management state of the CPU. By writing different values to this, you can put the CPU into -- awake, doze, nap, and sleep modes. To modify this and other special registers, you have to use a supervisor-level special machine instruction called mtspr (move to special purpose register). How do I know this? I looked it up at the following URLs.

http://rocky.digikey.com/WebLib/Moto...ata/MPC603.pdf
http://publib.boulder.ibm.com/infoce...gref/mtspr.htm

Does this mean that you cannot change the power mode? No. You do it by calling VxWorks routines such as cpuPwrCStateSet( ) or one of the dozen related functions. Note that I'm not even sure if this works on the PPC, but this is what I was able to find in the VxWorks docs. On a different OS, you'd make a different call. If you work for Intel or FreeScale, if you work on one of those projects that decides you want your own proprietary OS, you will need to write this function, and you will do so by using assembly. Otherwise, the OS will actually prevent, or try to prevent you from doing this. Do it wrong, and you will probably corrupt the machine state and crash within a few microseconds. And I don't mean crash as in throw an exception or with a nice dialog. I mean crash as in seized up -- no CPU instructions are being executed anywhere sort of crash.

Compiler not available:
When a bridge isn't available, people take a ferry. When that isn't available, a few people swim, but most go somewhere else. Once they build a bridge, that is what people use. My point is ... look around for a compiler, or build one. They sometimes name bridges after the engineer who builds it -- other times after the congressman who funds it.

Tricky Algorithms:
Examples please. If you wish to make your algorithm brittle and non-portable, even to new versions of the same CPU, use assembly. This is not common.

I think you just did. This is actually very HW dependent and is generally prohibited by the OS. Harvard architectures and derived architectures load code into different memory caches. They do this for efficiency gains for "normal" code. At this point, self-modifying code is either illegal, or needs cache flushes and is now quite inefficient. Similarly, most OSes mark VM pages as write protected. Your code will throw an exception in doing this. The compiler in LV takes your diagram and generates machine instructions directly as data. It then requests the OS to declare it as code so that it can be executed. JITters do the same thing. Sure, there are architectures and OSes where this is still possible, but from what I see happening, they are again, incredibly rare.

Conclusion:
By the way, I gave the references above so that you can read or skim it to appreciate the complexity of the CPU in the cRIO. It is a pretty old RISC architecture -- pretty simple and clean by most standards. And still, it is soooo tedious to try and keep straight what values you have in different registers, dealing with running out of registers, dealing with how the ABI defines parameter passing and other conventions. I do not want to discourage you from learning about hard things or even doing hard things such as this. But I want you to be aware of what you are trying to do.

If you attempt to program any significant portion of your FRC code in assembly, you will be making your task ~20 times harder than other approaches. You will most likely have a less impressive robot, disappoint your teammates, and the next batch of programmers will probably say interesting things about your code and your ancestry. By all means, learn about CPU architecture and underpinnings, but don't expect it to have much immediate impact on your robot. Learn assembly if you like, but do it in a supportive and safe environment.

If you have other assembly questions or debates, I'll be happy to take part.

Greg McKaskle

Re: Assembly Language FRC Robots????
 

There are other tricky high level syntax that might give you data that you could of munipulated better in assembly, ie. the BASIC syntax.

And...
Since it would be a waste of time remaking the entire WPILib in assembly, of which it was already set up for FRC, You could recompile the code in Windriver, and debug the code at the low level to see and learn what the C++ code is really doing. Then you will have to make some sort of documentation of the assembly code of what you should be doing to control the robot.
(Without doing harm to the cRIO.):(

:D :confused: :D
How ironic that a simple inside joke could be added to an intelligent responce. Self-modifiying code is not always illegal, or inefficient. It's just another powerful programming force that can either create or destroy many, many miracles.....
::rtm::
http://en.wikipedia.org/wiki/Self-modifying_code

Re: Assembly Language FRC Robots????
 

This thread is missing the biggest factor in making a decision to use assembly. We are tasked with coding and testing all the robot application firmware from scratch each year and we have only 6 weeks to get it done! Using assembly is fun to talk about but a crazy idea! And some other points...

- I have been doing this kind of stuff for almost 30 years. Anything and everthing done in assembly can be done in C (and C++ since it is simply a superset of C). The only tricky things are some instructions that are only available in assembly (like synchronizing the pipeline, invalidating caches etc) and there are pre-processor macros for these types of things. Note that this is not true of Java or most other 4GLs.

- Self-modifying code is from the devil ;o). Nobody in their right mind does this anymore. Every company I have ever worked for prohibits this practice. And on the cRio, under VxWorks, it is quite difficult to do since the text segments (where executable code is stored) are typically marked read-only.

- Most software spends huge amounts of time in just a few small areas of the code. Optimizing these regions in assembly so they are faster or might fit entirely into cache can yield huge improvements in throughput. For example, on the robot, putting the PID calculation thread in assembly might be kewl. But NOT in 6 weeks!

- It used to be that one could express algorithms in assembly better than a compiler. But in the last couple decades ANSI C added features (like the 'register', 'inline' and 'volatile' keywords) and compilers have improved to the point that it is very difficult to do a better job than the C compiler - and by extension better than LabView.

- Assembly is used today and is irreplacable for some things like booting the processor, binding interrupt service routines and executing some privileged instructions. But these things are done for us in the OS. Using assembly for application programming on the FRC robot is fun to talk about, but a really bad idea.

HTH

Re: Assembly Language FRC Robots????
 

WOOOOOPS!!! :yikes:
I've accedently trolled my own thread!!!!
Thank you all for mentioning that self-modifing code is a big no-no (along with me trying to convince myself somewhat right from "psuedo-true" wikipedia facts for the self-modifing code, but failed after hours of me researching the real dirty truth of the self-modifing code, via: learning how computer viruses work).

:mad:
Sorry for any cRIO hackers who would like to pray on poor defence-less robots. Your answer(s) are not here......

:confused:


On a serious note:

Very true!!!! My original thought was to use assembly language as a alternative programming language, not to make 99.99999999% of the FRC programming population to come down with an epidemic of coma-like headaches, but just to give FIRST an exposure of learning a low-level language. I believe low-level programming is just as vocationally benifical as high-level programming when it comes to programming robots. :D

(WITHOUT SELF-MODIFING CODE!!!!!) :(

So can we please stop with the SELF-MODIFING CODE.
From this point on, only post any opinions for anyone who is fully Pro/Con for the assembly language. Considering we all made enough facts on this thread for everyone to think about.

Re: Assembly Language FRC Robots????
 

am going to assume you did not mean to shout at me or the CD community - plz take things down a notch

HTH

Re: Assembly Language FRC Robots????
 

Sorry, I'm one of those programmers who likes the SELF-MODIFIYING CODE.:yikes:
(And no, I'm not a hacker):o

But seriouly, anyone else, who has any other expert advice of how assembly language can be used in FIRST, please join in......

Re: Assembly Language FRC Robots????
 

I'm not exactly an "expert", but having studied a bit of assembly code in college, my advice on how to use it in FIRST is: Don't!

Re: Assembly Language FRC Robots????
 

I would have to call Greg, and raise him another 5 or 10 times. (make that 50-100 times harder).

Lets clarify this... we're not talking about a few lines of optimized assembly code here, we're talking about a full blown, real time processing system with I/O, networking, disk operating systems, image processing, yada, yada, yada.

No point in just doing the main calling code in assembly. If you want ultimate control and performace then you need to recode EVERYTHING in assembly. Needless to say.. No-One is going to do it. Ever... period...

That being says, I think a basic knowledge of assembly code is a great skill for an embedded programmer to know... just like boolean logic gates and flip-flops.

Anyone who wants to get a taste of this world should get themselves a little 8 pin PIC processor and a PICKIT2 programmer and go for it. But be ready to start thinking in register memory maps, bit test operations and interrupt service routines, because it all gets a LOT more down and dirty.

Phil.

Re: Assembly Language FRC Robots????
 

Us programmers are already worked too hard. :rolleyes:

Re: Assembly Language FRC Robots????
 

I'm assuming this is true for every team.
ie: Mushroom cloud motor burnout...