Most recent activity
-
Wed 2019.01.16
Thank you for the confirmation, @Gordon
The third bullet needs just one final tweak. My take on the documentation is that there is one and only one UART SPI and I2C that can be configured.
Clarification is needed on the 'and infinite software SPI and I2C' part.
Does 'infinite I2C' then mean more than one Neopixel string may be configured? (no? as infinite other I2C devices %could% be configured, e.g. 'available', but only one Neopixel reference allowed? as limited by internal hardware/software design)
As a suggestion, what about a table for Neopixels that shows functionality?
On leftmost Y-Axis, the devices and adjacent to that the processors. Along the X-Axis, (numb) Hdwr SPI, Software SPI, Software I2C
ex: For Neopixel - 'inf' means infinite available but not for Neopixel - use I2C
Pico STM32 | 3 - -
Pixl nRF52 | - inf 1 -
Tue 2019.01.15
Slick!
Add to Tips-and-Tricks?
-
- 4 comments
- 80 views
-
'but the issue here is that the higher wins and is the only one detected'
May agree on the exit latch flip-flop, but not on 'only one detected' in above statement.
As the ball rolls through the lane, tripping it's lane switch, another player lane might have a ball roll through a half second later, and a third a second after that. The other nine would be in the process of launching the ball. So polling these switches is nothing in processor time and accurate event monitoring could take place.
'The real issue is that only one is noticed'
If a flip-flop is used, that might block/lock the other near simultaneous ball pass through reads. What about a simple R-C circuit that briefly charges a cap, then discharges it after a read. In that way, say polling ten times a second, would allow for %all% detections, even on close races, as the time to reload and fire might be three or more seconds away.
48 hrs have elapsed. Put an A.P.B. out for Mike, hope we haven't scared him away . . . .
-
Sun 2019.01.13
'A lower priority may trigger . . . . have chipped in and messed it all up'
I can't imagine this was of much concern the the design using relays back in the 50's
Just the time element in closing the relay contacts would be far worse (a fair guess) than a microcontroller polling the input.
Even as a child I remember what appeared to be 'glitches' in the way the (now lights) mechanical horses advanced. It sometimes seemed a random group of three advanced, when two of the three still had a ball waiting to enter a lane. I wonder if this is how they got around that timing issue, by creating a diversion, perhaps?
-
Sun 2019.01.13
Taking an overnight break and starting fresh, with a cup of coffee of course, Success!!
Well at least for the Hardware SPI on Pixl. Still would like Software SPI clarification, though.
So what did I learn from this experience?
Younger than fifty heed this as you'll get to this age eventually, a fact, older than that, you'll get a kick out of this.I attribute the success to the ID-10-T error. Enunciate alpha chars to get it. Okay, got it? (not, eye dee ten tee)
Embarrassment Factor: 6
Having two hundred hours Neopixel coding on the Pico, I was comfortable using any of the three SPI ports on that device. Wanted to build a BLE controlled Neopixel project, with the Pixl.Reading this note:
Note: Pixl.js has one available I2C, SPI and USART (and infinite software SPI and I2C). Unlike other Espruino boards, these peripherals can be used on any pin.
the fact that the words 'infinite software SPI' caught my eye. Following, 'can be used on any pin' made me curious. And here is where the flawed thinking crept in. As the other Pico documentation had roll-over icons that showed the hardware SPI ports, I made the Ass-U-Me(ption) that as the Pixl page indicated one hardware SPI, but the embedded image did not contain the roll-over icons, that the image needed updating, as the Pico page had been around for a few years and most likely had all flaws corrected. Not seeing the comparable hardware info blocked the reasoning that 'any pin' could be used. Again, after re-reading @MaBe response and rationalizing that why would the seemingly obvious be a type of response that a seasoned forum contributor would post. . . . hmmm . . . I went back to the Pixl page and noticed that there wasn't the USART and I2C roll-over detail either.
Then it hit me, ID-10-T !! Maybe, just maybe, the build as MaBe explained did a little magic under the hood, unlike how the Pico has fixed pins for it's SPI ports. Moving the data input wire to a selected pin and coding as MaBe suggested, and viola!
Steps to solving or debugging the seemingly impossible:
- Take a break and start fresh
- Re-Read the specs and supporting docs several times
- Double check your voltages and wiring
- Review other similar projects
- Re-Read what was (you) previously posted in the forum
- Ponder. Sit back and put the pieces together
Heeding the note, I limited my test to two Neopixels (any more and you'll blow the onboard regulator)the 5v pin will be connected to regulated 3.3v power (note: max power draw is 150mA)
http://www.espruino.com/Pixl.js#-vin-pinsrequire("neopixel").write(A5, [0,0,0,120,120,120,0,0,0,255,0,0]);turns on the second Neo amber and the forth Neo green
Success!!
- Take a break and start fresh
-
Sun 2019.01.13
Boy do those Swedes know how to have fun !!
(missing beer holder though)First Flight
https://www.digitaltrends.com/cool-tech/axel-borg-flying-machine-update/
http://amazingdiyprojects.com/in_progress.html -
Sat 2019.01.12
Performing a Google search, remember Google is your friend,
Google: E.openFile site:espruino.com
a lengthy discussion and solution was previously proposed
Thr 2019.01.17
Bullet #3 in post #6 indicates I2S But, searching the Pixl.js page only brought up the references to I2C, so I made the (false) assumption that 'S' was a typo as I had gotten the Neopixels to illuminate while realizing software SPI isn't what is controlling the output as the testing in #4 above shows. Bullet #3 led me to understand it was I2C.
So, is an explanation for I2S (for Neopixels) needed for nRF52 chips in those pages as this (I2S) is a new mystery feature?
This still doesn't answer the question as to the number of Neopixel channels(? strings?) for a single device when using Neopixels via software (nRF52).
The note at the Python build files show 1
and there isn't a reference to I2S there either.
So, would it be correct to say only one Neopixel string may be configured (using internal software I2S) on any pin for nRF52 chips?
IMO the table in #8 could have device by name descriptors to the far left as I indicated in #7 as I, and maybe others don't relate to the devices the same as designers do. Maybe that gets ironed out using them for five years? When using a device, I don't think I'm using my STM32 but think Pico, then look at the Pico.js page to see what processor it is to then determine whether hardware SPI is available, the same way I'm trying to learn what Pixl.js possesses.