Most recent activity
-
Thank you for the voltage readings @user118421
'Removing the the print line still leaves me with the same error'
As the errors bubble up, and therefore appear in reverse order, I would have expected a slightly different output, as the specific error related to calling the print() function is now not present.
Did you mean the same as in only the same for the first two line code block from #9 post perhaps? (I was attempting to determine if I2C was initializing [it's overhead] error free before attempting comm over the I2C bus)
Under the assumption 5V has to be the minimum input voltage, any other way to supply that, or only just the USB cable available at the moment?
'this specific display but as it failed just like the Nokia 5110'
Do we have a separate issue here with the 5110? There is a tutorial, but that is based on SPI rather than I2C.
I'm not a fan of using cutting edge builds for the existing tutorials, but as a consideration, would flashing to a previous version have a different outcome?
I have not tried or tested, but it might mean an additional step is required. I'll defer to others for this: (see code block under the schematic, beneath heading 'Power, and the FET/B0 Jumper')' Once the FET/B0 Jumper is shorted, the following commands will work:
digitalWrite(B0,0); // Turn on the 'Bat' output fully '
I'm not sure if 'Bat' means the VBAT pin 2 output, what the voltage might be, or whether this implies just a current boost. . . . -
Sun 2020.10.04
I agree with you that; that #5 post specific document does present some confusion over the allowed voltage. It is also very specific that the LCD requires 5V. Without that board schematic, it would be guessing as to whether a boost converter is onboard to create the 5V when using 3V3.
While I'll have to defer to the board designer for a definitive explanation, the Pico schematic implies a small drop over the FET when attempting to pull power, when not supplying at pin 18 BAT_IN. I just measured my Pico using USB power, but with no load, and pin 2 is at 4V6 which is very close to the low end specified to even drive that LCD. Under the assumption that speification sheet is in error, any luck driving from the regulated 3V3 pin 3 as was done in the initial post? (not expecting success however)
As all the Arduino snippets and the Espruino documentation example are suggesting 5V, I'd first check to see if that is what is at pin 2 as is now wired in a loaded condition.
Regarding #7 image and #9 code snippet, SCL and SDA now appear to be wired as needed. Does the same error exist when removing the
lcd.print()line as a possibility to see if I2C comm is occurring during initialization with just the connect function? On a really long shot, I've gotten a few knock off boards (not this module) that have had reversed silk screen. Something to consider, but not likely. -
Sun 2020.10.04
'output seems totally random'
There is a note concerning the mag, presumably the gyro also:
Has
E.getBattery()been used to determine the amount of battery charge remaining?Are the same flutuations observed when using the low power module?
source: http://www.espruino.com/modules/puckjsv2-accel-movement.js
-
repsonse to #14 post and #4 requirement
'I'm doing a road test of the PAN1780 eval kit for Element14 and one of the things I wanted to showcase its BT capabilities was doing some light shows with neopixels.'
'I can always do something else instead . . . '
Sometimes just taking a bit of time off, asking the right questions, then overturning that one last stone enables one to find the treasure!
'doing something else' seemed like a load of extra work, and besides who doesn't like bright colored moving lights as a showcase demo to spark a conversation!!
Glad your persistence located the tid-bit of needed info to resolve. . . .
-
Good spot @MaBe! My orthagonal viewing glasses didn't pick up on that in addition to B7-A8. ;-)
As the USB connector is supplying the 5V, it appears 3V3 is available after the regulator as the VDD output pin3.
https://github.com/espruino/EspruinoBoard/raw/master/Pico/pdf/schematic_1v3.pdf
-
'I am not sure what you mean by the Arduino code block image.'
Was referencing your #6 image. Our posts crossed and I didn't get the correction done by the time your follow-up came through.
What pinMode() is used?The ideas were worth a shot. It does seem odd though that the board just locks up. The additional image, links, verification and testing is helpful and should assist others.
It appears you are the pioneer (def pioneer: the guy with all the arrows in his back) here with the nRF52840DK.
-
Thanks for the image. So the above with Arduino uses a longer array to write out the eight colors. was that suggestion tried? (ref larger array)
And we confirm on board regulator is sufficent to drive 8 Neopixels using Arduino code block? (Yes?)
'I don't think it's the circuit nor the neopixels itself.'
Would have to agree (for #6 image - is that an Arduino and not the DK board?):
EDIT: But the link in #8 post is to a different board that what is shown in #6 image
EDIT:
Are we able to rule out the delay fetching the module across the web?I may have to eat crow on that one. I just took a look at some working code from two years ago, and I used the require within a function call. I've also re-read my notes and just realized the Neopixel module is now a part of the current release, so it isn't (now) fetched across the web as it was when I developed then.
That strip seems to the the WB2812B and pretty common and easy to work with.
FWIW: I had a heck of time many months ago, until I could confirm squaring up of the data line with a level shifter, and the correct leading start pulse length. I don't know the nRF52840DK and that may not even be a consideration as it is confirmed with the Arduino #6 post image. -
Sat 2020.10.03
Hi @parasquid, no experience with the nRF52840DK and as there are many variants:
REFERENCE table of RGB Led datasheets 3528 5050 WS2811 WS2812 SK6812 APA102 NeoPixel
Taking into consideration: (in case this statement is found inaccurate)'It doesn't seem to matter whether I have a neopixel connected or not'
Some ideas to explore:
Is there a level shifter, or is a level shifter required? (several in link above)
Separate supply and grounding consideration
Any possibility of a Neopixel strip of several LEDs to rule out flaky first green LED issue
https://www.reddit.com/r/arduino/comments/499ods/strip_of_144_ws2812b_leds_first_led_stuck_green/
that along with RGB vs GRB and leading start pulse duration
Pull-up on data line (see reference in reddit link)
Any ability to try a different Neopixel type? Some are 12V, different gating, end pulse state?
What is driving the Neopixel? Regulator on that board, or separate supply?
Try writing a larger array, to rule out rounding of starting pulse (which causes first green LED, BTW)
[055,055,055, 055,055,055, 055,055,055, 055,055,055])
Smaller value to reduce load on regulator, and all lit to see if pulse rounding issue is resolvedAbility to use Logic Analyzer to validate data sent?
EDIT: (see post #7 explanation - now built in)
Could there be a module retrieval delay that is beyond the 1 second timeout interval shown?FWIW: I've always assigned the results of the require to a separate object after init, and performed future array writes in separate functions after a three second wait. Always successful on Pico, Wifi and MDBT42Q when using a level shifter.
-
Sat 2020.10.03
For those following along; HD44780 LCD Display
Hi @user118421 and thank you for the images.
From:
It appears the pull-ups are on B7 and A8, and not B6 and B7
Could a quick cross check verification be done. Hey, who moved that pin row since the last time I remembered where that pin was actually located?
Sun 2020.10.11
Hi @David1234321 I see that you are running 2V07 but on what device?
Please post
process.envso we are all on the same page.Will need to understand which device is under test.
What are the contents of the var when entering the vaiable name
mcpinto the L-Hand console window of the WebIDE?Maybe try wrapping in sections, several lines of code within a try/catch block to possibly learn more about the error itself.
Was
save()used?