Coder Social home page Coder Social logo

badger2040's Introduction

Badger 2040 & Badger 2040 W

Firmware, Examples & Documentation

Badger 2040 and Badger 2040 W are maker-friendly all-in-one badge wearables, featuring a 2.9", 296x128 pixel, monochrome e-paper display.

Install

Grab the latest release from https://github.com/pimoroni/badger2040/releases/latest

There are four .uf2 files to pick from.

⚠️ Those marked with-badger-os contain a full filesystem image that will overwrite both the firmware and filesystem of your Badger:

  • pimoroni-badger2040-vX.X.X-micropython-with-badger-os.uf2
  • pimoroni-badger2040w-vX.X.X-micropython-with-badger-os.uf2

The regular builds just include the firmware, and leave your files alone:

  • pimoroni-badger2040-vX.X.X-micropython.uf2
  • pimoroni-badger2040w-vX.X.X-micropython.uf2

Badger 2040

  1. Connect your Badger 2040 to your computer using a USB A to C cable.

  2. Reset your device into bootloader mode by holding BOOT/USR and pressing the RST button next to it.

  3. Drag and drop one of the badger2040 .uf2 files to the "RPI-RP2" drive that appears.

  4. Your device should reset and, if you used a with-badger-os variant, show the Badger OS Launcher.

Badger 2040 W

  1. Connect your Badger 2040 W to your computer using a USB A to microB cable.

  2. Reset your device into bootloader mode by holding BOOTSEL (onboard the Pico W) and pressing RESET (next to the qw/st connector).

  3. Drag and drop one of the badger2040w .uf2 files to the "RPI-RP2" drive that appears.

  4. Your device should reset and, if you used a with-badger-os variant, show the Badger OS Launcher.

badger2040's People

Contributors

ahnlak avatar allc avatar axelson avatar gadgetoid avatar helgibbons avatar hrw avatar jsh97 avatar richrboo avatar sfblackwell avatar sinofp avatar zoobdude avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

badger2040's Issues

I2C pins on Qwiic connector

I'm trying to add a breakout board (BME688) via the Qwiic connector, however no combination of SDA/SCL pins can detect the board, what pins should I use to access boards via the connector?

MicroPython Startup Benchmarks

As part of the discovery process for dropping our complex Pico SDK runtime patches, I ran some tests of startup times under the following conditions:

  1. vsys high to GPIO 15 high (set by MicroPython)
  2. vsys high to GPIO 14 high (set by C++)
  3. vsys high to GPIO 12 high (set by our pico_runtime/runtime.c patch)

I also tested the first two cases with and without our clock config patches.

Basic clock config patch: https://github.com/pimoroni/badger2040/blob/v0.0.2/firmware/startup_overclock.patch

Full runtime patch: https://github.com/pimoroni/pimoroni-pico/blob/v1.19.18/micropython/_board/picow_enviro/wakeup_gpio.patch

Findings:

  1. Overclock makes more of a difference to startup time than moving from MicroPython to C++ -

    • from MicroPython to C++ is 50ms faster
    • raising clock early: MicroPython is 87.6ms faster
    • raising clock early: C++ is 88ms faster
    • raising clock early: gains ~88ms in both cases
  2. Moving from C++ to pico_runtime/runtime.c is much faster again

    • vsys high to GPIO set MicroPython: 77.6ms
    • vsys high to GPIO set C++: 26.8ms
    • vsys high to GPIO set pico_runtime/runtime.c: 8.2ms

If we want to read or set GPIO earlier than 26ms from power-on, we must patch pico_runtime/runtime.c and run our code before all the other bring-up.

A plain C++ approach gets us around 26.8ms to pin read. This is fine for Badger 2040 and actually functions as a sort-of debounce.

Summary

Setting a pin in MicroPython will take ~77ms from power on in the absolute best case. A larger MicroPython main.py with more complicated code will affect this.

Setting a pin in C++ (using __attribute__ ((init_priority (101))) on a struct instance) will take ~27ms from power on in the absolute best case. Adding any other C++ modules that are init before the wakeup module will affect this. (Though I have taken pains to remove all C++ init since it will try to allocate memory.)

Captures

VSys to GPIO15 High: MicroPython

pico-w-vanilla-startup-vsys-micropython-gpio15-high
pico-w-vanilla-startup-vsys-micropython-gpio15-high-overclocked

VSys to GPIO14 High: C++

pico-w-vanilla-startup-vsys-cpp-gpio14-high
pico-w-vanilla-startup-vsys-cpp-gpio14-high-overclocked

VSys to GPIO12 High: pico_runtime/runtime.c patch

pico-w-vanilla-startup-vsys-runtime-gpio12-high-overclocked-zoomed

BadgerOS image becomes unresponsive after first app launch, but works OK with MicroPython one

I just received my Badger2040 W. I read the getting started guide and found out how to the latest OS, and I've got that process working fine. However, once installed, things are not quite so smooth.

If I wipe it with flash_nuke.uf2, and then install MicroPython from pimoroni-badger2040w-v0.0.3-micropython.uf2, it resets, flashes the screen a couple of times (but the Badger OS screen still comes up, but buttons are unresponsive – I'm assuming this is some leftover image in the screen's own memory?). In this mode, I can interrupt it with Thonny and python works, but obviously none of the Badger OS apps are there.

If I wipe it again, and then install the BadgerOS image from pimoroni-badger2040w-v0.0.3-micropython-with-badger-os.uf2, the OS screen comes up again, but I can't interrupt it from Thonny, and also the buttons are unresponsive, and I can't launch any of the apps.

In both situations, the white LED in bottom left comes on and stays on.

I'm not using a battery, only USB power, but power-cycling it makes no difference.

When I first powered it on I was able to launch the apps, and I noticed that it showed 23% space used. After doing the 0.0.3 update (from blank, as above), it's using 40%, so I'm assuming that this means that it was running an older (and smaller) version of Badger OS that worked, but the newer version does not. After installing 0.0.2, I see that the usage graph has remained the same?

On further testing with both 0.0.2 and 0.0.3, they both act the same way - after installing a fresh OS image, I can launch any of the apps, then return to the launch screen, but after that everything is unresponsive, and I can no longer launch apps, even after a power cycle or reset. To clarify, after a clean install I can launch one app, exit it, and then the badger is seemingly dead.

I've not seen anything that suggests the two buttons on the right work – If I press one of them after a clean install, nothing happens, but I can't launch any apps either, and I have to wipe it again.

FWIW I'm on macOS running Thonny 4.1.2. I've also tried all this without Thonny running, so it's not interrupting anything.

Is this expected behaviour, or have I missed something?

Erratic performance of badger OS when using battery

With the badger on usb power, it’s nicely responsive. However, on battery, the exact same disk image reacts differently.

For example,

  • the QR code app usually doesn’t launch when selected from the menu. Also, when it launches, it flashes the ‘no qr codes’ text, despite a qr code existing. When I press up or down, the QR code appears. The happens both on AA power and LiPo.
  • On USB power, the QR code app launches straight away, and straight away displays the QR code.

Also, the

  • A+C combination doesn't work reliably on battery power - it takes several tries to exit an application
  • On USB power, no problem.

I’m running the latest image (v1.19.16 micropython).

https://forums.pimoroni.com/t/badger-2040-w-battery-vs-usb/21698/1
https://forums.pimoroni.com/t/badger-2040-w-alternative-key-to-return-to-menu/21688

Thanks!

`import badger2040` results in OSError: [Errno 5] EIO

After flashing my 2040W with the latest firmware (0.0.3), attempting to import badger2040 now results in an EIO error:

>>> import badger2040
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "badger2040.py", line 57, in <module>
OSError: [Errno 5] EIO

I can also repro this by entering commands into the repl: it appears that these lines trigger it in the firmware:

>>> import machine
>>> i2c = machine.I2C(0)
>>> i2c.writeto_mem(0x51, 0x00, b'\x00')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 5] EIO

badger2040.system_speed regression

Since badger2040.system_speed was migrated into Python to use machine.freq it's lost a lot of edge cases that handle lower clock frequencies, and additionally lacks the slight overvoltage that may make higher frequencies stable on some systems.

We need a custom module giving an implementation of machine.freq that looks more like the old Badger 2040 system_speed function.

Old function: https://github.com/pimoroni/pimoroni-pico/blob/c8d3b6b7d1875b35147867e31b102ffcad128788/micropython/modules/badger2040/badger2040.cpp#L535-L591

New function: https://discord.com/channels/801944326401556512/801944538981466183/1110852447242567690

MicroPython's machine.freq(): https://github.com/micropython/micropython/blob/ed7a3b11d9a6c21a964d55ebfcdefeb392389d10/ports/rp2/modmachine.c#L102-L116

OSError: [Errno 110] ETIMEDOUT

Hi,

Since recently, I receive the folllowing error, using badger2040w , pimoroni-badger2040w-v0.0.4-micropython-with-badger-os.uf2

Traceback (most recent call last):
File "", line 5, in
File "badger2040.py", line 58, in
OSError: [Errno 110] ETIMEDOUT

The error is thrown at this line:

i2c.writeto_mem(0x51, 0x00, b'\x00') # ensure rtc is running (this should be default?)

https://github.com/pimoroni/badger2040/blob/a8552a55ad090783f9bf06aa2a07821051accf87/firmware/PIMORONI_BADGER2040W/lib/badger2040.py#L57C31-L58C88

Any idea how to solve this? I tried reflashing pimoroni-badger2040w-v0.0.4-micropython-with-badger-os.uf2 though even with the default launcher, the error is thrown.

Even when trying to import badger from the shell , the error is thrown

>>> import badger2040
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "badger2040.py", line 58, in <module>
OSError: [Errno 110] ETIMEDOUT

memory usage indicator in launcher app: no need for % with decimals and config file for launcher basics ?

Right now I get the bar and a 40,57% figure which is tiny small and harder to read the older you get.

So might be time to focus on the key figures and in this case 41% would be enough - or you need a configuration file to setup things you want from the launcher like I would prefer a date and time in the upper right corner at least for those W versions where access to the web is possible. So another option for the config would be if and when to update the time from the web or not.

But that might be another topic and discussion as the next option for a configuration file like a bigger headline and font for the launcher's headline that makes it possible to read 'BadgerOS V0.0.2 ..... 41% .... .

At least a point to start cause I have added already a lot of these topics somehow with my basic skills and lot of tinkering to get rid of all the . as decimal separators and other points I do not really like cause our weather reports shows 9,7°C and not 9.7°C which leads to a lot of question cause this display is primarily used by elderly people to check the weather report and the power prices of now and every hour today cause we had gotten now offers with hourly rates and especially elderly are highly interested how to reduce their energy bill. That interest had made me buy this display cause it can be 247 on and update the power prices for every hour and once for the next day.
And the weather outlook is important for them to make the laundry at cheap tarifs and dry the clothes the other day in sunny weather.

Badger 2040W: Date_Time?

Hi,

I wrote a little script that looks at a dictionary with birthday and shows me how long until the next person has a birthday.

import badger2040
import utime


# Birthday information
birthdays = {
    'Person1': (9, 1),
    'Person2': (20, 1),
    'Person3': (4, 2),
}

# Function to get the current date in the format DD/MM
def get_current_date():
    current_time = utime.localtime()
    current_day = current_time[2]
    current_month = current_time[1]
    return current_day, current_month

# Function to display birthday message
def display_birthday_message(display, next_birthday_person, days_until_birthday):
    # Display "Happy birthday!" on the screen
    display.set_pen(15)  # White background
    display.clear()

    display.set_pen(0)  # Black text
    display.set_font("bitmap8")

    # Display the name centered, larger, and a bit lower
    text_width = display.measure_text(next_birthday_person, scale=5)
    display.text(next_birthday_person, (296 - text_width) // 2, 30, scale=5)

    # Display "Happy birthday!" centered and larger
    birthday_message = "Gelukkige verjaardag!"
    text_width = display.measure_text(birthday_message, scale=3)
    display.text(birthday_message, (296 - text_width) // 2, 95, scale=3)

    display.update()
    utime.sleep(5)  # Display the message for 5 seconds

# Function to calculate countdown
def countdown(current_date, stop_date):
    current_day, current_month = current_date
    stop_day, stop_month = stop_date

    # Calculate days until the next birthday
    if current_month < stop_month or (current_month == stop_month and current_day <= stop_day):
        days_until = (stop_month - current_month) * 30 + (stop_day - current_day)
    else:
        # Birthday is in the next year
        days_until = (12 - current_month + stop_month) * 30 + (stop_day - current_day)

    return days_until

# Display Setup
display = badger2040.Badger2040()

# Run the script every 8 hours
while True:
    # Get the current date
    current_date = get_current_date()

    # Find the next birthday
    next_birthday_person = None
    days_until_birthday = float('inf')

    for person, birthday in birthdays.items():
        days_until = countdown(current_date, birthday)

        if days_until < days_until_birthday:
            days_until_birthday = days_until
            next_birthday_person = person

    # Set pen color and font for the next person's birthday and days until
    display.set_pen(15)  # White background
    display.clear()

    display.set_pen(0)  # Black text
    display.set_font("bitmap8")

    # Display the next person's birthday centered, larger, and a bit lower
    text_width = display.measure_text(next_birthday_person, scale=5)
    display.text(next_birthday_person, (296 - text_width) // 2, 30, scale=5)

    # Display remaining days larger and centered
    days_text = f"Nog {days_until_birthday} dagen"
    text_width = display.measure_text(days_text, scale=4)
    display.text(days_text, (296 - text_width) // 2, 95, scale=4)  # Updated height to 95

    display.update()

    # Check if it's someone's birthday
    if days_until_birthday == 0:
        display_birthday_message(display, next_birthday_person, days_until_birthday)
    
    # Calculate and display countdown
    count_days = days_until_birthday
    countdown_text = f"Countdown: {count_days} days"
    text_width = display.measure_text(countdown_text, scale=4)
    display.text(countdown_text, (296 - text_width) // 2, 130, scale=4)
    
    display.update()

    # Sleep for 8 hours
    utime.sleep(1 * 60)  # 8 hours in seconds

Runs fine with Thonny! But when I run this on battery, the date is complely wrong on screen. Does this script use date time from Thonny? How do you get the correct date from the onboard 2040 chip, untethered?

Missing CmakeLists.txt

I'd like to build the uf2 from source, but there is a lack of a CMakeLists.txt file, and build instructions.

Wifi not initializing on Badger2040W

I am getting the following error trying to initialize wifi network using .connect:

ampy.pyboard.PyboardError: ('exception', b'', b'Traceback (most recent call last):\r\n  File "<stdin>", line 19, in <module>\r\n  File "badger2040.py", line 264, in connect\r\n  File "uasyncio/core.py", line 1, in run_until_complete\r\n  File "uasyncio/core.py", line 1, in run_until_complete\r\n  File "uasyncio/core.py", line 1, in run_until_complete\r\n  File "network_manager.py", line 78, in client\r\nOSError: [Errno 1] EPERM\r\n')

I have tried this on 3 different wifi networks and with v0.0.1 and v0.0.2 of the firmware, and the firmware from the latest build.

The simplest example of the error is:

>>> import network
>>> wlan = network.WLAN(network.STA_IF)
>>> wlan.active(True)
>>> wlan.scan()
Traceback (most recent call last):   
  File "<stdin>", line 1, in <module>
OSError: [Errno 1] EPERM

I thought hardware issue, but then I flashed the latest stock rp2 pico-w firmware, and the same command works correctly and lists wifi networks. I am able to connect with wlan.connect and get an ip address.

white space is mashed for bitmap fonts

I would like to reopen this issue. The whitespace character is messing things up somehow. See:
compare
I used badger.text(strLine, x, y, scale=2,spacing=1,fixed_width=True) (yeah I know spacing is not a thing when using the bitmap fonts, but I tried to make sure)
If I use _ for padding up spaces (using micropythons .format) everything is as expected, but space characters (ASCII 0x20 I suppose) fail to do so. Will have a look at the code if I got some time left

accessing the framebuffer?

i wanted to see if i can somehow get the framebuffer of the badger's display (mainly to create a function that inverts a small section of the display)

there is a set_framebuffer function that works with a bytearray, e.g.

import badger2040
display = badger2040.Badger2040()

fb = bytearray(4736) # (4736 = number of pixels on badger (296*128 = 37888) divided by 8)
display.set_framebuffer(fb) # fills the screen with black since the bytearray is full of 0x00s

display.update()

and picographics does seem to have a get_framebuffer function that is omitted from from the badger (was this deliberate?)

i feel like reading and modifying the framebuffer directly could have some uses, like creating interesting effects or being able to draw patterns faster (the example above is faster than setting the pen to 0 and clearing the screen, albeit by only 9 milliseconds)

v0.0.3 not recognised correctly by Thonny

If I flash v0.0.2 Thonny correctly displays all files etc.
But with version v0.0.3, it does fail when trying to stop the badger:

Unable to connect to /dev/cu.usbmodem1101: Could not configure port: (6, 'Device not configured')

Process ended with exit code 1.
────────────────────────────────

I need v0.0.3 for the new status handler option in display.connect!

Does anyone have any pointers maybe?

SD Card / SPI for Badger 2040 W

Is it possible to connect an SD Card to Badger 2040 W using the microSD card module and the SPI interface? If so, which pins can I use?

Display banding when power is removed

I am using a Badger 2040 with what I believe is the latest firmware.
Filename: pimoroni-badger2040-v0.0.3-micropython-with-badger-os.uf2

I have noticed that there is sometimes a vertical banding (lines) on the display after power is removed.

This appears to have been raised before, but the implication is that it was fixed with a firmware update.
pimoroni/pimoroni-pico#704
https://forums.pimoroni.com/t/display-banding-artefacts-on-badger-2040w-display/21521

Are there any known causes for this effect?
Regards, Dave

Badger 2040W: Not waking from halt with button press

Hi!

I am experiencing an issue whereby on the Badger 2040 W, when the halt() method is called, the device does not restart main.py upon a subsequent front button press, as expected in the documentation.

To demonstrate, I have the following program as main.py, with firmware v. 0.0.4:

import badger2040
import time

badger = badger2040.Badger2040()
badger.led(255)
time.sleep(1)
badger.led(0)
badger.halt()

When USB is connected, the LED blinks, as expected. Pressing any of the buttons on the front of the device does not cause the LED to blink again, so I suspect that main.py is not being started on wake up. However, when connected to Thonny, pressing any of the front buttons causes a new REPL prompt to appear (>>>), so the Badger does seem to wake up.

I'd be grateful for any help with this, please.

Thank you!

Waking from Sleep at a specific time of the day

Hello all,

I'm able to wake up my badger after a certain amount of time:

badger2040.sleep_for(minutes)

But how would I wake up at a certain time, i.e. 8:00 a.m. every day?

Thanks for help!

Badger_OS v0.0.3 VBUS sensing seems blind

@helgibbons animated me to report, that the badger_os v0.0.3 on Badger2040W(!) has an issue:

Code reads VBUS, but there will never appear a 'True', even if USB is plugged in:

from machine import ADC, I2C, Pin

# reading 'WL_GPIO2' on a picoW tells us whether or not USB power is connected (VBUS Sense)
vbus = Pin("WL_GPIO2", Pin.IN).value()
print(f"vbus: {vbus}")

Output Thonny (when USB is plugged in):

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
vbus: 0
>>> 

Since there is a newer version v0.0.4, with an even worse bug, this is just an idea, how the v0.0.4 got its reall bad bug, not recognizing the 'WL_GPIO2' pin anymore...

Badger 2040 display when connecting

def status_handler(self, mode, status, ip):
print(mode, status, ip)
self.display.set_pen(15)
self.display.clear()
self.display.set_pen(0)
if status:
self.display.text("Connected!", 10, 10, 300, 0.5)
self.display.text(ip, 10, 30, 300, 0.5)
else:
self.display.text("Connecting...", 10, 10, 300, 0.5)
self.update()

The 2040w is hard coded to take over the display when connecting, Could this be an option to light the LED or similar user defined action.

Example use case
Showing latest information from a website could look like

while True:
    display.keepalive()
    variables = get_data()
    draw_page(variables)
    sleep_for(10)

After waking up from sleep, the wifi needs to be connected again, taking ~10 seconds, so every 10 minutes, for 10 seconds the badge doesnt display the intended content. A user defined option could be doing an update partial to the screen or lighting the LED.

Badger_OS v0.0.4 does not recognize 'WL_GPIO2' on Badger2040W

Same code from #59 on same Badger2040W with Badger_OS v0.0.4 :

from machine import ADC, I2C, Pin

# reading 'WL_GPIO2' on a picoW tells us whether or not USB power is connected (VBUS Sense)
vbus = Pin("WL_GPIO2", Pin.IN).value()
print(f"vbus: {vbus}")

I personally find this one the more challenging output:

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
ValueError: unknown named pin "WL_GPIO2"
>>> 

Did I mess something up or are the releases getting some "winter tuning" lately?

Need a towel?

The Hitchhiker

documentation on display busy

Hi,
I sometimes run into issues when trying to send an update() or partial_update() while the display is already busy doing something. I thought I could just check for badger2040.BUSY.value() pin. But it does not work.

Do you happen to maybe provide more documentation on that?

Badger W not being detected by thonny.

My Badger W won't appear in Thonny. I've reflashed the firmware multiple times and even performed a flash nuke then a reflash but the Badger won't appear as a Serial device and thonny isn't able to connect to the Badger.
Is it an issue with the device or with how I'm handling the software?

Need method to compile micropython locally

I need a way to compile my own micropython interpreter for badger2040W locally (raspberry PI 4).
Specifically, there is a pull request in the main micropython repo I need that has not been merged.
It is micropython/micropython#10803.

I was able to figure out how to do this about 3 weeks ago when the micropython interpreter was built out of pimoroni-pico.
I am also building micropython for inkyframe 4.0 out of pimoroni-pico.

Ideally, Pimoroni needs to put your code in the main Micropython Project repo.
This process of needing code from 3 different repo that lineup is problematic.

I know you will give up some control over when your changes get merged.
But life will be simpler for anyone make changes to micropython for your platforms.

Note: I had discussions on Pimoroni forums about there here https://forums.pimoroni.com/t/compile-micropython-from-source-for-badger-2040w-and-inky-frame-4-0/21683

Badger example responds strangely

I just updated to 0.0.3 on a Badger2040 and attempted the "getting started" examples

>>> import badger2040
>>> badger = badger2040.Badger2040()
>>> print(badger2040.is_wireless)
<function is_wireless at 0x2000d120>

which is not the expected False value

everything else in the getting started seems to work as expected. I tried reflashing the uf twice to see if something weird happened.

c button acting as b button

Both the b & c buttons do the same thing. I can't open an app in the third column, and I verified that the c button checks a box in the check list app, just like the b button.

It was like this out of the box as well as after I flashed the latest firmware (pimoroni-badger2040-v0.0.4-micropython-with-badger-os.uf2)

I wonder if this is a bug in the firmware or a hardware defect.

It doesn't look like the code checking for BUTTON_C press has changed in some time. Are these buttons wired in a matrix and there is a short somewhere so it thinks B is being pressed instead?

Badger 2040 W does not run on battery until a button is pushed

When I run the new micropython 0.0.2 from pimoroni/badger2040 on battery after power up the LED does not light and main.py does not run.
If I push any of the front buttons it does run.

Running 1.19.16 from pimoroni/pimoroni-pico the LED lights and main.py runs when I power on the battery (with no button push).

I think the 1.19.16 behavior is correct. A fix for the newer version is needed.

Update: I just tried these tests on inky frame 4.0 running 1.19.16 and 1.19.18.
Behavior is the same for both. The LED does not light or main.py run until a button is pushed.

I noted a second issue. Related but different.

For both versions, on battery, once main.py is running if I push the reset button the LED turns off and main.py does not run.
Looking at the Badger 2040 W schematic this makes sense, but is not obvious.
The issue is the reset button does nothing to the PCF85063A.
I think it should pull the VDD for the RTC chip low putting it in a reset state too.
In my opinion, this is a defect in the board design.
I know you are not going to fix it. But it should be documented.

Circuitpython?

Are there any plans to make this work with CircuitPython? I know other Pimoroni projects use CircuitPython, and in fact it was Pimoroni hardware that caused me to switch from preferring MicroPython to preferring CircuitPython. I really like how CircuitPython shows up as a USB disk, and it seems that for a device like this where many folks are just going to be changing files on disk, and not writing python code, having a USB disk to work with would be much more user-friendly than having to install Thonny or other micropython file copy compatible tools.

Battery drain when wifi is not available

Hello all,

my Badger W is battery operated and works fine. Thanks! In normal operation the Badger does its job and then goes into power saving mode.

Just one thing: Whenever the Badger tries to reconnect to the local WLAN and the WLAN is offline and not available, the power saving mode is not reached.

After quite a short time, the battery is empty.

How could I avoid this?

Thanks a lot!

TODO

Phase 1 - Make this stuff work

  • - port the Badger W badger_os.py back to regular Badger
  • - port the Badger W badger2040w.py to badger2040.py
  • - figure out if much we can de-duplicate the above (not super urgent)
  • - ensure all Badger W examples fail gracefully on Badger, they should be mostly compatible except stuff like Clock where Badger 2040 has a USER button (and the example has manual time set) vs Badger 2040 W which tries to get time via NTP.
  • - ensure lib/ stuff is baked into firmware and badger_os/examples stuff is appended as a littlefs filesystem
  • - target an explicit release of pimoroni-pico
  • - add workflow to lint Python examples
  • - add .zip distribution of examples for copying to non -with-badger-os releases?

Phase 2 - Update docs & references

  • - Update badger2040 and badger2040w shop pages to link to firmware releases here
  • - Update learning portal examples to do the same
  • - Update learning portal examples to new Badger 2040 API (which will match 2040 W mostly)
  • - Update docs in pimoroni-pico to mark the Badger 2040 builds there as deprecated and point here
  • - Add porting guide doc covering any major differences between old Badger 2040 and new setup

Phase 3 - Delete all the things!

  • - Remove badger2040 .yml files from GitHub actions on pimoroni-pico
  • - Remove badger2040 docs & examples from pimoroni-pico

Screen won't refresh and error code [ERRNO1] EPERM

I think I may have broken the Badger 2040. Getting the error message [ERRNO1] EPERM.

I have reinstalled the OS and Thonny recognises the device giving the message below.

**MPY: soft reboot
MicroPython v1.21.0-dirty on 2023-10-11; Pimoroni Badger2040 2MB with RP2040
Type "help()" for more information.

**

Any ideas?

Add hints to pick a local NTP server, geographic and behind a NAT: examples/clock.py

Consider adding hints to pick a local NTP server, geographic and behind a NAT in examples/clock.py

Also:
a) Is it silly to wrap the Thonny bit in a conditional. I could not sync until I commented it out. Did Thonny change?
Does this argue with rshell use?
b) Since there are multiple fonts in examples/fonts.py hint that there are more.

% diff Current-Git-clock.py ./clock.py
16c16,24
< if display.isconnected():

    if display.isconnected(): 
        print("default NTP host is: ",ntptime.host)
        # Uncomment or edit for a 
        # local choice see https://www.ntppool.org/
        #ntptime.host = 'pool.ntp.org'
        #ntptime.host = 'server 1.north-america.pool.ntp.org'
        #ntptime.host = '2.north-america.pool.ntp.org'
        ntptime.host = '10.0.4.94'  #local behind NAT
        print("new and current NTP host is: ",ntptime.host)

22,25c30,33
< try:
< badger2040.pcf_to_pico_rtc()
< except RuntimeError:
< pass

#try:

badger2040.pcf_to_pico_rtc()

#except RuntimeError:

pass

29c37,38
< display.set_font("gothic")

#display.set_font("gothic")
display.set_font("serif")

Reading battery level with Badger 2040W

Dear All,

I have noticed that get_battery_level() doesn't perform a measurement:
def get_battery_level(): return 0 # Battery measurement`

Is this because the method provides erroneous results? Has anyone found a good way to report battery levels when running on battery?

Sincerely,
Duane

How are images to be loaded onto the Badger2040w?

I have not yet figured out how to load image files onto the Badger2040w and get them to display.

Steps I have taken:
-I read the readme within /examples/image.py """"Images must be 296x128 pixel JPEGs Create a new "images" directory via Thonny, and upload your .jpg files there."""

-I created what I believe to be a 1bit, 296x128 pixel .jpg image file. The same file as attached.

-I loaded said file into the /images folder alongside the /images/badgerpunk.jpg file, and got the message, "JPEG: could not read file/buffer. JPEG: could not read file/buffer."

-I have also loaded the image in other locations that did not follow the readme, but have had no success as well.

-I have also separately tried changing which extra data is saved and tried saving the image as grayscale when extracting the image from GIMP.

CatTree01

Building the u2f file

Hi,

I was wondering if there is a guide on how to build the u2f file for the non-W version of this. The whole thing is very nice, and it would be great to track my changes in a GitHub and deploy the firmware instead of tinkering with the interpreter :) Would save me from accidentally overwriting things on the device without saving them locally.

After some use, flashing firmware doesn’t restore a stalled badger

Working with Badger2040w and I am seeing some strange issues with firmware.

I had previously been running pimoroni-badger2040w-v0.0.3-micropython-with-badger-os.uf2

For some reason my badger stopped responding so I decided to flash the firmware and start from scratch

It enters bootloader mode fine.

Oddly, it now won’t respond when I provide the same v0.0.3 firmware (either the version with or without the badger-os files).

Rolling back, it also won’t take the v0.0.2
Trying v0.0.1 works and provides functional Badger-os.

Then tried to add v0.0.2 back and it won’t do anything. System freezes.
Same issue trying to add v0.0.3 from a baseline of v0.0.1

Flashed with RPI flash_nuke.uf2 and still the same problem

It seems that after some use, something is preventing v0.02 and v0.03 from flashing the device.

Badger 2040 W - ‘picographics’ object has no attribute ‘sleep_for’

I’ve written a bit of code for a brand new Badger 2040 W, it all works as expected, but I can’t get the sleep_for() function to work.

I’ve cut the code down to the bare minimum

import badger2040
badger = badger2040.Badger2040()
badger.sleep_for(1)

The error returned is

MPY: soft reboot
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "badger2040.py", line 171, in __getattr__
AttributeError: 'picographics' object has no attribute 'sleep_for'

The fuller code can connect to wifi, update the screen, turn the LED on and off etc without issue.

I’ve flashed my badger with the latest firmware for the Badger W (also tried without badger os). I've also tried version 0.1 and 0.2 https://github.com/pimoroni/badger2040/releases/download/v0.0.3/pimoroni-badger2040w-v0.0.3-micropython-with-badger-os.uf2 1

I've searched the examples and can't find any that use this function.

I’m using Thonny 4.1.1 to run the code on a windows 10 PC. Have also tried running the code saved as main.py when connected to a battery supplying 4v.

Broken Badger2040.image() method

In version 0.0.2, the Badger2040.image() method looked like this:

for(auto y = 0; y < dh; y++) {
  for(auto x = 0; x < dw; x++) {
    // work out byte offset in source data
    uint32_t o = ((y + sy) * (stride >> 3)) + ((x + sx) >> 3);
    // extract bitmask for this pixel
    uint32_t bm = 0b10000000 >> ((x + sx) & 0b111);
    // draw the pixel
    uc8151_legacy.pixel(dx + x, dy + y, data[o] & bm);
  }
}

However, in version 0.0.3 it looks like this:

for oy in range(h):
    row = data[oy]
    for ox in range(w):
        if row & 0b1 == 0:
            self.display.pixel(x + ox, y + oy)
        row >>= 1

So putting the same image data results in garbled pixels after upgrade to 0.0.3. Please make it compatible, like this:

for oy in range(h):
    for ox in range(w):
        o = oy * (w >> 3) + (ox >> 3)
        bm = 0b10000000 >> (ox & 0b111)
        if data[o] & bm:
            self.display.pixel(x + ox, y + oy)

Badger 2040W Won't Connect to Unsecured Wireless

Our school uses heavily filtered, unsecured wireless - mainly for any non-staff devices.

Our recently bought Badger 2040Ws don't want to connect to the unsecured WiFi (standard Raspberry Pis connect fine). We've tried several variations in the WIFI_CONFIG.py file, but without any luck.

We've tried:
PSK = ""
PSK = None
Adding a line with: KEY_MGMT = None
Replacing the PSK line with: KEY_MGMT=None

I've tried taking a look at net_info.py, but it only seems to pass the SSID and PSK from WIFI_CONFIG.py

Any ideas guys?

Missing version in the info launcher?

If I start the Badger W I can not find a version from the launcher menu .
I had expected to find the 0.0.2 mentioned here for the most recent one in the INFO section at least, maybe in the help section too.

Right now I am asking myself if I had gotten the Badger W shipped last week with V 0.0.2 or not and if I have to update or not.

Better Approach To Keepalive

In order to conserve battery, both Badger 2040 and Badger 2040 W cut the power immediately after refreshing the display in most examples. This is great for battery life, but not so great for user experience and we haven't really considered what the right balance should be here. It has also led to bugs like #7 where user-interaction causes the power to cut abruptly and unexpectedly.

I propose a major rethink of this pattern with some key goals:

  1. Try to avoid the user having to think about battery and when to power off
  2. Allow the system to remain powered on while the user is interacting- this would make apps like List as snappy as they are on USB power
  3. Allow the system to go to sleep/power off after a period of inactivity, whereupon a new button press turns it on and reloads the last app as normal

It feels like all of the user-facing buttons should be polled somehow in the background (we could attach an interrupt for this perhaps) and any button press should ensure the 3V3_ENABLE pin is turned back on to keep power running.

Rather than having a halt in the main loop, we should probably find some means of checking if the system is busy, and cut power when it has been "idle" for a (configurable?) timeout.

I don't know quite how any of this will work but I think it's worth thinking about.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.