I am having trouble with this question, somebody (hopefully mistakenly) moved the previous question to Unix/Linux list which has zero uclinux tagged questions. This is more of a embedded linux question..
I have a question about the footprint of uClinux. I have looked around to find a breakdown of requirements, there is no nice info on the net. The modules under interest are:
Core kernel TCPIP stack Serial Driver DHCP WiFi Support (any of the stack from vendors is ok) I am looking for RAM/Flash breakdown. I don't need a filesystem however there is a chance that I need it due to the driver model of Linux.
Bonus question: - Porting drivers from Linux to uClinux. I know the memory architecture is different. Considering driver doesn't do anything special wrt memory, could I just recompile the driver and expect it to work under uClinux?
I understand the drivers work pretty well. This driver has been ported to uClinux on Blackfin and STM32. http://www.sagrad.com/index.php?option=com_content&view=article&id=130&Itemid=130
The are running a sale on the ICs, Most of their modules that support WiFi and linux work with uClinux.
Related
In the case of x86 the same (real mode) bootloader works on virtually any x86 device.
Is that possible on ARM or do I need to create a specific bootloader for each 'cortex'?
x86 or lets say PC compatible systems are ... pc compatible. They support the ancient bios calls so that there is massive compatibility. by design, by the chip vendor (intel) the software vendors (bios, operating system) and the motherboard vendors.
ARM is in now way shape or form like that. There are instruction sets you can choose that work almost or all the way across, but remember ARM systems you buy an ARM core and add it to your special chip, you and your special/custom stuff, then that is put on one or more different boards. There is little to no compatibility. Instruction set and arm core is a small part of the whole picture most of the code is for the non-arm stuff.
u-boot and perhaps others are fairly massive bootloaders, pretty much an operating system themselves, and have to be ported just like an operating system to each chip/board combination. The chip vendor, if this is a linux compatible system, most likely has a reference design and a BSP including a u-boot port and/or some other solution (rasberry pi is a good example). it is fairly trivial to boot linux or used to be, there is no reason for the massively overcomplicated u-boot. without a DTB you setup a few memory locations a register or two and branch to the kernel, thats it (again look at the raspberry pi), I assume with DTB you build the dtb then put it somewhere, setup a few registers and branch to the linux kernel (raspberry pi? ntc chip?)
There is a Arm open source project that can cover Armv7/v8 Cortex-A processors bootloaders.
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Another open source project for Cortex-M processors:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/
I am totally a fresh on an assignment of developing a driver on a board, which uses a "small" Linux. Every time I make everything and get a ".bin" file on PC and then ftp ".bin" to the board, the system will just work.
Now the problem come. I checked the system, it can not use gdb. So when the system crash, it will just provide a core dump file, which gives messy address info (seems not helping or at least I have no idea how to use this).
Any experienced embedded developer can kindly give some suggestions? How you debugging in your work?
By the way, if the console print crash info includes stack info and Call Trace, no epc and ra (I just learnt that). Can the epc(crashed address) be found still?
Many kernel developers, including myself, do not use a debugger when developing device drivers. For many years, Linux did not support kernel debugging. Even now, not all CPU architectures support kernel debugging.
One of the easiest things you can do is to use printk to log events to the console. Also, increase the console UART speed. I often use 115200 baud.
The Linux kernel does support kgdb now, for some CPU architectures.
https://www.kernel.org/doc/htmldocs/kgdb/index.html
I also highly recommend Linux kernel developers read these two books:
Linux Device Drivers, by Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman
Understanding the Linux Kernel, by Daniel P. Bovet, Marco Cesati
I am post-newbie to Embedded Linux driver development, have developed Character, UART & simple USB drivers, and have worked with SBC (Raspberry Pi 2). My main learning resources are: Essential Linux Device Drivers, Embedded Linux System Design & Development, youtube tutorials and LDD3. Because of lack of real life driver experience, I have some questions that I would like to share:
Templates: are there some sort of driver templates for speeding up the coding process e.g. have the regularly used structures & functions for being modified & customized for the specific drivers.
What’s suitable minimum distribution:
What I am doing now is either building a kernel image using Buildroot then inserting the developed USB driver into it OR inserting the developed USB driver into a Ubuntu. And for proper testing I have to unload the default USB driver (usb_storage); otherwise can’t test my module. So, my question is regarding real-life development & how-to get minimum kernel that has no drivers, & how-to include my module into it (to be part of it) while building with Buildroot?
What Embedded Linux Driver Development community do you suggest for detailed Q&A?
i.e. In future if I want to ask about low level detail such as what is this x structure, or I am getting this error while using this y function .... is there a specialized community? because all I found are for Linux in general, for Kernel hacking, or don’t have experiences.
What is the missed link in the chain?
Developing applications for Microcontrollers relies on Datasheet, User Guide, Registers, C, etc. Developing Drivers for Embedded Linux relies on C, Linux API, Subsystems, etc. In most learning resources, I never found a relationship between both. So, are there really separated? OR there is a missed link between them??
e.g. for this I2C sensor http://www.robot-electronics.co.uk/htm/srf10tech.htm we have to manipulate it (send hexa to & receive values from its registers). If we imagine that we want to develop an I2C driver for it, then for sure we would need to do the same from within the driver, which is explained in Essential Linux Device Drivers (page#278). The main point behind it is that I2C core hides many complexes & simplifies driver development process.
However, I expect the case in real life is not for a sensor, instead it might be a Microcontroller or a complicated device. So, how would we manipulate the Registers & Peripherals of this Microcontroller? Also, I didn’t find tutorial for such a case!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What is the difference between programming for embedded systems vs device drivers? Both areas deal with making the hardware do a specific task. I would appreciate an explanation. I have knowledge of C and i would like to go a bit deeper dealing with the hardware.
What is the difference between programming for embedded systems vs device drivers?
Writing a Device Driver means a very specific thing: writing low-level code that runs at elevated privilege in the kernel. It's quite tricky, but if your hardware is similar enough to existing hardware, you can sometimes "get by" by copying an existing driver and making a few changes. Writing a driver from scratch involves knowing the a lot about the kernel. Device Drivers are only written in C.
Writing for an "Embedded system" isn't very specific. Generally, it means "programming on a computer with fewer resources than a desktop PC, and maybe special hardware". There is no real line between "embedded computer" and "general purpose computer".
Everyone would agree that an 8-bit system with 128 bytes of RAM is "embedded programming" (Arduino). But the Rasberry PI (with GBs of RAM, hard drives, HDMI display) can be considered embedded or not depending on your view. If you unplug the monitor and put it on a robot, more people would say it requires embedded programming. People sometimes call programming apps for phones "embedded programming", but generally they call it "mobile" instead.
Embedded systems can be programmed in high level languages like Ruby/Python, or even shell scripts.
What are some purposes to programming device drivers
Well, any time you have a hardware device. These days, we have FUSE and USBLib, which blur the line. But if you want your wifi/webcam/usb port to be recognized by the OS, it needs a driver.
What cant you do programming wise for embedded systems that you can programming device drivers and vise versa?
As I said, embedded systems sometimes contain bash scripts (i.e. my home router).
I'm confused because they both deal with programming for hardware specifically on a low level.
There is some overlap, but they are quite distinct.
Embedded is an adjective that describes the whole system, while 'driver' refers to one specific tiny part of the system. You can do driver programming without doing embedded (i.e. writing a driver for a webcam on your desktop), and you can do embedded programming without writing new kernel drivers. (i.e. no need to write drivers if all your hardware is supported by the kernel.)
If i wanted to create a robot would this be under embedded systems or device drivers?
On-board robotic systems are usually embedded programming. It gets fuzzy if you strap a laptop to your robot -- people might say that's not embedded anymore, since it's a desktop OS. (Embedded systems rarely have a GUI, and if they do, it's rarely a mainstream one.)
Your robot may or may not require writing new drivers. Maybe the motor can be turned on from user space, so you don't need a driver. On the other hand, there are times where you need the extra features found only in the kernel: Faster response times, access control, etc. For example, if your program dies, it might leave the motor running, and that's bad. So you can write a kernel driver that will clean up for your program when the program exits. It's a little bit more work up front, but can make development simpler down the road.
What about making the GPU of a PC work for that O.S.? Would that be device drivers? If the hardware is stand alone without OSthen it is embedded?
Yes. Writing a GPU driver is writing kernel device driver code. (it's fuzzy these days because of libraries, but whatever.) If you wrote it on embedded hardware, you can call it both device driver and embedded programming.
The way you have posed the question the answer is there is no difference. you have asked what is the difference between an apple and an apple? None.
Now if you are wanting to say compare bare metal and linux device drivers? Well the linux device drivers have a lot of operating system api calls you have to make and have to conform to that sandbox, so there is a lot of work there on top of the poking and peeking of registers and memory of the various peripherals. If you go bare metal (no operating system) then you can do pretty much anything you want, you can create more work for yourself than a (linux) device driver or you could create less work for yourself.
You can go to the depth of a device driver, or all the way to bare metal it is your choice. As far as the peripheral is concerned the stuff you have to do to it or with it will be similar, the differences will have to do with dealing with the operating system vs dealing without an operating system.
Maybe you should pick a task and do that, something like send a byte out a serial port is a reasonable statement. Putting a pixel on a display (raspberry pi is an exception), anything graphics, anything usb, is not a reasonable statement, there is a considerable amount of overhead and knowledge and experience you would need before doing that. Blinking an led (basic gpio) reading a button, and uart tx and rx are generally where you get your feet wet with bare metal. Granted tty/uart stuff on linux is far from beginner stuff so you really just have to start trying things and failing and get up and try something else and see where that takes you. fortunately there are tons of simulators out there so you can do all of these things using free everything, simulators, toolchains, etc.
I need to integrate a network stack into my embedded application. It can be a cross-platform real-time network stack written on C. The application is based on ARM7 processor and FreeRTOS kernel.
For example I would use TRECK (Treck Inc.) or Fusion (Unicoi Systems) real-time network stacks if they were free. Also I know that, for instance, there are ports of FreeBSD's and OpenBSD's network stacks to eCos operating systems, but is it possible to obtain them as a stand-alone package so that it's relatively easy to integrate them? Although I suspect they are not real-time.
Please, do not suggest me to change the OS for my application to one that has a built-in network stack. :-)
Why, I've found at least uIP and lwIP open-source network stacks. But they appear to be not real-time.