Show Posts
Pages: [1] 2 3 ... 156
1  Using Arduino / Microcontrollers / Re: RTC time running twice the speed with Time Library on: Today at 02:38:38 am
The speed you see on the datasheet is the maximum.
The core code must be told the actual speed that the part is running.
The speed you tell the code doesn't modify the actual speed it merely
tells the core code what the speed is.
This is why they must agree.

If things are now working when you are telling the core code that the AVR
is running at 16Mhz, it must be running 16Mhz rather than 8mhz.

Are you sure the board you have was running 8mhz?

--- bill

2  Using Arduino / Displays / Re: drawBitmpa not working on: April 18, 2014, 08:18:29 pm
So, your 307200 byte array was going into 96kB of RAM.
Assuming a DUE is being used,
RAM wouldn't be used for the actual data array since it was declared as const
and const won't be in RAM.

That said there are some things that don't add up.
The first post said it was a DUE, but yet the code is including
a header file <avr/pgmspace.h> which is a AVR specific header file.

--- bill
3  Using Arduino / Displays / Re: multiple - Arduino Serial IIC/I2C/TWI 2004 204 Character LCD Module on: April 18, 2014, 05:17:31 pm
No.
Vertical is up and down not horizontal.

--- bill
4  Using Arduino / Microcontrollers / Re: RTC time running twice the speed with Time Library on: April 18, 2014, 04:29:15 pm
The Time library uses the timer interrupt to track time between sync intervals.
You are using the M328 at 8Mhz vs the "normal" 16 Mhz.
The processor does not know how fast it is running.
The IDE tells the core code the speed of the processor at compile time
based on the board type selected.
My guess is that you have selected a board type that uses a 16Mhz clock
but your AVR is actually running at 8mhz.
When you do this, the core s/w will be confused because it was told
incorrect information.
The result is twice as many interrupts per second will happen than it was told would happen,
and so time will appear to run twice as fast.

My guess is that this is your problem.
I'd also bet that all your delay() calls would also finish twice as fast as they should.

Make sure to select a board type that has the F_CPU set to 8mhz vs 16Mhz.
You can verify the speed that the IDE is communicating to the core code by
turning on verbose output:
[File]->[Preferences]
and check the box
Code:
Show verbose output during: [x] compilation

When you build the code look at the output and
look for the F_CPU define.
It will look like:
-DF_CPU=8000000L

If you see this:
-DF_CPU=16000000L

Then you have a problem and need to pick another board type
or create one that for your board.

--- bill



5  Using Arduino / Displays / Re: multiple - Arduino Serial IIC/I2C/TWI 2004 204 Character LCD Module on: April 18, 2014, 04:11:00 pm
See the solder jumpers labeled A0, A1, A2  on your backpack?
Those are the A0, A1, A2 pins on the PCF8574 chip.
That is how you set the lower 3 bits of the i2c address for the chip.
http://www.nxp.com/documents/data_sheet/PCF8574.pdf
If you put a solder blob across the vertical pads it will alter the i2c address.
Then there are 3 address bits using A0, A1, and A2 that set the lower 3 bits of the i2c address
which you can set to allow up to 8 chips to be addressed on the same i2c bus.
If you have an i2c address of 0x27, then
more than likely the chip has a base address of 0x20 and
the three 10k resistors you see along the bottom of the board marked 103
are pullups on the A1,A1, and A2 pins which sets them all to 1
which sets the final address of the chip to 0x27.


To change the address, all you need to do is put some solder
(a blob that bridges the upper and lower pads)
on one or more of the A0, A1, A2 solder jumpers.
This will allow you to select an i2c address between 0x20 to 0x27

example, a solder blob on A0 would change the address from 0x27 to 0x26
a solder blob on A1 would change the address from 0x27 to 0x25
a solder blob on A2 would change the address from 0x27 to 0x23
a solder blob on all of them would change the address from 0x27 to 0x20

etc...

--- bill


6  Using Arduino / Displays / Re: Degree symbol - GLCD with KS0108 driver on: April 18, 2014, 10:54:49 am
With most glcd libraries printing a degree symbol is very easy,
just print the code value in the font for the degree symbol.
However, the ks0108 module has no built in fonts.
The fonts are implemented in the s/w so you will need to use a font that includes
a degree symbol.
Depending on which library you have it may or may not include a font with a degree symbol.
Also depending on which library you have, you may be able to define custom fonts.

The bottom line is you need to use a font that includes a degree symbol.
If the library doesn't include a font with a degree symbol, you may be able
to create a new font that includes one.
In the absence of being able to use a font with a degree symbol, you could
define a bitmap or even draw the pixels.

--- bill
7  Using Arduino / Displays / Re: Warning to users of some vendors LCD keypad shields. on: April 16, 2014, 11:38:01 pm
This thread seems in a mess to me and is confusing.

The top post states to look at the circuit especially at the backlight transistor.  That shows only connections to pins 15 and 16 of the LCD,  and to VCC and 0V,  it shows no connection to D10 as mentioned. 

Yes it does. Look closer at the schematic. While LCD pin 15 is connected to VCC,
LCD pin 16 is not connected to ground. It is connected to a transistor.
D10 connects directly to the base of the transistor.
When D10 is high, the circuit allows current
to flow into the base out the emitter with no current limiting resistor.
And that is the core of the problem.



So I purchased board and checked it.  As expected it was the same,  connection to pin 15/16 of the LCD,  power and gnd with no connection to D10. 
That might be the case, if so, then your shield is not the same as these others and does not have a transistor
for backlight control and so it does not have the problem.
Did you run the test program? What did it say?


Then look at the photos of the Diode mod,  it clearly shows the diode connected to the trace going to D8 not D10.
I assure that the diode is going to D10 and not to D8.
While not really shown in the photos, (until now) as mentioned in the original post:

Quote
The trace to D10 goes around the header then drops through the board.
The trace can be cut and a diode dead bugged to the board.
note: I just updated the 2nd photo in the 2nd post to show the other side of the header
for clarity. As you can see the diode connects to t trace that goes to D10.


Going by the photos the board looks the same as the one I have here,  but I can see no issue with it at all,  and it matches the circuit as shown.
Maybe you haven't looked close enough? Or maybe your shield is different.
If your shield really is like this one or the others
that has backlight control, then there is a transistor and then the LCD backlight pins
(pin 15 and 16) are not directly connected to power and ground.


what am I missing here?  Very confusing thread.....

Not sure. I think perhaps you are not understanding what the problem is?
which is that the base of the backlight control transistor is being driven by an Arduino pin
an there is no current limiting resistor in the circuit path through the emitter
to ground

--- bill
.

8  Development / Suggestions for the Arduino Project / Re: Need mechanism to pass defines to library cpp files on: April 16, 2014, 10:42:00 pm
No overhead for unused data. To achieve what you want, no mods are needed.
Same is true for code.

The gcc tools have gotten a lot more sophisticated/smarter in the past few years.
There are new options that put every single function and data element into its own section
and if there is no referenced to that section, the linker tosses it out.
It requires cooperation between the compiler and linker but the IDE turns on the
options to enable it.

make can do anything, since it just a dependency rule based system to run commands.
Most of the makefiles that I create for doing builds/compiles
use real libraries and create archive files and even peek into the archive files for dependencies.
I only wish the IDE was using meak underneath the covers vs trying to create their own set
of rules.
Much of the Arduino build nonsense that the IDE is doing and has been doing over the years would have been avoided.

As far as the libraries being real "libaries". The IDE is treating them similar to real libraries.
The distinction being that they are compiled separately vs being combined with users source when compiled.
The only thing not being done by the IDE is to combine the library objects into .a archive file.
The IDE does create a library archive file by combining all the core objects into a .a archive,
so for sure the Arduino core library is a true archive library.

In the early days, the IDE was combining everything into one mega gigantic file and then compiling it.
For many unsophisticated users, that probably would work better and even allow certain kinds
of optimizations that cannot be done when things are separate modules and compiled separately.

Maybe what was throwing me is this:
Quote
the Arduino libaries are not really libraries, but module of code that get included in the compile process.
as it was ambiguous to me.
I had assumed that you meant that the library source was getting included in the users sketch code
as part of the compile process where both were compiled together.
While that used to happen long ago, the current IDE process treats the libraries as libraries and compiles
the library modules separately. The only thing the IDE doesn't do right now is build a library archive .a file
for the libraries. (well it does for the core library).

--- bill

9  Development / Suggestions for the Arduino Project / Re: Need mechanism to pass defines to library cpp files on: April 16, 2014, 08:04:06 pm
wanderson,
In the bigger picture, without seeing your new code or understanding on how you
are changing the API,  it really isn't possible to make any
recommendations since it can depend on how you are implementing things.

For example, if the function names for obtaining floating point random numbers
vs integer random numbers is different or are overloaded functions, then there is nothing that you will need to do.
The IDE sets the gcc compiler and linker options to remove functions that are not called.
So while the Entropy library object will have the compiled code for the functions for both integer
and floating point functions as well as all the s/w floating point routines in it,
only the functions used will actually be linked in.
i.e. if you don't call the floating point functions, they will not be linked in
and all the floating point s/w support will also be yanked out.


git has great support for branches. Perhaps you could push your latest updates
into a branch so we could take a look at it?

--- bill
10  Development / Suggestions for the Arduino Project / Re: Need mechanism to pass defines to library cpp files on: April 16, 2014, 07:45:52 pm
Libraries are not slaves to the user of the library.
The library code is compiled separately and the behavior you are seeing is
the expected behavior. This is how libraries work.

Yes, and if the Arduino environment was actually using libraries I would understand that I would have to use a different method to get around the problem, for instance letting a define specify which vesion of the library to link into the code; however, as you point out below, the Arduino libaries are not really libraries, but module of code that get included in the compile process.

As such something simply like would be nice.

Code:
#define ENTROPY_FLOAT
#include <Entropy.h>

All the other Arduino libraries like your Entropy library are still being treated like a library by the IDE.
The IDE doesn't create a library .a archive file for it but otherwise the library is being handled
very similar to a "normal" library.
The files in the library are each compiled separately from the users code (sketch files) and then
then the library objects are linked in with the users code.
(The library files are not included or merged into the same compilation unit as the users sketch)
The only difference between "real" libraries and what the IDE is doing
is that with the exception of the Arduino core library, the compiled objects in the other libraries
are not archived into a .a archive file before they are linked in.

--- bill
11  Development / Suggestions for the Arduino Project / Re: Need mechanism to pass defines to library cpp files on: April 16, 2014, 02:18:51 pm
Libraries are not slaves to the user of the library.
The library code is compiled separately and the behavior you are seeing is
the expected behavior. This is how libraries work.
i.e. a library is a separate compilable module that must be capable of being compiled
separately, in advance, and without any knowledge of any code that uses the library.
In most build environments, libraries are compiled up front, saved away, and then used (linked against)
as needed. Since multiple users of the library might want to set library compile defines separately/differently
there would be no way to build the library object without seeing the user code that used it.
The Arduino build methodology is not all that smart and does not save things like the compiled libraries
for re-use across different sketches. However, in the Arduno environment, even though the libraries
are not being saved for other sketches to use, the libraries are still actual libraries and
since a library is a separate entity from the code that uses it, there is no way to do what you are wanting.


There are some ways to kind of do what you are wanting to do.

You could play some games with the pre-processor to rename the names of the
functions that the user code ends up calling.

That way you could have two sets of functions in the actual library,
one that uses floating point and the other that does not.
To select which the user simply puts a #define above the inclusion of the library header.
(The default might be floating point, then if the magic define is set it drops to integer only)

Then in the library header file, the header remaps all the function names
based on some ifdef condition

At link time the appropriate function would be pulled in and you end up with
the version of the support you want/need.

Another similar alternative would be to still have the two sets of functions
but then have an inline wrapper function that simple calls the integer or floating
point version. The inline wrapper function would be in a header file that the users
sketch code includes. That way, conditionals could change it appropriately.
The library would still have to have both sets functions but only the ones
actually referenced would be linked in.

I do some similar things in my openGLCD library to map some older functions
to the newer functions. In my case, I even manipulate the parameters being
passed to the functions.
The user sketch code doesn't change, all the magic is done by the mapping macros.

Another alternative that would work but some might call "ugly" would be to put all
the code in the header file.
The code is no longer a library at that point but you could then do whatever you
wanted and any conditionals you put in the user code prior to including the header
file would work as you are wanting.

--- bill
12  Using Arduino / Displays / Re: I2C Display issues, can't get it to work... on: April 14, 2014, 04:35:43 pm
JamesDonaldChilds,
what you need to understand is that the vast majority of the "I2C" displays out there are not
really I2C LCD displays.
They are hd44780 LCD displays with a backpack on them that contains an i2c i/o expander chip.
Not only are there different i/o expander chips, but the i/o expander chip's 8 pin output port
pins can be wired up to the hd44780 interface differently.

So if you start to look at the combinations there are essentially 3 categories:
1) Native I2C (most "I2C" LCDs do not fall into this category)
2) hd44780 LCD with PCF8574 i/o expander backpack (most "I2C" LCDs fall into this catetory)
3) hd44780 LCD with MCP23008 i/o expander backpack

Then, within those 3 categories, the various devices can work differently.
So between the 3 categories, you first have to have a library that supports it.
Then once you have library that supports the type of interface/device you have,
you then have to make sure that the library either supports the exact interface/device you have
or that it can be configured to support the exact interface/device  you have.

This is why just saying:
Quote
I purchased an I2C display from eBay
Is not enough.
From just the information, there is no way for anyone to know what you have
or what s/w you would need to make it work.

Also adding to the confusion, is that there are many different LCD libraries out there
and several have the same name.
So even naming the library you are using isn't enough information to know
which library you have.


--- bill
13  Using Arduino / Displays / Re: Artifacts on CrystalFontz LCD Display on: April 14, 2014, 04:24:25 pm
Sounds like it is all working now.

Just a bit of followup on the chip selects being "backwards".
In reality they are not backwards but rather a misconfiguration between
your glcd and the default ks0108 panel configuration file.
The data sheet that you have shows the chip select pins being active low.
Most 128x64 ks0108 modules use active high chip selects.

The default 128x64 ks0108 panel file uses active high logic for the chip selects.
You can see this by looking at the ks0108 panel file or at the diag output.
In the diag output note these lines:
Code:
CSEL1:35(PIN_C2) CSEL2:36(PIN_C1)
ChipSelects: CHIP0:(35,0x1, 36,0x0) CHIP1:(35,0x0, 36,0x1)

That shows that CS1 is connected to Arduino pin 35 and CS2 is Arduino pin 36
and that to address chip0 you set CS1 high and CS2 low
and to address chip 1 you set CS1 low and CS2 high.

The datasheet shows CS1 (glcd pin 12) and CS2 (glcd pin 13) as active low.
This doesn't match the default ks0108 configuration.
While technically to fix it, the ks0108 panel config file would have to
be modified, when you only have two chips and two chipselect lines
you can also make it work by just flipping the wires to the glcd CS1 and CS2 pins.

Switching the chip select wires in many cases is easier than editing the panel config file,
but in reality the chip selects weren't backwards, it was that the ks0108 panel config file
chip select definitions file didn't agree with the glcd module.

Another thing to consider is that if you want the maximum speed, the data line
Arduino pins need to be selected carefully. If you select them such that the bits in the AVR port
align with the data bits i.e. bit 0 is bit 0 of the AVR port, ... up to bit 7, then the library
will use nibble or byte mode which is faster than using bit i/o on all the individual bits.
byte mode if all 7 align and are in the same AVR port
and nibble mode if only the upper or lower 4 bits align or if all 8 bits are not in the same AVR port.


--- bill

14  Using Arduino / Displays / Re: Artifacts on CrystalFontz LCD Display on: April 12, 2014, 02:24:23 pm
It is difficult to tell what is happening.
I have seen this kind of behavior before, and usually it is due to broken wires, wires making poor contact,
or incorrectly connected wires.
It appears that something is strange on data bits 2 and 4 so I'd look closely at those wires.

Can you post a connection table of how each of the Arduino pins is connected to the GLCD,
just so I can verify them?
15  Products / Arduino Due / Re: Due compatible Time library? on: April 10, 2014, 11:42:59 am
Paul,
Simple solution is don't use Due but rather Teensy 3.x instead.  smiley-wink

Here is an option that I think is pretty good that is about the best that can be done
without the major headache of actually changing the object name or requiring the user
to declare the object.

Add this to the top of the DS1307RTC.h header file
just after the guard conditionals so it looks something like this:

Code:
#ifndef DS1307RTC_h
#define DS1307RTC_h

// ensure that Wire library header has already been included
#if !defined(TwoWire_h) && !defined(TinyWireM_h)
#error The Wire library header must be included before DS1307RTC.h
#endif


I think that this will catch the guard defines used by the AVR,  Teensy, chipkit/pic32,  Due and Tiny i2c libraries.
(Why the Tiny library deviated so much is beyond me....)
It is a bit ugly but at least it will ensure that the Wire library header is always included ahead
of DS1307RTC.h so the RTC define can always be undefined.

I'm not sure what happens if somebody actually tries to use the RTC on SAM
but I'm assuming that it isn't an issue in that users will more than likely
not be trying to use the built in RTC when they are using the DS1307RTC library.

Even with this, there still may be other libraries that end up including the sam header
that if the users sketch uses, might create the problem again.
However, I think for the time being, and the effort involved, this kludge/patch
is pretty useful.

Also, could you update the example program on the DS1307RTC page
so that Wire.h is included before DS1307RTC.h
That way the example will compile properly.

--- bill


Pages: [1] 2 3 ... 156