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 »

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

Victor posted:

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!

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.

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

# ? May 9, 2013 21:36

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 23:13

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.

# ? May 9, 2013 21:38

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.

# ? May 9, 2013 21:51

armorer: Aug 6, 2012; I like metal.

In the grand scheme of the "embedded systems world" I really do think Arduino is kind of like Duplo block. Sure you can do all sorts of stuff with it, but it clearly isn't the right tool for everything. I think my previous comments made it clear that I still think it has merit and is a useful product that fills a slot people clearly wanted. The fact that it is something of a Duplo block means that this stuff is available to a wide audience that otherwise would not be free to tinker.

Regarding the "gap" between Arduino and more professional options - I am not really qualified to say much because I don't know the profession. I know that Arduino didn't provide the flexibility or power that I wanted, and so I ended up reading Atmel datasheets, learning some AVR C (I already knew C, but learning what all the registers are and how to use them is a bit confusing), teaching myself to use Eagle, and a whole host of other skills. With all of that, I can just barely make something functional going that route.

I feel like after a while, once I know the tools and the landscape better, I will prefer that approach because it gives me more control and robustness for less cost. I am a professional software developer though, with engineering and mathematics degrees. 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.

armorer fucked around with this message at 21:59 on May 9, 2013

# ? May 9, 2013 21:53

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.

# ? May 9, 2013 22:07

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Victor posted:

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.

There is a tradeoff here, and it isn't necessarily one that everyone will want to make. The writer of that blog didn't really profile anything (hard to blame him since it isn't super easy to profile code running on an Arduino), but there are several distinct things that lead to that function being as slow as it is. The runtime checking is excessive, the excessive runtime checking and several other runtime configurations are done inefficiently, some of the safety could be better provided by the type system (eg. checking they passed a valid pin), etc, but claiming that templates are The Answer is a bit naive. The Atmel chip in the larger Arduinos has what, 64ish GPIO pins? You probably don't want to duplicate even a small function 64 times if code space is tight.

# ? May 9, 2013 22:16

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

# ? May 9, 2013 22:27

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Victor posted:

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.

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[sic] 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[sic] doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised.

There are a few points here.

The first half of this seems to be about building a dev board that is essentially a better Arduino in terms of quality, which is a great goal, albeit one that is already partly and imperfectly filled by things like TI's Stellaris launchpads.

The second half seems to be about building a dev board with greater capabilities than the Arduino, which is where the questionable utility resides. For instance, suppose someone wants to do serious signal processing or process control. The Atmel chip that (most) Arduinos use doesn't have the horsepower for this, and not only due to its lack of an FPU and non-astronomic clock. It might at first seem that a more powerful dev board would be useful, but hold your horses. The type of person who has these problems knows what a Fourier transform is, otherwise they wouldn't know how to implement or use one, or probably even that they should use one (for a lot of process control problems you would actually want a laplace transform, but whatever). You don't learn these things without picking up a bunch of other EE knowledge along the way, or at least relatively few people do. If you know about PID control, you probably know there are ICs that handle the PID stuff on their own that cost very little and are easy to use. If you know about signal processing, you probably know about a zillion types of micro, and about DSP chips, and you probably want control over how poo poo is laid out.

This is the no-mans land that Jawn was talking about - there is demonstrably a lot of demand on the very low end, and a multibillion dollar industry on the high end, but there are good reasons to believe there isn't much demand in the middle. It's possible that this is a niche that's waiting to be filled, but the odds look to be against it. 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. You have a reasonably good background in programming, Victor, and you seem to have picked up on a fair amount of the math needed for control systems in your quadcopter ventures, but if you think this opportunity is real and are sure you want to do this I think you're going to have to bone up on the fundamentals of electronics engineering. I recommend The Art of Electronics if you elect to go this way.

e: another point here is that PCB layout is kind of annoying, but in many contexts just isn't that hard - this is another thing that eats away at the middle end of the market as it were.

Blotto Skorzany fucked around with this message at 22:34 on May 9, 2013

# ? May 9, 2013 22:31

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.

# ? May 9, 2013 22:52

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.

# ? May 10, 2013 00:40

movax: Aug 30, 2008

Having quality libraries (ISRs and all) for common peripherals like I2C, SPI, UART, PWM, etc would be amazing, as well as still being able to utilize those with your own C code (vs being forced to use Processing, etc). That said, it's tough to monetize that (factoring in enforcing licenses and stuff); I think you've got a decent chance of engaging the quadcopter/drone community, especially if you could come up with some convincing/easy to understand PR to explain why your board may be more suitable than an Ardupilot.

# ? May 10, 2013 06:19

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.

# ? May 10, 2013 07:05

Kire: Aug 25, 2006

Delta-Wye posted:

Of course, when they go to do 30-45 analog reads in a row (the multiplexor guide said it would work!!!!!) and find out that it's hellishly slow they lack both the ability to recognize the problem (ADC reads take a long time) or the solution (kick them off and use an ISR to grab the data instead of spinlocking and waiting).

Something I'm confused about with the ISRs on the MSP430 line of chips is if the chip only has one processor, the ISR has to be swapped in and the main program be swapped out for a while for the ISR to run, so it's not truly happening in the background like on a multi-threaded system, correct? So for this example of kicking the analog reads off to an ISR, that requires a multi-core or multi-threaded system to have any effect, right?

Are those terms multi-core and multi-threaded appropriate for talking about microcontrollers?

# ? May 11, 2013 16:29

evensevenone: May 12, 2001; Glass is a solid.

Uh you never have multiple cores and rarely have multiple threads (unless you are using some kind of crazy RTOS).

An ISR needs to be a super-fast little thing that just does something like copy the value into a buffer and return. Then your regular code can read the buffer on its own time.

As long as you keep your ISRs fast, it's like they're happening in the background but they really aren't.

# ? May 11, 2013 16:41

Kire: Aug 25, 2006

evensevenone posted:

Uh you never have multiple cores and rarely have multiple threads (unless you are using some kind of crazy RTOS).

An ISR needs to be a super-fast little thing that just does something like copy the value into a buffer and return. Then your regular code can read the buffer on its own time.

As long as you keep your ISRs fast, it's like they're happening in the background but they really aren't.

That's what I thought. So Delta-Wye is saying that the ISRs should read the ADC output when it's ready at the ADC and then return it, rather than having the main thread poll it? I believe this assumes that the hardware supports activating an interrupt flag when the ADC output is ready?

# ? May 11, 2013 17:04

evensevenone: May 12, 2001; Glass is a solid.

Yeah, exactly. What happens is that it takes 20 usec or whatever to read the ADC, and you get an interrupt when a new value is in. So you can do the read and wait in your main code, or you can do the first read on init, and have an ISR that takes the results and puts them somewhere and starts the next read or switches channels or whatever. Then the the main code just reads the results from memory.

The ISR is just two or three instructions and it doesn't fire until the data is ready so it doesn't add much overhead. If you want even lower overhead or a certain precise sampling rate you can put the read requests on a timer (although usually timers are much more of a limited resource than cycles).

# ? May 11, 2013 17:18

Delta-Wye: Sep 29, 2005

Kire posted:

That's what I thought. So Delta-Wye is saying that the ISRs should read the ADC output when it's ready at the ADC and then return it, rather than having the main thread poll it? I believe this assumes that the hardware supports activating an interrupt flag when the ADC output is ready?

So lets say arduino's backend wrote the AnalogRead() function this way (in psuedocode, I'm not familiar with how the avr compilers want some of this stuff specified)

code:

//no idea for arduino
#define NUM_ANALOG 10

int analogBuffer[NUM_ANALOG]

int analogRead(int channel) {
	return analogBuffer[channel];
}

void ADCISR <interrupt> {
	analogBuffer[0] = ADCREG0;
...
...
	analogBuffer[X] = ADCREGX; 
}

Some platforms need slightly different setups, but you get the idea. Your loop() would do something like this:

code:

int value = analogRead(A0);
serial.println(value);

it will grab the newest value extremely fast and return it. If you are worried about stale data for some reason, let's say you are reading a MUX and you need to know the ADC returned a fresh value since the last address change, you can add a flag that can be checked with very little overhead. If you prefer the old behavior, you would simply do:

code:

while (!analogNewData(A0));
int value = analogRead(A0);

Boom, analogRead() is fixed. Well, 'fixed'. If you're doing a mux and you want to read it as fast as possible, you need to be able to set the address bits in the ISR so each read can be routed to an array, etc etc etc. Sure, it can be done in Arduino, but at 100x the cost in time. I am all for stuff like artists using it, often times it's plenty of horsepower and it's means to an end. If you are building electronics though? Seems like it would be worth cracking the datasheet open. Stuff like digitalRead is trivial to do with memory mapped IO.

# ? May 11, 2013 18:26

movax: Aug 30, 2008

Kire posted:

Something I'm confused about with the ISRs on the MSP430 line of chips is if the chip only has one processor, the ISR has to be swapped in and the main program be swapped out for a while for the ISR to run, so it's not truly happening in the background like on a multi-threaded system, correct? So for this example of kicking the analog reads off to an ISR, that requires a multi-core or multi-threaded system to have any effect, right?

Are those terms multi-core and multi-threaded appropriate for talking about microcontrollers?

Some architectures maintain a shadow set of registers so that you don't have to waste time pushing/popping them on the stack, you literally have a different set to play with when you're in ISR land. Other things to never do in ISR land include making function calls (yeah...), large loops, etc. On chips with a DMA engine you don't even have to worry about the data transfer part, all your ISR will do is clear some interrupt flags at the expense of a cycle or two.

# ? May 11, 2013 21:36

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

Victor posted:

Pretty sure I haven't grossly mischaracterized you. Need I quote the elitist post you later edited away?

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.

Victor posted:

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.

One last shot at explaining this. I mentioned "Ten Years" was my learning ramp. Me, Personally, Just This Jawn Dude. The "gap" is not necessarily between "Arduino" and "Me, Personally" but between "Arduino" and "Some Engineer". The post you linked literally apologized for having sounded like he was clubbing me into that crowd (thanks!), so I'm not even sure you're following the thread of conversation well enough for a subtlety like this. "Some Engineer" could be a kid in college, recent grad, exceptionally gifted high school student, whatever. My point is if you have someone who knows "floats" and FFT's, they probably clear the "Some Engineer" bar. Otto went into much greater depth on why the gap isn't currently served by the market (thanks!) and I'm curious why you didn't really engage on that part of his post.

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. If you literally need to see those letters, check out Dimax's USB solution.

Victor posted:

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.

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.

I'd like to characterize your two approaches "dig in, learn as necessary" and "bookworm datasheet analysis". One of these is The Right Way, a slow plodding approach that guarantees safety at the cost of huge up-front investment. The other is demonstrably Worse, with no guarantee of deterministic success and potential for huge delays that could have been avoided. Victor, you're arguing for Worse Is Better. And if either of us has a known history of requiring a 50-page PDF to be read before commencing a task, I believe it's you. I've always been an advocate for Worse Is Better and I can't imagine your bookworm description squaring with that history instead of whatever mythical elitist you've concocted in my place.

Victor posted:

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

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.

# ? May 12, 2013 16:20

evensevenone: May 12, 2001; Glass is a solid.

What I don't get about this whole argument is that there already is a LGPL library (libopencm3) for STM32 with support for I2C, SPI, USART etc, and a complete gcc toolchain maintained by ARM. I think you can even hardware debug with gdb on the $15 dev boards.

# ? May 12, 2013 16:40

Delta-Wye: Sep 29, 2005

JawnV6 posted:

One of these is The Right Way

Books are for dorks :colbert:

# ? May 12, 2013 17:49

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

# ? May 13, 2013 02:42

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

Victor posted:

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.

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.

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.

quote:

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.

You made up the shittiest possible learning method that nobody in their right mind would use, then ascribed it to me without a shred of evidence beyond your wild fantasies of elitism. Meanwhile, back in places where we actually read the thread, I've always been a worse is better advocate and its perplexing how you'd try to stuff me in the opposite camp without any rhyme or reason. Sure would be nice if you'd just argue your point instead of fantasizing about mistakes I'm not actually making.

# ? May 13, 2013 14:14

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

Victor posted:

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

Uh, wanna cite your source here? 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." Check it out. I'd hate to think you're using decade-old knowledge to unfairly trash something for the third time in as many posts. But the only other explanation that comes to mind is that you're using cursory google searches to call swaths of competing products "not robust" without ever thinking the problem might be on your end or that the IDE would helpfully link you to the proper docs. For someone claiming to be eager to do the heavy lifting for others, you don't seem all that invested in figuring out what's already out there. Did you even get around to checking out libopencm3 that evensevenone mentioned? Or were you more interested in trashing me than discussing relevant tech?

# ? May 13, 2013 16:08

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

# ? May 13, 2013 18:06

Star War Sex Parrot: Oct 2, 2003

This thread is the worst.

Knock it off.

# ? May 13, 2013 19:28

armorer: Aug 6, 2012; I like metal.

As I've mentioned before, I am trying to teach myself some embedded programming skills. Thus far, that has meant a lot of reading online, fumbling with AVR programming with a Dragon and AVR Studio, and reading of various datasheets. I have a few pretty obvious deficiencies in my skillset that I need to remedy, and so I was hoping you could provide me with some suggestions.

The main deficiency is that I don't really know C++. I did a lot of C in college, and have extensive experience in Java from my professional career, but I have never had to do anything meaningful in C++ so all my embedded code just ends up being C. (I know some other languages as well, but I mention C and Java to demonstrate somewhat relevant experience with concepts I expect I would find in C++.) I've looked into getting a good book to help remedy this, but a lot of C++ books seem to make heavy use of the standard library and I imagine embedded C++ tends to be a lot more lean. When I look for recent books on embedded programming, I tend to come up short. Does anyone have any recommendations?

The second problem I am running into is that I learn the most by doing. My learning style revolves around picking something that I don't know how to do, and then doing it. To that end, I find myself recreating various interesting things I find online (hackaday, make, etc) and picking up whatever skills I need along the way. This has worked pretty well for me so far, but I've also looked around for a decent project book. Most of the ones I find are either extremely old and dated, or entirely focused on making things with an Arduino (which is what I trying to move past). Are there any particularly good resources people can direct me to in this area?

The last problem is that there is a huge wealth of knowledge out there in the embedded world that I would classify under "best practices", "design patterns", and "institutional knowledge". This is an area that I am mostly ignorant of. Stuff like commonalities between different microcontroller architectures (so I might know what skills are transferable from AVR to PIC to others), tradeoffs between SPI and I2C, best practices for embedded debugging techniques (whether JTAG, digital logic analyzer, or other), common ics that I should always have on hand, and a whole lot more. I seriously doubt that there is a good book (or a few good books) that I can read to pick up some of this general knowledge. I don't work in an environment where I can pick this stuff up from professionals either. If there are decent resources that I can go through, please point me to them.

I looked through the OP but there really isn't a whole lot there on these topics.

Edit: If it's relevant for any potential recommendations, my preferred development environment is Linux, although I am perfectly willing to code on Windows or OSX if there is a compelling reason for it. I am mostly using AVR Studio on Windows at this point because I haven't gotten around to familiarizing myself with the command line toolchain, and my gaming computer (Windows) is right next to my electronics work bench.

Edit2: I realize there are a lot of questions in this post, and that it will take me years to develop full operational knowledge of all of this stuff. I am mostly looking for some good reference material to accompany my explorations.

armorer fucked around with this message at 02:01 on May 15, 2013

# ? May 14, 2013 19:33

Delta-Wye: Sep 29, 2005

Is there any particular reason you're doing c++? The runtime overhead for most of the novel c++ features (polymorphism et al) make it an unusual choice for resource constrained systems like 8bit avr/pic/etc chips.

You can get the benefits of classes in C with structs and making your own *this pointers as an argument to each 'member' function (it's all c++ is doing anyways).

Hell, you can even do inheritance if you really really want to via structs.

# ? May 15, 2013 00:02

armorer: Aug 6, 2012; I like metal.

No reason, and thus far I haven't been using C++ since I don't really know it. It just seemed like C++ was more common from some of the stuff I've read. If it's a better idea to stick with C and just use structs, that's great - less to learn!

# ? May 15, 2013 01:57

movax: Aug 30, 2008

armorer posted:

No reason, and thus far I haven't been using C++ since I don't really know it. It just seemed like C++ was more common from some of the stuff I've read. If it's a better idea to stick with C and just use structs, that's great - less to learn!

Yes, you definitely want to start out with C!

# ? May 15, 2013 02:07

Base Emitter: Apr 1, 2012; ?

Delta-Wye posted:

Is there any particular reason you're doing c++? The runtime overhead for most of the novel c++ features (polymorphism et al) make it an unusual choice for resource constrained systems like 8bit avr/pic/etc chips.

You can get the benefits of classes in C with structs and making your own *this pointers as an argument to each 'member' function (it's all c++ is doing anyways).

Hell, you can even do inheritance if you really really want to via structs.

Just scoping functions to a class is an ok reason to use C++, that's pretty much what I did for mbed programming. It's handy for modularizing IO that you can instantiate multiple times on different pins, for example, and more convenient than how you'd do it in C with no more overhead.

The one advantage C++ has over other OOP languages is constructing static and stack objects so you don't have to use the heap at all, which is great all by itself for embedded.

Plus, there's so many random BS features in C++ that you should never feel bad ignoring most of the language if a tiny subset solves your problem.

# ? May 15, 2013 02:17

armorer: Aug 6, 2012; I like metal.

For some reason I had the impression that C++ was more common in embedded design than C, and that if I wanted to be more "serious" I should learn it. If that is a bogus impression I picked up from somewhere, I am more than happy to cross it off my long list and focus on some other things instead.

I am thinking about going through one of these two books next:
Making Embedded Systems
Designing Embedded Hardware

# ? May 15, 2013 02:38

minidracula: Dec 22, 2007; boo woo boo

armorer posted:

I am thinking about going through one of these two books next:
Making Embedded Systems
Designing Embedded Hardware

I have both and think they are both worth reading. That said, I think the first is more relevant to your immediate goals.

# ? May 15, 2013 02:43

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

How do I learn to layout real PCBs.

# ? May 15, 2013 10:27

armorer: Aug 6, 2012; I like metal.

Sinestro posted:

How do I learn to layout real PCBs.

I learned my way around Eagle using the youtube videos that this guy put up rpcelectronics. They don't really teach you any design skills, but they do show you how to use the program for basic stuff pretty clearly. If you want to make them yourself via etching, there are a lot of tutorials online. If you want to upload your design to someplace like OSH Park, then I would look online for a design rule check (drc) file for eagle to run before you send them out.

armorer fucked around with this message at 13:21 on May 15, 2013

# ? May 15, 2013 13:12

Delta-Wye: Sep 29, 2005

Sinestro posted:

How do I learn to layout real PCBs.

"Real" PCBs? If you just mean a normal PCB, I would get a copy of Eagle and follow some tutorials to get started. Once you figure out the software start making lots of circuit boards as they are going to suck at first; like a lot of things, it takes practice.

Base Emitter posted:

Just scoping functions to a class is an ok reason to use C++, that's pretty much what I did for mbed programming. It's handy for modularizing IO that you can instantiate multiple times on different pins, for example, and more convenient than how you'd do it in C with no more overhead.

The one advantage C++ has over other OOP languages is constructing static and stack objects so you don't have to use the heap at all, which is great all by itself for embedded.

Plus, there's so many random BS features in C++ that you should never feel bad ignoring most of the language if a tiny subset solves your problem.

Tell me again about how developing for ARM is fundamentally different than an 8bit micro :allears:

Eh, mostly just giving you a hard time. Curious what exactly you mean by "scoping functions". Are you referring to public/private or seperation? I'm pretty sure you can recreate that by encapsulating a function inside of a library that is a separate .c/.h file by simply not exporting the private functions in the header file.

Delta-Wye fucked around with this message at 13:46 on May 15, 2013

# ? May 15, 2013 13:13

movax: Aug 30, 2008

Sinestro posted:

How do I learn to layout real PCBs.

Find slides and read a lot of app notes. Then, you'll have to parse all those documents yourself because they willconflict with each other when it comes to recommendations. Luckily the basics are not too difficult, and for most hobbyist class projects, even terrible PCB layout (usually) ends up working.

# ? May 15, 2013 15:02

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

Sorry, I am not at my most coherent at 2:27 AM. I want to learn to do advanced layout, such as a board using a CC430 family chip --I've never payed out a board with wireless on it.

# ? May 15, 2013 15:13

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Delta-Wye posted:

Curious what exactly you mean by "scoping functions". Are you referring to public/private or seperation? I'm pretty sure you can recreate that by encapsulating a function inside of a library that is a separate .c/.h file by simply not exporting the private functions in the header file.

Probably he means using classes as ersatz namespaces.

# ? May 15, 2013 15:26

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 23:13

evensevenone: May 12, 2001; Glass is a solid.

I think the trick with using C++ embedded is to start with a good understanding of C, and only incorporate those features from C++ that aren't too complex and that let you avoid dynamic allocation. If you just read a C++ book and start trying to use std:vector, you're headed for trouble. You certainly aren't going to get full OOP paradigm.

# ? May 15, 2013 16:23

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

«‹›53 »