HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Comments
You must login to participate in this chat. Please login.

I tend to be on the fence when it comes to GUI. I generally like to work with the command line but when tasks become repetitive a GUI is nice.

Iron

Reviewing this lecture

thank you Michael,

Iron

Mike: http://www.youtube.com/watch?v=JzMj_iU4vxs

do you have a better version of this some where? the audio is broken here

 

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?

Iron

Mike:I too am new to the code. Just started looking into it. But there is only wifi on this . so may be it is manifesting into more..

 

Mike: You may be right "USB behave as an Ethernet"

 

Well, sorry gang.  I'm out of time.  Got to get on to another meeting at a customer facility.  CU tomorrow.

@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.

Mike: I have only USB slots on the target. And USB OTG of not configured

@GBr is correct.  The actual ARM7 (opposed to the ARM v7 architecture) does not have an MMU.  ARM7tdmi would be an example of an MMU-less processor.

Mike: Thank you so much. But There is no USB OTG on the target. Could you please tell me what  part of code error

indicates it is USB OTG.

@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.

@timd MMU is memory management and allow you to have virtual address space. Without MMU you use real addresses. ARM7 I believe is without MMU.

Iron

@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.

What is MMU and how does it effect the operation of the kernel?  What would I use uCLinux for?

 

Iron

Mike: I need some help in reading this bug.

Mike : this is olpc 3.o kernel

 

Mike:Playing WAVE 'AfroString.wav' : Signed 16 bit Little Endian, Rate 11025 Hz, Mono
[604401.079555] BUG: scheduling while atomic: aplay/23434/0x00000002
[604401.090805] Modules linked in: cdc_acm fuse xt_tcpudp iptable_filter ip_tab]
[604401.134306] [<c00368a0>] (unwind_backtrace+0x0/0x11c) from [<c0397054>] (__)
[604401.149253] [<c0397054>] (__schedule 0x5c/0x430) from [<c03983c0>] (schedul)
[604401.171340] [<c03983c0>] (schedule_hrtimeout_range_

clock 0x44/0x100) from [)
[604401.194844] [<c00d83a4>] (poll_schedule_timeout 0x38/0x4c) from [<c00d953c>)
[604401.217771] [<c00d953c>] (do_sys_poll 0x2c0/0x374) from [<c00d968c>] (sys_p)
[604401.233296] [<c00d968c>] (sys_poll 0x58/0xb8) from [<c0030e80>] (ret_fast_s)
 

@kernelkernel  Usb audio by any chance?  Good luck.

@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.

OK, folks, I gotta go to review the presentation from start. 

I'll e-see everyone tomorrow.

Iron

Mike: ThankYou so much! very helpful indeed!

@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. 

Mike: specific debugging on Target and HOST ? for BUG: scheduling while atomic

 

@timd - LinuxC does not support Mem Management.

Iron

@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: BUG: scheduling while atomic

how to start debugging this 1. on Target  2. on HOST

please give a hint

 

What would be the difference between this linux code and uClinux?  Would uClinux be an esier starting point?

 

Iron

@Chuck - just now found the next week starts Aug 20 title ARM Core

Iron

@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."

Iron

BUG: scheduling while atomic

How to debug this, on the target?

 

@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

Thanks -- see you tomorrow.

Iron

@Mike: Question may have been lost... Do you see LTTng going into the mainline, and if so how soon?

Everyone:  There is also an embedded Linux group on Linked-in if you're interested.

When I download the kernel code to compile it for my embedded ARM processor is this the same code that is downloaded for the x86 processor for my PC?

Iron

@mraza17: You are actually using the live chat when you Post your statement about not getting on the live chat. This is the live chat.

Iron

Fore those who missed this post:

@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. 

Iron

@brettdog No, top doesn't use any of these mechanisms directly.  Top uses the scheduler info ranterh than the tracepoint interface.

@Chuck: have not needed to profile the Linux kernel in my current work.

Iron

@Chuck: measured interrupt latency using an ICE.

Iron

Thanks Mike and Chuck,  Great information and so easy to use.

 

Iron

@Chuck - when are the next week of presentations scheduled

Iron

Thanks! - still learning from a firehose :)

@FarAfield  True, there will often be some sort of timing critical code that needs profiling.  Especially if you're writing the LCD driver itself

@chuck - thanks Chuck and DigiKey - bring back the Starbucks coupons!

Iron

thanks for this new (to me) info. GREAT!!!

Nice. Thks. Adios

 

Iron

Thank you for another great presentation

Iron

thanks Mike - series has been great intro and very informative - see u tomorrow

Iron

Thank you Mike, Chuck and all.

Iron

Does TOP use one of these debugging methods?

 

Iron

Can't access live chat

 

Iron

Thank you Mike and Chuck!

Iron

Great class, thank you.

Iron

Thank You for the great time, see you tomorrow!

Iron

Thanks Mike and Chuck

Iron

Thkx Mike, Chuck.

Iron

Thank you very much Mike.

 

Iron

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.

Iron

Thank you for the presentation.

Thanks Mike and Chuck for the interesting session. see all tomorrow.

Iron

Thank You. Chuck n Mike!

 

Thanks Mike and Chuck!

Iron

Really informative.  Thanks.

Iron

Thank you for Today's presentatlion Mike

Iron

thanks mike & chuck!

Iron

So far the OS has been a black box but as I have to start writing my own OS the ability to profile in it is more important.

Iron

Yes. It would be helpfule to have a profile tool.

Iron

When doing soft real time activities - profiling is useful.

profile kernel - have done so in past; optimizing drivers

@Chuck: have not needed to profile the Linux kernel in my current work.

Iron

tools - could be outside of mainline.  I choose what I like best in the end.

kernel - a black box for me

Iron

Sometimes, I would like to, but I usually don't actually get around to it.

Iron

I have worked with a group that needed the kernel profile tweaked for realtime extensions. 

Iron

@Chuck - treat OS kernel as black box - never needed to profile it

Iron

profiling may be handy for embedded applications. Have not used linux of any kind yet.

Iron

Not usually. It really depends on the problem.

Iron

Black Box? Perfect! -- whenever I can. It never seems to work that way though!

Iron

I have changed some predefined values in microcontroller for programming interrupts etc

Iron

profiling -- yes -- useful in secuirty analysis...

Iron

Have not had to yet but vould like to do after learning more

Iron

Haven't had to profile a driver recently...

Iron

Need to profile to guarantee some soft realtime apps

 

Iron

rarely against the kernel

Iron

Well, for RTOSs ya kinda have to.

Iron

Kernel as a black box for now.

Iron

I need to profile all the time for getting efficeincy results of my changed code

 

have not yet needed to profile the kernel

Iron

Yes we do for some issues.

Iron

Not much of a need here.

Iron

Does anyone else chuckle when they hear "you can take a dump"?

 

Iron

Slide 18: CTF = Common Trace Format. LTV = Linux Trace Visualizer. Are these right?

Iron

Finally on the net from the Mac on Firefox. Safari on the iPad OK for Panera. but not on the Mac. Go figure.

Iron

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).

Iron

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)

If necessary, otherwise stick with mainline

Iron

For production development - NO want pre-integrated.

For hobby use - not quite so important.

Depends. It's more convenient when in mainline, but some value may be worth working with a non-mainline tool.

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

Iron

prefere mainline included

Iron

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...).

Iron

I am a beginner at this so, I can't comment on this question.

Iron

@Chuck - would prefer tools to be already integrated - this only makes the most sense to me

Iron

The tool can be outside of mainline, as long at the instrumentation it's using is IN mainline.

Iron

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.

Iron

would rather not, but not a big deal

Iron

Depends on what I'm trying to do.  If I need it, I'll do it.

Iron

Outside of mainline kernel means it changes the problem I'm trying to debug. 

Iron

If it causes problems in the kernel I avoid it.

Iron

It depends on what support is available

Iron

Integration? Maybe, maybe not. Depends on desperation level.

Iron

It depends on how well documented the non-main-line tools are.

Iron

willing to try non main line tools

Iron

Whatever they pay me for.

Iron

yes, willing to integrate if it's worth it

Iron

If its needed badly enough.  Cross-compiling can be painful at times

Iron

Tools outside mainline can be big trouble.

Iron

Not enough time to integrate here.

Iron

@Chuck - sure, why not...

Iron

Had too many issues with not so well thought GUIs... If I need a GUI I could build it myself on top of the CLI... so many issues eliminated

Iron

looks like another dropped post during the last question.

I tend to use command line and a keen eye for debug.

Iron

kernelshark is a way cooler name....lttng needs a new name. :)

Iron

Depends on what I need.

Iron

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.

Iron

Depends on what I'm looking for: GUI to see overview of situation and command line for detailed analysis.

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.

Iron

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...

Iron

@Chuck: I use both: GUI often for initial analysis, command line to build my own tools for regression or other repeatable processing.

Iron

command line is good for scripting; analyzing I'd rather a GUI - regardless, the data format should be documented and manipulatable

 

Both - Command line and GUI

 

Iron

Generally GUI.  Testers like cmd line because it's easier to automate.

Iron

GUI when it works.  Command line data dump when it does not.

Iron

@Chuck, Comfortable with either interface.

 

Iron

Command line seems to give most flexiblity.

Iron

@Chuck - gui is preferable - but also can use cmd line

Iron

a hammer for nails, a screwdriver for screws. Use the right tool for the job, it is not an either/or question.

Iron

commandline and vim  and menuconfig for kernel preferred!

Iron

both are nice to have -- gui and command line

Iron

split half/half between guis and commandline.

Iron
@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.
Iron

@Chuck - love the command line (much easier, for automation etc...)

Iron

I prefer to have both options available.

Iron

depends cmd line usually, but gui for analysis graphs

Iron

Usually, command line.

Iron

Command line for sure.   Think remote debugging.

Iron

depends, whatever works

Iron

used to command line....will use gui if available.

Iron

No difference in preference for command line or GUI

Iron

Definitely feel more at home at the command line. Way more power. Way more speed.

Iron

Depends what the output is.

Iron

Depends on what I'm looking for.

Iron

GUIs always seem to be missing features...

Iron

Where is trace.dat located?

Iron

@Chuck, never measured latency

Iron

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.

Iron

great question gschmick

Iron
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.
Iron

@Mike: Would you explain what you mean by top/bottom half?

Iron

@Chuck: measured interrupt latency using an ICE.

Iron

i/o pins and scope once

Iron

Using external emulator with an embedded hardware

Iron

Emulator Logic Analizer Scope

Iron

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

Iron

not under Linux, with a scope and test code to toggle I/O as neeeded

Iron

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.

Iron

In the kernel, you can access fine-grained clocks.

Iron

scope and logic analyzers

Iron

Yes.  We simply would set or clear hardware bits (which add a known overhead), then measure using a scope.

Iron

in past twiddled a parallel port bit and time on oscilloscope, have used logic analyzer way-way back (8086 CPU)

 

Yes. Used a scope, but was not a linux operating system.

Iron

have used hardware techniques in the past. trigger a scope on an event and measure in us

Iron

To verify timings, used a scope...

 

Iron

Yes - io pin and oscilloscope.

Havent measured interrupt latency

Iron

@Chuck - yes (re. interrupt latency) using a scope

Iron

Hardware (JTAG, Logic analyzer)

Iron

@Chuck - nevered measured interrupt latency

Iron

yes. cache tick cnt at start and end of isr then calc difference

Iron

Doing that now -- but embedd RTOS systems. Yes an oscilloscope is by my desk to...

Iron

Averaged Multiple interrupt calls.

Iron

I believe so, but think it was corporate tool dependent.

Iron

measured with polling. ac-dc  conversion

Iron

The Time Stamp Counter (TSC register) is great for measuring latency.  It can be used from user space, as well.

Iron

tools within VxWorks and logic analyzers

Iron

Have not needed to measure int latency.

Iron

io bit and a scope

 

Iron

I've not had to measure interrupt latency... yet

Iron

havent userd ftrace

 

Iron

lost audio for a moment (streamer was buffering) - simply stopped the streamer then started again - recovered easily

Iron

Question for the moderator (Chuck?).  Hw many folks registered for today's session?

Iron

how do you know which tracers are running and when?

no, i have not any trace functions.

traced in a simple OS - uC/OS-II

Iron

nevermind, flash crashed on me.  :)

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.

audio has dropped out here...

Late in Newport!

 

Haven't used ftrace

Iron

Used LTTng on Linux, but not Ftrace

I tried to use LLTng but it was difficult to apply the patches and I couldn't get the module to start without crashing

Used LTTng via some 3rd party tools.

Iron

have not used an OS function tracer, sounds great though.

Iron

Wow and all this time I thought you martians were invisible, so you are only hiding.  That is sneaky.

Iron

I have used the OS trace functions -- some from antiquity.

Iron

No, not that I recall...

Iron

@Chuck - not used OS func trace ... but extensive application func trace

Iron

vxworks, linux, threadx, and so on

 

Iron

developed my own....

Iron

I've never used a system tracer, but I'm interested ;)

Iron

Greetings from Mars, Earthlings.

Today your rover tried to take some pictures of us but we hid because we are extremely camera shy.

 

 

Iron

Good afternoon Mike.

Iron

Hello from Germany

Iron

audio loud and clear

Iron

Good afternoon folks

Iron

Hello from Milwaukee

Iron

Audio is loud and clear...

Iron

Hi from Northern CA

Iron

Greetings.  (JPL @ Pasadena, CA)

 

Iron

Hello to all from Needham, MA   (temp 88 F, bright and sunny)

Bon après-midi à partir de la Nouvelle-Orléans

 

Iron

Hi All From California

Iron

Hi from Portlandia (Portland OR) the land of Grimm/Leverage/Tektronix and Intel

The session will be starting in about 2 minutes...

Hello from Albuquerque, NM.

Iron

Hi, All. from British Columbia

Iron

greetings from PA

 

Iron

we sure are missing our Starbucks from digikey - how 'bout it

Iron

hi'ya y'all from Dallas --- on the way to 105F ... low 78F

Iron

Hi from Tucson 106 Deg

Iron

@nick78739, good thing it's not 111, or maybe it stands a chance of getting that hot.

Iron

In computers, there are 10 kinds of people.  Those that understand binary and those that don't.

Iron

In Austin, TX we're going to binary: 100, 101, 100, 100 for the next few days (degrees F)...

Iron

Good morning all from Edmonton, AB. Sunny and cool so far.

Iron

Good afternoon, everyone

Iron

Greetings from Washington, DC.  Temps here are in the 90's.  

The session will be beginning at 1400 EDT.  See you all on the audio feed...

90 C?  Are you in some sort of test chamber?

Iron

Good Afternoon from Ottawa.

Iron

Good Morning/Afternoon from Sunny San Jose, CA. Going to be 90 °C

Iron

Hello from Richmond, TX though I'd rather be in Richmond, VA.  It's cooler there.

Iron

Hello from sunny SE Lake Simcoe Ontario Canada. except it's cloudy and raining...

Iron

And a very early hello to you, from Colorado Springs, CO

Iron


Partner Zone
Latest Analysis
Robots came into their own in the 1970s. Gone were the low-budget black-and-white B movies. Now robots roamed in full-color feature films with A-list actors.
The rear window on Ford's Lightweight Concept vehicle, based on the Fusion model, is made with a material combination devised by SABIC that saves 35% of the weight. The car's overall weight is 25% lighter than a standard production 2013 Fusion.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
There is still time to get in your gadgets for the Design News and Allied Electronics second annual Gadget Freak of the Year contest. The top three gadgeteers will be awarded a total of $10,000.
Major global metropolitan areas are implementing a vast number of technology, energy, transportation, and Internet projects to make the metropolis a friendlier, greener, safer, and more sustainable place to be.
More:Blogs|News
Design News Webinar Series
7/23/2014 11:00 a.m. California / 2:00 p.m. New York
7/17/2014 11:00 a.m. California / 2:00 p.m. New York
6/25/2014 11:00 a.m. California / 2:00 p.m. New York
5/13/2014 10:00 a.m. California / 1:00 p.m. New York / 6:00 p.m. London
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Jul 21 - 25, Design Products With Bluetooth Low Energy
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.
Next Class: August 12 - 14
Sponsored by igus
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2014 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service