Skip to content

Instantly share code, notes, and snippets.

@ktemkin
Last active February 6, 2023 19:49
Show Gist options
  • Save ktemkin/4ce1dae9d6172a88764d2ff29f929614 to your computer and use it in GitHub Desktop.
Save ktemkin/4ce1dae9d6172a88764d2ff29f929614 to your computer and use it in GitHub Desktop.
# Creating a GreatFET object implicitly opens the USB connection to the device.
try:
device = GreatFET() # Optionally accepts serialNo= to select between multiple GreatFETs.
except DeviceNotFoundException:
print("No device found!")
sys.exit()
# Once a connection is made, the board's ID is queried, and used to make the board's peripherals available.
# (This either would be a factory method that produces an appropriate class, or a run-time mixin.)
# For now, this would mean that objects are present on 'device' that allow access to each of the Azalea board's peripherals.
#As an example, we might prod the device's raw GPIO:
device.gpio.set('LED1', 1)
# Example: reprogramming the board's onboard SPI flash with a new version of the firmware.
with open('my_new_firmware.bin','r') as firmware_file:
my_new_firmware = f.read()
device.onboard_flash.write(my_new_firmware, address=0)
# Example: It might be desirable to add neighbor functionality, simulating runtime extension of a class
# via Ruby-like mixins. This helps to keep our code nicely partitioned, so we don't have a giant GreatFET object
# that can do everything, or force the user into weird inheritance patterns or odd collections of separate objects.
device.add_neighbor(GreatFETCrocus)
device.crocus.crocus_specific_function("argument") #crocus object is created dynamically by add_neighbor for our use
# It would be nice and user-friendly to track which resources a given neighbor is claiming,
# so we can warn the user (or throw an error) if two neighbors try to claim the same resources/pins/I2C addresses.
# (This could be accomplished by having each neighbor call functions that mark resources as used as they're created,
# so the core GreatFET object can keep track.)
device.add_neighbor(TheoreticalDeviceUsingI2CAddress0x30);
device.add_neighbor(DifferentTheoreticalDeviceUsingI2CAddress0x30);
# Ideally, we'd produce an error message here explaining that these neighbors conflict, and suggesting a possible
# solution-- e.g. tweaking jumpers on the boards to re-assign one of their I2C addresses.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment