Paul & Sabrina's cheap DIY 144v motor controller

[MazdaMatt]

dcb, i don't mean a software uart. I mean the Uart handlers. Generally for any mpu you're working with, someone (private or from the mfg) has produced a Uart.c that contains hardwware init code (pass it your baud rate and settings, it sets up the registers), interrupt handlers, efficient buffers, etc. The hardware layer is covered, the uart.c would handle the transmission of characters and then an application layer would observe the incoming characters, compare them to the protocol and call the appropriate functions as well as take outgoing message commands and package them up in the protocol and send them to the uart.c for transmission.

[charlie_fd]

Originally Posted by MPaulHolmes

...
P.S.: Sorry about the nonstandard way of setting A/D channel for conversion. It's sort of like I was on a desert island, and was just programming as if there were no standards at all, just reading the ridiculous 308 page documentation and making stuff up as I went.
....

Paul,

Some of us in here are proffesional uC programmers. Some (including myself) are not. It is however benefic if more than one pair of eyes (hopefully connected to brains) are checking up the code. In order to allow everibody to understand faster we should think about refactoring the existing code to use as much as posible the same programming style/conventions. It's usefull in more than one way.

For example, the code:

ADCSRA |= 64;  // 64  = 01000000.  So, this sets the ADSC Start Conversion Bit. 
 while (ADCSRA & 64);  // Do nothing until the conversion is done.

could be written as:

ADCSRA |= _BV(ADSC);   // Set Bit7 on ATMega8. So, this sets the ADSC Start Conversion Bit. 
  while (ADCSRA & _BV(ADSC));   // Do nothing until the conversion is done.

Let the standard include files worry about which bit is ADSC and our code will perform the same on all uCs ...

We know you are bussy testing and improving. Let others (the pro-people preferably) take care of the refactoring and just concentrate on your work. But a group will not be able to work on the same code (not reliably) using snipplets in a forum. Please use the central repository: you will be able to see very fast what has changed, who did it and why, even decide to go back.

The use the example above here's how it looks (diff betwenn versions 7 and 8 of the file in the svn):

Changes r7:r8

Sorry if it sounds like a lecture ...

[dcb]

Originally Posted by MazdaMatt

dcb, i don't mean a software uart.

Nor do I, There seems to be traces of UART code already
/trunk/ - Open ReVolt - Trac

it needs to enable the data received interrupt and add the handler SIG_UART_RECV. Pretty much how all of AVR does it AFAIK.

examples in the atmega8 datasheet UART section starting on page 133:
http://atmel.com/dyn/resources/prod_...ts/doc2486.pdf

Originally Posted by charlie_fd

...Sorry if it sounds like a lecture ...

Problem is frequently people change stuff to fit their ideals and never test it. I personally prefer an "if it aint broke don't fix it" approach in situations where accountability is low (you aint getting fired if you mess up here). If there were some comprehensive unit tests to go along with the build it wouldn't be such a big deal, but that should be sorted out early.

[dlaing]

I agree with Charlie. Doing a refactoring without version control is going to be very tough. With it - one of us - could refactor the code on a branch while you continue making changes to the current code. Then - at a time of your choosing - that branch could be merged to the trunk. You'll hopefully suddenly have beautiful code that works identically to what used to be on the trunk.

I haven't worked with an avr chip before, and I'm still setting up my dev environment. Paul, what environment are you using? I might as well make sure I'm running the same thing.
Charlie, can I have access to your repository?

[dcb]

More important than _BV vs addition to zeroed bytes is testing though. I'm pretty serious about not checking in stuff in that hasn't been unit tested (beyond compiling). I think we need a complimentary device for developers to check that the CPU inputs and outputs still behave, and where we can add additional tests. I will start another thread though.

[MPaulHolmes]

Originally Posted by dlaing

Then - at a time of your choosing - that branch could be merged to the trunk. You'll hopefully suddenly have beautiful code that works identically to what used to be on the trunk.

I haven't worked with an avr chip before, and I'm still setting up my dev environment. Paul, what environment are you using? I might as well make sure I'm running the same thing.
Charlie, can I have access to your repository?

I downloaded the free AVR Studio 4.16, build 628, from Atmel.com. I got it here:

Atmel Products - Tools & Software

It's a bit down the page, next to a thing that says "REGISTER". It just means that you have to give them your email and a few other things.

EDIT: dcb, do you mean tested in the car? It would be sort of confusing having dozens of software versions, none of which have actually been driven around. What are the conditions that are required for a new revision to be added? I only uploaded a change once, and I'm not even sure where it ended up. I never checked. I'm sorry, but I'm really new at this and it's completely foreign to how I would normally think.

[esoneson]

We need to set some rules.

Let's keep things simple.

1. The only person that should have write access is PAUL. This will keep the repository in sync with Paul's latest and greatest blessed by Paul and Sabrina.

2. If you would like to contribute to the functionality, contact Paul and explain what you are doing. Then write/test your code as best as you can (unit test). Then send it to Paul for verification and integration and system test.

3. If it all works out and is acceptable to Paul (and any other testers he has), then he will have the option of adding the feature into the repository's main trunk.

4. If this is not acceptable, then you always have the option of checking out the latest 'Paul and Sabrina blessed' code, add, patch, merge and modify to your hearts content, check it in to your own repository as a major branch off of the trunk.

5. We could also create an 'untested feature' directory under (next to, or whatever) Paul's blessed code in the repository so that others can browse and may see something that they like and add it in themselves.

Paul should maintain control of what is in the main trunk.

Just my 2 pesos

Eric

[dcb]

seconded (though paul can delegate if he wants to take his time learning svn)

[MPaulHolmes]

Here's how I see things:

I am not the programmer that many of you are. You guys are way more qualified to make many of the changes that we're talking about. I don't want to stop anyone from doing what they are good at. Maybe until a few controllers get out to people, and more people can do their own testing, we could divide the software into parts that are not related to how the car drives, and parts that do relate to how it drives.

I see the serial communications stuff as not directly related to how the car drives. We would need to make sure that there is enough processing time available for it to happen, but I don't think that would be very hard. I think that this could be developed without too much thought to "testing by driving". I could be completely out of the loop on this one, which is nice, because I'm not the sharpest tool in the shed when it comes to serial communications programming.

I think getting the PWM and "A/D conversion complete" interrupts re-organized (like what dcb and David were helping with), the A/D conversions happening when and where they should, and issues related to timing and bits of accuracy of the A/D conversions, are all related to how the car drives. This would be nice to test in the car.

I think the PI loop can't be properly tuned without the serial communications feedback. If I had a Digital Storage Oscilloscope, it might be a different story, but I don't. The PI loop is like only 1 line anyway, so it's not a big deal. I think we should just get a value for Kp and Ki that make the car feel good while driving until the new control boards with the RS-232 interface get here.

Relating to refactoring the code, JayC started that process, so that might be a good place to start for someone who wants to continue with that. I think that's a good idea, David, about someone working on it, and incorporating it into the updated code. I'm going through his fixed up code right now (and typing this). I'll send the project to the RSVP server ( )in a couple minutes when I'm done, at least I'll try.

OK, so, does someone(s) want to continue work relating to the controller I/O and how to display the data, etc...? I think Adam is doing an awesome job!

Who wants to work on re-organization of the interrupts, maximizing possible resolution for A/D converter, figuring out where to stick the PI loop, stuff like that? I can help with this too, but I may need help. We need to test this one in the car.

Who wants to continue refactoring the code that I'm going to upload in a couple minutes??? Maybe it doesn't need any more refactoring? I am definitely not the one to say! haha!

[MPaulHolmes]

So, who can I email the refactored project to so that it ends up on where ever it's supposed to end up? I can't find the command "commit" to send the project to the svn server. The last time I "sent it to the server", I sent it to my own computer.