Show Posts
Pages: [1]
1  Development / Other Hardware Development / Re: $4 Cypress PSoC 4/ 4200 Prototype Board on: July 29, 2014, 12:28:14 am
Hi Ray,
That is great to find your post. I was just trying to tie the same hardware together (PSOC4 board and 2.2" SPI TFT).
Tonight and unsuccessfully!

If you would not mind, could you post or send me your PSOC project , so that I could look through how you got it working?
Thanks,
Bill
2  Products / Arduino Due / Re: Problem with SerialUSB.write on the Due on: January 04, 2013, 07:32:33 am
Could someone let me know where the Arduino bug list is so that this issue (SerialUSB.write on Due) can be collected into the next revision?

Also, in CDC.cpp there are a number of locations in which SERIAL_BUFFER_SIZE should be replaced by CDC_SERIAL_BUFFER_SIZE.

Thanks in advance.
3  Products / Arduino Due / Re: Problem with SerialUSB.write on the Due on: January 03, 2013, 08:29:37 pm
Yes, I am replying to my own post. The problem seemed to lie in USBCore.cpp, routine USBD_Send. The data pointer in the loop at the bottom was not being updated. Here are the changes to USBD_Send (two lines) I made to take care of the issue:

//   Blocking Send of data to an endpoint
uint32_t USBD_Send(uint32_t ep, const void* d, uint32_t len)
{
    uint32_t n;
   int r = len;
   //const uint8_t* data = (const uint8_t*)d;
   //THIS IS A CHANGE FROM CONST TO UPDATE THE POINTER - WRD
   uint8_t* data = (uint8_t*)d;


    if (!_usbConfiguration)
    {
       TRACE_CORE(printf("pb conf\n\r")smiley-wink
      return -1;
    }

   while (len)
   {
        if(ep==0) n = EP0_SIZE;
        else n =  EPX_SIZE;
      if (n > len)
         n = len;
      len -= n;

      UDD_Send(ep & 0xF, data, n);
//THIS IS AN ADDITION: UPDATING THE POINTER - WRD
      data += n;
    }
   //TXLED1;               // light the TX LED
   //TxLEDPulse = TX_RX_LED_PULSE_MS;
   return r;
}

The Arduino Due line: SerialUSB.write(test_buf,16384); now appears to actually send all of the 16384 bytes.
And by the way, with 64 * 16K transfers, I am getting around 8Mb per second transfer rates.
4  Products / Arduino Due / Problem with SerialUSB.write on the Due on: January 03, 2013, 02:35:48 pm
I have been doing some testing of the Native USB port by sending a large chunk of data (1 Megabyte) from the Due to a Windows 7 I3 notebook computer.
I create a 16K (16384) buffer of ramp data (0 to 255) and then transmit it to the PC using:

       for (int j = 0;j < 64;j++){
         SerialUSB.write(test_buf,16384);
       }

Everything tested fine, I had a C# program reading in the 1 Megabyte, checking for the 0 to 255 repeating ramp. 100% OK.
Then on the Arduino Due side, I decided to fill half the array with a different pattern, to make sure the PC side would catch the bad data. It didn't.
What I found was that SerialUSB.write repeats the first 512 bytes for any array transmission larger than 512 bytes.

Could someone point me to where SerialUSB.write is defined in the Arduino structure?
Thanks!
5  Topics / Science and Measurement / Native USB port on: January 02, 2013, 02:16:51 pm
Just started looking at the Native USB port. (The programming port seems to be working fine.) I can get my Win7 to install with this port as the BOSSA programming port after forcing the driver type in Device Manager.
Two questions:
1. After programming the Due with the BLINK sketch thru the Native USB port, it sometimes resets the port type to a non-functional Arduino Due in Device Manager. BLINK will then run. Other times the Native USB port remains BOSSA, but then BLINK will not run until the Due is unplugged and plugged back in. At which point the port is a non-functional Arduino Due in Device Manager.
Is this the way it is suppose to work?

2. I would like to use the Native port for high speed data transfer. Are there any examples out there for passing data to and from a PC? Would I use SerialUSB hinted at at arduino.cc?

Thanks in advance.
6  Topics / Science and Measurement / Re: Due A/D Speed Question. on: January 02, 2013, 02:01:10 pm
The Due has only ~96K bytes of SRAM... it lets you define an integer array of 256000? That does not seem right.

I am also looking for information on streaming data across the Native USB port but have not been able to get that port working at all.
Has anyone used SerialUSB or have a link to information on it?
7  Products / Arduino Due / Using the Hardware Quadrature Encoder Channel on the DUE on: January 01, 2013, 06:45:54 pm
Hi,
I would like to start working with the quadrature encoder hardware in the DUE. It appears you can use the pins TIOA0, TIOB0 and TIOA1 to decode 2 channel quadrature plus an index. (SAM3X manual p. 855) If my reading of the pinout is correct, this would be pins 2, 13 and AD7.

Could someone point me to any existing low level calls that might make this easier? I know, for instance, the Arduino code writes to the DAC using:
dacc_write_conversion_data(DACC_INTERFACE, 0x0000);

Is there a similar function for the decoder channels and where might I find these calls.
THANKS IN ADVANCE.
8  Using Arduino / Programming Questions / Re: Using Motor Encoder with Arduino? on: January 01, 2013, 06:32:16 pm
If you want to measure velocity profiles with your encoder, then you definitely need to use a timer/counter. I have used the Mega to do this a few times. You put the 2 quadrature encoder channels to the INT0 and INT1 pins 20 and 21 of the MEGA. You set up the interrupt vectors for either transition:
         EICRA = B00000101; //EITHER EDGE FOR THE INTERRUPT
         EIMSK = B00000011; //INT0 and INT1 ENABLED

You have two interrupt routines ISR(INT0_vect) and ISR(INT1_vect). Both basically do the same thing. In those routines, you grab the two bits from the encoder channels and determine the way the encoder is turning. (I do it by using two arrays CW and CCW.) You also grab the count from the interval timer, reset it and start it running again. The ISRs store the encoder position in one unsigned integer array, the position in the first position, the timer interval in the second position. The MEGA has 8K of SRAM so you can store about 2000 samples without resorting to external RAM.

byte CW[4] = {0x01,0x03,0x00,0x02};
byte CCW[4] = {0x02,0x00,0x03,0x01};

//BOTH ISRs do the same thing

ISR(INT0_vect){
  byte encoded = PIND & 0x03; //converting the 2 lower bit value to single number

  last_e_direction = e_direction;
  if (CW[encoded] == lastEncoded) {encoderValue ++; e_direction = 1;}
  else if (CCW[encoded] == lastEncoded) {encoderValue --; e_direction = 0;}

 lastEncoded = encoded;

//count is an unsigned integer that keeps track of the number of positions and timer intervals stored
  count+=2;
// ptr points to the array I am saving values in
  *ptr++ = (unsigned int) encoderValue;
// we use 16 bit timer 3 of the MEGA
  TCCR3B=0x00; //stop timer
//saving counter (time) value to the array
  *ptr++ = (unsigned int) TCNT3;
  TCNT3=0x00; // counter reset to zero;

  //enable overflow and input capture interrupts

  /* start timer, without prescaler, rising edge*/

  TCCR3B=0x41;
 //Collect data untill you have filled the array

  if (count >= HIGHEST_COUNT) EIMSK = B00000000; //INT0 and INT1 DISABLED; //stop the interrupts when we have collected the full number
}
 
9  Products / Arduino Due / DAC Speed on: December 31, 2012, 08:10:07 pm
I don't know if any one has posted on this yet, fastest update rate for a DAC(?). Here is some code:

int j = 0, topcount = 5;

void setup() {               
  // this is a cheat - enable the DAC
  analogWrite(DAC0,0);
}

void loop() {
 // write directly 
  dacc_write_conversion_data(DACC_INTERFACE, 0x0000);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0400);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0800);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0C00);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0FFF);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0C00);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0800);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0400);
  for (j = 0;j < topcount;j++);
//  delayMicroseconds(1);
  dacc_write_conversion_data(DACC_INTERFACE, 0x0000);
  for (j = 0;j < topcount;j++);

}

This code produces a triangular four steps up, four steps down ramp that goes from about 480mV to 2.32V. Each step is about 680ns wide.
The waveform becomes unstable below topcount = 5. Is this the fastest DAC step rate?
10  Products / Arduino Due / Re: Port manipulation PINx commands with Arduino Due ? on: December 31, 2012, 07:27:32 pm
To use REG_PIOD_ODSR use must first enable the bits with REG_PIOD_OWER (the output write enable).
For instance:

void setup() {                 
  pinMode(12, OUTPUT);
  pinMode(14, OUTPUT);
  pinMode(15, OUTPUT); 
  REG_PIOD_OWER = 0xFFFF; 
}

void loop() {
  REG_PIOD_ODSR = 0x0130;
  REG_PIOD_ODSR = 0x0000;
  REG_PIOD_ODSR = 0x0130;
}
 
Will produce a ~23ns low going pulse on pin 12, 14 and 15. For some reason you need to set the pinModes to make this work.

11  Development / Other Software Development / Re: Announcing BootDrive for Arduino on: March 01, 2012, 09:11:51 pm
Hi,
Thanks for posting BootDrive. Nice work... I migrated it to an AVR109 based booter. I did find one issue and a solution. If the HEX file contains a line shorter than 16 bytes, BootDrive does not load the correct code after that. Here is the code to correct that:

int leftover = 0;
unsigned char leftoverbuf[16];
int readPage(File input, AVRMEM *buf)
{
  int len;
  int address;
  int total_len = leftover;
  if (leftover > 0){
    memcpy(buf->buf,leftoverbuf,leftover);
  }
  // grab 128 bytes or less (one page)
  int i = 0;
  while (total_len < 128){
    len = readIntelHexLine(input, &address, &linemembuffer[0]);
    if (len < 0){
      if (i==0) total_len = len;
      break;
    }
//    else
//      total_len=total_len+len;
    if (i==0)// first record determines the page address
    {
      buf->pageaddress = address - leftover;
      leftover = 0;
    }
    i++;
//    memcpy((buf->buf)+(i*16), linemembuffer, len);
    if ((total_len+len) > 128)
    {
      leftover = (total_len+len)-128;
      memcpy(buf->buf+total_len, linemembuffer,128-total_len);
      int kk = 0;
      for (int k =(128-total_len);k<len;k++)
        leftoverbuf[kk++] = linemembuffer[k];
      leftover = kk; 
      total_len = 128;
    }
    else
    {
      memcpy((buf->buf)+total_len, linemembuffer, len);
      total_len=total_len+len;
    }
  }
 
  buf->size = total_len;
  return total_len;
 
}

Now, this page and all the subsequent ones will contain 128 bytes, until the last page (when it doesn't matter). I have tested it against another boot loader and was finally able to verify the code in memory was correct in two distinct ways.
Bill
Pages: [1]