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 »

Slanderer: May 6, 2007

JawnV6 posted:

Has anyone worked with the MPR121 capacitive touch sensor chip?

I'm building something based on it. I have the arduino library for it and converted those calls to a real platform. It's working great just with aluminum tape. Now I'm having to tune the sensitivity to put a dielectric between it and the actual touch point on the device. I'm going to dive into the datasheet shortly, but any pointers on working with this or other capacitive sensors would be much appreciated.

If you'd like, I could try to dig up some app notes from either Atmel or Cypress that I had a while back that got into circuit layout for different types of capacitive sensors. Mostly stuff about the correct geometry and the effect of dielectric layers, but there was one specific demonstrating prototyping different sensors using only copper taper on the underside of thin polycarbonate/lexan/something, and another that demonstrated drawing a capacitive "slider" sensor (one of the ones made of chevrons) on a piece of paper using regular pencil, and then demonstrating that it loving worked.

# ? Oct 3, 2013 17:58

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:08

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

Holy crap, yeah that would be perfect!

fake edit: this? http://www.atmel.com/Images/doc10752.pdf It's specific to one of their chips but includes a lot of general purpose information about the theory.

# ? Oct 3, 2013 18:08

Slanderer: May 6, 2007

JawnV6 posted:

Holy crap, yeah that would be perfect!

fake edit: this? http://www.atmel.com/Images/doc10752.pdf It's specific to one of their chips but includes a lot of general purpose information about the theory.

I don't have my files at work, but that might be it. I thought the document had a different title (it might have been an older version), but those diagrams seem familiar. Really good stuff in there regardless (the geometry diagrams, the stuff on making LED illuminated cap touch buttons).

I just realized that the demo of someone drawing a sensor on paper was a video, from Atmel I think. I can't find the video now, though, but I might be able to dig it up from my old bookmarks.

Here is the one on prototyping sensors:

http://www.cypress.com/?docID=3322

# ? Oct 3, 2013 18:46

TwystNeko: Dec 25, 2004; *ya~~wn*

So I'm thinking this might be a better thread to ask in rather than the DIY forum Arduino thread, since it's more programming oriented..

I'm working on a customized Daft Punk helmet, with two arduinos running different parts - One is running a 32-pixel RGB string, and the other is running a 8x16 single-color matrix. My questions are thus:

1) I'm looking for interesting algorithmic animations for the matrix. Pseudo-code is fine, as I've managed to implement a set of drawing functions, that boil down to a simple drawPixel(x,y,state) command. I just made a simple "matrix-style" dot scroller, since I can actually access the full LED array directly, which made scrolling pretty simple.

2) I want to have the arduinos talk to each other. The one running the RGB leds has a "blinking eyes" animation, and I want it to tell the matrix arduino that it's started/ended the animation, so I can sync up animations. This would also need the matrix arduino to stop whatever it's doing, and do the "mouth" display, then stop that and go on to a new animation when told to.

Bi-directional control isn't a big thing - Although I'm thinking of having the matrix do a 8-line "Vu-Meter" display, and maybe feeding the max level to the RGB leds to match up would be a cool effect.

# ? Oct 14, 2013 09:17

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

Why can't you drive both sets of LEDs from one arduino? :confused:

# ? Oct 14, 2013 15:19

TwystNeko: Dec 25, 2004; *ya~~wn*

You know, I'm not sure I can't. But there's a lot that I want just one arduino to do - run 32 RGB leds via SPI, a 8x16 matrix via I2C, and monitor a microphone via an analog input. What with different libraries for each, it MIGHT be possible, but I think I'll run into the space and memory limitations. I'll give it a whirl, though.

# ? Oct 14, 2013 19:11

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

I don't see how any of the leds would conflict with each other or even come close to maxing out the atmega. On a side note: fastspi lets you select arbitrary pins for software spi, and a mere 32 leds is waaaaaay under the max throughput for that, so even if your spi pins were to conflict with your i2c pins, you'd be able to adjust accordingly without issue.

And if you find your audio analyzing is too heavy (I doubt it, but if), you could always switch to a teensy. It'll be smaller, cheaper, and faster, and is basically a drop-in replacement for arduino.

# ? Oct 14, 2013 19:15

TwystNeko: Dec 25, 2004; *ya~~wn*

well, I tested it. Yup, I can run both things on the one arduino. So that's probably an easier thing all around. I'm using about 75% of the memory though, before any audio stuff.

The one thing I don't know how to solve: now both displays run at the same rate. ie, if I run the matrix-scroll effect, and a sinewave brightness effect on the RGBs, it doesn't look as nice as when the RGB animation was faster, but speeding up the matrix also looks wrong.

Is there a way to do asynchronous loops? ie, run two separate functions simultaneously?

# ? Oct 14, 2013 20:51

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

Make your displays update based on the current millis() instead of serially in a loop. That is, you update the displays as fast as your arduino possibly can, but for the sin wave, for instance, you update it using millis() as the variable instead of some loop variable.

If you want, you can put an if() a the beginning of your draw block that checks if, say, millis() ends in a 0 (thus updating every 10 millis at most.)

e: Here's what I assume you're doing now:

code:

void loop() {
	for(i = 0; i < 10; i++) {
		update_matrix(i);
		update_stripes(i);
	}
}

instead, do this:

code:

void loop() {
	int t = millis();
	update_matrix(t);
	update_stripes(t);
}

Of course you'll have to adjust your drawing functions a little but trust me, it's worth it, it makes for much nicer/convenient animation, and if something bogs down your atmega (like audio processing) the animation won't get hung up as noticeably, because you'll have a variable framerate. Nothing going on and you can render 100 frames a sec? No problem. More thinking going on and you can do only half of that? No problem, the animation will look exactly the same. The only time you will see a change in the framerate having an effect is if it slows down enough that you can see the individual frames, at like <25/sec. At which point, I'd still argue it's better, because otherwise your display would get hung up on that one phase for however many frames you had programmed in, instead of a certain amount of time.

e: Here's a more concrete example using fastspi2.

My loop() function looks like this:

code:

void loop() {
  //blah blah blah snip
  if(code.length() <= 0) {
    status_idling();
  } else {
    status_reading();
  }
}

and later on, my idling and reading functions:

code:

void status_idling() { //slowly "breathe" blue
  if((millis() - animation_offset) % 10 == 0) {
    LEDS.showColor(CRGB(0, 0, floor((sin(float((millis() - animation_offset)) / 1000.0) * 0.5 + 0.5) * 255)));
  }
}

void status_reading() { //spin a rainbow
  if((millis() - animation_offset) % 10 == 0) {
    fill_rainbow(leds, NUM_LEDS, float((millis() - animation_offset)) / 4.0, 20.0);
    LEDS.show();
  }
}

As you can see, it doesn't matter how often I call status_idling() or status_reading(), the animation comes out the same either way.

Bad Munki fucked around with this message at 22:09 on Oct 14, 2013

# ? Oct 14, 2013 21:30

TwystNeko: Dec 25, 2004; *ya~~wn*

Okay. That's really going to take some thinking then, on how to manage it. I have several different animations I want to be using, but that can be handled in the individual update function. So I guess what I need to do is recode my stuff to do one frame per update.

I can see what you mean - it's just going to take some thinking. Some of it, like the matrix-effect is already like that, so that's simple. The sinewave on the RGB strip isn't, so I'll have to work that out. I'll actually post the code, so you can see what I mean.

http://pastebin.com/NcgXijN7

I guess I'll be using a lot more globals for counting so that it knows where it is in an animation - like the circles one. Make j global, drop the loop, decrement it, and it should work.

example:

code:

void circles(int wait) { 
  // do one circle
  if(newCircle == true) {
    matrix.clear();
    circleX = random(8);
    circleY = random(16);
    newCircle = false;
    circleRadius = 3;
  }
    matrix.drawCircle(circleX,circleY,circleRadius,1);
    matrix.drawCircle(circleX,circleY,circleRadius+1,0);
    matrix.writeDisplay();
    circleRadius--;
    if(circleRadius < 1) { newCircle = true; }
}

I just need to sort out the "wait". For example, this animation looks good at a delay of 75. I want to pass in the wait, so it only updates that often.

TwystNeko fucked around with this message at 22:32 on Oct 14, 2013

# ? Oct 14, 2013 22:23

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

I'd also point out that you can, in fact, use both methods, in case shoe-horning an animation into that scheme is too kludgey. The easiest way (maybe not the cleanest, but easiest) is to simply call your time-based animation function in between each step of your frame-based animation. Since the time-based animation doesn't care how many frames per second it's animating at in order to get a temporally-correct display, you can clamp it to the frames of your frame-based animation with minimal effort.

So say I have two animations, one based on millis() and destined for Display1 and one based on a series of frames and destined for Display2:

code:

void loop() {
	// draw Display1's animation for one second and leave Display2 blank
	while(millis() < 1000) {
		updateDisplay1(millis());
	}
	// Continue drawing Display1, and draw Display2's frame-based animation
	for(i = 0; i < NUM_FRAMES; ++i) {
		updateDisplay1(millis());
		updateDisplay2(i);
	}
}

That code is entirely non-functional on its own, but hopefully that makes it clear enough how you can blend the two fairly easily. Maybe not optimal, but definitely do-able.

As for doing something similar with two frame-based animations, I'd probably set up a proxy that uses millis() and updates the frame on each display based on that and a desired framerate.

# ? Oct 14, 2013 23:44

TwystNeko: Dec 25, 2004; *ya~~wn*

I take it animation_offset in your earlier examples is the millis() when the animation started? So I just do if((millis() - start_time) % wait) == 0) ... ?

# ? Oct 15, 2013 00:20

Delta-Wye: Sep 29, 2005

To get easy animation, you need a method of pegging your refresh rate to walltime, and the arduino provides the milli() function for just that. You can either use the milli() value directly as your frame index, or track elapsed time.

It looks like you're leaning towards tracking elapsed time, which is pretty straight-forward. I'd do something like this:

code:

void drawframe(void) {

    static unsigned long next = 0;

    if (millis() > next) {
        // do your image generation here
        // set frame index, draw, update screen, etc
        next = millis() + 17;
    }

}

If you wanted to make it slick, you can pass in an argument that is a pointer to the light bar/framebuffer you want modified, and just call it something like:
drawType1(&left);
drawType2(&right);
etc...

What a great opportunity to use function pointers! :eng99:

Your main code just calls a function pointer and doesn't have to care what the current draw function is. Say your function prototype is:

code:

void drawOp(int*);

You can create an array of function points and just store a 'currently drawing' index of all of your draw ops.

code:

void (*drawOp[3]) = {drawOp1, drawOp2, drawOp3};
int OpIdxL = 1;
int OpIdxR = 2;
drawOp[OpIdxL](&bufferL);
drawOp[OpIdxR](&bufferR);

I've done this and been pretty happy when dealing with a situation where one process (say your infinite main loop) is calling draw functions while something else is asynchronously changing the desired calls (say, in an interrupt). It does a good job of calling the new code at the first opportunity. There are other issues if you are going to use interrupts (global accessibility, volatile, etc) but that is the general gist.

# ? Oct 15, 2013 01:04

TwystNeko: Dec 25, 2004; *ya~~wn*

Huh. That's getting a little too complex for me - I barely understand that, as pointers are kind of new to me. I think ... &var is a direct memory access of var? But int*?

I'm up for learning, of course. In the end, I just want something that works well, and lets me add new stuff. I'm all for "best practices", as less terrible code now means I can go back and look at it in 3 weeks and know what the hell I was doing. Slick is good, of course.

I'm less concerned with tracking elapsed time, to be honest - nothing I'm making is time sensitive at all, beyond making things look good.

I am noticing that I'm having to declare a whole lot more variables in the global scope. Is that something I should worry about? Or just roll with it?

# ? Oct 15, 2013 01:21

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

* is just your magic wand of dereferencing

https://www.youtube.com/watch?v=6pmWojisM_E

# ? Oct 15, 2013 01:27

ante: Apr 9, 2005; SUNSHINE AND RAINBOWS

TwystNeko posted:

I am noticing that I'm having to declare a whole lot more variables in the global scope. Is that something I should worry about? Or just roll with it?

Pretty common and fine in microcontrollers. Not so cool in desktop programming.

# ? Oct 15, 2013 01:32

Delta-Wye: Sep 29, 2005

TwystNeko posted:

Huh. That's getting a little too complex for me - I barely understand that, as pointers are kind of new to me. I think ... &var is a direct memory access of var? But int*?

I'm up for learning, of course. In the end, I just want something that works well, and lets me add new stuff. I'm all for "best practices", as less terrible code now means I can go back and look at it in 3 weeks and know what the hell I was doing. Slick is good, of course.

I'm less concerned with tracking elapsed time, to be honest - nothing I'm making is time sensitive at all, beyond making things look good.

I am noticing that I'm having to declare a whole lot more variables in the global scope. Is that something I should worry about? Or just roll with it?

Global variables are 'bad practice' that still shows up in embedded designs often. It's the simplest way to pass information around, especially if the project is naturally limited in scope so that you don't end up running into problems as the program gets larger (your project versus creating something like your web browser) and it has the added benefit of being fairly light-weight.

Ideally you'd collect the variables into objects and pass around the object or whatever but whatev.

I'm looking at your code on pastebin and there only seems to be a single LED matrix? Am I missing something?

# ? Oct 15, 2013 01:33

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

Delta-Wye posted:

To get easy animation, you need a method of pegging your refresh rate to walltime, and the arduino provides the milli() function for just that. You can either use the milli() value directly as your frame index, or track elapsed time.

It looks like you're leaning towards tracking elapsed time, which is pretty straight-forward. I'd do something like this:
code:
void drawframe(void) {

    static unsigned long next = 0;

    if (millis() > next) {
        // do your image generation here
        // set frame index, draw, update screen, etc
        next = millis() + 17;
    }

}
If you wanted to make it slick, you can pass in an argument that is a pointer to the light bar/framebuffer you want modified, and just call it something like:
drawType1(&left);
drawType2(&right);
etc...

What a great opportunity to use function pointers! Your main code just calls a function pointer and doesn't have to care what the current draw function is. Say your function prototype is:
code:
void drawOp(int*);
You can create an array of function points and just store a 'currently drawing' index of all of your draw ops.
code:
void (*drawOp[3]) = {drawOp1, drawOp2, drawOp3};
int OpIdxL = 1;
int OpIdxR = 2;
drawOp[OpIdxL](&bufferL);
drawOp[OpIdxR](&bufferR);
I've done this and been pretty happy when dealing with a situation where one process (say your infinite main loop) is calling draw functions while something else is asynchronously changing the desired calls (say, in an interrupt). It does a good job of calling the new code at the first opportunity. There are other issues if you are going to use interrupts (global accessibility, volatile, etc) but that is the general gist.

That plan of attack in general works extremely well with fastspi2, it was basically designed and optimized with that sort of behavior in mind. Fastspi2 is hot.

# ? Oct 15, 2013 02:01

TwystNeko: Dec 25, 2004; *ya~~wn*

"LEDS" is a 32-pixel RGB LED chain controlled with FastSPI.
"matrix" is the 8x16 matrix.

They're completely independant - matrix uses i2c, LEDS is SPI.

I found this: http://www.newty.de/fpt/index.html to try and understand function pointers. As you can see from my code, I don't really use them - a good chunk of that code is copy/pasted then mangled into what I need - like the clear_strip() function, it uses &LEDS[].

Okay, here's my updated code: http://pastebin.com/6dpwNceF

simpleWave is for the RGB strips, and circles is for the matrix. They both run at different rates, so I'm happy with that so far. From here it's easy enough for me to make a random animation selector for each component. The only challenge is to make the animations link up when needed, but that can probably be done with another global var.

edit: There has to be a better way to track the state of an animation than a new variable. Every animation needs some kind of counter, if not two or three. For example - the Circles animation needs to save the x,y,radius, and whether it's a new circle or not. The simpleWaves needs a hue, position, and a "new" flag. The rainbow stack code is going to need another 3.

This is going to get out of hand rapidly. Suggestions? You said collect the variables into objects, but I'm not seeing how that'll help. I was relying on local vars in a for loop.

Should I be making all my functions and such into classes?

TwystNeko fucked around with this message at 04:11 on Oct 15, 2013

# ? Oct 15, 2013 02:01

TwystNeko: Dec 25, 2004; *ya~~wn*

Argh. Sorry about the new post, but I figured this was worth a new one.

So I've been working on the animations, trying to make them all non-blocking as we were talking about.

I've made two functions, one of which, though identical to the other, will not work at all.

http://pastebin.com/APf1eWJZ <- the code.

The rainbowstack function works flawlessly. The dropLines function does not. It just puts a single line on the display, and it doesn't move at all. I had it spit out variables to the serial monitor, and it just reads m_X as 0. I check it in the init section, and it's saying it's 16. There's no decrementing, it's just 16, then 0. Any ideas? I'm kind of lost here.

Edit: Alright, I'm going INSANE. If I run the sinewave on the LEDs strips, at the same times as the dropLines function, it works. Running the rainbowstack function causes it to not work. What the HELL.

Edit2: Okay, it seems this is not as non-blocking as I thought it was. I can see a whole lot of stuttering on both the matrix and the LED strips, where it's waiting for the other device to catch up. I might have to go back to two arduinos after all.

Edit the 3rd: I've changed out all the modulos to using next = millis() + wait; - but it's still janky as hell, stuttering all over the place on both strips.

http://www.youtube.com/watch?v=ozMVYaeFDyw <- video. http://pastebin.com/KPsKHTf7 <- current code.

TwystNeko fucked around with this message at 06:55 on Oct 15, 2013

# ? Oct 15, 2013 05:46

Delta-Wye: Sep 29, 2005

TwystNeko posted:

http://pastebin.com/APf1eWJZ <- the code.

I notice you're not declaring your local variables, but from that snippet they don't seem to be shared. If you are just making variables like newStack and m_X global so their values persist, look into making them local static variables.

http://en.wikipedia.org/wiki/Static_variable

EDIT: About them acting funny depending on what is enabled - do you have an easy way to determine the refresh rate? I assume your loop() function is calling these, can you print out millis() every execution, or maybe blink an LED?

The modulo solution is a bit weird, as the behavior is dependent on how often it is called. If you call the function once per millis() increment, things are perfect and it works as expected. If you call it much more often than once per millis() increment, it will not run for several increments, and then get refreshed repeatedly during that millis() value until it increments again. If you sample less, it will occasionally fail to sample on an even modulo and it will skip that refresh entirely until the next one comes along. The issue comes from the equality sign, I guess, but either way it isn't ideal. You may be running into a similar problem if you're tracking the next values in a similar fashion.

Delta-Wye fucked around with this message at 07:03 on Oct 15, 2013

# ? Oct 15, 2013 06:54

TwystNeko: Dec 25, 2004; *ya~~wn*

okay, I'll do that. I just added in a video of the janky crap it's doing, along with the current code.

I've actually changed out the modulo code to the solution you suggested. As for the refresh rate.. it's just a basic loop. I did notice that printing to Serial.println() really bogged down everything.

I also changed the == out to >= where required, so it shouldn't skip a refresh. I realize there HAS to be a better way, but I just don't know it.

I'm not a great coder, obviously.

Huh. Changing everything I could to static local vars made a HUGE difference, and I'm not sure why. Huzzah!

TwystNeko fucked around with this message at 07:22 on Oct 15, 2013

# ? Oct 15, 2013 06:56

Delta-Wye: Sep 29, 2005

Yeah, it looks like it is hanging up during the processing-heavy frames. My solution shows similar behavior if the refresh calculation times are high because the true refresh rate is really the wait + refresh calculation/draw time as the next value is not changed until the end of the draw function. Moving it to the front doesn't help, as you have more than one draw function running so only the first one will be correct.

A better solution is to use some sort of call back library and a hardware timer (much like the millis() function itself is doing) to set a flag and just draw a frame/clear the flag asap in the main if it's set. A library like http://playground.arduino.cc/Code/Metro with autoreset may be appropriate for this. There looks to be quite a few options for the arduino, so feel free to look around.

EDIT: The project looks cool and the code isn't bad. Don't knock yourself too hard.

# ? Oct 15, 2013 07:18

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

I need some advice on serial programmers. This is an area I'm extremely weak in since my last company had teams dedicated to solving this.

We're building something that will take ~30 micros. It's a dead simple problem (i.e. two analog sense, drive some LED's) but we're trying to keep costs down. So a $30 arduino is overkill. Plus our senior EE has a burning hatred for arduino.

I have a SAM-ICE for working with bigger ARM's and wouldn't mind having a programmer for AVR's. I'm looking at getting 30 AVR dev boards and either an AVR Dragon or AVR ISP mkII. Total cost has to be under 900, so the programmer cost of $52 or $37 split over 30 boards + individual board cost has to be under $30. Any recommendation on a cheap AVR board? I'm looking at that or the STM Discovery from the OP, looks like it's $10 and doesn't require any other cost, correct?

# ? Oct 16, 2013 19:31

armorer: Aug 6, 2012; I like metal.

I have an AVR Dragon and it's been working fine for me. I believe that Marty picked one up as well a while back and has been using it long enough to have formed an opinion.

What are you looking for in a dev board exactly? When I tinker with AVR chips I typically am building up a small purpose built board, which keeps the cost way below $30. If you want the dev board to prove out a design, could you buy one or two Arduino Unos (just to use them as a dev board for the atmega328p) and then do your run of 30 devices on a cheaper custom board?

# ? Oct 16, 2013 20:03

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

Yeah the concept's proven out with Arduino already. A few interns did the coding and mechanical designs. Now that we're blowing it up to "production" we're looking into the low cost board. The biggest impediment to a custom board is our time, so we're hoping to get by with cheap dev kits. I was hoping to have an excuse to grab another tool to keep around, but the STM's looking cheap and easy enough to knock this out.

# ? Oct 16, 2013 20:11

armorer: Aug 6, 2012; I like metal.

There are a LOT of Uno "compatible" boards. I haven't used any of them (because I typically just cobble up something custom) but some of them are in the $10 range. SainSmart has this one for example. If you want an excuse to pick up a programmer and want to use whatever you already have coded up for the arduino, one of the cheap knockoff boards may work fine for you.

# ? Oct 16, 2013 20:23

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

The first intern prototype was derailed for a week when their cheap arduino knockoff turned out to nonfunctional. Was one of those onion peeling weeks when they finally traced it back to the cheap board not having the right parts on it. So I'm a little wary of going that route

I want to do a rewrite in C actually. The EE's time is more constrained than mine. I've been working in the comfort of managed languages and IDE's too long, need a return to the basics.

# ? Oct 16, 2013 21:36

Delta-Wye: Sep 29, 2005

JawnV6 posted:

The first intern prototype was derailed for a week when their cheap arduino knockoff turned out to nonfunctional. Was one of those onion peeling weeks when they finally traced it back to the cheap board not having the right parts on it. So I'm a little wary of going that route

I want to do a rewrite in C actually. The EE's time is more constrained than mine. I've been working in the comfort of managed languages and IDE's too long, need a return to the basics.

Any reason you couldn't just knock out an easy dev board of your own? If you're willing to program the bare processors, you don't need a whole lot of parts and then you can make the footprint whatever you want. Should be trivial to beat the $30 mark too.

# ? Oct 16, 2013 22:04

armorer: Aug 6, 2012; I like metal.

JawnV6 posted:

The first intern prototype was derailed for a week when their cheap arduino knockoff turned out to nonfunctional. Was one of those onion peeling weeks when they finally traced it back to the cheap board not having the right parts on it. So I'm a little wary of going that route

I want to do a rewrite in C actually. The EE's time is more constrained than mine. I've been working in the comfort of managed languages and IDE's too long, need a return to the basics.

Fair enough. As I said I haven't used any of the knockoffs. The whole schematic is freely accessible though, so if the parts are right it ought to work fine. I've had good luck just writing code in AVR Studio and programming the chips with the AVR Dragon. I keep meaning to get a gcc toolchain in place so I can switch over to coding on linux (which I vastly prefer in general), but I have honestly been pretty lazy about it. What I like about the AVR platform is that you have good free development options, and they are pretty easy to work with for a beginner like me. If you are willing to make some boards, that route may be your cheapest option. I have one of the STM Discovery boards you mentioned, but I haven't used it for anything so I really can't speak for it.

Another option for a $10 dev board is the MSP430 Launchpad. I think it has more of an online following than the STM Launchpad, but maybe I just haven't found the right forums yet. As far as the MSP430 goes, there are the 43oh forums where you might be able to get more info. On the AVR side there is AVR Freaks

armorer fucked around with this message at 02:48 on Oct 17, 2013

# ? Oct 17, 2013 02:45

Corla Plankun: May 8, 2007; improve the lives of everyone

Delta-Wye posted:

Any reason you couldn't just knock out an easy dev board of your own? If you're willing to program the bare processors, you don't need a whole lot of parts and then you can make the footprint whatever you want. Should be trivial to beat the $30 mark too.

This is probably the best answer. Get a breakout/protoboard to make it easier to deal with tiny pins and then go to town adding only the stuff you need.

# ? Oct 17, 2013 02:47

poeticoddity: Jan 14, 2007; "How nice - to feel nothing and still get full credit for being alive." - Kurt Vonnegut Jr. - Slaughterhouse Five

Delta-Wye posted:

Any reason you couldn't just knock out an easy dev board of your own? If you're willing to program the bare processors, you don't need a whole lot of parts and then you can make the footprint whatever you want. Should be trivial to beat the $30 mark too.

This is the best option.

If you're not interested in making your own boards, but you want a cheap Arduino compatible system, the Arduino Pro Mini is probably what you'd be looking for (they can be found for under nine bucks in moderate quantities).

# ? Oct 17, 2013 03:12

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

Thanks for the advice. AVR Dragon and some bare atmega328p's on order. Confused that digikey couldn't get them here today, but tomorrow's good enough.

# ? Oct 17, 2013 16:53

Slanderer: May 6, 2007

Be real careful with those AVR Dragons---they are really easy to kill. Presumably it's just ESD or something, but a lot of people have had those randomly die. A lot don't, but still consider getting/making a case for it.

Personally, I've always been just fine with the AVR ISP mkii.

Also, in case anyone is looking for a cheapo controller board, Adafruit started selling these a few weeks ago:

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

It's just an Attiny85 with some LEDs, a regulator, a reset button and a USB connector. They come in 3.3 or 5V versions, and they have bulk packs of them too. Nothing fancy, but better than using a full dev board (or making my own) for a single gadget that doesn't need to do anything complicated. The only downsides are that 1/3 of the flash is taken up by the USB bootloader, and it doesn't have a USB serial port.

# ? Oct 17, 2013 17:53

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

Slanderer posted:

Be real careful with those AVR Dragons---they are really easy to kill. Presumably it's just ESD or something, but a lot of people have had those randomly die. A lot don't, but still consider getting/making a case for it.

We have a full machine shop, should be able to get someone to make one.

Slanderer posted:

Personally, I've always been just fine with the AVR ISP mkii.

It looked like this supported fewer chips? If I end up frying the Dragon I'll order one.

# ? Oct 17, 2013 17:57

Slanderer: May 6, 2007

JawnV6 posted:

We have a full machine shop, should be able to get someone to make one.

It looked like this supported fewer chips? If I end up frying the Dragon I'll order one.

It does, but I recall some of Atmel's documentation may be incorrect. The same with the Dragon--I think they may have patched it at some point to support more chips (with larger memories??). It's been a while...

# ? Oct 17, 2013 18:18

armorer: Aug 6, 2012; I like metal.

I use the cardboard box my Dragon came in as the case, and am moderately careful with it. I've modified it a bit from how it comes stock - specifically I soldered in a set of male pin headers and a ZIF socket as shown here. The up-to-date documentation on the dragon is here. I made a few little adapter boards on protoboard like they show in that hackaday article. I only have them for the chips I work with frequently, and they are not nearly are professional looking as the ones there. It keeps me from having to wire up the dragon for each different chip I want to work with, and it also keeps me from mis-wiring it and frying something by mistake.

# ? Oct 17, 2013 19:16

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

Got the Dragon wired up and verified it's programming the chip with a meter. Biggest obstacle was the stupid DIP package. Will be doing a proto breadboard tomorrow to check if it's better to use the ADC input or a clock line and the I/O might be complicated by how the LED's are driven. But so far so good on step 1 of the process

Thanks armorer, I referred to your earlier post once I had it wired and ready to test.

# ? Oct 18, 2013 00:47

TwystNeko: Dec 25, 2004; *ya~~wn*

I mounted the matrix inside the helmet now, so here's a test vid of the current animation setup. Now that I've finally got internet back, it's time to work on the code some more.

https://www.youtube.com/watch?v=oMICZyqtKHI

Part of the reason there's a variance in color is the visor has a really lovely dye job done on it, applied from the guy who sold me the kit.

I missed my internet. Moving sucks.

TwystNeko fucked around with this message at 05:59 on Oct 19, 2013

# ? Oct 19, 2013 05:56

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:08

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

That looks pretty sweet.

# ? Oct 19, 2013 18:11

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

«‹›53 »