JawnV6 posted:Sorry, I don't mean to sound so snippy. Well, you're still being snippy 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:
code:
code:
code:
code:
In the interest of full disclosure, I was one of the printf debuggers for far too long
|
|
# ? Nov 16, 2013 22:35 |
|
|
# ? Jun 5, 2024 05:12 |
|
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 |
|
Has anyone used NXP Cortex M0/3/4 chips, and their LPCOpen library?
|
# ? Nov 22, 2013 01:53 |
|
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 |
|
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 |
|
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? 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 |
|
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 |
Yeah, it's no fun using multiple platforms of EW. Also EWARM is the only one that sounds cool.
|
|
# ? Nov 30, 2013 00:52 |
|
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 |
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 |
|
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 |
|
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 . 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 |
|
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 |
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 |
|
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 |
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 |
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.
|
|
# ? Dec 5, 2013 15:32 |
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 |
|
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 |
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 |
Bad Munki posted:I bought a bag of these (not that exact auction or seller, but the same product, quantity, and price point): 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 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 |
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 |
|
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 |
|
I can't say no to a $12 bag of chinese electronics. Ordered just for the hell of it 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 |
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 |
|
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 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 |
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. 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 |
|
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 |
|
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* 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 |
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 |
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 |
|
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. 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 |
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 |
|
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 |
|
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 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:
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 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:
C++ code:
First, fix the crash: C++ code:
C++ code:
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 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 |
|
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 |
|
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 |
|
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 |
|
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. Ugh flash backs of my work week.
|
# ? Dec 8, 2013 22:57 |
|
|
# ? Jun 5, 2024 05:12 |
|
That was demystifying and good. I liked that writeup.
|
# ? Dec 8, 2013 23:03 |