|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Re: C or LabVIEW: CompactRIO
I see learning lower level languages (such as assembly) as the CompE equivalent of taking a Design for Manufacture course.
DFM teaches MechEs how to design things so it is easier for the manufacturing engineers. Learning assembly teaches CompEs how to write things so it is more efficient once it is compiled. DFM is a necessity for any ME who intends to mass produce her work. Learning a low level programming language is a necessity for any CE who intends to mas produce his work. For research and one offs, it is completely superfluous to cost optimize. Cost optimization is a very important skill for a large fraction of engineers, but it is not necessary for 100 percent of engineers, and it is not necessary to start with it. |
|
#2
|
|||
|
|||
|
Re: C or LabVIEW: CompactRIO
Quote:
Algorithms, to choose the simplest code with the simplest access patterns. Architecture, because even at the assembly level, execution performance is hard to predict without considering cache lines, cache sizes, interrupt latencies, etc. Ideally, the architecture course uses an assembly language to illustrate some of the concepts. And of course both of these will get you only so far, so familiarity with profiling techniques, profiling tools, and lots of experimentation are necessary too. The architectures just keep getting more comlex. Greg McKaskle |
|
#3
|
|||
|
|||
|
Re: C or LabVIEW: CompactRIO
Quote:
Note: I am not a programmer by trade, I am a SparkE. However, I really like hardware, so I've spent a little time there. I learned a little x86 assembly, and a little PIC assembly. Relatively low return on investment, though it helped me understand C much better. In CompArch/VLSI, we designed our own processor. Started with architecture, decided on components and interconnects, went to gates, laid out on silicon, and we even wrote our own assembly languages. I think one team even made an assembler in python. I probably won't design too many more processors, but it sure did help me better understand what is going on under the hood. I got a lot out my Foundations of CS class. We learned a new programming language every other week, spanning most schools of thought. Scheme (LISP) taught me a surprising amount about algorithms, and prolog just proved that specific languages solve specific tasks orders and orders of magnitude better than any others can. So... I hit a few lower levels, scraped my knees a bit and moved to the higher level languages. Now I write any code I need in English (in the form of a spec document) or python (which is essentially a dialect of English). Last edited by EricVanWyk : 29-04-2008 at 23:17. Reason: Clarity. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| learning LabVIEW | Lions for First | National Instruments LabVIEW and Data Acquisition | 11 | 21-04-2008 15:26 |
| CompactRIO - new Control System by NI | ND4SPD | Programming | 1 | 17-04-2008 21:46 |
| Labview | tseres | Programming | 2 | 23-05-2007 00:27 |
| LABView Error | TuaMater | LabView and Data Acquisition | 1 | 20-01-2006 02:58 |
| Labview | Phreakuency | LabView and Data Acquisition | 6 | 14-01-2006 01:14 |