For programming microcontrollers, I know that both C and Bascom are suitable (Assembler is even more, but put that aside for now).
What bothers me is:
What are pros and cons for C or Bascom? Are there any? Is it only a question of the person programming a microcontroller and where his or her preferences lie?
BASCOM is OK for entry level hobby work.
Students should never use unstructured BASIC - it imprints very bad design habits that an employer would not want. Even as a hobby endeavor, you'll find that unstructured spaghetti-code BASIC becomes a confusing and unwieldy mess after about 100-200 lines of code. Kind of like a hardware breadboard with 50 jumper wires.
There are a few good structured BASICs around - like ZBasic.
So if your goal is to enhance your professional endeavors in small embedded microprocessors, you really need fluency in C/C++, modular functions, and a bit of assembly language.
?
I've just never understood why using Basic makes one a bad programmer...
In the real world these days, however, you need to know C/C++.
I don't, but electronics isn't my main occupation.
That said I've done a bunch of projects with Basic.
Use what makes you the most productive and that which you enjoy using.
At the end of the day the customer, (usually me, for my own projects), sees the case, the user interface, and knows whether or not the device does what it is suppose to do. They aren't looking at whether you used a very clever algorithm, or just straight coded a routine. They often don't even care what you coded it in.
Life is too short to sweat the small stuff.
JC
Edited.
At a time not so long ago nor so far away, there WAS a big difference between BASIC and C. BASIC was interpreted. "token" and numbers were stored in memory and an interpreter ran the code (essentially a "script", in modern terminology). C was compiled directly to machine code. So, BASIC was much slower.
Now, the differences are much smaller. BASIC (mostly) compiles to machine code. So, the differences are primarily in how standard functions are implemented behind the scenes. Without any real knowledge, I would guess that for most operations, any "good" BASIC will be very close to c. Maybe some differences but less than "interpreted vs compiled".
Jim
any "good" BASIC will be very close to c
I think Bascom is a good choice for one who only wants to make some hobby constructions and does not plan to earn money as a programmer.
I have some experience in Bascom, and when I see in this forum how beginners and students struggle with C in simple projects, I tell myself that their life would be much easier with Bascom.
i think C sufficient to meet most of the microprocessor.
i mean choice your interest in and specialization it
I think it's quite interesting to read the OP's other 8 posts for more background about this C vs Bascom choice.
What are pros and cons for C or Bascom? Are there any? Is it only a question of the person programming a microcontroller and where his or her preferences lie?
?I've just never understood why using Basic makes one a bad programmer...
Full disclosure: I haven't used any Basic in my AVR apps.
Does that make me a "good" programmer, or Basic programmers "bad" programmers?
Dunno if I'd call it "bad". Production AVR apps are essentially my profession, unlike Doc. So, if any of the AVR Basics can do skinny ISRs as in the link(s) below, then I'd have no problem with anyone that uses it. There is so much more sample code for C, though, that the Basic programmer my find him/herself re-inventing stuff.
https://www.avrfreaks.net/index.p...
(search for "REG_LEEWAY")
https://www.avrfreaks.net/index.p...
(search for "HALLB")
I think that much of the complaint about "bad BASSIC" has to do with the use of GOTO statements that results in spaghetti code. Not all BASIC programmers do this, and BASIC >>CAN<< be as structured as C. To be fair, C also has a "goto" statement, the use of it being strongly discouraged by modern programming texts.
So, there really should be no reason to label BASIC programmers as "bad programmers".
As a note to the OP,
What are pros and cons for C or Bascom? Are there any?
C has long had the reputation of allowing the programmer to get "closer" to the hardware. That argument is becoming less and less meaningful, IMHO, due to the increasing tendency to hide the hardware in "drivers" so that the programmer does not have to learn about the messy details of that greasy-grimy hardware stuff. In this sense, C is gradually shifting toward where BASIC has been for a long time. True, c lets you get closer to the grease, but who wants to? I would argue that any serious embedded programmer ought to!
Jim
There is so much more sample code for C, though, that the Basic programmer my find him/herself re-inventing stuff.
Have to agree with this one.
For the simple stuff Bascom also has a forum, application notes, and examples. But, as an example, for two of the Graphics LCDs I've used I wrote my own driver. It wasn't a problem for me, but I don't survive by how many finished products I turn out in a year. If I did it would be nice to have a larger assortment of fully debugged and documented libraries. I particularly miss canned FAT, USB, and eithernet libraries, although there are some (limited) examples out there. Reinventing the wheel is expensive when you are on the clock.
Skinny ISR...
To be trueful, I've not had many occassions where it made a big difference. Incrementing a counter or two or setting a flag doesn't take many clock cycles regardless of the language used. If the time windows are soooo tight that it matters, I've just grabbed a faster chip, (or clock), and not worried about it, rather than try to shave a few cycles off the ISR.
Such was the case on a GPS application where the uC was reading the NMEA, doing some time / distance / heading / etc. calc's, displaying the data, and plotting on a GLCD. What was difficult at 14.xxx MHz was easy at 20 MHz. (And easier yet at 32 MHz!).
Although it would have been possible to spend hours tweaking the code, the other approach was easier, faster, and didn't violate any cost/power/design constraints.
The exception is probably projects like Jesper's software DDS where a truely optimized ISR bumps up the project's specifications. Others exist, too, (FFTs, Digital Filters, (i.e. DSP on an 8-bit micro...)).
C has long had the reputation of allowing the programmer to get "closer" to the hardware.
Fortunately with Bascom this isn't an issue. Although I love the "high level" commands, like setting up an ISR driven, buffered USART in one instruction; in Bascom one has direct access to all the registers, also. I think setting up Timer/Counters in CTC mode is the best example. Bascom has only a few of the many possible configurations for the Timer/Counters built into the high level commands, so one reads the data sheet and sets a few registers directly for some operations.
This was also the only way to program the Xmegas, initially, as it took two or three versions to get the majority of the language upgraded to support them. (No longer an issue.)
Bascom also lets one insert in-line asm code, as did the Basic I use to use on PICs. But again, I don't do this enough to stay proficient at it.
Line Numbers and Gotos haven't been used since Dartmouth... :wink:
Mind you I have nothing against C. I've repeatedly stated that I think these days students in Engineering and CS should learn C. Otherwise one should use what they are most comfortable using, proficient at using, and enjoy using. Or what the boss is paying one to use.
Life is truely too short to sweat the small stuff! Excluding large team projects, which language one uses to get the job done is, I think, frequently in the realm of "small stuff".
JC
Hobby - fine. Have a blast.
Professional/student, not.
However, its a Big World and there's something for everybody. There are a bunch o niche langauges, and evidently there are folks that can really do productive stuff in python, ruby on rails, stuff I have no idea about. Good pilots probably aren't good aerodynamicists. Guys that drive Alias Wavefront like a sports car probably didn't ever write lo level 3d stuff like shading and rotations and polygon sorting. I did Turbo Pascal exclusively for years and everyone was bustin my chops... "Why not just do all that in c?" I don't know the exact analogy I'm trying to express here except that as things grow more complex, the ability to understand down to the gate level gets harder. USB: real complicated, but used as a module in a library. Telephones: complicated, but easy to use. Hope this blather made sense to someone.
Hope this blather made sense to someone.
What is the argument between hobby/professional? Truely, it has no bearing. What is so wrong with working professionally with BASCOM? If you and everyone else who needs to read the code understands BASCOM, where is the need to switch to C?
And honestly, to say C is more structured than BASIC is just being ignorant. That is the equivalent of an english-speaking person saying the Chinese should learn English, because it is more structured than Chinese. Clearly the Chinese have a different opinion.
There is nothing you can do in C that you cannot do equally well in BASCOM. I will take up any challenge pertaining to this statement.
The libraries argument is nil, since in C as in any other language, the libraries are specific to the compiler. There are plenty of compiler specific libraries included with BASCOM, as part of the source packages you get with the full version.
I agree with your sentiment in general. I only observed this, that might need moderation:
The libraries argument is nil, since in C as in any other language, the libraries are specific to the compiler.
Johan,
Only thing is that "library" code tends to have been written to use "special features" of the C dialect that may stray outside the C standard. For example, I guess it could be tempting for someone writing "library" code for GCC to use something like "0b" prefixed numbers. Or for someone writing CV code to use PINB.3 style access etc.
So yes, if you can find library code (perhaps a JPEG decode routine?) that has been written in 100% ANSI standard C then you would hope, wouldn't you, that it could simply be compiled on all the compilers.
Cliff
Well ok, you can port libraries from one compiler to another. You still have to port though. Do you have an example of an application on AVR for which you would use a third party library that you would likely have to rewrite completely in BASCOM?
Also, doesn't that make the C programmer the worst of the two, reusing code he has not written that he does not understand fully? ;)
Also, doesn't that make the C programmer the worst of the two, reusing code he has not written that he does not understand fully?
1) (Re-)using code one has not written oneself increases productivity.
2) Regardless of what language and compiler you use you use code that someone else has written.
3) Are there no "libraries of sort" in BASCOM?
4) [rhetorical ]Do you write everything yourself? Always?
I hereby confess that I do not fully understand e.g. the code in the printf-implementation in avrlibc. But I trust it at least as much as code I have written myself.
You still have to port though.
Again, I am not a sworn enemy of the BASIC family of programming languages, but this should be a fair trial. Shortcomings of BASIC languages are lack of standardization, and weak cross-platform support IMO. It's strengths are (arguably) a more "friendly" syntax, or at least perceived such. I suspect that BASCOM as such has special constructs that cater for embedded stuff in general and AVRs specifically, which is good (or at least partially good, if one argues that this is a two-sided coin, with the bad side again being portability problems).
Only thing is that "library" code tends to have been written to use "special features" of the C dialect that may stray outside the C standard. For example, I guess it could be tempting for someone writing "library" code for GCC to use something like "0b" prefixed numbers. Or for someone writing CV code to use PINB.3 style access etc.
After using BASIC, FORTRAN, SNOBOL, PASCAL, FORTH, C and VB6 you have to, "love the one you are with". They all have worked well for applications at the time. Often the programming language was not my choice, just the tool provided for me. C has provided me more than 20 tears of language stability. I like that.
BASCOM most likely will get the job done too. I do not think it will take over as the programming choice in the corporate world.
C has provided me more than 20 tears
There is nothing you can do in C that you cannot do equally well in BASCOM. I will take up any challenge pertaining to this statement.
So, post the BASCOM equivalents and the resulting machine language.
NB: On Burroughs systems, COBOL was a systems development language. The underlying Medium Systems >>was<< a COBOL machine. You could do everything well in COBOL.
On DEC VAX/VMS, the Fortran compiler was so evolved that it also could be considered a systems development language. You could do everything well in Fortran. As with Basics, there wasn't a line number or go-to label number in sight.
Make me a believer, Hugo.
Do you have an example of an application on AVR for which you would use a third party library that you would likely have to rewrite completely in BASCOM?
Lee
I do not have a framework to test with, though given a little more time I could show you ASM that would likely be identical to your compiled examples...
Pin_change_isr2:
If Not Halla Then
If Hallb Then
Position = Position + Rotation
Else
Position = Position - Rotation
End If
Else
If Not Hallb Then
Position = Position + Rotation
Else
Position = Position - Rotation
End If
End If
Return
Timer1_capt_isr:
Reg_partial = Icr1
Reg_difference = Reg_partial
Reg_difference = Reg_difference - Reg_previous
Reg_previous = Reg_partial
Reg_difference = Reg_difference - Reg_target
Reg_partial = Reg_leeway
If Reg_difference > Reg_partial Then
Reg_count = 0
Else If(reg_count + 1) > Reg_needed Then
Set Flg_pulse_done
Disable Icp1
End If
Return
EDIT: In fact, I can even optimize your second ISR a bit:
Timer1_capt_isr:
Reg_partial = Icr1
Reg_difference = Reg_partial - Reg_previous - Reg_target
Reg_previous = Reg_partial
If Reg_difference > Reg_leeway Then
Reg_count = 0
Else If(reg_count + 1) > Reg_needed Then
Set Flg_pulse_done
Disable Icp1
End If
Return
As for the Atmel RF stuff, I guess you got me there. Although I'm sure some digging would find me an ASM library which I could just link to...
C has provided me more than 20 tears
I have tears when I attempt to use VS2010
Oh man, how true. It took days to get a simple serial comm link from VB2010 to a Mega168 to work with a binary data stream, instead of just a 7-bit ASCII character stream.
It took a Thread posting here to finally get me on the right track!
Should have been trivial!
JC
The problem you were having with the serial port has nothing to do with the language, its the .NET API at large... You would have had the same problem with VC since it uses the exact same object from the Windows API...
Officially the usual answer is "Switch to USB."
Same goes with the parallel port. Officially unsupported in Windows Vista and up unless you use a signed driver.
I know this is pretty much beating a dead horse by now but:
I particularly miss canned FAT, USB, and ethernet libraries, although there are some (limited) examples out there.
All three are [more or less] natively supported by BASCOM now...
Hard to believe the OP is no where to be seen, it's not like his thread got high jacked.
Has anyone seen the OP recently? ;-)
<----------------- he's over there...
What are pros and cons for C or Bascom? Are there any?
My short answer... There are more freely available examples for 'C'!
There are more freely available tutorials for 'C'!
There are more freely available example projects/code for 'C'!
There are more 'C' programmers. Thus there is a wider user base to talk to in 'C'!
BTW: I use 4 different languages every working day. I don't have a favorite. Over my time I've probably had to learn 15-20 languages. They ALL have a job to do and a place and a time for being used.
I do not have a framework to test with, though given a little more time I could show you ASM that would likely be identical to your compiled examples...
[I'll have to look over your improvement. :) ]
Lee
EDIT: In fact, I can even optimize your second ISR a bit:
The optimization was mostly getting rid of one 16-bits register copy... ;)
Bascom has a lower level to entry if you aren't a programmer; C is a bit harder to learn, from my experience - also lots of non college teaching when it comes to programming is in basic (or pascal). (Again, IME)
TR
(Long time Bascom user)
Oh, and I've written a 9600 baud serial port (RX) in software in bascom; just using an external interrupt pin to kick the ISR.
Bascom was limited in parsing expressions.
So only one operation per line was allowed.
Also Bascom can not calculate constant expressions at compile time.
So in Bascom you must write down "magic numbers".
In C you can direct write down the formula.
It generate no additional code.
So C code was better readable and need less comments.
Peter
On DEC VAX/VMS, the Fortran compiler was so evolved that it also could be considered a systems development language. You could do everything well in Fortran.
For a "dead language", it's amazing how much fortran keeps on popping up. Intel support a fortran compiler (and it's FAST!) for high performance computing applications (supercomputers). Fortunately, gfortran is generally good enough on (Linux) embedded systems, though you'll generally have to compile your own toolchain (crosstools-ng rules!).
Maybe we should ask the mathematicians/scientists to re-write their libraries in C ;)
-- Dmaien
