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

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

peepsalot posted:

A+

# ¿ Nov 30, 2012 15:36

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 05:05

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

I'm trying to use a teensy 3 with the fastspi library to drive some LED strips, but I'm not sure which pins on the teensy I should be using for the two signal lines (data and clock.) Possibly I'm just being daft, or not reading very well tonight, but so far, my goo-fu seems to be lacking. Anyone got any hints?

http://www.pjrc.com/teensy/pinout.html
http://code.google.com/p/fastspi/

e: Oh poo poo, I really am being daft. It's 19 for clock and 18 for data, isn't it? :downsgun:

# ¿ Dec 10, 2012 04:17

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

Yeah, I hopped on the teensy boat with the 2.0++, then somehow missed the 3.0 kickstarter, but bought a pinless one as soon as I found out they existed (because the pinned ones weren't in stock.) Finally got some header pins soldered on mine today, so far seems to be working great. The only thing that caught me off guard was that I spaced on it being USB micro rather than USB mini like its predecessors, so I had to wait a couple days on a cable from monoprice.

Be advised, you'll want to go here for the latest teensy-compatible arduino dev environment, since it's still in beta at the moment: http://forum.pjrc.com/forums/6-Announcements

e: I'm double-dumb tonight, it's those green pins on the pinout I want for my SPI stuff I think. I'm just having all kinds of brain farts tonight.

ee: Ah HA! Got it. Pin 13 and pin 11. I don't know why that was so hard. :P

Bad Munki fucked around with this message at 05:47 on Dec 10, 2012

# ¿ Dec 10, 2012 05:22

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

I use the arduino environment. The goal of the project is for it to be a drop-in replacement for the arduino, and run as an add-on to the arduino environment. It does pretty well at that, imho. Of course, as is true with an arduino, nothing's stopping you from hacking it up however you like, as long as you have the know-how.

# ¿ Dec 10, 2012 06:08

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

Yeah, just easing in and easing out your plain old waveform will do wonders for softening a tone. For a sort of "ding" sound ease in over, like, 1/10th of a second, and ease out using a log function for however long you want.

# ¿ Dec 13, 2012 22:00

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

Radioshack is all right in a pinch, and as long as you aren't in one that is JUST cell phones, they'll usually keep their parts bins fairly well stocked, but I find that their parts are generally 5-10 times more expensive than, say, digikey or mouser, even after you factor in shipping. I mean, a buck for a 5-pack of resistors? Really?

The other stuff (shields and displays and PICs and kits and such) sounds a bit surprising, though. Could be that whoever runs that particular shop is into that stuff, I know they have a fair degree of freedom as to what they stock.

Bad Munki fucked around with this message at 15:30 on Jan 30, 2013

# ¿ Jan 30, 2013 15:28

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

I think it really depends on whether it's a cell-phone radioshack or a "proper" radioshack. The shacks in Fairbanks AK, Des Moines IA (two of them there that I checked), and even the mall here in Erie PA all carry discrete components.

As for the employees knowing anything about the stuff, yeah right, I mean, their job is to operate the cash register. Sometimes a manager will be able to help you find a part, but it's usually little more than "the parts drawers are over there." Which is all pretty understandable to me, really: brick and mortar stores really can't compete with these online shops like digikey and mouser that can offer a zillion individual parts at cut-rate bulk prices, it's just not feasible. So instead they have to offer a very limited selection, and mark the parts up enough to even make it worth the time it takes to stock them, and even then, they sell so little of it that most store managers probably just view it as wasted space.

# ¿ Jan 30, 2013 16:07

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

That sounds like an exceptional setup, that's pretty cool. And yeah, there's a lot to be said for being able to fondle a few parts and then walk off with them.

# ¿ Jan 30, 2013 16:55

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

Just for kicks, try putting single quotes around the url:

code:

wget 'http://www.angstrom-distribution.org/feeds/2011.03/ipk/glibc/armv7a/base/emacs_22.3-r1.6_armv7a.ipk'

# ¿ Jan 31, 2013 04:18

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

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.

And yet the package as a whole is incredibly accessible to even the greenest of experimenters. There's a ton of value in that.

# ¿ May 8, 2013 20:21

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

If you accept the Arduino as a sort of lowest-common-denominator solution, you'll find it's really not that aggravating at all.

# ¿ May 8, 2013 20:34

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

Because not bridging--or worse, widening--that gap promotes elitism on one side and disenchantment on the other?

# ¿ May 8, 2013 20:52

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

I bet the requirement was more along the lines of having to know EXACTLY where the code that was actually being executed was coming from and what it was. For example, with C, someone could alter the compiler to sneakily inject some nasty code to do nefarious things that the developer wasn't aware of. :tinfoil:

# ¿ Sep 5, 2013 18:46

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

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

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

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

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

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

That looks pretty sweet.

# ¿ Oct 19, 2013 18:11

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

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

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

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

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

# ¿ Dec 5, 2013 15:32

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

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

# ¿ Dec 5, 2013 18:38

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

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

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

# ¿ Dec 5, 2013 19:46

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

Post a trip report when you get a satisfactory solution. I haven't run into it yet so I haven't even bothered to look, but I do have some projects in mind where SPI and I2C would be critical factors.

# ¿ Dec 21, 2013 01:31

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

ante posted:

Big drill bits can definitely fit kibbles in the flutes.

# ¿ Jun 10, 2014 03:43

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 05:05

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

https://www.arduino.cc/en/Tutorial/Debounce

# ¿ Sep 8, 2015 14:11

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