Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was talking with some of the mentors in a local robotics competition for 7th and 8th level kids. The robot was using PBASIC and the parallax Basic Stamp. One of the major issues was this was short term project that required building the robot, teaching them to program in PBASIC and having them program the robot. All in only 2 hours or so a week over a couple months. PBASIC is kinda nice in that it has built in features to do everything, but information overload is possible to due this.
My thought are simplicity is key.
When you have kids struggling to grasp:
if X>10 then <DOSOMETHING>
There is not much point in throwing "proper" object oriented programming at them.
What are the essentials needed to foster an interest in programming?
Edit:
I like the notion of interpreted on the PC as learning tool. Due to the target platforms more than likely being somewhat resource constrained, I would like to target languages that are appropriate for embedded work. (Python and even Lua require more resources than the target likely to have. And I actually kinda like Lua.) I suppose that is one of the few virtues BASIC has, it has been ran on systems with less than 4K for over 30 years. C may not be a bad option if there are some "friendly" tools available such as Ch.
The most important is not a lot of boiler plate to make the simplest program run.
If you start of with a bunch of
import Supercalifragilistic from <expialidocious>
public void inherited security model=<apartment>
public : main .....
And tell them they "not to worry they aren't supposed to understand that" - you are going to put off both the brightest and the dumbest.
The nice thing about python is that printing "hello world" is print "hello world"
Fun, quick results. Capture the attention span of the kid.
Interpretive shells like most scripting languages offer (command line) that lets the student just type 1 or 2 liners is a big deal.
python:
>>> 1+1
2
Boom, instant feedback, kid thinks "the computer is talking back". Kids love that. Remember Eliza, anyone?
If they get bogged down in installing an IDE, creating a project, bleh bleh bleh, sometimes the tangents will take you away from the main topic.
BASIC is good too.
Look for some things online like "SIMPLE" : http://www.simplecodeworks.com/website.html
A team of researchers, beginning at Rice, then spreading out to Brown, Chicago, Northeastern, Northwestern, and Utah, have been studying this question for about 15 years. I can't summarize all their discoveries here, but here are some of their most important findings:
Irregular syntax can be a barrier to entry.
The language should be divided into concentric subsets, and you should choose a subset appropriate to the student's level of knowledge. For example, their smallest subset is called the "Beginning Student" language.
The compiler's error messages should be matched to the students' level of knowledge. If you are using subsets, different subsets might give different messages for the same error.
Beginners find it difficult to learn the phase distinction: separate phases for type checking and run time, with different kinds of errors. For this reason, beginners do better with a language where types are checked at run time, i.e., a dynamically typed language.
Beginners find it difficult to reason about mutable variables and mutable objects. If you teach pure functional programming, by contrast, you can leverage students' experience with high-school and middle-school algebra.
Beginning students are more engaged by an interactive programming environment than by the old edit-compile-link-go model.
Beginning students are engaged by splash and by interactivity. It's good if your language's standard library provides built-in support for creating and displaying images. It's better if those images are supported within the interactive programming environment, instead of requiring a separate player or viewer. And it's even better if your standard library can support moving images, or some other kind of animation.
Interestingly, they have got very good results with just 2D images. Even though we are all surrounded by examples of 3D computer graphics, students seem to get very engaged working with just two-dimensional images.
These results have been obtained primarily with college students, and they have been replicated at over 20 universities. However, the research team has also done some work with high-school and middle-school students. The first papers on that work are just coming out, so I'm less aware of the new findings and am not able to summarize them.
When you have kids struggling to grasp:
if X>10 then <DOSOMETHING>
Maybe it's a sign they shouldn't be doing programming?
What are the essentials needed to foster an interest in programming?
To see success with no or little effort. To create something running in a matter of minutes. A lot of programming languages can offer it, including the scary C++.
In order to avoid complication with #includes, multiple source files, modularization and compilation, why not have a look elsewhere? Try to write some Excel macros or use any other software with some basic built-in scripting language to automate certain tasks?
Another idea could be to play with web pages. It is not exactly programming, but at least easy to achieve something and show to others with pride.
This has been said on SO before, but... try Scratch. It's an incredible learning tool for kids. It teaches the basics of programming concepts in a hands-on and language-independent way. After a bit of playing around with it they can get down to learning a specific language's implementation of the concepts they already understand.
The common theme in languages that are easy for beginners - especially children to pick up is that there's very little barrier to entry, and immediate feedback. If "hello world" doesn't look a lot like print "Hello, world!", it's going to be harder for people to pick up. The following features along those lines come to mind:
Interpreted, or incrementally JIT compiled (which looks like an interpreter to the user)
No boilerplate
No attempt to enforce a specific programming style (e.g. Java requiring that everything be in a class definition, or Haskell enforcing purely functional design)
Dynamic typing
Implicit coercion (maybe)
A REPL
Breaking the problem (read program) down into a small set of sections (modules) that do one thing and do it very well.
You have to get them to stop thinking like a user and start thinking like a programmer. They need to take it one step at a time. Ask them what they have to think of in order to figure out the problem them selves and then write them down as steps. If you can then you break each step even more in the same mater. When done you will have the program in english making it simpler to program for real.
I did this with a friend that just could not get it and now he can. He used to look at something that I did and be bewildered and I would say that he has done more complex stuff than this.
One of the more persistently-present arguments I have had with other programmers is whether or not one's first language should require explicit type languages. Many are of the opinion that learning a language which requires you to explicitly declare type information is one which will teach you to program typefully. Conversely, it can be said that dynamic languages might present a less demanding learning curve. It goes either way, I suppose.
My advice: start with a simple model of how a computer works. I am particular to stack machines as good tools for teaching computation.
Remember that beginners are learning two disciplines at the same time: how computers work and the abstract logic involved (the basics of Computer Science), plus how to write programs that match their intended logic (learning a specific language's syntax and idioms). You have to address both concerns in an interwoven fashion in order for the students to quickly become effective. This is also the reason experienced programmers can often pick up new languages quickly.
It's worth noting Python grew out of a project for a language named ABC, which was targeted at beginners. For example, the required colon isn't strictly required, but was found to improve readability:
if some_condition:
do_this()
I got 3 words : Karel the Robot.
it's a really really simple 'language' that is designed to teach people the basis of programming :
Look for it on the web. You can look at this, though I never tried it :
http://karel.sourceforge.net/
While this isn't related to programming a robot, I think web programming is a great place to start with kids that age. It's how I started at that exact age. It easily translates to something kids understand if they use the web at all. Start with HTML, throw in Javascript, and soon they want to be doing features requiring server-side scripting or some sort, and things progress from there.
With the kind of kids who are already interested in robotics, though, I'd actually go for a different language like the ones already described. If you want to work in a field like robotics, you don't need to be convinced to try something hard. You need to be challenged.
A few years ago I saw a presentation at Ignite! Seattle from one of the people working on the project now known as Kodu who envisioned as a programming language for children. He spent time talking about what common language features could simply be thrown out in a programming environment meant to teach fundamentals.
A lot of cherished imperative constructs, like C-style for loops, were simply left out in favor of a simple object-messaging approach. Object-oriented programming isn't hard to understand when you think about "objects" and "messages"; the hard part is when you deal with things that programmers, but not children, care about, like inheritance and contracts and sweeping abstractions. I've got this thing (noun), now act on it (verb), in this way (adverb like quickly), when thing (sees/bumps into) something (with some attribute) (that's your if). Events are really conditions, and have all of the power of conditions, but it's up to the runtime to identify when those events happen.
This kind of event and messaging driven approach probably translates even better to robots than procedural programming would, anyway, so it might be a good way to look at the problem. Try not to think about what you'd "need" to know to program in C or Pascal or something; think about what you'd want to be able to make something do.
I am taking a Digital Circuits class in which we do not use a book, only lecture notes. In the section that covers adders I only have 2 small examples covering addition and subtraction of binary numbers. I am pretty sure i am going to have worded problems in the exam such as design a circuit to count something etc. Does anyone know any sites that have example questions and solution for me to go over?
I don't know of any particular sites, but I do know that when I took a similar class, the lecturer was awful and I relied entirely on the textbook. It was Digital Design, by M Morris Mano. I highly recommend it - it's got plenty of problems to go over and has all the information you need in case you get stuck on something.
Wikipedia is a useful resource. The best way to learn electronics is to build your own circuits, preferably with real hardware or using a simulator if the former is not practicable.
P.S. You do not need adders to count events. A cascade of bi-stable flip-flops will do this.
What are the most valuable parts of Computer Science studies for Cocoa developers?
Another way I might word this question is:
If I’m not going to go to school for Computer Science but want to be a developer working primarily with Cocoa, what are the things I should make sure I learn that I otherwise might miss by being self-taught, and be worse off for it.
Update: Replaced the term "professional Cocoa developer" with "developer primarily working with Cocoa", in hopes that the intent of my question is somehow clearer.
To be clear, I've been working with Cocoa for two years and am comfortable with Objective-C and the Cocoa frameworks, as well as Cocoa design patterns and the developer toolset, and thus am for the most part fluent with the Mac and iPhone platforms. But I have wondered whether I'm missing important CS or SE elements due to being self taught/no formal training, and not coming from other languages or platforms.
This question is for Cocoa developers.
There are many, but things that come to mind imediatly
-Design Patterns (the Cocoa framework relies on many Design Patterns, if you follow them it will make your life very easy, most obvious example is MVC)
-Algorithms and Data structures(this applies to any framework really)
-Memory Management (No garbage collection on the iphone!)
I would question whether there's really such a thing as a "professional Cocoa developer" (from a philosophical standpoint), or if you would want to be one. There's "professional developer", who may work with Cocoa primarily. A professional developer is language-agnostic and as such has a solid career ahead of him/her. A language- or platform-specific hacker has very limited usefulness.
The question to ask is do you want to be a developer or not? If there aren't any good Cocoa jobs available at the moment, or Cocoa is replaced by something newer and better and very different, a professional developer changes gears and follows. Are you OK with that?
If so, a computer science degree definitely cannot hurt. If not, you should probably not put all your eggs in the Cocoa basket and pursue a non-CS degree.
In addition to what's been pointed out already, I highly recommend reading "The Pragmatic Programmer". It contains a wealth of information on how to write software, how to manage projects, and how to develop your career, advice that goes well beyond the documentation you look at every day in Xcode. Some of the topics they cover are ones that you might have been exposed to during a standard computer science degree.
"Professional" is a relative term.. but anyways, this is what i had to go through so that i could easily learn a new language anytime i want and also master it:
started by learning a simple console language (pascal or c++, but i consider pascal being simpler than c/c++), then learned another language just to see if i can do it (c++)
i learned a lot of algorithms and data structures, until i was able to recreate them and even create my own
i moved to a visual approach on programming with Visual Basic 6 (another simple one to start with), and tried to copy lots of apps just to see if i can do it
i learned about Object-Oriented Programming and finished by mastering it
from this step on, learning a new language was like a hobby, like playing!
then i wanted to learn some different topics, like design patterns, multithreading, and so on..
moved from windows to mac, and started learning objective-c: because i already knew lots of languages, it took me 5 days to learn objective-c, and yes, i took breaks like any human being :P
after i learned obj-c, i now had to learn cocoa... this one took me a lot of time to learn, and i still don't know it all.. but i do know most of it :D
What are the most valuable parts of Computer Science studies for Cocoa developers?
Learn that it's important to understand the differences between languages, not learning a particular language.
Are you writing numerical method solvers with a Cocoa frontend? You'll want to take numerical methods. Writing a 3-D plugin with a Cocoa UI? Better learn about Catmull-Rom splines.
A good understanding of computer graphics is required if you want to make some good looking animations :)
This is not 100% programming related. But I think this is somewhat useful because it is addressing a minority in the SO community.
Microcontroller programming is one of the interesting areas in programming. I saw some topic here requesting the Resources for starting / learning / discussing about PICs.
Example topic
Since I have plenty of knowledge and experiences in this area I am thinking of publishing some resources that helps a novice to learn them from the basics. It will be not just a theoretical publication and will be based on example projects. I hope to start this over a new blog + forum so the users can dynamically interact with each other. I came in to this decision because I found very small amount of Sites that a novice can start learning and work collaboratively.
What do you guys think about this? Have you ever experienced such difficulty? Do you think you can get some use of that? What are the things you like to see on the site?
I would be thankful If you are not going to close this as NPR. I just want to do some service to other microcontroller lovers :)
There are already a few such tutorials on the net (e.g. this one from SparkFun), another one might be a valuable addition, but only if it is better or different in some way.
What will you offer that is a real improvement?
Some suggestions:
Don't assume I have windows
Have some side discussion of difference between various MCU and/or supporting electronics. Discuss some of the trade offs
You'll need a pretty general tutorial to suck people in, but the real value added might be in a specialized focus after the start
Build up to something useful and/or geeky cool
A unit on component integration (i.e. I can buy a Polar style heart rate receiver, and a MCU and a USB interface. How do I get them talking to each other so I can build an exercise data logger?)
What every you do, I'm looking forward to it (just learning embedded stuff in my spare time...).
There are the excellent tutorials at www.mikrocontroller.net, but they are in German.
If you could create something similar for an English speaking community, that would be great.
Yes! The more resources out there for helping with embedded software (microcontroller programming) the better.
It can be quite daunting to start with, especially if you've only written software for PCs or similar in the past. There are lot more constraints (e.g. on RAM and code space), and a whole load of things you need to know that don't apply to non-embedded software.
As others have mentioned here, there a number of websites that cover different aspects of this; some others are OnARM, for ARM processors, the related STM32 Circle, and Jack Ganssle's articles on his website and on Embedded.com.
Though embedded systems are an enormous market (just think how many such devices there are in your house, or in your car), my impression is that there is a lot less coverage of the subject on the web - and on Stack Overflow - than for non-embedded.
So, I look forward to seeing the fruits of your labour!
Something else that's worth to take into account when targeting beginners, is to directly provide pointers to useful resources, such as suitable simulators/emulators, or even addresses/webpages where you can easily order a starter kit or even free samples of some chips.
For example, most semiconductor manufacturers provide free samples of their products, e.g. see microchip.com or atmel.com.
Ideally, an introductory course would be based on working with such a hardware simulator or emulator in the beginning, so that the project and all relevant experience may directly map onto a real device once the beginner is interested in moving his work onto a real chip, providing pointers to freely available resources, or very affordable starter kits can be very useful.
This would ensure that beginners can get started as easily and cheaply as possible.
Maybe for the different ARM7 and CortexM3...?
Here everyone asumes there is a lot of information, but it is spread all over the net and without any red line what so ever...
But if you take AVR there is quite a lot of stuff over at http://www.avrfreaks.net, and I guess that PIC has quite a lot as well.
I have written many such examples myself but they are scattered and not organised and probably rarely read (one time the folks at avrfreaks borrowed something). StackOverflow might curb this but SO could in theory be used. Ask a question about boot code for an arm whatsit, then answer your own question with example code and text on how and why it works. The SO tags would be nice in that you could do a search on "boot" "arm" "embedded" and then one on "boot" "avr" "embedded", etc and get similar example programs for different platforms.
Personally I would go more in the direction of creating an example archive of complete programs for specific microcontroller versions (in typical uses), instead of making yet another "general" tutorial. E.g. one of microcontroller x/y that enables a serial port, one that configures a few digital outputs (setting TRIS and friends), how to set up common frequency/oscillator options etc.
When I started with PIC, (very short PIC16, then PIC18 then 24F and now dspic), one of the main problems is that all the examples are either only fragments or describing very general principles.
A tutorial is no good, if it takes more skills to get the examples actually working than the tutorial teaches.
I usually couldn't find one single complete program for exactly my controller, or even for the slightly wider group (that only vary in number of pins and memory/flash).
The initial program was always the problem, but sometimes later I had the same problem (initializing a certain peripheral) all over again (e.g. the encoder) It is specially frustrating if is the first run of a new micro controller line, and you might not be 100% sure of your hardware.
Unfortunately that takes some coordination, from a forum, an user group or so, since nobody has all devices, and all variants to wire them up (e.g. different oscillator options).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Can anyone recommend a good book for learning VHDL? Or failing that, any good resource?
The unfortunate problem with VHDL is that there are loads of outdated, poorly styled and outright wrong resources out there; both electronic and in print.
Part of the art of mastering VHDL is knowing how to filter these out. The following is the filtering I did in my previous life as a hardware designer. I hope it is helpful to you.
These are the things you want to read, or own, or download:
Book: "The Designer's Guide to VHDL" by Peter J. Ashenden (ISBN 1-55860-270-4). It does not waste your time by telling you to use obsolete or vendor specific libraries; it does not explain VHDL assuming you are a software engineer who wants to know about HDLs; it does not explain VHDL by assuming you are a hardware engineer who wants to know about HDLs. It does not advocate a vendor and its solutions (working with a particular vendor toolchain is a separate issue, and I've found it helpful to keep learning VHDL and vendor-specific separate). What it does do is introduce VHDL from the right perspective: as a language used to describe discrete event systems, from which smart programs can extract something that can end up as being hardware. It also describes what the standard language constructs are, which standards of the language exist, and what are their specific properties. Modern tools are ever more adherent to the standards, so this info is way more useful than a bunch of analogies that some other books (to remain nameless) seem to purport. Buy it, it's worth every cent.
The newsgroup comp.lang.vhdl is inhabited by people who are very knowledgeable about modern VHDL and can give you sane advice if you can ask questions well. To be able to do the latter, read the book mentioned above. Wading through numerous VHDL forums is in general a waste of time, as the information content there is generally drowned in noise.
Know your tools. Get yourself a PDF of the toolchain you will be using and know it very well. The more, the better. Especially know their limitations. Tools often have idiosyncrasies that you will need to work around or play along with to get things just right. For instance, you will probably want to write the portable behavioral code; except for the parts that are either technology-specific, or are such that your tool happens to synthesize them wrong.
Know where to find sane VHDL resources. An example of a sane resource is the Hamburg VHDL archive (at: http://tams-www.informatik.uni-hamburg.de/research/vlsi/vhdl/) I found through using the sampling method that the signal-to-noise ratio on that particular website is pretty high. Use it.
A fairly obscure book about hardware synthesis (for the really curious; and written from an academic perspective) is Giovanni de Micheli's "Synthesis and Optimization of Digital Circuits" (http://si2.epfl.ch/~demichel/publications/mcgraw/index.html) which may shed some light on the hardware synthesis methods -- though a substantial body of work has been done to improve the results given there since. You may want to borrow this one from a nearby library and leaf through it.
I like the book called "Circuit Design with VHDL", from Volnei A. Pedroni. It focuses on synthesizable VHDL, that is what you will need to code for real chips, not only for simulation.
A great textbook to start out with is: Fundamentals of Digital Logic with VHDL Design
I remember starting out with this to get a quick overview.
I found the Low Carb VHDL Tutorial to be excellent when I was learning VHDL. Now even more since the author of Low-Carb VHDL Tutorial has turned it into an open-source book titled Free Range VHDL.
I recommend the Chu, Pong P.: RTL Hardware design using VHDL. John Wiley & Sons Inc., 2006.
When learning any sort of HDL (Verilog, VHDL...) it is important to keep one thing in mind. It is not software programming and things work in parallel. That being said, I find that the best way to learn any HDL is to learn how to think in hardware and describe the hardware (that's why it is called a hardware description language).
So far, I have rarely seen books that show you how your HDL gets translated into hardware. I've read through one when I was at Synopsys (pages filled with code and schematics) but it was an internal publication. However, even lacking this book, you can still see how your code gets turned into hardware by running it through synthesis on free-software.
The reason that I wish to stress this is because there are many ways to solve a problem. You will only be able to write code that solves it efficiently, from a gate count and timing stand point, if you understand how it gets translated into underlying hardware.
Good luck!
This is the book I used for Systems Architecture class. It is dirt simple.
Be carefull though things are not always parallel. Sequential assignments are different than combinational assignments.
I'm not sure what your background or needs are, but Digital Design and Computer Architecture, by David Harris and Sarah Harris, was a very useful introduction for me. It's not VHDL specific (Verilog and VHDL examples are presented side by side) or even HDL-heavy – as the title would suggest, it's more of an introduction to digital design in general. But for me it has been a great approach, presenting the code along with a grounding in its application and theoretical context.