I'm experimenting with Manchester encoding in low-end 12F PICs but your standard library fuctions appear only to apply to the 16 and 18 range of PICs (presumably due to code size).
Its become common practice for software houses to include the source code to their libraries supplied with the compiler - my copy of Borland Delphi for example comes with complete source code for the VCL, etc.
Would you consider making the source code for the pre-compiled mikroPascal libraries available us - or perhaps only to registered compiler users?
I'm sure many mikroPascal users would find it both a valuable educational reference and a great help in debugging / porting to other devices.
Many thanks
Library Source Code
Library Source Code
Last edited by gbh on 14 Mar 2005 17:30, edited 1 time in total.
I had been holding back on my purchase of the mikroPascal compiler (and EasyPIC 2 development board) until a reply was posted, but having used the demo software for a couple of weeks now (and being very impressed with it) I decided to press ahead and order it anyway!
Having researched other compiler vendors on the web, it seems to me that most (if not all) supply the source code to their libraries to registered users.
As well as helping to port code to other PIC types, I feel that access to the library source would also help myself (and fellow development board users) debug our applications without having the nagging doubt that any fault may lie with the library code (and consequently raise a 'fault' with yourselves in the general forum for you to investigate).
My last concern would be one of confidence. When I go into production (as is my plan) with a commercial product developed in the mikroPascal environment, I'd be very reticent indeed to include routines from the development library - as I would not be able to support them effectively and independently - which rather dimishes their value in the first place.
Have you had any further thoughts on this? What do others feel?
Many thanks,
Gary
Having researched other compiler vendors on the web, it seems to me that most (if not all) supply the source code to their libraries to registered users.
As well as helping to port code to other PIC types, I feel that access to the library source would also help myself (and fellow development board users) debug our applications without having the nagging doubt that any fault may lie with the library code (and consequently raise a 'fault' with yourselves in the general forum for you to investigate).
My last concern would be one of confidence. When I go into production (as is my plan) with a commercial product developed in the mikroPascal environment, I'd be very reticent indeed to include routines from the development library - as I would not be able to support them effectively and independently - which rather dimishes their value in the first place.
Have you had any further thoughts on this? What do others feel?
Many thanks,
Gary
Let me add a different perspective ... I am not so concerned with knowing what is in the libraries, as I am with being able to toss out extraneous portions which are either not needed in the specific application, or are convoluted because of the need to provide flexibility in a binary library. An example would be setting the ports and pins for the LCD/GLCD libraries. It would be so much cleaner to simply declare the parameters as constants, and not have to call these long procedures with long argument lists. I suspect that there would be a significant reduction in hex, as well.
Binary procedures have their place, but sometimes they are clumsy. And of course, if you are having a problem, and trying to understand what is happening, it is easier to follow source than ASM.
I suspect that these libraries are commented in Serbian, and there may be some reluctance to release that. I wouldn't worry about that, The GLCD example was also commented in Serbian, and having the source was better than not having it. It wasn't hard to figure out the general program flow, and how to modify it.
Binary procedures have their place, but sometimes they are clumsy. And of course, if you are having a problem, and trying to understand what is happening, it is easier to follow source than ASM.
I suspect that these libraries are commented in Serbian, and there may be some reluctance to release that. I wouldn't worry about that, The GLCD example was also commented in Serbian, and having the source was better than not having it. It wasn't hard to figure out the general program flow, and how to modify it.
Thanks for the general support - however I was basing my request on making the library source code available to all registered users - as is usual with other compiler vendors.
To limit it to just 'some' of the libraries would mean that I'd still be reluctant to incorporate functions from libraries to which I didn't have access to the source in any commercial application. And who would decide which libraries?
You raise a further good point however in that it may spur some customers to add to and customise the library functions - adding new functionality to existing libraries and possibly sharing it with other users (and mikroElektronika).
I don't quite agree your comment that new users could read too much into code they don't understand. I personally learned as much from books as I did from looking through the source code of the Delphi VCL.
To limit it to just 'some' of the libraries would mean that I'd still be reluctant to incorporate functions from libraries to which I didn't have access to the source in any commercial application. And who would decide which libraries?
You raise a further good point however in that it may spur some customers to add to and customise the library functions - adding new functionality to existing libraries and possibly sharing it with other users (and mikroElektronika).
I don't quite agree your comment that new users could read too much into code they don't understand. I personally learned as much from books as I did from looking through the source code of the Delphi VCL.
I think that the concern is that a little knowledge can be dangerous sometimes, and the support forums may be clogged with questions that shouldn't be asked. While you are developing a commercial product, a significant number of users are hobbyists or students. In general, the first choice for library functions should be that they are used as "turnkey" or "black box" devices. If you are going to ask what's inside, you need to take responsibility for the ramifications of fiddling.gbh wrote:I don't quite agree your comment that new users could read too much into code they don't understand..
As a practical matter, if these binary procedures are turned loose in the hands of enough people, they will either come to be considered reliable, or will develop a pattern of known quirks which can be worked around. I don't think that reliablilty in a commercial product is a question provided that they have been used by enough different users in enough different applications. The value of the feedback is improved when we know that everyone is using the same unmodified routines.
What will be most important is getting some feedback on how thoroughly these routines have been tested, and what the known quirks are. I think that this is an area where the forum can be improved to include bug tracking. I would be more concerned about improving the bug tracking system if you are concerned about reliability. It is somewhat unusual for a bug to pop up out of nowhere after months or years of operation (though it can happen).
Frankly, I don't know where the reluctance to publish these to registered users comes from. If there is a desire to protect IP, Pascal is the ideal language, because there is no other Pascal compilers for PICs out there (except for a Pascal-to-C cross compiler). It may have more to do with documentation and support.
I take on board your points.
I haven't seen a reluctance to publish the source to registered users - I'm still awaiting comment from the guys at mikroElektronika.
I'd be happy for the original compiled libraries to be supported, and the source to be issued as-is, regardless of the language it is commented in.
I haven't seen a reluctance to publish the source to registered users - I'm still awaiting comment from the guys at mikroElektronika.
I'd be happy for the original compiled libraries to be supported, and the source to be issued as-is, regardless of the language it is commented in.
Exactly.gbh wrote:I'd be happy for the original compiled libraries to be supported, and the source to be issued as-is, regardless of the language it is commented in.
I hope that I have this story correct, but as I recall, the open source/GNU movement was started over precicely such an issue. I believe that it was a research physicist trying to get his Xerox printer to do something that it wouldn't do. At the time, proprietary binary software was new, and the tradition from the days of mainframes was to provide software free of charge and in source form.
After contacting Xerox, he was told that the driver wouldn't do what he wanted. He requested the source, so that he could add the feature himself. He was told that that wasn't possible. He got mad, and developed the GNU agreement. All he really wanted was to tweak his printer driver. Instead, Xerox tweaked him.
Well,
shouldnt be available only to registered users, but for other users too, i recently purchased an easypic2 and cf adapter and my efforts towards writing code to access the CF card using another C compiler, failed miserably, for some reason the mirkopascal examples work just fine, but my code which is based on other CF codes written for PIC just doesnt want to work.
I would really like to take a closer look at the compact flash library from mikroelektronika to figure out what im doing wrong, because apparently there is no reason for it not to work ...
shouldnt be available only to registered users, but for other users too, i recently purchased an easypic2 and cf adapter and my efforts towards writing code to access the CF card using another C compiler, failed miserably, for some reason the mirkopascal examples work just fine, but my code which is based on other CF codes written for PIC just doesnt want to work.
I would really like to take a closer look at the compact flash library from mikroelektronika to figure out what im doing wrong, because apparently there is no reason for it not to work ...
This is a good example of where an excerpt of the source would be helpful. Of course, you can always examine the ASM listing generated by the compiler. It includes the ASM of the library functions. The ASM listings are automatically generated, but they are actually not as hard to follow as you would think.Synologic wrote:for some reason the mirkopascal examples work just fine, but my code which is based on other CF codes written for PIC just doesnt want to work.
I would really like to take a closer look at the compact flash library from mikroelektronika to figure out what im doing wrong, because apparently there is no reason for it not to work ...
Yes i agree on ASM part, but im not very knowledgeable with ASM language 
my code in C is as follows:
address = 7;
output_bit(CF_ADRESS_0,bit_test(address,0));
output_bit(CF_ADRESS_1,bit_test(address,1));
output_bit(CF_ADRESS_2,bit_test(address,2));
sets the CF register for receiving commands
after this code i tried with and without strobing the write line, some documentation mentions that one needs to strobe the write line after putting the register address, others dont,
output_d(0xEC);
output_low(CF_WRITE); // Strobe Write Line
delay_us(300);
output_high(CF_WRITE);
here, i put the identify drive command on portd and strobe the write line
address = 0;
output_bit(CF_ADRESS_0,bit_test(address,0));
output_bit(CF_ADRESS_1,bit_test(address,1));
output_bit(CF_ADRESS_2,bit_test(address,2));
then i put 0 for generic read/write on the address line
output_low(CF_READ); // Strobe Read Line
delay_us(300);
cd=input_D(); // Read Data Bus
output_high(CF_READ);
then strobe the read line and get the input from portd
note that i wait 300 us for the command to be processed by the card, again some code do that, some code dont do that, some code waits for the READY line to become active (again tried all ways)
for two consecutive reads, first returns 0xEC (which i just wrote to the port) and second read returns 0.
Some examples i read, besides the CF 3.0 specifications include the code from www.mpic3.com which is based on another source code snippet i found (dont remember the link now). I even read some AVR code which i found on the net, which practically does the same thing.
my code in C is as follows:
address = 7;
output_bit(CF_ADRESS_0,bit_test(address,0));
output_bit(CF_ADRESS_1,bit_test(address,1));
output_bit(CF_ADRESS_2,bit_test(address,2));
sets the CF register for receiving commands
after this code i tried with and without strobing the write line, some documentation mentions that one needs to strobe the write line after putting the register address, others dont,
output_d(0xEC);
output_low(CF_WRITE); // Strobe Write Line
delay_us(300);
output_high(CF_WRITE);
here, i put the identify drive command on portd and strobe the write line
address = 0;
output_bit(CF_ADRESS_0,bit_test(address,0));
output_bit(CF_ADRESS_1,bit_test(address,1));
output_bit(CF_ADRESS_2,bit_test(address,2));
then i put 0 for generic read/write on the address line
output_low(CF_READ); // Strobe Read Line
delay_us(300);
cd=input_D(); // Read Data Bus
output_high(CF_READ);
then strobe the read line and get the input from portd
note that i wait 300 us for the command to be processed by the card, again some code do that, some code dont do that, some code waits for the READY line to become active (again tried all ways)
for two consecutive reads, first returns 0xEC (which i just wrote to the port) and second read returns 0.
Some examples i read, besides the CF 3.0 specifications include the code from www.mpic3.com which is based on another source code snippet i found (dont remember the link now). I even read some AVR code which i found on the net, which practically does the same thing.
Almost another 3 weeks have passed since my last plea for a statement re. library source code availability. It's been 7 weeks since my original posting and still no reply. 
I like the comment from another user in the mikroPascal forum on an unrelated problem...
..."source code could be a step in the good direction, i could then see what is wrong. As it is today it is like trying to find your way blindfolded in a dark tunnel"
Without access to the library source mikroPascal is more like a closed system, rather than a development system.
I know you guys are tied up with compiler development, but could you consider your policy here please, and let us know.
Many thanks
I like the comment from another user in the mikroPascal forum on an unrelated problem...
..."source code could be a step in the good direction, i could then see what is wrong. As it is today it is like trying to find your way blindfolded in a dark tunnel"
Without access to the library source mikroPascal is more like a closed system, rather than a development system.
I know you guys are tied up with compiler development, but could you consider your policy here please, and let us know.
Many thanks
