Show Posts
Pages: [1] 2 3 ... 22
1  Community / Website and Forum / Re: leonardo documentation on: June 09, 2012, 09:39:58 am
Look at the picture at http://arduino.cc/en/Main/ArduinoBoardLeonardo. To the left of AREF at the top left corner are pins labeled SDA and SCL but without digital numbers. Now look at http://arduino.cc/en/Hacking/PinMapping32u4 again. That would say that SDA and SCL are mapped to Digital 2 and 3. Are those 2 pairs of headers pins actually just connected together? That seems to be what the documentation says.

The schematic at http://arduino.cc/en/uploads/Main/arduino-leonardo-schematic_3b.pdf seems to show both sets of header pins connected to the same signals. This surprises me and suggests unique ways to short things out. Am I misunderstanding?
2  Community / Website and Forum / leonardo documentation on: May 28, 2012, 12:48:47 pm
Now that the Leonardo is out, I thought I would start to look at  modifying the digitalWriteFast library to cover the new board. I ordered a board and it hasn't come yet, so I'm trying to sort out how it works from looking at /Applications/Arduino.app/Contents/Resources/Java/hardware/arduino/variants/leonardo/pins_arduino.h

and the website.  At http://arduino.cc/en/Hacking/PinMapping32u4 there is clearly an error:

Quote
29   (PCINT5/OC1A/#OC4B/ADC12) PB5   Digital Pin 9 (PWM)
30   (PCINT6/OC1B/OC4B/ADC13) PB6   Digital Pin 9 (PWM)

PB5 and PB6 are not both Digital Pin 9. From pins_arduino.h  it looks like the second one should be digital pin 10.
3  Community / Bar Sport / Re: Why are high power LEDs hot? on: February 08, 2012, 05:39:36 pm
Thanks for the insight. I think I understand better now.

Bill gave me more insight into what a strange measure 'lumen' is than I had any idea about!

It seems like a bunch of the available (white) devices produce about 60 lumens / watt while 100-105 lumens /watt  is mentioned some places (more as coming soon than available now). That certainly implies more of the energy going to heat (in currently available devices)  than I thought at first. It also suggests that future LEDs might be cooler and brighter. My impression from some of the graphs I've looked at is that overall efficiency of converting power into light is not much different for fluorescents and LEDs. I guess that might make some sense since conceptually similar quantum phenomena are used to produce photons from electric energy and then a phosphor to shift the spectrum to a more pleasing one. The fluorescent devices are physically larger and don't seem to have the heat dissipation issue because they don't concentrate the energy all in a tiny space.
4  Community / Bar Sport / Why are high power LEDs hot? on: February 04, 2012, 05:58:47 am
As recently as a year ago I bought a light for scuba diving that was HID, about 700 lumens. I have a similar HID light for riding my bike at night. Neither are viable products today since LED lights that produce 600-800 lumens are a little cheaper and are instant on, rather than taking a couple of minutes for the gas to reach its optimum temperature.

LED lights to replace incandescent or fluorescent bulbs in the home devote most of their weight and bulk to heat dissipation. UK dive lights have a little heat fin on the front of the lens http://www.uwkinetics.com/technology/lights-technology/lumen-booster  which keeps the temperature of the LED close to the temperature of the surrounding water and improves the efficiency of the LED itself by avoiding heating.

When I read the wikipedia article on LEDs, I learn about 2 issues. The one I disregard is that "white" high power LEDs are blue LEDs with a yellow phosphor. I don't think the yellow phosphor is the source of heat, since it seems more or less equivalent to the coating on the inside of a fluorescent tube's glass and those are cool. The main issue is that the epoxy coating the LED has a high refractive index ( >4 ) and so light that hits it at any angle much different from 90 degrees is reflected internally. The edges  of the LEDs are at right angles so that the reflected light bounces around inside forever or until it becomes heat.

But if the epoxy coating were spherical all of the light would be at a right angle to the surface on the first try. And if the epoxy coating were something like the dome shape we are all familiar with from low power through-hole LEDs, the light would all get out on the first few bounces. And then the LED would not get hot, the heat sink would not be needed?

Obviously smart people at Cree etc have thought of all this. What is it that I don't understand?
5  Using Arduino / Displays / Re: New LiquidCrystal library - LCD library on: November 19, 2011, 06:55:34 am
When I worked on LiquidCrystal I found an LCD that was significantly slower and increased delays to accommodate that. I bought another one just like it out of the same bin at our local Axman store and it had the same timing issues. As I said before, checking the busy flag increases reliability of communication between the display and the Arduino MCU as well as speeding it up. It does not seem reasonable to expect the user to fine tune the various delays. Producing code that worked with 'most' displays was not my goal, and I doubt it is your goal.

I will happily mail you one of the slow displays if you want to try to make your code work reliably with them. PM me if you would like that.

Even one of the displays I bought from Adafruit needed an increase in one of the delays from what was in the initialization code of the standard LiquidCrystal routine. As Don pointed out, increasing the delays at initialization has almost no penalty--it just runs as the code starts up.
6  Using Arduino / Displays / Re: New LiquidCrystal library on: November 10, 2011, 08:38:06 am
I realized as I was bicycling to work that the code base you started from has a long delay between nibbles when it uses the 4 bit mode. Don Weiman (floresta) pointed out that that is unnecessary. 1 usec is adequate there. I don't have your code here but that change is worth 30-40% improvement in speed with the 4 bit mode, if I recall.
7  Using Arduino / Displays / Re: I2C LCD garbles text on: November 10, 2011, 06:08:01 am
I'd have a look at
http://www.arduino.cc/playground/Code/AvailableMemory

you might need to switch to a mega or teensy++ etc.
8  Using Arduino / Displays / Re: New LiquidCrystal library on: November 10, 2011, 06:05:07 am
part of the advantage of testing the busy flag is reliability. When I've worked on displays that weren't able to keep up with the fixed delays in the standard LIquidCrystal, it became clear that waiting for the busy flag greatly increased the reliability--once you get initialization right (initialization can't use the busy flag). I still puzzle over how much faster the code runs with the busy flag testing than I can make it run without that; I can't just try to slowly reduce the delays until it doesn't run and come anywhere close to the speed of testing the busy flag. Here's a quote from the thread I pointed to before:

Quote
Speed testing
All of the interface modes go faster than the eye can follow.  This version of the software is significantly slower than previous versions when using timed delays. I found an LCD (Axman) that needed longer delays and in the interests of making the code foolproof, I lengthened the delays to make that LCD work. However Paul Stoffregen has significantly speeded up the code when testing the busy flag and so those options run significantly faster than before. I compared the speeds of the different interfaces--writing 80 characters to the screen then 80 blanks and looping through that 20 times. The results  on a Mega are:
Axman 4 data pins no RW 1349 milliseconds  |  nonAxman 1349
Axman 4 data pins  + RW  565 milliseconds  |  nonAxman  468
Axman 8 data pins no RW 1314 milliseconds  |  nonAxman 1314
Axman 8 data pins  + RW  520 milliseconds  |  nonAxman  500
Axman 4 pins + user busy 369 milliseconds  |  nonAxman  316

I also have a Teensy++2.0 board. One of the interesting things about that board is that the software that comes with it includes considerable optimization of digitalRead, digitalWrite etc. The board runs at 16 megaHz, just like the Mega, but speeding up those commands results in an impressive change in the benchmarks:
Axman 4 data pins no RW 1207 milliseconds  |  nonAxman 1207
Axman 4 data pins  + RW  327 milliseconds  |  nonAxman  219
Axman 8 data pins no RW 1212 milliseconds  |  nonAxman 1212
Axman 8 data pins  + RW  361 milliseconds  |  nonAxman  296
Axman 4 pins + user busy 241 milliseconds  |  nonAxman  189
9  Using Arduino / Displays / Re: New LiquidCrystal library on: November 09, 2011, 08:23:52 pm
nice work!

I have only quickly looked at the code. The standard LiquidCrystal initializes the display when you declare the LiquidCrystal object; you can dispense with the begin() statement if you have the size display it assumes. I don't see that in your code.

When Paul Stoffregen was helping me with optimizing the LiquidCrystal440 line of this we eventually eliminated the 8 bit mode internally (we kept the API but ignored 4 of the pins). We did that because when we were testing the LCD's busy flag, we needed to set pinMode on all the data pins twice. So the fastest modes of writing to the display (using the busy flag) were 4 bit rather than 8 bit. The 8 bit mode is a little faster if you don't check the busy flag, but it isn't a big difference. see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1264823411

10  Using Arduino / Displays / Re: 40x4 + LiquidCrystal440 missing character on: November 09, 2011, 06:37:34 pm
I only have one of these displays but every version of the software I have posted has been run through test code that puts characters in all 4 corners at several points in the code. I test that in because I wanted to demonstrate/test that I had fixed the way the standard liquidCrystal behaves if you scroll the display and then setCursor. It puts characters in all 4 corners before scrolling a random number of times and then again after scrolling. It does ithis for both left and right scrolling directions.

Certainly the software has been thoroughly tested at all 4 corners of each of the sizes of display I have (40,4; 20,4; 16,4;16,2) except the 16,1 = 8,2. My test program overwrites some of the 'corners' that would be in the middle of the screen before it pauses to give me a look in the corner tests for that goofy display and I never bothered to fix the test code to handle that case better.

If Don thinks it may be a defect in your display, I would tend to agree.
11  Using Arduino / Programming Questions / Re: portOutputRegister() on: October 19, 2011, 08:27:42 pm
Thanks, Paul.

 I would have thought there must be a unix tool of some sort on the Mac to do the job. It occurred to me (finally) that all those smart unix guys must have gotten fed up with hunting through dozens of haystacks looking for which one had the needle.


12  Using Arduino / Programming Questions / portOutputRegister() on: October 19, 2011, 05:30:48 am
I have a color LCD breakout board from Adafruit and I am trying to get it working on a Teensy2++. It works fine on a Mega and I moved the 8 data pins to the interior pins on the Teensy2++ which should keep the port the same. It has power but nothing is appearing on the screen. I put the control lines that were on A0-A3 on the Mega onto the Teensy2++'s A0-A3 lines.

I started looking at how the driver code accesses the control lines. An example:
Code:
void TFTLCD::writeData(uint16_t data) {
  volatile uint8_t *wrportreg = portOutputRegister(wrport);

  *portOutputRegister(csport) &= ~cspin;
  //digitalWrite(_cs, LOW);
  *portOutputRegister(cdport) |= cdpin;
  //digitalWrite(_cd, HIGH);
  *portOutputRegister(rdport) |= rdpin;
  //digitalWrite(_rd, HIGH);
 
  *wrportreg |=  wrpin;
  //digitalWrite(_wr, HIGH);

  setWriteDir();
  write8(data >> 8);
 
  *wrportreg &= ~wrpin;
  //digitalWrite(_wr, LOW);
  *wrportreg |=  wrpin;
  //digitalWrite(_wr, HIGH);

  write8(data);

  *wrportreg &= ~wrpin;
  //digitalWrite(_wr, LOW);
  *wrportreg |=  wrpin;
  //digitalWrite(_wr, HIGH);

  *portOutputRegister(csport) |= cspin;
  //digitalWrite(_cs, HIGH);
}

The commented out code is a good way to figure out what the code means but I don't think I have seen portOutputRegister() before and haven't been able to find it when I poke around in various source files. I'm using Xcode 3.2.6 as my editor for the driver file so I get a nice popup list of defined symbols (maybe not as nice as if they were alphabetized).

So 2 questions: where is portOutputRegister defined and more importantly is there a better technique for finding a symbol that is defined in some included file rather than just opening and examining each included file? Seems like this general problem must have been solved with some neat tool that I don't know about. Maybe a 3rd question: what should I have read or googled to get the answer to the 2nd question?
13  Using Arduino / Displays / Re: 1602 LCD Dispaly dont work on: October 08, 2011, 05:40:10 am
I have trouble following all the wires and am never as good at that as Don and John, but it looks to me like the blue wires from Arduino pins 11 and 12 go to DATA pins, not RS and EN control pins--ie in this line
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
the 5 and 3 should be 12 and 11. That makes me think the rest of them are probably also goofy.
14  Using Arduino / Programming Questions / Re: Programming the Arduino mega on: October 05, 2011, 08:28:45 pm
the usb port powers and programs the mega and supports serial communication between the host and the mega when a sketch is running
15  Using Arduino / Displays / Re: Need help with my LCD after running a function on: October 02, 2011, 07:57:36 am
Thinking about this kind of bug a little more, it seems to me that the way stackable headers bring all the pins forward for potential reuse is part of the issue. It might be good practice when one first gets a new shield and carefully reads the documentation to PLUG the used sockets in some way to remind one's later self. It should probably be a removable way, since as Don points out, if you are really careful you can reuse the pins.
Pages: [1] 2 3 ... 22