Taggsladder

"if (bar[0]==NULL)" won't look at the pointer value, but instead the memory the pointer references, so that is right out, unless you want to know if the parameter is an empty string (only the null terminator)
"if (bar == NULL)" should work, in particular if you explicitly pass NULL in since you are comparing a value to itself, as should "if (!bar)", since NULL should be 0.
I just checked both (using gcc on a windoze machine) and they work as expected, so I can offer no insight as to why you would have a problem. I would suspect that you are seeing a symptom of some other issue than pointer comparison.

Depending on the application, you might try a latching relay instead.
 
In a low power ap, you can't beat them, but there are a few drawbacks, such as they do not drop out on power loss like a standard relay. Even in a non-low power ap, not needing to power the coil continuously is a nice feature. If you haven't seen a latching relay, among other places you see them is in electronic thermostats.

Hello,
 
Forget relay, just whack an 1k resistor between the G of the Q4 and C of the Q2 and put a 10V zener across that 10k resistor and the Vgs of the Q4 is OK. Use a N-FET instead of the Q1 & D5 and you are ready to go.
 
In fact, I would replace the Q4 with an N-FET too, just as a good practice. If MOSFETS cost half a penny each, why we still use BJTs? You can fly to the Jupiter just using the base currents of all those misused BJTs.
 
Cheers,
 
-=solipso=-

Q4 is going to see greater than 20Vgs, and may fail. Generally not a lot of leeway in these ratings. I wouldn't even count on a long life if you are running at just below 20V, as even small transients beyond 20V can damage the FET.
 
As for the two BJT's, I don't see any particular issue with Q2 until the gate of Q4 fails, as there shouldn't be dissipation greater than about 225mW while switching for Q2 at 30V supply (15mA*15V), and a few mW when full on. That shouldn't be sufficient to lead to heating issues. Once the gate fails for Q4, though, there is indeterminate current limiting for the collector of Q2, and likely Q2 will fail.
 
I would also put a 100K to ground from the base, though, to prevent leakage from turning it on, as the LED in the base line keeps the output pin from pulling it hard off.
 
I can say nothing about Q1 failing without knowing the diode you used. What is its reverse breakdown?
 
 
Once you are switching a load, things get more involved, as the dissipation in Q1 can be significant, especially if Ib is deficient. You need about 10mA Ib to hold the transistor in saturation at 200mA Ic, and I don't think you will have that here, which means you may end up with significant dissipation under load, if you are running at 200mA. You may also have dissipation issues with Q4 under load, but I am too lazy to look up the full data sheet right now. Things may be OK-- unless there is a major issue looking at the data sheet, I would go with this as a start for 100 to 200mA-- but I wouldn't put a product in the field without a lot of testing, as you are closer to the bounds than I might be comfortable with based solely on a paper design.

Because the reverse current of a zener is not exactly zero, so there's a tiny current leaking through the zener causing it to act as a non-linear resistor in parallel with your second resistor.
I don't think you can solve this problem using just passives. You could maybe use an opamp as an analog buffer, powering it from the same source as your controller will effectively clip your output voltage from the opamp to the maximum voltage allowed by your controller.

@@Taggsladder Glad it's all up and running. Thanks for the update.

Strange. Changed computer and used a new Launchpad and it worked straight ahead. Well well. Goofed something up
 
I used another library this time though. Don't know if it was the problem.
 
Used this library from here instead, don't know the difference.
https://github.com/pasky/Energia/tree/master/examples/7.Display/LCD_5110_430
 
Thanks anyway, sorry to bothering

Kind regards
Andreas

The datasheet also has this nice graph that tells you what the maximum frequencies are, given a certain supply voltage.
If you cannot lower the voltage to the desired operating level for the UART, you could use a logic level converter. You could also use the Vf voltage drop over a diode as a level converter, dropping roughly 0.6 to 0.7 volts per diode in forward setup.
So if you have a supply of 4V, which is too high for the MSP430, you can use one diode to drop it to about 3.3V, which is enough to power it at even 16MHz.
Then you need to drop from 3.3V to 2.4, which is again 0.7V, so you can use a single diode in the UART line from the MSP430 tx to the device's rx. Note that since the device will send out UART at 2.8V typically, you should not drop the level there, while it's still high enough to be considered a high level by the msp430. This is true because the datasheet says that worst case 0.75 Vcc is still considered high, 3.3 * 0.75 = 2.475V it's close, but since the current will be really low, so will the voltage drop (it's not really a constant voltage drop).
So even with worst case parameters, you can play things fine when using only 2 diodes.

http://energia.nu/download/

Thanks for everybodys input! Since it is working perfect and errorfree now I will stay with my setup until I have to move up if I need to incorporate new functions.
 
Thanks again, really appreciate it! This is a great forum with nice people.
 
Best regards
Andreas

Yes, the array always starts at zero, but the number inside your declaration "char a[2]" is defining the total # of units, not the "maximum index number".  Common mistake with C/C++ coding BTW.
 
So "char a[2]" has two valid indices: a[0], and a[1].  a[2] is 1 byte beyond the upper boundary of the array's reserved memory space.

It's not bad, either positive or negative requires pretty much the same treatment. I have designed many products used in autos and trucks. A resistor, a capacitor, and a Zener diode is ample protection for an input pin. If you are using the internal pullup or pulldown in the MSP430 then it might influence the choice of resistor value, use a higher value if you are sensing a 12V signal(4.7K or 10K is fine). But the basic three parts are all you need. Use a white or blue LED if you don't have a 3.3V Zener. Or two reds in series.
Regards, Bob

If you want to sniff all traffic sent from device 1 to device 2, all you need to do is connect that line to the RX pin on the launchpad.  When device 1 transmits a bit, both devices (device 2 and your sniffer) will read it.
 
I'm not an energia user, so I can't give specific code advice there, but the easiest way to pull this off would be to use the hardware UART peripheral and an interrupt.  When the launchpad receives (sniffs) a new byte on the line, the interrupt fires and does something with it.  Maybe pop it onto an array, or display it on a screen, or flash the LED....  There are lots of tutorials about interrupts on the MSP430 and lots of code examples on this site.  There should be a good write up in the two documents you referenced.
 
If you want to monitor both sides of the conversation (1--->2 and 2--->1) at the same time, things get more interesting.  Since a single UART module just has an RX/TX pair, to get two RX channels, you need two UARTs.  There are chips with dual UART, but the 2553 on the launchpad is not one of them.  You can, however, implement a timer based serial (which does exist already in Energia) to listen to the other line.  The same workflow would apply...use an interrupt to read the the incoming byte and then do something with it.
 
One word of caution.... UART lines are totem driven.  That means the transmitter asserts high and low by actively driving the line to Vcc or GND.  If you put two transmitters on the same line (sort of sounds like you did that in your description), if one tries to send a 1 while the other is still idle (0), the first transmitter will be pulling the UART line to ground while the idle transmitter tries to hold the line up.  This is called bus contention and creates a short-circuit condition that can potentially burn out the transmitter on the MCU or the entire MCU itself if it pulls enough current.  
 
The RX side is high impedance, and safe to do this as long as you aren't attempting to connect a ton of receivers in parallel.