YABB - Breadboard Booster on steroids

[campbellsan 24]

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 ;-)

[campbellsan 24]

@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.

[bluehash 1,581]

Good work campbellsan. Keep us posted as you go.

[campbellsan 24]

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, another is to just accept that the MCU will not talk to the CPLD on these two pins. I think the jumper solution is preferable, since P1.1 and P1.2 have SOMI and SIMO SPI functions that would be nice to have available.

 

I also discovered that attempting to use these two pins can also brick the board, since UART communications are interrupted if the pins are active. I created an eraseCPLD MCU program that recovers from this if anyone runs into it. MSP430 JTAG programming is not affected, so a self contained CPLD reset program still works and is small enough to not need the UART.

 

It is easy to exclude these two pins from the design, you just add:

 

CONFIG PROHIBIT = "P13";

CONFIG PROHIBIT = "P14";

 

to the constraints file.

 

While on the subject of SPI (the other MSP SPI port should work fine, even with these prototype boards), I have found an open source SPI VHDL implementation that should fit into one of these devices nicely, which will make this board into an awesome I/O expander amongst its many uses.

 

@Automate, I will ship you a board tomorrow.

[bluehash 1,581]

I was wondering if this one could be used on the C2K Launchpad too. Other than the dual row headers, it would be perfect.

[campbellsan 24]

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.

[Automate 69]

Can you point me at a footprint?

This is TI's recomendations on the new 40 Pin Boosters http://processors.wiki.ti.com/index.php/BYOB

The extra rows of pins are inside of the existing MSP430 Booster rows.

[campbellsan 24]

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.

[campbellsan 24]

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 (21 downto 6);
       p2_drivers <= counter (21 downto 7); 
	end if;
   end process;
end behavioral;

 

What it implements is a very simple clock divider in the form of a 22 bit counter. I could have allocated all 22 bits to different pins to generate a different frequency on each pin. However, I found that doing that spread the frequency range so far that my oscilloscope could not see the fastest signals while the slowest were below 0.25 Hz and time consuming to measure. Accordingly I allocated the outputs to a useful range inside the counter.

 

I left the fitter to map external pins for me since I did not care which pin came out where:

 

NET "clock" BUFG = "CLK";
CONFIG PROHIBIT = "P13";
CONFIG PROHIBIT = "P14";

 

The first line tells the silicon compiler that I want clock to be a, well, clock. The fitter then automatically assigns special pin GCK1 to this signal. This is in turn wired on the booster pack to P1.4 of the MCU, which just happens to be a special purpose I/O clock output pin on the MSP430G2553. The two PROHIBIT lines prevent the compiler using pins P13 and P14 which interfere with the UART functions on the MSP430 as discussed earlier in this thread (and now fixed in the production design).

 

Even this bit of test code has its uses. While its unlikely you'd ever want 30 odd different clock frequencies, its not uncommon to need two or three and there is plenty of room left over in the CPLD for it to do more stuff at the same time.

[campbellsan 24]

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

[Rickta59 589]

So what ever happened with this?