Hello. I'm trying to get into the world of electronics, and the Arduino of course is useful, but its a very...'watered-down' ...version of embedded electronics. It reduces time to develop a project, yet because of it you can't really peel under all the code. I want to understand chip firmwares, how they work and how they're written and how they're uploaded. I want to understand exactly what each Arduino library does behind the scenes. I want to understand each communication protocol (with all the supported devices) for what it really is.

Now, I saw the Micro SD card that Sparfun stocks, and the page said, "microSD cards have a simple to use SPI interface". That made me happy, thinking I could start my journey by just understanding Arduino's SD card library. I goto libraries/SD/ and lo and behold, there are three lengthy .c/.h files, and a folder by the name of "utility" with even more files.

Did somebody have the same problem some time? Could somebody guide me? I want to know this and so many other things in electronics (even outside of embedded, but lets stick with embedded for the moment). All the firmwares for chips if seen so far have large, complex code too. How do I go about peeling back the layers and understanding how each thing works? I hate staying in the dark like this. Knowing the details makes me happy, but it seems like such an impossible climb.

 

All those library files are very long for good reason. Embedded systems programming is very complex.

As I see it, you have one of two choices:

1) accept pre-written library functions that someone has labored to produce,

2) learn from the bottom up by writing your own.

It depends on your objectives and final goal. If you want to become an expert and know everything there is to know, (2) is your only choice. Start by taking one MCU chip and learn to program all aspects of the chip in assembler. The path is long and tedious but very rewarding.

If you wish to short circuit the process and jump into producing final products quickly, then you go with (1) and accept library functions as is. Learning the api calls is complicated as it is anyway.

 

Mr. Chips is absolutely correct.

It is important to grasp the assembly layer, or better, the RTL layer, of a microcontroller. Then, understand that the compiler breaks the high-level code into assembly/opcodes for the processor. The Arduino sits on top of this abstracted layer, so I'd have to agree with your watered-down statement. Once you grasp this process, you can go back and deconstruct the Arduino libraries, though, you should know, it takes a long time to do it that way....

It bothers me how many people view the Arduino as engineering.... at best, it's hobbineering... So, thank you for wanting to understand the complex, for diving into the world of registers and ALUs

 

There are some people out there who programmed USB in assembler. But that is rather regretable. The firmware stack (C language) is not endless complex but it is quite a small number of files.

It is by no means neccessary to verify and understand how it actually works internally. You can spend a few weeks on it, and you will get some idea how it works.

This is why C language is used. You develope some piece of code, let say for a graphical LCD, and once it works, you bury the low-level stuff. And you forget about how it actually works.

Even 4-bit LCD is a bit of a pain to understand how it works in all details each time you use it.

 

Then what is there to engineering, if its all watered down professionally? Arduino is "hobineering" as someone suggested.. no need to remember the bottom layers. I just feel so cheap being an engineer when there isn't so much thought to it all, when there's no deep thought.

 

Arduino is crap. No engineer should use it for anything more than seeing if their sensor works. In fact, I think if an engineer suggests an Arduino in a end-product, they should be fired on the spot. No questions asked...(though, I'm sure that "engineer" would have plenty...). I called it hobbineering because it lets a hobbyist control a PWM signal to light a LED, but they do not understand what is happening internally. They cannot think, "Whoa, there are 100 wasted clock cycles from the compilation code bloating!", because they do not understand the basic principles.

No deep thought!? You mistake what we are saying. Sometimes, the abstracted layer is good since you don't have to reinvent the wheel, you can stand on the shoulder of giants. Sometimes, though, your timing requirements are so strict that you can't waste the extra clock cycle and you'll have to tear down everything into assembly. Other times, you have to scrap the processor for a FPGA because the whole thing really should have been a parallel process from the start. This field requires a vast understanding of how things work, what their trade-offs are, and using what you have to accomplish the task. You have to be able to justify why you put a second battery in your design just for a negative supply for an ADC that measures 0 - 5V. And, when you can't you must look back and think, what did I learn?

You say there isn't much to it, but what do you know? what do I know? It's impossible to know it all, but you have to be able to make it happen, either way, when your boss tells you to create a system using a FPGA using PCM which will modulate onto a carrier that will be randomly generated through a LSFR whose seed is a floating ADC input. If you don't know it, you don't tell him that you didn't learn that. You sit down and teach yourself. If he then tells you that you have to communicate with the FPGA through a VMEbus whose host is a 8-bit microcontroller, you should be able to tell him that that design is ridiculous, that a FPGA is much better suited to be arbiter on teh VMEbus.

Forgive me for the rant, I'm afraid it might be a bit harsh, but it is important for everyone to know that you do not know it all. You know how to flash a LED, and that's a great place to start, but do not mistake that for the end-game.

 

Divide and conquer is the only viable strategy. Nature is mechanistic and deterministic and there is no such thing as magic. Only sufficiently advanced technology.

You can use an Arduino as it is with all the scaffolding or you can get down to bare metal. If you go down to bare metal it is as good a $35.00 board as anything else that might be in second place.

It is hard to beat for rapid prototyping and you could hardly go wrong using it for a reference design built around any similar chip.

 

Divide and conquer is the only viable strategy. Nature is mechanistic and deterministic and there is no such thing as magic. Only sufficiently advanced technology.

You can use an Arduino as it is with all the scaffolding or you can get down to bare metal. If you go down to bare metal it is as good a $35.00 board as anything else that might be in second place.

It is hard to beat for rapid prototyping and you could hardly go wrong using it for a reference design built around a similar chip.

I am referring simply to the Arduino...the abstracted layer, not the AVR microcontroller or the board itself.

Prototyping, yes, it is useful, but that's where it ends in the professional workplace.

 

I am referring simply to the Arduino...the abstracted layer, not the AVR microcontroller or the board itself.

Prototyping, yes, it is useful, but that's where it ends in the professional workplace.

No argument -- Agreed
I have often said the same thing about the 555