It's time to connect my turntable to the internet. We're in the last month, and I haven't sent a single bit to the cloud.
That's about to change.
I'm preparing my fixture to publish information. It's going to be a two-step exercise.
First, I'm going to share the light organ info. I'll send the state of my Highs; Mids and Lows LEDs to the world.
Once I have that working, I'm going to add speed info: is my Perpetuum Ebner running slow, fast or perfect.
From UNO to Yún
My UNO was running the light organ and servo lift code. Today's exercise is taking care that that info is ported to the Yún.
And to check that there's enough space left to talk to the cloud.
That was a fairly easy task. To cut a long story short: the code just ported straight away.
There's a tendency to play down the Arduino concept. But I'm very sold into it. It's a great platform to try out new things with an easy step-in cost; there are libraries for so many things. If you want to go low level, you can just do that. Nothing stops you from going bare metal. When I have difficulties talking to a particular ship, I often turn to an Arduino to set up a prototype that I can probe with my logic analyzer.
And in this particular project, I can just switch to a WiFI enabled Yún. Just like that. It's at those moments that you really understand why Arduino has had such an impact. |
There wasn't any software issue during the switch. I changed port and board type, loaded the code, and off I went.
There is a slight difference in sensitivity of the ADC that I have to fine-tune.
I haven't found the reason for it yet, but particularly in the high frequency range, the Yún's ADC is more sensitive than the UNO's.
This results in my green Highs LED being on more often.
That's something I can compensate in software. But I'm still curious on why that happens. I'll have to pull up Atmel's data sheets.
The second thing to consider when porting, is the form factor of the Yún. More specific: the USB and ethernet connectors.
The protoboard that's part of the enchanted objects package doesn't fit out of the box.
This is what I have done to it:
I used my fake dremel and sliced the board in half. That way it fits on the Yún.
I loose the SMD pads - something I would have liked to use, I have some nice Texas Instruments SMD opamps - but you can't have it all.
With both hardware and software ported, I'm ready to reach for the clouds.
MQTT and Me
I have previous experience with the protocol. I've used it for my Christmas Wreath of Things.
If I'm expecting an issue, it would be space or compatibility related.
Regarding space, I'm optimistic. I tried to add the MQTT libraries to my sketch, and initialize some objects to get an appreciation of the memory use.
Sketch uses 16,356 bytes (57%) of program storage space. Maximum is 28,672 bytes. Global variables use 1,138 bytes (44%) of dynamic memory, leaving 1,422 bytes for local variables. Maximum is 2,560 bytes.
Nothing alarming there.
Library incompatibility is something more difficult in the Arduino world. In particular when libraries are using lower level components of the controller.
I have issues in my design. The motor PWM engine, speed sampler and servo libraries compete for the same hardware timer.(and are incompatible because of that).
I solved that by using two different Arduinos. It's a bit silly because one ATMega has enough juice to do all the work.
The right approach would be to either find libraries that work together, or write my own firmware.
I'll leave that as an academic exercise for the reader.
I'm just hoping here that the Servo lib is compatible with the MQTT and Bridge part...
Top Comments