Daniel Garcia   Mark Kriegsman  , The aurbee team (kickstarter,

fastled-random
gplus
(Peter Spriet) #1

@Daniel_Garcia @Mark_Kriegsman , The aurbee team (kickstarter, poststamp arduino with zigbee integrated) revealed their specs.
To me the processor specs look very similar to a teensy 3.1 (but with the extra of zigbee). Does this mean that the fastled (2.1) lib would be compatible with it ? (or am I dreaming too much …)
https://www.kickstarter.com/projects/1973729481/aurbee

(Ashley M. Kirchner [Norym]) #2

Wow, they’re using 64K of flash memory for their “Aurbee stack”! Plus another 12K of ram. That’s a chunk!

(Jon Burroughs) #3

I think that the price point in the future could be a problem too. If they go over the $40 mark, I’m not interested.

(Peter Spriet) #4

Price of a “bare” aurbee is indeed crucial. In an earlier communication they claimed it would be in the RFDuino range => $15-$20. But on the kickstarter not yet a word about it.
But If price is <$20 and commanding 1 aurbee from another one is as simple as they claim it Than it could open a world if interesting led installations.
1 big virtual CRGB of different aurbee is most probably a challenge (I think zigbee communication speed is not that high)
But ie starting synchronous different aurbee driven (fast)led strips seems to me a simple thing.

(Jon Burroughs) #5

My conclusions in working with Xbee’s, is that the less info you send over the air, the faster you can send more data. If all remote arduinos are synced to a master clock, you could trigger events, based on time, to multiple devices in the field. I don’t have a proof of concept yet, but I am thinking this is the only way to get unison events from multiple devices. This would mean each remote, would require a super accurate clock source, that could sync to the master remote control.

(Daniel Garcia) #6

The fact they’re using the k20 would make it easier to port - but unless they’re using the same pin out as the teensy3, it’d still take me a couple (calendar) days to do.

(Daniel Garcia) #7

The port is more something that I’d most likely need to do as we abuse low level i/o registers and asm code to get the performance we want out of things. Luckily, from first glance, it looks like you’re using the same K20 as used in the Teensy 3.1 so hopefully it’s just a matter of getting the pin mappings defined. (If you’re using the same gpio mappings as the teensy 3.1 then there may not need to be any porting work done, beyond making sure that the defines that identify the chip used for compiling work as well - and since i’m flagging off of the MK20DX256 compiler define, it should work for your setup as well).

(Ashley M. Kirchner [Norym]) #8

@Aurbee Hey, don’t get me wrong. Just doing what you did in and by itself is a great achievement. And regardless of the 64K being taken up by the stack, the remaining memory (both FLASH and RAM) is still more than what the most common AVRs have in them.