64K is still quite a lot! Embedded Programming Microthread

Victor · Victor Jun 18, 2004

I'm looking into the STM32F4x5/4x7 series (DigiKey overview) for quadcopter (actually, hexacopter but whatever) development. The STM32F4DISCOVERY is only $15. I'll likely go with the 4x7, so I can hook the EMAC up to a ethernet-wifi bridge. Glancing at Wikipedia's STM32 page, it seems like it might be reasonable to do development on OSX. I found someone who is developing the F4 under Ubuntu (except for flashing), and here's a nice F4 under OSX tutorial. I have a Windows VM set up, but I'd rather not have to use it. This looks promising: http://dangerousprototypes.com/tag/stm32f4/ .

Martytoof posted:

I still swear that when I get halfway decent at this I am going to write some sort of "How to get into ARM development for beginners" website. At least for people who don't use the standard Windows tools.

If I go the STM32 route, I'd be happy to contribute to this, at least if F3 development is sufficiently similar to F4 development. I've only ever used Atmel Mega8 and Mega2560 chips, unless you could the ancient 8086 from a uni embedded class. :-) If I move to ARM, I can become a big boy.

Adbot · # ¿ Apr 28, 2024 07:32

Victor · Victor Jun 18, 2004

movax posted:

There's no nerdcred to it, I use Windows for everything because the manufacturers support it, I've been using it for probably 15 years now, and oh yeah, I pretty much never have to gently caress with anything to get a toolchain up and running.

Yeah it's cool for stuff to run on other OSes, but to be honest, I'd rather the companies continue to invest their time and money into improving and perfecting their tools for one OS. They cater to corporations, not hobbyists, and for the most part it's Windows workstations with perhaps some Linux servers doing X11 forwarding for some high-end Cadence/Mentor simulation packages.

I have two objections, one of which is somewhat alleviated by PowerShell: the Windows shell sucks. Some things fit IDEs well, but some things really just don't. Second: package manager? Hello? Note that I used 100% Windows up until two years ago; I first transitioned to OSX because of work, then treated myself to a Retina MBP.

Victor · Victor Jun 18, 2004

movax posted:

I'm not sure what you mean about package management though?

I can do sudo port install mmv to get the multiple-file renaming tool called mmv. So if someone tells me about mmv, I can have the installation process started in seconds. I don't have to navigate to a website, find the downloads page, find the right one for my OS, download it, run it, click through a EULA, etc. Uninstalling it is as simple as sudo port uninstall mvv. Oh, and package managers take care of dependencies.

movax posted:

To remain tangentially on topic though, it seems like AVR enjoys a large amount of cross-platform support, and a vast amount of that is open-source or at least free. Microchip's now cross-platform, but it's all closed-source and proprietary from Microchip (which I'm cool with, but others may not be). Seems like ARM varies based on the specific implementation though.

I think Atmel is trying to get people away from the ATmega series, though. For example, the ATmega2560 is ($17.97, $10.03) from digikey, while the STM42F407 is ($12.78, $9.88, $6.97) from digikey (qty 1, qty 100, qty 10,000). The former is an 8-bit 16MHz chip with 8K SRAM and no FPU, while the latter is a 32-bit 168MHz ARM with 196K SRAM, FPU, USB, Ethernet, RTC, DMA, SDIO, up to 17 timers, etc. Hmmm, perhaps a better comparison would be to Atmel's ATSAM3X8CA-AU, which is ($10.92, $6.10) from digikey. 32-bit, 84 MHz, no FPU still, but Ethernet, USB, 96K SRAM, etc.

I don't really feel like looking for competitors to Atmel's smaller chips, like the ATmega8A. Well, maybe not. The cheapest XMega is ($2.39, $1.33) from digikey while the cheapest ATmega8A is ($3.21, $1.79) from digikey. I'm pretty sure that XMega is better than the ATmega8A in pretty much every way, except that it has 44 pins instead of 32.

Victor · Victor Jun 18, 2004

Within the last few months, I read that at least some SPI slaves rely on an SS pin transition. I haven't looked at the state machines in particular, though.

Victor · Victor Jun 18, 2004

Martytoof, you might look for an SPI device that demuxes the last 8-bit (well, 2–4-bit) value it received onto 4-16 pins, making them the inverse of SS. Surely something like this exists, for pin-starved MPU designs.

Victor · Victor Jun 18, 2004

Martytoof posted:

Can someone help me understand how to choose a prescaler for a timer?

Do you want to count past the max value of the timer? Higher prescalars = longer time intervals that can be used without having to maintain additional bits of timer value somewhere else (which you'd update on timer overflows).

Victor · Victor Jun 18, 2004

Martytoof posted:

is it a "balance power draw and necessary speed" sort of situation?

Power might be a huge consideration. A lot of power is used to switch a transistor, vs. just let it stay at whatever level it's at. If you're running on a battery, or just want to be green, you care about this stuff. But having to care about this stuff is annoying, so most people don't unless they're forced to.

Victor · Victor Jun 18, 2004

Arcsech posted:

DO NOT use an Arduino if you're attempting to get an embedded systems job, you will be laughed at all the way to the door. Right or wrong, the Arduino has a rep for being nothing but a kid's toy but the MSP430 line are some pretty commonly used microcontrollers, and of course ARM is beefy as hell (for a uC).

Heh, at my job we're switching away from an Arduino Mega to our own board with an STM32F4xx chip for our quadcopter flight board. I think a few questions could easily winnow the ranks of applicants. For example, ask them if they like the IDE (correct answer is it's nice for simple stuff and ridiculous for anything non-simple), if they like the TWI library (correct answer is it's nice for simple stuff but horrible for robustness), etc.

Sinestro posted:

I didn't know they did. You have made me work on my UAV for the first time in weeks because comms code was sucking the life out of me.

How are you liking Google protocol buffers on embedded devices, so far? I have to do the same thing at work for our quadcopter. We're using AeroQuad code now and it's... not as robust as what we'd like. (I probably ought to be politically correct.)

Victor · Victor Jun 18, 2004

movax posted:

As anyone who has read my posts knows I've kind of got a little hatred for the Arduino, but even putting that aside, I can quickly knock out applicants by asking them to do bitwise operations in C / write a sample ISR during interviews. I don't mind reminding them of the syntax or anything like that, but some people can't even grasp the concept of bitwise operations or architecting an ISR without function calls. When I inquired a bit further, well, there are apparently communities out there convincing people that Arduino skills make you an embedded wizard and the rest of us wasted our time/money in school/elsewhere acquiring our skills.

Heh, sounds like you've found good embedded FizzBuzz tests. My preferred method of expressing disapproval of said Arduino folks is to point out where Arduino fails. For example, the Arduino TWI library is not fault tolerant, and can block one's program forever. My boss and I are in the process of writing robust, asynchronous TWI interfaces, although they may become unnecessary if the STM32F4xx TWI interface is sufficiently different. Another example of where Arduino will never be ready for prime-time is that they don't trust users to handle serial data ready ISRs. I suppose I could get jaded though, and resort to the easier criticisms. I endeavor not to, though! :v:

On the other hand, I hugely approve of the Arduino because it Just Works. I dunno how many other dev platforms do. It doesn't take many bits of configuration before it is extremely hard to track down why things aren't working and frustrate the hell out of someone who isn't already fantastic at troubleshooting. I got bitten the other day by a broken makefile, which didn't have dependencies set up properly and thus wasn't recompiling enough. I kept making code changes and the problem didn't get fixed! I know what it's like to experience that problem without the expertise I have now; I would often switch from doing digital electronics to computer games in high school because getting things to work was so insanely frustrating. I still made stuff like a graphical LCD I could write to with a VB mspaint-like program over the parallel port (later a countdown timer to when my new girlfriend would fly across the country to my senior prom, using Windows fonts), but I missed out on a lot because of how much of a pain in the rear end things were for someone without a mentor.

Someday, maybe I'll be part of making something Arduino-like, which combines Just Working with solid coding practices. I wanted to do that in college (around the time Arduino started up in fact) but other people were too busy. :-/ It seems like the people who know how to design and code really well don't have time for hobbyists. :smith:

Victor · Victor Jun 18, 2004

Otto Skorzeny posted:

The arduino libraries aren't the only bad I2C routines out there.

If you're commenting on the version I helped write, criticism is more than welcome. I don't have much experience writing robust embedded code. If you're not, then yes, there is that pesky 80/20 rule.

Victor · Victor Jun 18, 2004

Otto Skorzeny posted:

Haven't seen your code. Hope it's good. I2C is simple enough but it gets screwed up often. My recommendation is that you provide versions of your functions with specified timeouts.

Yep, there are timeouts. They aren't implemented in a portable fashion yet. More eyes make for better code, though!

movax posted:

Everyone reinvents I2C libraries all the time, and some of the app notes companies put out have sample routines that aren't entirely production-level robust. IMO more companies should be putting out "offical" software libs / "extensive samples" for use by their customers. It can't take much more than 1 or 2 Sr. SW engineers + a week or two to release (even warranty-less) well-written, solid, interrupt-driven serial comm code for SPI/I2C and friends.

Hahahaha this is so true. I wrote the below:

ASHIMA.md posted:

embedded-atmel-twi is a robust driver module for Atmel's Two Wire Interface (I2C) on Atmel's AVR ATmega chips. It includes handling for bus errors not documented in Atmel's TWI slave and master Application Notes (the flowcharts are incorrect), and implemented in the slave code but not the master code. The Master driver can operate in a synchronous or queued asynchronous mode. The slave implemented so far implements a multi-byte memory interface.

That's right, Atmel's TWI master application note has it handling bus errors in a way that will stall the I2C bus if not all execution. :doh:

Victor · Victor Jun 18, 2004

STM32F4xx goons: Would you care to describe your experience so far with the STM32F4xx?

Getting started with the STM32F4xx has been a bit of a nightmare. First, STMicroelectronics seems to like creating lots of dead hyperlinks and other things; see this funny/sad account for some details. It seems like they just don't care about enabling startups to quickly and cheaply get up to speed on their chips.

There are bugs in their peripheral libraries, like what is bit-banded and where certain things are bit-banded to.
There is no mature I2C library. Seriously?
There are no makefiles and source files are copied all over the place in their code downloads. Sucks to be you if you don't want to pony up for an IDE.
They can't do something as simple as provide a minimal program that blinks a user-specified LED�you know, the embedded version of "Hello, World!"

I could go on.

Then there's programming the thing. dfu-util works just fine if you boot up with the manufacturer firmware (set via BOOT0,1), but things aren't so simple when using ST-LINK2. If you install openocd from Macports, you must specify the +stlink variant. Next, to properly flash the chip you apparently have to issue reset halt; if you don't, random flash locations (where the PC is? I didn't have the patience to check) wouldn't program. If you want to use gdb, note that it won't set breakpoints until you set "set breakpoint always-inserted", even if gdb is aware of hardware breakpoints. Yeah, you have to tell gdb, "no, really, when I say insert a breakpoint, I actually want you to INSERT A BREAKPOINT".

At several points, once I figured out something I up and left work because I was so frustrated and was just happy I accomplished a single thing that day. Now, I don't have a ton of embedded experience; I had only used ATmega 8-bit AVR chips before (excepting a bit of FPGA dabbling). I actually started on them before Arduino came out, so I've used them both in Arduino form and non-Arduino form. But good grief, perhaps people could make things a bit easier to get started quickly and be off to the races?

I propose an information exchange about the STM32F4xx series. We can probably include the other STM32's due to the amount of similarity. For example:

frankvh.com's STM32 Information: he has a bunch of overview stuff plus discussion of DMA, SDIO, how to extract the relevant information from HardFaults, etc.
GNU Tools for ARM Embedded Processors: this is probably the toolchain you should be using if you aren't going to pay megabucks for an IDE other than Eclipse. "ARM employees are maintaining this project." Probably enough said... although they do hardcode references to /Library/.../Python2.7 on the OSX version�so much for people who like to use package managers! I gave up and installed Python2.7 on my OSX 10.6.8 machine.
Get started with STM32F4 on Ubuntu Linux: the STM32F4_Sample code download on this page was the most reliable, makes-from-the-getgo project I could find. It has some issues (like duplicate files and vpathing everything), but it works and isn't too unwieldy for getting started. I didn't make use of anything else in that blog post other than the code. Unfortunately, the code does not appear to available from any public versioning system.
Writing a minimal C program for the STM32 Primer: this is a minimal program, linker script, gcc/ld invocation, plus an explanation of what the disassembly and binary dump of the firmware binary should look like. That was a life saver; plenty attempts couldn't get the two words of the firmware binary correct and I could know that with a quick od -x invocation.
Programming STM32 F2, F4 ARMs under Linux: A Tutorial from Scratch: another minimal program tutorial, its C code and linker script are very readable.
Use some distributed source control client when trying to figure poo poo out. Commit often, including when things are broken. Use good commit messages. This kept me sane at several points. I think I'm glad that repo is only on my machine (plus backups that will hopefully never see the light of day).

What have you guys got to add? Any good I2C, USART, or SPI libraries? Any experience with libopencm3, for example?

Victor fucked around with this message at 18:50 on Mar 23, 2013

Victor · Victor Jun 18, 2004

evensevenone posted:

There's also this but I'm not sure what I'd be giving up.

I think the STM32F3xx doesn't have any DSP instructions; it definitely doesn't have hardware floating point. If neither of these matters to you, then just compare the peripherals. If you find a neat way to do so, please post it. ST doesn't seem interested in making such things easy.

Victor · Victor Jun 18, 2004

Otto Skorzeny posted:

Who gave you the george clooney avatar, Victor?

Heh, someone who doesn't like how I debate in D&D and/or that I insist on empirical evidence and peer-reviewed articles. I'm happy to get matching donations to SA. People rarely own up to my custom titles; I don't know who it was this time.

Victor · Victor Jun 18, 2004

The startup I work for recently made a Kickstarter project called 'AshimaCore':

AshimaCore can be seen three ways:

an avionics package for multirotors (I always link hunting hydrogen balloons with fireworks for those unfamiliar with multirotors)
an IMU/dev platform for the MPU-9150 (manufacturer, SparkFun) 9-axis sensor
a dev platform for the STM32F405/7

Its primary purpose is to be an avionics package for multirotors we plan to build. However, dev boards for the MPU-9150 are notoriously hard to get and... $80. Whereas our kickstarter starts at $129 and includes a capable microcontroller, wireless-readiness, and a �SD slot. The small size and 2-layer design accounts for the small numbers of pinouts compared to, e.g. the STM32F4DISCOVERY, which is ST's $15 dev board. Here's a quick rundown of the features:

STM32F405/7 168 MHz, 32-bit ARM chip with FPU and a few DSP instructions (as well as lots of peripherals)
MPU-9150 9-axis (accel, gyro, mag) sensor in a 4x4x1mm LGA package (I would call it a QFN myself)
XBee-compatible socket, which can support a Digi XBee module or one of many pin-compatible products; you can get WiFi, 802.15.4, ZigBee, Bluetooth, mesh, and even the simultaneously-launched ExtraBee Open-Source Radio Module Kickstarter. We hook up both the UART and SPI; you can get 3.5Mbps with Digi's WiFi modules via SPI.
�SD slot, connected via high-speed 4-bit SDIO, which the microcontroller supports, including DMA
BMP180 pressure sensor
1W audio amp
detachable power board supplying 3.3V and 5V via DC-DC converters which can take 6-20V
5V tolerant I/O
28 pins routed from the MCU
programmable via USB�no external programmer required
hardware debugging is possible with ST's $15 dev board
software can be developed and firmware programmed on OSX, Windows, and Linux

In addition to the hardware, we're writing an open-source peripherals library. Before you go all not-invented-here on that, note that ST's license prohibits open-sourcing code using it. While it's not clear that they would ever enforce this [insane] license, we'd rather not risk it. Another reason to write our own library was to take advantage of C++ features that reduce the kinds of bugs one can commit. One really cool thing that we do is derive as much of the peripherals library as we can from ST's documentation itself. For example, this involved OCRing the datasheet. This both ensures we get stuff right, and it makes it easier to see where in the datasheet we get various bits. Trust me when I say that ST's datasheets aren't always the easiest to navigate! For example, we made our own clock tree diagrams, after getting frustrated about how the relevant information was scattered around ST's documentation like shrapnel.

As I briefly mentioned above, an ultimate goal of my startup is to design a hexacopter 'puck'. Here's a picture of the puck, as well as the puck next to our existing quadrotor:

We decided that it would be a good idea to first release the avionics board that we'll be using for a hexacopter precursor to the puck. We looked around for sub-$200 IMUs and didn't find much that was good. There's a $125 IMU from SparkFun, but it has a 16MHz, 8-bit processor with no FPU. If you want logging or wireless ability, you'll be spending more. We give you the sensor + hefty MCU + �SD slot for $129, and adding WiFi is $35. If our board becomes popular enough to hit 1000 units, that $129 price could drop appreciably as well.

Ok this seems very sales-pitchy so far. First, I'm excited about providing a cheap IMU that has a sufficiently beefy processor to do high quality state estimation with plenty of cycles to spare. Second, I'm excited about fostering a community around the STM32F4xx processors, analogous to Arduino but appealing to people willing to write more rigorous code and get the advantages that come with more powerful libraries. Arduino, for example, doesn't have an asynchronous I2C library and it only recently added asynchronous UART. Third, I look forward to helping write open-source multicopter code under a non-GPL license (so far we've settled on MIT Expat) that can assume a hefty microcontroller, and benefit from a few years' experience with writing multicopter code. I don't want to come down too hard on what's out there, but let's just say that the code has a long history of evolving from something simple; cruft inevitably accumulates, especially when nobody is being paid full-time to work on the code base. Finally, I look forward to using C++11 in an embedded context, from the libraries on up. Certain bugs just won't be possible, and one gets benefits like lambda functions.

If anyone here wants to pledge to the Kickstarter, that'd clearly be awesome, but I'd also appreciate comments and suggestions. Any funds go to support a company committed to open-sourcing much of what they do. (We may not open-source our IMU code, because we need to make a profit somehow and a services-only model isn't guaranteed to work, here. Others would be welcome to write their own IMU code, of course.) It would be neat if there could be one more success story of a company which open-sourced much of what it did, proving that this is a viable model. Stuff that you can build with IMUs is also freaking cool, whether it's a multicopter or something else.

_{^{_{Note on ST hyperlinks: ST likes to change their URL structure a lot, so please let me know if they break.}}}

Victor · Victor Jun 18, 2004

Delta-Wye posted:

So... "please buy our IMU, oh and no, we won't give you the IMU software to make it work"?

No, we might not open-source the actual state estimation code. You'd get object files. The reason we wouldn't be open-sourcing it is that it's using advanced math that not very many people know, we've spent several months on it. I'm trying to be up-front about things instead of hide them.

Edit: asking a company to open-source everything it does isn't always a practical thing. Not everyone can work on a pure-services basis.

Victor · Victor Jun 18, 2004

movax posted:

Question re: IMU board, is that a 2-layer PCB still?

Yep. We're pretty proud of accomplishing that.

quote:

And re: AVR Studio, fuckin' ugh. Wasted like four hours of life trying to use it to flash some chips via ISP, and it just kept loving it up. Some cobbled-together version of avrdude + libusb managed to get the job done with no issues whatsoever. And that doesn't include the time it took to find some F/F jumpers and get the AVR Dragon rigged up for HVSP to un-gently caress bogus fuse settings AVR Studio wrote (bonus: unless I'm missing something, the current version of Studio is bugged and can't flash program code using HVSP, just fuses). I'm really beginning to hate everything remotely related to Atmel and the AVR. PICs 4 Lyfe

My last experience with AVR Studio was in 2003; it worked then, but a lot can change in ten years. Have you had issues using GCC tools and avrdude, or do you just prefer an IDE?

Martytoof posted:

Probably a really frowned-upon opinion, but I'm starting to think everything I need to do I can just do on an arduino because I'm way too impatient to do low level stuff these days.

I'm actually kind of looking forward to this thing: http://www.sparkdevices.com/. Cortex M3 Arduino + WiFi onboard. Use Wiring or use the JTAG headers to write low level stuff to the chip.

Hey that's a pretty cool Kickstarter. I don't know why yours should be a frowned-upon opinion; why must you become a microcontroller whiz and be able to design PCBs in your sleep?

Victor · Victor Jun 18, 2004

Martytoof posted:

Yeah I tried to not link directly to the kickstarter to avoid clashing with your project, but it's the perfect board for my little pet project (basically a clone of the Budweiser goal light). Will let me hop on the nearest wifi, and I'll just hook up an SD card to store the goal horn audio. All I have to do is write the parser to scrape the actual scores from an online source, which will likely run on an endpoint at my house anyway.

No worries about competition; the Spark Core board is awesome. They're going to make a killing as well, given that they'll be able to buy at least an order of magnitude more components and reap the economies of scale that come with that. The iffiest part might be the range on the wireless unit, given the mini antenna. I wonder how much buy-in they got from claiming Arduino compatibility.

Victor · Victor Jun 18, 2004

Victor posted:

Ok this seems very sales-pitchy so far. First, I'm excited about providing a cheap IMU that has a sufficiently beefy processor to do high quality state estimation with plenty of cycles to spare. Second, I'm excited about fostering a community around the STM32F4xx processors, analogous to Arduino but appealing to people willing to write more rigorous code and get the advantages that come with more powerful libraries. Arduino, for example, doesn't have an asynchronous I2C library and it only recently added asynchronous UART. Third, I look forward to helping write open-source multicopter code under a non-GPL license (so far we've settled on MIT Expat) that can assume a hefty microcontroller, and benefit from a few years' experience with writing multicopter code. I don't want to come down too hard on what's out there, but let's just say that the code has a long history of evolving from something simple; cruft inevitably accumulates, especially when nobody is being paid full-time to work on the code base. Finally, I look forward to using C++11 in an embedded context, from the libraries on up. Certain bugs just won't be possible, and one gets benefits like lambda functions.

Is anyone here actually interested in any of the above? There has been a bit of Arduino-dissing in this thread, but do you guys have a sense of how much people run into its limitations? I'm primarily talking about A) limitation of 16MHz, 8-bit, no FPU; B) libraries that are designed specifically for noobs, and thus don't expose the more powerful bits (like easy access to UART interrupts).

I don't want to call Arduino 'bad', because it has clearly fostered an huge community by making simple embedded development quite easy. I was amused to find out that one of my wife's coworkers is using an Arduino in their lab to keep a laser from bleaching out their samples by only activating it when the microscope camera is on. When it comes to more complex things (e.g. generating decent quality sound), Arduino just isn't capable. You aren't going to be running too many FFTs on an AVR, and they aren't going to be floats if you want even 100Hz. The code quality of the Arduino community also isn't that great; most if not all of us know how hard it is to foster a high quality and competent community.

What I don't know is how to effectively communicate the above. :-/

Victor · Victor Jun 18, 2004

Are you saying that there is nothing between using Arduino and becoming a microcontroller whiz? Let's forget the whole need to be able to design PCBs, which is definitely not something most people want (or need) to do.

Victor · Victor Jun 18, 2004

JawnV6 posted:

There's a whole spectrum. You're alternating between hating above and hating below. I'm curious how you found yourself on the precise defensible point.

Was I so strong as to constitute 'hating'? Would you flesh out what you're saying a bit more? I'm not understanding how something in between is anything but a good thing. Is there some dogma I'm ignoring, like "If you're going to do more than get your feet wet, you must dive in the deep end."?

the wizards beard posted:

I think I read about this recently, weren't you ripped off on IndieGoGo?

Yep. I don't know what was up with that, but it got taken down pretty quickly.

Victor · Victor Jun 18, 2004

Hey, no reason to apologize! Yesterday, I talked to my boss about the whole idea behind Arduino, and to what extent that made Spark Core so successful. (almost at $200k, with $10k target) To what extent do you simply want to see that it's about as easy to get up-and-going with AshimaCore as it is with an Arduino?

I'm a little confused at how you see it 'shoving avionics down your throat'; could you explain how you got that message? It is designed to be an avionics package, but all that really means is that it has a decently powerful processor, �SD, two sensors, and multiple wireless options. If you were to try and get all these separately, you'd be paying well over $129, you'd have to hook things up yourself, and you probably wouldn't have a high-speed SDIO hookup. If, however, you don't want at least the accelerometer and gyro, I don't think this is the board for you anyway.

Victor · Victor Jun 18, 2004

Slanderer posted:

The arduino libraries somehow manage to be both devoid of features and entirely unoptimized. (Also their I2C libraries will always be poo poo, forever). Their build process is totally hosed, too.

Just sayin.

There are some pretty hilarious changelogs in the Arduino libraries. For example, they tried providing users with ISRs for UARTs, and then took that feature away and implemented in a ghetto manner. Probably because users abused the ISRs and caused the many problems one can get from misbehaving ISRs.

Bad Munki is right, though. I really hate the 'worse is better' dogma, but it seems like people are often unable to make high-quality products that actually get delivered and have nice learning curves.

How does one reach out to people who want devices that have features and are optimized? Are there any good examples of this out there? If so, what does the learning curve look like?

Victor · Victor Jun 18, 2004

JawnV6 posted:

a decade of computer engineering
[...]
Why *must* there be something in that gap?

Not everyone has a decade of computer engineering.

Victor · Victor Jun 18, 2004

JawnV6 posted:

Mechanical engineers I work with without any software training are able to get workable solutions to their problems with Arduino alone, so I'm really having a hard time fathoming what's in the gap.

You're assuming that only people with a decade of experience in computer engineering will want something more powerful than an Arduino.

Victor · Victor Jun 18, 2004

JawnV6 posted:

If you know what "ISR" stands for, you can use an Atmel. Sorry you missed my edit, they're really great tools and did you even look at them before coming back to post at me again?

I used WinAVR in 2003; it was my first introduction to assembly and I was able to learn alright. On the other hand, I had used C++ before and I had already learned how to program standard 1-4 line LCD displays as well as a 128x64 graphical LCD display (from VB6 via parallel port, of all things). I haven't used later incarnations of ATMEL's IDEs because I primarily develop on OS X, where there is a sane shell, among other things. Having an IDE can be nice, but it doesn't necessarily help with the library situation. Does AVR Studio 6.x offer decent libraries? I tried searching for an official I2C library and didn't find one. As we all know, available libraries are what make or break most embedded environments (at least for hobbyists).

There seems to be quite a bit of noise about AVR Studio being buggy, within this thread and outside. Any idea what the current state of AVR Studio is? There has also been noise about the $54 AVR Dragon not always being the most reliable hardware debugger (apparently a lot of people manage to brick them); with the JTAGICE3 being $99 (not to mention the JTAGICE mkII being $400), hardware debugging of ATMEL devices is a bit pricey for hobbyists. To compare, STM32Fxxx devices can be programmed and debugged via the $15 STM32F4DISCOVERY board (gotta remove a 0Ω SMT) or the $21 ST-LINK/V2 programmer/debugger.

Taking a step back, I'm still not sure what your beef is. The point of Arduino seems to be twofold:

provide hardware that can do a good number of interesting things, and allow for modularity (via 'shields')
make it easy to get up and going with software and programming, by providing a nice IDE and easy-to-use libraries

Now that there's the Arduino DUE, 1) is changed a bit. Not having an FPU and not being 5V-tolerant makes the jump from AVR a bit smaller than one might think, though. On the 2) library front, I have yet to find any good options for 100-200MHz ARM platforms�admittedly, I haven't searched as much as I could have. I can say that STM's peripherals library isn't nearly as close to ready-to-use as Arduino.

There definitely seems to be an unfilled niche. Whether or not we're filling it is another question. $129 is a lot to just get going, although it's qty 50, not 1000. I would have thought there would be demand for a decent IMU + �SD + wireless option in this range. But perhaps we aren't marketing ourselves properly.

Victor · Victor Jun 18, 2004

JawnV6 posted:

I'm getting the distinct impression people think more complex things should be possible without an ounce of engineering effort applied.

Sucks, but past a certain point of complexity you need an engineer. From what I've seen Arduino's covering most of that low end and I don't see the gap between "what's possible with an Arduino" and "what you need an Engineer for". For what it's worth, if we're talking about floats and FFT's, I think you've got an engineer.

That impression is from your attitude that people must expend as much effort as you had to, in order to get going on something more powerful than an Arduino. I encounter plenty of your type: people who refuse to believe that helping people learn things in less time than it took you to learn them is a good thing. If you had to walk uphill both ways for school, your children ought to as well! It's... character-building!

It was telling that in your douchebaggy response that you edited out, you mocked my student-run data backup service idea as an example of bad niche-identification. That was pretty hilarious, given that the motivation for said project was my judgment that grad students needed a cheaper way to back up their data than use a then-pretty expensive ($50+/mo) plan. I thought it would be fun to figure out all the bits necessary to offer such a service (I love learning how things work); I was dissuaded from that because the liabilities were just too high. Well guess what, there are now $5/mo unlimited plans. I know several grad student labs that use CrashPlan, labs which had ghetto or nonexistent backups before. So in terms of seeing a niche? Yeah, I got that bit right. In terms of filling it? When it came to a student-run data backup service, I got it utterly wrong.

I took your challenge to examine the TWI libraries provided with AVR Studio 6. I found a TWI library for some of Atmel's SAM ARM devices; it didn't offer anything like callbacks for asynchronous operation, nor did it even do basic stuff like report back bus arbitration errors. Another TWI implementation I found doesn't differentiate between a nack and a lost arbitration in its return code! It wasn't robust. I couldn't find any AVR TWI libraries until I downloaded the Atmel Software Framework. It's allegedly contained in AS6, but I couldn't find matching files in AS6 and there are no 10MB+ zip files in the AS6 installation location. Anyhow I found a single, third-party twi_master.c that looks like a half-assed, buggy, global-variable-using implementation of the TWI Master app note. Not to mention that there is no asynchronous support for AVR I2C, even though I2C is a slow communications protocol. So I don't know what you were talking about when you said there are libraries ready to use, unless you regularly use non-robust libraries.

Do you think people should have to write their own I2C libraries before using a new microcontroller, JawnV6? armorer, if having ready-to-use, robust I2C libraries constitutes having "Duplo blocks", then hell yeah I want Duplo blocks. I'm guessing you don't hold such a dumb opinion, though.

�

Claiming that there is no niche between Arduino and you-must-read-through-the-datasheet-with-a-fine-toothed-comb is myopic, elitist, and just plain retarding. Creating robust, easy-to-use libraries is not easy and shouldn't have to be done over and over and over again. Arduino didn't have to be restricted to n00bs by having crap libraries. Hell, the use of digitalWrite(pin, level) could have been implemented via digitalWrite<pin>(level), avoiding the insane number of cycles it takes to write to a single pin. On the other hand, lots of people use 8N1 on UARTs, so Arduino's Serial.begin(baud) isn't insane as a default. Compare that to what STM's library provides.

Victor · Victor Jun 18, 2004

Slanderer posted:

Actually, my complaint was about people taking Arduino way too far, and not saying, "Ok, let's start naming our files *.c and *.cpp, let's use our own build process, and let's actually commit to doing a good job". As it stands, that project has been so overextended that it's an incomprehensible mess a lot of the time, and it's not rare to encounter a completely untraceable bug that causes poo poo to fall out of the sky. Due to the way they integrated a lot of libs from arduino, tracing poo poo is hard as balls.

Tell me about it. I've mostly dealt with AeroQuad, which is similar to what you've described. We did get a quad flying on it, but holy hell is there some insane stuff going on in there. My next project is to investigate the AQ32Plus codebase, as they need hardware that's actually available and that could be a way to put new life into our flagging Kickstarter.

Do you know of any OSS multicopter projects with sane code?

quote:

I admittedly still use the Arduino at times to prototype something extremely quickly (because it's quicker than digging out an Atmega, a programmer, a breadboard, and all the components I need). I through something together in a day last year using a graphical LCD shield and an isolator that counted hi speed pulses and kept a histogram of pulse duration (I was debugging an issue with some power switchover HW here at work). It's just annoying to see people accumulating a tower of crap on top of Arduino.

I just refuse to believe that providing a more solid library foundation and build practices would make things that much harder than things are with Arduino, now. At least, I refuse to believe this without evidence. You seem to be criticizing the software design/build process and not the hardware design, right? I don't see the problem with having little dev boards to use when the expense of something else is not worth it.

Victor · Victor Jun 18, 2004

JawnV6 posted:

You specifically asked for my learning ramp and I provided it. If I'd known you'd throw this much poo poo at me as a result or so grossly mischaracterized a response to a direct question you asked, I doubt I would've been so forthcoming.

Pretty sure I haven't grossly mischaracterized you. Need I quote the elitist post you later edited away? My criticism wasn't that you are a really good engineer, it's that you don't think there's a niche between Arduino and requiring ten years of engineering experience, as you stated. Although, I actually do question what those ten years of engineering experience have gotten you, if you think the TWI libraries provided with Atmel Studio 6 are production-ready. Maybe you just haven't done much with TWI, but this also makes me wonder about the other libs provided by Atmel.

quote:

You're shilling for your company, and that's great, have at it, but could you back the gently caress up off me?

You've made your opinion clear and I don't think you'll budge, so yeah this tangent is done. I do think it's funny/sad that you characterize "trying to provide the community with something better than Arduino" as "shilling for my company". Do you think random hobbyists are going to produce a solid piece of hardware (which is then in stock) and solid libraries? Pretty sure that almost never happens.

Victor · Victor Jun 18, 2004

Maybe I'm not being clear enough. Consider if we made the following changes to Arduino:

make the libraries robust and well-designed
provide a proper build system
provide motivating examples of using the various peripherals, demonstrating good coding and design style
provide makefiles and perhaps project files for a few IDEs

How much better do you think this would be? We can throw in more capable hardware and things don't change too much. You'll probably have to enable clocks to various peripherals and DMA can get a bit tricky, but that isn't needed from the get-go.

armorer posted:

In order to "step up" from Arduino (which I feel is a sort of construction kit/toy) to these other solutions, you really do need a lot of engineering knowledge.

Writing better software, using an actual build system (even if it's just a makefile), and being able to consult datasheets is definitely a step up and maybe I'm not being clear enough on that. What I'm saying is that these things can be made easier than they are, and we need not demand intricate knowledge in order for someone to get up-and-running, with a solid foundation to work on. There's just no reason to e.g. provide new users with peripheral libraries that don't expose all the errors so that it's as easy as possible to troubleshoot problems.

Part of this may be due to a huge personality difference between folks like Jawn6V and myself. I like to dig into something head-first, learning the various bits and pieces only when I need to. Oftentimes, bad software and hardware design requires you to know far more details than is theoretically required, for a given task. I wouldn't be surprised if Jawn6V doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised.

Victor · Victor Jun 18, 2004

Where does the tradeoff occur, though? I doubt people will be digitalWrite-ing all 64 pins. People who are doing that should definitely be accessing the port registers directly. I definitely didn't mean to indicate that templates are the answer, in all situations. I wonder if one could turn the templated call into a trampoline to something closer to the original digitalWrite and have it inline, and then offer that as an #ifdef option between size and speed...

Victor · Victor Jun 18, 2004

Thanks for taking the time to post that, Otto. And yep, I wrote Jawn6V instead of JawnV6�sorry JawnV6.

Otto Skorzeny posted:

It might at first seem that a more powerful dev board would be useful, but hold your horses.

So we actually are going to be choosing a chip like the one used on the BeagleBone in our end-product, where we'll be using multicopters to convert 2D video footage into 3D models. You make a good point about using specialized hardware for DSP and maybe even PID control; I really don't know how much is reasonable to do on a 168MHz, 32-bit ARM with an FPU and some basic DSP instructions. I definitely have the urge to splurge and use an FPGA to do stuff, but that's quite a bit more expensive, especially if you can't use a free dev environment (in other words, if you want anything more than a very simple design, unless things have changed since I last looked into this). Multiple people have definitely run into issues with multicopter avionics boards running on AVRs, but I really am only guessing when it comes to other application areas. I would have thought there'd be some demand for basic IMUs you don't have to design and fabricate yourself, but perhaps people would prefer to buy ones that have been vetted by the community.

quote:

Furthermore, apologies if I sound like an rear end in a top hat or an "elitist" in saying this but it stands to reason that if this niche were to be filled competently, it would be by someone who doesn't think PCB layout is wizardry.

I didn't say that PCB layout is 'wizardry'; I said "why must you become a microcontroller whiz and be able to design PCBs in your sleep?" I didn't design that PCB; my boss did. It took weeks of effort, and he has designed PCBs that are in spacecraft. Maybe part of the problem is that we didn't have money for anything more than CADSoft's Eagle? I forget if I mentioned that prototyping a board like we're Kickstarting isn't cheap, either.

Victor · Victor Jun 18, 2004

After saying that I couldn't think of motivating uses of a 168MHZ 32-bit ARM with FPU beyond quadcopter avionics boards and IMUs, apparently contradicting my there-exists-a-niche claim, I think a stronger case can be made for offering something Arduino-like with quality libraries and a real build process, full stop. Using something more capable than an AVR makes sense because an STM32F407VG costs less than an ATmega2560. Smaller, cheaper ARM chips could be used if we want to have an alternative to the ATmega328P. I'm not sure there would be enough people to make up such a community, though. :-( Most are happy with pretty crap-quality code. The quadcopter community might actually be more appreciative of robust code than most others, given that there are significant, fun-abridging, $$ costs to buggy code.

I still can't get over the state of TWI library code in Atmel's libraries. Heh, if you look at their API documentation, you can see which error codes are never returned.

Victor · Victor Jun 18, 2004

Yeah, the more I think about this, the more quadcopters seem to be our way in. I'd love to move out from there into fostering a community of people who want higher quality hobbyist (and sometimes not hobbyist) electronic projects, but that's not where to start. If it can be made known that our hardware/software is excellent for quadcopters, maybe people would branch out, more boards can be made (or just used, there are a few STM32F4xx boards out there). In terms of monetizing, we ourselves want a solid foundation and when the code isn't secret sauce, we want to release it and expose it to critical eyes. That's one of my favorite things about my startup. We roll our eyes when someone says everything must be open-sourced, but hey, the world's gotta have some ideologues.

Victor · Victor Jun 18, 2004

JawnV6 posted:

Who the hell does this? Seriously? You kept the post that I thought better of and are now, I'm not even sure, are you threatening posting it again? Classy dude.

Someone who rarely closes tabs and uses two computers. Spooky, I know.

quote:

One last shot at explaining this. I mentioned "Ten Years" was my learning ramp.

I'm merely suggesting that you forget what it was like to want to go beyond Arduino, but not really want to get into a more powerful microcontroller from the ground-up. It's pretty typical for people to forget their understanding level and mentality when they were first learning something.

quote:

I'm not interested in giving a history lesson with such an antagonistic student, but let me know if you ever learn why Atmel doesn't say I2C and we could share a laugh about this.

I know exactly why they don't say I2C (thanks for being a bitch, Phillips). My criticism remains: the TWI libraries you casually referenced in AS6 are not robust. Well, the one for AVRs was third-party and passed its arguments via global variables, so I hesitate to call it a 'library'.

quote:

Lies. Lies and slander. Not content asking direct questions and going nuts over misreading the answer, now you're just going to make things up whole cloth? Classy dude.

How did you interpret the following statement as slander? "I wouldn't be surprised if JawnV6 doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised." Color me surprised. I'm not what you're talking about with respect to the 50-page PDF thing. Good grief.

quote:

Yet again, decade-old knowledge of the toolchain is inaccurate. WebPack is free, I've done a few complex designs with it. On the Linux side there's ways to do Verilog simulation, compilation, and download to the device entirely from the command line. I've talked about these a few times over in the Verilog thread.

Thanks for the update; when I used WebPack I'm pretty sure it had a gate limit. Now I see it's just limited to small-to-medium devices, enough to do some pretty interesting things.

Victor fucked around with this message at 02:45 on May 13, 2013

Victor · Victor Jun 18, 2004

Was there a vitriol spill recently?

JawnV6 posted:

Yet again, randomly picking lovely positions, ascribing them to me, then being a condescending jerk about the whole thing. You must be a hit at parties.

Actually, I've mentioned this idea to quite a few people and nobody was visibly offended, with some of them happily engaging me further on the idea.

quote:

My statements are actually based on watching a bunch of mechanical engineers with no coding or EE skills get Arduino up to snuff prototyping things without my help. And seeing them perfectly content with that tool set. No, really, they've done amazing things and haven't needed floats or FFT's that you're totally sure the Arduino really really needs. If you're quite done maligning my good name without cause, we might be able to discuss the gap you see in real terms instead of whipping up yet another false accusation.

How on earth is this a false accusation? I myself gave an example of Arduino fitting the bill. When I say there exists a niche between Arduino and dev boards/designing your own PCB, I mean that Arduino fits a niche.

quote:

You made up the shittiest possible learning method that nobody in their right mind would use,

I know several extremely smart people who employ this method, so forgive me if I didn't see it as insulting.

JawnV6 posted:

Uh, wanna cite your source here?

Download ASF, then go to /sam/drivers/twi/twi.c. Notice how bus errors, arbitration errors, and overruns are never reported. If you the I2C bus is in an error state when you call a read or write function, I think it'll just freeze the chip (aside from interrupts and watchdog). Oh, there's also no asynchronous option. Cycle wasting time!

quote:

At work now and the tool that I'm actually using, the one that would be in front of a generic user, doesn't look anything like "third party passing global variables."

Please spend a little more time reading and a little less time getting angry. I mentioned AVR specifically when I talked about that little bit. The link you gave me was to SAM.

quote:

Did you even get around to checking out libopencm3 that evensevenone mentioned?

Yep. They provide only the barest I2C support; you have to do something like this to actually use it. (libopencm3 is sufficiently similar to STM's I2C peripheral to make this comparison sound.)

Victor · Victor Jun 18, 2004

I think the Dragon will do, although I recall reading that it's flaky. There's a $42 xPlained board that will also do; JawnV6 linked to it in the post he later edited out. I have since closed my browser, so I don't know which one it was.

Victor · Victor Jun 18, 2004

I'd suggest you look at an alternative to the Dragon if you have yet to order it. I dunno if the XPlained boards can be used for both SAM and AVR hardware debugging or only one. Maybe if you prod JawnV6 he'll comment? He seems to know quite a bit about Atmel products.

Victor · Victor Jun 18, 2004

Delta-Wye posted:

This is very true, and while I love the MSP430 platform, it can be a bit overwhelming for new folks. A lot of the low-power features result in complicated configuration due to the several clock domains. IMHO, anyways.

This is the same with the STM32F4xx. You even have to enable GPIO clocks before calling the pin lock functions�I would have fried a board if I didn't verify that the pin locking worked, first!

Adbot · # ¿ Apr 28, 2024 07:32

Victor · Victor Jun 18, 2004

Martytoof posted:

All the other dev kits are super nice, but if you're just learning to flip registers and turn GPIO pins on and off then you'll be fine with an AVR (or pic or whatever) for a while. That's just my opinion as someone who's starting out myself. I bought a ton of Cortex dev kits but the added complexity just gets in the way. I found that throwing an AVR on a breadboard and using ArduinoISP to program it is fine. I want to get a debugger (Dragon? We hashed over this last page) so I can step through my code and program my AVR without using ArduinoISP, but I'm not really worried about exhausting the limits of an 8 bit AVR while learning.

Agreed: it really isn't worth banging your head against the wall for a few hours because you forgot to add a peripheral clock enable. At least not in the beginning. A hardware debugger is nice though; it's good to at least be able to see what the heck the processor is executing when nothing seems to be happening.