Show Posts
Pages: 1 2 [3] 4 5 ... 100
31  Using Arduino / Programming Questions / Re: Menu for Display on: August 09, 2014, 05:06:33 am
I think, using a button callback (like you did) is the prefered way to jump back to the other mode. This looks already good. You might check also direktly in the event source for "1", assign root and change mode. I have not tested this, but maybe you can also jump back then.

Oliver
32  Using Arduino / Displays / Re: YL24064-27 Graphic Display, need help at wireing on: August 09, 2014, 04:45:15 am
Have a look here: http://www.newhavendisplay.com/specs/NHD-24064CZ-FSW-GBW.pdf
Your vee pin: I think is an output (although marked as input on your datasheet, but i found newhaven displays description more trustable). You can do this: Apply 5V to your display and measure voltage at your vee pin. If it is -10 V you do not need to apply extra -10V, because it is produced on board. You can then use the vee pin as source for pin 4. However you need a resistor devider or adjustable resistor to obtain the voltage for pin 4.
Pin 4 is used to adjust contrast and must receive a voltage between -5 and -10V (see the newhaven doc).
If there is no voltage on vee, then you need an external -10 source to get the voltage for pin 4 (v0)

Oliver
33  Using Arduino / Displays / Re: YL24064-27 Graphic Display, need help at wireing on: August 08, 2014, 05:17:43 pm
reset = pin 10

The display might require -10 V (not clear from the datasheet)

How did you connect pin 4?

Oliver
34  Using Arduino / Displays / Re: YL24064-27 Graphic Display, need help at wireing on: August 08, 2014, 02:35:32 pm
Hi

This is a T6963 display as mentioned in the datasheet. u8glib might work.

Oliver
35  Using Arduino / Programming Questions / Re: Menu for Display on: August 07, 2014, 02:27:27 pm
Hi gnux

I see at least two problems.
First is, that the event source is not complete:
Code:
uint8_t m2_es_gnusso(m2_p ep, uint8_t msg)
{
  if ( keypad_is_used_for_menu != 0 )
   // Tasto(that means key) maybe is not correct my fault is use when I call ReadKeypad
  else
   // Tasto(that means key) maybe is not correct my fault is use when I call ReadKeypad
  switch(msg)
  {
    case M2_ES_MSG_GET_KEY:
      if (Tasto == '5'  )
        return  M2_KEY_EVENT(M2_KEY_SELECT);
      if (Tasto == '6') 
        return  M2_KEY_EVENT(M2_KEY_NEXT);
      return M2_KEY_NONE;
    }
   return 0;
}
I thinkt the logic is inverted and some { and } are missing.
Quote
Code:
uint8_t m2_es_gnusso(m2_p ep, uint8_t msg)
{
  if ( keypad_is_used_for_menu == 0 )  // this should be a check for equal, i think!!!
  {
    // do nothing
  }
  else
  {
   // Tasto(that means key) maybe is not correct my fault is use when I call ReadKeypad
  switch(msg)
  {
    case M2_ES_MSG_GET_KEY:
      if (Tasto == '5'  )
        return  M2_KEY_EVENT(M2_KEY_SELECT);
      if (Tasto == '6') 
        return  M2_KEY_EVENT(M2_KEY_NEXT);
      return M2_KEY_NONE;
    }
   }
   return 0;
}

Second problem is, that keypad_is_used_for_menu is never changed. If you detect "*", you probably want to set keypad_is_used_for_menu to 1. And if you did finished your menu, you may want to set keypad_is_used_for_menu to 0.

Oliver
36  Using Arduino / Networking, Protocols, and Devices / Re: I2C and USB conflict on Atmega32u4 with Leonardo bootloader on: August 07, 2014, 01:50:42 pm
hmmm... then i also have no other idea.

Oliver
37  Using Arduino / Networking, Protocols, and Devices / Re: I2C and USB conflict on Atmega32u4 with Leonardo bootloader on: August 07, 2014, 05:40:41 am
Hi

Are there pull-up resistors on the I2C bus?
It might be worth to try to add pull-ups (4.7K Ohm) and check whether this will improve the situation.

Oliver
38  Using Arduino / Programming Questions / Re: Menu for Display on: August 06, 2014, 11:54:08 pm
Hi

I think, your "m2_es_gnusso" looks almost korrekt, but should return NONE if no key is pressed. Will the menu work with this?

Code:
uint8_t m2_es_gnusso(m2_p ep, uint8_t msg)
{
  Tasto = customKeypad.getKey(); // is necessary call getKey() here ?
  switch(msg)
  {
    case M2_ES_MSG_GET_KEY:
      if (Tasto == '4')
        return  M2_KEY_EVENT(M2_KEY_PREV);
      if (Tasto == '5'  )
        return  M2_KEY_EVENT(M2_KEY_SELECT);
      if (Tasto == '6') 
        return  M2_KEY_EVENT(M2_KEY_NEXT);
      return M2_KEY_NONE;
    }
   return 0;
}
In order to switch between two different "phases", you may need to extend "m2_es_gnusso":
1. Introduce a new flag, that indicates whether you are in the menu or not
2. Check this flag inside "m2_es_gnusso"
for example:

Code:
int keypad_is_used_for_menu = 1;

uint8_t m2_es_gnusso(m2_p ep, uint8_t msg)
{
  if ( keypad_is_used_for_menu != 0 )
    Tasto = customKeypad.getKey();
  else
    Tasto = 0;
  switch(msg)
  {
    case M2_ES_MSG_GET_KEY:
      if (Tasto == '4')
        return  M2_KEY_EVENT(M2_KEY_PREV);
      if (Tasto == '5'  )
        return  M2_KEY_EVENT(M2_KEY_SELECT);
      if (Tasto == '6') 
        return  M2_KEY_EVENT(M2_KEY_NEXT);
      return M2_KEY_NONE;
    }
   return 0;
}


Now you can turn the flag keypad_is_used_for_menu on and off in order to switch between menu input and other input.

Oliver
39  Using Arduino / Displays / Re: OLED 1.3" I2C IIC 128x64 Serial LCD - Faulty? on: August 06, 2014, 12:41:55 pm
Hi All

Of course pull up resistors are mandatory for I2C, however it is not clear whether they are included on the OLED module or not. Yet, your pictures did prove, that you are able to transfer some usefull data to your OLED. So, pullups are not required in your specific case. This also aligns with my own experience, that such kind of OLED modules often do not need pullup resistors.

Still my suggestion is to give a try to u8glib with the setup of your picture. All the example sketches include the constructors, and checking the options will be as simple as uncommenting exactly one of the constructors in the examples of U8glib.

The "GraphicsTest" example looks like this in line 89:
Code:
//U8GLIB_SSD1306_128X64 u8g(13, 11, 10, 9); // SW SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9
//U8GLIB_SSD1306_128X64 u8g(4, 5, 6, 7); // SW SPI Com: SCK = 4, MOSI = 5, CS = 6, A0 = 7 (new white HalTec OLED)
//U8GLIB_SSD1306_128X64 u8g(10, 9); // HW SPI Com: CS = 10, A0 = 9 (Hardware Pins are  SCK = 13 and MOSI = 11)
//U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NONE); // I2C / TWI
//U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NO_ACK); // Display which does not send ACK
//U8GLIB_SSD1306_ADAFRUIT_128X64 u8g(13, 11, 10, 9); // SW SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9
//U8GLIB_SSD1306_ADAFRUIT_128X64 u8g(10, 9); // HW SPI Com: CS = 10, A0 = 9 (Hardware Pins are  SCK = 13 and MOSI = 11)
//U8GLIB_SSD1306_128X32 u8g(13, 11, 10, 9); // SW SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9
//U8GLIB_SSD1306_128X32 u8g(10, 9);             // HW SPI Com: CS = 10, A0 = 9 (Hardware Pins are  SCK = 13 and MOSI = 11)
//U8GLIB_SSD1306_128X32 u8g(U8G_I2C_OPT_NONE); // I2C / TWI
//U8GLIB_SH1106_128X64 u8g(13, 11, 10, 9); // SW SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9
//U8GLIB_SH1106_128X64 u8g(4, 5, 6, 7); // SW SPI Com: SCK = 4, MOSI = 5, CS = 6, A0 = 7 (new blue HalTec OLED)
//U8GLIB_SH1106_128X64 u8g(U8G_I2C_OPT_NONE); // I2C / TWI
//U8GLIB_SH1106_128X64 u8g(U8G_I2C_OPT_NO_ACK); // Display which does not send ACK

Uncomment this line:
Code:
//U8GLIB_SH1106_128X64 u8g(U8G_I2C_OPT_NONE); // I2C / TWI
Compile and upload the example. Will this work? I am very confident it will.

The problem here is not the Adafruit and not the OLED Display. It is the combination of both. I can not promise, that u8glib will work, but i did work together with a lot arduino users and i received a lot of feedback about successful installations.

Moreover, i sometimes order "strange" OLEDs from far east, just to make it work with U8glib. Of course you do not need to use u8glib (it might appear to be strange by itself), but at least you would know the exact controller type: SSD1306 or SH1106. Please also note, that the displays often are offered as SSD1306, although they contain a SH1106.

Oliver



40  Using Arduino / Displays / Re: OLED 1.3" I2C IIC 128x64 Serial LCD - Faulty? on: August 06, 2014, 12:17:21 am
Hi

I have discussed this kind of display on my gallery page (4th pic from top): https://code.google.com/p/u8glib/wiki/gallery. At least my own OLED does not require pull up resistors and it works with 5V:

Also note, that this display might be invisible to the I2C scanner, because it might not send the ACK response.

My suggestion is, with your setup from your first post, try U8glib with the constructors
Code:
U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NO_ACK); 
or
Code:
U8GLIB_SH1106_128X64 u8g(U8G_I2C_OPT_NO_ACK);

or
Code:
U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NONE); 
or
Code:
U8GLIB_SH1106_128X64 u8g(U8G_I2C_OPT_NONE);


Oliver

41  Using Arduino / Displays / Re: OLED 1.3" I2C IIC 128x64 Serial LCD - Faulty? on: August 05, 2014, 09:13:49 am
Hi

Not sure what you mean by IDAFRUIT, i assume you use the Adafruit Software.

So, i would say this: If your display is NOT a original Adafruit OLED display, then there is a good chance, that your display does not contain the SSD1306 controller (which is the one in the Adafruit display) but instead contains a SH1106 controller, which also is used for 128x64 displays. Any OLED with the SH1106 controller is NOT supported by Adafruit.

All in all, your pictures (partly visible correct bitmap) indicate such a problem.

You may want to use u8glib instead, which has support for both types of 128x64 OLED displays: With SSD1306 or with SH1106 controller.

Oliver
42  Using Arduino / Displays / Re: Noob Moving From LCD to More Sophisticated Display? on: August 03, 2014, 01:49:09 pm
Maybe look at the white shields from elecfreak:
http://www.elecfreaks.com/store/lcd-tft-c-30_33.html

The white 1.8TFT shield from elecfreak uses a ST7735 controller, which is compatible with the Arduino TFT. I am 99% sure that you can use the Arduino TFT library. If this does not work, UTFT and ucglib should also work.
The shield should be also compatible with Uno, Mega and Due. So you could start with your existing hardware.  It seems they also have a good documentation.

Only problem: It does not contain a touch panel.

I personally have used the TFT2.2 shield without problems: Bottom of page https://code.google.com/p/ucglib/wiki/connectili9341.

Oliver

Oliver
43  Using Arduino / Displays / Re: u8glib with 12864 SPI Display + ultrasonic + motor control - huge delays on: August 03, 2014, 02:52:11 am
Hi Norman

I removed some delays and also placed the call to "distance()" at a different positition. Maybe some more delays can be removed.

See my comments in the fixed code (not tested):

Code:
void distance() {
 
  front_distance_av = sonar_01.ping_median(3);
  front_distance = sonar_01.convert_cm(front_distance_av);
  front_left1_distance_av = sonar_02.ping_median(3);
  front_left1_distance = sonar_02.convert_cm(front_left1_distance_av);
  front_left2_distance_av = sonar_03.ping_median(3);
  front_left2_distance = sonar_03.convert_cm(front_left2_distance_av);
  front_right1_distance_av = sonar_04.ping_median(3);
  front_right1_distance = sonar_04.convert_cm(front_right1_distance_av);
  front_right2_distance_av = sonar_05.ping_median(3);
  front_right2_distance = sonar_05.convert_cm(front_right2_distance_av);
  delay(200); // maybe this can be removed
 
}


void draw() {
  // instead of calling distance() here, do this call in "loop()"
  // distance();
 
  u8g.setFont(u8g_font_5x8);
 
  u8g.drawStr( 0, 10, "FL2: ");
  u8g.setPrintPos(30, 10);
  u8g.print(front_left2_distance);
 
  u8g.drawStr( 0, 20, "FL1: ");
  u8g.setPrintPos(30, 20);
  u8g.print(front_left1_distance);

  u8g.drawStr( 0, 30, "F: ");
  u8g.setPrintPos(30,30);
  u8g.print(front_distance);
 
  u8g.drawStr( 0, 40, "FR1: ");
  u8g.setPrintPos(30, 40);
  u8g.print(front_right1_distance);
 
  u8g.drawStr( 0, 50, "FR2: ");
  u8g.setPrintPos(30, 50);
  u8g.print(front_right2_distance);
 
  u8g.drawLine(50, 1, 50, 60);
 
  // the delay does not make sense here, removed
  // delay(500);
}


void loop(void) {

  idleMotor_a();
 
   //  433Mhz Remote)
    uint8_t buf[VW_MAX_MESSAGE_LEN];
    uint8_t buflen = VW_MAX_MESSAGE_LEN;
    if (vw_get_message(buf, &buflen)) // Non-blocking
    {
      int i;
      for (i = 0; i < buflen; i++)
      {
        if(buf[i]=='1')
        {
          lcd_int = 1;
          forward_a();
        }
       
        if(buf[i]=='2')
        {
          backward_a();
        }
       
        if(buf[i]=='3')
        {
          leftTurn_a(); 
        }
       
        if(buf[i]=='4')
        {
          rightTurn_a();     
        }
       
        if(buf[i]=='5')
        {
          idleMotor_a();
        }
    }}
   
  // distance should be called outside the "picture loop"
  distance();
   
  u8g.firstPage(); 
  do {
    draw();
  } while( u8g.nextPage() );
  delay(200);
}

void forward_a()
{
  digitalWrite(PoM1b, LOW);
  analogWrite(PoM1a, 120);
  digitalWrite(PoM2b, LOW);
  analogWrite(PoM2a, 120);
  delay(200);
}

Oliver
44  Using Arduino / Displays / Re: Ucglib: A new Color OLED and TFT Library... on: July 31, 2014, 01:52:51 pm
Great. Excellent error description. I will create an issue for this.
Meanwhile, UCG_FONT_MODE_TRANSPARENT could be used as a workaround.

K+

Oliver
45  Using Arduino / Displays / Re: Reducing the size of u8glib on: July 29, 2014, 03:25:21 am
Which fonts did you select? Maybe select a font with an "r" postfix, if codes above 127 are not required.
On the wiki pages, for each font, the size in bytes is also mentioned. Based on this, you can predict and optimize the code size.

Oliver
Pages: 1 2 [3] 4 5 ... 100