Forum Replies Created

Viewing 15 posts - 46 through 60 (of 108 total)
  • Author
  • in reply to: Maximum Length with EasyTransfer #2595

    100 meters is too long for simple serial. You would need to use differential signaling (like 485) over twisted pair.


    Are you still having the problem? What if you force the code to see it as a dualshock?

    in reply to: Arduino Due & PS2X Library!!! #2593

    I don’t have a Due to test against. Did you fix it.

    in reply to: Arduino Due & EasyTransfer Library !!!! #2592



    Can you detail how you fixed it? I’ll add it to the code. I don’t have a DUE to test against.

    in reply to: SFEMP3Shield works with Arduino Due #2591

    gallegojm replied to the notification email instead of submitting a response. His email:


    i Michael
    I almost finish to redact this e-mail when I see you send me an other mail. You are faster than me!
    Well. I send you now what I was redacting before I make the test with the Due


    Hi Michael
    I shall try to answer all your questions:

    1) PROGMEM does not exist on the SAM3X8E.

    Yes. SAM3X8E has no EEPROM but plenty of flash memory for code (512 kBytes). So PROGMEM does not  exist.
    Notice that the function F( “…” ) does not generate error under Due but don’t do anything.

    2) There is a problem reading back the MP3reset pin.

    6) I don’t understand the reason for digitalRead(MP3_RESET) not reading back the MP3_RESET pin. Do you know of a reason for this? Perhaps you could direct me to a Link explaining why. Or is this something you are observing?
    I am suspicious this may because of the SparkFun MP3 shield is actually designed for 5V. Where the Due is only 3V which may not be supplying or reading proper signals.
    Is it possible that your board or PIN is not actually going low and resetting?

     On Due reading a digital output always return a low value. (,151120.0.html ,,157749.0.html and more) .
    That is why I add the variable mp3Reset. I think it is not a bad idea to do this for all the configuration, because it is faster when you need to test the state of the pin. What do you think? Would you prefer an other name for the variable?

    3) SPI member functions between UNO and DUE have some differences.
    a. SPI.tranfer’s member function requires the Chip Select in the function call.
    b. Default setup can’t be used for setBitOrder and setDataMode
    c. setClockDivider is obviously different

    5) cs_low() and dcs_low(), you have commented out ” SPI.setClockDivider(spiRate);” and not replaced it with “SPI.setClockDivider( MP3_XCS, spiRate );”.

    Yes, “the SAM3X8E has advanced SPI capabilities” ( )

    This is related with SAM3X8E SPI capabilities. “If you specify one of the Arduino Due’s Slave Select (SS) pin in the call to setClockDivider(), the clock setting is applied only to the device connected to the specified SS pin” ( )

    I just see now I can increase velocity for multiple transfers (like in function Mp3WriteRegister() ) using aditional parameter SPI_CONTINUE calling SPI.transfer()

    What Shield are you using and how have mated it to the DUE?

    I use an Arduino Ethernet shield between the Due and the MP3 shield.
    On the Ethernet shield I solder 3 wires to connect SPI pins MOSI, MISO and SCK from SPI connector to digital pins 11, 12 and 13 and I bent this pins
    I also cut the bridge between digital pin 4 and GPIO1 on the MP3 shield as it conflict with SD card select of Ethernet shield.

    I think I have to try now to ensure there is no conflict with Ethernet library and if that is right try to merge Due’ modification to you library

    in reply to: Triggering mp3 file over serial #2374

    (responding to jayceekey’s email)

    Fileplayer.ino that michael was referring too is in Michael’s branch of the code available here.

    in reply to: Does this interfere with SPI? #2349

    This is a problem with the Virtual Library itself. I would not know how to change it. I suggest contacting the writers of Virtual Wire.

    in reply to: Maximum Length with EasyTransfer #2348

    The library itself will handle 255 bytes. However, the Serial buffer is only 64 bytes. So if you want to use more than 64 bytes, you must check for new messages very fast, faster than the buffer can fill up at your baud rate.



    in reply to: ps2 not working #2195
    in reply to: Pressure mode not working with 1st party Dualshock 2 #2194

    What kind of controller is it? As I understand it, not all 3rd party controllers had pressure sensors, and wouldn’t go into a mode they don’t support.

    in reply to: Does this interfere with SPI? #2193

    My guess is you are running out of RAM. Does the code do anything else when the audio shield stops working, something to make sure the code is still running?

    in reply to: Interference with millis() function #2171

    From the Arduino Reference on attachInterrupt()


    Inside the attached function, delay() won’t work and the value returned by millis() will not increment. Serial data received while in the function may be lost. You should declare as volatile any variables that you modify within the attached function.

    I imagine this is because the user’s function is nested inside the Interrupt vector and therefore global interrupts remain disabled while the user’s function runs. The millis() method uses timer overflow interrupt to increment.

    AVRs support nested interrupts. I wonder if there’s any harm in just re-enabling global interrupts first thing in our refill function Michael? Might cause unexpected delays in the SPI stream to the decoder/SD card but that might be tolerable.

    Jim, What Michael suggested should work. But if your willing try editing your version of the library as such:

    void SFEMP3Shield::refill() {




    void SFEMP3Shield::refill() {




    and you might have to #include <avr/interrupt.h> at the top of the file. See if that breaks anything.

    in reply to: little problem with timing #2164

    Oops, forgot to show you how to send that. It’s simple:

    struct SEND_DATA_STRUCTURE { //Send commands

    byte commands;


    And That’s it. 6 of the 8 bits in commands hold all your boolean values as 1s or 0s.

    in reply to: little problem with timing #2163

    I don’t know what could be wrong without looking at the rest of your code, but I do suggest a more efficient way to do what you are trying to do.

    You are trying to send 6 boolean (yes/no) values, however the smallest unit of data in an AVR is a byte of 8 bits. So each boolean uses up a whole byte of data space. So to send 6 yes/no values you are using up 6 whole bytes or 48 bits of data. Instead, you could encode all of your boolean values into a single byte. Here’s an example:

    //first create a naming to position address convention, this is just to make it easier for us
    #define SCAN 0
    #define FORWARD 1
    #define STOP 2
    #define REVERSE 3
    #define LEFT 4
    #define RIGHT 5

    //create a variable that will hold all the values.
    byte commands;

    //When we want to set a value to 1 (true) we do this
    bitSet(commands, FORWARD);
    bitSet(commands, LEFT);

    //When we want to clear a value (set to 0, false) we do this
    bitClear(commands, RIGHT);
    bitClear(commands, SCAN);

    //When we want to act on the different values
    if(bitRead(commands, FORWARD) == true)
    Do Something;

    if(bitRead(commands, SCAN) == false)
    Stop Something;

    So it looks a bit different but it is a much more efficient way to encode binary (on or off) information. Give it a try and see if it works out for you.

    You could also set a value directly from a digital input pin like this:

    bitWrite(commands, FORWARD, digitalRead(13));

    That will set the FORWARD bit TRUE if pin 13 is HIGH or FALSE if the pin is LOW.

    in reply to: Compile error #2160

    Further history into this in case you are interested:

Viewing 15 posts - 46 through 60 (of 108 total)