64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »

Delta-Wye: Sep 29, 2005

JawnV6 posted:

Sorry, I don't mean to sound so snippy.

It's just that debug is very, very important. Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging can easily get to the 90% mark on a project without any red flags then have horrendous integration debug because they can't easily peek at what the software's doing. At that point it's a difficult decision between engineering a one-off solution with an oscilloscope and hardware or changing the entire toolchain. Neither impossible, but I wouldn't want to implement either right up against a deadline.

Notice that everyone who said IDE's weren't necessary backed it up with very good practices. Unit tests, strict development, etc. It takes some expertise to figure out when a debugger isn't necessary.

Well, you're still being snippy :colbert:

I like the power and configuration of command line tools, I think they can be used to great effect in those good practices you mention. I sometimes find myself being too lazy to run through with gdb but that's hardly the tools fault. When building things like automated unit testing, its great to keep a consistent toolchain across different projects and architectures and the gnu stuff seems like a logical choice.

SybilVimes posted:

Personally, I'd still be happier with a consistant and easily ported system that allows me to get on with debugging if I need to, rather than learning the quirks and oddities of a new system for every hardware platform. Thus the 'command line land' with gdb (and gdb-stub) is preferrable to me.

As one of those programmers from linux land, I decided it would be worth trying to get my dev environment for msp430 moved over to the gnu chain under linux. I was mostly worried about the drivers for the programmer (a Olimex special from quite a few years ago that can be finicky in Windows with the official drivers).

Installing the cross-development environment in gentoo was easy enough:

code:

emerge crossdev
emerge mspdebug
crossdev -t msp430

Compiling code is pretty easy:

code:

user@host$ msp430-gcc -mmcu=msp430f2131 msp430test.c -Wall -g -o testapp

To program the chip with the program, I need to use mspdebug. I was really worried about this step, but I plugged in my programmer and ran the list devices command and got this:

code:

user@host$ mspdebug --usb-list
Devices on bus 001:
    001:002 8087:0020 
    001:001 1d6b:0002 
Devices on bus 002:
    002:002 8087:0020 
    002:001 1d6b:0002 
    002:095 1a40:0101 
    002:091 046d:c313 
    002:104 046d:c219 
    002:108 15ba:0002 Olimex MSP430-JTAG-TINY (v1)
    002:102 046d:c52f 
    002:099 1a40:0101 
    002:096 1a40:0101 
    002:103 046d:c52b 
    002:098 058f:6387 
Devices on bus 003:
    003:001 1d6b:0002 
Devices on bus 004:
    004:001 1d6b:0003

Cool, found it without any actual work on my part. It always surprises me when Linux ends up with better support than Windows thanks to some dude working in his basement. Anyways, programming and starting the gdb stub isn't too bad either:

code:

root@host# mspdebug olimex-v1 -j
(mspdebug) prog testapp
Erasing...
Programming...
Writing  124 bytes at e000 [section: .text]...
Writing   32 bytes at ffe0 [section: .vectors]...
Done, 156 bytes total
(mspdebug) gdb
Bound to port 2000. Now waiting for connection...

Then I run the debugger and connect to the remote target:

code:

user@host$ msp430-gdb
(gdb) symbol-file testapp
Reading symbols from /home/dboyer/msp430/testapp...done.
(gdb) target remote tcp::2000
Remote debugging using tcp::2000
0x0000ffff in __ivtbl_16 ()
(gdb)

I have a ways to go yet; this is extremely cumbersome at the moment but these tools are scriptable. It only took me a few minutes to get a "make debug" command that compiled the project (as necessary), programmed the chip, and started up the gdb stub in one go. I should be able to turn it into a couple quick and easy commands to do just about anything I need if I want to stay on the commandline. m3oh has some information that leads me to believe that Eclipse can be made to run all of this stuff if I wish to move to a GUI, which would be pretty slick too.

In the interest of full disclosure, I was one of the printf debuggers for far too long

# ? Nov 16, 2013 22:35

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 17:03

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

sund posted:

What do you guys think of the mbed platform? I'd rather my low level peripheral driver turd polishing amounted to something more than some code with a funny API that will stagnate on my company SVN server. It seems pretty win/win/win for the company, me and the platform to adopt something like this at work instead of rolling our own everything. Personally, it comes off as maybe a little Arduino-like, but they could just be good at hiding the gritty details. Any experience besides laughing at the concept of an online compiler?

I used it for a summer. It is laughably bad as an IDE, because it is shorty and slow and browser based so there's bad shortcuts and no debugging capability and honestly why else would you use an IDE? Having libraries to use is nice and all but they're also just glorified app notes and drivers of the sort you'd otherwise get from the vendors. There's no actual upside and dealing with the online ide is just way too lovely to make make up for it.

# ? Nov 18, 2013 03:22

Krenzo: Nov 10, 2004

Has anyone used NXP Cortex M0/3/4 chips, and their LPCOpen library?

# ? Nov 22, 2013 01:53

Krenzo: Nov 10, 2004

Nevermind, I was having trouble getting SPI to work on their LPC1316 Cortex M3, but their support got back to me. It turns out when setting the IO mode of a pin, the value of reserved bits is important. You can't just set the lower bits to what mode you want and set the rest to zero if there are reserved bits that default to 1.

# ? Nov 23, 2013 03:32

some kinda jackal: Feb 25, 2003; �
�

Is anyone here familiar with IAR Embedded Workbench? I have the 16kb limited Kickstart version that I got from STM that works just fine for my needs right now, but I'm thinking about picking up the AVR version as well. Will the two integrate into each other, or will I be stuck with two separate installs, one for AVR and one for ARM?

And yes, I realize that Atmel Studio is free, but I'm not going to be footing the bill for this so whatever

# ? Nov 29, 2013 21:38

EpicCodeMonkey: Feb 19, 2011

Martytoof posted:

Is anyone here familiar with IAR Embedded Workbench? I have the 16kb limited Kickstart version that I got from STM that works just fine for my needs right now, but I'm thinking about picking up the AVR version as well. Will the two integrate into each other, or will I be stuck with two separate installs, one for AVR and one for ARM?

And yes, I realize that Atmel Studio is free, but I'm not going to be footing the bill for this so whatever

They'll be separate, and (at least from my installs) it will then break every freaking project file since it will prefer one IDE version over the other, causing errors if the wrong one auto-opens.

# ? Nov 29, 2013 23:24

some kinda jackal: Feb 25, 2003; �
�

EpicCodeMonkey posted:

They'll be separate, and (at least from my installs) it will then break every freaking project file since it will prefer one IDE version over the other, causing errors if the wrong one auto-opens.

Wow. Okay hmm. That's pretty awful

# ? Nov 30, 2013 00:44

carticket: Jun 28, 2005; white and gold.

Yeah, it's no fun using multiple platforms of EW. Also EWARM is the only one that sounds cool.

# ? Nov 30, 2013 00:52

armorer: Aug 6, 2012; I like metal.

I have zero experience with it, but you could always stick it in a VM if you want to try it out without interfering with another install.

# ? Nov 30, 2013 03:03

carticket: Jun 28, 2005; white and gold.

armorer posted:

I have zero experience with it, but you could always stick it in a VM if you want to try it out without interfering with another install.

The interference is just file associations. Only one instance can be opened when you double click ewp/eww files. I have 5 versions of EWARM installed at work for different projects that are stuck to specific versions and and install of EW430. It doesn't cause problems at all since I don't try to double click the workspace files to open them.

It does suck when you accidentally open a 5.x workspace in 6.x. You basically have to roll back via version control or recreate the workspace in 5.

Edit:

This week I learned to love Duff's Device. I've been trying to optimize a bit banged parallel NAND driver because we need better performance. With Duff's Device, the read loop went from 6 instructions per byte down to 4.125. After doing all that work I found out that the three instructions that hit the peripheral bus take so much longer than the loop overhead that there was only like a 10% boost.

carticket fucked around with this message at 05:23 on Nov 30, 2013

# ? Nov 30, 2013 05:17

EpicCodeMonkey: Feb 19, 2011

Mr. Powers posted:

The interference is just file associations.

It's still crappy coding; Visual Studio and other IDEs have a common shell launcher that is associated with the project/solution/whatever files, which examines the file and then bounces it to the appropriate IDE version. IAR is a terrible, awful product - and not ever having to use it again is the only (big) perk to leaving my current job.

The project file format belongs in the coding horrors thread too; it's a mishmash of binary data, random fields, ASCII encoded bitfields and other junk wrapped up in XML.

# ? Nov 30, 2013 10:04

some kinda jackal: Feb 25, 2003; �
�

Yeah, I've just been using IAR because I got that neat Kickstart version (and it's really just been all I needed for now). I was hoping to leverage the familiarity for an AVR IDE but I guess that's not likely to happen since it's such a mess. I could use a different VM for each one, but :effort:

. I was kind of thinking about dicking around with Rowley's stuff since it's not expensive for hobbyist versions, but quite frankly the demo kind of put me off. It's lacking some features that the nicer IDEs have. I guess you get what you pay for.

I'm fine with using Atmel Studio, it's just a little bloaty

# ? Nov 30, 2013 18:19

some kinda jackal: Feb 25, 2003; �
�

Hey gang. I bought a new car so I want to put a neat garage door opener in it. In true nerd fashion I want to DIY this. Obviously the programming aspect of it isn't difficult. It'll just be two uC's handshaking over some kind of wireless sensor network. That's kind of where I break down though. Xbee is definitely one way to do this, but Xbees seem to be kind of pricey per-unit. I was hoping to do this whole thing for under $20. Any recommendations for lower cost wireless UART communication? The range literally only has to be like 20 feet so I don't need anything super fancy. I just don't really know what my options are other than the Xbees I'm familiar with.

# ? Dec 5, 2013 04:12

Delta-Wye: Sep 29, 2005

Martytoof posted:

Hey gang. I bought a new car so I want to put a neat garage door opener in it. In true nerd fashion I want to DIY this. Obviously the programming aspect of it isn't difficult. It'll just be two uC's handshaking over some kind of wireless sensor network. That's kind of where I break down though. Xbee is definitely one way to do this, but Xbees seem to be kind of pricey per-unit. I was hoping to do this whole thing for under $20. Any recommendations for lower cost wireless UART communication? The range literally only has to be like 20 feet so I don't need anything super fancy. I just don't really know what my options are other than the Xbees I'm familiar with.

Sparkfun has a bunch of dumb wireless modules that may work for you. Are you thinking you'll need bidirectional communication?

# ? Dec 5, 2013 04:21

some kinda jackal: Feb 25, 2003; �
�

Delta-Wye posted:

Sparkfun has a bunch of dumb wireless modules that may work for you. Are you thinking you'll need bidirectional communication?

It's entirely possible that I won't. I haven't really put too much thought into the firmware yet. I can probably just have the remote provide a simple key to my base station that'll be wired up to my physical opener in the garage and the base station doesn't really need to respond back unless I plan to do something fancy like light an LED or something in the car. I'm sure for security I'll give it a little more thought than this but thanks for the suggestion!

edit: I might grab a few of these to play with: https://www.sparkfun.com/products/12031

some kinda jackal fucked around with this message at 04:33 on Dec 5, 2013

# ? Dec 5, 2013 04:24

Delta-Wye: Sep 29, 2005

Yeah, I think those look pretty nice for bidirectional comms. They look like they will need some configuration before they are ready to rock - do you have a library? If not, be aware you'll have to write a driver of some sort.

These would provide drop-in wireless, but are unidirectional and probably shittier in most other respects to be honest:

https://www.sparkfun.com/products/10532
https://www.sparkfun.com/products/10534

# ? Dec 5, 2013 06:41

Bad Munki: Nov 4, 2008; We're all mad here.

I bought a bag of these (not that exact auction or seller, but the same product, quantity, and price point):

http://www.ebay.com/itm/10pcs-NRF24...=item5d4551b2f2

I haven't gotten around to trying them out yet, but there are some good libraries for them and they might do what you want. And the price is hard to beat, a 10-pack for :10bux:

(or so) is pretty drat cheap, so you can put them in whatever else you want, too.

# ? Dec 5, 2013 15:32

carticket: Jun 28, 2005; white and gold.

So, lately I've been picking up VHDL and general techniques for making FPGAs do what you want. Given my entire background is in sequential execution of instructions, it's definitely interesting. Do you think there may be interest in a write up on parallels between the two and making the jump from software to HDL?

# ? Dec 5, 2013 15:35

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

Mr. Powers: That would definitely be very interesting. A lot of the existing stuff out there is geared toward EE types but there's surprisingly little that talks about things like "Know how you would do X in C? Well, in VHDL,"

# ? Dec 5, 2013 16:11

carticket: Jun 28, 2005; white and gold.

Sagacity posted:

Mr. Powers: That would definitely be very interesting. A lot of the existing stuff out there is geared toward EE types but there's surprisingly little that talks about things like "Know how you would do X in C? Well, in VHDL,"

Yeah, that's the trouble I've run into, although I have an EE background so it's not totally foreign, professionally I am a software engineer and the concepts are completely different. It helps having a team of FPGA guys at work to answer my questions.

# ? Dec 5, 2013 17:29

Delta-Wye: Sep 29, 2005

Bad Munki posted:

I bought a bag of these (not that exact auction or seller, but the same product, quantity, and price point):

http://www.ebay.com/itm/10pcs-NRF24...=item5d4551b2f2

I haven't gotten around to trying them out yet, but there are some good libraries for them and they might do what you want. And the price is hard to beat, a 10-pack for (or so) is pretty drat cheap, so you can put them in whatever else you want, too.

I've used nordic radios - I mostly didn't recommend them because I've never seen them that cheap. That's cheaper than the individual chips :catstare:

edit:

Sparkfun's done some neat things with Nordics:
https://www.sparkfun.com/news/729
https://www.sparkfun.com/tutorials/135

Admittedly, the radio is built into the hardware they're using on the second one.

s/car door/garage door/g

Delta-Wye fucked around with this message at 18:44 on Dec 5, 2013

# ? Dec 5, 2013 18:36

Bad Munki: Nov 4, 2008; We're all mad here.

Yay China. Of course, it's also possible I bought a handful of non-functional lumps of silicon and plastic. Maybe some day I'll check.

# ? Dec 5, 2013 18:38

Zuph: Jul 24, 2003; Zupht0r 6000 Turbo Type-R

Delta-Wye posted:

I've used nordic radios - I mostly didn't recommend them because I've never seen them that cheap. That's cheaper than the individual chips

I've used a bunch of these super cheap Chinese radios, and I've never had a problem. God knows how the make 'em that cheap, but they work.

# ? Dec 5, 2013 18:51

some kinda jackal: Feb 25, 2003; �
�

I can't say no to a $12 bag of chinese electronics. Ordered just for the hell of it :haw:

Thanks for the help guys. I'll look into libraries and such, but I won't mind if it's a complete DIY right down to the code

# ? Dec 5, 2013 19:44

Bad Munki: Nov 4, 2008; We're all mad here.

Yeah, that was exactly how it went for me, too. I was looking for something for a project I was mulling over, and thought, "Well, I'm nowhere near needing them, but some day I might, and it's only $12!" *click*

And I came across a pretty featureful arduino library for that chipset, supported a number of different network designs including mesh. Depending on your platform, you shouldn't have too much trouble.

# ? Dec 5, 2013 19:46

JawnV6: Jul 4, 2004; So hot ...

Mr. Powers posted:

Yeah, that's the trouble I've run into, although I have an EE background so it's not totally foreign, professionally I am a software engineer and the concepts are completely different. It helps having a team of FPGA guys at work to answer my questions.

I don't think you get any mileage out of trying to teach an HDL like it's C with some deltas. More likely to end up with someone stuck trying to make a recursive function work.

I know I'm veering into "uphill both ways" territory but I learned on a GUI and dagnabit that's good enough for everyone. You're describing how a circuit should be built, not creating a list of instructions.

# ? Dec 5, 2013 19:53

carticket: Jun 28, 2005; white and gold.

JawnV6 posted:

I don't think you get any mileage out of trying to teach an HDL like it's C with some deltas. More likely to end up with someone stuck trying to make a recursive function work.

I know I'm veering into "uphill both ways" territory but I learned on a GUI and dagnabit that's good enough for everyone. You're describing how a circuit should be built, not creating a list of instructions.

How complicated were you doing? I know someone who started to schematic capture, but if you're trying to do complicated things, that gets very uphill very fast. The project from college that I am attempting to tackle again is driving a VGA output that shows an analog click with the current time. I can't imagine trying to do that graphically.

# ? Dec 5, 2013 20:01

JawnV6: Jul 4, 2004; So hot ...

Right, I use a HDL for everything now. The biggest project I did purely by GUI was an embedded Tetris game, took a sega genesis controller and spit VGA out, stored the board in SRAM. But for learning purposes, telling everyone C is close will hamper more than help.

# ? Dec 5, 2013 20:05

Slanderer: May 6, 2007

Bad Munki posted:

Yeah, that was exactly how it went for me, too. I was looking for something for a project I was mulling over, and thought, "Well, I'm nowhere near needing them, but some day I might, and it's only $12!" *click*

And I came across a pretty featureful arduino library for that chipset, supported a number of different network designs including mesh. Depending on your platform, you shouldn't have too much trouble.

Jesus, I did the exact same thing months back. I just found them in a box of similarly cool components I've yet to do anything with.

Normally I feel back for wasting money on stuff that I can't see myself using anytime soon, but they were just so drat cheap.

# ? Dec 5, 2013 20:12

carticket: Jun 28, 2005; white and gold.

JawnV6 posted:

Right, I use a HDL for everything now. The biggest project I did purely by GUI was an embedded Tetris game, took a sega genesis controller and spit VGA out, stored the board in SRAM. But for learning purposes, telling everyone C is close will hamper more than help.

I didn't mean to suggest that they are similar, but there are some parallels in terms of design patterns. I.e. if you want to do x in C, you can do the same x in VHDL this way. That's what's been the most difficult for me. It would be geared towards people who have a software background and would help bridge the gap caused because they are so different. There are still skills that will apply in both, just differently.

Also, that is a ridiculous project to do graphically.

# ? Dec 5, 2013 20:14

Delta-Wye: Sep 29, 2005

Mr. Powers posted:

I didn't mean to suggest that they are similar, but there are some parallels in terms of design patterns. I.e. if you want to do x in C, you can do the same x in VHDL this way.

What kind of 'things' do you have in mind? I'm leaning towards JawnV6's opinion in general, but there may be some carry over I guess.

# ? Dec 5, 2013 20:31

JawnV6: Jul 4, 2004; So hot ...

Seconding the request for examples. Could also move discussion to the Verilog megathread.

Mr. Powers posted:

Also, that is a ridiculous project to do graphically.

It seemed about perfect for an undergraduate project on a team of two. Make a module for each cell, a module for each row, string a few of those together.

Then I got to watch as everyone who learned HDL's first go through a few rounds of "wait wait, I want to do it C-like!" until the differences finally sunk in. Starting from the C perspective seems like you'd just delay that learning and have a lot more stumbling along the way.

# ? Dec 5, 2013 20:39

carticket: Jun 28, 2005; white and gold.

OK, examples, and this is an incredibly simple lab I did where it was specifically done through software and then in an FPGA: blinking a LED.

You want to blink an LED on your micro. If that's all you're doing you can just use a timer and watch the value. From the count you can decide if the LED should be on or not. It's very simple code even if you didn't have a timer and just counted yourself.

Now you want to do it in your FPGA. You don't have a timer peripheral, you've just got a clock. Your LED output code will appear superficially similar to the C code in that you will decide the state of the output based on the counter's value, but you also have the process to handle counting clocks.

It's an overly simple example, I know, but of I were putting time into it, I would continue building the example to more complex systems. It's not about saying "here is C code and here is how to do it in VHDL", but to say "here is something you want to do, and here is how you might do it in C. This is how you could do the same thing in VHDL and I'm explaining why it I'd done this way." It would help people like me get over the first hurdles of going from a software background into FPGA design.

Really I just find the information out there to be overly simple (here's how to make a 3-input AND), lacking on practical examples (here's a list of all the syntactic structures of the language) or lacking explanation (here's a complicated design I did this way but I'm not telling you why).

I figure if I document my learning, I can go back and revise when I have an Aha! moment down the road. Most of what I have come across is written by an expert that has probably forgotten what it was like when they first learned.

Going the route of "I'm designing a circuit"is great for people who have circuits/logic background, but it's a completely new skill for software guys. If you tailor the material to someone with software background, you can leverage skills they have and teach the skills that are missing.

Edit: I think this is an appropriate thread since posters in this thread who want to jump into HDLs would really be the target audience. Although, arguing about whether it's C-like doesn't really belong anywhere since we're pretty much in agreement that it is not. If you want more examples then it's really just a matter of me actually following through and writing stuff up, since the learning is still an ongoing process for me.

carticket fucked around with this message at 21:08 on Dec 5, 2013

# ? Dec 5, 2013 21:04

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

I found hdl to be superficially like writing frp code but I only made LEDs blink so I don't know how generalizable that is

Fwiw conal Elliot, the arrowized frp guy now does work for an fpga company and arrows are very good at describing frp so maybe there's something useful there

# ? Dec 5, 2013 23:44

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

I'm working on a board with arm-linux, so I thought I might share today's debugging process. While the kernel running on a quadcore arm chips is a bit more than most embedded projects, debugging it is fundamentally the same as a 4k embedded part, as opposed to debugging an application running on a full OS.

Oops posted:

Unable to handle kernel NULL pointer dereference at virtual address 000000a0
...
r3 : 00000001 r2 : bff8be40 r1 : bfe74a08 r0 : 000000a0
...
[<805168cc>] (__raw_spin_lock+0x24/0xa8) from [<80295688>] (get_device_parent+0x5)
[<80295688>] (get_device_parent+0x50/0x1a0) from [<80296698>] (device_add+0x94/0x)
[<80296698>] (device_add+0x94/0x56c) from [<80296c28>] (device_create_vargs+0xa0/)
[<80296c28>] (device_create_vargs+0xa0/0xd0) from [<80296c78>] (device_create+0x2)
[<80296c78>] (device_create+0x20/0x28) from [<802498cc>] (pwmchip_sysfs_export+0x)
[<802498cc>] (pwmchip_sysfs_export+0x4c/0x80) from [<802490f8>] (pwmchip_add+0x17)

I'm backporting the modern PWM infrastructure to the vendor kernel from 2011.

I used git cherry-pick to apply the driver patch-by-patch, cleaning up merge errors. The main problem was the expectation that the modern DeviceTree would exist, which of course it didn't back then. (I loathe vendors being consistently 3+ years behind mainline development) Once merged, I have a nice clean git history with the PWM core + sysfs changes. Builds, but I got the above trace at boot.

To fix a bug like this, you have to really understand why it happened. The information in the linux oops is the same as you'd get with a hardware debugger and reading the stacktrace by hand.

__raw_spin_lock takes one argument, and on ARM the first few arguments are passed in r0..r3, so since r0 is 0x0a0 we can guess that it was passed that. On to the next frame.

device_add_parent seems to be the culprit, so we find where it called the spinlock from.

C++ code:

         /* find our class-directory at the parent and reference it */
         spin_lock(&dev->class->p->glue_dirs.list_lock);

Because it's address 0xa0, it's the offset into a structure - so class->p is null.

So the origin of the bug is in the setter of dev->class->p, time to find them. First stop, where does dev->class come from? dev is passed into device_add_parent from device_add, which doesn't set class. It's passed in from device_create_vargs(struct class *, ...) which creates the device structure and sets class from the argument.

device_create is just a wrapper around _vargs, so the origin dev->class is pwmchip_sysfs_export(&pwm_class, ...) - but wait, a serendipitous comment on device_create_vargs():

quote:

* Note: the struct class passed to this function must have previously
* been created with a call to class_create().

Looking up class_create, it doesn't set ->p, but class_register() does, and in fact is the only place where ->p is set. So, armed with this, let's investigate pwmchip_sysfs_export().

C++ code:

static struct class pwm_class = {
        .name           = "pwm",
        .owner          = THIS_MODULE,
        .dev_attrs      = pwm_chip_attrs,
};
/* ... */
        parent = device_create(&pwm_class, chip->dev, MKDEV(0, 0), chip,
                               "pwmchip%d", chip->base);

no .p being set, but:

C++ code:

static int __init pwm_sysfs_init(void)
{
        return class_register(&pwm_class);
}
subsys_initcall(pwm_sysfs_init);

So now we can put the pieces together: pwmchip_sysfs_export is being called before sysfs_init.

First, fix the crash:

C++ code:

       /* Platform PWM chips show up before sysfs is ready, we get them
           later in pwm_sysfs_init() */

        if (!pwm_class.p)
                return;

if I leave it like that, it will boot but my PWMs won't show up properly. So after looking at the way some other systems did it, I added some code to pwm_sysfs_init:

C++ code:

        int status;
        struct pwm_chip *chip;

        status = class_register(&pwm_class);
        if (status < 0)
                return status;

        mutex_lock(&pwm_lock);

        list_for_each_entry(chip, &pwm_chips, list) {
                pwmchip_sysfs_export(chip);
        }
	mutex_unlock(&pwm_lock);

Compile, copy to flash, boot:

pre:

root@192:/sys/class/pwm/pwmchip0/pwm0# ls -l
total 0
-rw-r--r-- 1 root root 4096 Dec  6 03:23 duty_cycle
-rw-r--r-- 1 root root 4096 Dec  6 03:23 enable
-rw-r--r-- 1 root root 4096 Dec  6 03:23 period
-rw-r--r-- 1 root root 4096 Dec  6 03:23 polarity
drwxr-xr-x 2 root root    0 Dec  6 03:23 power
-rw-r--r-- 1 root root 4096 Dec  6 03:23 uevent

If I had to hazard a guess as to why this works on newer kernels, it's that they've moved the platform hardware into DeviceTree and that initializes after sysfs does.

One failed boot, some detective work, one patch, working boot. I can feel confident that I'm not just covering over a problem, because I've got a good understanding of the origin.

Main tools in this were git grep and a textfile where I kept notes. LXR was useful for tracing functions through macros and grabbing structure layouts, but unfortunately when dealing with "class" and "p" it's not type-aware and can't follow them properly.

# ? Dec 6, 2013 04:38

movax: Aug 30, 2008

~~You've got a LXR setup for your source tree(s), right?~~

e: gently caress me it's late and I can't read. I had do similar stuff, backporting a lot of newer features (PCI Express related mostly) into a 2.7.x-something kernel. At least it was x86, which made life a little bit easier.

# ? Dec 7, 2013 04:54

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

I got my Raspberry Pi the other day and have it running chaser lights now. I figured it was a nice board for writing quick-and-dirty stuff using common tools and powerful languages; I am just too lazy to pick up another ISA, and spend a bunch of time enabling hardware registers and crap rather than doing whatever. Actually my wife just wants me to do some microcontroller things for her for Instructables and whatnot, and I figured I could quickly humor her this way. The big problem I see is with the analog-digital disconnect. There aren't any DACs or ADCs for it. I was wondering what's the, well, laziest way I can get a pile of them on standby for screwing around. I saw this gertboard idea for having a bunch of I/O available:

http://www.element14.com/community/docs/DOC-51726/l/assembled-gertboard-for-raspberry-pi

That was close, but they only had two channels for DACs and ADCs. For whatever reason, the stuff my wife always asks about is the kind of thing that needs, like 8 of them or something else normally excessive. In that spirit I found this:

http://www.abelectronics.co.uk/products/3/Raspberry-Pi/17/

But that's just ADCs. Does anybody know of something for the Raspberry Pi readily available for going DAC/ADC crazy with some other bonus I/O?

# ? Dec 7, 2013 23:09

ante: Apr 9, 2005; SUNSHINE AND RAINBOWS

You don't need to be searching for Raspberry Pi specific boards. Anything designed for hobbiests (mostly Arduino stuff) will work pretty well with I2C libraries using the GPIO.

Something like:
http://www.adafruit.com/products/1083

http://www.adafruit.com/products/935

That's with like two minutes of searching, I'm sure you can find combination boards (for waaay cheaper than that gertboard) from your preferred suppliers.

# ? Dec 7, 2013 23:19

Tiger.Bomb: Jan 22, 2012

Harik posted:

I'm working on a board with arm-linux, so I thought I might share today's debugging process. While the kernel running on a quadcore arm chips is a bit more than most embedded projects, debugging it is fundamentally the same as a 4k embedded part, as opposed to debugging an application running on a full OS.

I'm backporting the modern PWM infrastructure to the vendor kernel from 2011.

I used git cherry-pick to apply the driver patch-by-patch, cleaning up merge errors. The main problem was the expectation that the modern DeviceTree would exist, which of course it didn't back then. (I loathe vendors being consistently 3+ years behind mainline development) Once merged, I have a nice clean git history with the PWM core + sysfs changes. Builds, but I got the above trace at boot.

To fix a bug like this, you have to really understand why it happened. The information in the linux oops is the same as you'd get with a hardware debugger and reading the stacktrace by hand.

__raw_spin_lock takes one argument, and on ARM the first few arguments are passed in r0..r3, so since r0 is 0x0a0 we can guess that it was passed that. On to the next frame.

device_add_parent seems to be the culprit, so we find where it called the spinlock from.
C++ code:
         /* find our class-directory at the parent and reference it */
         spin_lock(&dev->class->p->glue_dirs.list_lock);
Because it's address 0xa0, it's the offset into a structure - so class->p is null.

So the origin of the bug is in the setter of dev->class->p, time to find them. First stop, where does dev->class come from? dev is passed into device_add_parent from device_add, which doesn't set class. It's passed in from device_create_vargs(struct class *, ...) which creates the device structure and sets class from the argument.

device_create is just a wrapper around _vargs, so the origin dev->class is pwmchip_sysfs_export(&pwm_class, ...) - but wait, a serendipitous comment on device_create_vargs():

Looking up class_create, it doesn't set ->p, but class_register() does, and in fact is the only place where ->p is set. So, armed with this, let's investigate pwmchip_sysfs_export().
C++ code:
static struct class pwm_class = {
        .name           = "pwm",
        .owner          = THIS_MODULE,
        .dev_attrs      = pwm_chip_attrs,
};
/* ... */
        parent = device_create(&pwm_class, chip->dev, MKDEV(0, 0), chip,
                               "pwmchip%d", chip->base);
no .p being set, but:
C++ code:
static int __init pwm_sysfs_init(void)
{
        return class_register(&pwm_class);
}
subsys_initcall(pwm_sysfs_init);
So now we can put the pieces together: pwmchip_sysfs_export is being called before sysfs_init.

First, fix the crash:
C++ code:
       /* Platform PWM chips show up before sysfs is ready, we get them
           later in pwm_sysfs_init() */

        if (!pwm_class.p)
                return;
if I leave it like that, it will boot but my PWMs won't show up properly. So after looking at the way some other systems did it, I added some code to pwm_sysfs_init:
C++ code:
        int status;
        struct pwm_chip *chip;

        status = class_register(&pwm_class);
        if (status < 0)
                return status;

        mutex_lock(&pwm_lock);

        list_for_each_entry(chip, &pwm_chips, list) {
                pwmchip_sysfs_export(chip);
        }
	mutex_unlock(&pwm_lock);
Compile, copy to flash, boot:
pre:
root@192:/sys/class/pwm/pwmchip0/pwm0# ls -l
total 0
-rw-r--r-- 1 root root 4096 Dec  6 03:23 duty_cycle
-rw-r--r-- 1 root root 4096 Dec  6 03:23 enable
-rw-r--r-- 1 root root 4096 Dec  6 03:23 period
-rw-r--r-- 1 root root 4096 Dec  6 03:23 polarity
drwxr-xr-x 2 root root    0 Dec  6 03:23 power
-rw-r--r-- 1 root root 4096 Dec  6 03:23 uevent
If I had to hazard a guess as to why this works on newer kernels, it's that they've moved the platform hardware into DeviceTree and that initializes after sysfs does.

One failed boot, some detective work, one patch, working boot. I can feel confident that I'm not just covering over a problem, because I've got a good understanding of the origin.

Main tools in this were git grep and a textfile where I kept notes. LXR was useful for tracing functions through macros and grabbing structure layouts, but unfortunately when dealing with "class" and "p" it's not type-aware and can't follow them properly.

Ugh flash backs of my work week.

# ? Dec 8, 2013 22:57

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 17:03

ante: Apr 9, 2005; SUNSHINE AND RAINBOWS

That was demystifying and good. I liked that writeup.

# ? Dec 8, 2013 23:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »