[SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

Support for Arduino in combination with Air Manager and Air Player

Moderators: russ, Ralph

Message
Author
User avatar
jph
Posts: 2853
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#81 Post by jph »

Looking really nice, a good tool.
Are you getting the others from Ali ex ?
Joe
Joe. CISSP, MSc.

SimPassion
Posts: 5338
Joined: Thu Jul 27, 2017 12:22 am

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#82 Post by SimPassion »

jph wrote: Wed Dec 27, 2023 8:27 am Looking really nice, a good tool.
Are you getting the others from Ali ex ?
Joe
Not already purchased Joe, though this will be the way to go 👍

User avatar
jph
Posts: 2853
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#83 Post by jph »

SimPassion wrote: Wed Dec 27, 2023 1:57 pm
jph wrote: Wed Dec 27, 2023 8:27 am Looking really nice, a good tool.
Are you getting the others from Ali ex ?
Joe
Not already purchased Joe, though this will be the way to go 👍
What are you using at the moment for the ICD Gilles ?
Also, could you please post an image of the breakout board you are using ? - I have some somewhere, but that looks a rather nice unit. :)
Joe
Joe. CISSP, MSc.

SimPassion
Posts: 5338
Joined: Thu Jul 27, 2017 12:22 am

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#84 Post by SimPassion »

Hi Joe, not already gone ICD for the Pico, I get interested in, while watching the OPENOCD link around RP-2040

Here's the Freenove breakout board :

image.png

https://www.amazon.fr/dp/B0BFB53Y2N
https://www.aliexpress.us/item/3256804522867433.html
https://www.ebay.co.uk/str/freenove/For ... 7159186010
https://www.ebay.com/str/freenove/For-R ... 7159186010
https://www.freenove.com/tutorial
Last edited by SimPassion on Thu Dec 28, 2023 5:44 pm, edited 1 time in total.

User avatar
jph
Posts: 2853
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#85 Post by jph »

Thank you Gilles, that is a rather nice board. I will order a couple as they are handy to have and indicative of the pin states.

Just a thought that may be of some use, the pinout is not 'exactly' the same as the chinese pico, specifically in the areas of 'EN' and 'VREF'
On the chinese boards VREF is actually a through hole on the pcb to the left of the 3V3 pin on the right hand side if you look at the board with the USB upwards.
It is not brought out to the pin marked VREF on the breakout board.
Please can you try the following ?
Measure the value of the VREF through hole in relationship to ground, either the gnd through hole above the VREF through hole, or, to any other ground - it makes little difference. There is the very slightest of possibilities that a resistor may be open circuit from 3V3 to VREF which may cause your issue. You should see around 3.3v on VREF through hole to GND,
If the voltage at VREF through hole is not 3.3V then the resistor is probably open circuit and we can get around that.
Joe
Joe. CISSP, MSc.

SimPassion
Posts: 5338
Joined: Thu Jul 27, 2017 12:22 am

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#86 Post by SimPassion »

Hi Joe, as suspected I get only 0V between VREF and GND and as seen on the picture, the VREF Pad isn't soldered. Even after being shortened, the Voltage doesn't changed from 0V.
So, thanks for your invaluable help Joe, though don't take more time on this issue, as it appears this board is really Out of Service.
I will pursue the work with next batch, no worries.
[EDIT] What I think is I don't care enough that much initially, on compatibility with the Freenove breakout board and it may really be this breakout layout isn't totally compatible with non Genuine Pico, as you've already suggested. This doesn't bother me though, as I will use it when Genuine Pico will arrive. It was a try and start again with a reliable one ...

image.png

SimPassion
Posts: 5338
Joined: Thu Jul 27, 2017 12:22 am

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#87 Post by SimPassion »

Luckily the WS2812B is still working, so this will be a board for RGB experiment
For testing purpose I've replaced the green triggering with white and the orange button trigger the OFF

image.png
image.png (10.68 KiB) Viewed 2355 times
image.png
image.png
image.png

SimPassion
Posts: 5338
Joined: Thu Jul 27, 2017 12:22 am

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#88 Post by SimPassion »

jph wrote: Mon Dec 25, 2023 10:33 am Hi Gilles, I was just looking through my code library and found an early test of dual cores with a pico !.

You can give your board a shakedown test with this. It runs one core flat out with a 16 x 16 MUX input unit and the other core just runs the basic 'blink' code so the output is the onboard led flashing at 1 second intervals and the serial port gives the number of cycles the 16 x 16 mux unit runs per second.
I used the same board as yours with generic rp2040 as the board and it works fine.

Just for fun to see two cores running at once with independent programs.
It shows a 16 x 16 bit input matrix (256 buttons) with only 10 pins used. 4067 mux ics are used - they are only a few cents each. I use this code as a performance test for picos.
This will probably give you about 1200 complete matrix inputs per second. On a 'normal' generic pico with the clock set at 240MHz it almost doubles !. incredible performance, and notice the second core just runs along happily without a care in the world doing the blink program :lol:

Code: Select all

/*
******************************************************************************************************
     Joe Hanley, 2022. 
     
     JPH on the fs forums. 
      
     Test of dual core on PICO
     
     1st run at 256 input 16 x 16 bit multiplexed matrix
     
     This code is free to use providing all credit is given to the author and sources.
******************************************************************************************************
*/
// includes
// defines

// constants
// our mux control pins for the 16:1 CD4067 mux/decoders
//const uint8_t CD4067_COL_S0 = 22;
//const uint8_t CD4067_COL_S1 = 24;
//const uint8_t CD4067_COL_S2 = 26;
//const uint8_t CD4067_COL_S3 = 28;
//const uint8_t CD4067_COL_IO = 30;
//const uint8_t CD4067_ROW_S0 = 32;
//const uint8_t CD4067_ROW_S1 = 34;
//const uint8_t CD4067_ROW_S2 = 36;
//const uint8_t CD4067_ROW_S3 = 38;
//const uint8_t CD4067_ROW_IO = 40;

const uint8_t CD4067_COL_S0 = 4;
const uint8_t CD4067_COL_S1 = 5;
const uint8_t CD4067_COL_S2 = 5;
const uint8_t CD4067_COL_S3 = 7;

const uint8_t CD4067_COL_IO = 8;

const uint8_t CD4067_ROW_S0 = 9;
const uint8_t CD4067_ROW_S1 = 10;
const uint8_t CD4067_ROW_S2 = 11;
const uint8_t CD4067_ROW_S3 = 12;

const uint8_t CD4067_ROW_IO = 13;


const uint8_t CD4067_TRUTH_TABLE[16][4] = {
  // s0, s1, s2, s3     channel
  {0,  0,  0,  0}, // 0
  {1,  0,  0,  0}, // 1
  {0,  1,  0,  0}, // 2
  {1,  1,  0,  0}, // 3
  {0,  0,  1,  0}, // 4
  {1,  0,  1,  0}, // 5
  {0,  1,  1,  0}, // 6
  {1,  1,  1,  0}, // 7
  {0,  0,  0,  1}, // 8
  {1,  0,  0,  1}, // 9
  {0,  1,  0,  1}, // 10
  {1,  1,  0,  1}, // 11
  {0,  0,  1,  1}, // 12
  {1,  0,  1,  1}, // 13
  {0,  1,  1,  1}, // 14
  {1,  1,  1,  1}  // 15
};


// variables

// our arrays for the binary data. 16 bits for incoming to start with as that is the width of the matrix, then push to 32 bit for messagePort transfer.
uint16_t matrixRead16[16];     // 16 x 16 bit uint16_t for storage of the complete 256 bits per full matrix read.
uint32_t matrixRead32Last[8];  // 16 x 16 bit uint16_t for LAST storage of the complete 256 bits per full matrix read.
uint32_t matrixRead32[8];      // pack the 16 bit reads for transport to 8 32 bits where 32[0]  is [1] and [0] of 16
bool     isNewMatrix[16];      // flags indicating that a 16 bit section has changed

//****************************************************************************************************

void setup() {                         //  setup: run once
  Serial.begin(115200);

  pinMode(CD4067_COL_S0, OUTPUT);
  pinMode(CD4067_COL_S1, OUTPUT);
  pinMode(CD4067_COL_S2, OUTPUT);
  pinMode(CD4067_COL_S3, OUTPUT);
  pinMode(CD4067_COL_IO, INPUT);   // this is where we read the data bit on the scan
  pinMode(CD4067_ROW_S0, OUTPUT);
  pinMode(CD4067_ROW_S1, OUTPUT);
  pinMode(CD4067_ROW_S2, OUTPUT);
  pinMode(CD4067_ROW_S3, OUTPUT);
  pinMode(CD4067_ROW_IO, OUTPUT); // this is always HIGH, it is the ROW logic 1 driver state. All other rows are pulled down by 10k resistors.

  digitalWrite(CD4067_ROW_IO, HIGH);
}                                      //    setup end

void setup1() { // core 2
   pinMode (LED_BUILTIN, OUTPUT);
}

void loop1() { // core 2
  digitalWrite ( LED_BUILTIN,HIGH );
  delay(1000);
  digitalWrite ( LED_BUILTIN,LOW );
  delay(1000);
}
//****************************************************************************************************

void loop() {                          // main program loop

  uint8_t x = 0;
  uint32_t test = 0;
  uint32_t count = 0;
  // was 2268 test 1
  //
  
  float now1 = millis()+1000;
  while (millis() < now1) {
  //for (uint32_t test = 0; test <= 5000; test++ ) {
    if (scanInputMatrix()){      // scan returned a matrixNew flag set so we have new data
      sendMatrixToMessagePort(); // need to check serial port buffers etc
    } 
    count++;
  }

  //float now2 = millis();
  //delay(1000);
  Serial.print(count);
  Serial.print(" scans completed in ");
  //Serial.print((now2 - now1) / 1000);
  Serial.println(" 1 Seconds");




}                                      // main loop end

/*
******************************************************************************************************
                                            Subroutines
******************************************************************************************************
*/
void sendMatrixToMessagePort() {
  // stuff appropriate data to MP - minimise transfer
  // now we have 8 matrixRead32[] units of the array which contain - for example - matrixRead32[0] is made up of matrixRead15[0] in the low word and matrixRead16[1] in the highword etc
  // we also have flags for the isNewMatrix[x] which are the 16 original array elemenets
}



bool scanInputMatrix() {
  //  Serial.println("We got to scanInputMatrix ! ");
  uint8_t tempRead = 0;
  uint8_t x = 0;
  bool matrixNew = false;
  
  
  for ( x = 0; x < 8; x++ ) {        // clear all previous values
    matrixRead32[x] = 0;                   // clear all cells ready for read
    isNewMatrix[x]  = false;                // clear all 'new reading' flags
  }

  for ( x = 0; x <= 15; x++ ) {        // step our matrix
    CD4067setColumn(x);                      // set the column number that the mux is open on
    for (uint8_t y = 0; y <= 15; y++) {      // now we will step through all 16 rows and read the col value for that row,
      CD4067setRow(y);                       // ROW IO is always a HIGH OUTPUT - this is the driver, we read the COL IO !
      // read in value
      //if ( x != 0) matrixRead16[x] = matrixRead16[x] << 1;     // shift left 1 place - but not on the very first time !
      matrixRead16[x] = matrixRead16[x] << 1;                    // shift left 1 place - but not on the very first time ! // IF the var is EMPTY to start with this wont be an issue.
      //        tempRead = digitalRead(CD4067_COL_IO);           // now contains the value from that read = 0 or 1 only
      //        matrixRead16[x] = matrixRead16[x] + tempRead;    // place value in bit 0
      tempRead = digitalRead(CD4067_COL_IO);                     // now contains the value from that read = 0 or 1 only
      bitWrite(matrixRead16[x], 0, tempRead);
    }
  }
//   now convert to 8 x 32 bit
//   convert uint16_t to uint32_t
  for ( x = 0; x < 8; x++) {                              // stuff the values, upper and lower into matrixRead32 from matrixRead16
    matrixRead32[x] = matrixRead16[x + 1];                // stuff the lower 16 bits
    matrixRead32[x] = matrixRead32[x] << 16;              // shuft these right into the higher 16 bits
    matrixRead32[x] = matrixRead32[x] + matrixRead16[x];  // now matrixRead32[x] has the upper 16 bits stuffed with matrixRead[1] and lower with [0], and same for all others
  }

//   compare to old values from last scan and update where needed
  for ( x = 0; x < 8; x++) {                             // loop through our 8 x uint32_t arrays
    if (matrixRead32[x] != matrixRead32Last[x]) {         // we will store ANY changes and set the flag if changed
      matrixRead32Last[x] = matrixRead32[x];              // store our changed values in matrixRead32Last[]
      isNewMatrix[x] = true;                              // our individual 32 bit int flags to identify which ones have changed to allow selective sending to messagePort                                                          /
      matrixNew = true;
    }
  }
  return (matrixNew);
}



void CD4067setColumn(uint8_t channel)
{
  digitalWrite(CD4067_COL_S0, CD4067_TRUTH_TABLE[channel][0]);
  digitalWrite(CD4067_COL_S1, CD4067_TRUTH_TABLE[channel][1]);
  digitalWrite(CD4067_COL_S2, CD4067_TRUTH_TABLE[channel][2]);
  digitalWrite(CD4067_COL_S3, CD4067_TRUTH_TABLE[channel][3]);
}

void CD4067setRow(uint8_t channel)
{
  digitalWrite(CD4067_ROW_S0, CD4067_TRUTH_TABLE[channel][0]);
  digitalWrite(CD4067_ROW_S1, CD4067_TRUTH_TABLE[channel][1]);
  digitalWrite(CD4067_ROW_S2, CD4067_TRUTH_TABLE[channel][2]);
  digitalWrite(CD4067_ROW_S3, CD4067_TRUTH_TABLE[channel][3]);
}
Will be next experiment, indeed have to wire and add inputs/outputs, together with external power supply, unfortunately with unavailable VR delivery, though would still have been mandatory :

image.png

SimPassion
Posts: 5338
Joined: Thu Jul 27, 2017 12:22 am

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#89 Post by SimPassion »

I will not purchase this, though I've been amazed by this 4 channels expander for the Pico 😲😃


Image

User avatar
jph
Posts: 2853
Joined: Fri Apr 10, 2020 12:50 pm
Location: Somewhere over the rainbow..

Re: [SOLVED & RPi Pico Issue] NANO - CH340 - Win 11 - Flashing issues / RPi Pico communication issue MessagePort

#90 Post by jph »

Hi Gilles, what a shame on the board. WHY did these people ship it with no vref soldered ? That is what has damaged the board !. The VREF will have been effectively 0V ! hence would be overloaded when 3.3 was applied. Crazy. Well, as you say, never mind. It was worth a try but yes at some point it is time to move on.
Nice work on the mods to the program, it is really easy to use and you can use it as the basis for your own code to do anything at all with neopixels. When you get a strip of them you can have great fun :D It's a good intro to messageport as well.

Good luck with the mux program. I have never actually set it up and tried it apart from a few early tests on a single board but the theory should be sound. I was more interested - at the time - in testing the amount of reads per second I could do and it was more than enough, especially when you consider that you have another completely idle core on the pico to play with that could, for example, run the neopixel program - or indeed more than one string! at the same time. Incredible computing power on such a small device.
A 'Gilles' version of the neopixel side would be pretty amazing in the future.
I am going to order a couple of those expansion boards today from aliex as they are good for bringing out the pin namings as the genuine pico has them on the WRONG side of the board :shock: :lol: .
When you get your genuine picos from the EU you should be able to set the clock at 240Mhz ultra reliably and these really are quick.
Have fun.
Joe
Joe. CISSP, MSc.

Post Reply