Re: [Developers] About board design decisions
41 views
Skip to first unread message
Paul Stoffregen
Jul 15, 2015, 9:23:06 AM7/15/15
to devel...@arduino.cc
On 07/14/2015 07:01 PM, Massimo Banzi wrote:
> We actually use only 2 now Micro and B. We’re migrating legacy
> products to micro
Within a year, maybe even sooner, we'll be having this conversation all
over again, with USB type C.
>> Now that we're talking about the *U2, how was adding that (compared to
>> FT232RL) a reduction of complexity? It added a new firmware to the
>> system and i dont have much good to say of the default one.
>> Btw, if you happen to know the author/maintainer of it there's a
>> thread on this ML (started by me) you could point them to (hint hint).
> the 16U2 allowed us to remove the step of installing the FTDI drivers on mac and Win. Currently on windows we just need an .inf file ...
The INF issue is likely to soon become a relic of the past.
With Windows 10 (at least TP build 9860... the last I actually tested),
Microsoft finally bundled a generic Compatible-Id matching INF with
Windows. They also fixed a long-standing bug in the USBSER.SYS driver
which impacts all Arduino Uno & Leonardo (and Teensy) boards. Phil
Torrone of Adafruit deserves credit for getting the attention of the
right people at Microsoft a couple years ago. This video was the
turning point that got them to recognize and reproduce and finally fix
the bug: https://www.youtube.com/watch?v=DRmvUsa2xuU
USB enumeration delays also seemed to be greatly improved in Windows 10,
perhaps even on par with Linux and Macintosh.
With Windows 10 officially releasing at the end of this month, this
moment hardly seems like the best time to consider design changes based
on usability issues with older versions of Windows!
> We are at the beginning of a process of migrating libraries to avoid
> direct access to registers so that they can be easily ported between
> processors. Migrating part of the community to ARM 32bit and Intel
> 32bit is a journey and we’ve just started it.
Massimo, we should really talk more about this!
I contributed the hardware abstraction layers that currently exist in
many of the well known libraries, including Servo, Firmata,
SoftwareSerial, IRremote, OneWire, CapacitiveSensor, etc.
Since at least 2009 I've wanted to contribute better hardware
abstractions to Arduino's official API. But considering such
substantial APIs has always been extremely difficult.... contributing
custom-made abstractions to every widely used library has historically
been the easier and more achievable path. The unfortunate result is a
high barrier to new boards achieving complete "Arduino compatibility"
when the many widely used libraries are included in the notion of
compatibility.
> We actually use only 2 now Micro and B. We’re migrating legacy
> products to micro
Within a year, maybe even sooner, we'll be having this conversation all
over again, with USB type C.
>> Now that we're talking about the *U2, how was adding that (compared to
>> FT232RL) a reduction of complexity? It added a new firmware to the
>> system and i dont have much good to say of the default one.
>> Btw, if you happen to know the author/maintainer of it there's a
>> thread on this ML (started by me) you could point them to (hint hint).
> the 16U2 allowed us to remove the step of installing the FTDI drivers on mac and Win. Currently on windows we just need an .inf file ...
The INF issue is likely to soon become a relic of the past.
With Windows 10 (at least TP build 9860... the last I actually tested),
Microsoft finally bundled a generic Compatible-Id matching INF with
Windows. They also fixed a long-standing bug in the USBSER.SYS driver
which impacts all Arduino Uno & Leonardo (and Teensy) boards. Phil
Torrone of Adafruit deserves credit for getting the attention of the
right people at Microsoft a couple years ago. This video was the
turning point that got them to recognize and reproduce and finally fix
the bug: https://www.youtube.com/watch?v=DRmvUsa2xuU
USB enumeration delays also seemed to be greatly improved in Windows 10,
perhaps even on par with Linux and Macintosh.
With Windows 10 officially releasing at the end of this month, this
moment hardly seems like the best time to consider design changes based
on usability issues with older versions of Windows!
> We are at the beginning of a process of migrating libraries to avoid
> direct access to registers so that they can be easily ported between
> processors. Migrating part of the community to ARM 32bit and Intel
> 32bit is a journey and we’ve just started it.
Massimo, we should really talk more about this!
I contributed the hardware abstraction layers that currently exist in
many of the well known libraries, including Servo, Firmata,
SoftwareSerial, IRremote, OneWire, CapacitiveSensor, etc.
Since at least 2009 I've wanted to contribute better hardware
abstractions to Arduino's official API. But considering such
substantial APIs has always been extremely difficult.... contributing
custom-made abstractions to every widely used library has historically
been the easier and more achievable path. The unfortunate result is a
high barrier to new boards achieving complete "Arduino compatibility"
when the many widely used libraries are included in the notion of
compatibility.
Andrew Kroll
Jul 15, 2015, 8:40:10 PM7/15/15
to devel...@arduino.cc
The NUY is one of these (cough) ;-)
There are others though. They usually include one of the following:- NRF24L1
- zigbee
- bluetooth
On Tue, Jul 14, 2015 at 9:11 PM, Massimo Banzi <m.b...@arduino.cc> wrote:
The holes are there. We simply didn’t mount the 6pin connector on the 16U2 on the first batch of US UNOs
What shields are you referring to? Link? :)
m
> On 15 Jul 2015, at 00:36, Andrew Kroll <xxx...@gmail.com> wrote:
>
> One other point on the missing header...
> There are shields, some of which are in beta, some of which are available now, that actually require that reset is held low on the 16u2 in order to disable it and allow the shield to program the board. This includes various WiFi and Bluetooth shields that provide OTA firmware uploads to the MCU board. You simply pop on a jumper cap to accomplish this. Could not be any easier.
>
> If the actual header holes are there for you to supply your own pins, that is fine and dandy, and I can live with that.
>
> If the capability has been removed, then we have a major problem, and not including it for at least the OTA uploading case is a huge mistake IMHO. Lets not even get into the ability to be able to make the 16u2 appear as an entirely different device, which goes without saying, happens to be very very handy.
>
>
--
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.
--
Reply all
Reply to author
Forward
0 new messages