Disabling automatic including of units?

[rainer]

Hello,

I am currently porting one of my applications from mE's LCD library to the LCD1602 unit of dany's website. The original LCD library is almost useless to me, as mE appears to have absolutely no interest in adding a simple delay function to their closed source library for slowing the LCD-output down (I pleased them at least 10 times in the past months and got only useless answers like "... we will consider...blah..." ). -> Really exciting, this is professional help!

Hereby I found out that this "feature" of automatically including mE-libraries can become very nasty, as...

• - I cannot replace their units with self-written ones, using the same procedure names (would allow me to keep my code unchanged except of a different name in the uses line).
  - Even if I use different names, there is the problem that the compiler rises no error if forgot somewhere to replace an old procedure name, it simply inserts then the mE library in addition.

-> You can imagine what the result will be.

How can I force mP 8.1 to only link those libraries I explicitly declare in the uses line and to rise an error otherwise? This is how normal compilers work[/list]

[piort]

hi,
i think you will be able to do it with the next version. If you look the pro version for other mcu, you have a check list to specify the lib you want...

hth a bit

[rainer]

hi,
i think you will be able to do it with the next version. If you look the pro version for other mcu, you have a check list to specify the lib you want...

hth a bit

Hi, piort,
how is the progress with mP at all? It appears to me that it stucks.

There was also a Linux-native version announced long time ago. Your opinion? This Windows drives me crazy and I will be happy to be able to entirely work on Linux. Currently I edit in Linux, compile in Windows (vmplayer), then flash the PIC in Linux with PicKIT2. - Not very funny, but still better than running the editor in a virtual environment as this is awfully slow.

rainer

[piort]

hi rainer,

im not in ME secret but if you look what they have done with pascal for 8051 and avr...

now those application have command line for compile. The fact they have seperate the IDE and the compiler was the first step to port to linux... I'm sure they will make it....in one years or two...

If the new pic pro version will be in line with the avr one, that will be a big step... new ide, new lib management, new project wizard, new statistic widows in html so you can save it for compare or print it or put it on your web site And if they corect the same number of bug in the pic compiler they have made in avr , MP will be near free of bug )))) not...that was a dream... lolol but they come with new bit type... so boolean will take one bit of memory instead of one byte. And i forgot to mention the speed of compile....very fast now... And im sure i forgot half of the improvement....

for me, corrected the bug list was a priority because i have to use version 7 instead of 8.1 or 8.3... I have send some piece of code that compile and work fine in V7 but not work (compile without error) in V8 ... So i have going back with old version in the mid time they come with the pro version

the beta version will be online in one month or 2 ... following what i have read in the forum...

So just dream and wait

[rainer]

piort,
thanks for this info. I wonder why they initially started with everything (IDE and compiler) in one application. I cannot remember any tool which really works trouble free this way. But now they split that up, so it only can become better (and faster). But speed is not everything...

How do they handle all the PIC options in the new version? Currently they save them in the project file with their IDE. Will this IDE be available on Linux then, too? If not, editing this file could become a chellenge.
It would be really smart if they allow defines for configuring the compiler from inside the main program (as FreePascal, TurboPascal, BorlandPascal, ... do), otherwise I am still not really able to work from the command line. Also I hope they changed to Lazarus, as it is able to compile on every OS, while Kylix is more restricted.

Is there some beta available I can view or play with? Only PIC16/18 makes sense, as I don't use other PICs. Do you have a link to it, please?

[janni]

Is there some beta available I can view or play with?

As piort said, the beta will still need at least a month to arrive .

- I cannot replace their units with self-written ones, using the same procedure names (would allow me to keep my code unchanged except of a different name in the uses line).
- Even if I use different names, there is the problem that the compiler rises no error if forgot somewhere to replace an old procedure name, it simply inserts then the mE library in addition.

You could manipulate the definition file for the PIC you use - from the list of libraries you may remove the one that causes trouble (only a whole lib, unfortunately). You may also rename the lib in Uses/PICxx directory and place your own under the old one's name (if you gave your unit the same name).

Already a long time ago I petitioned for possibilty of overwriting single offficial lib routines. I repeated the plea lately, but I wouldn't expect this feature to come to life in next release...

[rainer]

Hi, janni!

I didn't recognize that even the beta is not ready.

Manipulating definition files is not very practical as this will cause/be a general effect on all projects. Therefore I didn't do that. But thank you very much for your kindness.

Hope that some of mE read this and think about that:
Life would be so much easier if MikroE would simply supply the library sources for personal/individual use on request (either entirely or only the requested one), if they are not willing to do the required changes within an acceptable period of time, or don't have enough resources free. Instead, they prefer a lot of unsatisfied users, where everybody is forced to find workarounds by himself.

They would get back the sources and would benefit hereby,
Other users extend their libraries, they only have to decide what they will add into the next revision of their original libs.
Their libraries will be much closer to real life needs as they currently are, without having much work with that.


I offered repeatedly to do the extensions by myself (if they supply me the source of the LCD-libs) and to leave them the modified source for free(!), but meanwhile I gave up (as surely many others did) and do it myself. Very sad, but true.

[coldharbor]

I do this with our source control system--check the modded defs/ in and out along with the sources as needed for a project build.

However, I believe if you copy the necessary chip's defs/ files to a new name, mod the references (unit names) and rebuild, you can then modify the new defs to suit your needs. Basically make a new chip def.

For example, to mod a 16f690, copy P16F690.MLK, P16F690.ppas, and P16F690def.ppas to say, QP16F690.MLK, QP16F690.ppas, and QP16F690def.ppas, modify the internal unit references text to match the new name, edit the include units list if needed, load a dummy project, then build all to get the .mcl files done.

[janni]

Manipulating definition files is not very practical as this will cause/be a general effect on all projects.

I can confirm that, as coldharbor explained, "new" processor definition works as well as any other, so one may have individual definitions for individual projects without affecting any other ones.

[rainer]

Now I am a little bit confused about what you are talking about.

I am not talking of new processor types which shall be implemented, I am talking only about mikroPascal units like LCD, LCD8, ..., making me troubles.
Some of the original units (mE units) are more or less away from practical usability and need some tweaking, but mE makes that impossible with their closed source units. They don't add those changes by themself, but they also don't hand out the source. So I mut entirely replace the units by self written ones and this causes again earlier mentioned problems.

As an example, the LCD unit runs so close to the limits of a 16x2 LCD, that you get troubles at low temperatures (the LCD is slower then), when using a little bit longer cables (30cm were enough to cause random errors), and also some LCDs are definitely slower as written in the datasheet.
All you have to do is: Talk a little bit slower to the LCD and everything is fine then, but you cannot set the speed in mE's unit. So the unit is fine for playing on the desktop or with their demo boards (there you have max. 5cm wire length), but in reality you sometimes run into troubles and cannot fix it because of this insufficient unit!

[janni]

I am not talking of new processor types which shall be implemented

Neither are we. By "new" processor definition we meant a tweaked definition of the processor you use. You may have it under a new name and use it with specific project. (Actually, every processor has three definition files, so a copy of all three has to be made.)

As you looked for a way to replace or remove an official lib (LCD), I've suggested removing it from the list in processor definition file. Coldharbor suggested a way to do it without affecting other projects, and that's what I also do for some projects that require slightly modified parameters.

In other words, one may have several definitions for the same processor (under different names) and choose one of them for a specific project.

[coldharbor]

I should have put in more detail. Janni filled it in nicely.

But I'll ramble on anyway. If you want to manually specify units, take them out of the definition files (.ppas, .mlk) and rebuild the def files (build all), which gives you new .mcl files. This allows you to (1) specify only the units you want to use (2) use your own units that may have matching identifiers in the mE units. This obviously does not address not having sources to mE libraries, but allows you to include your own libraries easily, which I believe is the original question. The downside of this approach, is remembering to do this to every processor def you want to use.

If you have, for example, cooked your own LCD unit that has matching identifiers in the mE LCD unit, you would remove the mE LCD unit references from the def files and rebuild them. Now, you can manually include the mE or your LCD unit via uses. Or, you can include your LCD unit in the defs so it is always there.

I use almost all my own libraries as I usually need to be able to produce and retain source so I often start with cleaned out def files (prefix name with 'E', empty). New MCUs get an 'S' (sample).

Not to start another thread on lib sources, but for $150 or $250 I don't expect to get library sources. Among other considerations, there is a lot of intellectual property tied up in them and they may not be as clean as wanted for public release/criticism (it is a valid reason). On the other hand, when I am writing a check for $1500 per processor family for a compiler, you bet I want the sources.

[rainer]

As you looked for a way to replace or remove an official lib (LCD), I've suggested removing it from the list in processor definition file. Coldharbor suggested a way to do it without affecting other projects, and that's what I also do for some projects that require slightly modified parameters.
In other words, one may have several definitions for the same processor (under different names) and choose one of them for a specific project.

Ok, now I understand.
It is really surprising how mikroPascal internally works. I would never expect that libraries/units are referenced in the processor defs, so I would never have searched there, as I assumed that the processor defs only contain processor related things, while the libs/units are always the same and linked in on demand?

Indeed a very interesting compiler design...

I am really interested how mE will do that in the next version.