[Prev][Next][Index][Thread]

Re: Wanted ideas for using one code base with multiple mice



I would support Garry's suggestion of git for source control. It is very flexible and well suited to this task. Each source tree is also a repository making it very useful for taking.a working copy out to contests. There are good free hosting services that will allow access to repositories from anywhere. On the other hand it is not huge fun to learn the finer points of it's use. For me, the main thing I did not like compared to subversion was the relative difficulty of seeing the history of a single file. Then again, subversion would regularly screw up my repositories. It is much harder to do than with git.

Decimus 1 and Decimus 2 use very similar hardware. Wherever possible, specific hardware is accessed only from a single file per peripheral. For example, the ADC has a single code file and header with generic looking functions like adc_init() and adc_read(int channel). Changing the underlying hardware is then easier. Even if you wanted to use DMA or clever sequencing, it should be possible to hide this behind suitably generic function calls.

Things like pin assignment and where printf sends it's output are determined by the IDE's configurations. It is common for an IDE to have a debug and release configuration. I have these for each mouse and a common code set. A single "platform.h" has a #if define statement that selects either "decimus1.h" or "decimus2.h" as appropriate.

So far so good but I am less sure now that it is the right approach. For example, it does not make it easy to use different algorithms with different mice. Say you have a mouse with six sensors and a mouse with four sensors. How much common code is there? What about the stuff all wrapped up in edge detection and steering? They may end up very different but still have a number of common areas. Factoring those out could get complicated but should be possible.

More recently, I have started to think in terms of shared libraries. Here, for example, I might consider the maze solver. This code might be common to several mice and an improvement in one of the functions could probably be included immediately in all the mice that use it. Again, a common interface hides implementation details.

On 16 Aug 2011, at 06:38, Harjit Singh <zeetahhs@hotmail.com> wrote:

Thank you everyone for the many suggestions.
 
Some thoughts:
I do use a source control program - Perforce. I will expend some effort to understand branches.
 
I did spend sometime thinking about a hardware abstraction layer/separating the code into device dependent and device independent but I think it will be a struggle for me.
 
Just yesterday, I spent some time thinking about how do you abstract out something as simple as the PWM. Currently, it is setup for ten bits but should I leave it as that or make it a fraction and then translate (don't really want to because of the overhead).
 
In any case, I'm leaning towards separating out the mouse specific items into "equivalent" but separate files and that way, I can do comparisons between them and use that to move stuff over. I wish there was a way to mark a set of differences as "acceptable" so that when I did comparisons, these set of differences wouldn't be flagged but I'm not aware of such a tool.
 
Again, thank you very much for the many different view points and guidance. Once I get this implemented, I'll follow up with my findings.
 
All the best.
Harjit

Email has been scanned for viruses by Altman Technologies' email management service

Email has been scanned for viruses by Altman Technologies' email management service