标签: adafruit

In line with my Caveman Diorama project, we've nowcome to the stage where we need to consider how to implement the fire around which a miniature version of yours truly and his cavemen companions will be relaxing, mulling over the events of the day, and commenting on the quality of the mammoth burgers we'll doubtless be munching.   I've actually been pondering this poser in the back of my mind for the past couple of months, but now it's time to leap into action with gusto and abandon.   It probably won't surprise you to learn that I'm currently planning on using an Arduino microcontroller and a bunch of Adafruit's NeoPixels as the basis for my fire effect. One reason for this is that I happen to have quantities of both of these little rascals close to hand here in my office. Having said this, I may change direction if it turns out we cannot achieve sufficient realism, but we'll see how we go.   We'll consider the actuall nitty-gritty details of the fire implementation in a future column. For the moment, one thing we know we're going to need is a good random (or pseudo-random) number generator upon which to base our fabulously flickering effects.   One way to create random numbers is to build a hardware random number generator (HRNG) -- also known as a true random number generator (TRNG) -- that is based on some physical process that generates low-level, statistically-random "noise" signals, such as thermal noise, the photoelectric effect, and other quantum phenomena.   The HRNG/TRNG level of super-randomness is great for applications like cryptography, but it's probably overkill for what I'm doing, not the least that I don't want to spend the time building one.   Of course, the Arduino does come equipped with a handy-dandy random() function, which is just what I need... assuming that this little scamp does indeed generate random numbers. Call me an old fuddy-duddy if you will, but this is the sort of thing that is easy to take for granted, only to be unpleasantly surprised somewhere down the line.   Suppose, for example, that I wish the various NeoPixel elements forming my fire to randomly switch between red, orange, and yellow (we'll also want to vary their brightness and duration, but let's not get ahead of ourselves). Let's further suppose that we want to weight things such that red is the predominant color, followed by orange, followed by yellow.   One way to do this would be to generate a series of random numbers between say 1 and 1,000, and to then say that any number from 1 to 500 equates to red, any number from 501 to 800 equates to orange, and any number from 801 to 1000 equates to yellow. The idea being that (over time and using these values) each LED will spend 50% of its time red, 30% of its time orange, and 20% of its time yellow.   But this only works if the random() function is truly -- or, at least, reasonably -- random. We'd all feel slightly silly if we ended up seeing only a tiny amount of yellow, and we subsequently discovered that the vast majority of our "random" (1 to 1,000) numbers actually resided predominantly in the 300 to 700 range.   In order to test this, I threw a simple program together that loops around creating 1000 X-Y pairs where each X and Y value is a randomly generated integer between 1 and 1,000. The core of this code is as follows:   for (int i = 0; i 1000; i++) { x = random(0, 1001); y = random(0, 1001); Serial.print(x); Serial.print(","); Serial.println(y); } You can Click Here to see the full code (such as it is). If you do, you might care to note that I'm trying to follow the guidelines espoused in the Embedded C Coding Standard by Michael Barr (or, at least, the guidelines I find to be most applicable to what I'm doing).   I then copied my 1,000 comma-separated X-Y pairs out of the Arduino IDE's Serial Monitor window and saved them in a NotePad *.txt file. You can Click Here to access these values if you want to play with them yourself (see also the discussions below).   So, now that I have my 1,000 comma-separated X-Y pairs, what do I want to do with them? Well, the obvious first-pass option is to generate a scatter plot and observe the result. What we would like to see would be an arbitrary distribution that is relatively evenly distributed across our 1000 x 1000 canvas. What we don't want to see is something that looks like the following, for example:   (Source: Max Maxfield / Embedded.com)   Actually, even the above would be (fractionally) better than seeing something like the following, which would tend to indicate that our random number generator is outputting different sub-sets of values into our 'x' and 'y' variables, which would certainly make our poor old noggins ache.   (Source: Max Maxfield / Embedded.com)   Of course, my next consideration was performing the actual plot itself. I had a quick Google (while no one was looking) and ended up using an online tool called plotly ( https://plot.ly ). Although the user interface ended up being a tad less intuitive than one might hope, I was certainly happy with the first-pass results, as illustrated below:   ( Click Here to see a larger image. Source: Max Maxfield / Embedded.com)   Well, I must admit that this is looking rather encouraging. Having said this, my chum Ivan (the "Moustache of Knowledge") just wandered into my office and observed that it might be worth examining the temporal and spatial relationships between the X-Y pairs in more detail. For example, is the average distance between the members of medium-sized groups of X-Y pairs constant across the whole canvas? Also, if we were to consider medium-sized groups of X-Y pairs whose members are generated close to each other in time, then are the members of those groups also distributed spatially across the whole canvas, or are they clustered and clumped together?   Remember that you can Click Here to access my 1,000 X-Y pairs. What we need is someone who has a clue what they are doing access to sophisticated plotting and analysis software and knows how to use it. Are you that person?

Ever since I’ve known Max, I have figured that there is no keeping up with him or even beating him -- that is until now when he challenged me to a design-off contest  over who could build the best pixel ring clock . So I thought to give it a whirl.   This is a work in progress. Comments are welcome.   Hardware I thought my clock’s display should be quite active when running, understand what I say to it, have capacitive-sense touch buttons that also would know when it was touched anywhere, and have a speech and audio playback synthesizer to complete the communication-to-human part of the beast. Lastly and obviously, no clock would be complete without a time-keeping mechanism, so a clock/calendar is included.   I ended up with the following for hardware and will give my reasoning: Arduino Leonardo . The UNO and Mega have a USB to TTL chip that connects to the hardware serial port, which ties up the hardware serial port that I want to use to talk to the voice recognition system. The alternative is using the software serial interface, which might work if changed to be interrupt driven – however, my clock is going to be too busy to have to take on this overhead. Available from SparkFun , the Leonardo has the USB built into the processor, which frees up the hardware serial port. It also makes the ‘bridge’ function to connect the PC to the voice system simple and easier to share with the debug-serial I/O console built into the compiler environment, not to mention that it also runs 115k baud with minimal overhead.   ChronoDot clock/calendar , available from Adafruit , was almost a no-brainer. It interfaces to the I2C wire bus, is very low power, and keeps outstandingly accurate time. Also it comes with the obvious other things required, such as the button-cell battery, for example.   EasyVR shield V3 , from Veear and available from Sparkfun . This little beauty is both a speech recognition engine and a sound player in one. Having extensive support and library, this board-shield offloads the Arduino from what would otherwise be an impossible task for the 16 MHz memory-limited processor. The hardware can be run in standalone PC mode, as well as ride on the Arduino, to make it easier to develop an operating environment. Its separate commander software that runs on the PC makes the job of teaching the device words (speaker dependent) and then downloading them a breeze. For Arduino code development, there are very good examples to use. Lastly, for speaker-independent additional-word supplements, a software tool can be purchased.   Groove Q-touch sensor , from EpicTinker , has the following features: Shares the I2C bus nicely, has 7 separate very noise-tolerant capacitive inputs, self calibrates, and is very small itself. For debug, three of the buttons can optionally be used already configured on the board’s underside.   The concentric, three pixel rings , which are 60 pixels for the outside-most ring, 24-pixel ring for the middle, and a 12-ring for the inside-most ring, make a tasty clock. This makes the minutes and seconds share the outside ring, the 24-ring for hours when in the 24-hour mode, and lastly the 12-ring to display the hours in 12-hour mode. Having the extra unused ring depending on the mode, allows it to be used for AM/PM indication, and status display of other clock functions such as voice, for example.   Power supply . An external power supply is required, since all-white/all-on and fully-bright pixels draw considerable amps. I chose the Recom Power RAC60-05S/OF  from Digi-key . It has room to grow at 10 amps, is relatively small, and is only about $21. One down-side note to mention however, is that whenever the supply draws more than a few amps, it ‘sings’ a bit, which could get a tad annoying if it turns out to be loud enough after mounting it inside the clock.   To get started: I hooked everything up as mentioned, and used digital pins 4, 7, and 8 for the 60-ring, 24-ring, and 12-ring respectively. I left the pullup resistors for the I2C bus installed on the Q-touch, because I changed the I2C library away from using the standard WIRE library, and the replacement didn’t enable the internal pullups. I will discuss this library replacement later.   Software At first it seemed logical to try to use everything stock and standard, as supplied by the manufacturers of each of the respective pieces, to save time and keep it simple, clean, and understandable. However, it quickly became apparent that to have a dynamic real-time display, something like an interrupt-driven task manager would make things work better. The manager would not need to be a full up pre-emptive multitasker operating system, but could be a single-level interrupting scheduler. Hunting around for exactly that on the web, I landed on something that was an outstanding multitasker  but wasn’t interrupt driven. To overcome this problem, I thought to give it a try as a quick poll in loop(), then add the interrupts as necessary. To its credit, this library is very full featured, having things like run once, run every time on a time, run a certain number of times, oscillate, pulse, stop, update, and find free event index. I found the   t.every( xMilliseconds, routineName, number-of-times)   quite useful, where it calls the routinenamed  every x milliseconds  for number-of-times and then stops.   All tasks are sampled to see if the timers are to be triggered for calls, each time the t.update() is run. As nice as this was to use, it had the down-side that PWM, millis() and other internal timer delays, as well as other timer library functions were not useable. So rather than expend energy to add interrupts, I thought to look for another solution that was already interrupt-driven, which led me to LeOS (little embedded Operating System) . While this was not as full featured, and lacked the run number-of-times item I wanted, it did have everything else, including interrupts, task restart, task change, etc. Much later on I would also discover, to my chagrin, that this scheduler was not compatible with the NeoPixel and WIRE I2C libraries, causing me to hunt/replace these with something that would work. To these ends I first found the Neopixel replacement, light_WS2812  which worked well enough, even though it was a very basic engine. Next I found the replacement for the I2C  which allowed to disable interrupts, set speed, and other nice things, but which mainly was compatible with LeOS. I did notice that this library didn’t enable the internal pullups, so I went to make sure there were external ones provided on at least one of the boards connected to the bus, rather than spend the time to find the software fix. After substituting appropriately this softI2C master to the function calls to the ChronoDot, I thought to tackle the touch controller, which I had working originally using the Wire library, prior to integrating LeOS. This was not to be.   At this point, I had a beautifully spinning and whirring display, eloquently running, voice recognition accepting a trigger-speech command, and responding with speaking the current time. However, I couldn’t get the I2C library swapped out for the WIRE library on the calls to the touch controller. It seems that the trouble lies in the compiler’s insistence that the I2C be declared in proper scope inside the touch controller’s library, where the I2C is itself a library. All the techniques I usually use to resolve such issues, such as pulling the code out of the library up to the top-level sketch, for example, have failed.   Some of you who read this, may have discovered a few OTHER quirks with the otherwise nice compiler. As an example that I ran across on this project, I had a function called serialIN(), which worked just fine as the code steadily grew, but then suddenly the compiler began complaining that serialIN was not defined in this scope. I worked for hours trying to fix this, until I accidentally renamed it to iserialIN(), which made the compiler happy! Now mind you, the serialIN was not a keyword (Serial.xxx with the capitol ‘S’ is a keyword, as it would indicate this by a change of text color). There were no constructors, classes or anything else that I could find, having been added, to cause the error. Not having much more patience to bear, I left it like this and decided to move on.   To solve this last seemingly insurmountable problem (to me) with the I2C library replacement for the touch controller, I welcome any ‘C’ guru to take a look at this and offer a suggestion/fix. I will supply the appropriate code snippets for all who brave forward.   iframe width="400" height="360" src="https://www.youtube.com/embed/Ov1ZI26uTFI?feature=player_embedded" frameborder="0" allowfullscreen/iframe   By the way, I have included a video of what I have so far, for you who are interested to drool over, or cry, as appropriate.   Thanks in advance!   Ivan Cowie

My dreams have come true. I am currently performing my happiest of happy dances (it's not a pretty sight). Let me explain. For the longest time, I've been looking for a sound effects card to use in my hobby projects. In the case of my Inamorata Prognostication Engine, for example, the front panel is festooned with antique push-buttons and toggle switches and knobs and dials. When I flick a switch on this little beauty, I don’t want to be disappointed with a sheepish "click" that sounds embarrassed to be making itself heard. My ears deserve to be caressed by a satisfying "ker-thump," followed by the sounds of clockwork contrivances and mechanical mechanisms and balls rolling down chutes and suchlike.   Sad to relate, I couldn’t find anything to fit the bill. For some applications synthesized sound might be the way to go, such as the effects one can obtain using a GinSing Shield , for example. In the case of my projects, however, I want to use real-world sound samples, so next I looked at traditional audio shields such as the WAVE Shield from Adafruit.     The WAVE Shield is described as being ideal for adding audio effects to one's projects. The problem is that -- like the vast majority of cards of this ilk -- it can only play a single audio file at a time. For my projects, by comparison, I want to be able to add "layers of sound" corresponding to different actions taking place.   Eventually, a group of us started to consider designing and building our own card, as discussed in Sound Effects Shield for Arduino: The Particulars . This project has been shuffling along in the background, but everyone is busy and nothing really substantial has emerged.   And then, just a couple of days ago, my chum Duane Benson sent me an email saying:   I've been busy getting ready for Maker Faire and haven't had time to work on our sound player, but this sound effects board may be what we're looking for.   "This" turned out to be the WAV Trigger board, which is supplied by our friends at SparkFun, but which was actually created by my new hero Jamie Robertson, who is a senior Disney Imagineer by day and a mad scientist designer by night (check out Jamie's Robertsonics.com website).   OMG! As I said at the beginning of this column, the WAV Trigger board is the answer to my dreams. The key feature is that it's Polyphonic , which means "many-voiced" or "capable of producing many sounds simultaneously." In fact, the WAV Trigger can play and blend up to 14 stereo audio streams at the same time, where each stream can be started, paused, resumed, or terminated independently. The board also automatically performs voice stealing , which means that -- if it's told to play a new audio stream while it is currently playing the maximum number of streams -- it will automatically drop the oldest audio stream and add the latest request to the mix.   The way this works is that you use an audio editor like Audacity to prepare your sound snippets on your host computing platform (Windows, Linux, etc.). You can use your own sound bites and/or you can download them from loads of websites. Then you copy these sound files onto a Micro-SD card, which you plug into the WAV Trigger board.   The board I have supports up to 1,000 uncompressed 16-bit, 44.1kHz stereo WAV files (CD-quality), which is way more than I personally need, especially remembering that I only require short sound snippets and an 8GB Micro-SD card can hold over 12 hours of stereo WAV audio. (I was chatting with Jamie on the phone earlier, and he is currently working on a new version of the firmware that will support up to 2048 tracks.)   The simplest way to use the WAV Trigger is by means of its 16 trigger inputs, which can be set to be edge or level sensitive, and which can be controlled by simple switches or by a microcontroller. In this case, activating a trigger input will cause a corresponding audio file to be added into the mix (the trigger-to-sound delay is typically only 8 milliseconds). Alternatively, you can control the WAV Trigger using a simple serial protocol -- an Arduino Library is available to make this easy -- that allows you to access all 1,000 sound files. But instead of my waffling on, check out This Video and tell me what you think.   iframe width="400" height="360" src="https://www.youtube.com/embed/UUkcs_XL5x0?feature=player_embedded" frameborder="0" allowfullscreen/iframe   I can’t help myself. I'm currently chuckling and chortling with delight. My WAV Trigger is sitting here on my desk looking up at me with a "hello handsome, are you ready for some fun" look (metaphorically speaking). What can I say? Yes, I am indeed ready for some fun. Watch this space for future updates as I integrate WAV Triggers into all of my projects.

One way I keep myself out of trouble is to always have a bunch of hobby projects on the go. A few years ago I started playing with Arduino microcontroller development boards. The great thing about these boards: they have so many add-on boards (called "shields") available, such as motor control boards, real-time clocks, and so forth.   There are also lots of cool things you can control with these devices, like tri-color NeoPixel LED rings and strips from the folks at Adafruit and the MSGEQ7 audio-spectrum analyzer chip from the guys and gals at SparkFun .   As you will know if you've played with the Arduino yourself, you often end up with a stack of boards mounted on top of each other. In the case of my Vetinari Clock, for example, I have an Arduino Mega at the bottom of my stack. On top of this, we have a large prototyping board containing the circuits used to drive my antique analog meters. Next, we find a smaller prototyping board carrying a real-time clock (RTC) and a temperature sensor. And, in the fullness of time, I'm going to add a sound effects card.   Now, one tiny fly in the soup, as it were, is the fact that — when you have a board stack like this — it can be a pain to locate, isolate, and debug any problems. So you can only imagine my surprise and delight when I came into contact with Guido Bonelli.     Guido, who is an Independent Consultant, has created a capriciously cunning device called a Dr. Duino , which he describes as "A shield for your shields!" The image below shows a Dr. Duino (the green board) sitting on top of an Arduino Uno (the blue board). In addition to providing a bunch of switches, LEDs, potentiometers, and suchlike, the Dr. Duino also allows you to monitor signals going up and down through the header terminals forming the stack. Furthermore, by means of jumpers, it allows you to break the vertical connections and inject your own signals into the mix.     If you have a stack of shields mounted on top of an Arduino Uno, for example, you can insert the Dr. Duino between the Arduino and the first shield, or between the first and second shields, or between the second and third... or you can have it sitting on the top of the stack.   As an aside, I typically use the larger Arduino Mega for my projects, so I live in hopes that Guido will develop a Dr. Duino Mega. If he decides to do so, he says that I can have some input into its design. Guido may live to regret this, because I have ideas rocketing around my head like fireworks, but we digress...   The reason I'm waffling on about this here is that Guido will be giving a presentation on the way in which he designed and implemented the Dr. Duino at the forthcoming ESC Boston .   But don’t just take my word for this; take a peek at this video and hear what the man himself has to say:     For your delectation and delight, I asked Guido to pen a few words describing his presentation, and he kindly responded as follows:   Please join me, Guido Bonelli, for an exciting dive into the world of “Making” using Arduino at this year’s ESC Boston 2015. There will be giveaways, so don’t miss out! Learning and debugging your Arduino project will never be the same again after you sit in on this session! So come learn how to effortlessly get started with Arduino and debug like a pro. In this session, we will delve into the blissful highs of building stackable hardware, coupled with the lowest of lows when trying to debug our megalithic towers of Arduino awesomeness. New to Arduino and don’t know where to start? Well this session is for you too! During this presentation, you will learn how to use a new type of shield called a Dr. Duino to kick-start your entry into Arduino development. We will start off with an introduction into the Arduino landscape, followed by a brief discussion of a personal project called Orbis -- The Amazing Kinetic Sculpture. In fact, it was the problems I encountered while building Orbis that spurred the development of the Dr. Duino Arduino shield. In addition to a teardown of Orbis’s hardware, we will discuss how 3D printing, Arduino shields, and laser-cut wood were used to realize Orbis. Next, we will review all of the pain-points associated with building a multi-shield Arduino stack and the difficulties that can arise with this method. Finally, we will take a more in-depth look at the Dr.Duino shield, which is like a Swiss Army Knife when it comes to debugging one's Arduino-based projects. I am very excited to be presenting at this year’s ESC and look forward to changing the way you Arduino!   Well, this is certainly one of the talks I'm planning on attending, not the least that I can corner Guido and hound him with regard to the Dr. Duino Mega I so badly desire him to create in order to make my life easier; after all, isn’t that what it's all about (LOL)?

项目描述 我要介绍一个关于mini打印机的教程，这个打印机可以通过Arduino Uno 和 Ethernet Shield 实现物联网。 Adafruit 物联网打印机 有人说 Adafruit的学习页是非常好的学习材料。的确是这样！！我很幸运在Adafruit上找到这篇文章。 IoT打印机项目简介如下。   构建一个“物联网” 的mini 打印机，它将完全听命于你! 这是一个有意思的周末项目，还带一个漂亮的激光机切割箱。一经组装，这个小打印机就连接以太网，获取网络数据并打印在宽 2 1/4″ 的收据打印纸上.我们写好的例程中将连接Twitter，根据你的要求搜寻API并检索、打印消息：你可以打印出 来自一个人，一个标签提到的词语等等！ 一旦你让他工作，你就可以轻松的调整我们的例程来定制打印机。 这个项目不是很难，但是需要一些光钎焊，所以你需要点使用烙铁的经验。你也需要一套小的傻瓜螺丝刀来装配盒子。你最好还有些Arduino的经验，这样你就能感受到下载IDE和上传我们例程的快感了。 完成此项目，需要Arduino 和 Arduino Ethernet Shield.当你阅读Adafruit的Arduino Ethernet Shield产品页时，你会发现WIZnet W5100芯片。 板子挑选（用于 IoT打印机的Arduino Ethernet Shield） Arduino Ethernet Shield中的W5100 因为IoT打印机是在售的真实商品，制作方法完全可以用于DIY，这篇文章对于那些对Arduino Ethernet Shield例程感兴趣的人很有利用价值。   更多信息，请参考以下链接： – 在售商品 http://www.adafruit.com/product/717 – 教程 Internet of Things Printer