Sparkfun Turbo compatibility with GPS Logger Shield

I am running across a similar problem- hope you can help.

I thought it might be handy to use the GPS logger shield as a basis for a GPS guided vehicle I am building. I figured that in using the GPS logger shield to start I could have my GPS and SD card which stores CSV files of my waypoint lists (RDDF) already on the same shield- only difference is that instead of logging GPS to the card I will want to be reading CSV lists from the card for my GPS routing. I have the Shield running on a RedBoard Turbo, because the speed and additional memory were attractive to me for this project. The GPS part works fine. I changed some of the comms mapping on the Turbo to assign the D2 and D3 pins as an additional UART for a 4d Systems LCD display and it is working beautifully. Pins D0 and D1 were left as is on the logger shield to handle comms with the GPS, and that part is working fine too so far with no physical wiring modifications.

I did need to swap the “stock” RX and TX select jumper settings on the 4d Systems LCD Display Arduino shield such that TX and RX are swapped, as the ports on the SAMD would not accomodate RX and TX on pins D2 and D3 without the swap. As it is now, though, it works fine.

My only remaining issue is in getting the SD card to function. I have been trying two different example sketches; the one presented in the GPS Logger Shield hookup guide, and the one presented in the SD Card Reader hookup guide, and I cannot get either one to even recognize the SD Card. I am using a new freshly formatted (FAT32) 16GB card. I checked the card in my laptop at it seems healthy. The only modification I made to the sketch was to change my serial port for monitoring over to SerialUSB, in order to save my other comm ports for the rest of the project.

I am designating D10 as my CS line, and other than that, the other SPI pins are 11-14 as they should be. I do not think I need to change anything physically with the RedBoard or the GPS Logger Shield in order for the SPI port to function, but do I need to define anything or otherwise change anything code-wise in order for the RedBoard to recognize SD Card on those pins?

I am also wondering whether the spi.h library will function as expected with the SAMD based RedBoard, or if the sd.h library would work as well. Interestingly, even though I installed the very latest version of the Arduino IDE when I first started this project, all of the SPI related and SD related examples I have seen state that sd.h and spi.h are both built-in libraries for the Arduino IDE. When I go to the libraries manager, I can see the sd.h library installed, but I could not find the spi.h library anywhere, only a few variations of it for specific applications. If I am compiling the sketches and including spi.h when spi.h is not actually installed, wouldn’t the IDE give me an error message stating as much? I am not sure where to go from here.

I mostly need confirmation on whether spi.h and sd.h will work with the RedBoard Turbo, and if so, where would I find the actual spi.h library? I think the issue lies somewhere in the SAMD’s compatibility with one of those libraries. - Any help is much appreciated.

OK so now with a little more digging I see that originally the legacy SPI port on the 6-pin header was tied to pins 10-13 on the side header. I should first mention that I have based many projects on RedBoards in the past, but this is my first SAMD21 board, and I have never configured a SPI port before. I suppose when they designed the GPS Logger shield they assumed the legacy SPI port and pins D10-D13 were physically connected on the RedBoard, so the documentation states that if the user is setting the shield up on a RedBoard, there should be no need to alter the SPI pin select jumpers.

It looks like the original RedBoards would have had the legacy SPI connector pins and pins 10-13 routed together on the board, so when they shipped the GPS Logger shield with the SPI select pins connected to both locations simultaneously, it would not really cause a problem if it were left that way (assuming some external device was not connected to both locations at the same time.)

However, it looks to me that the RedBoard Turbo has the legacy SPI location connected to a different port than pins D10-D13. This would mean that connecting the GPS Logger Shield to a RedBoard Turbo would short the pins from the legacy SPI port to the pins connected to D10-D13. I could see where this might cause a problem if I am correct that this is the way it is connected.

I do not know if I might have damaged the RedBoard or the shield plugging it in this way, but I am going to try cutting the traces on the SPI select jumper on the GPS Logger such that only pins D10-D13 are connected. Once that is done I will go back to attempting to make one or the other SD example sketches work.

If anyone else might have had success getting the RedBoard Turbo to run the GPS Logger Shield, please weigh in.

Thanks!- Rob

Hi Rob,

The SD Library and SPI should work just fine with the RedBoard Turbo but as I mentioned in [this post you will want to run the SPI lines to the 3x2 legacy header making sure to leave the Vcc/5V pin disconnected.

You should have no problems with those lines sharing connections with D10-D13 unless you need them for something else in your project. If that is the case, you can disconnect those to free up D10-D13 by adjusting the SPI Select jumpers on the bottom of the GPS Logger Shield. We cover how to do that in the [Hardware Overview section of the Hookup Guide.

Give this a try and if you continue to have issues logging to your SD card using the RedBoard Turbo, let me know and we can troubleshoot further.](https://learn.sparkfun.com/tutorials/gps-logger-shield-hookup-guide#hardware-overview)](https://forum.sparkfun.com/viewtopic.php?f=145&t=49946)

I had seen the other thread, but I was hoping to leave the legacy header available for another purpose. Nonetheless, I soldered a female header into the ICSP location, after being sure to omit the power contact from its location, and the sketch ran fine just like that.

I left the CS line on D10, and everything else stayed the same. I do not know why the SPI and/or SD libraries would not work with the D10-D13 location, but I figure there must be something specific to the workings of one or both of those libraries that allows it to only work with the ICSP/Legacy SPI port. Nonetheless, it is working reliably (and fast!) and I already have the sketch for parsing the data files working and giving me just the numbers I need in the correct order and format. Now on to the rest of the project!

If I may share a bit of the history and purpose of this project, it involves replacing/updating/streamlining the navigation system I had built many years ago for my entry into the original DARPA Grand Challenge offroad autonomous vehicle competition (Rob Meyer Productions - Coyote UGV). The original platform had a ruggedized laptop computer connected by serial (RS-232) to a BasicX-01 microcontroller which acted as an interface for a number of other microcontrollers (over a RS-485 network) running two Doppler Radar sensors, three Sonar sensors, a Scanning Laser Rangefinder, a Fluid Stabilized Magnetic Compass, a GPS Receiver and Differential Beacon Receiver, a CMU Cam Vision Sensor, and two Bumper Contact Sensors.

In order to overcome some bi-directional communication conflicts with the RS-232 connection between the laptop and the microcontroller interface side which worked, albeit slowly, I eventually built a simple parallel-to-series converter out of another BasicX-01 and then ran all of my control outputs from the laptop’s parallel printer port out to where the converted serial outputs then fed into a serial servo controller, which ultimately controlled the closed-loop steering servomotor, the brake motor, the E-brake air solenoid, the throttle, and the automatic transmission gear select servomotor. For whatever reasons which are beyond my understanding, I just figured out through experimentation that I could achieve lower latency by keeping all of the inputs on the laptop’s serial port, and running all of the control outputs through the parallel port.

I was able to build the system and have it running autonomous GPS courses by the second season’s event and I actually passed some of the preliminary portions of the competition, but by the time of the site-visit-demonstration portion, I had the car running GPS courses, but it still had no real functioning obstacle avoidance measures, which eventually led to my being eliminated from the competition at that stage.

I kept the vehicle, as well as the smaller “Javelina” autonomous rover which was electrically identical to the larger car, and which was thus used as the primary test vehicle for the larger system, and I continued to work to complete the obstacle avoidance features and test/optimize the system. Even though the larger car now sits unused in my shop, the smaller go-cart sized Javelina vehicle is now being pressed into service here on our farm as an autonomous bird-deterrent vehicle in our vineyards. I have it programmed to run routes along the outside edge of the vineyards, periodically sounding a 12-Volt air-horn to keep the birds from picking our ripening fruit off the vines. This is proving to be a great practical use for the little GPS-Guided car, as it frees me from having to take the time to drive around dealing with the birds myself. (of course we do employ other humane bird deterrent measures, but it usually takes a variety of approaches to achieve real effective control).

So what I am working on now is to replace the laptop computer on this little vehicle with a microcontroller-based system. I had originally equipped the car with the laptop as the central controller, because already having a display, disc drives, keyboard and communication ports, it made loading route data, programming the navigation algorithms, and reading the system states and debugging a fairly quick and simple task.

The laptop, though, is very old and tired now, and even though it is a tough little machine (Toshiba Satellite 2535CDS), I am afraid the rough roads out here on the farm will eventually take their toll. So I am porting the whole system onto a RedBoard Turbo SAMD21 Board. The SAMD21 has plenty of processing power to run the navigation program, it is now connected to a GPS logger shield, so the SD card reader can replace the need for disk drive route data storage, and I have it connected to a 4D systems LCD Display, so all of the essential functions of the original laptop have now been assimilated by this new system which is smaller, lighter, more durable, and more power efficient than the laptop was.

I am sure by now you might be thinking “Why not just go with a single board computer, Raspberry Pi or such??” The short of it is that for now those are beyond my skillset.

The only physical tasks left are to configure and additional UART port on the RedBoard to interface back to the cars’s microcontroller network through a MAX-232 or similar driver, and to configure and program some of the remaining digital pins on the redboard to function as an eight-bit parallel port. While it may sound cumbersome to emulate the serial and parallel ports from the laptop, I am doing so in order to make the swap between the laptop and the new RedBoard a Plug-and-Play situation. I do not want to alter the existing electronics or firmware on the original system in any way.

Even though I could certainly upgrade and streamline every aspect of the system, network, and sensors, it works fine at the speeds and purposes I am now using it for, so I decided to retain all of the now obsolete tech and just concentrate on building a more robust central processor . At the time I built the original system, I could have never imagined having a single microcontroller that could handle all of these tasks with any efficiency- at least not one that I would be capable of working with!

I suppose I might port this post onto one of the project forums in here so I can share more as I work to complete the project. Thanks for the guidance on the SD card reader issue- it is working great.

Hey again Rob,

I’m glad to hear the SD is logging just fine now! That is a fantastic rover project! I am sure other users would love to read and learn more about it if you would like to share here or on the Projects Forum.

As for the D10-D13 conundrum, I did some more digging and spoke to the engineer who designed the board and it turns out there is not an SPI bus on D10-D13 by default on the RedBoard Turbo. It is only on the 2x3 ICSP header. We’ll add some notes to the Hookup Guide (edit: we will also fix the error in the Graphical Datasheet) clarifying that and we’ll also get [this tutorial updated to note that as well. If you feel up to it and want to free up the legacy header on your Turbo, you can follow along with that tutorial to add a SERCOM port for SPI on D10-D13 on your board.

Thanks for sharing your rover(s) project. If you run into any other issues or have any questions about using the Turbo or other SparkFun parts for this or another project, let us know and we would be happy to help as much as we can.](Adding More SERCOM Ports for SAMD Boards - SparkFun Learn)