| View previous topic :: View next topic |
| Author |
Message |
mpthompson
Joined: 02 Jan 2006 Posts: 650 Location: San Carlos, CA
|
Posted: Thu Mar 08, 2007 4:16 pm Post subject: Support for ATtiny45 and ATmega8 going away? |
|
|
I'm going start ripping into the OpenServo source code to begin some testing for back EMF measurements as discussed in this thread regarding the future OpenServo ver. 3. While this work won't be checked into CVS for quite a while, I'm not planning on supporting the ATtiny45 and ATmega8 in the news code as currently supported in the CVS tree.
I have several thoughts on this:
At the time I added ATmega8 support it seemed like a good idea at the time, but I don't believe anyone is actually using the ATmega8 rather than the more capable ATmega168. The ATmega168 is a pin-compatible upgrade of the ATmega8 with twice the Flash and more capable timer features and other things.
The ATtiny45/85 support is a legacy from the early OpenServo ver 1.0 days and I also don't see it being used currently. It's possible that this code could be more useful as some people may be interested in revisting that design with newer hardware. However, right now I don't have the resources or bandwidth to build new ATtiny45/85 hardware to support the features contemplated for the version 3.0 OpenServo hardware.
The support for these MCUs is preserved in the CVS tree so if in the future someone does want to work with these MCUs on an OpenServo derived design, the code is easy to get at. I would be happy to help someone through the process if needed.
Does anyone else have thoughts on this?
-Mike |
|
| Back to top |
|
 |
ginge Site Admin
Joined: 14 Jan 2006 Posts: 1029 Location: Manchester, UK
|
Posted: Thu Mar 08, 2007 5:17 pm Post subject: |
|
|
Mike, I think you are correct in saying that the old legacy v1.0 code is not needed at this time.
I think it might be prudent to fork the codebase at this point and add a new tree for the upcoming v3 changes. If it is forked like this you would be able to use attiny/mega8/168 without too much trouble.
I agree that stripping the old code out of the new branch will help keep things cleaner.
Barry _________________ http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
 |
mpthompson
Joined: 02 Jan 2006 Posts: 650 Location: San Carlos, CA
|
Posted: Thu Mar 08, 2007 6:51 pm Post subject: |
|
|
Barry,
I'm not much of a CVS guru. Are you familiar with creating CVS branches for different development forks in the manner described? I could probably figure it out, but I would be more comfortable working with someone who has more current experience with CVS than I.
-Mike |
|
| Back to top |
|
 |
ginge Site Admin
Joined: 14 Jan 2006 Posts: 1029 Location: Manchester, UK
|
Posted: Thu Mar 08, 2007 10:41 pm Post subject: |
|
|
I'm a little rusty with CVS, I use SVN at work. I know enough to create a fork and get it up to scratch. I will run some local tests first... unless anyone else chips in.
Barry _________________ http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
 |
guru
Joined: 03 Jan 2006 Posts: 128 Location: St Pete Beach, FL
|
Posted: Wed Apr 25, 2007 3:42 pm Post subject: |
|
|
I've had quite a bit of cvs experience but I never had a need to branch (fork) before. I would recommend branching off v3 and continue with the v2 as the main trunk I think. I guess that really depends on how much the v2 will be further developed at this point though. But anyone already having the v2 checked out would next commit have to add a branch flag parameter to the commit if I understand correctly.
Branching can be a tricky deal.
Here is a good page on it:
http://www.netbeans.org/community/sources/branches.html
I have access to the cvs server. I can help, and would like to get started on updating the code for v3 next week.
In any case, the entire cvs repository should be backed up before anyone tries anything. !!!CVS can be tricky!!! I have since moved to SVN because of some of the quirks.
C |
|
| Back to top |
|
 |
youthreewire
Joined: 30 Nov 2008 Posts: 39
|
Posted: Mon Dec 01, 2008 6:06 pm Post subject: |
|
|
| It would have been great if the CVS repository was organised in terms of the Microcontroller versions. |
|
| Back to top |
|
 |
ginge Site Admin
Joined: 14 Jan 2006 Posts: 1029 Location: Manchester, UK
|
Posted: Mon Dec 01, 2008 6:15 pm Post subject: |
|
|
It doesn't really make sense to oraganise our CVS that way, as there are very few microcontroller specific blocks of code. For example, the Version 2 branch (AVR_OpenServo) has support for multiple processoes, including the attiny45, atmega8, mega88 and mega168.
A branch for each of those would make it an unmaintainable nightmare as one change in branch for mega8 will mean you have to edit the files for the other processors.
This is why we use the #ifdef's for identifying processor specific sections.
Here is a brief rundown of what each branch is for:
branch Openservo version CPU
AVR_OpenServo: Version 2 attiny45, atmega8, atmega88, atmega168
AVR_OpenServo-dev: Version 2.1 (now defunct) attiny45, atmega8, atmega88, atmega168
AVR_OpenServo_V3: Version 3.0 atmega168
AVR_OpenServo_V3-dev: Version 3.2 atmega168
Barry _________________ http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
 |
youthreewire
Joined: 30 Nov 2008 Posts: 39
|
Posted: Mon Dec 01, 2008 6:21 pm Post subject: |
|
|
| Thanks .(defunct means it is not working for any micro?) |
|
| Back to top |
|
 |
ginge Site Admin
Joined: 14 Jan 2006 Posts: 1029 Location: Manchester, UK
|
|
| Back to top |
|
 |
|