cougar controller testing

[dcb]

Update, VMLAB refued to even start on my XP box. I'm about ready to say screw this software emulation testing stuff I think. Unless someone else wants to look at simulavr or something and has a glowing report, I'm not putting any faith in the software only simulators.

[charlie_fd]

I've just finished building a basic test board (uC, rs232, a couple of pots, buttons, leds ...).
For now I'm going to test the serial communication part for the controller on this one. Simple interrupt based transmit only, sending 16bit integers for temperature, pwm and pedal values. There will be no bcd conversion on the controller, I'll just write a dedicated client to receive, convert display and log this data.

[dcb]

Ok, can of worms but ok. Adam was messing around with client stuff here: http://ecomodder.com/forum/showthrea...tml#post106367 , I was rooting for java so anyone could use it, have used rxtx a lot Deploying JAVA with RXTX - Rxtx


just for example, here is a sample java prog that sends a character version of the serial bits to stdout and a hex converted version to stderr (9600, com2)

PHP Code:

import gnu.io.CommPortIdentifier;

import gnu.io.SerialPort;

import java.io.InputStream;

import java.io.OutputStream;

public class SerialMon {

    static InputStream input;
    static OutputStream output;
    static char[] hexstr = {'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'};

    static String toHex(int x){
        return ""+hexstr[x/16]+hexstr[x%16];
    }
    
    public static void main(String[] args) throws Exception{
        
        CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(
                "COM2");

        SerialPort port = (SerialPort)portId.open("serial madness", 4000);
        input = port.getInputStream();
        output = port.getOutputStream();
        port.setSerialPortParams(
                  9600,
                  SerialPort.DATABITS_8,
                  SerialPort.STOPBITS_1,
                  SerialPort.PARITY_NONE);
        while(true){
            while (input.available()>0){
                int x = input.read();
                System.out.print((char)x);
                System.err.print(toHex(x));
            }
        }
    }
} 


[charlie_fd]

And here is the result: Trevor has written an awt java app, I modified it a bit to work on my linux (with rxtxcomm), and we have a simple java client for the controller. The nice graphic representation of data to follow ...

L.E.: the current value is fake since my setup has the input pin for the current sensor not connected ... The PWM follows very nicely the change in Throttle

[MPaulHolmes]

Awesome! But I think 1701 for current might be a bit optimistic?

[charlie_fd]

well ... It looks like my idea of padding the transmissions with a pair of 0xFF is not going to work in all cases: when i slowly increase the throttle I confuse the algorithm at the moment the throttle value is exactly 0xFF and for a brief moment I get really funny values on my screen


l.e.: solution was simple using 0xFD 0xFF sync sequence should be safe. Actually any non identical 2 values above 0x02 each would work for our values (max 511 for all that we read)

[charlie_fd]

Fixed the bug. Attached is the client program running on windows this time.

I've uploaded the sources, the ready-to-run java ".jar" file and the binary drivers for windows, linux and mac to a subdirectory in svn for other people to use.

Jar file here: /trunk/javaclient/MotorClient.jar - Open ReVolt - Trac

Drivers: /trunk/javaclient/MotorClient/lib - Open ReVolt - Trac

... and the relevant code from the avr:

Buffer_StoreElement(&txBuffer, (uint8_t) (tmpThrottle >>8)); // Store value for throttleH into ringbuff
Buffer_StoreElement(&txBuffer, (uint8_t) tmpThrottle); // Store value for throttleL into ringbuff		
Buffer_StoreElement(&txBuffer, (uint8_t) (tmpCurrent >>8)); // Store value for currentH into ringbuff
Buffer_StoreElement(&txBuffer, (uint8_t) tmpCurrent); // Store value for currentL into ringbuff
Buffer_StoreElement(&txBuffer, (uint8_t) (pwmDuty >>8)); // Store value for currentH into ringbuff
Buffer_StoreElement(&txBuffer, (uint8_t) pwmDuty); // Store value for currentL into ringbuff
Buffer_StoreElement(&txBuffer, (uint8_t) 0xF0); // Sync Byte
Buffer_StoreElement(&txBuffer, (uint8_t) 0xFF); // Sync Byte

//enable USART "TX buffer empty" interrupt
UCSRB |= _BV(UDRIE);

[charlie_fd]

Trevor is making good progress ... He sent me the version with graphic representation of the loged values and it works really nice!

[roverT]

Originally Posted by charlie_fd

Trevor is making good progress ... He sent me the version with graphic representation of the loged values and it works really nice!

Charlie pointed out a few other things to clean this up a little.

my task list
-adjustable scaling on the chart (or fixed from 0 - 512)
-writing to csv
-change the end of packet suffix to FF F0 ( your code above looks like F0FF?)

the graphing is working pretty well, glitches every once in a while....not sure why, if its because of my pic or a software bug.

[charlie_fd]

Correct! 0xF0 0xFF. Already changed that in the java code in the svn.