The code has been updated to address bugs, and testing with the current Arduino platform (Uno) is nearly complete.
There are known problems with the auto-reporting of digital pin state. This applies to digital pins in INPUT more only; there are no known issues with digital pins in OUTPUT, PWM, or SERVO mode.
Still working on documentation and hoping for some user feedback before making the first official release. I will be heading to Burning Man at the end of the month, so progress on this project will be slow until I return. While I haven't set a date for
the 1.0 release, it's safe to say that the earliest it will be available is at the end of September.
I've been silent with the status updates for a while because of a heatwave that hit the Seattle area. I haven't been able to keep my computers powered up for very long before overheating became an issue. Regardless, all's clear now. I'm working
on a full programmer's guide and building a more comprehensive set of sample projects. Barring any new show-stopper bugs, I'll release v1 when the samples and docs are completed.
The first release candidate
is ready! Additionally, two new samples have been created to demonstrate the release candidate code. These samples are simpler than the previous samples, but more will
be provided soon.
Opening a Connection to an Arduino
Using Digital Pins for Output
Everything's clicking together and functioning well at this point. The only troubling bit is the code that automatically detects a connected device. As a result, I've decided to remove that feature and implement it in a future release, or as an add-on
component. Over the next few days I'll be updating the samples in preparation for a release candidate build. I don't know when it'll be available yet, but it will definitely be ready before July 4th.
I just checked in a bunch of unit tests. The unit tests are almost all completed now. One more file to test, Arduino.cs, but that's the largest file by far. I've done some ad-hoc functional testing, but nothing too formal. Once the unit tests are completed,
by 6/29 I hope, I'll start formalizing the functional tests so that everyone knows how this component is being stressed. When the functional tests are are all completed (and passing), I'll put out a release candidate build and start updating the documentation.
Enough has changed since the last beta build that I don't want to jump right into a release build. However, since I don't anticipate ANY interface changes from this point through v1, I'm calling the build a release candidate.
I haven't posted status in a few days because I've been working through this hairy "how to test digital pin control automatically" issue. I gave up for the time being and bypassed it altogether. I built a little 12-segment LED board with surplus
hardware I had lying around and wired it to the digital pins of the Arduino. Now I can test the state control of the digital pins all at once, but I still need to be watching the test to know if things worked.
Part of solving this digital pin testing issue was determining what the Firmata spec really meant to say and if the StandardFirmata sketch that I was using on the Arduino was really interpreting the sketch correctly. If you've used Firmata or Rhyduino (the
betas), then you know that digital pins are grouped into ports, so every interaction with a pin has to be done in the context of the port. When you aren't sure which bits in the data correspond to which pins on the board, trying to deal with a port of
pins at a time makes things messy. Therefore, I revised the digital pin handling code to add another layer of abstraction between the developer and Firmata. Now digital pins are controlled by an object called
and it allows you to directly change the state and mode of the pins individually. All of the Firmata stuff is completely hidden. Additionally, I'm happy to say that it's working perfectly. Whether or not the Arduino sketch
matches the Firmata spec doesn't really matter to me anymore. My code works, so that's all I care about. If
changes and breaks me, then I'll just update Rhyduino.
Previously, all Arduino<-->Rhyduino communication was done in the exact same way. Now I've created a special case for digital pins that have a binary state (HIGH/LOW). If you've read anything about refactoring then you might call this a (very)
bad code smell. I'm going to need to implement this same pin access interface methodology for the non binary digital pin states (Pwm, servo, etc.), and for the analog pins as well. I'll keep the direct Firmata message control methods visible, but I
for the documentation I will begin to focus on the newer ways of controlling the Arduino.
While trying to get my test rig working, I came across a pretty big snag in the handling of digital pins. The issue comes down to the fact that the StandardFirmata sketch handles digital pins differently than the spec defines. I should post something on the
Firmata boards to discuss this, but I haven't done that yet.
The StandardFirmata sketch expects that the bytes in a message describing digital data for port 0 will be contained in bits 3-8. However, the Firmata spec says that it should contain data in bits 3-7. It took me a while to figure out which implementation was
appropriate, and unfortunately I had to concede that the sketch is wrong and the Firmata spec is right. The clincher was that bit 8 is supposed to be used as a flag to indicate that the byte is a command instruction byte - if the 8th bit is a 1, then the byte
represents a command, but if it's 0 then the byte represents data. Therefore, the data byte for ports 0 and 1 should be used like this (from my understanding).
The black boxes indicate that the digital pins they represent are reserved for use internally
by the Arduino for serial communication. The red boxes indicate that those bits in the message data should not be used when passing in values (as opposed to commands).
To compensate for this ambiguity/confusion/misunderstanding, I'm reworking the way I expose the digital pin values to the users of the library. Currently, I assume that you know roughly how to use Firmata, but since the specification and implementation
don't agree, that's not a safe assumption to make. I'm reworking my handling of the pins so that Rhyduino will always know what the user/programmer is trying to accomplish, even if I'm not entirely sure yet how I'll translate that knowledge
into something that the Arduino understands.
(4:34pm) Ok, the observer backpack worked really well. I mean, so well that I'm fucking ecstatic and I feel compelled to share the code so you can see how easy it is to use.
The Test That Made Me Fucking Ecstatic
(noonish) In the process of developing some of the unit tests I found differences between the
and the Arduino implementation of it. Without taking sides, I'm going to assume the Arduino implementation is the correct one, because frankly, it makes more sense to me. However, this means I
need to do some functional testing before I can finish the unit testing so that I know what the expected behaviors are.
It's pretty important to me that I automate everything I can, with regard to testing, because I don't really enjoy running the tests. I get bored VERY quickly. Anyway, I came up with a test rig that could monitor my Arduino being tested and report the
results. If you're interested in how that's being handled, click
to check it out.
I've been working on creating the
and implementing some of the unit tests. I hope to have all unit tests and end-to-end functionality automated tests completed by the end of June. If you've been following the project and testing it out, please go to the discussion section
and let me know your thoughts. I'd like to hear what systems you're running it on and what your experiences have been like. Good or bad, others could benefit from the info as well.
Today I was experimenting with Charlieplexed LEDs, and my goal was to see if I could program it using Rhyduino. I was able to - no problem. I'll upload my test code into the source control system, but it'll never be part of a release. Perhaps as an
add-on initially, and then fully integrated later.
Built the first of the "How-to" pages:
Opening a Connection to an Arduino
. Next I'll start working through the other topics demonstrated in the sample code.
Updated the beta by adding servo control code and the MockArduino class. For more details go to the
Beta Release v0.8.2
I thought servo support was missing from the StandardFirmata sketch, but I was totally wrong! < poof > Now Rhyduino has servo support too! It's a big enough feature that I can't just introduce it in v1 without public testing, therefore, I'll
have to update the beta build. It'll be in version 0.8.2.
Turns out that the HW Virtual Serial Port tool works. Today I built an Arduino mock. It just sits there and responds to Rhyduino as if it were a real Arduino. This means I can do software testing without a physical hardware circuit. It'll speed things up
a lot. It also means that anyone who wants to try Rhyduino out can do so without having access to a physical Arduino device. This is high on my list of things to document.
I've decided that for proper testing of the software, I'm going to need to create a software mock of a physical Arduino. Fortunately, it looks like software from
will provide the functionality that allows our mock to emulate a serial port. This'll allow us to do cheap local monitoring of both devices simultaneously and enable developers to test new code
without having access to a physical device.
I've made it through all open issues that were required for v1. So now it's time to start writing some rougher test code to see if we can break it.
I have updated the beta code package to include a sample project that can serve as some basic documentation. I am making progress on the written documentation as well. Feel free to look it over.
Go to documentation