Jump to content
43oh

campbellsan

Members
  • Content Count

    34
  • Joined

  • Last visited

  • Days Won

    3

campbellsan last won the day on June 25 2012

campbellsan had the most liked content!

About campbellsan

  • Rank
    Advanced Member
  1. Got mine yesterday. This boards all the award I need Hmm now, what will I do with it?
  2. I now have SPI communication going between the MSP MCU and the CPLD. I am using the slave part of this open source SPI implementation: http://opencores.org/project,spi_master_slave
  3. So here is some VHDL I used to test our prototype boards: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity tester is Port ( clock : in STD_LOGIC; p1_drivers : OUT std_logic_vector(15 downto 0) := (others => 'Z'); p2_drivers : OUT std_logic_vector(14 downto 0) := (others => 'Z') ); end tester; architecture behavioral of tester is signal counter : std_logic_vector (21 downto 0); begin process (clock) begin if (rising_edge(clock)) then counter <= counter + 1; p1_drivers <= counter (2
  4. Ah, I just scanned the schematic and drew the wrong conclusions. This board should Just Fit. However, it would make the inner pins inaccessible. That kinda defeats the purpose of an I/O expansion type Booster, so I still think a redesigned board that exposed all the pins would be better.
  5. I'll take a look at what would be involved. Can you point me at a footprint? My first thought is that this board is actually quite dense around the edges, so a dual target board would probably be a challenge. I see that the power pins are brought out differently too. However, laying out another board would definitely be possible and the support software would likely port without trouble. The CPLD by nature is very flexible, so there would be no problem there.
  6. Progress ... Everything seems to be working on all boards except pins 13 and 14. This is because they are connected to P1.1 and P1.2 of the MCU. When these pins are used in a design they glitch at a certain point during the programming cycle which is enough to upset the UART connection from the host to the MCU. This happens even if they are set to a 'Z' initial state or used as an input. So unfortunately for the prototype boards, these two pins cannot be used on the CPLD. I will consider what this means for the next revision of the board. One possibility is to add two more jumpers,
  7. @Automate Yes, the tools are available under Windows. The programmer host end is written in Java to run as an Eclipse plugin, so it will run on any host. If you don't use Eclipse, it is quite simple and should be easy to port. I'll help with that. Please PM me with your mailing address and I'll get one over to you.
  8. Note in the above shot that the oscillator isn't populated. The reason is that you only need that if you want to have the CPLD to be clocked independently. For combinatorial logic applications like I/O expansion, it is not needed. That and the oscillator part costs more than the CPLD ;-)
  9. And here is the underside with the CPLD: Oh my! The camera makes those CPLD solder joints look ugly. In real life they're just fine. Note the ugly strap which fixes the mistake I made in the design. Production boards won't have those of course. I put some hot glue on the strap to make sure the pin doesn't break off the CPLD.
  10. Here is the finished prototype board: Note the jumpers in the 'Program' state. Move them to the left if you wish to use those MSP pins in your project.
  11. Finally got parts and made one of these and it works great. I also set up the Xilinx development flow on Linux and proved it works (I only used the windows version in the past). For those of you on Linux, Xilinx only supports SUSE 11 and RHEL 5 and 6. Since neither of these are free, I tried OpenSUSE 11 which worked fine (OpenSUSE12 had dynamic library conflicts). A Fedora distro from around the RHEL 5 era might work, but I did not try it. For other distros, you'd be on your own though I'll help if I have the knowledge. To whet your appetite here is some simple Hello world VHDL:
  12. Actually, looking more closely at that ADC it uses SPI, so why not just hook it to the MSP directly? CPLD's come into their own for interfacing to IO pin heavy devices, such as those with 16 (or even 8) bit ports. The CPLD can read the state of the pins and convert them into an SPI stream for example. In the case of this chip, that's already done for you.
  13. Well, that one is in a SOP, so you couldn't just pop it into the breadboard. You'd need to stack another board on top instead, but the CPLD could drive it for sure. If you could find another high bit count ADC in a DIP package you could use it directly without another board (getting harder to find though, I know).
  14. Yes, CPLD's are pure digital. If you wanted to use the MSP built in ADC you'd want to bring that pin out before the CPLD. You could easily do that using the long pin connectors available in the store. Alternatives are that you could use the CPLD to control an external ADC to achieve sample rates up to around 70 Msps. Depending on the sample rate, you might again need an external SRAM. Given that these boards are going to need cuts and straps, I was thinking of pre-building them, but if anyone feels like giving SMD soldering a shot you can have a bare board.
  15. Hi again, So I got the boards back from Seeed. They look great ... ... if it wasn't for a dumb design mistake I made. I tied JTAG_TDO to ground and it is needed by the programming algorithm to confirm that the CPLD received the correct programming commands. What was I thinking. They're not quite coaster material though. Two cuts and two straps should have them running. I'll be ordering parts for this at the end of the week. Let me know if you are interested in getting one of these prototypes. Since I borked the design, they'll be going for free :-). In other progress, I ha
×
×
  • Create New...