On May 22, 12:32 am, Sebastien Lelong <[email protected]>
wrote:
> Hi,
>
> > > From what you say, I understand you don't want
> > >commercial compilers to be allowed to use your files. Is that right ?
>
> > Yup. that's right. Long live open source!
>
> > The flow would be like this.
> > The dex code i produce could be keep secret from outside world, just
> > for now. But not from you and other JALLIB developers.
>
> Well, keeping things secret is not something I would call open source :)
>
> What about other open source compilers ? Why couldn't they use your files ?
>
>
>
> > I hope, myself, you and others will be maintain that dex information
> > first.
>
> OK. What is "dex" ? Is it a format of your own ? Is that what you posted, or
> something "above" this ?
Yeah. It is format on my own. My actual intention is to "map" the PIC
into
a file that could be read, in a text form, that will be used to any
PIC programs. Microchip
only provide PDF details for this. PDF is impossible to be read by any
generators, as Microchip
love to put mutiple microcontroller information in single file. This
lead to complicated analysis method.
The name DEX is derived from EXternal Device information.
Actual DEV is focuses on programming.
My DEX focus on Target chip itself,
that make us to create other things that we could not do before. RAW
device information.
Example:
case (1)
pin AN0/RB0. AN0 is a ADC source. (just an example)
if we in the process using AN0 and we try to use RB0 in the same time,
without waiting GO_DONE, a message will be generated:
Warning: Line X: Pin AN0 is used. RB0 data could conflict the target.
etc etc blah blah blah...
Locked target, maybe.
Error: Line X: Error access RB0 when AN0 is used. Access Denied.
Case (2)
We could show user the real object (the PIC). We also could make a GUI
program
to show user the actual device, and the data mappings, pins, and
others.
This not only could be integrated in compilers, but in simulators too.
Because of its flexiblity, we could intergrate others PIC or SCENIX
new device, at any time.
We also could generate JALLIB file direct from these details.
More complete detail JAL LIB file, i guess.
>
> > We could release it in the future, after we gathered all the PIC
> > details. Complete it first.
>
> Why not, but another approach is to use this information little by little,
> as soon as it's available. Integrate, use it early. This will make sure it
> can be used as expected, and can give lots of ideas while using it to
> improve our libs.
Okay. I agree to your strong point. We could start the project,
okay? Make it PICEX project maybe? Suggest a good name please.
>
> Can you give some details about work to be done before having this
> information complete ? What should be done ?
>
Okay. That's a lot of things that we need to do.
The details in the PIC PDF lack something.
If we directly search to details, there will be mismatch on
indentifying pin data.
Example, As ANx pin, it maybe an Analog Comparator pin or ADC Pin on
some PDF.
For now, i solve this by ADCRes detail. If ADCRes=0 then no ADC
available.
The ANx pin will be assumed as comparator pin.
Programming method strategy (burning method).
ROM and other detailed things. Specify EEPROM, UV/OTP/Flash, PIC
Package available (example, DIPCERDIP/DIP/SSOP bla bla), and a lot.
>
>
> > We could generate JALLIB files some information from this dex code,
> > Then, the released file, would be in license is either BSD or ZLIB.
>
> OK.
>
> I understand that:
>
> - you don't want your files/informations being used by commercial
> compiler/lib/program/etc...
> - there's probably an open source license which would fit this need
> - but this information will also be the source for producing, generating
> jal files
> - these jal files will be ZLIB licensed (BSD is for samples and projects),
> thus allowed to be used in commercial applications.
>
> And this is where we may have problems:
>
> - depending on the license used for your dex files, it could be
> incompatible with ZLIB, or worst contaminate our jal files, which would not
> be allowed to be used in commercial applications (this is not what we want)
> - even it's ok, the information containted in generated jal files could be
> exploited by commercial applications. Parsing a jal file is not a big deal.
> At the end, one could reconstitute your dex files from another source of
> information.
>
> Sorry to bother with this, but this is an important point, that must be
> clarified. Just few more words: when I wrote my small scripts to parse PDF
> in order to extract pin aliases (DIPPinDef in your dex), I first tried to
> get this information from another project, website, etc, in a format that
> could programmatically be used... I was quite surprised to found nothing...
> even from Microchip itself ! This information is valuable, if others
> (commercial or not) could use it, then it's good for them, it's good for us
> and for jallib/jal.
>
Okay. You win, with your two cents and I agree that such details is
valueable.
Why dont we start now, and create our DEX library?
>
>
> > This dex will be not needed on jal compiler. We don't need to release
> > it as part of JALLIB right?
>
> This is up to you ! As an example, Rob develops dev2jal project, which
> generate device files. While this project could live (and is living) on its
> own, it's also part of jallib, because Rob wanted it and this makes sens.
>
> This is my point of view, maybe other guys around there could give their own
> point of view, advices.
>
> Cheers,
> Seb
> --
> Sébastien Lelonghttp://www.sirloon.nethttp://sirbot.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---
