|
No, you are saying in your original post that the quality of questions has gone down because people aren't reporting them any more: and yet you clearly are still reporting them, and so is You Know Who. And as a result, they are still getting closed - which negates the point of your original comment!
That was a question - at least for the poster - and deserved a reply if only to explain that he shouldn't be using us as a search resource. It's entirely possible that he has tried to Google but doesn't understand what he found and needs help to work it out. Just arbitrarily going "that isn't a question" doesn't help anyone because it closes off all avenues for conversation about why he doesn't understand!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I don't know why people feel such messages (my original post) Spam/Abusive.
"When you don't know what you're doing it's best to do it quickly"- SoMad
|
|
|
|
|
No idea - certainly I didn't tag it as such.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Well, I'm a people (theoretically), and I don't feel your post here was spam, or abusive !
cheers, Bill
«At the still point of the turning world. Neither flesh nor fleshless;
Neither from nor towards; at the still point, there the dance is
...
Neither ascent nor decline. Except for the point, the still point,
There would be no dance, and there is only the dance»
T.S. Elliot, The Four Quartets: "Burnt Norton"/xml>
|
|
|
|
|
I couldn't have put it better myself.
PooperPig - Coming Soon
|
|
|
|
|
My personal approach is
If the OP hasn't made much of an effort and I like the topic / learning the topic I will then point them towards the relevant documentation.
If the OP has made an effort I will also point them towards the documentation and provide an answer with the potential of a code example.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
I'm very much with OG on this; I tend to be more relaxed and forgiving than some.
I guess that it boils down to what, as a community, we want QA to be.
There are some who feel that SO is the model to aim for. I don't agree; as long as SO is there, we don't need another - it's quite simply very good at what SO does.
CP, IMO, has always been a more liberal and newb friendly place than SO. It's great strengths are: Articles, Tips, News Aggregation and a great place to hang and have a laugh.
I see QA as more of a throw-away not a resource; "Quick" rather supports this. If a silly question gets posted on there, we can choose to ignore them or maybe add a generic comment. They soon scroll down the list if it is really that bad. I guess there is a line, but the only questions I've ever voted to remove have bee spam. I would always prefer to point the poster towards a better path.
Maybe there is an opportunity to split QA into two? One forum for beginners and one for difficult and detailed questions. I know there would be some confusion about which to post to, but moderation would help sort that out (maybe a move to beginners QA option?) Possibly the Beginners QA doesn't get archived and accepted solutions get dropped after a time, say a week, only visible to the original poster? Those of us that may have a little more time and/or patience/tolerance for newbs (and questions that you'd think anyone in the field shouldn't be asking) can then help the little ones.
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
Here's the link to the complete sequence
clickety[^]
enjoy...
|
|
|
|
|
Very ; thanks!
Software Zen: delete this;
|
|
|
|
|
The link doesn't seem to work.
"Note: This event is over."
|
|
|
|
|
use the arrow keys. The first 5 pictures or so are white...
|
|
|
|
|
I get no image; just a box with a red X. Maybe it's my browser. He's not using Flash, is he?
|
|
|
|
|
don´t know, I don´t think so...
|
|
|
|
|
It worked on my phone -- but no arrow keys.
|
|
|
|
|
Hello!
Could you recommend me a proper book on embedded systems? There are so many of them and everyone is "the best". I wish to gain skill required to apply to a job for an "Embedded C Developer". I've been coding in (very)high-level languages like C#, but I know basics of C too. I was writing simple verilog and asm stuff for FPGA and controllers back in a university but it was long time ago.
I suppose that the book should cover such topic as:
- detailed introduction to embedded programming, how devices work etc.
- how to use development tools/IDEs in a Linux environment
- C embedded
- assembler languages for various devices/instruction sets.
A price is an important factor, too.
Greetings,
Jacek
|
|
|
|
|
"The book". BEEEEP. Wrong question
I very much doubt that you'll find a book that has "languages for various devices/instruction sets." in it - well, current, modern ones anyway.
The programming guide on the ARM cortex M3 is a rather thick book already - and that's only generic onformation, not talking about the custom peripherals of any of the different hardware implementers at all.
One book, or even many books by themselves won't turn you into an "embedded C developer".
What do you mean by "C embedded"? I'm doing some embedded work only for a few years now, but I think some sort of restricted C for embedded stuff is a thing of the past.
Even most commercial embedded IDEs at least for the ARM world use GCC, well and then there's the ARM compiler that comes with Keil, also standard C.
If you mean "c programminc concepts best suitezd in embedded world", hrm, maybe look at the book called "design patterns for embedded systems in C", although reviewers found some flaws with the way the book is made / usability, albeit good content wise.
There are quite some very different architectures on the market. I doubt a book can cover them all well enough for you to become proficient. You need to do stuff and gain experience. Sounds obvious, yeah. But maybe pick one popular architecture, and try to understand that one and actually do projects with it, fail and learn why, learn by doing.
There may be a book teahcing general concepts - but then again, take just the GPIO (general purpose input / output) - what they are and can do also differs between architectures.
Yeah, I'd definitley suggest that you find some clever way of findong out what are well in-demand "hot" platforms / architectures right now and then pick one that may be the most beginner friendly one from freely available resources - you'd have to ask for that specifically then.
I know that e.g. AVR is supposed to be simple, and they even offer a free to use VisualStudio based IDE I think.
For some, AVR is too simple / not capable enough. (the small AVR, not the AVR32 anyway)
I like the STMicro electronics based ARM cortex chips since they have some nice ranges which cover my project needs better than other ARM implementors I checked out so far, or other platforms.
But some people think this is harder to get into micro controllers than other MCU types. They are option-packed & lots of stuff needs to be set up.
Ok my overall view of MCU platforms is limited, let's see what other people have to say.
Maybe you should look for a dedicated embedded forum, though. Or even a (digital) electronics forum, where people also do embedded.
Disclaimer:
If my grammar etc was more whacky than usual it may be due to nightshift + some hours overtime (what the hell I'm doing here then? very good question indeed)
|
|
|
|
|
Good and detailed answer.
I agree with you, and I'd also add that the embedded development *must* face with hardware as well. So, a decent knowledge of electronics is mandatory, IMHO.
Good luck!
|
|
|
|
|
The two books we have around the office, to which I refer when I need to refresh my failing memory are:
Embedded Systems Dictionary by Jack Ganssle and Michael Barr
and
Real-Time Concepts for Embedded Systems by Qing Li.
For a book on Electronics, The Art of Electronics by Horowitz and Hill.
Michael Barr was an expert witness in the Toyata case and his website barrgroup.com has some good resources.
|
|
|
|
|
Well, maybe my suppositions were wrong. I know I should learn by trying things, but need something to begin with... Like an introduction to the topic written for an engineer.
|
|
|
|
|
I, like you, have spent most of my career in higher-level languages, although I have also worked in assembly and C. Earlier this year I took a MOOC on embedded systems programming offered via the EdX - https://www.edx.org/course/utaustinx/utaustinx-ut-6-02x-embedded-systems-4806[^]. The course is free, but the hardware kit costs some money (you don't absolutely need the hardware, you can run with an emulator, but it is helpful to actually do the hardware part). It was a good course, I thought. I had fun, and learned quite a bit. They are re-offering it in January. Per the Linux thing, the (free) IDE they recommended used Windows, but I seem to remember some chatter on the message boards about getting it to work under Wine. Anyway, the textbook is an ebook that is free (aimed at the board they use for the class), the videos are all online on Youtube, so you could check it out before registering.
|
|
|
|
|
That is sort of like asking "what is the best book to learn about PC programming?". There isn't one because the field is broad. If you feel pretty good about C especially pointers and bit operations you are probably fine there. Frankly very little is done with assembly these days. Many embedded programmers are actually Electrical Engineers (I am). I think the one thing that defines embedded programmers is a deeper understanding of computer architecture and operating systems. Every RTOS implements the same things differently so without knowing what one you will use understanding POSIX is a good start. I'm not an embedded Linux fan. You'll probably want some type of background in serial communications or networking. You also need to think about the domain you want to go after. A motor control guy is much different that a video processing expert. Same with processors. If I had to pick a good processor to learn it would be ARM because that architecture is used in many applications.
There are lots of embedded book lists out there. Try www.ganssle.com/bkreviews.htm
Another thing to think about is debug tools. Debugging generally is not like it is for a PC. Baseline is JTAG debugging but a good embedded guy can also use a multimeter and oscilloscope. A great one can use a logic analyzer.
Once you narrow your focus a bit I would go research the relevant technologies that you are interested in. I'd also go buy myself a SBC Development kit preferably one with a good manual and a prototyping area to play around with, maybe even a JTAG interface. PIC kits are fun and there is lots of learning info out there but don't expect to find lots of jobs with them.
Good luck.
|
|
|
|
|
A good start to help decide what your needs are and go from there. <a href="http://en.m.wikipedia.org/wiki/Embedded_system">http://en.m.wikipedia.org/wiki/Embedded_system</a>[<a href="http://en.m.wikipedia.org/wiki/Embedded_system" target="_blank" title="New Window">^</a>]
|
|
|
|
|
Jacek Gajek wrote: Could you recommend me a proper book on embedded systems?
The answer as other's have said is "it depends", mostly on the flavor of the unit you are going to work with. There is a nice selection of boards out there such as the Raspberry Pi, Beagle bone Black, which are fairly close in capability, both run stripped Linux builds.
At the lower end, the Arduino is a fun board to play with and start building some skills. It uses an IDE with a C like syntax with versions for Linux (not sure which flavour). Microchip also has a number of demo boards to get you up and running (and a fairly decent free C based tool chain)...I think there are builds for Linux now...
In my experience, I have found the boards are the least of the problems, it's finding the low cost tool chains that are compatible (which tends to take out the higher stuff i.e. TI, Motorola, STM etc which have some very nice boards), unless your being funded. Most offer a limited use tool chain for demo, normally either size locked, time locked or other restriction.
Ken
|
|
|
|
|
I don't think you could lift a book that went into all that in any kind of detail.
When making the transition from Windows device drivers to 'embedded systems' I found the book "MicroC OS II" by Jean J. Labrosse very helpful (on Amazon here http://tinyurl.com/pgluzvd[^])
There is a newer version of the book but I have not read it and I don't think it's as good because the OS is closed source.
Jean has another book, "Embedded Systems Building Blocks" where he goes into interfacing with devices ( [on Amazon here:]) This is geared towards smaller systems.
There are 2 basic types of embedded systems, "super loop" and using some sort of embedded OS (such as uCOS/II.) Most of the engineers that I have worked with struggle with the concurrency issues. Get a handle on these first and you will be a step ahead of most people.
Wayne
|
|
|
|
|
Experience only
|
|
|
|
|