jrychter

Hey, some quick notes having taken a look at the schematic:
 
The caps around MMA8453Q should probably be larger (a mistake in the value in the schematic?): C15 is normally 100nF, while C16 at least 1

Hey, some quick notes having taken a look at the schematic:
 
The caps around MMA8453Q should probably be larger (a mistake in the value in the schematic?): C15 is normally 100nF, while C16 at least 1

Well, the problem with the legged version is that the holes take up so much board space. My main motivation is lack of board space, so I'd much rather stay with the -NL version if possible.
 
Thanks for your advice

I'm not sure if it will help in your design, but I've found that you can save some board space by going with milled cutouts for screws instead of holes. Yes, you still need room for the screw top, but less than you'd need if you had the hole in the middle of the board. See the attached picture for an example (the bottom cutout is marginal, parts are placed slightly too close)

I'm not sure if it will help in your design, but I've found that you can save some board space by going with milled cutouts for screws instead of holes. Yes, you still need room for the screw top, but less than you'd need if you had the hole in the middle of the board. See the attached picture for an example (the bottom cutout is marginal, parts are placed slightly too close)

I'm not sure if it will help in your design, but I've found that you can save some board space by going with milled cutouts for screws instead of holes. Yes, you still need room for the screw top, but less than you'd need if you had the hole in the middle of the board. See the attached picture for an example (the bottom cutout is marginal, parts are placed slightly too close)

Well, I don't think I can enlighten you, but I can state my reasons for using USI.
 
It is true that USI is a very primitive peripheral. However, it still gets you:
 
* a shift register,
* a "timer" that precisely times your output,
* interrupts,
* outputs that are capable of simultaneously driving the bus and reading it (read on for why this might be needed).
 
Here are my reasons for using the USI:
 
* No matter what you do, I2C needs two pins. No savings here.
 
* If I wanted to bit-bang, I would also need a timer, and there is only one on the G2412. Seems like a waste to use up such a precious peripheral.
 
* I would have to bit-bang every bit of the output/input (USI has a shift register, so it takes care of 8 bits for you in one go).
 
* The code would likely be much larger, not smaller, and more complex, too (switching pin directions, interrupts, etc). I don't see how you can simplify the I2C state machine by much (I use 6 states + idle), and my code really doesn't do much outside of the state machine.
 
* If I ever wanted arbitration loss detection, the code would become even more complex: for every bit written, you'd need to simultaneously detect that the line has been driven low by someone else.
 
Overall, bit-banging seemed to me like going out of my way so as not to use the USI at all costs. And avoiding the USI makes no sense: what else would I use it for? For projects that need both SPI and I2C, I'd much rather bit-bang SPI.
 
But, I would gladly compare notes with your library that bit-bangs I2C. Perhaps you did manage to simplify the I2C state machine. So, is the library available?
 
EDIT: oops, I missed the link to your code! Sorry. Now, having looked at your code, the tradeoff seems to be that it is significantly larger, more complex, uses busy-waiting, and the I2C clock is strictly tied to your core frequency. For some that is a reasonable tradeoff to get I2C on any GPIO pins they want, for me it wasn't. I'd rather use the USI, since it's already there.
 
BTW, another tradeoff is that your code is under GPLv3, while mine is under the MIT license.

[i really need to do a writeup of my experiences writing a reliable driver for the WS2812 strips]
 
First, I'd strongly suggest using level-shifting to drive the WS2812 at 5V. It might depend on your particular chip/strip, but I couldn't reliably drive them from 3.3V logic. The datasheet (crappy as it is) states CMOS logic, 0.7*VCC, which is 3.5V. You *might* get away with 3.6V, but I wouldn't count on it. For prototyping I used a 74HCT04 with two gates wired in series, any HCT chip will do. For production devices I'll probably use a M74VHC1GT125DT1G.
 
Second, if you are writing code to drive the WS2812, I'd suggest testing it carefully using various bit patterns. I got best results using alternating 0x55 and 0xaa patterns, with some bytes being continuously and slowly incremented/decremented, in the middle of the string. There were many times when I thought I had correct code, only to see flickering somewhere down the string.
 
Third, I don't really know why, but the WS2812 really does need 5V. That is a big disappointment, because you need complex power management in battery-powered applications, but that's just the way it is.

Hmmm, I have code that works reliably on LP-G2553, but not so good on LP-F or any 3.3V powered board. Will have to take this into consideration.
 
 
And don't forget about input/output resistors, they are very important. Without them, any data line longer than few inches will suffer from reflection problems.

[i really need to do a writeup of my experiences writing a reliable driver for the WS2812 strips]
 
First, I'd strongly suggest using level-shifting to drive the WS2812 at 5V. It might depend on your particular chip/strip, but I couldn't reliably drive them from 3.3V logic. The datasheet (crappy as it is) states CMOS logic, 0.7*VCC, which is 3.5V. You *might* get away with 3.6V, but I wouldn't count on it. For prototyping I used a 74HCT04 with two gates wired in series, any HCT chip will do. For production devices I'll probably use a M74VHC1GT125DT1G.
 
Second, if you are writing code to drive the WS2812, I'd suggest testing it carefully using various bit patterns. I got best results using alternating 0x55 and 0xaa patterns, with some bytes being continuously and slowly incremented/decremented, in the middle of the string. There were many times when I thought I had correct code, only to see flickering somewhere down the string.
 
Third, I don't really know why, but the WS2812 really does need 5V. That is a big disappointment, because you need complex power management in battery-powered applications, but that's just the way it is.

@@jrychter
The WS2812 is a fantastic IC.
 
DMA sounds like such a luxury. I've been working on some code to drive these for the valueline MSP430's, unfortuantely only the higher end MSP's have a DMA
 
Yeah go ahead. I've released the updated PCB's under OSHW. I'd like to see what you come up with
 
Edit: mis-post added text.

Hey, It's been along time since I've posted. but I've been keeping busy with uni and working on some cool projects for the last year.
 
This is something I'd like to share with you guys, it's not finished yet but the hardware is more or less complete. It is an RGB LED ring clock.
 

 
The clock is comprised of 2 rings of 60 LEDs each. the LEDs are WS2812 parts, which include a built-in driver.
 
The PCB is one of the interesting parts of this clock. I designed the board in altium as a single 6 LED segment. and then left pads at each end to allow them to be soldered onto another segment.
 

 
Using seeed's 10pcs PCB program I was able to create the full ring.
 
Currently I am using a MSP-EXP430FR5739 board to drive it, using some very in-efficient assembly code that requires a 20MHz clock.
 
I'd like to optimise the code to use an internal SPI module? or timer to bring that clock speed down.
Hopefully also design a control segment with LEDs on one side that could replace one of the current segments in the ring.
 

 
 
Edit: I've built up a simple controller based on the G2121. yes, 1kb Flash, 128b of RAM!
 
I decided to test my asmebly skills and use naken430 the msp430 assembler. Here is my code
G2121_ledRing.zip
 
I also added a ring of perspex to help difuse the LEDs
 
Here is a video of the clock in action.
http://www.youtube.com/watch?v=tBCvR4BA7pw
 
 
edit: 06/03/14
Version 2_02!
Major differences:
"double" so you need only 5 pcs to make a full ring, the pieces fit in 5x10cm Uses new 4 pin WS2812b parts
 
PCBs arrived, been tested and is functional, but has some very small issues.
Known Errata:
Doesn't account for very small milling tolerance, means small gaps at joins No silkscreen for LED footprint, only shows orientation Edge connectors a few mm from the edge. Vias connecting to pour have star connections, should be direct connection Thin soldermask trace around OSHW logo is to thin 1 LED under OSHW logo isn't concentric with the rest of the LEDs (<1mm off)  
 
There is also a special controller board in the mail, this will be tested and documented when it arrives.
 
edit 2/06/13
Please see this project for lot of photos and additional information about version 2_02
 
Version 3!

Boards have been designed, and I have some prototypes on the way. Designed mainly to upgrade the MSP430 used in the last design to a more capable one.  Boards arrived Some small errata found, pads to small for regulator, JTAG pins in wrong order. New board has been design to fix these issues. There is a tindie page where you can register any interest in buying.
https://www.tindie.com/products/Greeeg/ledring-clock/

I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
 
Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
 
Github repo at https://github.com/jwr/msp430_usi_i2c
 
Have fun!
 
 

I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
 
Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
 
Github repo at https://github.com/jwr/msp430_usi_i2c
 
Have fun!
 
 

I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
 
Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
 
Github repo at https://github.com/jwr/msp430_usi_i2c
 
Have fun!
 
 

I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
 
Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
 
Github repo at https://github.com/jwr/msp430_usi_i2c
 
Have fun!
 
 

I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
 
Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
 
Github repo at https://github.com/jwr/msp430_usi_i2c
 
Have fun!
 
 

Yes.. version all of them, since I need to use projects across multiple PCs. The .cproject and .project, I version at the end of day.

Do a project clean then try using the "File/Export..." menu item. Export as an archive file and see what it puts in the zip. You can safely delete the Debug directory or just exclude it using the checkboxes in the export dialog.  The files in that list should give you a good idea of what is needed by someone else to be able to build from scratch inside of CCS (eclipse really)
 
-rick

43oh Community USB board development in progress.
 
Dear Geeks and Wizards !
 
I happily invite you to share my joy ! Today, the first MSP430G2452 bit-banged the welcome ceremony of USB successfully. Crystal is 18 MHz.
 
Feel free to contact me via m-atthias@users.sf.net to get in touch with development.

Matthias Koch

--> Experimental Mecrimus-B 0.1 is out on mecrisp.sourceforge.net