Programming: Bascom vs. C

Go To Last Post
36 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Last Edited: Tue. Jul 11, 2017 - 11:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

where his or her preferences lie?

Got it in one - try a bit of each - pick what you like.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

?

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.

Last Edited: Sun. Jun 5, 2011 - 12:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
any "good" BASIC will be very close to c

If not to C++, like Visual Basic.net with all those classes, objects, constructors etc.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i think C sufficient to meet most of the microprocessor.
i mean choice your interest in and specialization it

ElecFreaks
Home Page: http://www.elecfreaks.com/
Email: support@elecfreaks.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think it's quite interesting to read the OP's other 8 posts for more background about this C vs Bascom choice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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?

Quote:

?

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")

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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,

Quote:
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

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
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...)).

Quote:
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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hobby - fine. Have a blast.

Professional/student, not.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Hope this blather made sense to someone.

I ran it through Google Translate: Uncle Bob to English, and it spit out "Obama did it."

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with your sentiment in general. I only observed this, that might need moderation:

Quote:

The libraries argument is nil, since in C as in any other language, the libraries are specific to the compiler.

Really? Always? (I.e. what actually differs between e.g. the avr-gcc compiler and say CodeVision or ImageCraft? (I can think of ISR syntax, flash and EEPROM handling off hand). But there should be many areas where a library should easily be portable between compilers. (This is one of the real strengths of the C language. It is strictly standardized. Only a few things varies between compilers, so if you layer your software with care large parts of it could be portable).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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? ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
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?

No.

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.

Quote:

You still have to port though.

Yes, those few things that differ. And those can be isolated. They will make up a small or even tiny fraction of the source code.

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).

Quote:
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.

That would be against our advice, then. Both you and I have argued here to stick to standard C as far as possible. Specifically we have argued for the 1<<bit_number idiom for constructing a bitmask, rather than e.g. the PINB.3 CV style that not only isn't supported by all compiler but actually is in clear violation of the C standard.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
C has provided me more than 20 tears

Freud would be proud...

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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.

See my earlier post. I'm not issuing a challenge so much as I'm interested whether the AVR Basics (and for you, apparently, BASCOM in particular) have the facilities to produce skinny ISRs. The two I posted links to have the resulting machine language. those two ISRs are critical to the production AVR design.

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.

Quote:

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?


Lessee--all the Atmel RF stuff--Raven and the like?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
C has provided me more than 20 tears

Chuck:
I meant years, a typo. I have tears when I attempt to use VS2010 using example code from VS2005 or VS2008. Makes me think this dog is too old for new tricks or the VS is not what it should be.

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know this is pretty much beating a dead horse by now but:

Quote:
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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone seen the OP recently? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hard to believe the OP is no where to be seen, it's not like his thread got high jacked.

clawson wrote:
Has anyone seen the OP recently? ;-)

Gary - W4GNS
Tel: BR549

In my many years I have come to a conclusion that one useless man is a shame, two is a law firm and three or more is a congress. -- John Adams

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

<----------------- he's over there...

Quote:
What are pros and cons for C or Bascom? Are there any?
He probably got bored waiting for an answer.

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.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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...


But that is the part I need to see--the generated code. I purposefully picked examples that are indeed straight coding. I'd bet several virtual cold ones that GCC sequences wouldn't be as "skinny".

[I'll have to look over your improvement. :) ]

Lee

Quote:
EDIT: In fact, I can even optimize your second ISR a bit:

Surely you would be free to make that re-ordering. With my compiler it would want to introduce a temporary to calculate the expression, while when I have it "unrolled" the operations are done directly on the 16-bit global register variables. That is indeed part of the skinniness.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The optimization was mostly getting rid of one 16-bits register copy... ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

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

Topic locked