Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 102
61  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
62  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
63  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
64  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



65  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

66  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
67  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
68  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
69  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
70  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
71  Using Arduino / Displays / Re: U8glib: Graphics Lib for LCDs and OLEDs on: July 29, 2014, 03:21:12 am
Yes, the listing file would be nice to see.
Depending on the fonts U8glib requires about 10K. If you do not need ASCII chars with code higher than 127, then fonts with a "r" postfix can be used to reduce flash memory.
Also other libraries and the use of floating point are common reasons for increased memory usage.

Oliver
72  Using Arduino / Displays / Re: Req: Display two pages of data alternately using U8glib on: July 29, 2014, 03:15:11 am
Hi Dave

First you need to group your procedures according to what needs to be displayed on one page.
For the first page, this seems to be:
draw(0);
draw(1);
draw(2);

I personally suggest to introduce a procedure for this (to simplify the code):
Code:
void draw_page_1(void)
{
draw(0);
draw(1);
draw(2);
}
Of course you could still use the param loop.
Same should be done for draw_page_2()

Second, the delay and the different pages must be selected/switched outside the picture loop.
This might look like this:

Code:
  u8g.firstPage();   
  do {
   draw_page_1();
  }
  while( u8g.nextPage() );//end of picture loop
  delay(1000);
  u8g.firstPage();   
  do {
   draw_page_2();
  }
  while( u8g.nextPage() );//end of picture loop

Oliver

73  Using Arduino / Displays / Re: U8glib refreshing delay, communicating trough xbee on: July 26, 2014, 02:13:40 pm
Hi

1. Only do graphics output in the draw() procedure (body of the picture loop)
More specific: Do not call unpack() inside the loop body, instead call "unpack" in loop itself:

Code:
void loop(void) { 
  unpack();
  u8g.firstPage(); 
  do {
    draw();
  } while( u8g.nextPage() );
    delay(150);  // maybe this can be removed or the value can be reduced
}
I guess this will also solve your second problem.

2. Display graphics, then your numbers
The keyword is "state machine". You must introduce a state variable, e.g.:
Code:
uint8_t dispaly_state = 0;
Then define, what should be shown for which number. Let me define this:
0 = display graphics
1 = display normal content

Then, your main loop will look like this:
Code:
uint8_t dispaly_state = 0;

void loop(void) { 
  unpack();
  u8g.firstPage(); 
  do {
    if ( display_state == 0 )
      draw_graphics();   // show graphics here
   else
      draw();
  } while( u8g.nextPage() );
    delay(150);
}
Now, because display_state is set to 0 at startup, this will always show your graphics, but will never call draw(). But this is easy, we just need to assign 1 to display_state. As requested, this could be done after 5 seconds:

Code:
uint8_t dispaly_state = 0;

void loop(void) { 
  unpack();
  u8g.firstPage(); 
  do {
    if ( display_state == 0 )
      draw_graphics();   // show graphics here
   else
      draw();
  } while( u8g.nextPage() );

  if ( display_state == 0 && millis() > 5000 )
    display_state = 1;

  delay(150);
}

Oliver

74  Using Arduino / Displays / Re: ST7920 Dot Matrix LCD Screen has shadows/artifacts. on: July 24, 2014, 04:34:33 pm
If this picture was created by the sketch with the endless for loop, then i would also thinkt, that this is a hardware issue with the display.

Oliver
75  Using Arduino / Displays / Re: ST7920 Dot Matrix LCD Screen has shadows/artifacts. on: July 24, 2014, 02:06:51 pm
I have seen a lot of timing problems with the ST7920, but they usually look differently.
Is there some flicker, or is it constantly looking like this?

Can you modify the HelloWorld example, where you enter an infinit loop after the first picture loop:

Code:
void loop(void) {
  // picture loop
  u8g.firstPage(); 
  do {
    draw();
  } while( u8g.nextPage() );
 
  for(;;)
    ;
}

How  will it look like?

Oliver
Pages: 1 ... 3 4 [5] 6 7 ... 102