Show Posts
Pages: [1] 2 3 ... 184
1  Using Arduino / LEDs and Multiplexing / Re: How to use 74LS138 or 74HC595 to muliplex two I2C signals? on: Today at 01:07:56 am
Pretty sure the Slave does not drive SCL - only  the master does.
That would be incorrect.
SCL can be driven low by either.
The slave holds SCL down during clock stretching.

--- bill
2  Using Arduino / LEDs and Multiplexing / Re: How to use 74LS138 or 74HC595 to muliplex two I2C signals? on: Today at 12:57:52 am
Both SDA and SCL are open drain as both the master and the slave can pull them down.
You could something similar by sharing the SCL lines and then using an analog switch (which is bi-directional)
instead of transistor to select which bus to use.

--- bill
3  Using Arduino / LEDs and Multiplexing / Re: How to use 74LS138 or 74HC595 to muliplex two I2C signals? on: Today at 12:10:00 am
You won't be able to use those parts to cross connect and select between two i2c buses.
If you have a couple of extra pins you could run two separate buses by using a software i2c library:

--- bill
4  Using Arduino / Displays / Re: Contrast problem using 1602A LCD over I2C on: September 22, 2014, 11:52:37 pm
You should be able to hook up only the power connections to the i2c backpack and then
adjust the contrast pot to see some pixels.

You should be able to see a row of blocks on the display which is the default powerup
state of the LCD.

--- bill
5  Using Arduino / Displays / Re: Example in GLCD does not get complied on: September 21, 2014, 11:45:48 pm
Your installation of the library is ok.
Also, the code appears to have compiled ok as well.
That error means the that compiled code when linked to create the final code image
is too large to fit  in the micro-controller that you are using.

I am no longer maintain the GLCD library code.
I would suggest that  you have a look at the openGLCD library which I currently am supporting.

openGLCD currently is a superset of the GLCD v3 library and has many new features as well
as bug fixes.
While it is not backward compatible with GLCD v3, there is a GLCD v3 backward compatibility mode
that can be used for existing projects while transitioning from GLCD v3 to openGLCD APIs.
openGLCD can be found here:

--- bill
6  Using Arduino / Project Guidance / Re: reef aquarium controller on: September 20, 2014, 01:58:37 pm

The technique as described in "blink without delay" example is essential to master if you want to do multiple things simultaneously,
So you should start there.

I see so much pushing of people to "blink without delay" examples.
While it is a way do things, the way those examples code things, it is not the  only way.
In fact there are other ways to multiple things that can be cleaner and easier from a sketch coding
There are several libraries that can be used to schedule your tasks which can make things
simpler and cleaner than using the "blink without delay" coding methodology.
Libraries that use timer interrupts can be particularly beneficial and can do things
that blink with out delay cannot do like high priority background priority processing.

So while blink without delay can be used, I'd encourage people to look at some
of the existing libraries for task scheduling before going down the blink without delay path.
In my view there is simply no need to drop down to the "blink without delay" coding
since there are libraries out there that can do the same thing or better.

Some of what will determine the direction of what to use and which way to go will be
guided by the overall architecture of the system.
i.e. are there real time events that need to be processed? If so interrupts will be needed.
Are are there many events or just a  few?

Here are a a few libraries to consider:
works similar to "blink without delay" but uses C++ objects for event task checking.
You create a metro object for each desired task & interval and loop() polls for the event
and when the event occurs, calls the desired function.
I would use this over typical "blink without delay" coding - as it is the same methodology but cleaner
from a coding perspective.

This library takes things to higher level by combining scheduled events and pin control.
It is very good for handling things like controlling output pins for timed durations
as well as event scheduling.
additional documentation:

This library also includes some examples for things like switch debouncing,
and tone/sounds.

These provide a realtime event callback using a h/w timer.
While providing true realtime event scheduling, care must be taking as to what and
how much is done in the event processing routine since the event function is
called at interrupt level.

--- bill

7  Using Arduino / Project Guidance / Re: AlarmLibrary or selfbaked? on: September 20, 2014, 01:57:41 am
I would switch libraries.
I'd use these libraries:
- Time - for the time tracking
A real time clock library pick one of:
 - DS1307RTC
 - DS3231 (I'd use a DS3231 for better accuracy and an internal temp sensor)
- TimeAlarms - for the Alarms
- Timezone - so you can run the proper timezone and get automatic daylight savings time changes

For a full blown Aquarium controller, I'd use existing libraries and focus on the higher level
functions since there are so many other things to worry about than the lower level code.
Maybe even add a GLCD for displaying information.

--- bill

8  Using Arduino / Microcontrollers / Re: Cheap Chinese clone: Programmer not responding on: September 17, 2014, 01:48:23 pm
Yes, there are always exceptions, but not common.  Now you are talking about design philosophy and that doesn't really help for the OP situation.  Besides, how would you handle the millions of existing boards out there with the auto-reset cap?  (not trying to criticize, just trying to make practical sense of it)

Sure. I'll agree that the cap on a FTDI board is the exception.
In terms of switching to RTS over DTR, there is nothing that has to be done
to existing h/w as RTS will work with or without the cap, which is why it is the better choice.

In other words, if I were going to design a serial board, I'd use RTS
since that will work with the target regardless of whether it has the cap.
I've actually modified my USB to serial boards to use RTS instead of DTR.
Another advantage of using RTS over DTR is that you can connect to the serial
port without reseting the target.  This is useful for certain types of monitoring.
This is not the case with DTR since it will always reset the board.

The only reason I mentioned the cap and auto reset stuff
is that it is possible that the FTDI board does have the DTR h/w hack capacitor on it.

My view is that when dealing with low cost h/w, is that I believe that the sellers are often just copying other designs
and not doing their own designs, because I often see design issues and actual h/w flaws in the boards.
Or  at least that has been my experience with low cost stuff from ebay.
Often the issues are usually fixable.

That is why when you buy the cheap stuff,  be prepared to look it over and make sure
the design is correct and doesn't have flaws.
There are many examples where the h/w design is broken.
I've seen many i2c RTC modules where you must go in and cut some traces to ensure you don't fry the
batteries, or to ensure that the clock crystal works correctly.

When boards are simple like these it is fairly simple to do.
You can look at the board or use an ohm meter to map out the traces.

In this case, the auto reset circuit is a pretty simple circuit.
It should only take a few minutes to trace out all of it on both boards.
There is way too much guessing going on in this thread.
The real answer is to simply look at the boards and go through the auto reset circuitry to
see what the problem is.
It will only take a few minutes.

Everything else is just pure guesses and potentially wastes time.

And at this point, I've already spent much more time writing posts in this thread
than it would have taken to just look at the board and determine the actual issue.

--- bill
9  Using Arduino / Microcontrollers / Re: Cheap Chinese clone: Programmer not responding on: September 17, 2014, 01:24:57 pm
Im not sure what you are referring to when saying the green hole?

From the photos I saw of your pro-mini board you can see the FTDI connector holes are labeled.
On one end you see "GRN" and the other "BLK"
That is telling you the orientation of the FTDI connector pins.

An original/official FTDI cable uses an actual cable with a 6 pin header on the end of it.
That header has six  pins on it and the wires going to the header pins are different colors.
The colors tell you which way the pins are oriented so you know
which way to plug in the header.

You can see in the attached diagram, the green wire is actually the RTS signal not DTR.
Using DTR was a quick and dirty hack done years ago before the s/w in the IDE
or avrdude controlled the RTS signal to reset the board.
The problem was/is DTR is not controlled by the application
but rather the Operating System software, however the RS-232 spec
says that DTR is not a toggle but rather a level signal that is activated when
the serial port is in use (the serial port device opened in this case).
The capacitor was a h/w hack needed to allow using DTR for autorset
within the existing s/w environment.
The  capacitor changes that DTR level signal to a pulse.

If you use RTS instead, there is no need for the capacitor
however, RTS must be controlled by the application.
The IDE and avrdude have been toggling RTS for quite some time.
It is toggled just before the download so when using RTS a cap is not needed.
A cap can still be used when RTS is used, but it is not needed when
RTS is used whereas the cap is still needed when DTR is used.

--- bill
10  Using Arduino / Microcontrollers / Re: Cheap Chinese clone: Programmer not responding on: September 17, 2014, 12:58:58 pm
Nope, FTDI programmers do not have an auto-reset capacitor on the DTR signal.  The only capacitors on the FTDI are used for decoupling.

The auto-reset capacitors are almost always on the main MCU board.
This is not always the case.
There are some FTDI boards that have the cap on them. I have one.
In fact in some situations you want the cap on the FTDI board and not on the main board.
This is  useful in some situations where say you are using debug wire for debugging
(you can't have the cap on main board when using debugwire)
but still want auto reset to work when using the serial port for uploads.

The other/better alternative is to remove the cap and use the RTS line instead of the DTR line.
The use of DTR and the cap should not be used anymore now that avrdude supports toggling the RTS line.
The use of DTR and the cap was originally done as a hack as it was a h/w solution for a s/w problem.
The s/w was updated several years ago so there is no longer a need to be using DTR for autoreset.
11  Using Arduino / Microcontrollers / Re: Cheap Chinese clone: Programmer not responding on: September 17, 2014, 02:50:50 am
Thanks. It sure does look like theres a cap on both FTDI and the board it self connected the the DTR line. If this is the issue - is there then any solutions without removing one of the caps?
The cap is in series with the signal.
You don't have to remove the extra cap, in fact removing it will not make it work,
it will fully disable auto reset.
It just needs to be shorted/replaced with a trace so the signal
doesn't go through.
You could remove it and replace it with a small piece of wire.

I couldn't see the traces on the ftdi board in the photo.
Are they there or are the traces on inner layers?

You should be able to test it with an ohm meter on the FTDI board.
Just measure between the DTR header pin and the DTR pin on the chip.

If there really are two, you will have to figure out which one to bypass.

On the mini, you could run a wire between the green hole to the trace under
the "RAW" which is the other side of the cap.

I couldn't see the traces on the FTDI board to tell how to do it.
It could be done by desoldering the cap and replacing it with a

--- bill
12  Using Arduino / Microcontrollers / Re: Cheap Chinese clone: Programmer not responding on: September 17, 2014, 02:03:43 am
The auto reset circuit is dirt simple.

Look at your boards and make sure that there is only a single cap in the circuit.
There should be a single cap in series with the DTR signal from the FTDI chip to
the reset signal of the AVR.

The boards appear to be simple dual sided boards so you can see all the traces.
Just look at the boards and verify that there is only a single cap involved.
You have to look at the board to figure out the wiring & traces anyway since you
have to map out the other holes and jumpers for things like ADC6 and ADC7.
It's not hard and should only take a few minutes.

I couldn't tell from the photos but it looks like there is a cap on the DTR line
of the mini.
It also looks suspiciously like there is a cap on the DTR line on the FTDI adapter
which could cause issues.

--- bill
13  Using Arduino / Displays / Re: Large LED sign on: September 17, 2014, 01:10:16 am
You specifically said you only had "only 1 week to do it".
That week is gone and now you are looking ebay parts with long delivery times.
If you really do have more time,
there are several solutions that could be done using mail order or ebay parts that have existing libraries
and  demo examples.

That matrix you linked to on ebay says 2-4 weeks for delivery.

So please tell us what your real requirements/needs are and
how much time do you really have?

What is it that you really need to be able to do and when does it really need to be up and working?
("need" being the key word vs "want")

Alternatively, you could buy a pre-built programmable led matrix sign.
It wouldn't be 64 x 32 but it could up and going very quickly and easily.
--- bill
14  Using Arduino / Displays / Re: Extended set of Fonts for Adafruit GFX Library on: September 15, 2014, 02:58:29 pm
Or even a 3rd (hidden in the first): "steal" the fonts from the other library.
Getting fonts or font data isn't really the issue.
The issue will be with the format of the data.
There are many different ways the font data is stored in embedded arrays
and eventually rendered on the display.
So while just grabbing the data from some other library is easy,
getting it to work and render correctly can potentially be a much larger effort.

Icons, that is easy.
Just make your own.
If you want to use some kind of standard format. XBM is a good choice.
It is fairly trivial to write a routine to render XBM data format.
Once you have that there are many tools that can write out XBM bitmap files
which are C data arrays and can be compiled directly into your code.
--- bill
15  Using Arduino / Displays / Re: Warning to users of some vendors LCD keypad shields. on: September 14, 2014, 05:09:55 pm
All of this information is already in this thread.
In fact nearly all of it is in the original post, including a description of
the issue and an attached schematic image.

As was discussed in the thread, the issue with a few of the solutions you are
considering is that they are very difficult to do, particularly your #1 solution.
While better than using a diode, it requires unsoldering and resoldering the LCD
to be able to get to the area where the transistor and resistor are located.
In post #1, I mentioned using the diode solution, not because it was ideal,
but because doing much else required lots of desoldering.

The reason you don't see any discussion of directly wiring d10 to the backlight
is that it is not guaranteed to work. LCD Backlights are typically driven with a transistor
because backlight current needs can vary between LCDs and some can consume more power than than an i/o pin
on a microcontroller can supply supply. 
While some backlights can be driven by an AVR pin directly, some can't.
That is why you typically see the backlight begin driven by a transistor.

This part of your post is incorrect.
Or a suitable diode can be placed in series between pin D10 and where the 4.7k  resistor attaches to the line to the transistor base.  If the diode's orientation is correct,  it will prevent short circuit of pin D10,  when it is set to OUTPUT and HIGH. In this case however,  you will only be able to turn the backlight ON with pin D10 in INPUT mode,  backlight OFF with pinD10 in OUTPUT mode (either HIGH or LOW).  You will have no intensity control.
Refer to the following corrected schematic – note that the free end of the diode should have been labeled as connected to Arduino pin D10,  rather than labeled with a cryptic BT.
Note: this is the same diode solution I used in the orginal post; however,
the entire point of the diode is to allow controlling the transistor and hence the backlight,
while D10 is always in OUTPUT mode.
With the diode, when D10 is HIGH, the diode blocks it but the pullup on the shield turns on the backlight, when D10 is LOW
it goes through the diode and overrides the pullup and turns off the backlight.
When D10 is used in PWM mode using andlogWrite() you
get dimming/intensity control.
The point of the diode is prevent the short between the D10 being HIGH and ground through the transistor
so that the D10 can be left in OUTPUT mode and driven HIGH or LOW with no issues.

The ideal solution would be to replace the transistor with an FET. Problem solved.
Not only do you get the backlight on by default by the pullup turning on the FET, but
D10 can overfide the pullup to control the gate with no issues of a short,
since there is no current flow into the gate.

But that requires being able to get to the transistor which is usually quite difficult because
it is under the soldered LCD.

There is a s/w only solution that is also mentioned in the original post.
In that solution, there is no modification needed to the board,
you must have D10 in INPUT mode to allow the pullup to turn on the backlight
and then set D10 to OUTPUT and LOW to turn off the backlight.
This work around precludes the use of PWM since that leaves the pin OUTPUT
mode all the time and during the HIGH portions of the PWM signal, there will
be the short through the transistor.

The original post mentions this and reply #1 has the code for the s/w work around.

--- bill

Pages: [1] 2 3 ... 184