While waiting for my 1 Channel USB Powered Relay Module to arrive I'd like to start on the software to control it. The User's Guide does a great job of detailing the commands, but doesn't indicate how the board will respond when given a bad command like "relayonn 64", or an incomplete command like "relay on" where the relay number's not provided. Could you you help by telling me how the device would respond? Tks.
When an incompatible/bad command is entered, the device will respond with a new prompt as if nothing happened. We understand that ideally the device should respond with some kind of error code. But this behavior had been the norm for a long time and can not change without breaking compatibility with software written by many hundreds of existing customers. We are working on a new firmware stack that is designed from the ground up to resolve this dilemma and to add a lot more features. The new stack will be compatible to existing hardware and one will be able to switch between legacy firmware stack and new firmware stack at will. Hope this answers the question. Please let me know if I can help with any additional info. Thanks, Tom Numato Lab
Appreciate the quick reply. The new firmware stack sounds like something I'd be interested in using. Any information available on when to expect the new firmware (2nd quarter, 3rd quarter, this year, next year)? Assuming "compatible to existing hardware" means I could load the new firmware on my recently purchased device, what programmer & programming software are recommended? Is it too late to suggest features for the new firmware? If not, how could I provide input? These may already be included, but I'd like to suggest new commands to query the current configuration of the GPIO pins (if currently set as output, input, or adc). The current state of GPIO's set as output pins (if pin is currently set ON or OFF, similar to "relay read" for relays). Commands to toggle a relay or GPIO output pin for a user specified time (turn a relay on or off for a user specified number of milliseconds then return it to it's previous state. would allow module to be used to reset power on the device controlling it [assuming module has a separate power supply], and allow precise timing when using direct terminal control of the module). Along with error codes for the command related errors already discussed. Thanks, Jay
Hello Jay, below are the answers based on currently available information. This project is still in its infancy so the details may change as it progress. We are planning a beta release by end of this quarter (Q1 2015). This release is expected to have only limited features though. All currently shipped hardware is pre-programmed with a bootloader. So the user should be able to switch between legacy firmware stack and the new firmware stack on all previously bought hardware. We are planning a hardware upgrade as well in the mean time. The exact details on compatibility, upgrade options and feature support is still being planned. More info should be published along with the first beta release. Not too late for sure, In fact it is never too late to make a suggestion. We are always happy to consider suggestions as long as they are feasible in terms of backward compatibility, hardware/software limitations and necessary efforts. All of the features that you have requested are already in the list of items that are being implemented. The new firmware stack is primarily designed to be used with application programs, not with serial terminal emulators. So it may not have a command line interface like the current firmware. There are couple of reasons why we have to avoid serial emulation. The most important once are some issues with Microsoft's CDC ACM driver and the serial emulation code taking up too much space in the microcontroller and thus making it impossible to add newer features. The current firmware with command line interface will still be fully supported/actively maintained and bug fixes and other improvements will be implemented.
