I have been using a Linux operaing system on a small ARM processor board. All of my software runs in user-space. I have had a big challenge creating software interrupts on a periodic bases. I've used the sigaction() and setitimer() functions to setup this periodic timer interupt. This gives me only one periodic interrupt that occurs ever 30ms. Is there a better way to do this? Could I get these interupts to occur more often, perhaps every 100us?
@kernelkernel: I just see it linked in as a module (604401.090805] Modules linked in: cdc_acm). I think that's part of USB OTG subsystem used to make USB behave as an Ethernet. I could be wrong those as I haven't looked at that part of the kernel in a few months.
@timd: The memory management uint (MMU) is used to create a translation of physical to virtual addresses. The MMU enables a consistent memory interface across all CPU architectures that run Linux. But, the use of an MMU and it's page tables consumes memory. So, uCLinux is a way to give a Linux look and feel to processors with well less than 1 MB of RAM. It's not quite Linux, but from a user's API perspective, it's pretty close.
@kernelkernel I see you're using USB OTG. The most known source for this bug is tring to sleep in a completion handler. So, if you try to sleep in a bottom_half (e.g., tasklet) you'll also see this error. Look at your ISR to see if you're using a schedule_tasklet call. If so, look in the tasklet to make sure it's not trying to sleep (wait_event, etc.) Also, look at your kernel timers for similar logic.
@timd: uCLinux runs with an MMU on smaller processors like the CortexM3/M4. It is based on the Linux source tree, but operates in a fundamentally different way than full-up Linux. I'd use the full-up version first and then experiment with uCLinux if you have a specific need to run on an MMU-less processor.
Mike: Thank You for that info. This error is occuring when I am trying to play a audio. There is a new chunk of code added . I have to debug it. I will post to the mailing list after I reach to certain point from the ftrace hint you have given
@kernelkernel: BTW, most of the time I've see that error were related to the driver calling schedule() while the application was supposed to have exclusive access. E.g., USB interface calling schedule in a wait_event_interruptible() call.
@kernelkernel The trace should be captured on the target. Is this bug repeatable? If so, use the tracing_on and tracing_off features in the kernel API to capture the function graph associated with the failure. Capture that info to a trace file and look at it on the host. Then, if it's a repeatible bug and not related to proprietary code, submit the bug and the trace to the Linux Kernel Mailing List for the maintainers to examine.
@kernelkernel The "scheduling while atomic" bug is a significant problem in your system if you're seeing it. I'd use ftrace to capture the trace around that and look to see where your system is going south.
@MIKE: Thank you Mike. I know there are a tone of forums also, but I thought to use the bond of this course to get a small group to interact as they grow in the subject as "class mates."
@jamesdeutch The stated goal of LTTng is to get it into mainline sometime by year end. But, because ftrace and oprofile are aready there, Linus may not be keep on adding yet another profiler to the kernel. If the argument for LTTng is compelling, then it will likely get in. If it's just another "me too" then it may never get into the kernel.
@timd Yes, it is the same source tree. Obvisously the interfaces are slightly different for the ARM because of the difference in CPU features. So, there may be features that exist on ARM that don't on x86 and vice versa
@INVITATION: I am accepting input from those interested in participating on an Embedded Study group. Please, write about your interest to luizcosta@sbcglobal.net. The level should start with basics but opent to any one interested in learning or helping to learn. No agenda in place yet.
Embedded systems typically need some kernel tweaking though some of this may be better done in a module. LCD driver for a specific LCD Controller in a new chip being one example.
Re mainline question: a few years ago, I would have answered affirmatively wrt being comfortable "doing the integration" work. But now, not unless it's integrated with whatever kernel source mgmt infrastructure I'm using (eg Debian's).
depends on level of work and benefits (if I'm trying to debug a problem building/integrating tools is a side-trip and too much time can be problematic)
Depends on the ease of integration (which usually means lots of documentation is needed) - I don't mind surgery on the kernel at all, but I don't like spending hours upon hours just trying to get a tool to work so that I can start on solving my problems
Varies for me. Often, commandline is faster to move around with. But GUIs that provide some sort of "value-added" output (like the tool in the slides) can be useful for first-line exploration (also nice is if they implement IO via separate thread or process mechanisms...).
If the tool is not in the mainline kernel, it needs to be better enough to make it work the effort to build a new kernel. Plus, if the tool is not in the mainline kernel, it makes kernel upgrades a pain.
I can't say that I have a preference. Sometimes I want to include commands within a script, or post-process the data. A GUI makes it harder to automate stuff.
I almost always require that my tools are fully functional via the CLI, but the option of viewing the information occasionally in a GUI so that I can use my eyes+brain as a pattern recognition device is useful.
CMD line is OK -- but I really appreciate a GUI for ease of use. Tired of thinking too hard. Too many systems, too much to remember too few brain cells. The easier the better...
@INVITATION: I am accepting input from those interested in participating on an Embedded Study group. Please, write about your interest to luizcosta@sbcglobal.net. The level should be beginner but opent to any one interested to learn or help to learn. No agenda in place yet.
thanks Mike for talking about interrupt handling. a really good refresher about why you don't do any processing in the interrupt routine, but schedule the work after an event is recognized.
So much for PANERA's "FREE" WiFi" Hi to all and sorryfor this huge delay in logging in mute on my iPad. Panera's net won't allow me to lig in on my Mac.
Used PCIe analyzer to see times between interrupt cause packet (either MSI or legacy INTx message) and the first read of the hardware register in the ISR
I experienced latency problem with my own uart based micro network -- on a linux with no low latency switched on we experienced problems with the micro-network which needed hard response times from the nodes.
only used our own debug functions (way back) in Windows CE. Have used Performance Validator (SoftwareVerify.com) more recently for timing information but not completely into kernel; was one layer above.
We looked at a number of sources to determine this year's greenest cars, from KBB to automotive trade magazines to environmental organizations. These 14 cars emerged as being great at either stretching fuel or reducing carbon footprint.
Researchers at MIT and Sandia National Labs have observed a reaction in lithium-air batteries that could help improve the design of these cells for electric vehicles and other applications.
Healthcare might seem to be an unlikely target application for the Internet of Things technology, but recent developments show small ways that big-data is going to make an impact on patient care moving into the future.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
4 
