Post by thread:PBasic PRO compiler

On Fri, 29 May 1998, Dennis Plunkett wrote: > At 01:33 PM 29/05/98 +0800, you wrote: > >Hi all > >Does anyone have experience with the PbasicPRO compiler? > >Is it worth getting, and does it support all the functions of the > >PIC? > >Thanks > > > >Justin Grimm reaperKILLspamsouthwest.com.au > > > > > > Hello Justin ,from a fellow Aussie > My question is why basic? The PIC assembler is quite easy, and on top of > that one could argue that C is an industry standard. > > Dennis > PTM: I'm for the Basic. It was originally to be a SIMPLE way to write code for a person who doesn't want to learn high level programming. In the PC world I have allways wondered why they didn't take Basic for the command prompt language and to be used in the .BAT -files. They had the code allready in the PC's PROM, so it would not be hard to do. There got to be something wrong with IBM and Micro$oft. In hardware programming Basic makes it fast to make simple systems. I have myself written the programs first with PICBasic and then compiled time and space -critical parts anew with ASM after they work in Basic. This makes testing fast. Sometimes I have not found any method to write faster code than PICBasic. I'n not against C, I have used it myself very much, but writing user interfaces and character string manipulatin is still easier with a good basic (I wonder why they don't have QuickBasic any more for the PC) PICBasic has been very effective system: code is tight and rather fast. It is easy to optimise to assembler. It is even easy to comment and document. What I would like to have is a PIC emulator (simulator ?) in PC so that I have not to compile and move the code to PIC. -------------------------------------------------------------------------- PTM, .....pasi.mustalahtiKILLspam.....utu.fi, EraseMEptmustaspam_OUTTakeThisOuTutu.fi, http://www.utu.fi/~ptmusta Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK Lab.engineer (PC support) Computer Center OI7234 Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014 Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 0400-555577) --------------------------------------------------------------------------

Is there any hard or software lock of PIC BASIC PRO COMPILER? Dr. Imre Bartfai wrote: {Quote hidden}> On Fri, 29 May 1998, Dennis Plunkett wrote: > > > At 01:33 PM 29/05/98 +0800, you wrote: > > >Hi all > > >Does anyone have experience with the PbasicPRO compiler? > > >Is it worth getting, and does it support all the functions of the > > >PIC? > > >Thanks > > > > > >Justin Grimm RemoveMEreaperTakeThisOuTsouthwest.com.au > > > > > > > > > > Hello Justin ,from a fellow Aussie > > My question is why basic? The PIC assembler is quite easy, and on top of > > that one could argue that C is an industry standard. > > > > Dennis > > > > > Hello, > > why NOT Basic? > > Arguments vs. assembler (I like assembler!): > > - arithmetic very easy > - variable maintenance automatic > - lot of useful stuff you must otherwise program > SERIN, SEROUT, SHIFTOUT, I2READ, I2WRITE, LCDOUT, etc. > - structured programming > - you can use assembler as integral part of the language wherever you want > > I personally has studied the assembly code generated by the PICBasicPRO: > it is very tight so one does need to be afraid from overhead. > > Disadvantages (maybe vs C): > > - no dummy parameter for the procedures > - no local variables (i.e. all are global) > > I'm satisfied with PICBasicPRO (after collecting some experience). > > Imre

In a message dated 5/29/98 2:08:02 AM Eastern Daylight Time, reaperEraseME.....SOUTHWEST.COM.AU writes: << Hi all Does anyone have experience with the PbasicPRO compiler? Is it worth getting, and does it support all the functions of the PIC? Thanks Justin Grimm EraseMEreapersouthwest.com.au >> Dear Justin, We are having great success with the PBasicPro setup. It pretty much works as advertised, and makes development a dream. The best part from our point of view is you can easily mix assembly code with basic. For example, in a heart-rate monitor just completed, I did the messy stuff (convert millisecond count into beats-per-minute) in basic with: bpm = 60000 / ms This lets the compiler do all the nasty 32-bit math, and lets you get on with life! Also, it seems very efficient in generating compact code. You might check that it supports your PIC of choice; we have been using the 16F84 so far, but I am anxious to try the higher-end chips as well. Highly recommended! Cheers, Charles Ward CWE, Inc.

Pasi T Mustalahti <RemoveMEptmustaEraseMEEraseMEUTU.FI> writes: > On Fri, 29 May 1998, Dennis Plunkett wrote: > > > At 01:33 PM 29/05/98 +0800, you wrote: > > >Hi all > > >Does anyone have experience with the PbasicPRO compiler? > > >Is it worth getting, and does it su > PTM: I'm for the Basic. It was originally to be a SIMPLE way to write code > for a person who doesn't want to learn high level programming. In the PC > world I have allways wondered why they didn't take Basic for the command > prompt language and to be used in the .BAT -files. They had the code > allready in the PC's PROM, so it would not be hard to do. There got to be > something wrong with IBM and Micro$oft. > The ROM basic was not something that you could leave without rebooting. It also did not use ASCII character sets; it used a compacted 7-bit word and some other things that made it easy to say ``that won't work for batch files.'' > I'n not against C, I have used it myself very much, but writing user > interfaces and character string manipulatin is still easier with a good > basic (I wonder why they don't have QuickBasic any more for the PC) > Not if you know C, imho. -- Matthias Granberry RemoveMEGonffspam_OUTKILLspamwindmillbbs.com Caffeine, nicotine, and execution all serve as "normalizing agents". -- "Attention Deficit Disorder"

Hi all, there is only a legal "lock". Here follows quote from the Software License: ... Licensee may not network the software or otherwise use it on more than one computer terminal at the same time. Copies may only be made for archival or backup purposes [end of quote] I think it is clear. Any violation of the terms and conditions is a CRIME and will be prosecuted by the full extent of the law (at least in our country). I think it is fair that somebody working hard to create a program will be saved from piracy (what would you do if YOU were the victim of a software piracy, i. e. you made a software and could sell it only one copy). On the other hand, most software producents (except Microsoft) can be entered into a fair bargain. Regards, Dr. Imre Bartfai On Fri, 29 May 1998, Ocal TURKBEY wrote: {Quote hidden}> Is there any hard or software lock of PIC BASIC PRO COMPILER? > > Dr. Imre Bartfai wrote: > > > On Fri, 29 May 1998, Dennis Plunkett wrote: > > > > > At 01:33 PM 29/05/98 +0800, you wrote: > > > >Hi all > > > >Does anyone have experience with the PbasicPRO compiler? > > > >Is it worth getting, and does it support all the functions of the > > > >PIC? > > > >Thanks > > > > > > > >Justin Grimm RemoveMEreaperTakeThisOuTspamsouthwest.com.au > > > > > > > > > > > > > > Hello Justin ,from a fellow Aussie > > > My question is why basic? The PIC assembler is quite easy, and on top of > > > that one could argue that C is an industry standard. > > > > > > Dennis > > > > > > > > Hello, > > > > why NOT Basic? > > > > Arguments vs. assembler (I like assembler!): > > > > - arithmetic very easy > > - variable maintenance automatic > > - lot of useful stuff you must otherwise program > > SERIN, SEROUT, SHIFTOUT, I2READ, I2WRITE, LCDOUT, etc. > > - structured programming > > - you can use assembler as integral part of the language wherever you want > > > > I personally has studied the assembly code generated by the PICBasicPRO: > > it is very tight so one does need to be afraid from overhead. > > > > Disadvantages (maybe vs C): > > > > - no dummy parameter for the procedures > > - no local variables (i.e. all are global) > > > > I'm satisfied with PICBasicPRO (after collecting some experience). > > > > Imre > >

Justin Grimm wrote: > Does anyone have experience with the PbasicPRO compiler? > Is it worth getting, and does it support all the functions of the > PIC? My two pence: I have found that MEL's products are functionaly OK, but that the people working there have been less than helpful on more than one occasion. They claimed that their assembler was "compatible" with MPASM, but after repeated inquiries into problems compiling MPASM code (out of books, off the net, etc.) I was told to just quit using their compiler (and supposedly just quit bothering them) and use MPASM. Not a great recommendation for their product or their product support! Their documentation leaves a lot to be desired IMO and seems to be little more than a tacked-on afterthought. As an example of their lack of interest after they have my money, I wrote to their tech support via E-mail on the 22 of May and as of this writting have heard nothing back. How would you feel if your project was stalled and you had no reply from them for eight days (and counting)? And this makes three unanswered E-mails to them at this time -- although, to be fair, two were sent on the 22nd about the same problem and the other was a non-critical inquiry. They sell functional products at a low price, and perhaps don't have the headroom to provide much support. But in that case it should have been made clear to the prospective buyer that they were buying a "vagrant product" (no visible means of support). My feeling is that, had I built David Tait's excellent programmer for free, I would have gotten more response from David then I am getting from MEL. I, for one, will not buy anything else from them after these experiences, and I cannot recommend that anyone else buy from them. Just my two pence. Your mileage may vary. Michael REMOVE THE .NS (NO SPAM) FROM MY ADDRESS TO REPLY *************************************************************************When th e way of the Tao is forgotten, kindness and ethics must be taught. Men must learn to pretend to be wise and good. -- Lao Tzu *************************************************************************

Dr. Imre Bartfai wrote: > > Hi all, > > there is only a legal "lock". Here follows quote from the Software > License: > > ... Licensee may not network the software or otherwise use it on more than > one computer terminal at the same time. Copies may only be made for > archival or backup purposes > > [end of quote] Not sure if this is what you were really talking about, since the message you quoted didn't seem to have much to do with your new text.. While most software does say something like this, it is pretty much unenforcable on most software sales. In several cases the courts have ruled that you do own the software you buy and can modify it for your own purposes. Now an actual software LEASE (similar to leasing equipment) may not be so lenient, but for the most part the courts have been pretty much "if it looks like a sale of an item, it is a sale." {Quote hidden}> > I think it is clear. Any violation of the terms and conditions is a CRIME > and will be prosecuted by the full extent of the law (at least in our > country). I think it is fair that somebody working hard to create a > program will be saved from piracy (what would you do if YOU were the > victim of a software piracy, i. e. you made a software and could sell it > only one copy). On the other hand, most software producents (except > Microsoft) can be entered into a fair bargain. > > Regards, > > Dr. Imre Bartfai >

I have also Parallax programmer. I wrote a small program which inserts a device record into the hex file generated by PicBasic Pro, so the Parallax Programmer starts with a correct chip. If there is an interest, I could send it for testing. Imre On Sat, 30 May 1998, Max Toole wrote: {Quote hidden}> I have had very good results with the MELabs PicBasic Pro Compiler. When I > called them to purchase it, I told them that I have a Parallax programmer and > asked if it would work or if I needed to purchase their programmer. The guy > that I spoke with was very honest and told me that I didn't need to spend the > money to buy their programmer. I have been using the PicBasic Pro software > with the Parallax programmer and I think it is great. Maybe I'm not using > some of the functionality that others are. I'll admit that I am not a > heavyweight programmer but, for my application, It has worked very well and I > recommend it. > > Max Toole, > Electronic Innovations,Inc. > >

Dr. Imre Bartfai wrote: > > I have also Parallax programmer. I wrote a small program which inserts a > device record into the hex file generated by PicBasic Pro, so the Parallax > Programmer starts with a correct chip. If there is an interest, I could > send it for testing. > If you want to send it to me Imre, I'll post it on my PRO page at: http://www.dontronics.com/pbpro.html and also post the feedback for the benefit of all Pro Users. Don McKenzie RemoveMEdonKILLspamdontronics.com http://www.dontronics.com Don's Download Dungeon: http://www.dontronics.com/download.html For more details, send a blank message to infoSTOPspamspam_OUTdontronics.com or spamBeGonesimstickSTOPspamEraseMEdontronics.com or KILLspambasicsspamBeGonedontronics.com

Dr. Imre Bartfai wrote: > > Hi there, > I used already its predecessor, the Pbasic. I purchased the PICBasicPro as > it came and I find it great (for the sake of truth, there are small bugs, > but I know only 2 at a moment and I can tell it in private [or - if there > is an interest - public] mail). I would like to know what bugs you've found I have had problems with sleep, also with pins ( I now ALWAYS use the full name ie: if portb.3=0 then.....) and also a timing problem, out by a factor of five, (count, rctime or pauseus I don't remember ) at 4mhz osc. > I personally has studied the assembly code generated by the > PICBasicPRO: > it is very tight so one does need to be afraid from overhead. I am not as happy as you are on this one PBP eats up lots of ram (a big problem on 16c84's) also PBP has lost a lot of it's automatic functions that make stamp/pbc easy. ie: I have just writen a test program to drive an LCD, I also have buttons connected to the LCD data lines (two buttons at the moment porta.2/3) loop: trisa.3=1 pause 5 if porta.3=0 then lcdout "button depressed" endif result = strange characters on the display ? fix = set the trisa.3=0 before the lcdout This should surely be set by the lcdout command ! And as for tight code, this test program has 11 lines and outputs only 1 character to the LCD display. ( each character takes 2 words ) It compiles with PBP to 220 words or almost 1/4 of a 16f84 program space. 22 Words per line ? loop: lcdout $fe, 1 'clear display trisa = 1 'porta set as inputs pause 5 'wait 5ms if porta.3 = 0 then 'test button trisa = 0 'porta set as outputs lcdout $fe, $c0 'go to second line on lcd lcdout "D" 'down button pushed pause 1000 endif goto loop Peter Cousens email: EraseMEpeterEraseMEcousens.her.forthnet.gr phone: + 3081 324450, 380534 snailmail: Folia, Agia Fotini, Karteros, Heraklion Crete, Greece.

Hi Peter, to understand the code tightness you must take in account the following: the Pic Basic (Pro) [I think also other compilers] has a high-level statements, e. g. LCDOUT, LET, IF, etc. It means behind the statements there are CALLed routines. If the compiler encounters a new statement type (i. e. new in your program, it did not occur up to that point) the whole stuff is linked to your program. If the program is relatively complex, this necessary overhad seems to be huge. However, if a statement of previous type occurs, only the calling sequence will be generated inline (i. e. several words). With LET and arithmetical expression, it is a bit more complicated. If the expression or a sub-expression can be evaluated during compile-time, it will be without overhead. However, multiplication and addition causes the appropriate routines to be linked. I use the practice if I have only a single division (being done in runtime!) I try to replace it with RLF/RRF statements, so the whole dividing stuff can be eliminated. The need of RAM is another thing. Of course, the routines need some working space. I think it is normal. I suggest to drop 16C84 as it is obsolete and has the famous security bug. For the LCD problem: I'm a bit surprised why it is needed to use LCD data lines also as input... You should know... but if you depress a button to ground, how do you want to drive the same line? And a tip: try to define all variables to be used. E. g. Instead of if porta.3 = 0 ... write butt VAR porta.3 if butt = 0 ... I hope I could help you On Tue, 9 Jun 1998, Peter Cousens wrote: {Quote hidden}> Dr. Imre Bartfai wrote: > > > > Hi there, > > I used already its predecessor, the Pbasic. I purchased the PICBasicPro as > > it came and I find it great (for the sake of truth, there are small bugs, > > but I know only 2 at a moment and I can tell it in private [or - if there > > is an interest - public] mail). > > I would like to know what bugs you've found > I have had problems with sleep, > also with pins ( I now ALWAYS use the full name ie: if portb.3=0 > then.....) > and also a timing problem, out by a factor of five, (count, rctime or > pauseus I don't remember ) at 4mhz osc. > > > > I personally has studied the assembly code generated by the > > PICBasicPRO: > > it is very tight so one does need to be afraid from overhead. > > I am not as happy as you are on this one > PBP eats up lots of ram (a big problem on 16c84's) > also PBP has lost a lot of it's automatic functions > that make stamp/pbc easy. > > ie: I have just writen a test program to drive an LCD, I also have > buttons connected to the LCD data lines (two buttons at the moment > porta.2/3) > loop: > trisa.3=1 > pause 5 > if porta.3=0 then > lcdout "button depressed" > endif > > result = strange characters on the display ? > fix = set the trisa.3=0 before the lcdout > This should surely be set by the lcdout command ! > > And as for tight code, this test program has 11 lines > and outputs only 1 character to the LCD display. ( each character takes > 2 words ) > It compiles with PBP to 220 words or almost 1/4 of a 16f84 program > space. > 22 Words per line ? > > > loop: > lcdout $fe, 1 'clear display > trisa = 1 'porta set as inputs > pause 5 'wait 5ms > if porta.3 = 0 then 'test button > trisa = 0 'porta set as outputs > lcdout $fe, $c0 'go to second line on lcd > lcdout "D" 'down button pushed > pause 1000 > endif > goto loop > > Peter Cousens > email: @spam@peter@spam@spam_OUTcousens.her.forthnet.gr phone: + 3081 324450, 380534 > snailmail: Folia, Agia Fotini, Karteros, Heraklion Crete, Greece. > >