Actually there's Schottky diode right there so tried powering after that, ~4.8 V.
That worked color wise, but battery bank still turned out.
Going to see if two WS2816B is enough...
Thanks @macca that looks better than last time I looked at it. Still, main problem there is that I/O pins have to be in 0..7 range.
Doesn't work in this particular instance...
In a very large number of my P1 projects a launch an internal support cog that runs a 1ms loop and calls very tasks that have their own timing variables. It turns out that you can get quite a lot of work done in a millisecond in the P1. This might be something to consider for your controller -- you're trading one cog (WS28xx) for this; that said, you can control a standard LED and a whole lot more, and use the LED as a 1s "heartbeat" indicator.
This is the background code in the demo.
con { background cog }
var
long bcog ' background cog #
long bcstack[32] ' stack for background cog
long millis ' global milliseconds register
pri background | t ' launch with cognew()
io.low(LED_26)
millis := 0
t := cnt ' sync loop timer
repeat
waitcnt(t += MS_001) ' run loop every millisecond
++millis ' increment millis
show_heartbeat
var
long hbms
pri show_heartbeat
if (++hbms == 1000)
hbms := 0
if (hbms < 250)
outa[LED_26] := 1 ' 100%
' outa[LED_26] := hbms ' 50%
' outa[LED_26] := hbms >> 1 ' 25%
else
outa[LED_26] := 0
The easy way around this is to put two 100 Ohm resistors between 5V and ground. This seems to suck enough power to keep my bank on. Not sure how universal that is going to be though.
Still think will add this with another solder jumper. Definitely don't want that connected when powering board by coil cell...
Might look to see if there's another load that would keep it going. Maybe a couple NeoPixels would be enough. Robot needs lights anyway...
Hi, I recently read that it is enough, to have a current pulse load to keep the power bank on. It isn't necessary to have a constant load. Current and pulse frequency varies for different banks.
@"Christof Eb." Read that too. But, doesn't really work with one of my power banks. Anything less than 50% duty load and it shuts down. But, maybe need to play with that more....
Got the revised boards in a few days ago and assembled some yesterday, and it's all looking good!
Using a new type of I2C EEPROM, as described here: https://forums.parallax.com/discussion/173266/eeprom-for-propeller-1#latest
This is great because it is compatible with 3.4 MHz and also low speed I2C, has double the size, and includes a unique ID.
It shows up as four devices in I2C scanner, with two of them belonging to memory, which think means can use existing driver and just treat as two separate 64 kB devices.
Just tested a QWIIC device on the QWIIC connector with the new solder switches set to share the EEPROM I2C bus and it seems to work. This is really nice.
The old type of EEPROM may not have been happy with some other devices on the bus, especially high speed ones, but this is looking good.
One minor thing is that a lot of QWIIC things have their own pullups on board, which wind up in parallel with the 10k ones on the board.
But, thinking that will actually help it go to high speed and doesn't seem to bother P1 booting...
If memory serves me, the I2C clock when the P1 boots up is around 200kHz. There is no problem dropping fast devices on the EEPROM bus, though I did once have an issue with a display that did I2C in software and couldn't go past 100kHz; for reasons I don't fully understand that display would interfere with writes to the EEPROM. Thankfully, the board I was using (EFX-TEK HC-8+) had spare IOs and I was able to put that display on its own bus.
Guess we will see how my Qwiic collection behaves with eeprom…
Think you are probably right that will be ok.
BTW: the Qwiic connector also could allow easy connection for non i2c purposes. Imagine that some other mcu can’t do this because using dedicated i2c pins. But find it interesting that haven’t seen anybody use the connector for other purposes…
One thing thinking about is Qwiic cable connection to a breadboard. Two propeller pins is enough to play with for many things…
Glad added the option to switch Qwiic to p26 and p27 for something like this…
On the HC-8+ -- which was designed before the QWIIC connector was around, I have 3.3v and 5v I2C headers to give myself flexibility, but as I indicated, I had spare pins I could use for 3.3v I2C. On the P2 Battle Tower board I have QWIIC (3.3v) and JST XH-4 (5v) I2C headers connected to a couple free pins. Neither of those connectors is used in Battle Tower, but we envision future projects taking advantage.
Comments
Actually there's Schottky diode right there so tried powering after that, ~4.8 V.
That worked color wise, but battery bank still turned out.
Going to see if two WS2816B is enough...
Found that two WS2816B LEDs in white draws enough current to keep the battery pack on.
Tried reducing the on time to conserve power.. 50% duty like below works, but less than that doesn't seem to work...
PUB Main | pos strip.start_b(LEDS, STRIP_LEN) ' start led driver strip.off repeat strip.set_all(strip#white) pause(5000) strip.set_all(strip#BROWN) pause(5000)[...]
Just in case you missed it, there is a USB driver for the P1 https://github.com/SaucySoliton/propeller-usb-host
Thanks @macca that looks better than last time I looked at it. Still, main problem there is that I/O pins have to be in 0..7 range.
Doesn't work in this particular instance...
In a very large number of my P1 projects a launch an internal support cog that runs a 1ms loop and calls very tasks that have their own timing variables. It turns out that you can get quite a lot of work done in a millisecond in the P1. This might be something to consider for your controller -- you're trading one cog (WS28xx) for this; that said, you can control a standard LED and a whole lot more, and use the LED as a 1s "heartbeat" indicator.
This is the background code in the demo.
con { background cog } var long bcog ' background cog # long bcstack[32] ' stack for background cog long millis ' global milliseconds register pri background | t ' launch with cognew() io.low(LED_26) millis := 0 t := cnt ' sync loop timer repeat waitcnt(t += MS_001) ' run loop every millisecond ++millis ' increment millis show_heartbeat var long hbms pri show_heartbeat if (++hbms == 1000) hbms := 0 if (hbms < 250) outa[LED_26] := 1 ' 100% ' outa[LED_26] := hbms ' 50% ' outa[LED_26] := hbms >> 1 ' 25% else outa[LED_26] := 0@JonnyMac Something to keep in mind...
@macca Will see if can add pads for pulldowns so could then use for real USB using jumpers at least...
Here's layout for VGA-PS2(on USB)-stereo-mic board, adapted from P2 version. Same size, but this one has a lot more resistors and caps...
Hi, I recently read that it is enough, to have a current pulse load to keep the power bank on. It isn't necessary to have a constant load. Current and pulse frequency varies for different banks.
@"Christof Eb." Read that too. But, doesn't really work with one of my power banks. Anything less than 50% duty load and it shuts down. But, maybe need to play with that more....
Got the revised boards in a few days ago and assembled some yesterday, and it's all looking good!
Using a new type of I2C EEPROM, as described here: https://forums.parallax.com/discussion/173266/eeprom-for-propeller-1#latest
This is great because it is compatible with 3.4 MHz and also low speed I2C, has double the size, and includes a unique ID.
It shows up as four devices in I2C scanner, with two of them belonging to memory, which think means can use existing driver and just treat as two separate 64 kB devices.
Just tested a QWIIC device on the QWIIC connector with the new solder switches set to share the EEPROM I2C bus and it seems to work. This is really nice.
The old type of EEPROM may not have been happy with some other devices on the bus, especially high speed ones, but this is looking good.
One minor thing is that a lot of QWIIC things have their own pullups on board, which wind up in parallel with the 10k ones on the board.
But, thinking that will actually help it go to high speed and doesn't seem to bother P1 booting...
If memory serves me, the I2C clock when the P1 boots up is around 200kHz. There is no problem dropping fast devices on the EEPROM bus, though I did once have an issue with a display that did I2C in software and couldn't go past 100kHz; for reasons I don't fully understand that display would interfere with writes to the EEPROM. Thankfully, the board I was using (EFX-TEK HC-8+) had spare IOs and I was able to put that display on its own bus.
Guess we will see how my Qwiic collection behaves with eeprom…
Think you are probably right that will be ok.
BTW: the Qwiic connector also could allow easy connection for non i2c purposes. Imagine that some other mcu can’t do this because using dedicated i2c pins. But find it interesting that haven’t seen anybody use the connector for other purposes…
One thing thinking about is Qwiic cable connection to a breadboard. Two propeller pins is enough to play with for many things…
Glad added the option to switch Qwiic to p26 and p27 for something like this…
Now, need to decide if default qwiic pins should be 26&27 or 28&29…
Kind of a tough call…
On the HC-8+ -- which was designed before the QWIIC connector was around, I have 3.3v and 5v I2C headers to give myself flexibility, but as I indicated, I had spare pins I could use for 3.3v I2C. On the P2 Battle Tower board I have QWIIC (3.3v) and JST XH-4 (5v) I2C headers connected to a couple free pins. Neither of those connectors is used in Battle Tower, but we envision future projects taking advantage.
Good progress overall.
Keeping PFET power control for uSD is useful, especially for battery setups. Use short retry delays instead of long waits.