Looks like your library supports 16x2 and 20x2, but doesn't not support 20x4 LCDs.

It is supposed to support 20x4, what's not working for you?

!c

Well the issue (and limit) is the maximum continuous forward current rating of the series polarity protection diode wired between the external power connector and the Vin pin. This diode will pass all current supplied to the board and any current consumed off board via the Vin pin. Does anyone one know the actual diode part number used and it's max forward current rating? I have no doubt one can draw more then it's safe rating but it's not an accepted good engineering practice to do so. I always assumed it was a bog standard 1 amp diode?

You know, now I feel like an Idiot with a capital I.

No matter how many times I've looked at that schematic, I've blocked D1 out of my mind until this moment.

Now I'm nervous, hah. (Well, not really... But now I just have to know!)  I'm going to take a look when I get home and see if I can discern anything...

!c

Wow, thanks guys.  That's why I love this community, everyone helps each other out.  I've spent a few days searching the internet for something similar to LiquidCrystal library and looks like the SparkSoftLCD library is pretty close.  I think I'll probably use the SparkSoftLCD library because I wouldn't have to make too many changes to my sketch.  Thanks for the other suggestion; it had me pulling my hair out last night.  it kind of makes sense now.

No problem at all =)  Glad to be of service!

If you have any issues with the library, let me know.  (Disclosure: I'm the author =)

!c

It's worth noting that I have about a thousand devices in the field drawing from 1.25A to 2A @12V through the Arduino Vin pin (to a shield), and none of them have burned out any traces or melted any pins in the Arduino =)

The biggest concern I had originally, was the trace size from the dc plug to the Vin pin, which seems fairly small, and AFAIK the Arduino boards use 1oz pours.  (My shield uses 20 mil traces for the biggest consuming paths, and 2oz pours.)  However, this has not proven out to be an issue.  However, I still have some serious concerns in the long run, considering a lot of the female headers I see out there are rated @ 2A through each contact.  I don't know the specific P/N of the headers used in the Arduino, but I'd bet money on them being around the same.

!c

Have you looked at http://openmoco.org/node/153 ? The SparkSoftLCD library, has the function cursorTo(row, col) - it would be extremely simple to reverse these arguments in the library, to match the order of arguments in liquidcrystal library (col, row).

Of course, if you just want to figure out how to set the row and column, this may be more instructive than your example (from the above library) :

Code:

   switch(line) {
       case 1:
        break;
   case 2:
pos += 64;
break;
   case 3:
pos += 20;
break;
   case 4:
pos += 84;
break;
   default:
return;
   }
 
   
   pos += 128;   
   
   sendControl( pos );

!c

Solution: I converted all functions that return array of chars into void functions.

Almost certainly what you were doing was returning a pointer to a local variable that went out of scope. While that memory will not be immediately overwritten, pointing to data on the heap is dangerous because you never know when the memory will be clobbered.

Does the compiler not at least throw a warning when you do that?  I haven't tried such in arduino, but I know Qt will not compile when you attempt to return a pointer to a local variable from within a method or function.

!c

I can see (via LCD) the "trash" on this data structure just after writing the correct data using different functions. This is the scenario that the program is "locked" and if continues after the loop, the behavior of the device is unpredictable. Therefore, the leakage seems to be caused by the mentioned functions and their usage of the RAM memory.

I'd better dollars to donuts you don't have a memory "leak" (which is memory allocated but never freed when no longer needed, yet continuing to allocate new memory causing usage of RAM to grow), but instead, you have a memory over- or under-flow. This happens, most notably, when using arrays and forgetting to check the bounds of the array when using incrementing indeces, and so forth.  This is more than likely why you're seeing "garbage data" in your printed data - if it's at the beginning of your data, you likely overflowed the variable before it.*

But, without seeing code - that would be nearly impossible to ascertain at a distance.

If you're not using new or malloc, then you're likely not having anything like a memory leak. (As already stated.)

* - it's actually more complex than this, but I'm not sure I'm qualified to explain heap, stack, and how variables are declared - I've just had to fix a lot of similar issues myself =)

!c

To add to what PaulS said, if you're going to use a persistent buffer, it should be large enough to hold your largest command data set.  Because of this, you will need to make sure that you always memset() it back to all zeros -before- writing anything into it, otherwise you will have bytes left over in it when reading a shorter command.

e.g.:

Code:

memset(cmdtrans, 0, CMDBUFSIZE * sizeof(uint8_t)); // CMDBUFSIZE defines maximum buffer len

!c

1: Do not mix logic.  Mixing "which LED do I turn on," and "should I turn any LED off" is a big part of your problem.  They are distinct issues, and should be treated distinctly - not only will this generate less code, it will also make it much easier to debug.

2: Avoid redundant code.

Imagine the following:

Code:

int led1 = 2;
int led2 = 3;
int led3 = 4;
int led4 = 5;
long int time4 = 4500;
long previousMillis = 0;

...

boolean is_lit = false;
byte cur_led  = led1;

void loop() {


  if( ! is_lit && digitalRead(buttonState1) == HIGH ) {

      // no led is currently list

    cur_led = random(1,4) + 1; // LEDs start at pin 2 and move sequentially to pin 5

    digitalWrite(cur_led, HIGH);
    
    previousMillis = millis();
    is_lit = true;

  }

  else {

    // an LED is lit currently.

     if( millis() - previousMillis() >= time4 ) {
          // enough time has passed to turn off the LEd
        digitalWrite(cur_led, LOW);
        is_lit = false;
     }
  }
    

}

Note here the logic is such:

If no LED is lit and button is pressed -> determine which LED to light up + light the LED + indicate time LED was started + indicate that LED is lit up
If an LED is lit -> determine if enough time has passed to turn off the LED, if it has - turn it off an indicate that the LED is no longer on

Note that your previous code wouldn't turn off the LED if the button wasn't pressed.

!c

If you wanted to be slick, you could do it quite easily (and a lot faster, with a lot less code) using the port input pins register.

Assuming you used pins 0-7 (yes, using the RX/TX may not be safe =), you could quickly do:

Code:

result = PIND;

Yup, that's it =)

PIND = one bit per state, where the first bit (Bx) is pin 7 and the last bit (B0000000x) is pin 0.  Thus, Binary one = B00000001, and only having pin 0 high would cause PIND's value to be B00000001.  If you spread the pins across two registers, you'd need to do some bit-shifting and some and operations to get the right values in place, but that's pretty easy to do.

The drawbacks?  You have to use PIND which may change on different processors.  The benefits?  If you're doing time-sensitive stuff, this will run eons faster than 8 digitalRead()s, and will compile to a lot less code.

!c

Hi,

I have a simple question...

How much of current i can get from arduino mega if is connected to pc?

Thank Koudy

From what on the Arduino mega?

From the 5V connector, from one pin, or from all pins combined?

!c

Me to as I've been using logic levels rather than just looking at the state of the transistors, ie on of off.

So your last circuit will work I think, even without the pull up resistors. As long as the OK1 transistor is driven hard enough to drive a LED.

______
Rob

Yeah, it got my head all turned around - but it's looking pretty clear now.  I think you're on to something with the transistor's ability to handle that much power - the maximum dissipation is 150mW, and at 1.1v/20mA that's 176mW for 8 LEDs. I'd run them lower, but experience has proven problems with the triggered devices when I run the NTE3086's this low! (Too much voltage drop for some of them, the best performance from the left-hand side with a wide range of triggered devices has been running @ 30mA.)

So, now the only trick is to get enough power flowing through there... Much easier problem, I think =)

!c

EDIT: N/M the above - fully within power spec- recalling there are two transistors input, that means 4x LED per transistor, or 132mW @ 1.1V/30mA.

The 1.5V comes from a single AAA battery cell (not shown)

Here is the datasheet for the NOR chip CD74AC02: http://focus.ti.com/lit/ds/symlink/cd74ac02.pdf  -- it works with Vcc from 1.5->5V

The LED in the NTE3086 has a typical voltage of 1.1V @ 20mA.  And the V_CE saturation voltage is 0.2-0.4V at 16mA for I_F, so well within the 1.5V supply voltage.

These being the only IC's in the circuit (this is just a splitter device, to replicate from 2 outputs to 8 - I'm only showing 2 outputs for simplicity's sake), should have no issue running from a single AAA cell.  My only real concern is the value of R1/2 being too high to register a proper high signal at IC1x - that's easy to solve by reducing the value though.

I want the C+Es on the outputs to be in the exact same state as the C+E's on the input.  I just want to replicate the status of the two outputs into 8 outputs.

The function table for the NOR indicates that if either input is HIGH, it outputs a LOW signal - this means that in drawing 1, by default it is outputting a LOW signal when OK1/1's LED is not engaged, because the OK1/1's Collector is pulled HIGH.  Thus, when LED OK1/1 is off, the following is the state of the function table:

IN1    IN2    OUT
H       L*      L

* IN2 is tied to GND, so is always low.  If that is the case, and the output of the NOR is connected to the cathode with the anode tied directly to 1.5V, would that not result in the LED being on on OK2/1 when OK1/1's LED is off?  (I.e. allowing voltage to flow from A to K because K is biased low?)

I can't seem to figure out how I've gotten that wrong?  Is that not the function of an NOR, and is that not the state of the IC1C when OK1/1 LED is not engaged? Or is the pull-up too weak?

Your table #1 also seems to be wrong to me (it presumes an inverter when I have an NOR):

-----LED OK1 TRANS -----INV----- LED OK2 TRANS -----
hi    on            on      lo           hi    off           off      hi

It should be:

-----LED OK1 TRANS -----NOR----- LED OK2 TRANS -----
hi    on            on      lo           hi    off           off     off

Even simplifying it to use an inverter like below, we still have the cathode low on OK2/1 when the base is NOT energized on OK1/1 - as the input is pulled high by default, thus would not the LED on OK2/1 be energized in this state, and therefor energizing the base on OK2/1, resulting in an inverted state between the input and the output?



I'm pretty thoroughly convinced that I can make it work now, with an NOR connected between the anode and the collector.

To be honest though, I'm starting to think there isn't a need for either an NOR nor an inverter!  The following seems to make perfect sense to me:



It seems like I've made things way over-complicated and just confused myself along the process, if what I said earlier holds true, then this must also - given that I can completely prevent the anode from ever being pulled to 0V, it should never have a reverse current condition?


!c

However, the arduino pins can only supply 40mA,

No. The arduino will get fried if you try to pull more than 40mA from it. It is very easy to do this.
...

You should not take more than 30mA in any good design.

The 1K series resistor is too high, you should use something between 200 to 500 ohms.

(I'll make sure to add the words "safely, briefly" next time I say that.)

To be in-spec with the data sheet (1.2-1.4V at 20mA), that should be closer to 200 than 500, otherwise you're still going to have issues.  At 500, you're getting close to the min CTR.

!c

Hmm, switching to the cathode on OK2 just seems to invert our logic entirely, and an NOR or inverter don't work at all - remember the emitter is shared between both left-hand side OK's, meaning I can't look at the emitter for which one is triggered, and I'm trying to follow the collector instead - to see if it is sent to ground by pulling it up gently...

Using an inverter or NOR on the cathode actually creates the inverse logic you mention, see:



Note, it is now turning on the right OKs (OK2/1 and OK2/2) whenever OK1's are not triggered.  (Unless I'm missing something completely fundamental here!)

Now, by switching back to the anode, the original image looks much more correct with the following changes -- but the presumption I have here is that the transistor in OK would behave in such a way as to make it appear that the collector is connected to ground, and there wouldn't be so much resistance within the transistor that I would still follow the path to 1.5V (I'll admit, transistors aren't my strong suit - I can follow calculations and instructions, but my understanding depth of them is fairly shallow):



That is to say, when the LED in OK1/x is not triggered, both the collectors will be pulled high, which will cause both NOR's to output 0.  However, bringing the LED on OK1/2 high will cause pin 11 on IC1D to go low, and make IC1D output 1, while IC1C still outputs 0, right?

!c

EDIT: I think I've answered my own question here - it's an NPN transistor, so, the electrons do in fact flow from Emitter to Collector, and therefor this design should work fine.