I am in the middle of a project that combines hardware design and software to operate that hardware. Please do not ask for all the specifics as it is proprietary. I will provide as much as I believe is needed and as I can. The hardware has been designed and tested with another PIC device (PICAXE 08M2). No hardware problems were apparent, so that part of the design is fairly fixed at this point. One of the goals of this project is for the hardware to be as universal as possible as regards the micro controllers/PICs that it can operate with. Hence, I am now tasked with the job of writing driver and demonstration software for additional devices and the Arduino is next on my list. I have an Arduino Uno to play with but the code I come up with should be usable with as much of the Arduino line as possible, with the least amount of modification.
In addition to being a complete novice with the Arduino, I am also a beginner with C++ code. I am currently on about page 85 of a Dummies book on it. Probably going to take me another week or so. Also looking up things on the internet and asking a question or two on a C++ BB. Hopefully I will be able to avoid some stupid questions on basic C++ symtax, etc. But I would like to ask some general questions so that I can better determine the rough course I need to follow in doing this. This will help me to focus on the parts of the C++ language that are more important in this task. And also to choose a good general approach.
The code will probably be divided into two parts: first the necessary routines to actually communicate with the hardware and second a main routine that will demonstrate it's various capabilities. Communication is one way only, from the microprocessor (Arduino) to the hardware. The communication routines will need to send groups of 14 bits from one pin of the Arduino with 14 clock pulses on a second pin when the data bit has been set. Because each data bit has it's own clock pulse, the hardware is tolerant of a wide range of transmission speeds and I assume that I can always slow the transmission down with some kind of Pause instruction or routine if the Arduino runs too fast. The PICAXE, running at a 4 MHz clock gave me no problems: I actually wanted it to run faster. I believe the Uno will be significantly faster. The data transmitted will consist of one 8 bit data word and 6 additional bits, 3 before the data word and 3 after. These bits will be constant except for the third one in the leading group. The pattern, in order of transmission, looks like this: 1 0 ? b7 b6 b5 b4 b3 b2 b1 b0 0 0 0. This sequence is fixed in the hardware and would be quite difficult to change at this point.
For the PICAXE I used subroutines. I started with two, one for each choice of the third bit. Once that third bit was set, these two subs then passed control to a third sub which actually transmitted the full 14 bits. Subroutines are probably the only way to do it for that processor due to it's simplicity. And there are a couple of additional subs for some necessary housekeeping: five all totaled.
The main part of the PICAXE program then simply called these subs with the appropriate data to demonstrate the various uses of the hardware.
At this point I would like to ask for some thoughts as to how this type of thing could/should best be accomplished on the Arduino. I assume that I could follow the PICAXE model and just use subroutines. But, as I understand it, C++ has a feature called library files. So I wonder if they could be used to create the communication routines? Or perhaps there is another way? What would be the best approach? What approach would you prefer if you were purchasing this device and it's software? Which would be the easiest for the user to learn and use? And, which would be possible for an inexperienced C++ programmer, like myself, to be successful in creating?
One more thing, I AM completely aware of other serial communication protocols, like I2C. These were considered when the hardware was being designed. However, they were rejected for a number of reasons. One of which was the requirement for compatibility with as many microprocessors/PICs as possible. Another one was to allow at least one of the lines/pins used to serve for additional purposes when pins were in short supply. The scheme chosen will allow the data pin to be used for other devices as long as the clock pin is not pulsed. And there were others, so the hardware is really fairly fixed at this point and the communication method I described above will probably be the final one used.