Announcement

Collapse
No announcement yet.

uLCD 32PT GPIO bug for SPI and 1 Wire

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • uLCD 32PT GPIO bug for SPI and 1 Wire

    Hi

    I made connexion with a digital barometer (SCP1000) by SPI. That consume 4 of GPio pins, but working fine.

    I want to use the last available pin to connect a 1-wire Dallas 18B20 digital thermometer.

    I notice that for pins IO2 to IO5, there is non problem to switch between output and input. but not for IO1.

    I use this code :

    Code:
    #platform "uLCD-32PT_GFX2"#constant DQ  IO1_PINfunc main()var x;while(1)if (x := !x)pin_Set(OUTPUT, DQ);pin_HI(DQ);elsepin_Set(OUTPUT, DQ);pin_LO(DQ);endifpin_Set(INPUT, DQ);print(x, "=", pin_Read(DQ), "\n" );wendendfunc
    If I use IO2_PIN, there is no problem, I read on the screen 1=1, 0=0, 1=1, 0=0, etc... and I see that on the pin 2 itself :



    But if I use IO1_PIN, like in the code example, I read on the screen 1=0, 0=0, 1=0, 0=0, etc... And I see the pin 1 itself :



    I use the extension board P1 EB. I try without and with pull up resistor on GND or 3.3v, no changes...

    Is it a bug, or a fault on my board (in addition of the powering fault) ?

    Thanks a lot,
    Pierre

  • #2


    I made an other test. In fact pin1 seems to have problem as output when an other pin is set to Input.

    I used this code :

    HTML Code:
    #platform "uLCD-32PT_GFX2"
    func main()
    var x;
    pin_Set(OUTPUT, IO1_PIN);
    pin_Set(OUTPUT, IO2_PIN);
    pin_Set(OUTPUT, IO3_PIN);
    pin_Set(OUTPUT, IO4_PIN);
    pin_Set(OUTPUT, IO5_PIN);
    
    pin_HI(IO1_PIN);    //square on pin 1 OK
    pin_LO(IO1_PIN);
    pin_HI(IO1_PIN);
    
    pin_HI(IO2_PIN);    //square on pin 2 OK
    pin_LO(IO2_PIN);
    pin_HI(IO2_PIN);
    
    pin_Set(INPUT, IO2_PIN);  //set pin2 as INPUT break pin 1 !
    
    pin_HI(IO1_PIN);    //square on pin 1 NOT OK
    pin_LO(IO1_PIN);
    pin_HI(IO1_PIN);
    
    pin_Set(OUTPUT, IO2_PIN);
    
    pin_HI(IO2_PIN);    //square on pin 2 OK
    pin_LO(IO2_PIN);
    pin_HI(IO2_PIN);
    pin_LO(IO2_PIN);
    pin_HI(IO2_PIN);
    
    pin_Set(INPUT, IO2_PIN);
    
    while(1)
    wend
    endfunc
    And obtain this odd behaviour:





    It is very annoying, due to that, I cannot use my SPI barometer plus the 1wire thermometer...

    Do you have any ideas ? Or I can say bye bye to my hobby whether station ?

    Thanks a lot for reading,

    Pierre

    Comment


    • #3


      I finally find a work around, not solving the problem. I redraw the schematic to use the pin 1 only as Input. (SDI )

      I have some suggestions.

      On the extension board P1EB, there is mentioned the pins SDCS, SDO, SDI, SCK, related to SPI com. But non available because the uLCD32PT do not propagate them to J1 and J2. SDCS is to select the SD card. We can imagine to use one of the GPIO to select an other SPI device, and use the same SDO, SDI, SCK pins. Like that, multiple SPI device connection is possible.

      I don't know, if it's possible with the sub-structure of Picaso to use the pins BUS0~7 also as independent I/O.

      Apparently, flexible connectivity is not the main aim of picaso (graphics facilities are times more elaborated). This subject seems not interested lot of people, but I can share the small piece of code I use to interface SPI barometer and 1-Wire thermometer.

      Comment


      • #4


        I am trying to use the module to make an automotive computer with functions of GPS position, GPS hour, hour with a I2C RTC circuit, interior and external temperatures (I2C) and datalogging of all that on SD card.
        I had already do that on my own PIC modules (www.d6tm.fr) but the tactile and color screen are funny to use. I confirm also that if graphic functions are enough complete (many a bugs appear when the timers are used), the painful management of I/O, very incomplete SPI buffer mode, I2C with bug and not float mode make this module difficult to exploit. It is very damage because if the language 4DGL were richer and more stable, these platforms would be superb.
        It is true of a sharing zone code would be very an good idea because we lose all much time.
        Regards,

        Thierry - Avignon - France

        Comment


        • #5


          Thank a lot bisnouk for the reply and sharing your experience !
          Have you manage to exploit an RTC circuit ? I think add a DS1307chip in order to log and display data according true time.
          Et bravo pour les produits sur d6tm.fr, belles réalisations !

          Comment


          • #6


            Thank's !
            Yes, in a D6t'M module based on PIC18F4620, i use a Dallas DS1340C I2C RTC. it's easy to use with the integrate 32K xtal.
            For the temperature, i usually use DS1721 or DS1731.
            But, it' easy to use when the I2C functions are ok,... with my µLCD, it never run...
            My english is bad and a bit poor... you're french is perfect, are you french or living in France ?
            Regards,

            Thierry - Avignon - France

            Comment


            • #7


              Yes I'm french, and don't worry, I think your english is time more better than mine.
              I'll keep this language to allow, we never know, a feed back from 4D.

              It's a shame you not had I2C working. I'll try and if I not success, I will be constraint to return also to my PIC 18F, and use the uLCD as a simple serial display...
              "Dommage", It was, I think, an elegant idea to have only this great screen connected to different sensors, log data to SD card in files, and visualize them...

              Anyway, merci beaucoup pour le retour !
              À bientôt

              Comment


              • #8


                If you want, we can exchange our ideas in french by direct mail (thierry-at-d6tm.fr) and write together feed back here. This forum is a bit calm.
                Regards,

                Thierry - Avignon - France

                Comment


                • #9


                  Gentlemen,
                  All the bugs we're aware of have been fixed in the r22 PmmC (due for release Monday 13th). Apologies the release took longer than anticipated but we wanted to make sure everything was tested and tested again before we released.
                  Merci pour votre patience...
                  Atilla

                  Comment


                  • #10


                    A follow up on that bug, the parameters to function pin_Set(direction, pin); were inadvertently transposed in PmmC r20. This has been fixed for r21.

                    a temporary workaround would be to transpose the parameters for pin_Set eg:

                    pin_Set(IO2_PIN, OUTPUT);
                    Regards,
                    Dave

                    Comment


                    • #11


                      Many thanks meldavia and Atilla for the reply, I'm very pleased to have a feed back.

                      I'm quiet sure to had uploaded the r21 pmmc version, but I did not realize that parameters of pin_Set could be inverted, that explain lot of things. Thanks a lot for the bug explanation !

                      Is it conceivable to add, like bisnouk suggested, a code sharing section in the forum ? (near the Anna's sandbox probably)

                      Is a section with, on going work or improvement for pmmc, list of bug found, explained and possible work around, exist ?

                      Of course I can easily imagine the work load represented by managing a forum in addition of the technical work on your products. I would like to thank you for the time taken to reply me, and the continuous work on those devices.

                      I'm patiently looking forward the r22

                      PS: bisnouk: I'll make a tiny web page with my project, I'll mail you when I put online.

                      Comment


                      • #12


                        My apologies, what I said above about r21 is incorrect. The problem exists in r20 and r21, r22 will have the correct behaviour.
                        Regards,
                        Dave

                        Comment


                        • #13


                          No problem meldavia

                          Comment


                          • #14


                            Thanks for all these replies, and thanks for the R22 release.
                            Regards,

                            Thierry - Avignon - France

                            Comment


                            • #15


                              @muth

                              I just came across this thread. I'm interested in using the spi which on the uLCD-32PT only goes to the Micro SD card.

                              I think it would be posssible to tap into those lines and run back to the expansion board. They do it on the uLCD-3202 board.

                              I'm going to try since I need the SPI interface in a project of mine and I don't want to use a PIC which is just more hardware to worry about.

                              Did you try yet?

                              Regards

                              Eric

                              Comment

                              Working...
                              X