Comments: MiniGen Hookup Guide

Pages

Looking for answers to technical questions?

We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.

  • Landscape Futurist / about 5 years ago / 1

    Got the MiniGen for my university's students to use. To allow switching between 3v3 and 5v power, I cut the trace between the 5v and GND pad, then soldered a trio of (trimmed) long male header pins (needed to bend them closer to work) to use with a jumper shunt.

    But right after soldering, the pads pulled off the board when minor torque was applied to the pins :-(

    As the pads still seem to be connected to the boards traces - fingers crossed that superglue will do the trick.

  • Member #1512799 / about 6 years ago / 1

    I've had same problem as you. In my case error was in hardware - put jumpers on VIN 3.3----5 V "VIN - By default, this goes to a 3.3V regulator. If you want to use the board with a 5V Pro Mini, you should put a blob of solder on the jumper pads on the back to connect all three together." In my case problem solved :)

  • Member #1154319 / about 7 years ago * / 1

    I am aware that this post is a bit old, but I am trying to use the MiniGen with the Arduino Due.

    It is not working, and that's why I writting here.

    The connections I have done are:

    fsync => pin 10

    sdata => mosi

    sclk => sck

    The MOSI and the SCK are from the pinouts labelled SPI (I have tried also the ones labelled ICSP).

    As Vin for the minigen, I am using the "power" labelled 3.3V of the Due.

    I am using the Arduino IDE 1.8.4. I have use the build in library manager to install the minigen library. I went to example from external library and load without any problem.

    However, I do not get anything that makes sense in the oscilloscope...

    Any help?

    Thanks for your time. Jofre

    • SFUptownMaker / about 7 years ago / 1

      Have you verified activity on the MOSI, SCLK and FSYNC lines with your scope? Or better yet, with a logic analyzer?

      • Member #1154319 / about 7 years ago / 1

        For information, I have load "Barometric Pressure Sensor" under example for DUE. It is indicated as a comment that the clk is in pin 13. If I load the code, I can see the clk in the oscilloscope! So I think the problem is soft rather than hard. I found the SPI.h used by that example but the contents are too cryptic for me...

      • Member #1154319 / about 7 years ago * / 1

        Good point, let me check them. I do not have a logic analyzer, but an oscilloscope (40MHz ; 500MS/s) Pin04 = 3.28V (constant, no 'activity') : Pin10 = 0.00V (constant, no 'activity') Pin52 = 0.00V (constant, no 'activity')

        MOSI (at SPI) = 3.00V (constant, no 'activity') : clk (at SPI) = 3.00V (constant, no 'activity')

        MOSI (at ICSP) = 0.00V (constant, no 'activity') : clk (at ICSP) = 0.00V (constant, no 'activity')

        I have tried standard Arduino examples and they are working fine (I do not think that I have brick the Arduino already...) Thanks for trying to help

        • SFUptownMaker / about 7 years ago / 1

          You mean, you've tried standard Arduino SPI examples? I'd do that and make sure SPI is working.

          The MiniGen library is pretty basic from a hardware point of view, and the fact that it compiles strongly suggests that things should work right. Have you set the I/O pins for MOSI, FSYNC and SCK to outputs? That may be necessary...

          • Member #1154319 / about 7 years ago * / 1

            Yes, I tried the "Barometric Pressure Sensor" example and I found what seems plausible signals in the mosi and clk pins (this time, the code says explicitly at which pins they are: MOSI: pin 11, SCK: pin 13). I re-load the MiniGen example and checked the signals again, but nothing this time...

            Regarding your comment "Have you set the I/O pins for MOSI, FSYNC and SCK to outputs?", I thought the MiniGen library was doing that for me... Do I have to do it manually? In any case, the documentation of the example does not indicate that it needs to be done.

            I do not understand... in the https://www.arduino.cc/en/Reference/SPI it is cleary said that the MOSI is at ICSP-4 and the SCK is at the ICSP-3, which I did check. Also, in the 'hardware.cpp' file from the SparkFun_MiniGen_Arduino_Library has a comments: // configSPIPeripheral() is an abstraction of the SPI setup code. This // minimizes difficulty in porting to a new target: simply change this // code to fit the new target.

            So it seems that by default, the fsync should be at pin10, but I did not measure anything...

            I should point out that I performed such measurements without the MiniGen connected.

            • SFUptownMaker / about 7 years ago / 1

              Try adding this code to the setup() function:

              SPI.setDataMode(SPI_MODE2);  // Clock idle high, data capture on falling edge
              pinMode(_FSYNCPin, OUTPUT);  // Make the FSYCPin an output; this is analogous
                                         //  to chip select in most systems.
              pinMode(10, OUTPUT);
              digitalWrite(_FSYNCPin, HIGH);
              SPI.begin();
              

              • Member #1154319 / about 7 years ago * / 1

                Yep, me again. I have modified the library from MiniGen to remove all the reference to SPI, so I handle that. I have check that the there is bits going in at the same time than the clock, and i have simply grounded fsync, so it is always listening. However, the code does not seem to react to the type of the waveform or the frequency. (I was not expecting so many issues...) The code is:

                    MiniGen gen;
                
                    void setup()
                    {
                      SPI.begin();
                      SPI.beginTransaction(SPISettings(4000000, LSBFIRST, SPI_MODE2));
                
                      gen.reset();                          delay(2000);
                      gen.selectFreqReg(MiniGen::FREQ0);    delay(2000);
                      gen.setMode(MiniGen::SQUARE);         delay(2000);
                      gen.setFreqAdjustMode(MiniGen::FULL); delay(2000);
                
                      static float frequency = 2000.0;
                      unsigned long freqReg = gen.freqCalc(frequency);
                      gen.adjustFreq(MiniGen::FREQ0, freqReg);
                    }
                
                    void loop()
                    {
                    }
                

              • Member #1154319 / about 7 years ago / 1

                I have copy paste the bare minimum from the MiniGen library and put it directly on the ino file. I get activity now, and after reading all morning different things, I would say I am doing things right (assuming the MiniGen library is ok). However, there is still no sinusoide in the oscilloscope...

                My code is:
                #include <SPI.h>

                void MiniGen_SPIWrite(uint16_t data)
                {
                  int16_t FSYNCPin = 10;
                  digitalWrite(FSYNCPin, LOW);
                  SPI.transfer((byte)(data>>8));
                  SPI.transfer((byte)data);
                  digitalWrite(FSYNCPin, HIGH);
                }
                
                void MiniGen_reset()
                {
                
                  uint32_t defaultFreq = freqCalc(100.0);
                  // set FREQ0
                  defaultFreq &= ~0xC000;
                  defaultFreq |= 0x4000;
                  adjustFreq(defaultFreq);
                  MiniGen_SPIWrite(0x0100);
                  MiniGen_SPIWrite(0x0000);
                }
                uint32_t freqCalc(float desiredFrequency)
                {
                  return (uint32_t) (desiredFrequency/.0596);
                }
                void adjustFreq(uint32_t newFreq) // Uses FREQ0 always
                {  
                  uint16_t temp = (uint16_t)newFreq;
                  temp &= ~0xC000;
                  temp |= 0x4000;
                
                  MiniGen_SPIWrite(temp);
                  temp = (uint16_t)(newFreq>>14);
                  temp &= ~0xC000;
                  temp |= 0x4000;
                  MiniGen_SPIWrite(temp);
                }
                
                void setup() {
                  SPI.begin();
                  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE2));
                
                //  sig_gen.setFreqAdjustMode(MiniGen::FULL);
                  uint16_t configReg = 0x0000; 
                
                  // Select FREQ0
                  configReg &= ~0x0400;
                  MiniGen_SPIWrite(configReg); delay(2000);
                
                  // Define Full Mode
                  configReg &= ~0x3000; configReg |= 0x2000;
                  MiniGen_SPIWrite(configReg); delay(2000);
                
                  MiniGen_reset(); delay(2000);
                
                //  sig_gen.setMode(MiniGen::SINE); delay(2000);
                  configReg &= ~0x002A; configReg |=0x0000;
                  MiniGen_SPIWrite(configReg); delay(2000);
                }
                
                void loop() {
                  unsigned long freqReg = freqCalc(1000);
                //  //sig_gen.adjustFreq(MiniGen::FREQ0, freqReg);
                  freqReg &= ~0xC000;
                  freqReg |= 0x4000;
                
                  MiniGen_SPIWrite(freqReg);
                
                  delay(1000);
                }
                

              • Member #1154319 / about 7 years ago / 1

                Ok, I have tried those lines, which do not compile because _FSYNCPin is not defined, so I declared:
                int16_t _FSYNCPin = 10;
                Now it compiles and loads fine, but still no activity

              • Member #1154319 / about 7 years ago / 1

                But those lines are not excecuted when in the example (line 38) does "MiniGen gen"? (I am a Fortran person, so some times I get lost with C code...)

                Maybe not... I'll try tomorrow when I get back to my lab (it's 22h here in France).

                Thanks a lot anyway SFUptownMaker!!!

                • SFUptownMaker / about 7 years ago / 1

                  Pretty sure I have it figured out, and the answer isn't good.

                  SPI has four "modes", which define whether the clock is high or low when idle, and whether the data latches on the rising or falling edge of the clock. Apparently the Due only supports Mode 0, and the MiniGen needs Mode 2.

                  This means that the MiniGen will not work with the Due until the Due core is fixed to support other SPI modes.

                  I'm sorry, but there's nothing I can do to make the Due work with the MiniGen.

                  • Member #1154319 / about 7 years ago / 1

                    It's me again. I found the following document where the person's code uses explitcitly the mode2 on a DUE (4th page of http://schianorobotics.altervista.org/Arduino_DUE___DAC_MCP4922.pdf)

                  • Member #1154319 / about 7 years ago / 1

                    Apparently the Due only supports Mode 0

                    That's surprising. I was observing what it seemed sensible signals in clk and miso. Where did you find that information? Moreover, the "modes" are just different conventions of when to go high or low of logical levels. It is very strange that they have implemented one and not the others...

                    • SFUptownMaker / about 7 years ago / 1

                      I observed it in effect. No matter what mode you pass to the setDataMode() function, the resulting data output timing is the same.

                      It's probably possible to write code to set up the Due to use mode 2 (the reference you linked is consistent with what I observed; the author mentions the DAC uses mode 0, and doesn't understand why mode 2 works. It works because it's NOT mode 2, it's mode 0), but that's going to involve digging into the datasheet and finding out how to configure the peripheral manually. That's a whole can of worms I'm afraid I don't have time to open.

  • Member #35679 / about 8 years ago / 1

    An interesting aspect of this board is, for me, contained in the declaration that "Though the MiniGen is technically a shield it can, in fact, operate as a stand-alone board..." Maybe I'm looking in the wrong places, or don't understand what I'm reading, but I can't find any guidance that I can use to do this. (For some kinetic sculptures, I need to output a ~12Hz sine wave to an audio amp which is driving a voice coil motor...) At present, I'm using an Arduino ProMini to run the miniGen, which works fine, but is kind of wasteful. Any tips would be welcome. Thanks!

  • -------------------- Tech Support Tips/Troubleshooting/Common Issues --------------------

    Connecting to a 3.3V Arduino Pro Mini

    You basically stack it on the Arduino Pro Mini 3.3V/8MHz. If you are just using wires between the two boards, here are the connections:

    MiniGen <=> 3.3V Arduino Pro Mini
      GND   <=>        GND
      VIN   <=>     VCC (3.3V)
     SCLK   <=>    SCK (pin 13)
     SDATA  <=>    MOSI (pin 11)
     FSYNC  <=>     CS (pin 10)
    

    Connecting to the Arduino Uno

    The MiniGen was designed for 3.3V with the Arduino Pro Mini's footprint but it should compile correctly for the Arduino Uno. You just need to add solder jumper to all three pads on the back for 5V and make sure that you are connecting to the correct SPI pins:

    MiniGen <=> 5V Arduino Uno
      GND   <=>        GND
      VIN   <=>     VCC (5V)
     SCLK   <=>    SCK (pin 13)
     SDATA  <=>    MOSI (pin 11)
     FSYNC  <=>     CS (pin 10)
    

    Connecting to Arduino Mega

    The MiniGen was designed for 3.3V with the Arduino Pro Mini's footprint but it should compile correctly for the Arduino Mega. You just need to add solder jumper to all three pads on the back for 5V and make sure that you are connecting to the correct SPI pins:

    MiniGen <=>    5V Arduino Mega
      GND   <=>         GND
      VIN   <=>     VCC (5V)
      SCK   <=>  SCK (pin52 or ICSP-3)
     SDATA  <=>  MOSI (pin51 or ICSP-4)
     FSYNC  <=>       CS pin 10
    

    Testing this out with the different Arduinos listed above on an oscilloscope, I did not have any issues generating a signal.

  • Member #816983 / about 8 years ago * / 1

    Hi,

    I try to run this module with a Leonardo card. For now, that's not success!

    My Connections: Leonardo pin to 10 pin Minigen FSYNC

    Leonardo ICSP MOSI pin to pin Minigen SDATA

    Leonardo ICSP SCK pin to pin SCLK Minigen

    First, my connections are they correct?

    • SFUptownMaker / about 8 years ago / 1

      They seem correct to me. The Leonardo may need a different pin to connect to FSYNC, however.

  • Member #616379 / about 10 years ago / 1

    In the hook up guide you say CPOL = 0 and CPHA = 1, what corresponds to SPI_MODE1, but in the library you are actually using

    SPI.setDataMode(SPI_MODE2);

    what is now correct? I am trying to get it running on an arduino due.

    • SFUptownMaker / about 10 years ago / 1

      Try mode 2, if that's what's being used in the library. I'll go back and review it and figure out which is correct.

      • Member #616379 / about 10 years ago * / 1

        Did you every try to connect it to a Arduino Due? There are some funny things happening with the SPI: http://arduino.stackexchange.com/questions/4900/spi-arduino-due-conflict-with-pinmode-bug

        In the Data Sheet of Analog Devices of Programmable Waveform Generator on page 4 it looks like SCLK is high on idle, so it is probably not SPI_MODE0 nor SPI_MODE1. And on page 13 they say "data is shifted into the input shift register of the device on the falling edges of SCLK...." MODE 2 is correct. So that should be corrected in the hookup-guide.

        • SFUptownMaker / about 10 years ago / 1

          Will correct.

          We haven't tried it on a Due- we made the decision that the Due and other 32-bit Arduino devices are too unstable at this time for us to sink a great deal of effort into making examples for them.

          The link you posted certainly underscores that; there's a definite hardware configuration fail going on there. Hopefully the Arduino folks resolve that in a future release.


If you've found an issue with this tutorial content, please send us your feedback!