Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
pmod:hardware_compatibility [2015/12/16 22:55] – James Colvinpmod:hardware_compatibility [2022/10/04 11:38] (current) – external edit 127.0.0.1
Line 3: Line 3:
 ====== Pmod Hardware Compatibility Guide ====== ====== Pmod Hardware Compatibility Guide ======
  
-Welcome to the Pmod hardware compatibility guide! Although you likely have seen a Pmod that meets your needs either in our [[http://store.digilentinc.com/pmod-peripheral-modules/|store]] or on the [[:start#pmod|Wiki]], an important question remains: will the Pmod be able to physically interface with my hardware? This guide will walk through how one can determine this using Digilent system boards as an example (considering this is the Digilent Wiki and all).+Welcome to the Pmod hardware compatibility guide!  
 + 
 +Although you likely have seen a Pmod that meets your needs either in our [[https://digilent.com/shop/boards-and-components/system-board-expansion-modules/pmods/|store]] or on the [[start|Wiki]], an important question remains: will the Pmod be able to physically interface with my hardware? This guide will walk through how one can determine this using Digilent system boards as an example (considering this is the Digilent Wiki and all).
  
 But first, a clarification. Some of you may have noticed on other pages of the Wiki or seen elsewhere that Pmods are compatible with any system board that is able to use the same communication protocol that the Pmod uses to communicate. Why bother talking about compatibility at all? But first, a clarification. Some of you may have noticed on other pages of the Wiki or seen elsewhere that Pmods are compatible with any system board that is able to use the same communication protocol that the Pmod uses to communicate. Why bother talking about compatibility at all?
Line 9: Line 11:
 Here's the secret: when writing software (i.e. code), if you have enough time, experience, and talent, you can program your setup to do anything you want, much like an FPGA can be programmed to do anything you want it to do. Here's the secret: when writing software (i.e. code), if you have enough time, experience, and talent, you can program your setup to do anything you want, much like an FPGA can be programmed to do anything you want it to do.
  
-But for those of us in the mortal world, including myself, it simply isn't going to be worth the effort on our end to figure out how to get all of this setup, leaving us with using the tools that are already provided for us. As comforting as it is to know some of the work may has already been done for us, how are we able to tell if such tools are available with our setup? Let's take a look.+But for those of us in the mortal world, including myself, it's useful to understand how to use the tools that are already provided for us. As comforting as it is to know some of the work has already been done for us, how are we able to tell if such tools are available with our setup? Let's take a look. 
 + 
 +===== Determining Hardware Compatibility ===== 
 +There are two main ways in which a Pmod is connected to a host system: through a Pmod connector present on the host board or by individually wiring the 100 mil spaced pins on the Pmod header to I/O pins dedicated for the appropriate communication protocol on the host board. As convenient as that seems to have two straightforward options, how does one determine if their hardware has such options? 
 + 
 +==== The easy cases ==== 
 + 
 +Say you happened to find a Pmod that suits your needs either in our [[https://digilent.com/shop/boards-and-components/system-board-expansion-modules/pmods/|store]] or on the [[pmod:start|Wiki]] and you are working with Digilent's [[chipkit_pro_mx4:chipkit_pro_mx4|chipKIT Pro MX4]]. As this is a microcontroller, we can be fairly certain that it has some dedicated pins for each of the communication protocols that are commonly used by Pmods. We can determine what is available by checking out the host boards's datasheet (or in our case [[chipkit_pro_mx4:refmanual|reference manual]]). 
 + 
 +Taking the easy route (as it's the fastest and most efficient in this case), we can do Control+F search for whatever particular protocol we are looking for. Here, we can see that the chipKIT Pro MX4 has the three communication protocols that are used by a majority of Pmods: SPI, I²C, and UART. Furthermore, each of those protocols have a dedicated pin header on the board so that we are able to directly connect our Pmod to the host board without any unnecessary cross wiring or other tediousness.  
 + 
 +But perhaps our microcontroller isn't so nicely convenient and we are instead working with the [[chipkit_wifire:chipkit_wifire|chipKIT Wi-FIRE]] which does not have any obvious Pmod headers on the board. The thing to look for in this case is two-fold: do dedicated pins exist and if so, are all of the related pins physically located next to each other?  
 + 
 +Again looking at the [[chipkit_wifire:refmanual|reference manual]], we can see that the chipKIT Wi-FIRE board does indeed support those three communication protocols. Using SPI as an example, it is also apparent that users may take advantage of having all of the hardware pins physically close together on the PCB (chipKIT pins 10, 11, 12, and 13).  
 + 
 +==== The non-obvious cases ==== 
 +Up to this point, you may have noticed two things: One is that I've neglected talking about a large portion of the Pmod ecosystem - those without a "standard" communication protocol, and the other major portion of the Digilent ecosystem - FPGAs.  
 + 
 +These Pmods that don't have a "standard" communication protocol, i.e. those that are button modules, motor drivers, audio modules, and the like, must communicate with the host through GPIO pins. The general purpose pins (or I/O pins) on a system board are ones that are not necessarily dedicated to one particular function. This way, users are able to dictate to the host board how the pins should perform, either as simple input lines, clock lines, or even to emulate other communication protocols.  
 + 
 +FPGAs are inherently compatible with any Pmod. The reason for this is because users are able to program the hardware within the FPGA itself. This way you can configure it to be hardware compatible with any system on any I/O pin on the FPGA; you get to decide it's compatibility status. 
 + 
 +==== When is something not hardware compatible? ==== 
 +In my mind, this is almost the trickiest question to find out the answer for in the first place. Certainly, you can search your system board's datasheet and see if it has some dedicated hardware pins for that communication protocol, but what about if it doesn't? Or if it does have the dedicated pins, but they aren't nicely lined up for you? 
 + 
 +To me then, that would be a matter of personal taste: do you want to put in the effort into making the two pieces of hardware cooperate together or is that not worth your time? That I can't answer for you.
  
 +What I would recommend though is that if you are going to have to emulate a standard protocol, this may be a case where the two components are not hardware compatible. Additionally, if a Pmod happens to need quite a bit of software or firmware in order work correctly (like an ethernet stack), you may as well consider avoiding using platforms that are not supported by the firmware; it'll likely end up being a lot more difficult than you are hoping.
  
 +===== Hardware Compatibility Table =====
 +Coming soon to you! (likely in 2016)