Tom.DeVito 3.9.2011

Aurdino – SOMO 14D interfacing:

  • Serial communication is a bit more difficult then I thought it would be because the SOMO does not follow any standard protocol.  Instead you have to time the clock cycles and data timings manually.  Luckily someone has translated the 4D Systems sample code to work with the arduino:  http://forum.sparkfun.com/viewtopic.php?f=14&t=21388
  • The code doesn’t do exactly what I want but the main important part is the sendData(int) function:
  1. void sendData(int ThisSong)  //it says this song but it can be any 16 bit command
  2. {
  3. int TheSong = ThisSong;
  4. int ClockCounter=0;
  5. int ClockCycle=15;//0x0f;
  6. digitalWrite(pinClock,HIGH); // Hold (idle) for 300msec to prepare data start
  7. delay(300);
  8. digitalWrite(pinClock,LOW); //Hold for 2msec to signal data start
  9. delay(2); //2msec delay
  10. while(ClockCounter <= ClockCycle)
  11. { digitalWrite(pinClock,LOW);
  12. if (TheSong & 0x8000)
  13. {digitalWrite(pinData,HIGH);
  14. }
  15. else
  16. {digitalWrite(pinData,LOW)
  17. }
  18. TheSong = TheSong << 1;
  19. delayMicroseconds(200); //Clock cycle period is 200 uSec – LOW
  20. digitalWrite(pinClock,HIGH);
  21. ClockCounter++;
  22. delayMicroseconds(200); //Clock cycle period is 200 uSec – HIGH
  23. }
  24. digitalWrite(pinData,LOW);
  25. digitalWrite(pinClock,HIGH); // Place clock high to signal end of data
  26. }
  • Considering there may be a time I will not have the code given to me, its best to explain whats going on here so that I know how to do this with just data sheet timings.
  1. Lines 3-5 set up are pretty basic.  Declare a counter, declare a maximum, pass the parameter into the function.
  2. Lines 6-7 set the clock to high for 300ms to ensure a data reset between consecutive commands
  3. Lines 8-9 a two ms low tells the SOMO that the data stream will begin.
  4. lines 10-23 is the while loop.  16 cycles for the 16 bits of data
  5. line 11 sets the clock to low between bits.  The first run its already low so it doesn’t really matter but it doesn’t hurt to set it to low again
  6. lines 12-17 was really confusing to me at first.   I am used to only using Boolean operations within if statements.  & is a bit wise function comparison function.  Instead of checking the whole thing to see if its the same it checks each bit and only produces a 1 when both are 1 and 1.  Every other combination produces a 0.  So by comparing the command to 1000000000000000(0x8000) you will only get a non-zero value(true) if the leftmost bit is a 1.  If its true it sends a high and false sends a low.
  7. line 18 bit shifts left to test the next leftmost bit during the next cycle
  8. lines 19-22 I am not sure why this has a 400us delay.  The total cycle period is supposed to be 200us,  high should be 100us, and low should be 100us.  I guess as long as its consistent and under 1ms it will work.  The two delays are in place to ensure the clock cycle takes at least 400us(it should be 200us).
  9. lines 24-25 are just used to set the idle state.  A high on the clock line lasting more then 2ms stops that data transmission.  The data line doesn’t have to be set low during idle but why not.
  • The 300ms delay(+20ms processing after command is received) between commands is a bit long.  Our amplifiers are much quicker(100ns per pulse cycle*steps) so this shouldn’t hurt response time too much except on initial contact.  I believe when you send the command for select track and it will auto play but if you have to do two commands to do this that would be over a half second delay…  I can probably minimize this by having a delta t function which measures the time between commands and delays the difference if its under 300ms.