• Content Count

  • Joined

  • Last visited

About adafruit

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ok - hopefully its sustainable now we've split chip/board definitions so if its an allwinner chip, we can recycle that collection of pins to create a large variety of boards
  2. @TonyMac32you can start a PR here theres no magic way to detect, we wish there was a mix of grepping files usually gets ya there
  3. hiya @lanefu - thank you! more armbian boards are welcome (i had an orangepi on hand) if anyone would like to add support for their boards - we have libgpiod for easy-gpio control and use spidev/smbus for i2c/spi so adding other chips and boards is less than a day of effort we can help and mentor if you're not sure how - please open an issue or create a PR here your devboard will get access to nearly 150 drivers and libraries - from OLEDs to sensors to LoRa radios - and more always on the way
  4. @chwe hiya restructuring PR's that don't break all the tests are welcome, we aren't experts at structuring code like you are if there's some other cross-platform detection suite, we'd use that instead please let us know if you can help us with code restructuring!
  5. we will be supporting ESP8266 and ESP32 as co-processors -
  6. hiya - we wanted an easy and extensible way to support the large # of various linux boards - and doing it this way means very little effort for a big outcome! we've got 125 libraries and drivers, having them all work on any computer would avoid duplication of effort and MORE COOL HARDWARE being built
  7. we've updated the library structure, @chwe wanna take another look?
  8. sounds good, yeah we're still working out the platform detection stuff, your structure looks good! we also will be adding 96boards support so that's a whole 'nother collection of mysteries for ESP32, blinka will probably work, we just haven't tested it. we'll probably go back to that after getting linux sorted out
  9. hiya - yes circuitpython is originally designed to run on small microcontrollers. as we've ported over 100 drivers, libraries and helpers, the light-but-complete API can also be really great for Python 3 computers. that way people can start a project on smaller chips, then 'upgrade' to a SBC when they want video, mp3, full tcpip stack. or they can just take advantage of all the drivers to make IoT SBC with sensors we sorted out the API about 2 years ago when we started circuitpython, and have been hacking on adding the Py3 support layer over the last few months. the translation layer repository is here the new platform detection repo is here - it will be replacing the current platform detection.
  10. gpio is libgpiod i2c is direct ioctls spi is spidev
  11. thanks folks - if y'all can help with getting the uart/spi emabled (sounds like its possible), we will do all the documentation so people can use the odroid c2 w/armbian with a wide variety of gpio/spi/uart/i2c devices including parts like DHT sensors, gps, servos, IR, etc. good for home automation, IoT, etc! that will relieve ya'll from trying to do that kind of support.
  12. ooh ok didnt realize the image was a full image, thought you meant a kernel image yeah i can't run the `gpio readall` program that would normally give me the MUX data so no idea what anything is set up as. serial might not be muxed right. all very mysteirous
  13. hiya, bitbang SPI is just fine, as long as its a device. i think i'll wait till the kernel's in a downloadable image - hopefully soon for the uart, there's ttyAML0, but that's attached to the console? its the 4 pin header at the edge called UART right? pi@odroidc2:~$ dmesg | grep tty [ 0.000275] console [tty0] enabled [ 0.565504] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 13, base_baud = 1500000) is a meson_uart [ 0.565540] console [ttyAML0] enabled we want to access the uart on the 40 pin connector, e.g. the non-console UART this documentation sorta implies its on ttyS1 and no other details :/
  14. exciting! i just bumped into this trying to port CircuitPython to odroid C2. i2c exists and works, and no spidev even when i modprobe.. root@odroidc2:/home/pi# uname -a Linux odroidc2 4.18.8-odroidc2 #244 SMP PREEMPT Tue Sep 18 18:33:22 CEST 2018 aarch64 GNU/Linux do you know what release i need to look for, when this will be included - like what the release would be called/numbered? cause that would be way faster than bitbanging in python also, somewhat relatedly, the onboard uart /dev/ttyS1 isn't working either, device exists but can't open it :/ root@odroidc2:/home/pi# cat import serial ser = serial.Serial('/dev/ttyS1') # open serial port print( # check which port was really used ser.write(b'hello') # write a string ser.close() # close port running it ... root@odroidc2:/home/pi# python3 Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/serial/", line 323, in _reconfigure_port orig_attr = termios.tcgetattr(self.fd) termios.error: (5, 'Input/output error') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 3, in <module> ser = serial.Serial('/dev/ttyS1') # open serial port File "/usr/local/lib/python3.5/dist-packages/serial/", line 240, in __init__ File "/usr/local/lib/python3.5/dist-packages/serial/", line 272, in open self._reconfigure_port(force_update=True) File "/usr/local/lib/python3.5/dist-packages/serial/", line 326, in _reconfigure_port raise SerialException("Could not configure port: {}".format(msg)) serial.serialutil.SerialException: Could not configure port: (5, 'Input/output error') but all the documentation for this board says it should 'just work' with kernels 3.x - not sure if this also broke in 4.x