arduino 2020: features, ideas, and more …
85 views
Skip to first unread message
Phillip Torrone
Dec 30, 2019, 6:36:22 PM12/30/19
to devel...@arduino.cc
here's an arduino 2020: features, ideas, and more post as we get close to 2020. the post here, and text below:
https://blog.adafruit.com/2019/12/30/arduino-2020-features-ideas-and-more-post-yours-arduino-adafruit-arduino/
====
DOWNLOAD STATS FROM ARDUINO FOR COMMUNITY AND DEVELOPERS
Currently, there is no way (unless you work at Arduino) to get the download stats for libraries. The way the Arduino Library manager works is that once a copy is moved to Arduino, stats for developers are not available and are not published. The site: arduinolibraries.info is an attempt at that, but it can only get data from GitHub and public sources.
Having the download stats of the library you have contributed to Arduino would help software developers and community to know what’s popular, what development resources are needed, and encourage developers to contribute their libraries to Arduino. Download stats were mentioned in April of 2019. We got a top 10 from the presentation and have a post about it here.
TINYUSB SUPPORT IN ARDUINO-CORE
The Arduino low level hardware support was recently “chainsaw”-ed to make adding new hardware cores easy and keep them all compatible. TinyUSB is an open-source cross-platform USB Host/Device stack for embedded systems, and it is a perfect fit as a default USB stack (when none is provided by the hardware port). It allows developers to add USB support to their hardware quickly and easily. The supported boards include: MicroChip SAMD, Nordic nRF5x, NXP iMX RT, NXP LPC, Sony, ST STM32, Tomu and more.
If Arduino replaced the current USB stack with TinyUSB, more hardware makers and software developers would be able to contribute to the Arduino ecosystem. This would make it easier to add new chipsets, and open up the peripherals available. (For example, mass storage which is an oft-requested but unavailable class for Arduino). Best of all, the same USB interfaces would work across all ports!
UF2 BOOTLOADER SUPPORT FROM ARDUINO
UF2 is an open-source file format and bootloading specification, developed by Microsoft for PXT (also known as Microsoft MakeCode) that makes it super-easy to flash microcontrollers. It shows up as a USB drive and new/updated software can be flashed to the device eliminating much of the frustration for users. Even better you can drag existing firmware OFF the device, for backup and distribution. It solves many problems with serial port drivers/identification, tricky command line tools like bossa, and project setup.There are bootloaders for Microchip ATSAMD21 and ATSAMD51, Arduino UNO, STM32F103, STM32F4, Nordic NRF52840, Linux (RPi Zero), Cypress FX2 and more!
Microsoft has a great post about it, and check it out on GitHub.
Being able to flash devices immediately without special cables or software, and being able to run Arduino (or Python, tinyGo, uLisp, etc) on your hardware gives users the maximum choice for what they want to do. It’s the easiest way to send updates to users if they are developers or hardware makers. Arduino supporting UF2 would allow more people to contribute to the Arduino ecosystem and participate with their hardware innovations.
ARDUINO LIBRARY STANDARDS & AUTOMATION
Writing software is like gardening – the flowers are beautiful but you’re going to spend a lot of time weeding! Except instead of weeding, it’s keeping up to date with new frameworks, operating systems and dependencies. It’s a ton of work! Automation makes this easy – there are free continuous integration services like Travis and GitHub actions. It would be really great if there was an Arduino CI system check/prerequisite for inclusion into the Arduino library manager. Stuff like dependencies, clean formatting, documentation, and other ‘linting’ that could be done to promote good quality libraries and coding styles. There’s been more work on this recently, in compilation-testing, which is a great start. It would be great to have the CI script do even more common-error checking like -Wall, or clang-format.
UNIFORM TRANSFER OF STRUCTURED DATA OF UART, SPI, ETC. IN ARDUINO
Related to library standards checking with automation – it would be a great help when creating better libraries and examples if there were some lightly-structured helpers for the common bus interfaces like UART/SPI/I2C, so folks don’t have to copy-and-paste the same code over and over for transmitting data. This would be a big boon for library writers who can have small bugs slip in and also will keep code updated as the interfaces improve – for example when the I2C buffer size changes, SMBus-style register reading, bitmask twiddling, or when transactions are improved/added. Adafruit created – Adafruit_BusIO. Having a universally-available toolset would also keep hardware forks from adding or changing the bus interfaces.
SUPPORT FOR GROVE / QWIIC / STEMMA ON ARDUINO HARDWARE
On the Arduino MKR there is a 5-pin JST SH connector, with +5V, ground, and SDA/SCL. This is great because we’re definitely seeing a big shift over to I2C as its the one and only ‘universal’ interface for sensors and mainboards, it’s even supported in Linux and there’s USB to I2C adapters that cost $1.50. However, given it’s a 5V power supply not 3V, it risks having I2C pullups to 5V on the ‘client’ device if its plugged into something like a Grove sensor – or possibly trying to connect it to a non-regulated sensor and frazzling it. It’s not a big issue but it would be great if the power supply was 3V so it would work with SparkFun QWIIC, Seeed Grove, DF Robot Gravity, or Adafruit STEMMA / STEMMA QT. If everyone making breakouts would be interested in committing to a standard, it would make customers very happy!
https://blog.adafruit.com/2019/12/30/arduino-2020-features-ideas-and-more-post-yours-arduino-adafruit-arduino/
====
DOWNLOAD STATS FROM ARDUINO FOR COMMUNITY AND DEVELOPERS
Currently, there is no way (unless you work at Arduino) to get the download stats for libraries. The way the Arduino Library manager works is that once a copy is moved to Arduino, stats for developers are not available and are not published. The site: arduinolibraries.info is an attempt at that, but it can only get data from GitHub and public sources.
Having the download stats of the library you have contributed to Arduino would help software developers and community to know what’s popular, what development resources are needed, and encourage developers to contribute their libraries to Arduino. Download stats were mentioned in April of 2019. We got a top 10 from the presentation and have a post about it here.
TINYUSB SUPPORT IN ARDUINO-CORE
The Arduino low level hardware support was recently “chainsaw”-ed to make adding new hardware cores easy and keep them all compatible. TinyUSB is an open-source cross-platform USB Host/Device stack for embedded systems, and it is a perfect fit as a default USB stack (when none is provided by the hardware port). It allows developers to add USB support to their hardware quickly and easily. The supported boards include: MicroChip SAMD, Nordic nRF5x, NXP iMX RT, NXP LPC, Sony, ST STM32, Tomu and more.
If Arduino replaced the current USB stack with TinyUSB, more hardware makers and software developers would be able to contribute to the Arduino ecosystem. This would make it easier to add new chipsets, and open up the peripherals available. (For example, mass storage which is an oft-requested but unavailable class for Arduino). Best of all, the same USB interfaces would work across all ports!
UF2 BOOTLOADER SUPPORT FROM ARDUINO
UF2 is an open-source file format and bootloading specification, developed by Microsoft for PXT (also known as Microsoft MakeCode) that makes it super-easy to flash microcontrollers. It shows up as a USB drive and new/updated software can be flashed to the device eliminating much of the frustration for users. Even better you can drag existing firmware OFF the device, for backup and distribution. It solves many problems with serial port drivers/identification, tricky command line tools like bossa, and project setup.There are bootloaders for Microchip ATSAMD21 and ATSAMD51, Arduino UNO, STM32F103, STM32F4, Nordic NRF52840, Linux (RPi Zero), Cypress FX2 and more!
Microsoft has a great post about it, and check it out on GitHub.
Being able to flash devices immediately without special cables or software, and being able to run Arduino (or Python, tinyGo, uLisp, etc) on your hardware gives users the maximum choice for what they want to do. It’s the easiest way to send updates to users if they are developers or hardware makers. Arduino supporting UF2 would allow more people to contribute to the Arduino ecosystem and participate with their hardware innovations.
ARDUINO LIBRARY STANDARDS & AUTOMATION
Writing software is like gardening – the flowers are beautiful but you’re going to spend a lot of time weeding! Except instead of weeding, it’s keeping up to date with new frameworks, operating systems and dependencies. It’s a ton of work! Automation makes this easy – there are free continuous integration services like Travis and GitHub actions. It would be really great if there was an Arduino CI system check/prerequisite for inclusion into the Arduino library manager. Stuff like dependencies, clean formatting, documentation, and other ‘linting’ that could be done to promote good quality libraries and coding styles. There’s been more work on this recently, in compilation-testing, which is a great start. It would be great to have the CI script do even more common-error checking like -Wall, or clang-format.
UNIFORM TRANSFER OF STRUCTURED DATA OF UART, SPI, ETC. IN ARDUINO
Related to library standards checking with automation – it would be a great help when creating better libraries and examples if there were some lightly-structured helpers for the common bus interfaces like UART/SPI/I2C, so folks don’t have to copy-and-paste the same code over and over for transmitting data. This would be a big boon for library writers who can have small bugs slip in and also will keep code updated as the interfaces improve – for example when the I2C buffer size changes, SMBus-style register reading, bitmask twiddling, or when transactions are improved/added. Adafruit created – Adafruit_BusIO. Having a universally-available toolset would also keep hardware forks from adding or changing the bus interfaces.
SUPPORT FOR GROVE / QWIIC / STEMMA ON ARDUINO HARDWARE
On the Arduino MKR there is a 5-pin JST SH connector, with +5V, ground, and SDA/SCL. This is great because we’re definitely seeing a big shift over to I2C as its the one and only ‘universal’ interface for sensors and mainboards, it’s even supported in Linux and there’s USB to I2C adapters that cost $1.50. However, given it’s a 5V power supply not 3V, it risks having I2C pullups to 5V on the ‘client’ device if its plugged into something like a Grove sensor – or possibly trying to connect it to a non-regulated sensor and frazzling it. It’s not a big issue but it would be great if the power supply was 3V so it would work with SparkFun QWIIC, Seeed Grove, DF Robot Gravity, or Adafruit STEMMA / STEMMA QT. If everyone making breakouts would be interested in committing to a standard, it would make customers very happy!
John Paul Adrian Glaubitz
Dec 30, 2019, 6:44:16 PM12/30/19
to devel...@arduino.cc
Hi!
On 12/31/19 12:36 AM, 'Phillip Torrone' via Developers wrote:
> here's an arduino 2020: features, ideas, and more post as we get close to 2020. the post here, and text below:
> https://blog.adafruit.com/2019/12/30/arduino-2020-features-ideas-and-more-post-yours-arduino-adafruit-arduino/
I would add the Bountysource campaign to save the AVR backend in GCC [1].
GCC 11 can be expected for release in 2020/2021 when going by the timeline
of previous releases [2] and if the AVR backend isn't going to be modernized
by then, it will be removed from GCC unfortunately.
Until now, the campaign hasn't collected enough money to motivate a GCC
developer to work on the task, so it would be great if the message could
be amplified among the community so we can find more backers to make the
modernization happen.
Thanks,
Adrian
> [1] https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> [2] https://gcc.gnu.org/releases.html
On 12/31/19 12:36 AM, 'Phillip Torrone' via Developers wrote:
> here's an arduino 2020: features, ideas, and more post as we get close to 2020. the post here, and text below:
> https://blog.adafruit.com/2019/12/30/arduino-2020-features-ideas-and-more-post-yours-arduino-adafruit-arduino/
GCC 11 can be expected for release in 2020/2021 when going by the timeline
of previous releases [2] and if the AVR backend isn't going to be modernized
by then, it will be removed from GCC unfortunately.
Until now, the campaign hasn't collected enough money to motivate a GCC
developer to work on the task, so it would be great if the message could
be amplified among the community so we can find more backers to make the
modernization happen.
Thanks,
Adrian
> [1] https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> [2] https://gcc.gnu.org/releases.html
phillip torrone
Dec 30, 2019, 6:50:32 PM12/30/19
to devel...@arduino.cc
hi hi, we contacted microchip (formerly atmel) to see what they can do (sponsor a developer, submit changes, etc). they told us they are aware of this. here is what they said:
===
> We are aware of the situation, and are evaluating how critical GCC-11 support will be given that we will always maintain and support earlier versions. Preliminary discussions with our compiler team suggests that this mode change will increase the code size emits, given that these changes favor the ARM architecture more so than the AVR.
>
> I notified Arduino a few months back as well, but we haven't discussed this at length
>
> I'll update when I know more
==
cheers,
pt
> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
> To view this discussion on the web visit https://groups.google.com/a/arduino.cc/d/msgid/developers/6e79eebb-3245-a9ca-1cc3-a449ace60c1f%40googlemail.com.
===
> We are aware of the situation, and are evaluating how critical GCC-11 support will be given that we will always maintain and support earlier versions. Preliminary discussions with our compiler team suggests that this mode change will increase the code size emits, given that these changes favor the ARM architecture more so than the AVR.
>
> I notified Arduino a few months back as well, but we haven't discussed this at length
>
> I'll update when I know more
==
cheers,
pt
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
> To view this discussion on the web visit https://groups.google.com/a/arduino.cc/d/msgid/developers/6e79eebb-3245-a9ca-1cc3-a449ace60c1f%40googlemail.com.
John Paul Adrian Glaubitz
Dec 30, 2019, 6:56:42 PM12/30/19
to devel...@arduino.cc
Hi Philip!
On 12/31/19 12:50 AM, 'phillip torrone' via Developers wrote:
> ===
>> We are aware of the situation, and are evaluating how critical GCC-11 support will be given that we will always maintain and support earlier versions. Preliminary discussions with our compiler team suggests that this mode change will increase the code size emits, given that these changes favor the ARM architecture more so than the AVR.
>>
>> I notified Arduino a few months back as well, but we haven't discussed this at length
>>
>> I'll update when I know more
> ==
Thanks for sharing this message with me. I had contacted Microchip a few weeks ago regarding
this but they didn't get back to me.
I'm glad they are aware of the problem and thinking about a solution. FWIW, the conversion
of the m68k backend was successful and didn't change the size of the emitted code more than
1%.
Looking forward to what Microchip is going to do.
Adrian
On 12/31/19 12:50 AM, 'phillip torrone' via Developers wrote:
> ===
>> We are aware of the situation, and are evaluating how critical GCC-11 support will be given that we will always maintain and support earlier versions. Preliminary discussions with our compiler team suggests that this mode change will increase the code size emits, given that these changes favor the ARM architecture more so than the AVR.
>>
>> I notified Arduino a few months back as well, but we haven't discussed this at length
>>
>> I'll update when I know more
> ==
this but they didn't get back to me.
I'm glad they are aware of the problem and thinking about a solution. FWIW, the conversion
of the m68k backend was successful and didn't change the size of the emitted code more than
1%.
Looking forward to what Microchip is going to do.
Adrian
Ian Katz
Dec 30, 2019, 11:04:25 PM12/30/19
to devel...@arduino.cc
> ARDUINO LIBRARY STANDARDS & AUTOMATION
> [...]. It would be really great if there was an Arduino CI system check/prerequisite for inclusion into the Arduino library manager. Stuff like dependencies, clean formatting, documentation, and other ‘linting’ that could be done to promote good quality libraries and coding styles. There’s been more work on this recently, in compilation-testing, which is a great start. It would be great to have the CI script do even more common-error checking like -Wall, or clang-format.
One thing I wish was written in here is UNIT TESTING. Full
disclosure, I wrote a library that does unit testing + linting for CI
purposes:
https://github.com/ianfixes/arduino_ci
There is also PlatformIO that does this, which has recently been
released under some sort of free license. I honestly don't have a
preference for which one gets used, but I feel strongly that some form
of unit testing framework be officially supported (i.e. encouraged) by
the Arduino team. Compilation tests aren't really sufficient for
being able to verify that an updated dependency actually functions as
expected.
> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
> To view this discussion on the web visit https://groups.google.com/a/arduino.cc/d/msgid/developers/5F5CFB1D-86AD-4EA4-BABB-AAF63172F793%40adafruit.com.
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
Jim Leonard
Dec 30, 2019, 11:52:22 PM12/30/19
to 'John Paul Adrian Glaubitz' via Developers
> I would add the Bountysource campaign to save the AVR backend in GCC [1].
>
> GCC 11 can be expected for release in 2020/2021 when going by the timeline
> of previous releases [2] and if the AVR backend isn't going to be modernized
> by then, it will be removed from GCC unfortunately.
>
> Until now, the campaign hasn't collected enough money to motivate a GCC
> developer to work on the task, so it would be great if the message could
> be amplified among the community so we can find more backers to make the
> modernization happen.
William Westfield
Dec 31, 2019, 2:56:02 AM12/31/19
to devel...@arduino.cc
> On Dec 30, 2019, at 3:36 PM, 'Phillip Torrone' via Developers <devel...@arduino.cc> wrote:
> UF2 BOOTLOADER SUPPORT
I was wondering why the current Adafruit boards (that already support UF2) haven’t already replaced the bossa “upload” commands with something like “copy sketch.hex /Volumes/UF2name/“ or similar.
I guess the whole scheme for finding and selecting “ports” would have to change.
Do you have a vision for how that would work? Given a drive that suddenly appears, are there easy ways to tell that it’s a UF2 device rather than … anything else?
BillW/WestfW
> UF2 BOOTLOADER SUPPORT
I was wondering why the current Adafruit boards (that already support UF2) haven’t already replaced the bossa “upload” commands with something like “copy sketch.hex /Volumes/UF2name/“ or similar.
I guess the whole scheme for finding and selecting “ports” would have to change.
Do you have a vision for how that would work? Given a drive that suddenly appears, are there easy ways to tell that it’s a UF2 device rather than … anything else?
BillW/WestfW
Timon
Dec 31, 2019, 10:49:40 AM12/31/19
to 'William Westfield' via Developers
I would say that is even harder to handle and can be potentially very
annoying because many users have the setting to open up a drive when its
inserted, that would result in many file manager windows opening up and
never closing unless the users does so.
An HID upload like Teensy does it would be the better future in my
opinion. UF2 already has support for HID upload.
annoying because many users have the setting to open up a drive when its
inserted, that would result in many file manager windows opening up and
never closing unless the users does so.
An HID upload like Teensy does it would be the better future in my
opinion. UF2 already has support for HID upload.
phillip torrone
Dec 31, 2019, 1:35:02 PM12/31/19
to devel...@arduino.cc
hi hi,
for the arduino IDE we are sticking with backward compatibility for IDE uploads because the IDE works well with COM port detection and it is a little faster than UF2 drag-n-drop. UF2 is great for when you want to make a backup of existing firmware or distribute a firmware image - you drag the UF2 file to and from the MSD instead of using avrdude or bossac.
cheers,
pt
> On 31.12.2019 08:55, 'William Westfield' via Developers wrote:
>>> On Dec 30, 2019, at 3:36 PM, 'Phillip Torrone' via Developers <devel...@arduino.cc> wrote:
>>> UF2 BOOTLOADER SUPPORT
>> I was wondering why the current Adafruit boards (that already support UF2) haven’t already replaced the bossa “upload” commands with something like “copy sketch.hex /Volumes/UF2name/“ or similar.
>> I guess the whole scheme for finding and selecting “ports” would have to change.
>> Do you have a vision for how that would work? Given a drive that suddenly appears, are there easy ways to tell that it’s a UF2 device rather than … anything else?
>>
>> BillW/WestfW
for the arduino IDE we are sticking with backward compatibility for IDE uploads because the IDE works well with COM port detection and it is a little faster than UF2 drag-n-drop. UF2 is great for when you want to make a backup of existing firmware or distribute a firmware image - you drag the UF2 file to and from the MSD instead of using avrdude or bossac.
cheers,
pt
> On 31.12.2019 08:55, 'William Westfield' via Developers wrote:
>>> On Dec 30, 2019, at 3:36 PM, 'Phillip Torrone' via Developers <devel...@arduino.cc> wrote:
>>> UF2 BOOTLOADER SUPPORT
>> I was wondering why the current Adafruit boards (that already support UF2) haven’t already replaced the bossa “upload” commands with something like “copy sketch.hex /Volumes/UF2name/“ or similar.
>> I guess the whole scheme for finding and selecting “ports” would have to change.
>> Do you have a vision for how that would work? Given a drive that suddenly appears, are there easy ways to tell that it’s a UF2 device rather than … anything else?
>>
>> BillW/WestfW
> On Dec 31, 2019, at 10:49 AM, Timon <timo...@gmail.com> wrote:
> I would say that is even harder to handle and can be potentially very annoying because many users have the setting to open up a drive when its inserted, that would result in many file manager windows opening up and never closing unless the users does so.
> An HID upload like Teensy does it would be the better future in my opinion. UF2 already has support for HID upload.
> I would say that is even harder to handle and can be potentially very annoying because many users have the setting to open up a drive when its inserted, that would result in many file manager windows opening up and never closing unless the users does so.
> An HID upload like Teensy does it would be the better future in my opinion. UF2 already has support for HID upload.
Adrian Godwin
Dec 31, 2019, 1:57:17 PM12/31/19
to devel...@arduino.cc
On Tue, Dec 31, 2019 at 6:35 PM 'phillip torrone' via Developers <devel...@arduino.cc> wrote:
SUPPORT FOR GROVE / QWIIC / STEMMA ON ARDUINO HARDWARE
On the Arduino MKR there is a 5-pin JST SH connector, with +5V, ground, and SDA/SCL. This is great because we’re definitely seeing a big shift over to I2C as its the one and only ‘universal’ interface for sensors and mainboards, it’s even supported in Linux and there’s USB to I2C adapters that cost $1.50. However, given it’s a 5V power supply not 3V, it risks having I2C pullups to 5V on the ‘client’ device if its plugged into something like a Grove sensor – or possibly trying to connect it to a non-regulated sensor and frazzling it. It’s not a big issue but it would be great if the power supply was 3V so it would work with SparkFun QWIIC, Seeed Grove, DF Robot Gravity, or Adafruit STEMMA / STEMMA QT. If everyone making breakouts would be interested in committing to a standard, it would make customers very happy!
I'm not sure how convinced I am about Grove and similar. They seem like a neat idea that's been taken past the point of usefulness. Sure, there are plenty of sensors that are useful in a 3v and I2C only form. But the 5V is usually provided by a fairly tough USB or a big regulator. 3v3 tends to have more restricted current available. So you can cheaply - and with some advantage - provide a 3v3 regulator onboard but if you need 5V it's a nuisance to generate it.
My real problem, though, is with the limitations of the 4-wire chained bus. If you want to use more than one sensor of the same type - a very common requirement outside of initial experimentation - then they're typically on the same address. Some, like the BMP280, can be configured with a link on the breakout board. Others, like the VL53L0X, need an active reset line to reconfigure them (or a dedicated i2c bus which is not usually available).
So I'll be sad to see the majority of quick and convenient breakout boards going this way. It's too limiting.
phillip torrone
Dec 31, 2019, 3:36:08 PM12/31/19
to devel...@arduino.cc
hi hi,
all the plug-n-play sensors we've seen also have pin breakouts for all the interrupts, SPI, etc. beginners can get started fast, and experts can add any capability they like.
our request:
the I2C host is to provide 5V power, it should also provide level shifting protection on the I2C lines as stemma QT and grove have 3V regulators on board, qwiic boards do not.
cheers,
pt
all the plug-n-play sensors we've seen also have pin breakouts for all the interrupts, SPI, etc. beginners can get started fast, and experts can add any capability they like.
our request:
the I2C host is to provide 5V power, it should also provide level shifting protection on the I2C lines as stemma QT and grove have 3V regulators on board, qwiic boards do not.
cheers,
pt
Mikal Hart
Dec 31, 2019, 4:05:18 PM12/31/19
to devel...@arduino.cc
]
-------- Original message --------
From: 'phillip torrone' via Developers <devel...@arduino.cc>
Date: 12/31/19 13:36 (GMT-07:00)
Subject: Re: [Developers] arduino 2020: features, ideas, and more …
all the plug-n-play sensors we've seen also have pin breakouts for all the interrupts, SPI, etc. beginners can get started fast, and experts can add any capability they like.
our request:
the I2C host is to provide 5V power, it should also provide level shifting protection on the I2C lines as stemma QT and grove have 3V regulators on board, qwiic boards do not.
cheers,
pt
>> From: Adrian Godwin <artg...@gmail.com>
>> Subject: Re: [Developers] arduino 2020: features, ideas, and more …
>> Date: December 31, 2019 at 1:57:02 PM EST
>> To: devel...@arduino.cc
>> Reply-To: devel...@arduino.cc
>>
>>
>> On Tue, Dec 31, 2019 at 6:35 PM 'phillip torrone' via Developers <devel...@arduino.cc> wrote:
>> SUPPORT FOR GROVE / QWIIC / STEMMA ON ARDUINO HARDWARE
>> On the Arduino MKR there is a 5-pin JST SH connector, with +5V, ground, and SDA/SCL. This is great because we’re definitely seeing a big shift over to I2C as its the one and only ‘universal’ interface for sensors and mainboards, it’s even supported in Linux and there’s USB to I2C adapters that cost $1.50. However, given it’s a 5V power supply not 3V, it risks having I2C pullups to 5V on the ‘client’ device if its plugged into something like a Grove sensor – or possibly trying to connect it to a non-regulated sensor and frazzling it. It’s not a big issue but it would be great if the power supply was 3V so it would work with SparkFun QWIIC, Seeed Grove, DF Robot Gravity, or Adafruit STEMMA / STEMMA QT. If everyone making breakouts would be interested in committing to a standard, it would make customers very happy!
>> I'm not sure how convinced I am about Grove and similar. They seem like a neat idea that's been taken past the point of usefulness. Sure, there are plenty of sensors that are useful in a 3v and I2C only form. But the 5V is usually provided by a fairly tough USB or a big regulator. 3v3 tends to have more restricted current available. So you can cheaply - and with some advantage - provide a 3v3 regulator onboard but if you need 5V it's a nuisance to generate it.
>>
>> My real problem, though, is with the limitations of the 4-wire chained bus. If you want to use more than one sensor of the same type - a very common requirement outside of initial experimentation - then they're typically on the same address. Some, like the BMP280, can be configured with a link on the breakout board. Others, like the VL53L0X, need an active reset line to reconfigure them (or a dedicated i2c bus which is not usually available).
>>
>> So I'll be sad to see the majority of quick and convenient breakout boards going this way. It's too limiting.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
To view this discussion on the web visit https://groups.google.com/a/arduino.cc/d/msgid/developers/01E309F9-7167-4C7A-87CA-9F23A3879A8A%40adafruit.com.
phillip torrone
Jan 2, 2020, 2:32:50 PM1/2/20
to devel...@arduino.cc
> On Dec 31, 2019, at 4:05 PM, Mikal Hart <mh...@sundial.com> wrote:
> ]
an update, here is the video version from our show last night that has this as well.
https://youtu.be/-oKohL8tW-k
cheers,
pt
phillip torrone
Sep 9, 2021, 6:22:59 PM9/9/21
to devel...@arduino.cc
update! we got to this one... would be great if this was an official arduino standard for developers to use, especially given the large number of board support packages out there ...
https://blog.adafruit.com/2021/09/09/adafruit_busio-ification-for-prettier-easier-to-maintain-arduino-libraries/
https://blog.adafruit.com/2021/09/09/adafruit_busio-ification-for-prettier-easier-to-maintain-arduino-libraries/
Rob Tillaart
Sep 10, 2021, 3:21:12 AM9/10/21
to Arduino Developers
+1
Maintaining a few libs myself I recognize the need for the higher level I2C and SPI interfaces.
I might say I have quite some duplicate code in my libs regarding IO.
Need to investigate the impact of a port on my libs and the effort it will take (probably an action for the long winter evenings)
I might say I have quite some duplicate code in my libs regarding IO.
Need to investigate the impact of a port on my libs and the effort it will take (probably an action for the long winter evenings)
.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
To view this discussion on the web visit https://groups.google.com/a/arduino.cc/d/msgid/developers/5959153F-47E1-47EA-85F5-EA88ED43BD55%40adafruit.com.
Graynomad
Sep 15, 2021, 1:43:53 AM9/15/21
to Developers, p...@adafruit.com
RE:
SUPPORT FOR GROVE / QWIIC / STEMMA ON ARDUINO HARDWARE
Did anything ever come of this? If so does anyone have some info because I can't find anything.
Rob
PS. I haven't used this group for years, I hope I pressed the right reply button :)
On Tuesday, 31 December 2019 at 09:36:22 UTC+10 p...@adafruit.com wrote:
here's an arduino 2020: features, ideas, and more post as we get close to 2020. the post here, and text below:
https://blog.adafruit.com/2019/12/30/arduino-2020-features-ideas-and-more-post-yours-arduino-adafruit-arduino/
...
phillip torrone
Sep 15, 2021, 10:26:57 AM9/15/21
to Graynomad, Developers
> On Sep 15, 2021, at 1:43 AM, Graynomad <r...@robgray.com> wrote:
> RE: SUPPORT FOR GROVE / QWIIC / STEMMA ON ARDUINO HARDWARE
> Did anything ever come of this? If so does anyone have some info because I can't find anything.
arduino has not adopted any compatible qwiic/stemma connectors.
the MKR board(s) and the PRO boards have a connector that looks like qwiic/stemma, but it's a battery connector (and there is another connector called "ESLOV") which is "Arduino's open connector standard for self-identifiable hardware"
https://store.arduino.cc/products/arduino-mkr-wifi-1010
there is a kickstarter from 2016 that seems to have some hardware that was not published or released?
https://www.kickstarter.com/projects/iot-invention-kit/eslov-iot-invention-kit
adafruit has a cable that connects MKR boards to stemma/qwiic boards (5-pin (Arduino MKR) to 4-pin JST SH STEMMA QT / Qwiic Cable) -
https://www.adafruit.com/product/4483
arduino has a MKR - grove connector carrier:
https://store-usa.arduino.cc/products/arduino-mkr-connector-carrier-grove-compatible
cheers,
pt
Graynomad
Sep 15, 2021, 6:55:38 PM9/15/21
to Developers, p...@adafruit.com, Developers, Graynomad
Thanks for all that info. So the short answer is no then :) Just basically a heap of adapters.
Amazing that Eslov didn't take off with all that work done and Arduino behind it.
I'm developing a small base/carrier board for the Adafruit Itsy Bitsy M4, it has addressable daughter boards and a somewhat unique way to attach expansion modules, but I also want to have a "standard" I2C-style interface, unfortunately it seems that there is no such thing, so I think I will add two qwicc/stemma-qt connecters with an optional extra pin for interrupts or maybe other user purposes. As for 5 or 3 volts, not sure yet, there are obvious pros and cons either way.
The DF Robot Gravity has a lot of boards as well, but try as I might I can find no spec for that system. It's as though they make it deliberately difficult/impossible to find, maybe it's not open source.
I'm developing a small base/carrier board for the Adafruit Itsy Bitsy M4, it has addressable daughter boards and a somewhat unique way to attach expansion modules, but I also want to have a "standard" I2C-style interface, unfortunately it seems that there is no such thing, so I think I will add two qwicc/stemma-qt connecters with an optional extra pin for interrupts or maybe other user purposes. As for 5 or 3 volts, not sure yet, there are obvious pros and cons either way.
Rob
phillip torrone
Sep 15, 2021, 7:28:12 PM9/15/21
to Graynomad, Developers
sounds good - two JST SH connectors with qwiic/qt compatibility will work very well, and use 3V power/logic since some folks make boards without level shifters or regulators.
cheers,
pt
cheers,
pt
Graynomad
Sep 15, 2021, 11:24:42 PM9/15/21
to Developers, p...@adafruit.com, Developers, Graynomad
OK, yeah I think I'm happy to stick with 3v3. I now see that PiicoDev has the same pinout as well, that's three mobs that are the same so I'll stick with that. The difference might be that I add a 5th pin for interrupts, but that doesn't make mine incompatible as long as the extra signal is at one end or the other. I can place a footprint that allows both connectors.
Rob
Reply all
Reply to author
Forward
0 new messages