[chbot] Digilent ChipKit Uno32

Tue Aug 14 06:57:09 BST 2012

Please note: as I stated earlier:

Microchip had NOTHING to do with the ChipKit development which is what
that article talks about.... some people from Microchip may have
volunteered their time after hours to help with some porting... but
was nothing to do with Microchip.

It was solely developed by a company called Digilent
http://www.digilentinc.com
All Microchips efforts were halted when Digilent announced the
development of the ChipKit

Just because they used a Microchip PIC32 to develop the board does not
mean it is a Microchip product... it never was.
The software was ported by a hacker space and shifted to GitHub.

Same as calling an Arduino an Atmel Product... which it is not.

Be careful where you lay the blame.... and that Article is misleading
as it is NOT a Microchip product it is a Digilent Product.... and they
mix in so many other things which is misleading.... joys of "Open
Discussion" as facts do not have to be checked before publishing.

As far as "Lock In" Arduino was that way until Digilent stepped up and
did the real work and worked with people to port Wired to PIC32... now
you are no longer Locked into Atmel for Ardinuo products.... other
developers are also releasing ARM, ST and other based products and
using the work done by Digilent and the Hackerspace to port Wired to
those platforms using the Multi Platform I.D.E  (mpide)

As far as "Developers" are concerned the world wide majority actually
want to avoid Open source because of Major Legal issues that it
entails and has constantly caused in product development.... to a
point where may refuse to use GCC based products to even compile their
code... they would rather pay IAR or some other 3rd party to avoid
potential legal issues that could cause them to lose their IP.
Again you are confusing hobbyists with developers... a really big difference.

In the scheme of things NZ based "Developers" are more like
hobbyists... I used to be one so I know..... its a very very very
different world across the ocean.

Atmel does not and never did have a compiler.... it was users that
developed it because Atmel refused to and it is still the users that
develop it with limited help from Atmel.
You are more than welcome to do the same for any processor that you
want so don't blame vendors when they do it themselves and try and
protect their work that cost them a lot of money to do.
In saying that all of the source code for the GCC compilers that
Microchip ported is openly available if you want to build it yourself,
just not the proprietary libraries they created and optimized....
google does find them.

Also "porting" between different "ARM" based vendors is not as simple
as you make it sound... it is just as easy to port to a MIPS, TI, or
Renasas, or other vendors product, as long as you learn the
peripherals. The peripherals is where they all vary and where the work
is, and between ARM based vendors there are a lot of differences ....
If you write in assembly code all the time, which means you are not
making much money and never going to port code.

You have choices out there... if you want real vendor support then you
choose to use vendor supplied and built products.....
 if you want "Open" support then use open products which may mean no
support at all.... it all about choice.

Also you get what you pay for still applies today as it did in the past.
If you don't pay for it, don't expect it to work , and don't expect
any support and you don't have any right to complain.
If you pay for it, it should work, and you should get support, and if
it don't work you have every right to complain.

Also if you complain about Microchips Licensing then you have
obviously not looked at NXP, Freescale, TI, Intel, Atmel, Renassas,
Cypress, or any other vendor supplied source code as some of those are
just as bad, if not worse and more restrictive. i.e. the Majority
actual charge for their source code and even have licenses and
royalties, when Microchip actually give it away on the one condition
that its only use on their products since they put the large sums of
money into developing it.
Yes there is other "Open source" for those products... just like there
is plenty of open source for Microchip parts as well... all developed
by end users.
And if there is open source code for one vendor you are more than
welcome to port it to another.

P.S. I think you also confused the two different Mikes as well.

On Mon, Aug 13, 2012 at 9:50 PM, Charles Manning <cdhmanning at gmail.com> wrote:
> Mike
>
> I think you have taken a genuine concern and completely missed the point by
> going on about the hardware the way you have.
>
> Avoidance of vendor lock-in does not preclude the use of closed technologies.
> What it precludes is wedding yourself to one particular technology, be that
> one micro, one toolchain or Windows etc. in a way that prevents moving.
>
> Where this really matters in the world of micros is that once you have wed
> yourself to some variants of micros it is really hard to move to something
> else if there is a silicon bug  or supply issue.
>
> The other concern is locking in your skills. I'm getting tired of learning a
> new CPU architecture for each different family of micros.
>
> The way to avoid lock-in is to use standards etc supported by many different
> vendors.
>
> Which NOR flash should I use? I don't care, so long as it if CFI-compliant
> flash so I can switch in a different flash if required.
>
> Which hard drive should I use? Again I don't care so long as they use IDE,
> SATA or whatever.
>
> Which SD card interface? Same deal.
>
> If I develop code I want to be able to port it to other environments.
>
> I want to be able to use Linux.
>
> Which micro? Well these days my view is there better be a good reason for
> selecting anything other than ARM. One general architecture (yes, there are
> sub-architectures) and one debugger/toolchain covers everything from
> sub-dollar micros to GHz multi-cores.
>
> Sure ARM is proprietary, but it does not limit me to any one vendor. If one
> vendor does not have the parts I want, another will. Porting from one ARM
> micro to another is almost trivial. That is not lock in.
>
> Where lock in happens is when we use off-beat architectures only used by one
> vendor. PIC 8-bits for instance. At least the PIC32 is MIPS based and there
> are a few MIPS licensees, but none else with single-chip offerings, AFAIK.
>
> I share the concern about the way Microchip controls their licensing. A while
> ago I attended a conference where the Microchip people said that their tools
> were gcc based, yet they were keeping enough under wraps to prevent the goals
> of open source. Everything was tethered to the workbench. I don't know if
> they have improved since then.
>
>
> These concerns seem quite common:
>
> http://dangerousprototypes.com/2011/08/30/editorial-our-friend-microchip-and-open-source/
>
> If you are part of Microchip, I would suggest that you take on this feedback
> and pass it back to management. These are genuine concerns that alienate the
> developer community.
>
> Just arguing with people that have legitimate reasons to avoid your product is
> pointless.
>
>
>
> On Tuesday 14 August 2012 14:59:55 Michael Field wrote:
>> On 13/08/2012 9:02 p.m., Volker Kuhlmann wrote:
>>  > Well I'm not interested in vendor lock-ins and non-portability.
>>
>> This is getting completely off topic and I'm being a bit facetious, but
>> I'm trying to understand how you can reject what to me appears to be a
>> useful Arduino work-a-like with claims of "Vendor lock-ins and
>> non-portability" when in practice for anybody using the product it makes
>> zero difference
>> - any simple projects (and some complex ones) will move between boards
>> with minimal fuss.
>> - for any complex projects, if the AVR doesn't cut it, then maybe PIC32
>> is the answer. The developer understand that it will be locked to that
>> hardware
>> - Maybe it's Arduino's fault for not being portable in the first place,
>> not the PIC32's problem. (Like a bit-bashing USB HID stack is ever going
>> to be portable...)
>>
>> I'ld really like to know were you draw the line in the sand vs
>> Open/Closed...
>>
>> What hardware do you use for day-to-day computing?
>>
>> Do you frown on using 'closed' toolchains to build Open tools? Like in
>> the old days when I used HP's C compiler to build Samba?
>>
>> If you are on a 'closed' CPU? If so, do you have the microcode for it?
>> Or the VHDL design for it?
>>
>> Maybe you one of few who have a working OpenRISC system? If so, did you
>> use the vendor's closed tools to implement the design in an FPGA?
>>
>> What about licensing on DVI-D & HDMI? Is it Display Port only for you? I
>> recently implemented DVI-D/HDMI on an FPGA for my own use, and nobody
>> came knocking...
>>
>> Do you have the schematics for your PC's motherboard?
>>
>> Do you run OpenBIOS?
>>
>> Do you use TOE NICs or real RAID controllers with their own closed
>> firmware?
>>
>> What do you use for storage to avoid closed firmware on your disk
>> drives?  I've done the magic "fix your mates broken HDD with a
>> USB-to-serial adapter" https://sites.google.com/site/seagatefix/
>> allowing us to replace buggy firmware on a bricked drive... it would
>> have been so much easier if it was Open Source ;-)
>>
>> Mike
>>
>>
>> _______________________________________________
>> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
>> http://lists.ourshack.com/mailman/listinfo/chchrobotics
>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
>> Web site: http://kiwibots.org
>> Meetings 3rd Monday each month at Tait Radio Communications, 175 Roydvale
>> Ave, 6.30pm
>>
>> When replying, please edit your Subject line to reflect new content.
>
>
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Web site: http://kiwibots.org
> Meetings 3rd Monday each month at Tait Radio Communications, 175 Roydvale Ave, 6.30pm
>
> When replying, please edit your Subject line to reflect new content.