dkedr

I'll be getting this board made some time this week, here is a current feature list:
 

3 x DRV8825 micro stepping stepper drivers
Every pin but the HOME is controllable - micro-stepping, decay mode, enable, sleep, reset.
Fault detection multiplexed through the PCF8574 I2C port expander.
Each stepper driver can have a different current limit set as each has it's own pair of current setting resistors.
2 x 20A n-channel fets for whatever you want.
LEDs can be wired up to be controlled by the PCF8574 or to be always on as long as power is applied.
Up to 8 limit switch inputs multiplexed via PCF8574
On board LM317 regulator(chosen due to high input voltage & it's cheap)  
 
 
Schematic:

 
Board:

3 Stepper driver.zip

nrf24L01.h Contains command and register address definitions.
nrf24L01.c Contains functions (tx not tested but should work, rx not tested)
regs.h Contains settings for the MSP430 and the nrf24L01
main.c - Demo main program code
 
Apparently the nrf24L01 can take a pules on CS without any delay. If any one runs into a problem with this do tell.
 
The delay from PWR_UP being written to CE going high is very crucial. If not observed, the nrf24L01 will not work.
 
Also by the looks of it the nrf24L01 can take 16Mbps SPI. I don't have a logic analyzer to test this, but my code seams to work.
 
regs.h hold a definition "test_config". If it's set to "1" a demo type program will run.
If it's defined as "0" the test code will not be included.
tx1st defines if the nrf will be in tx mode when it power up. If set to "0" nrf will be in RX mode.
The code in main.c should increment the RX_ADDR_P0 then send it to the received address.
If the msp that is transmitting doesn't receive an ACK, it will turn on LED1 and go into LPM4.
This should continue indefinitely. Only the LSB of the address is changing, and should roll over.
 
 
 
tx is working now, tested with msp430g2252 on the tx side and the buspirate on the rx side
rx is still untested. (Will test later)
regs.h
nrf24l01.h
nrf24l01.c
main.c
nrf test.buspirate.txt

nrf24L01.h Contains command and register address definitions.
nrf24L01.c Contains functions (tx not tested but should work, rx not tested)
regs.h Contains settings for the MSP430 and the nrf24L01
main.c - Demo main program code
 
Apparently the nrf24L01 can take a pules on CS without any delay. If any one runs into a problem with this do tell.
 
The delay from PWR_UP being written to CE going high is very crucial. If not observed, the nrf24L01 will not work.
 
Also by the looks of it the nrf24L01 can take 16Mbps SPI. I don't have a logic analyzer to test this, but my code seams to work.
 
regs.h hold a definition "test_config". If it's set to "1" a demo type program will run.
If it's defined as "0" the test code will not be included.
tx1st defines if the nrf will be in tx mode when it power up. If set to "0" nrf will be in RX mode.
The code in main.c should increment the RX_ADDR_P0 then send it to the received address.
If the msp that is transmitting doesn't receive an ACK, it will turn on LED1 and go into LPM4.
This should continue indefinitely. Only the LSB of the address is changing, and should roll over.
 
 
 
tx is working now, tested with msp430g2252 on the tx side and the buspirate on the rx side
rx is still untested. (Will test later)
regs.h
nrf24l01.h
nrf24l01.c
main.c
nrf test.buspirate.txt

How about a v0.2?
 
The only thing I didn't add is the CR2032 holder because I couldn't find one in my eagle libraries, but there is plenty of space to add one
 
EDIT: added a header for the NC pins, just in case one of the forum members discovers that those pins do something cool.
 

43oh GPS booster.zip

I wrote some code to modify which NMEA sentences the GPS module spits out and their frequency.
 
If you disable some the logger will have less data to chew through and can spend more time sleeping.
 
I should probably mention that it uses the button on P1.3 to select which one of the 8 available sentences comes out. I'm using hardware debounce so it might skip a few sentences if you don't debounce the pin.
 
Modifying the code will allow you to select any combination.
main.c

I wrote some code to modify which NMEA sentences the GPS module spits out and their frequency.
 
If you disable some the logger will have less data to chew through and can spend more time sleeping.
 
I should probably mention that it uses the button on P1.3 to select which one of the 8 available sentences comes out. I'm using hardware debounce so it might skip a few sentences if you don't debounce the pin.
 
Modifying the code will allow you to select any combination.
main.c

Here are two adapters that can be used to remap the pins.
 
 

I wrote some code to modify which NMEA sentences the GPS module spits out and their frequency.
 
If you disable some the logger will have less data to chew through and can spend more time sleeping.
 
I should probably mention that it uses the button on P1.3 to select which one of the 8 available sentences comes out. I'm using hardware debounce so it might skip a few sentences if you don't debounce the pin.
 
Modifying the code will allow you to select any combination.
main.c

If you don't know what to do with that 5.25" drive cable, here's an idea, use it to test booster packs
 
To our younger users: 5.25" drive is something your dad used to store data on (the data was actually stored an a 5.25" floppy disk.)
 

The LogicBoost is a 6 channel 16 MHz 256 ksample logic anlyzer booster for the MSP430 launchpad. It works with 3 to 5 volt logic levels.

Many common communication protocols can be observed, such as:
- Async serial ("UART", "RS-232")
- SPI
- IIC
- Dallas/Maxim one wire
- Low speed USB (1.5 Mbps)
- DHT11/22 sensors
- Consumer infrared and IRDA
It is also useful for PWM and other applications.
 
SPI RAM chips are used for the acquisition buffer. This greatly simplifies the design relative to using parallel SRAM chips. The SPI RAM have and internal address counter that eliminates the need for an external address bus and counter. The MSP430 sets up an address and write mode, and then data is clocked into the RAM on every SPI clock.
 

 
The PCB is 50 x 50 mm for low cost and uses thru-hole components so anyone can build it. An optional FTDI board can be used for faster host communication.

 
It can be stacked with the Launchpad Mini - also 50 x 50 mm. An FTDI board is required for host communication and power in this configuration.

Hallo Joseph,
Hallo MSP430 wizards !
 
Here I am, glad to read from you.
 
A 15 MHz crystal MCLK is definitely needed to catch the signal and stay in sync with the bitstream without having a phase locked loop that copes with timing variations. I use an external XO that feeds in as digital external clock, so it is easier to hook up an oscilloscope probe without detuning crystal or even loosing clock.
 
There are some more hardware dependencies: D- has to accessible with constant generator, e.g. use the lower 4 Bits of P1 or P2. D+ only has to be on the same port as D-. I added resistors of about 50 Ohms into the usb lines, just for sure, and there should be a 1,5 kOhms Pullup on D-, switchable for now to simulate connect and disconnect. Add a constant-generator-accessible LED to view syncing.
 
The controller gets it power over USB via two Si-Diodes for a voltage of 5V-2*0.7V=3.6V, the USB data lines are connected via resistors directly to port pins.
 
Feel free to ask questions !
 
Best wishes out of Germany,
Matthias Koch

Here is a click able link to the schematic from the first post.
http://www.acmewebpages.com/leds/chmsl/uc_schematic.jpg
Is there a particular reason you are using the PTN78000?
 
The TLC5916 is actually rated up to 20V on the LED output pins, so you could use the 13.8V input to drive the LEDs directly. However depending on the current you might want to add some series resistors.
 
The amount of regulators in your design is actually unnecessary. The first regulator is actually capable of producing the 3.3V for the MSP/TLC.
 
Also, all your regulators are rated at 1A, which would mean a large chunk of their capacity is unused as you're just powering the logic inside the TLC5916 and the MSP430 is a very low power device so it doesn't draw much current.
 
The way you have arranged those diodes is incorrect. The diodes are there to prevent negative voltages from destroying whatever electronics come after it, in your design however the diodes don't serve a purpose, and also don't allow the capacitors to do their job. If you look at the datasheets of the parts you used, you'll notice that there are no diodes in the example circuits, especially on the output. Diodes are normally used at the very start of the design, to protect the circuit from reverse polarity(the user reversing the + and - terminals). The diode should be connected with the arrow pointing into your circuit, so it should be in between the 13.8V and the input of your first regulator.
 
The capacitors are there to smooth out any noise that might be superimposed(added) to the regulated signal. Noise comes from pretty much anything that has current flowing through it, so we filter it to prevent it getting into our circuits(you've done more of this with the .1uF caps next to the MSP and the TLC chips). Now the way you have the capacitors connected now, they will only charge up once, when you power on your circuit and will not discharge because the diodes are blocking the discharge path. To allow the capacitor to work you will need to take out the diodes and put a connection across the place where they used to be. It's also good practice to have capacitors close to the input of the regulators as well as the outputs. This makes the output they produce smoother(less noise).
 
EDIT: Found a simple circuit with a well known regulator:

Here is the updated design
 
3 stepper drivers (drv8825/24)
3 i/o port expanders(PFC8574) to control every thing that the steppers do. STEP and DIR is still done directly my the MCU. All INT pins ORed together to detect FAULT. The MCU will have to check all the IO expanders to see which stepper driver has a fault.
1 i/o port expander to read the limit switches. The INT output will cause an interrupt in the MCU.
 
There are still 2 unused pins on the MCU, I'm thinking temperature sensors? More fets? Supply voltage off clamp?
There should also be two unused pins on the io expander which does the limit switches.
 

 
 

I'll be getting this board made some time this week, here is a current feature list:
 

3 x DRV8825 micro stepping stepper drivers
Every pin but the HOME is controllable - micro-stepping, decay mode, enable, sleep, reset.
Fault detection multiplexed through the PCF8574 I2C port expander.
Each stepper driver can have a different current limit set as each has it's own pair of current setting resistors.
2 x 20A n-channel fets for whatever you want.
LEDs can be wired up to be controlled by the PCF8574 or to be always on as long as power is applied.
Up to 8 limit switch inputs multiplexed via PCF8574
On board LM317 regulator(chosen due to high input voltage & it's cheap)  
 
 
Schematic:

 
Board:

3 Stepper driver.zip

LEDsssssss

 
Added places for them to go, but only two should be used, unless blue or white leds are used. The two footprints are in series from 3.3V to ground, and there is a single current limiting resistor between the center of the two leds an the I/O expander.
 
I've also started some routing of the stepper drivers, looks like it's going to be tight fit.

Here is the updated design
 
3 stepper drivers (drv8825/24)
3 i/o port expanders(PFC8574) to control every thing that the steppers do. STEP and DIR is still done directly my the MCU. All INT pins ORed together to detect FAULT. The MCU will have to check all the IO expanders to see which stepper driver has a fault.
1 i/o port expander to read the limit switches. The INT output will cause an interrupt in the MCU.
 
There are still 2 unused pins on the MCU, I'm thinking temperature sensors? More fets? Supply voltage off clamp?
There should also be two unused pins on the io expander which does the limit switches.
 

 
 

Here is the updated design
 
3 stepper drivers (drv8825/24)
3 i/o port expanders(PFC8574) to control every thing that the steppers do. STEP and DIR is still done directly my the MCU. All INT pins ORed together to detect FAULT. The MCU will have to check all the IO expanders to see which stepper driver has a fault.
1 i/o port expander to read the limit switches. The INT output will cause an interrupt in the MCU.
 
There are still 2 unused pins on the MCU, I'm thinking temperature sensors? More fets? Supply voltage off clamp?
There should also be two unused pins on the io expander which does the limit switches.
 

 
 

I'll be getting this board made some time this week, here is a current feature list:
 

3 x DRV8825 micro stepping stepper drivers
Every pin but the HOME is controllable - micro-stepping, decay mode, enable, sleep, reset.
Fault detection multiplexed through the PCF8574 I2C port expander.
Each stepper driver can have a different current limit set as each has it's own pair of current setting resistors.
2 x 20A n-channel fets for whatever you want.
LEDs can be wired up to be controlled by the PCF8574 or to be always on as long as power is applied.
Up to 8 limit switch inputs multiplexed via PCF8574
On board LM317 regulator(chosen due to high input voltage & it's cheap)  
 
 
Schematic:

 
Board:

3 Stepper driver.zip

I'll be getting this board made some time this week, here is a current feature list:
 

3 x DRV8825 micro stepping stepper drivers
Every pin but the HOME is controllable - micro-stepping, decay mode, enable, sleep, reset.
Fault detection multiplexed through the PCF8574 I2C port expander.
Each stepper driver can have a different current limit set as each has it's own pair of current setting resistors.
2 x 20A n-channel fets for whatever you want.
LEDs can be wired up to be controlled by the PCF8574 or to be always on as long as power is applied.
Up to 8 limit switch inputs multiplexed via PCF8574
On board LM317 regulator(chosen due to high input voltage & it's cheap)  
 
 
Schematic:

 
Board:

3 Stepper driver.zip

Made this to drive some leds and make a graphic EQ type thing.
 
Just wondering if I've goofed anywhere. DRC and ERC both check out.
 

led_driver.zip

Made this to drive some leds and make a graphic EQ type thing.
 
Just wondering if I've goofed anywhere. DRC and ERC both check out.
 

led_driver.zip

Where is this stuff noted? And does this same thing happen in asm programs?

The old way to handle multiple pins on the same net is to name them SIGNAL, SIGNAL@1, SIGNAL@2, SIGNAL@3, ect..
 
This would show as entered in the library editor, but in the schematic editor the @N suffix is dropped so there will be multiple pins with exactly the same name and Eagle knows they are internally connected.

In Eagle 6, open Device, select your package and click Connect.
In Connect dialog box, select the pin (Pin column) and the first pad (Pad column,) click Connect.
Now, in the Pad column, select your second pad and the previous connection (Connection column,) click Append. Voil

If I understand correctly it traps the CPU at that point.
 
If you were to remove it the CPU would continue to execute all the addresses (as NOP) up to the end of the flash, after which it would try to execute an address that doesn't physically exist. This should cause some kind of "out of range" violation which will cause your MSP to reset.