|
Hi All, Does anyoone have experience with this BASIC programmer. Not that I need BASIC but this compiler seems pretty good and the included SPLICE simulator is pretty neat as well. I am still trying to find the right compiler and am looking at either CCS, PICBASIC Pro, and the Proton Development Suite. I've finally settled on the PIC line of microcontrollers and this is the next step. I am doing mostly robotics and would prefer not to be mucking in assembler if I don't need to. Thanks, Gary |
|
|
Proton Development Suite
Started by ●November 17, 2004
Reply by ●November 17, 20042004-11-17
|
Hi Gary, I have the PDS and it's great, the simulator is limited to the virtual counterparts of Crownhill's development boards, but they are enough to test most code you can produce, things like timings, serial, etc. can all be simulated without a fuss. It also comes with a USB dongle, so you can install the software on as many PCs as you want, and use it where you need it when you need it. The IDE has been very much improved now, it detects duplicate variable declarations, and has a handy navigation bar on the left with all the labels, so you can move about a large program much easier than before. AFAIK PDS has the most complete command set in the current range of BASIC compilers. Best regards, Mike ----- Original Message ----- From: "ascii_geek" <> To: <> Sent: Wednesday, November 17, 2004 1:47 PM Subject: [piclist] Proton Development Suite > > > Hi All, > > Does anyoone have experience with this BASIC programmer. Not that I > need BASIC but this compiler seems pretty good and the included > SPLICE simulator is pretty neat as well. > > I am still trying to find the right compiler and am looking at either > CCS, PICBASIC Pro, and the Proton Development Suite. > > I've finally settled on the PIC line of microcontrollers and this is > the next step. I am doing mostly robotics and would prefer not to be > mucking in assembler if I don't need to. > > Thanks, > Gary > > to unsubscribe, go to http://www.yahoogroups.com and follow the instructions > Yahoo! Groups Links |
Reply by ●November 18, 20042004-11-18
|
As the other reply said the Spice model is free but limited to the 6 development boards included. I have the full system of Labcenters ISIS you can do really neat stuff. Like modelling 2 or more pics talking to each other and veiwing the timing of the interactions by sending a pin high/low on each PIC and then viewing it all on a VSM logic analyser. When you need to single step all the source on the screen at once, (screen does get a little cluttered) I have read with interest the talk about HLL on the list recently. A lot of people think that if you have a HLL with procedures and functions it is the ultimate system. To me it imposes too many restrictions. Below is copy of a post on the forum who agrees with me. Lastly Proton is highly optimised. Print "hello" will produce Movlw 104 Call Print Movlw 101 Call Print Movlw 108 Call Print Call Print Movlw 111 Call Print Note the repeated call without loading W for the second L Then Like C if you go over a certain string length it will turn the string into a DB file like this:- F1_000014 equ $ ; in [OPTERMISATION.BAS] Print "hello great big world out there" Movlw high str@lb1 Movwf TBLPTRLH Movlw low str@lb1 Movwf TBLPTRL F@Call print@mstr F1_EOF equ $ ; OPTERMISATION.BAS ;--------- ; Null Terminated Strings ; String hello great big world out there str@lb1 DB 104,101,108,108,111,32,103,114,101,97,116,32,98,105,103,32,119,111,114,108 DB 100,32,111,117,116,32,116,104,101,114,101,0 ;--------- From the proton forum There is an example of why structured languages & systems, which allow for parameter passing, have advantages and disadvantages. I used to use the BasicX system, which uses an almost-VisualBasic-compatible language, i.e. you define Subs and Functions, which can receive parameters by value or reference, and return results, etc. It is very practical in some ways, but extremely cumbersome in others. Since discovering Proton+, I can say I won't be going back, specially with PDS which now eases navigation through large projects a LOT. For starters, take a look at this: Code: Serin GPS_RX, 16572, 2000, No_SendPos, [Wait("$GPRMC"), Skip 8, Valid, Skip 1, STR Lat\8, Skip 1, LatDir, Skip 2, STR Lon\8, Skip 1, LonDir] It's a simple GPS NMEA reading operation. The translation into structured BasicX code would be something like: Code: Call OpenQueue(InBuffer, 49) Call OpenQueue(OutBuffer, 29) Call DefineCom3(InPin, OutPin, bx0000_1000) ' n,8,1 Call OpenCom(3, BaudRate, InBuffer, OutBuffer) Wait_RX: If StatusQueue(InBuffer) Then Call GetQueue(InBuffer, InChar, 1) If InChar = 36 Then For i = 1 to 4 Jump Next Call GetQueue(InBuffer, InChar, 1) If InChar <> 67 Then Goto Wait_RX Else Jump For i = 1 to 4 Call GetQueue(InBuffer, InChar, 1) Time = Time & Chr(InChar) Next For i = 1 to 7 Jump Next Call GetQueue(InBuffer, InChar, 1) If InChar <> 65 Then Debug.Print "Invalid" Goto Off End If Jump For i = 1 to 9 Call GetQueue(InBuffer, InChar, 1) Lat = Lat & Chr(InChar) Next Jump Call GetQueue(InBuffer, InChar, 1) LatDir = Chr(InChar) Jump Jump For i = 1 to 9 Call GetQueue(InBuffer, InChar, 1) Lon = Lon & Chr(InChar) Next Jump Call GetQueue(InBuffer, InChar, 1) LonDir = Chr(InChar) Jump InChar = 0 sVel = "" Do While InChar <> 44 Call GetQueue(InBuffer, InChar, 1) If InChar <> 44 Then sVel = sVel & Chr(InChar) End If Loop Call ValueS(sVel, Vel, Dummy) Vel = Vel * 1.85 sVel = CStr(Vel) InChar = 0 Do While InChar <> 46 Call GetQueue(InBuffer, InChar, 1) If InChar <> 46 Then Hdg = Hdg & Chr(InChar) End If Loop End If Else Goto Esperar_RX End If Else Goto Esperar_RX End If Note that this does not include a timeout routine, which is also implemented, involving another few lines of code. In this example, Jump is a subroutine that pulls n characters from the serial buffer. Nice to have a large serial buffer too, but I've learned to live without it. The worst problem with this environment is that you run out of stack space very fast, and so you end up writing the same long routines over all your code rather than calling them nested, because when you bust the stack the uC hangs. --- In , "ascii_geek" <gwatson@w...> wrote: > > Hi All, > > Does anyoone have experience with this BASIC programmer. Not that I > need BASIC but this compiler seems pretty good and the included > SPLICE simulator is pretty neat as well. > > I am still trying to find the right compiler and am looking at either > CCS, PICBASIC Pro, and the Proton Development Suite. > > I've finally settled on the PIC line of microcontrollers and this is > the next step. I am doing mostly robotics and would prefer not to be > mucking in assembler if I don't need to. > > Thanks, > Gary |
Reply by ●November 20, 20042004-11-20
|
----- Original Message ----- From: timbox2005 <> To: <> Sent: Thursday, November 18, 2004 9:07 AM Subject: [piclist] Re: Proton Development Suite > > > As the other reply said the Spice model is free but limited to the 6 > development boards included. I have the full system of Labcenters ISIS > you can do really neat stuff. Like modelling 2 or more pics talking to > each other and veiwing the timing of the interactions by sending a pin > high/low on each PIC and then viewing it all on a VSM logic analyser. > > When you need to single step all the source on the screen at once, > (screen does get a little cluttered) XCSIM allows you to simulate multiple PICs talking to each other and using XEBOT you can design and build virtual hardware to interact with the PICs you are simulating. You can embed high level simulation directives directly into the executable from either XCSB or XCASM and control the simulation without adding code to your executable (your debug version does not need to be different to your release version) > > I have read with interest the talk about HLL on the list recently. A > lot of people think that if you have a HLL with procedures and > functions it is the ultimate system. To me it imposes too many > restrictions. Below is copy of a post on the forum who agrees with me. > > Lastly Proton is highly optimised. > > Print "hello" will produce > > Movlw 104 > Call Print > Movlw 101 > Call Print > Movlw 108 > Call Print > Call Print > Movlw 111 > Call Print > > Note the repeated call without loading W for the second L Superficially this looks like a good optimisation but what happens when the subroutine "Print" is in a different code page to the calling code? I downloaded Proton+ lite last night to have a look at the docs. It was interesting to see that many string functions are not available for the 16 series PICs but only for the 18 series - not a good sign. The mark of good optimisation is not how few machine code instructions one high level instruction can be converted into, but how big a sequence of high level instructions can be reduced to just one machine code instruction. I have shown on many occations how complex sequences of XCSB statements can be converted to just one machine code instruction by the XCSB compiler so I wont waste bandwidth here. > > Then Like C if you go over a certain string length it will turn the > string into a DB file like this:- > F1_000014 equ $ ; in [OPTERMISATION.BAS] Print "hello great big world > out there" > Movlw high str@lb1 > Movwf TBLPTRLH > Movlw low str@lb1 > Movwf TBLPTRL > F@Call print@mstr > F1_EOF equ $ ; OPTERMISATION.BAS > ;--------- > ; Null Terminated Strings > > ; String hello great big world out there > str@lb1 > DB > 104,101,108,108,111,32,103,114,101,97,116,32,98,105,103,32,119,111,114,108 > DB 100,32,111,117,116,32,116,104,101,114,101,0 > ;--------- > > >From the proton forum > > There is an example of why structured languages & systems, which allow > for parameter passing, have advantages and disadvantages. > > I used to use the BasicX system, which uses an > almost-VisualBasic-compatible language, i.e. you define Subs and > Functions, which can receive parameters by value or reference, and > return results, etc. It is very practical in some ways, but extremely > cumbersome in others. Respectfully, I have seen all kinds of rubish produced by people that did not know what they were doing and who then pointed at it as an example of "how complex things really are". If you really want to understand the power of a programming language you should look at the work of a competant user with a view to modifying it. The reason so many professionals frown on (unstructred) BASIC is because many of the programs produced using it end up being so incredibly difficult to maintain. > > Since discovering Proton+, I can say I won't be going back, specially > with PDS which now eases navigation through large projects a LOT. > > For starters, take a look at this: > > Code: > > Serin GPS_RX, 16572, 2000, No_SendPos, [Wait("$GPRMC"), Skip 8, Valid, > Skip 1, STR Lat\8, Skip 1, LatDir, Skip 2, STR Lon\8, Skip 1, LonDir] > > It's a simple GPS NMEA reading operation. The translation into > structured BasicX code would be something like: > Code: > > Call OpenQueue(InBuffer, 49) > Call OpenQueue(OutBuffer, 29) > > Call DefineCom3(InPin, OutPin, bx0000_1000) ' n,8,1 > Call OpenCom(3, BaudRate, InBuffer, OutBuffer) > > Wait_RX: > > If StatusQueue(InBuffer) Then > Call GetQueue(InBuffer, InChar, 1) > If InChar = 36 Then > For i = 1 to 4 > Jump > Next > Call GetQueue(InBuffer, InChar, 1) > If InChar <> 67 Then > Goto Wait_RX > Else > Jump > For i = 1 to 4 > Call GetQueue(InBuffer, InChar, 1) > Time = Time & Chr(InChar) > Next > For i = 1 to 7 > Jump > Next > Call GetQueue(InBuffer, InChar, 1) > If InChar <> 65 Then > Debug.Print "Invalid" > Goto Off > End If > Jump > For i = 1 to 9 > Call GetQueue(InBuffer, InChar, 1) > Lat = Lat & Chr(InChar) > Next > Jump > Call GetQueue(InBuffer, InChar, 1) > LatDir = Chr(InChar) > Jump > Jump > For i = 1 to 9 > Call GetQueue(InBuffer, InChar, 1) > Lon = Lon & Chr(InChar) > Next > Jump > Call GetQueue(InBuffer, InChar, 1) > LonDir = Chr(InChar) > Jump > InChar = 0 > sVel = "" > Do While InChar <> 44 > Call GetQueue(InBuffer, InChar, 1) > If InChar <> 44 Then > sVel = sVel & Chr(InChar) > End If > Loop > Call ValueS(sVel, Vel, Dummy) > Vel = Vel * 1.85 > sVel = CStr(Vel) > InChar = 0 > Do While InChar <> 46 > Call GetQueue(InBuffer, InChar, 1) > If InChar <> 46 Then > Hdg = Hdg & Chr(InChar) > End If > Loop > End If > Else > Goto Esperar_RX > End If > Else > Goto Esperar_RX > End If > > Note that this does not include a timeout routine, which is also > implemented, involving another few lines of code. In this example, > Jump is a subroutine that pulls n characters from the serial buffer. > Nice to have a large serial buffer too, but I've learned to live > without it. > > The worst problem with this environment is that you run out of stack > space very fast, and so you end up writing the same long routines over > all your code rather than calling them nested, because when you bust > the stack the uC hangs. So because you have trouble with one structured language you conclude that they all have the same limitations? XCSB has no such stack restrictions. Within it you can call functions to any depth you like limited only by the amount of available RAM. You can create many small well behaved well documented functions with meaningful names and stitch them together in a meaningful easy to follow program without incuring the overheads of many function calls - you don't need to repeat code you let the compiler do all the hard work for you. Yes you may be able to do things more simply in an unstructured way for small trivial programs but given that you can do all this using a structured programming language if you really wanted to, would you not feel more comfortable knowing that when things get complicated you can simply import complex sections of code (written by others) WITHOUT impacting on what you have already written? No worrying about variable name clashes or special parameter / result passing protocols or RAM or code use. With a programming language such as Proton+ if you want to control specific hardware in an efficient optimised way you are either dependent on the compiler writer adding support for it or you have to write it yourself in assembler. On the other hard XCSB recently aquired 1-Wire functionality because a user (Colin Barnard) with no connection to the compiler writer wrote the library to provide the functionality. And because of the optimisation built into the compiler, the 1-Wire library is as efficient as if it had been implemented by the compiler writer! Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
Reply by ●November 21, 20042004-11-21
|
Believe me Sergio I do not deny that XSCSB is an excellent compiler. What you can make a 14bit core pic do is great, and by using you own assembler the core optimisation >2k know doubt is going to be superb. The Proton developers decided that to enable complete compatibility with Mplabs and its tools they have to live with MPASM and all its failings. Stamp style Pic Basic compilers are in a different market to your product, XSCB is IMHO designed for seasoned writers who are prepared to write code by the book. Capable to write there own routines when there are non available, and understand the need to casting variables in advance of calling procedures them selves. Is XSCB still only 14 bit core? As far as optimising goes what I indicated is only a brief example, like you I could give more. But the main point is the Stamp style Pic Basic compilers are in a different market. There for beginners and people in a hurry. Beginners what every thing handed to them on a plate, a good editor that invokes the compiler and produces code with 1 click. They want very comprehensive manuals; they want lots of pre made commands. People in a hurry want easy to use readable code and to be able to just write:- Print at 1,1, bin12 vara Without having to write there own bin print routines Those who started with stamps at some stage want to move on, in the past it was Pbpro, Proton now offers a that step up from stamps and for Pbro users who want more var types, better data handling, Floats, seamless GLCD support more commands etc. Know doubt if they feel that they have out grown Proton they can move onto XSCSB. Please, please remember I do not want to start a "my compiler is better than yours" fight. This excellent list deserves better than that. As I said at the top Sergio, XSCSB sounds to be a great product. I would though recommend that you put some more work into making it easy to test and run. I would really like to try it out and check just how good the optimisation is, I'll keep reading the included HTM manual I'm sure the instructions on editors are in there some were. Tim --- In , "sergio masci" <smypl@x> wrote: > > ----- Original Message ----- > From: timbox2005 <tim.yahoo@t...> > To: <> > Sent: Thursday, November 18, 2004 9:07 AM > Subject: [piclist] Re: Proton Development Suite |
Reply by ●November 23, 20042004-11-23
|
I'm sorry for jumping in here, but as the post concerning the BasicX
example on the Proton+ forums is mine, I feel I have a right to comment: ----- Original Message ----- From: "sergio masci" <> To: <> Sent: Sunday, November 21, 2004 4:12 AM Subject: Re: [piclist] Re: Proton Development Suite > Respectfully, I have seen all kinds of rubish produced by people that did > not know what they were doing and who then pointed at it as an example of > "how complex things really are". If you really want to understand the power > of a programming language you should look at the work of a competant user > with a view to modifying it. The reason so many professionals frown on > (unstructred) BASIC is because many of the programs produced using it end up > being so incredibly difficult to maintain. Are you talking about this specific example? Why is it rubbish? There are a dozen ways to read a string from the serial buffer that the BasicX interpreter provides, I cannot see why this code is rubbish. I have used it in many projects, and they all worked fine, albeit the other limitations of the BasicX which I won't dwell on all over again. The code was simply pasted from a project, and edited a bit for clarity, ONLY TO SERVE AS AN EXAMPLE. All I wanted to compare was the length of time it takes to write a simple serial input parsing function in Proton+ as compared to something that is almost Visual Basic for microcontrollers. Tell me if it's not quicker to write and hence debug the Proton+ version than the BasicX version? (some 70 lines vs. one) I have used the BasicX for some five years, so I think I'm in a position to tell you, and I don't need your judgement on wether it's rubbish or not. My years of work have shown me that the worst factor in the maintenance of ANY code in whatever languange, structured or unstructured, is COMMENTS, and not the language itself. I have been able to follow complex ASM stuff just because it was very well commented, and I admit I can't code in ASM to save my life. I have ported C code to Basic because it was well commented. I can look at a program I've written 10 years ago and follow it quite well because I comment almost *every* line. Yes, that's right, *every* line. Comments don't take space in compiled code, so they are free to write. Sloppy programmers don't comment their code, and that's when it's hard to maintain something someone else has written before you arrive. > So because you have trouble with one structured language you conclude that > they all have the same limitations? NO. What I am saying is that they ALL have their limitations. When I had to use an 18F452 to make a datalogger using it's own internal flash memory (the first code bank was for program, the other three for data), the only way I could erase a page before writing to it was using ASM embedded in the BASIC code - no function is provided to directly erase a page of flash. The limitation here was clear, but could be overcome. With the BasicX, once you bust the stack, the ONLY way to cure it is to start re-using variables, which makes it very ugly and MUCH harder to maintain codewise than other languages. Imagine having variables called dummy1, dummy2, etc. all over your code because if you declare ONE more byte variable the whole thing comes crashing down. Another example: Proton+ had it's parity broken when sending serial data out, i.e. even if you declared 8 data bits and one (say odd) parity bit, only the 8 data bits would get sent out. I had to bit-bang my own routine until the bug was fixed (which it was, and quite timely), but I have no problem with that. Having used BasicStamps, AVRs, PICs and BasicX, all of them for a number of years, and on serious commercial projects, I can say that they ALL have their own problems. There is no such thing as a perfect language, not even your XCSB which you write so much about (commendable effort to provide something like this, my hat off to you in this aspect). > XCSB has no such stack restrictions. Within it you can call functions to any > depth you like limited only by the amount of available RAM. You can create > many small well behaved well documented functions with meaningful names and > stitch them together in a meaningful easy to follow program without incuring > the overheads of many function calls - you don't need to repeat code you let > the compiler do all the hard work for you. Well, that's one thing I like about Proton+, that I know exactly where my limits are. Such PIC, so many bytes of RAM, so much program space. No hidden crash vectors. Nothing that can catch you when you are at 80% of the project and you have to redesign the whole thing because you start breaking things. I imagine XCSB is the same in this aspect, so here they both beat BasicX. If you are looking to write code as if you were writing Visual Basic, with all it's niceties, then use the BasicX. As always, PIC THE RIGHT TOOL FOR THE JOB. > would you not feel more > comfortable knowing that when things get complicated you can simply import > complex sections of code (written by others) WITHOUT impacting on what you > have already written? No worrying about variable name clashes or special > parameter / result passing protocols or RAM or code use. You cannot seriously expect to be able to import other people's code just like that, without any form of variable clash (unless you are lucky and they use n and m instead of x and y). You may be able to keep your own functions and libraries, which I have done for ANY programming language I have used. I declare all my variables at the start, so for me it's very easy to simply replace a variable if I see a clash. I have tons of code snippets in sepparate files which I can simply add, as I use the same variable names for similar things (i.e. i is always used in for-next loops, etc.) > With a programming > language such as Proton+ if you want to control specific hardware in an > efficient optimised way you are either dependent on the compiler writer > adding support for it or you have to write it yourself in assembler. Not really. Well, if you are talking about exotic hardware then you can usually bit-bang things, I have done this before in BASIC with no problems. There is no need to recurse to ASM for most things. Besides, most common protocols are already included, for example 1-Wire is present, and has been for some time. It is very easy and convenient to use. > On the > other hard XCSB recently aquired 1-Wire functionality because a user (Colin > Barnard) with no connection to the compiler writer wrote the library to > provide the functionality. And because of the optimisation built into the > compiler, the 1-Wire library is as efficient as if it had been implemented > by the compiler writer! Having this possibility is great, and of course more likely found on an open source or freeware project, than on a commercial project. You won't see many IDE / compiler suppliers opening up the doors for people to start writing their own plugins for them. You can write *around* them, but not *into* them. The latest Proton+ release includes a plugin API, with which you can pretty much do anything you want with the programs you write, i.e. serialize on each compile, have an on-line code snippet library, etc. Keep up the good work, I would just ask you not to pre-judge people's work without knowing their background. Regards, Mike |
|
|
Reply by ●November 25, 20042004-11-25
|
you are absolutely correct and very tactfully written. being a C programmer
myself I 100% agree you must include comments in your code. How else do you expect you college or the next person to come behind you and update and modify the code? Also I agree with all compilers has their own limitations. Believe I've tried a lot of them. I personally use 3 compilers; quick an dirty basic compiler, basic with floating point,and C compiler. so the best solution would be to have a variety of tools in your box and to pick the best compiler for the job. At 08:24 PM 11/23/2004, you wrote: >I'm sorry for jumping in here, but as the post concerning the BasicX example >on the Proton+ forums is mine, I feel I have a right to comment: > >----- Original Message ----- >From: "sergio masci" <> >To: <> >Sent: Sunday, November 21, 2004 4:12 AM >Subject: Re: [piclist] Re: Proton Development Suite > > Respectfully, I have seen all kinds of rubish produced by people that did > > not know what they were doing and who then pointed at it as an example of > > "how complex things really are". If you really want to understand the >power > > of a programming language you should look at the work of a competant user > > with a view to modifying it. The reason so many professionals frown on > > (unstructred) BASIC is because many of the programs produced using it end >up > > being so incredibly difficult to maintain. > >Are you talking about this specific example? Why is it rubbish? There are a >dozen ways to read a string from the serial buffer that the BasicX >interpreter provides, I cannot see why this code is rubbish. I have used it >in many projects, and they all worked fine, albeit the other limitations of >the BasicX which I won't dwell on all over again. The code was simply pasted >from a project, and edited a bit for clarity, ONLY TO SERVE AS AN EXAMPLE. >All I wanted to compare was the length of time it takes to write a simple >serial input parsing function in Proton+ as compared to something that is >almost Visual Basic for microcontrollers. Tell me if it's not quicker to >write and hence debug the Proton+ version than the BasicX version? (some 70 >lines vs. one) I have used the BasicX for some five years, so I think I'm in >a position to tell you, and I don't need your judgement on wether it's >rubbish or not. > >My years of work have shown me that the worst factor in the maintenance of >ANY code in whatever languange, structured or unstructured, is COMMENTS, and >not the language itself. I have been able to follow complex ASM stuff just >because it was very well commented, and I admit I can't code in ASM to save >my life. I have ported C code to Basic because it was well commented. I can >look at a program I've written 10 years ago and follow it quite well because >I comment almost *every* line. Yes, that's right, *every* line. Comments >don't take space in compiled code, so they are free to write. Sloppy >programmers don't comment their code, and that's when it's hard to maintain >something someone else has written before you arrive. > > > So because you have trouble with one structured language you conclude that > > they all have the same limitations? > >NO. What I am saying is that they ALL have their limitations. When I had to >use an 18F452 to make a datalogger using it's own internal flash memory (the >first code bank was for program, the other three for data), the only way I >could erase a page before writing to it was using ASM embedded in the BASIC >code - no function is provided to directly erase a page of flash. The >limitation here was clear, but could be overcome. With the BasicX, once you >bust the stack, the ONLY way to cure it is to start re-using variables, >which makes it very ugly and MUCH harder to maintain codewise than other >languages. Imagine having variables called dummy1, dummy2, etc. all over >your code because if you declare ONE more byte variable the whole thing >comes crashing down. > >Another example: Proton+ had it's parity broken when sending serial data >out, i.e. even if you declared 8 data bits and one (say odd) parity bit, >only the 8 data bits would get sent out. I had to bit-bang my own routine >until the bug was fixed (which it was, and quite timely), but I have no >problem with that. Having used BasicStamps, AVRs, PICs and BasicX, all of >them for a number of years, and on serious commercial projects, I can say >that they ALL have their own problems. There is no such thing as a perfect >language, not even your XCSB which you write so much about (commendable >effort to provide something like this, my hat off to you in this aspect). > > > XCSB has no such stack restrictions. Within it you can call functions to >any > > depth you like limited only by the amount of available RAM. You can create > > many small well behaved well documented functions with meaningful names >and > > stitch them together in a meaningful easy to follow program without >incuring > > the overheads of many function calls - you don't need to repeat code you >let > > the compiler do all the hard work for you. > >Well, that's one thing I like about Proton+, that I know exactly where my >limits are. Such PIC, so many bytes of RAM, so much program space. No hidden >crash vectors. Nothing that can catch you when you are at 80% of the project >and you have to redesign the whole thing because you start breaking things. >I imagine XCSB is the same in this aspect, so here they both beat BasicX. If >you are looking to write code as if you were writing Visual Basic, with all >it's niceties, then use the BasicX. As always, PIC THE RIGHT TOOL FOR THE >JOB. > > > would you not feel more > > comfortable knowing that when things get complicated you can simply import > > complex sections of code (written by others) WITHOUT impacting on what you > > have already written? No worrying about variable name clashes or special > > parameter / result passing protocols or RAM or code use. > >You cannot seriously expect to be able to import other people's code just >like that, without any form of variable clash (unless you are lucky and they >use n and m instead of x and y). You may be able to keep your own functions >and libraries, which I have done for ANY programming language I have used. I >declare all my variables at the start, so for me it's very easy to simply >replace a variable if I see a clash. I have tons of code snippets in >sepparate files which I can simply add, as I use the same variable names for >similar things (i.e. i is always used in for-next loops, etc.) > > > With a programming > > language such as Proton+ if you want to control specific hardware in an > > efficient optimised way you are either dependent on the compiler writer > > adding support for it or you have to write it yourself in assembler. > >Not really. Well, if you are talking about exotic hardware then you can >usually bit-bang things, I have done this before in BASIC with no problems. >There is no need to recurse to ASM for most things. Besides, most common >protocols are already included, for example 1-Wire is present, and has been >for some time. It is very easy and convenient to use. > > > On the > > other hard XCSB recently aquired 1-Wire functionality because a user >(Colin > > Barnard) with no connection to the compiler writer wrote the library to > > provide the functionality. And because of the optimisation built into the > > compiler, the 1-Wire library is as efficient as if it had been implemented > > by the compiler writer! > >Having this possibility is great, and of course more likely found on an open >source or freeware project, than on a commercial project. You won't see many >IDE / compiler suppliers opening up the doors for people to start writing >their own plugins for them. You can write *around* them, but not *into* >them. The latest Proton+ release includes a plugin API, with which you can >pretty much do anything you want with the programs you write, i.e. serialize >on each compile, have an on-line code snippet library, etc. > >Keep up the good work, I would just ask you not to pre-judge people's work >without knowing their background. > >Regards, > >Mike > > >to unsubscribe, go to http://www.yahoogroups.com and follow the instructions >Yahoo! Groups Links > > |
Reply by ●December 5, 20042004-12-05
|
Hi Tim, ----- Original Message ----- From: "timbox2005" <> To: <> Sent: Sunday, November 21, 2004 1:15 PM Subject: [piclist] Re: Proton Development Suite > But the main point is the Stamp style Pic Basic compilers are in a > different market. There for beginners and people in a hurry. I know a lot of professionals that use Proton to write professional products. We are again going into the downward slope of "your compiler is better than mine", as you rightly mention below. > Beginners what every thing handed to them on a plate, a good editor > that invokes the compiler and produces code with 1 click. They want > very comprehensive manuals; they want lots of pre made commands. Today's begginners yes, a few years ago you were taught by having to research things yourself, then asking for help. If you hadn't done the effort yourself first, you were usually told not so nice things. Todays students / begginners, as you say, want to be spoonfed. I don't agree with this at all, people should learn to put effort in their work. > People in a hurry want easy to use readable code and to be able to > just write:- > > Print at 1,1, bin12 vara > > Without having to write there own bin print routines In my book, time == money, which means that the faster I can do something, the more things I can do, and the more money I can earn. If you are on a salary, or a hobbyist, your position may be different. If I had to write the above in ASM, maybe I would have to charge a lot more for my projects. The end result is exactly the same, doesn't matter how you code it, so why argue so much about it? I have had to write inline ASM in some Proton projects, so there is no problem there. > Those who started with stamps at some stage want to move on, in the > past it was Pbpro Now, the Stamps AFAIK use interpreted code, the Stamp editor is not a "real" compiler per se, as it produces a set of tokens which are run by the "OS" inside the PIC. This is WAY different than Proton, PBPro or similar compilers, which produce true machine code that can run directly on the target PIC. I started with Stamps, moved to BasicX, and now have moved to PICs with Proton. Best regards, Mike |
Reply by ●December 5, 20042004-12-05
|
----- Original Message ----- From: Michael Puchol <> To: <> Sent: Wednesday, November 24, 2004 2:24 AM Subject: Re: [piclist] Re: Proton Development Suite > > I'm sorry for jumping in here, but as the post concerning the BasicX example > on the Proton+ forums is mine, I feel I have a right to comment: > > ----- Original Message ----- > From: "sergio masci" <> > To: <> > Sent: Sunday, November 21, 2004 4:12 AM > Subject: Re: [piclist] Re: Proton Development Suite > > Respectfully, I have seen all kinds of rubish produced by people that did > > not know what they were doing and who then pointed at it as an example of > > "how complex things really are". If you really want to understand the > power > > of a programming language you should look at the work of a competant user > > with a view to modifying it. The reason so many professionals frown on > > (unstructred) BASIC is because many of the programs produced using it end > up > > being so incredibly difficult to maintain. > > Are you talking about this specific example? Hi Michael, I am sorry that you have taken offence but I really was not talking specifically about your example. My statement (the one you quoted above) came after: :: > There is an example of why structured languages & systems, which allow :: > for parameter passing, have advantages and disadvantages. :: > <snip> :: > you define Subs and :: > Functions, which can receive parameters by value or reference, and :: > return results, etc. It is very practical in some ways, but extremely :: > cumbersome in others. Now this statement can be read in (at least) two ways: (1) yes structured programming and parameter passing is good but sometimes you want to do something really simple and it is frustrating to have to build functions the proper way, and (2) structured programming is OK but most of the time it just gets in the way of what you really want to do. Someone who started out by tinkering with non-structured languages will identify with view (2) and someone who has seen the benefit of using structured languages will identify with view (1). The "structured-language-o-phobe" does tend to try to justify himself by producing all kinds of crap because he is more intent on proving that his inital view was right than actually moving forward and admitting that there is a better way to do things. Now again, I not trying to insult or offend you. I am not saying that YOU are a "structured-language-o-phobe". What I was trying to say was that people can justify themselves by producing bad code if they really want to but they should look at some real code produced by a competent user if they really want to understand the benefits. I hope this has clarified what I originally wrote. > Why is it rubbish? There are a > dozen ways to read a string from the serial buffer that the BasicX > interpreter provides, I cannot see why this code is rubbish. I have used it > in many projects, and they all worked fine, albeit the other limitations of > the BasicX which I won't dwell on all over again. The code was simply pasted > from a project, and edited a bit for clarity, ONLY TO SERVE AS AN EXAMPLE. > All I wanted to compare was the length of time it takes to write a simple > serial input parsing function in Proton+ as compared to something that is > almost Visual Basic for microcontrollers. Tell me if it's not quicker to > write and hence debug the Proton+ version than the BasicX version? (some 70 > lines vs. one) I have used the BasicX for some five years, so I think I'm in > a position to tell you, and I don't need your judgement on wether it's > rubbish or not. Not applicable :-) > > My years of work have shown me that the worst factor in the maintenance of > ANY code in whatever languange, structured or unstructured, is COMMENTS, and > not the language itself. I have been able to follow complex ASM stuff just > because it was very well commented, and I admit I can't code in ASM to save > my life. I have ported C code to Basic because it was well commented. I can > look at a program I've written 10 years ago and follow it quite well because > I comment almost *every* line. Yes, that's right, *every* line. Comments > don't take space in compiled code, so they are free to write. Sloppy > programmers don't comment their code, and that's when it's hard to maintain > something someone else has written before you arrive. My experience has been different to yours. I have worked for many companies and organisations and I have found that often the comments are in error. People do not maintain the comments with the same diligence that they do the code. If the use of a variable changes or the behaviour of a function changes and the compiler spots a problem it will complain, if a bug manifests itself it will be tracked down and fixed but when a comment is incorrect it just sits there like a bear trap waiting to misguide you. The really bad thing about comments is that they move information way from the program and into the programmer. The compiler and assembler cannot use a comment to verify the code or understand it any better. Using more descriptive variable and function names does help, using sensible formal parameters does help, using manifest constants does help, using lexical scope does help. > > > So because you have trouble with one structured language you conclude that > > they all have the same limitations? > > NO. What I am saying is that they ALL have their limitations. When I had to > use an 18F452 to make a datalogger using it's own internal flash memory (the > first code bank was for program, the other three for data), the only way I > could erase a page before writing to it was using ASM embedded in the BASIC > code - no function is provided to directly erase a page of flash. The > limitation here was clear, but could be overcome. With the BasicX, once you > bust the stack, the ONLY way to cure it is to start re-using variables, > which makes it very ugly and MUCH harder to maintain codewise than other > languages. Imagine having variables called dummy1, dummy2, etc. all over > your code because if you declare ONE more byte variable the whole thing > comes crashing down. But is this not what using local variables is all about? Using local variables allows you to re-use RAM previously used by one variable for another variable. Scope helps the compiler identify which RAM locations can be shared between multiple variables. This is like increasing the amount of RAM available or having a variable called dummy1 and renaming it for you as fred, jack and bert when it is safe to do so. > > Another example: Proton+ had it's parity broken when sending serial data > out, i.e. even if you declared 8 data bits and one (say odd) parity bit, > only the 8 data bits would get sent out. I had to bit-bang my own routine > until the bug was fixed (which it was, and quite timely), but I have no > problem with that. Having used BasicStamps, AVRs, PICs and BasicX, all of > them for a number of years, and on serious commercial projects, I can say > that they ALL have their own problems. There is no such thing as a perfect > language, not even your XCSB which you write so much about (commendable > effort to provide something like this, my hat off to you in this aspect). > > > XCSB has no such stack restrictions. Within it you can call functions to > any > > depth you like limited only by the amount of available RAM. You can create > > many small well behaved well documented functions with meaningful names > and > > stitch them together in a meaningful easy to follow program without > incuring > > the overheads of many function calls - you don't need to repeat code you > let > > the compiler do all the hard work for you. > > Well, that's one thing I like about Proton+, that I know exactly where my > limits are. Such PIC, so many bytes of RAM, so much program space. No hidden > crash vectors. Nothing that can catch you when you are at 80% of the project > and you have to redesign the whole thing because you start breaking things. > I imagine XCSB is the same in this aspect, so here they both beat BasicX. If > you are looking to write code as if you were writing Visual Basic, with all > it's niceties, then use the BasicX. As always, PIC THE RIGHT TOOL FOR THE > JOB. > > > would you not feel more > > comfortable knowing that when things get complicated you can simply import > > complex sections of code (written by others) WITHOUT impacting on what you > > have already written? No worrying about variable name clashes or special > > parameter / result passing protocols or RAM or code use. > > You cannot seriously expect to be able to import other people's code just > like that, without any form of variable clash (unless you are lucky and they > use n and m instead of x and y). You may be able to keep your own functions > and libraries, which I have done for ANY programming language I have used. I > declare all my variables at the start, so for me it's very easy to simply > replace a variable if I see a clash. I have tons of code snippets in > sepparate files which I can simply add, as I use the same variable names for > similar things (i.e. i is always used in for-next loops, etc.) Actually yes I do expect you to be able to import other peoples code without any form of variable clash. Variables that are defined local to a function cannot clash with variables that are defined as global or local to any other function. By using parameters to functions to pass values into functions (not using globals) this further eliminates variable clashes. > > > With a programming > > language such as Proton+ if you want to control specific hardware in an > > efficient optimised way you are either dependent on the compiler writer > > adding support for it or you have to write it yourself in assembler. > > Not really. Well, if you are talking about exotic hardware then you can > usually bit-bang things, I have done this before in BASIC with no problems. > There is no need to recurse to ASM for most things. Besides, most common > protocols are already included, for example 1-Wire is present, and has been > for some time. It is very easy and convenient to use. > > > On the > > other hard XCSB recently aquired 1-Wire functionality because a user > (Colin > > Barnard) with no connection to the compiler writer wrote the library to > > provide the functionality. And because of the optimisation built into the > > compiler, the 1-Wire library is as efficient as if it had been implemented > > by the compiler writer! > > Having this possibility is great, and of course more likely found on an open > source or freeware project, than on a commercial project. You won't see many > IDE / compiler suppliers opening up the doors for people to start writing > their own plugins for them. You can write *around* them, but not *into* > them. The latest Proton+ release includes a plugin API, with which you can > pretty much do anything you want with the programs you write, i.e. serialize > on each compile, have an on-line code snippet library, etc. > > Keep up the good work, I would just ask you not to pre-judge people's work > without knowing their background. I really have not made any judgement about you or your work. If you would like to show me some of your work I would be happy to see it :-) > > Regards, > > Mike Regards Sergio Masci |
Reply by ●December 5, 20042004-12-05
|
----- Original Message ----- From: timbox2005 <> To: <> Sent: Sunday, November 21, 2004 12:15 PM Subject: [piclist] Re: Proton Development Suite > Believe me Sergio I do not deny that XSCSB is an excellent compiler. > What you can make a 14bit core pic do is great, and by using you own > assembler the core optimisation >2k know doubt is going to be superb. > > The Proton developers decided that to enable complete compatibility > with Mplabs and its tools they have to live with MPASM and all its > failings. > > Stamp style Pic Basic compilers are in a different market to your > product, XSCB is IMHO designed for seasoned writers who are prepared > to write code by the book. Capable to write there own routines when > there are non available, and understand the need to casting variables > in advance of calling procedures them selves. > > Is XSCB still only 14 bit core? Yes but XCSB is built on top of XCASM which is a meta assembler. Porting to a new processor is very straight forward but I need to address some of the points you raise first. > > As far as optimising goes what I indicated is only a brief example, > like you I could give more. > > But the main point is the Stamp style Pic Basic compilers are in a > different market. There for beginners and people in a hurry. Yes I understand what you are saying but I think people see XCSB as something which is far more complicated than it really is. The demo code and circuits I provide should really allow anyone to start tinkering and get off the ground quickly. > > Beginners what every thing handed to them on a plate, a good editor > that invokes the compiler and produces code with 1 click. They want > very comprehensive manuals; they want lots of pre made commands. > > People in a hurry want easy to use readable code and to be able to > just write:- > > Print at 1,1, bin12 vara > > Without having to write there own bin print routines At the moment you would write: char buff[8] int_to_str(buff, vara) LCD_set_pos(1, 1) LCD_write_str(buff) but this could easily be encapsulated into a function such as: proc LCD_print(ubyte x, ubyte y, int val) char buff[8] int_to_str(buff, val) LCD_set_pos(x, y) LCD_write_str(buff) endproc and then used as: LCD_print(1, 1, vara) But I hear what you are saying. > > Those who started with stamps at some stage want to move on, in the > past it was Pbpro, Proton now offers a that step up from stamps and > for Pbro users who want more var types, better data handling, Floats, > seamless GLCD support more commands etc. Know doubt if they feel > that they have out grown Proton they can move onto XSCSB. > > Please, please remember I do not want to start a "my compiler is > better than yours" fight. This excellent list deserves better than > that. > > As I said at the top Sergio, XSCSB sounds to be a great product. I > would though recommend that you put some more work into making it > easy to test and run. I would really like to try it out and check > just how good the optimisation is, I'll keep reading the included HTM > manual I'm sure the instructions on editors are in there some were. So an Integrated Development Environment (IDE) is important to you. The only one that I currently do is part of a much larger system and is expensive. Stef Mientki has an IDE called JALcc that supports XCSB which is available for free. > > Tim > Thank you for your comments Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
