--- In 68HC12@68HC..., "Jefferson Smith" <imajeff84663@y...>
> Eclipse... that's the effor to cover that
end, except I guess Java
> itself might never be really Open Source.
There are many open source implementations of the Java compiler (Jikes
is the best known) and the JVM, but Sun won't allow any commercial
competition. Sun almost made Java an open standard, but they changed
their mind and didn't do it.
It's my understanding that Sun allows open source implementations that
have a licensing model that forbids commercial sales.
Microsoft's C# language and their CLR are open standards, so anyone
can give away their own tools, or sell them with no royalties to
Microsoft.
hc12mem v1.1
Started by ●November 17, 2005
Reply by ●November 23, 20052005-11-23
Reply by ●November 23, 20052005-11-23
Comments below.
On Wed, 2005-11-23 at 03:43 +0000, Eric Engler wrote:
> --- In 68HC12@68HC..., "Jefferson Smith" <imajeff84663@y...>
>
> > Eclipse... that's the effor to cover that end, except I guess Java
> > itself might never be really Open Source.
We can get by with Java not being open source. Fedora has a version as
does IBM.
> There are many open source implementations of the Java compiler (Jikes
> is the best known) and the JVM, but Sun won't allow any commercial
> competition. Sun almost made Java an open standard, but they changed
> their mind and didn't do it.
>
> It's my understanding that Sun allows open source implementations that
> have a licensing model that forbids commercial sales.
???? In order for Java to be something, Sun needs it to run on other
platforms and for that to happen, it must share.
> Microsoft's C# language and their CLR are open standards, so anyone
> can give away their own tools, or sell them with no royalties to
> Microsoft.
C# is an attempt by Microsoft to lock people in to Microsoft products.
C# isn't an open standard. Ask people on the mono team.
--
Kim Lux, Diesel Research Inc.
On Wed, 2005-11-23 at 03:43 +0000, Eric Engler wrote:
> --- In 68HC12@68HC..., "Jefferson Smith" <imajeff84663@y...>
>
> > Eclipse... that's the effor to cover that end, except I guess Java
> > itself might never be really Open Source.
We can get by with Java not being open source. Fedora has a version as
does IBM.
> There are many open source implementations of the Java compiler (Jikes
> is the best known) and the JVM, but Sun won't allow any commercial
> competition. Sun almost made Java an open standard, but they changed
> their mind and didn't do it.
>
> It's my understanding that Sun allows open source implementations that
> have a licensing model that forbids commercial sales.
???? In order for Java to be something, Sun needs it to run on other
platforms and for that to happen, it must share.
> Microsoft's C# language and their CLR are open standards, so anyone
> can give away their own tools, or sell them with no royalties to
> Microsoft.
C# is an attempt by Microsoft to lock people in to Microsoft products.
C# isn't an open standard. Ask people on the mono team.
--
Kim Lux, Diesel Research Inc.
Reply by ●November 23, 20052005-11-23
--- In 68HC12@68HC..., "Eric Engler" <englere.geo@y...>
wrote:
>
> --- In 68HC12@68HC..., "Jefferson Smith" <imajeff84663@y...>
>
> > Eclipse... that's the effor to cover that end, except I guess Java
> > itself might never be really Open Source.
>
> There are many open source implementations of the Java compiler (Jikes
> is the best known) and the JVM, but Sun won't allow any commercial
> competition. Sun almost made Java an open standard, but they changed
> their mind and didn't do it.
>
> It's my understanding that Sun allows open source implementations that
> have a licensing model that forbids commercial sales.
I've seen some worrying about whether Sun will fight open source. But
to me the problem is proving (or certifying) the Java compatibility.
What I've tried in the past didn't come close to the same. Since being
the same is the whole purpose of Java, it must be exactly the same
(execution results, anyway).
>
> --- In 68HC12@68HC..., "Jefferson Smith" <imajeff84663@y...>
>
> > Eclipse... that's the effor to cover that end, except I guess Java
> > itself might never be really Open Source.
>
> There are many open source implementations of the Java compiler (Jikes
> is the best known) and the JVM, but Sun won't allow any commercial
> competition. Sun almost made Java an open standard, but they changed
> their mind and didn't do it.
>
> It's my understanding that Sun allows open source implementations that
> have a licensing model that forbids commercial sales.
I've seen some worrying about whether Sun will fight open source. But
to me the problem is proving (or certifying) the Java compatibility.
What I've tried in the past didn't come close to the same. Since being
the same is the whole purpose of Java, it must be exactly the same
(execution results, anyway).
Reply by ●November 23, 20052005-11-23
witam Michal
czy moglbys mi wyslac swoj programator do hc 12 ??
ja urzywam tylko do programowania eeprom
czy potrzebny jest jakis specjalny interfejs ??
jak bys ml podaj mi sw nr telefonu bo chcialbym z toba porozmawiac
pozdrawiam radek
----- Original Message -----
From: "Michal Konieczny" <mk@mk@....>
To: <68HC12@68HC...>
Sent: Saturday, November 19, 2005 11:57 AM
Subject: Re: [68HC12] Re: hc12mem v1.1 > > I've already got C# code for the serial monitor but I need to polish
> > it a bit more. I want to establish an open standard for low-level
> > drivers so people can plug different drivers into different IDEs. My
> > first release will be within 2 months, I hope.
> >
> > I think 2006 will see some major developments in free tools for the
> > hc12 family. I am expecting someone to provide Eclipse support (which
> > uses Java) for this platform (I don't know who, but it's inevitable),
> > and I'll be approaching this arena from the .NET side.
>
> Great effort !
> But all this .NET is targeting mainly windows, and this leaves all free
> operating systems somewhat in a shadow, again and again.
> As an additional note, there're two types of programmers: ones that use
> flashy IDEs, with all these wizards, project managers, auto-this,
> automagic-that, sometimes more often using mouse than typing on the
> keyboard.
> And there're "old school" programmers, that use emacs or some other
> "just editor" of choice, Makefiles and command line tools, and consider
> such environment as homeland. Don't forget about us :)
>
> Back to the matter - I'm slowly approaching mentally making my program
> some kind of a "plugin" for gdb, that will enable adding support for
> more target connections (especially various bdm pods) much more easily
> than putting support code directly into main gdb source tree - to do it
> externally to gdb. I see that we have many common things to think about.
> If you could describe me the architecture of your project (I'm real
> stranger to all these IDEs), especially what components are involved and
> how it all works, maybe we can share some work. But for this, I think we
> can move off this list, to private email.
>
> Best regards,
>
> --
> Michal Konieczny
> mk@mk@.... >
>
> Yahoo! Groups Links >
>
czy moglbys mi wyslac swoj programator do hc 12 ??
ja urzywam tylko do programowania eeprom
czy potrzebny jest jakis specjalny interfejs ??
jak bys ml podaj mi sw nr telefonu bo chcialbym z toba porozmawiac
pozdrawiam radek
----- Original Message -----
From: "Michal Konieczny" <mk@mk@....>
To: <68HC12@68HC...>
Sent: Saturday, November 19, 2005 11:57 AM
Subject: Re: [68HC12] Re: hc12mem v1.1 > > I've already got C# code for the serial monitor but I need to polish
> > it a bit more. I want to establish an open standard for low-level
> > drivers so people can plug different drivers into different IDEs. My
> > first release will be within 2 months, I hope.
> >
> > I think 2006 will see some major developments in free tools for the
> > hc12 family. I am expecting someone to provide Eclipse support (which
> > uses Java) for this platform (I don't know who, but it's inevitable),
> > and I'll be approaching this arena from the .NET side.
>
> Great effort !
> But all this .NET is targeting mainly windows, and this leaves all free
> operating systems somewhat in a shadow, again and again.
> As an additional note, there're two types of programmers: ones that use
> flashy IDEs, with all these wizards, project managers, auto-this,
> automagic-that, sometimes more often using mouse than typing on the
> keyboard.
> And there're "old school" programmers, that use emacs or some other
> "just editor" of choice, Makefiles and command line tools, and consider
> such environment as homeland. Don't forget about us :)
>
> Back to the matter - I'm slowly approaching mentally making my program
> some kind of a "plugin" for gdb, that will enable adding support for
> more target connections (especially various bdm pods) much more easily
> than putting support code directly into main gdb source tree - to do it
> externally to gdb. I see that we have many common things to think about.
> If you could describe me the architecture of your project (I'm real
> stranger to all these IDEs), especially what components are involved and
> how it all works, maybe we can share some work. But for this, I think we
> can move off this list, to private email.
>
> Best regards,
>
> --
> Michal Konieczny
> mk@mk@.... >
>
> Yahoo! Groups Links >
>
Reply by ●November 27, 20052005-11-27
> Any idea what part of HC11/HC12 programming is not supported by
> Eclipse/CDT already? I've been developing with it for a year with HC12
> and it works great.
>
no debugging, no terminal window, no automatic creation of make files
and linker script files.
It probably wouldn't be too hard to add a terminal window, but I
haven't seen if anyone has done this yet.
The debugger is the hard part, but there's an open source driver for
ARM RDI commands for gdb, and a nice visual integration to make it
easy to use. If I were doing a port of Eclipse I'd look at this ARM
oriented solution to act as a starting point.
RDI commands are just debugging API commands provided by Windows DLLs
that communicate with the JTAG port (basically similar to a BDM port,
but it's more complicated because the ARM EmbeddedICE module is harder
to work with). This is the only work needed to make the hc12 port -
just implement the RDI style commands for BDM devices. You'd only need
a subset to make it work reasonably well.
There is no standard Windows/linux API for debuggers that work with
BDM devices yet (nothing like RDI; note that RDI is a proprietary
standard), but we should create an open standard and work towards
interoperability for various open source tools.
Eric
Reply by ●November 27, 20052005-11-27
--- In 68HC12@68HC..., Kim Lux <lux@d...> wrote:
> > Microsoft's C# language and their CLR are open standards, so anyone
> > can give away their own tools, or sell them with no royalties to
> > Microsoft.
>
> C# is an attempt by Microsoft to lock people in to Microsoft products.
> C# isn't an open standard. Ask people on the mono team.
I am well aware of these issues the mono team has with Microsoft, but
frankly, they've overstepped the bounds of the open tools and have
tried doing open implementations of Microsoft proprietary tools.
The full C# language (including all the latest enhancements such as
generics) is fully open and documented as ECMA standard 334. The
Common Language Infrastructure (runtime) is open and documented as
ECMA standard 335. No company or individual can ever be sued for
implementing their own tools based on ECMA standards.
http://www.dina.kvl.dk/~sestoft/ecma/
Some of the higher level libraries are not open standards, and
recently the mono team has been looking at writing an open source
version of Indigo (the Windows Communications Foundation layer for the
new Windows Vista line). This is an advanced method of handling
remoting and web services that is NOT an open standard.
I strongly support a company's right to have some proprietary code
because that pays the salaries of their employees. If Microsoft gave
away all of their standards, then there would be no Microsoft.
Similarly, Freescale has given us the source code for the serial
monitor, but not for d-bug12. Like you, I really wish they'd give us
the code for d-bug12, but I support their right to keep it closed if
they choose to do so. Maybe this is a poor analogy, but I'm trying to
say that many companies have trade secrets and open secrets.
Eric
> > Microsoft's C# language and their CLR are open standards, so anyone
> > can give away their own tools, or sell them with no royalties to
> > Microsoft.
>
> C# is an attempt by Microsoft to lock people in to Microsoft products.
> C# isn't an open standard. Ask people on the mono team.
I am well aware of these issues the mono team has with Microsoft, but
frankly, they've overstepped the bounds of the open tools and have
tried doing open implementations of Microsoft proprietary tools.
The full C# language (including all the latest enhancements such as
generics) is fully open and documented as ECMA standard 334. The
Common Language Infrastructure (runtime) is open and documented as
ECMA standard 335. No company or individual can ever be sued for
implementing their own tools based on ECMA standards.
http://www.dina.kvl.dk/~sestoft/ecma/
Some of the higher level libraries are not open standards, and
recently the mono team has been looking at writing an open source
version of Indigo (the Windows Communications Foundation layer for the
new Windows Vista line). This is an advanced method of handling
remoting and web services that is NOT an open standard.
I strongly support a company's right to have some proprietary code
because that pays the salaries of their employees. If Microsoft gave
away all of their standards, then there would be no Microsoft.
Similarly, Freescale has given us the source code for the serial
monitor, but not for d-bug12. Like you, I really wish they'd give us
the code for d-bug12, but I support their right to keep it closed if
they choose to do so. Maybe this is a poor analogy, but I'm trying to
say that many companies have trade secrets and open secrets.
Eric
