Show Posts
Pages: [1] 2 3 ... 180
1  Using Arduino / Displays / Re: KS0108 glcd I2c communication on: August 18, 2014, 12:37:12 am
Just as a follow-up for completeness,
I gave Nick some updates for the library that he has incorporated to add Print class support
to the library.
This means that you case use the print() function to print strings and numbers just like on the serial port.
The library also has a function setInv() to set the inverse mode.

The library on Nicks page referenced above, now contains these updates.

--- bill
2  Using Arduino / Displays / Re: Multiple 192 x 64 KS0108 Displays using OpenGLCD library? on: August 18, 2014, 12:32:05 am
Ok, I see these are the displays with 3 chip selects.
I'll go update the code to support more chips & chip selects.

I did originally plan on using u8glib, however the lack of native 192 x 64 support made me think it would have been easier to approach what I am doing with modifications to openGLCD.
I'm kind of surprised at the lack of ks0108 192x64 support in u8glib.
Modifying openGLCD for multiple instances is a pretty big modification.
I have plans to refactor the code for a 2.x release but that is still a ways out.
When that happens, many things will change like multiple instances, and support
for different interfaces and user definable pins in the sketch along with support
for more display chips.

Also what I meant by artifacts is that when I have all of those data lines shared in parallel, when I, for example, send an image to screen #1, you will see some remnants of that same image appear on the other screens. This is happening after I modified the library to create different instances of screens. Its happening likely because of some timing issues while sharing data lines which I have been slowly getting to. But I would love an easier solution than what I am currently doing.
typically a timing issue will cause corruption on the selected display.
If the data is going to the incorrect display or the incorrect portion of the display or showing up multiple times
on the same display,, that is more than likely an issue with the chip select code
incorrectly driving the chip select pins and selecting the incorrect chip or selecting multiple chips.

I'll PM you when I have something to try as I'll want to work off line with you to
have you give it a try before I release it.
It may be a day or so before I have something ready.

--- bill
3  Using Arduino / Displays / Re: Multiple 192 x 64 KS0108 Displays using OpenGLCD library? on: August 17, 2014, 01:56:29 pm
What did you mean by:
Unfortunately with this current wiring scheme, I get artifacts on the other screens when drawing to a different one.

Not sure if you looked at Olivers u8glib library:
I believe that it can support multiple displays.
It works very differently than openGLCD.

Bummer on the number ofchip selects.
Some 192x64 glcds use 2 and some use 3.
Can you post a link to the displays you are using?
I'd like to see which one you are using to see if there are some other possibilities
other than having to use 9 chip selects and to make sure that the updates will work
with your displays.

But even if 9 chip selects are needed, it might be worth using something like
a 4-line/BCD to 10 line decoder like the 7442 to reduce it down to 4 pins
to save pins.

--- bill

4  Using Arduino / LEDs and Multiplexing / Re: 8574 I2C Port expander problem on: August 16, 2014, 12:40:16 pm
Depending on which Arduino board you have A4/A5 may not be the proper pins.
(Leonardo uses different pins for I2c)

First thing is to verify that you can talk to the chip.
You can do this by using an i2c scanner sketch. (search around you will find one)
If it comes back and reports the i2c address of the chip, then you are able to talk to the chip
and will know the i2c address.

Since the PCF8574 i/o pins are  "Quasi bi-directional pins",
the key to reading the i/o port is that you must make sure that all the i/o port pins are set to high first.
They are by default but if you have changed any of them you must first write 0xff to the port.
Then do your reads.

Keep in mind when using the pins for output, because of the "Quasi bi-directional" pins,
the PCF8574 pins cannot really drive current.
OK, it can drive a little current but not enough to do anything but feed as an input to some other chip.
It can sink current.
So if you want to drive an LED you have to hook up the LED anode to power then use the
i/o expander to pull the LED cathode down to ground.
Just make sure you don't try to sink more than 20ma per pin or 100ma total.

--- bill

5  Using Arduino / Displays / Re: Multiple 192 x 64 KS0108 Displays using OpenGLCD library? on: August 15, 2014, 11:57:54 am
Yes the current library only supports a single display instance.
However, there is a way to "trick" the library into using more than one.
You can trick the library into thinking the multiple displays
are part of a larger single display.
See the attached images for examples of using two 128x64 displays.

There are some issues to be aware of:
The current code uses uint8_t for the pixel coordinates so you can't have a pixel coordinate larger than 192,
which doesn't seem to be an issue in this situation.
This means that you would create a 192x192 display by creating a virtual display of the physical displays
my mapping them vertically to create the larger display.
That said, the current code can only deal with having 4 chip selects, so depending on how your chip select
signals need to work, it may not work for all 3 displays.
It is very likely that you will need more than 4 chip selects.
The change to support more than 4 chips selects is quite trivial and if you chose to go down this path,
I can update the library for this.

With respect to wiring:
All glcd modules will share
- data lines,
- R/W
- DI
- E
- reset (if used)

Each module will have its own contrast control circuit and pot for control.
(You might be able to share the pot across all of them using the VEE signal from one,
but  I've not dug deep enough to see if that could work or has any potential issues)

The chip selects may or may not be shared depending on how the
chipselects work for the GLCD.
More than likely the chipselects will not be shared.
So if you have a GLCD that uses 2 chip selects, then you will likely need to have 6 chip selects
and the macros that control the chip selects will need to be updated to support more than
the current 4 maximum.

Depending on how you are planing to use the displays wiring may be an issue.
(i.e. if they are not all very close to each other it will not work).

To use them/it, you use it as a single larger display. For text you can create text areas
that are within the desired physical display. Graphics is a bit of an issue since there is no equivalent
to a text area for graphics. So you have to be careful with your coordinates and clearing the display.
For clearing an individual physical display, you can cheat a bit and create a text area
that encompasses the pixels for the physical display and then use ClearArea() to clear that display.

--- bill

6  Using Arduino / Displays / Re: Warning to users of some vendors LCD keypad shields. on: August 15, 2014, 11:19:10 am
would like to know where is the "test sketch and it reports the shield has the issue. The shield has the issue."
the module turns on back lite bright blue with 16 spots on the upper line...
I'm not really understanding your question, but the very first post has all the information.

--- bill
7  Using Arduino / Programming Questions / Re: Digital input initialized to low but reads +5V on: August 11, 2014, 11:31:36 pm
Use this: const int buttonPin 8;

const int buttonPin = 8;
8  Using Arduino / Microcontrollers / Re: Security of Software on: August 11, 2014, 01:44:49 pm
Many people mistakenly believe that LGPL 2.1+ can be freely used in a closed source project/product
Apparently including the Arduino project leaders, since they state in various places that you CAN build closed source projects with the arduino libraries.  ( )  The GPL/LGPL actual license terms are as bperrybap states, and are obnoxiously incompatible with closed-source embedded products, despite what fsf sometimes seems to say.  The ability to produce proprietary products is very much oriented toward desktop-like environments :-(
While the license is more generally applied to desktop environments,
it is possible to make it work for embedded environments and
there are cases/examples of companies that have properly complied in embedded environments.
TIVO being a very notable one.
I've also seen the object files and makefiles for Samsung phone s/w, and for several embedded GPS devices.
You can also find the code and build tools for many android phones out there.
These are what are being used to create many of the custom roms you see out there.
The rebuild requirement is what ensures you have the needed components
to  allow you to rebuild a custom phone rom even though some of the code is closed source.

Some of the TIVO "abuse" of LGPL and GPL 2.x is what led Stallman to create GPL 3.0 to tighten
up the licensing.
Ironically, even many of the things that Michael Tieman was doing back in 1989 when
he started Cygnus were HORRIBLE and extreme abuses of GPL (CopyLeft - back then)
and are no longer allowed under current GPL terms.
Tieman took over and re-wrote the gcc compiler and linker in the main gcc distribution to use a
slightly different object format.
He then refused to give you linker source to a few modules for some of the newer risk processors
and also refused to license the binary objects to them unless you paid Cygnus
10's of thousands of dollars!
I tangled heavily with him back then and he finally relented after several of us were going to release
a backport of the old object format code to get around his abuse.

  (This is why you won't see a GPL license on avr-libc, or newlib, or anything I ever write, even though they're also open source.)
I went the other route and any open source projects I write are  GPL 3.0 which restricts its use to open source projects/products.
i.e. I'll only share my efforts with other fully open source authors/projects.

(Does FSF/etc actually pursue violators of the gnu licenses on software where they are not the license holder?
I don't think I know of any project that has been called out on the LGPL re-linkability requirement.)
Yes. But not so much in the US.
Also I haven't dug deep enough into the cases to be know whether the cases were LGPL vs GPL.
Go read about some of the recent cases with SFLC and SFC.
They have determined that there is enough money coming in to sustain the litigation.
So now they are taking on cases on behalf of other authors.
So far, this has  mainly been for large works like the linux kernel, or something like ffmpeg where there
are commercial violators with money go after.
What is interesting is that it only takes a single author to enable the case, and it can proceed even
if all the other authors willing decide to not to proceed or wave their rights.

Providing object files of your proprietary project that are linkable with new versions of the arduino libraries is likely to be pretty spectacularly useless to almost everyone.  But the requirement does make attempts to protect the object code in the chip using the AVR hardware mechanisms technically/legally meaningless. 
I don't necessarily agree with  all of that.
Projects that are developed  using more traditional unix style scripting tools like make, etc...
can be fairly easy to rebuild for a developer type person with average skills.
Where things are pretty hopeless is when using proprietary tools and IDEs which are quite
common for Windows development and environments like Arduino.

But I do agree that most people and users of a product are not developers.
And for them this kind of stuff is of no value.
But then those types would not be building any s/w anyway, so you have
exclude them from the people that the license was designed to offer rights to.

--- bill
9  Using Arduino / Displays / Re: [SOLVED]Controling 20x4 LCD with Serial interface module on: August 11, 2014, 01:36:30 am
I googled these kinds of charge pumps and i will try that out. Unfortunatelly it will take some time to buy and deliver the item :-/
wouldn't it be easier to run the backpack at 5v, and then either remove the backpack pullups and replace them
with external pullups to 3v or use an inexpensive i2c level shifter?

--- bill
10  Using Arduino / Displays / Re: [SOLVED]Controling 20x4 LCD with Serial interface module on: August 10, 2014, 05:39:50 pm
Have you tried using a level converter yet (to drive the display with the DUE , running the display off 5V and converting the Due signals to 5V for the display ) ?

Actually the signals on the backpack (and bus) are already 5v do to the pullup resistors being connected
to the VCC signal which was connected to 5v.
The DUE and the PCF8574 only ever drive the bus signals low. (The pullups are what creates the highs/1s)
The issue is the other direction, the 5v pullup signal on the bus from the backpack
needs to be level shifted to 3v for the DUE.

--- bill
11  Using Arduino / Displays / Re: [SOLVED]Controling 20x4 LCD with Serial interface module on: August 10, 2014, 03:47:42 pm
I tried to run backpack on 3.3V but it is not working. The backlight turns on as it should, but lcd shows no characters.
Just another thought.
Did you re-adjust the contrast?
It is possible that the contrast adjustment is so far off with the lower voltage that no pixels show up.

--- bill
12  Using Arduino / Displays / Re: [SOLVED]Controling 20x4 LCD with Serial interface module on: August 10, 2014, 03:45:59 pm
I was wonder the backpack and LCD would work at 3v. Bummer that it doesn't.
You have a 3v only Arduino board, and a 5v i2c device that won't run at 3v.
I don't think that the SDA/SCK pins have additional protection on them.
If the pullup resistors on the backpack are large enough,
the injection current going into the SAM  from using 5v will not burn it up.

I haven't looked at the SAM datasheet close enough to see what that limit is
but the total current will depend on the resistor values.
Once you know what the limit is, you can then calculate the smallest 5v pullup resistor
that could be used before the SAM is burned up.
If the resistor on the backpack is smaller than that, or you have multiple i2c devices on the
bus with pullup resistors and the overall pullup resistance is below that calculated resistor value,
then there is a risk of damage to the SAM.

The safest most reliable way to do it would be to either use a real level shifter
or remove the pullup resistors on the backpack and add external pullup resistors going to 3v.

--- bill

13  Using Arduino / Microcontrollers / Re: Security of Software on: August 10, 2014, 03:11:09 pm
Many people mistakenly believe that LGPL 2.1+ can be freely used in a closed source project/product very similar to an MIT, BSD or even a freeware license. This is not the case.
As a practical matter, has anyone ever been sued over this, and who enforces this?  How do they detect it?  Do they have a crack squad of engineers buying every electronics product in the world, including very niche products, no matter how expensive, to see if it has an Atmel chip in it or not and then reverse engineering it to see if obvious compile images of their software is in it?  Just wonderin'... 
Yes people/companies have been sued.

In terms of who enforces it, there are several
but FSF, SFLC and SFC being some of the better known entities.

I'll agree that as a practical matter it is often difficult to discover violations and
then enforce GPL/LGPL licensing against a violator can end up being expensive.
Not just in a chip, but in s/w products from major companies including the likes of Microsoft.

There are many dishonest people and companies out there stealing and repackaging
open source in their own products in order to unfairly monetize the work of others.

There is nothing to stop anyone from being dishonest, and in most cases, particularly
in a small run products, the likelihood of being caught must less being prosecuted for it
are extremely low.

It is no different than cheating in professional athletics. The rewards can be high
and the risk of being caught and punished for it are low, so some people cheat.

--- bill

14  Using Arduino / Microcontrollers / Re: Security of Software on: August 10, 2014, 01:35:18 pm
The real issue for you if you decide to sell this as a closed source product will be the s/w licensing.
If you are using Arduino libraries, it will be impossible to comply with the licensing terms of the Arduino libraries,
if you don't want to fully disclose all the source code

The issue is not with the gnu tools and gcc avr compiler s/w libraries that come with the IDE
but rather that Arduino libraries.
Different arduino libaries have different licensing terms.
The license might be GPL, LGPL, BSD, MIT,  or even freeware.
The bulk of libraries that come with the IDE are LGPL 2.1+
a few are GPL 3.0

Remember that the "free" in GPL/LGPL open source is about freedom and user rights.

If you use a GPL 3.0 library then all the code must conform to GPL 3.0 and you must
open source all the code - That is "price" for using a GPL 3.0 piece of s/w.
GPL 3.0 is a "You can use this code, if you share your code with everyone else" license.
Also, if you use GPL 3.0 you wave your  patent rights that might be related to your code.

Many people mistakenly believe that LGPL 2.1+ can be freely used in a closed source project/product
very similar to an MIT, BSD or even a freeware license.
This is not the case. While LGPL 2.1 source modules can be used in closed source projects/products,
in order to fully comply with the GNU LGPL 2.1+ license,  there are some things you must do.
This is the "price" you pay for using LGPL 2.1 licensed s/w.
The biggest thing you must do is that you must provide a means for the user to
rebuild the s/w image so that he can modify/update/maintain the image he received.
LGPL 2.1 is a "You are allowed to use it in a closed source project, but you must provide a means for users
to update any of the LGPL 2.1  source components used" license.

In other words, the high level goal of both LGPL and GPL is  to always allow the user access to and the
ability to modify LGPL and GPL modules even once they are linked into a larger work.
In other words, even with LGPL, you can never lock out and users ability to modify the open source portions
of the code, even if it is used as component of larger closed source project/product.

The LGPL 2.1 license is quite clear that if you use it in a closed source project/product you must
provide all the pre-compiled objects and build scripts so that an end user can rebuild the image
with updated versions of the open source modules.

For example, if you ship an image in your AVR, and there were an update/bug-fix to the digitalWrite() code,
the user has to have the ability to  re-create your the image using the updated code.

The Arduino guys very much dance around this issue.
Here is a excerpt from their FAQ page:
Using the Arduino core and libraries for the firmware of a commercial product does not require you to release the source code for the firmware. The LGPL does, however, require you to make available object files that allow for the relinking of the firmware against updated versions of the Arduino core and libraries. Any modifications to the core and libraries must be released under the LGPL.

The problem with this, is that section 6(a) of the LGPL 2.1 requires more than that:

Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library.

In the case of shipping a product with a firmware image that uses Arduino code,
that would fall under the the executable work, portion above,
which still requires that the user have the ability to modify the open source components and create
a modified executable (firmware image) with the modified library.

Where this gets very sticky and impossible to comply, is that currently the wimpy Ardiuino IDE build system
has no way to build/re-build an image using pre-compiled images.
Because of this,  it is impossible to comply with the LGPL 2.1 licensing terms when trying to create
a closed source Arduino project/product that uses the Arduino IDE since the user has no way
of modifying/updating the code of any of the LGPL 2.1 modules used  and then re-creating a new firmware image as is
required by 6(a) of the 2.1 LGPL

So in the ultimate irony, the Arduino platform and core libraries used LGPL 2.1 licenses but there is no way
to comply with it for closed source Arduino projects/products so they might as well have used GPL licensing
which would have made it more obvious that you can't create closed source projects.

--- bill
15  Using Arduino / Displays / Re: [SOLVED]Controling 20x4 LCD with Serial interface module on: August 10, 2014, 12:30:54 pm
What voltage did you hook up to the backpack?
From looking at the photo of your board in the link you originally provided, it looks
like that board has pullups on it.
(I cant see what value they are)

Since the DUE inputs cannot handle 5v, this can create a problem if the voltage used
to the backpack is 5v since the pullups on the backpack are connected to the voltage pin
which means that the bus pullups are pulling up to 5v rather than 3v

I'm not exactly sure what voltages the SAM is being run at or which i/o mode the Arduino
code uses, but if I understand the SAM3X8E datasheet correctly it can handle about 2ma of current on
the i/o pins. (assuming the worst case limitation)
If I'm understanding it correctly (which I might not), then you must not try to push/pull more than
that 2ma current.
When using 5v on your pullups you are creating a voltage differential above what
the SAM is rated for but the current draw is being limited by the pullup.
If I'm understanding the limitation  and doing the math correctly that means that it probably
will work without damage when using 5v as long as the pullup is greater than 2.5k

However, to avoid any potential for damage the pullups really
should be going to the 3v3 signal not the 5v.
So as I mentioned earlier it can make it tricky to wire up 5v i2c devices if
they can't be run at 3v.

So what voltage did you run to the backpack?

--- bill

Pages: [1] 2 3 ... 180