dubnet

@dubnet
Well, I do have three monitors... So, yes, I am able to see my logic analyzer, two debuggers, and off to my right, when needed the oscilloscope. I know there are those out there with more talent, skill and experience who are able to manage with their blinky LED, but I need all the help I can get!
 

@NurseBob
For your video work where is the bottleneck? If it's the drive subsystem then perhaps an upgrade to SSD would be helpful. Perhaps not for the whole 21TB but maybe as scratch drives for the rendering process.  Prices keep dropping and are now at the point, in my opinion at least, where the price difference between spinning drives and SSD is pretty easily justified by the performance gains. I have them in my laptops and main desktop and love the performance boost. 
In the past I have recommended adding memory, to a point (and you are north of the point with 24GB), as a way to inexpensively increase performance. Now, its a toss up between memory and SSD and I am leaning more toward the SSD and not solely due to lower prices. Reason is that even with less than optimal memory, the swap to virtual memory on the SSD is so much faster it mitigates the need for more system memory.

Bummer is certainly an understatement.
As to my local backups I run Macrium reflect pro (now V7 home edition). I have all of my code and eagle files on a 1TB 10k  rpm hard drive. Macrium does a full backup every day around 02:00 to an internal 5TB drive, and then copies to my server's 24TB JOBD array.  Finally, the source files get posted to my AWS account for "offsite" storage.  My AWS account runs about $2.00/month. And the last upgrade for my 5 licenses for Macrium was about $150.  Money well spent.  All of the machines on my home network run daily backups. In general, I do a daily full system image for the boot drives, and then the data files are incremental folder/file backups.  I generally keep 8 full backups of my system images, and for the data files, there's a full backup done weekly, and I keep four full backups + the incrementals for a month.  FWIW, Macrium's Windows PE rescue disk saved my butt last week when the system files became corrupted due to a problem with my aging RAM.  I was able to recover the system and get completely back up and running after a day's effort (about 200 reboots while playing with BIOS HD settings...)

I just spent the last two hours trying to figure out why all of the UART-related register code was failing on my 5529LP. After hooking up to a different 5529, where code performed as expected, I finally remembered that several months ago I'd found that one of my LP boards had a "broken" UART/I2C - Of course, I'd not marked the board when I set it aside.  Dumb.  Board is marked now. It's still useful for other experiments, so I'll keep it on hand; I just won't use it for any comms protocols.

The example msp430fr5994x_lpm4-5_02.c is supposed to show how little current is used in this mode.
In the file it says:
//   MSP430FR5x9x Demo - Entering and waking up from LPM4.5 via P1.3 interrupt
//                       with SVS disabled
//
//   Description: Download and run the program. When entered LPM4.5, no LEDs
//                should be on. Use a multimeter to measure current on JP1 and
//                compare to the datasheet. When a positive voltage is applied
//                to P1.3 the device should wake up from LPM4.5. This will enable
//                the LFXT oscillator and blink the LED (on P1.0).
Even for a high-end multimeter this current is too low to be accurately measured. 
So I helped myself this way: 
- power the processor from the supercap
- a 10k resistor with two antiparallel diodes act as a shunt,  
- connect the volt meter across the supercap, not across the processor
0.43mV over a 10k resistor gives 43 Nanoamps. (!)   Yes, the datasheet (page 32) is right, typical value at 25°C is 45nA.  
A  CR2032 (200mAh) cell would allow the processor to wait for an interrupt  for 530 years. 

My compact Lisp interpreter, uLisp, now supports the MSP430F5529 and MSP430FR5969 LaunchPads.
As well as supporting a core set of Lisp functions, uLisp includes Arduino/Energia extensions, making it ideal as a control language for the MSP430.
For more information see http://www.ulisp.com/.

A good bench is at the top of the list. I have an industrial assembly bench as my primary space with a work area of 1500mm by 700mm. It came with outlets mounted in the shelf faces, the front of the work area, and the back f the work area, but I ended up adding several more duplexes (4, for a total of 8 more) as well as a few 2A USB sources and an IEC320 strip (I scored a bunch of 600mm IECmale to female cords at Eli Heffron's back in the late '80s. They still come in handy) Power is key, and not just for electronics work, These power the scope, logic ananyzer, several meters, computer, monitors, power supplies, and several projects.
The bench has a lighted magnifier-on-a-stick which gets a LOT of use (I have about a half dozen mounted around the shop and the office. I am getting old and have had several eye injuries) as well as the optivisor and a bunch of loupes. My go-to style loupe is the jewelers style (black conical with a single lens) of 2.5 to 5X. The 5X and 10X Bauch and Lomb that clips onto my glasses gets a lot of use, as well. One good one costs as much as several cheapies, but the cheap ones are useless due to distortion. Go good with glass lenses. I also keep several powers of cheater reading glasses around as well as safety glasses with cheaters.
 
A stereo microscope gets a lot of use. High power isn't the key for electronics. It lets you work in a more comfortable position and focus without strain. I would love a Mantis, but can't justify the cost, so I have a 7.5 to 75X Nikon that spends most of the time at the 7.5X end. It also gets used for machinist work (I made a mount for the lathe and for the mill), and for measurement and for photography. If you can find one (craigslist is your best friend) an arm mount beats a base any day. It isn't too hard to make a mount, but it is nice to have it come with one.
 
My monitors are mounted to the back rail of the bench. Dual monitors (if I upgrade the machine, I'll go for three next time) of good size are a requirement to maximize workflow and reduce eyestrain from focal changes. It doesn't seem like it should matter, but it does. A lot. They also get use with the microscope camera for a lot of things when I prefer not to be staring down the eyepieces.
A decent workholding vise is nice. I made several for specific purposes, including board-holding.
If I was to name the MOST important thing, it is light. A lot of glare free light. I have about 5000lm/m^2 at the bench, from multiple directions, most diffuse sources, and have about another 10000lm available task lighting (fixed fluorescent and lamps on movable arms). About 20%  of this os LED floods, to give some shadowing and contrast, the rest being quite uniform from flourescent.. I use high color rendering index lights (90+) daylight (6500k) mostly. I have a few fixtures in the shop with warm (4500K) so it doesn't feel so clinical, but hte key is a LOT of light. Magnification comes right with this.
As I also use the space for woodwork and machining, I also have a bunch of vises for these tasks. A decent drill press vise can serve a lot of masters.  The one I get the most use from is an ancient, swap meet, palmgren 2-1/2" angle vise. Second is a dirt cheap ($2?) yard sale job with 1" and 1-1/2" jaws that rotates (no brand.... just "Japan"). The jaws on that needed a little dress with a file, and the vacuum holddown went to the trash, but it works a treat for everything from holding a probe in place to holding a micrometer suspended in mineral spirits during rebuild. I never had mch use for a panavise or equivalent, though I have had several, as they never seem to be rigid enough or be able to get to the position I need them in.
 

Events: Such a range of sources. Hardware (internal and external), timers, user-generated, etc.  As you alluded to, there's usually a heirarchy of priorities that impact how they are, or need to be, handled. I don't really have any internal association between event-driven and OO; one reflects how things happen, the other is merely one way to define a world view. The PC GUI world is certainly built around the event model and the understanding of the potentially random timing of events coupled with a management of event priority. My fading memory seems to recall that the original implementation of the Windows GUI several decades back was niether OO nor C++, but a loop which handled and/or generated messages.
As to my own project, the ISRs are C.  The name mangling of C++ led to problems. So, just as TI's C++ libraries do, I define the ISRs as extern C routines. I do spend some time looking at the order and frequency of the case statements in terms of execution, but my implementation spends very little time doing any communication with the sensors, and typically only in response to a sensor-generated interrupt (also rare events), otherwise the app is spending it's time sleeping.
I agree, complex code is likely slower to execute. And almost never should reside in an ISR; aside from my TX RX event handlers, my ISRs follow the "set a flag or generate a software  interrupt and return" rule. And as much as possible, even the TX RX handlers are setting flags for a main-based while loop to process then go back to sleep where communication timing is not an issue.
My knowledge of the C language is probably barely adequate to the task, as well as is my knowledge of C++. However, experimentation is a basis for how my brain works and remembers.  I've spent hours in the debugger stepping through both C and disassembled code; fixed problems, and sometimes have even remembered not to create the same problem again. Were it not for Google, code snippets, reference circuits, etc., my little project would have never gotten started, let alone to the point it's reached. Ok, now I'm rambling...

Late into this thread, and I haven't read it top to bottom, but there seems to be a slight conceptual gap developing regarding what C & C++ really are.
They are languages, not environments. The C language was originally designed for telephone exchange testing & control. Subsequently, it was used to implement the early UNIX kernels. There is a "C Standard Library", which is distinct from the language proper - this is where printf etc. come from.
The story is similar with C++ - the language is distinct from its support libraries, e.g. stdlib, STL, and the various boost libraries.
A huge amount of apocrypha and mis-information surrounds these languages and the pros and cons of their various implementations - most of the arguments are bogus and ill-informed. The truth is, IMHO, far more boring - that they each have pluses and minuses.
The main differences are that C++ is geared to a more object-orientated design methodology, and generally, the mindsets used are different, which is why some feel that teaching people C, then C++ is a bad plan.
When mis-used, C++ can be memory-hungry, which is one some decry its use for embedded work - I feel that this is a fallacy - C++ is absolutely fine for embedded work (I use it all the time), if you understand the consequences of your actions - C++ is a far more powerful & capable language than C, but with great power comes great responsibility (*) - blaming the language for your poor understanding of the consequences of your actions is not an excuse. C++ is easy to abuse, C can be plain dangerous...
An analogy I like to use is the difference between "mathematicians" and "people who do mathematics".
A mathematician has an intuitive grasp of numbers and mathematics - they can visualize the problem they are working on and come up with novel ways of solving it; further, when presented with a left-field/previously unseen problem, they will see ways of dealing with and solving that.
Someone who does maths, OTOH, knows how to follow rules and can solve problems that are related to problems that they have encountered before, but may have real issues dealing with a novel puzzle..
Same with programmers. There's a world of people who can do C or C++ and have used the support libraries - that does not make them good or even half-decent programmers.
In my career, I have found very very few genuinely good programmers - people who understand architectural issues, who can see solutions, who can visualise novel approaches and solutions, who understand and then, very importantly, can implement with excellence - it's the difference between a programmer (rare beast), and journeymen who know how to program (common as anything).. 
 
Note: I was involved in the ANSI C process and have been an editor or cited as a contributor to various C++ related books, including Scott Meyers' "Effective STL" etc Spent 30 years in the City of London and elsewhere as a CTO, designing, developing and implementing some of the world's largest real-time equity, derivative & FX exchange trading systems, mostly in C & C++.
(*) Attributed to Ben Parker, Peter Parker's uncle...

Hello all.
 
I got my hands on 100+ PCBs with M430F140 CPU and trying to figure out what to do with them?
 
It has a programming header, 4 Buttons,8 LEDs, 4 Mofsets (6 volt), Battery Input, DC input, 2 Low pressure air transducers (1 psi max) and a buzzer.  Seems like a cool little board.  I also have full schematics.  If anyone is interested in some for a project, Please PM me here.
 
Thanks
 
Tim
 

First of all, welcome to the forum!
In terms of pin usage you will want to pay attention to pins already used by the Launchpad (e.g.switches and LEDs) to avoid conflicts.
With regard to the fan speed control, why not use temp sensor(s) in lieu of the potentiometers fed into the A./D converter? Perhaps just one, or possibly two, would be enough to adequately control the speed of all four fans. Just a thought....

If you use the 2553 on your own PCB you will want to replicate the reset circuit (capacitor and resistor) that the Launchpad uses. Otherwise the MCU won't run.
On the temperature sensor(s) I was envisioning using something like an LM34 or LM35 placed near the area in the PC enclosure you are interested in keeping cool. If this is done then when the PC is idling along the fans should run slower and when you are pushing it the fans will run at near maximum speeds.
I would guess that you have some free four pin power plugs (with 5V) in the chassis. If you add a 3.3V linear regulator to your PCB to drop the 5V then it would resolve your power issue without splicing.

This project was put on hold over the holidays. It's always a busy time, plus the club doesn't hold meets over summer.
But I have just completed another 10 units. More of the same, but thought you guys might enjoy some more photos.





 
I couldn't get the same batteries as the last batch, which were 650mAh, these have much smaller 220mAh. But this still provides about 4 hours of run time.
The uBlox GPS modules are a huge improvement. Even without the SAW filter in the RF path and the sub-optimal PCB size compared to the antenna. These find more GPS satellites faster than the G.top modules, plus they also use glonass which doubles the visible satellites.
 
 

More upgrades:
 PHP5.4 -> 5.6 Memcache support for forums. Added 12GB more to disc size.

There is a new BeagleBone out in the field. This one is the "Blue", following the "Black" and "Green" ones.
Expected retail price is $80. 
Feature list:
Processor: Octavo Systems OSD3358 1GHz ARM® Cortex-A8
• 512MB DDR3 RAM
• 4GB 8-bit on-board flash storage
• 2×32-bit 200-MHz programmable real-time units (PRUs)
• On-board flash programmed with Linux distribution
Connectivity and sensors
• Battery: 2-cell LiPo support with balancing, 6-16V charger input
• Wireless: 802.11bgn, Bluetooth 4.1 and BLE
• Motor control: 8 6V servo out, 4 DC motor out, 4 quad enc in
• Sensors: 9 axis IMU, barometer
• Connectivity: HighSpeed USB 2.0 client and host
• Other easy connect interfaces: GPS, DSM2 radio, UARTs, SPI, I2C, analog, buttons, LEDs
Software Compatibility
• Debian, ROS, Ardupilot,
• Graphical programming, Cloud9 IDE on Node.js


 
 

Hi EveryBody!
 
I came across three software libraries on github that I thought I would share:
pytelemetry telemetry pytelemetrycli  
pytelemetry provides high-level communication with any embedded device for remote control and monitoring. Specifically, pytelemetry implements a custom communication protocol, based on the PubSub (Publish/Subscribe) messaging pattern.   telemetry is the C implementation of the protocol. It can run on any embedded system, along with official distributions for Arduino and ARM Mbed.   pytelemetrycli is a powerful command line interface to interact with embedded devices using the protocol. It enables instant data visualization of any received data, full logging of communications, health monitoring of the serial port and much more.   It looks like the libraries have been developed for the mbed and the arduino so far.   I've got these on my "to play with" bucket list.   YMMV

My understanding is that Delay() is functionally equivalent to Sleep() in EMT which I believe is LPM3. I also am of the understanding that the Suspend command puts the MCU in LPM4 and requires a interrupt to return to an active state. I welcome those more knowledgeable to correct this if I am mistaken.

I don't know how good those books by Make are, but if you're looking for some beginner books for Arduino and Raspberry Pi and don't mind that you only get a digital copy (PDF, ePUB or MOBI), this might be of interest:
 
Humble Book Bundles: Arduino & Raspberry Pi
https://www.humblebundle.com/books/make-arduino-and-raspberry-pi
 
$1 bundle:
Make: magazine, Volume 38: Everything you need to know about DIY consumer electronics
Make: Basic Arduino Projects
Making Things See: 3D vision with Kinect, Processing, Arduino, and MakerBot
Make: Getting Started with the Internet of Things
Make: Getting Started with Netduino
 
$8 bundle adds:
Make a Mind-Controlled Arduino Robot
Make: A Raspberry Pi-Controlled Robot
Make: AVR Programming
Make: FPGAs
Make: Bluetooth
 
$15 bundle adds:
Make: Getting Started with Arduino, 3rd Edition
Make: Getting Started with Raspberry Pi, 3rd Edition
Make: Getting Started with Sensors: Measure the World with Electronics, Arduino, and Raspberry Pi
Make: Raspberry Pi and AVR Projects
Make: Arduino Bots and Gadgets
Make: Sensors
Make: Getting Started with the Photon: Making Things with the Affordable, Compact, Hackable WiFi Module
 

Have you tried getting the Arduino code working in Energia by itself?   If not, try to get it working in Energia before combining the two.  It does not look like you have done basic "porting" to get it to work in Energia. 
 
For example, this: 
byte sensorInterrupt = 0; // 0 = digital pin 2 The comment says it is supposed to be digital pin 2 but the variable says 0.  And there is no pin 0 in Energia.  You are also writing to pin 13 and calling it the status LED.  Pin 13 is the red LED on an Arduino.  In Energia it is RED_LED.  The code looks like it should be easy to get it going but you must carefully map the pins.

Here is a version written with fabooh. https://github.com/RickKimball/fabooh
 

/* * andyd273.cpp - simple fabooh msp430g2231 program to turn on a relay for 10 seconds * when the user button on the launchpad is pressed * * Created on: Feb 13th, 2017 * Author: kimballr * Pinout: * P1.3 is button on launchpad board * P1.6 is relay output (also lights led) */ #include <fabooh.h> #define SMALL_INIT4 /* don't initialize .bss and .data sections */ #include <main.h> #include <serial.h> namespace { const uint32_t BAUD_RATE=9600; typedef serial_default_t<BAUD_RATE, CPU::frequency, TX_PIN, NO_PIN> serial; serial Serial; } void setup() { PUSH2::set_mode(INPUT_PULLUP); P1_6::set_mode(OUTPUT); P1_6::low(); Serial.begin(); } void loop() { for (; { int n = 1; do (PUSH2::read()) ? --n : (n = 5000); while (n); do (PUSH2::read()) ? n = 5000 : --n; while (n); Serial << "turning on relay\r\n"; P1_6::high(); Serial << "wait 10 seconds\r\n"; delay(10000); Serial << "turning off relay\r\n"; P1_6::low(); } }   
I've included a compiled version of this so you can just load it on the msp430g2231 launchpad.
Use the mspdebug command to load it (Find mspdebug.exe someplace in the Energia install tree on your hard disk)
 
C:\ mspdebug rf2500 "prog andyd273.hex"
 
rename this file to andyd273.hex
andyd273.txt

First of all, welcome to the forum!
 
Sometimes doing things in the analog domain can be a viable option. Your requirements said "peak detector" to me when I read them. See the links below for some info on peak detectors and you may be able to find integrated solutions from the likes of TI, Analog Devices, Maxim, LTC, etc.
 
http://www.planetanalog.com/author.asp?section_id=396&doc_id=562072
 
http://electronics.stackexchange.com/questions/57866/how-to-sample-and-hold-on-very-narrow-pulse

First of all, welcome to the forum!
 
Sometimes doing things in the analog domain can be a viable option. Your requirements said "peak detector" to me when I read them. See the links below for some info on peak detectors and you may be able to find integrated solutions from the likes of TI, Analog Devices, Maxim, LTC, etc.
 
http://www.planetanalog.com/author.asp?section_id=396&doc_id=562072
 
http://electronics.stackexchange.com/questions/57866/how-to-sample-and-hold-on-very-narrow-pulse

I succeed  interfacing a 16x2 LCD with a 430G2553 trough a PCF8574A port expansor as I2C/parallel  converter using the DFRobot.com library posted by Fmilburn, after solving the Energia 18 known issue with the 2553 I2C pin association described here. 
To do this, it iwas necessary to copy the files twi.c and twi_sw.c  in the folder hardware/msp430/cores/msp430 in the Energia installation and, in addition to that, to edit the .cpp file in the library to add the line "Wire.setModule(0);" just before "Wire.begin(0);".
Two additional comments that could be usefull for those that could want to use the same configuration:
1) Pay attention to the chip used in the I2C backpack: Most of the code examples use the address 0x20, that is the default for the to PCF8574 (unless you had been playing with the A0, A1 and A2 pins) but today it is pretty usual to find the version PCF8574A where the default address is 0x38.
2) Most LCDs work with 5V, but the PCF8574 works fine with any voltage in the range 2.5 - 6 V. So, you have two alternatives to wire the LCD to the 2553 without using the space-consuming level converters:
- Connect the backpack to 3.3 V using an additional wire to feed the LCD with 5V, or
- Connect the LCD and the backpack to 5V, but removing the pull up resistors from the SCA and SCL lines on the backpack board and placing them on the pins 14 and 15 of the G2553 (to 3.3V, obviously).
BTW, you should also consider this last solution if you plan to connect more than one display (or other devices) to the I2C bus, to avoid the parallel of the individual pull up resistors.
JLV

>Does the AVcc and AVss needs to be connected
For the FET? Yes - it senses the '430
Also, with IAR, if you've configured the dbugger for the FET to expect an external supply, it must be connected. (FWIW, running devices off the FET can be problematic if the overall ckt draws more than about 60mA, if I remember correctly; it will need to be set up with an external supply and the debugger properly configured in the setup options)
Speaking of debugger setup, did you specify the correct '430?
>including external pullup resistors and capacitors
Am I correct in assuming you're refering to the reset pullup ckt?  And it's connected to the 3V3 supply?
Also, you don't explicity state that you're running the '430 off the 3V3 supply. Just curious...
Is the PCB of your own design? SpyByWire mode, if derived from an "experimenter" type board can lead to missed connections. This is based on past, sad, experience.

Well, I am not sure about the interrupt latency (not that familiar with the arch), and the price is more like $1.50ish... but Renesas RL78/G13 is close:
 
https://www.renesas.com/en-us/products/microcontrollers-microprocessors/rl78/rl78g1x/rl78g13.html
 
https://products.avnet.com/shop/en/ProductDisplay?storeId=715839035&catalogId=10001&langId=-1&productId=3074457345625366633
 
OK, going down a bit, RL78/G12 has a 24MHz part that's <$1:
https://www.renesas.com/en-us/products/microcontrollers-microprocessors/rl78/rl78g1x/rl78g12.html?status=No%3B&pin_count=20%3A20%3B#
 
https://products.avnet.com/shop/ProductDisplay?catalogId=10001&langId=-1&storeId=715839035&productId=3074457345625120989&categoryId=&fromPage=autoSuggest
 
IIRC the compiler is free, or at least there is a GCC port, and Renesas e2studio is a free Eclipse-based IDE.