dpharris

Thanks.
 
This is what I know about the ESP32: 
 
At the moment there is a beta-board out to the developers.  This contains the ESP31, which is a preliminary version of the ESP32.  It does not implement a complete set of peripherals.  
 
The ESP32 is expected relatively soon (months?) and will include al the peripherals, including CAN.   This looks like a nice chip with many expanded features over the ESP8266, including more sockets.  There are plans for a compatible Arduino-IDE for it.  
 
There is a forum at http://www.esp32.com, but it is pretty quiet.  

TI has 'launched' a multi protocol wireless launchpad.  
It uses the CC2650 chip:  The CC2650 device is a wireless MCU targeting Bluetooth Smart, ZigBee and 6LoWPAN. The CC2650 device contains a 32-bit ARM

TI has 'launched' a multi protocol wireless launchpad.  
It uses the CC2650 chip:  The CC2650 device is a wireless MCU targeting Bluetooth Smart, ZigBee and 6LoWPAN. The CC2650 device contains a 32-bit ARM

TI has 'launched' a multi protocol wireless launchpad.  
It uses the CC2650 chip:  The CC2650 device is a wireless MCU targeting Bluetooth Smart, ZigBee and 6LoWPAN. The CC2650 device contains a 32-bit ARM

Congrats for your nuptials!  

Exactly, PIOSC is the default clock....also if other clock source is configured like MOSC, but later on there is a system clock error...then the system clock falls back to PIOSC by default.
 
I would recomend you to check the Data sheet, look for chapter 5...in particular look figure 5.5 it is a functional diagram of the main clock tree.

Hi,
First this one: http://www.ti.com/lit/an/spma059/spma059.pdf
The second, Launchpad board manual, hope you have it.
One word of caution: you say:
"can use all function as a Tiva Launchpad without JTAG."
but design the board with JTAG connector, otherwise you are lost...
L

Layout for the programmer attached.  As mentioned this is in the form factor of the UNO, but it's actually an eZ-FET lite programmer using the MSP430F5528.  It includes the F5528, micro-USB, 4 LEDs (2 for the ezFET, 2 for UART), a regulator and a breakout for standard JFET.
 
...and before you ask, yes the product name is Storm Ninja.  For those unaware, it's a joke from one of our favorite shows - Archer.

I am happy to announce that release 0101E0013 just went up on http://energia.nu. This release adds support for the awesome CC3200 WiFi LaunchPad and CC3100 BoosterPack for MSP430 and TivaC.
 
I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!
 
Details of the release can be found on http://energia.nu

Another thing I discovered, not about Energia but noteworthy for folks using the new CC3200 - ADC inputs are measured against a 1.46V reference, the analog input buffers are only supposedly tolerant up to 1.8V.  That could be a problem if you have some 3.3V-level analog inputs.
 
This doesn't seem to apply with digital I/O mode for these pins, but as the datasheet cautions, having the digital I/O output buffers enabled & set high while the ADC mode is configured for the pin could cause the MCU to blow up its own ADC buffers.  Since Energia uses the CC3200 driverlib I assume there's no risk of that here...

A big thanks to all of you who maintain these forums and develop the hardware and software.  I am very impressed by the quality of these.  Trying to maintain compatibility with multiple versions or hardware and software is truly daunting.  
 
Thanks again,  
 
David

I've been playing with NRF24L01+ modules and launchpads. I've got 'em to where they can run and send packets on a (&*@#% little solar panel out of a harbor freight solar path light, and make it through the night on a 300mAh NiCd. Next up was improving their range, as the PCB trace antennas aren't especially good (even more so when you have metal walls to punch though, like I do).
 

Cut traces, soldered mini-coax from a dead WiFi router in place.
 

Built a mini-yagi!
 

The test package, a MSP430G2553 launchpad, a JeeLabs AA power board (3.3v boost converter, extremely efficient and low quiescent current), a $1 NRF24 board, and the Yagi.
 
Works great! Over doubled the range I get through the wall, it went from ~60-80' depending on direction to 200-240'.

Okay guys, sorry it took a bit longer than anticipated to roll this one out. 
 
This is the new version 3 of the ledRing boards.
 
 
This is the controller, powered by msp430g2955. Stuck with the value line series, because it has very easy capacitive button features.
 
 
 
I packaged these more professionally than the last. included in the zips:
PCB (Altium format, gerber format, 3d step format) Schematic (Altium format, PDF) BOM (.xls and .pdf) [controller board only, slave boards are just 24x WS2812b + 0603 100nF decoupling caps]  
Downloads:
Slave board:
LedRing_03.zip
 
Controller board:
LedRingController_03.zip
 
 
Major changes from last revision,
GND pour is on bottom layer (non-LED side) VCC pour on front (LED side) Added more vias to capacitive slider elements (increase sensitivity) Corrected errata found in previous revision Increased the radius of the inner corner (more tolerant to manufacturing errors) Changed programming connector to tag-connect footprint Changed from G2553 to G2955 (8x more RAM, 3x more FLASH) Changed to proper level shiftier IC, from discrete FETs added footprints for IR reciever (BETA) added footprints for miniature buzzer (BETA) I've never used IR before, but I think it would be a good addition. 
 
Hope you guys enjoy.

Fantastic project, and well executed. Small changes could be made. Thx for advice re caps. The resistor to ground is a good safety measure for mosfets. The level shifter could have been a single mosfet, see http://www.nxp.com/documents/application_note/AN10441.pdf -- but we are micromanaging here. Still, all food for thought :-).

It all started with an aim of improving communication between speech & hearing impaired and normal people. But it has now almost become an alternative input device for any computing device!
 
So what is it all about? It's a cyber glove that recognizes sign language gestures and convert them into ASCII. Voila! We can throw away our keyboards and start using this glove. Right? After all, our keyboard does the same thing.
 
Don't try too hard to visualize this peculiar device! This is how it will be!!
 

And Technically it will be something like this
 
And more technically the flow of data will be like this

 
 
Got a overall picture? Okay. Let's see how this is implemented. The sensor boards which are mounted on the finger tips is a custom PCB (see attachements schema_acc_board.png & pcb_footprint_acc_board.pdf) which houses the accelerometer (in our case MMA7361L). Those accelerometers will be connected MSP430 Launchpad and Launchpad will then be connected to Bluetooth Module as shown below. (BT boosterpack from iTeadStudio is used here)
 

 
Wondering why not all axes of accelerometers are utilized? Well we have to do some trade-off between resolution and no. of ADC channels available :-( 
 
That's all. Find the code as attachment (code.zip)
 
Here are few pics of the setup & output...
 
 
 



 
Attempts have been made to miniaturize the whole setup into one glove. The FET Debugger is not able to recognize the custom board. But I'm not sure whether the problem is with Schema or PCB footprint.  I've attached the unverified schema and footprint also with this post. Interested are welcome to give a try! If you come up with a better design you are welcome to share it with me at any time ;-)
 
 
pcb_footprint_acc_board.pdf

code.zip
pcb_1_NOT_VERIFIED.pdf
pcb_2_NOT_VERIFIED.pdf
pcb_3_NOT_VERIFIED.pdf
schema_NOT_VERIFIED.pdf

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

@@dpharris Here is the schematic in pdf form.
The uni has an older version of altium, so the schematic title block thing didn't work :/
 
ledRing_controller.pdf

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/

Yes, there is a small test program on then MCU. it should show accelerometer data with one moving pixel over 6 of the LEDs and then the other 6 show a rainbow.
 
this was the programming jig I made.

 
But then later just soldered a connector, it's not a perfect fit unfortunately. It was hard to find a small connector that wouldn't obscure parts on the other-side of the PCB.

 
Maybe a future revision could use tagConnect? ;P
 

I finally mounted the clock, I think it's looking quite fine.


 
And I made a write up here, included lots of photos from the physical side of the project.
http://www.instructables.com/id/Rainbow-Ring-Wall-Clock/

Thank you for reporting this issue! This was a very fundamental bug in HardwareSerial. 
1: peek() would loop forever if the RX buffer was empty.
2: read() would increase the buffer read pointer even if no byte was read because the buffer was empty.
 
Both of these issues have been fixed and pushed up to github:
Patch: https://github.com/energia/Energia/commit/b95f5f346a320bf8d06f4d4281ec31d0d62f9cff
 
Easiest way to fix this in your installation is:
1: Download the patched file from https://raw.githubusercontent.com/energia/Energia/master/hardware/lm4f/cores/lm4f/HardwareSerial.cpp
2: In your Energia folder browse to hardware/lm4f/cores/lm4f
3: Rename HardwareSerial.cpp to HardwareSerial.org
4: Copy the file you downloaded under 1 to this folder.
5: Restart Energia.
 
Thanks again for the report!
 
Robert

Hi --
 
I have been trying to use Serial.parseInt() -- but can't get it to work.  It appears to read on digit only.  
 
So, I thought, try an example.  However, ReadASCIIString does;t work, either, at least in my hands :-(
 
Using Tiva Launchpad.  Any advice welcome.  
 
Thanks,
David
 

Just received one of the 'CAN Bus BoosterPack's   -- will now have to apply it.  Will keep you posted.  Time to re-read this thread, in detail.  
 
David

I just got a Stellaris and a Tiva Launchpad talking CAN without a driver chip.  This uses diodes on the Tx pins, to common single bus wire with and a pull-up resistor.  This is strictly short-distance, but proof of concept for a quick hack.  See: http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf for details.   I used 3.3V, so I used a 3k pull-up, and used 1N4148 diodes.   
 
David

I just got a Stellaris and a Tiva Launchpad talking CAN without a driver chip.  This uses diodes on the Tx pins, to common single bus wire with and a pull-up resistor.  This is strictly short-distance, but proof of concept for a quick hack.  See: http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf for details.   I used 3.3V, so I used a 3k pull-up, and used 1N4148 diodes.   
 
David

A word of caution:  the specifications for bus-speed/distance usually overstate the performance.  The actual performance will depend on a wide variety of issues such as line capacitance, drive loading, etc.  While one can push it to the maximums, this often needs sophisticated equipment.  
 
That being said, I am part of a project to use this for model railroading which is a noisy environment, and we think that CAN is close to perfect for this because of all its built-in hardware supported error detection and correction.   [We found the 8-byte data-part limiting, though.]   For our bus-speed of 125k baud, we have some rough guidelines for success*:
Maximum CAN segment cable length is 1000 ft / 300m The max cable length is reduced by 20 ft / 6m for each physical node attached to the segment The max cable length is further reduced by double the length of each stub cable attached to the segment There may never be less than 1 ft / 30cm of cable between nodes, nor between a stub connection and a node. This implies that there is a limit of about 48 nodes on a single segment.  Hope that helps.  
David
*See: CanPhysicalS.pdf and CanPhysicalTN.pdf  for details and lots of references.