The best programming language for me ...

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

Hello again ...

I looked at several programming languages, and thank all people who answered. For many reasons I think that for me and my applications the best programming language available at this moment is still GCBasic ! Free Pascal would have been fine too, with a better setup and user interface, the DOS mode window is a real disaster on the screen of W7 x64. sad

This topic has a solution.
Last Edited: Sat. Nov 21, 2020 - 06:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are comfortable with BASIC then you can get BASCOM-AVR  https://www.mcselec.com/index.ph...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The best programming language is Common Sense.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GCBasic is better than Bascom (allows multiple operations on the same line) ... and is free so it does not cost anything !

 

laugh

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

Pity it doesn't run on a AVR - it is a cross-compiler.

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

Bascom is a cross-compiler, too ... it runs on PC and produces code for AVR ; if one looks for a BASIC directly executable on the microcontroller, he should go back to the roots of PicBasic, there was a Basic INTERPRETER in the ROM !

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

It is unfortunate that neither Bascom nor GCBasic yet support the new AVR DB series...

 

JC

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

"Dare to be naïve." - Buckminster Fuller

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

DocJC wrote:

It is unfortunate that neither Bascom nor GCBasic yet support the new AVR DB series...

 

JC

I was waiting to hear from DocJC.    He is a regular user of Basic.    And is probably able to give his practical experience of BasCom and possibly GCBasic.

 

Perhaps you could clarify some points.

e.g. shortcomings of BasCom-AVR

e.g. shortcomings of GCBasic

 

There might be some members experienced with MikroElekronika PIC-BASIC

How well does PIC-BASIC work ?

 

Most Forum members are familiar with C, C++,  and possibly Assembler

A few members are experienced  with Basic.

 

Regarding this particular thread.     The OP is only interested in legacy hardware and legacy languages.    Even Assembler is considered "too large and complicated".

 

I am sure it would be "nice" if there was a Pascal Compiler for AVR.   Fortran possibly.

All the same,  it would be a very limited market and tiny User base.

 

David.

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

Bascom allows only one operation per line ; in GCBasic there is (was ?) a buffer overflow with too long strings, I don't know if this is still true or if the issue has been solced ; and about Pascal : some people say that it is possible to modify Lazarus to cross-compile (Free Pascal's UI is a disaster) ; but as I searched how I could do it, the instructions were, as so often, "Penguin contaminated", instructions only for Linux distributions, nothing for Windows. I admit that Pascal would be my preferred language, on Windows I use Delphi, so I would be interested if somebody could modify it to a "readymade" cross compiler for AVR, easy to install like GCBasic. There is a Fortran but development stopped 2 years ago and many features are missing (look on SourceForge) ; I contacted the developper, maybe he will complete his work ? If You are interested, there is a forum, till today I was the only guy who posted anything ... MikroPascal (and I think it is the same with MikroBasic) allows only hardware UARTS and only one soft UART, and this does not support strings, it works only "bytewise" ; GCBasic allows 3 soft UARTS with full variable support ...

Last Edited: Sat. Nov 21, 2020 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lemiceterrieux wrote:
Bascom allows only one operation per line

 

This seems unlikely.   Which is why it would be interesting to hear from genuine Bascom users.   

 

lemiceterrieux wrote:
in GCBasic there is (was ?) a buffer overflow with too long strings, I don't know if this is still true or if the issue has been solced

 

I don't know.   Surely you can test this yourself.    I seem to remember that PET-BASIC was limited to 255 characters.

Hey-ho.   Not many things would need longer strings.

 

lemiceterrieux wrote:
"Penguin contaminated", instructions only for Linux distributions, nothing for Windows.

Most developers / hobbyists would prefer Linux.

 

lemiceterrieux wrote:
I admit that Pascal would be my preferred language, on Windows I use Delphi, so I would be interested if somebody could modify it to a "readymade" cross compiler for AVR, easy to install like GCBasic.

Requires a somebody that is interested.    Your distaste for Linux might discourage them.

 

lemiceterrieux wrote:
If You are interested, there is a forum, till today I was the only guy who posted anything ...

Many things in life are like that !

 

David.

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

david.prentice wrote:
Most (sic?) developers / hobbyists would prefer Linux.

I don't know about that ...

 

IME, at the level of AVR, Windows seems more common?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe that the limitation in Bascom is now obsolete, I read it in a book by B. Kainka, Elektor edition ; and look here, the post by Danni at the end of the page. About GCBasic : I notified the string error on the forum, the answer was that it occured with (about, as I remember) 38 chars in length if somebody tried to send such a string via RS232. But the main advantages of GCBasic against Bascom : it is continuously developed and costs nothing !

 

smileyheart

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

for me and my applications the best programming language available is [xxxx]

 With qualifiers like that, I'm not going to argue with you.  It's unfortunate that there can't be more widespread agreement on "best" language...

I keep reminding myself how "ridiculous" it is that pre-Arduino, the most popular microcontroller environments for non-computer people were very slow and very limited interpreted BASIC systems (BASIC Stamp, 8051-BASIC.)  And yet, people accomplished amazing things...
 

 

GCBasic looks...

  1. like it allows most of the sorts of constructs that "real CS people" like to see in languages, as opposed to lots of line numbers and GOTOs.
  2. Not a lot like other BASICs.  This would be the main disadvantage, IMO.  One of the things that one gains by using a HLL is (theoretically) portability (better portability, anyway.)  With something like GCBASIC, you end up restricted to whatever chips that GCBASIC actually supports.  That's a good, but not great, range.  (No 32bit processors?)

 

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

Heh. Don't look at me... I'm currently trying to get a 1976 Microsoft Basic working in 6502 assembly on an emulator I have (mostly) written a gtk debugging wrapper for in C on Linux...

 

I don't hold that one language is 'better' than another; it all depends on your metrics for 'better'. Though I do hold a mild distaste for languages that are buried deep in abstractions and rely on dozens of user supplied libraries to work; I prefer to consider what the processor is doing rather than the UI or other behind the scenes stuff. But that's just me, probably.

 

 

 

Neil

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

Every language has its limitations and does not support all newer processors immediately ... I don't know if "commercial" compilers do already allow 32 bits PICs and AVRs. But, despite of the fact that I dislike some open source projects (Penguins ! ), I must admit that open source utilities like GCBasic evolve very faster than the others ... For example, the newest version of GCBasic came Oct 2020, and for comparison some other (commercial) compiler show a version from 2017 (and Murphy says that there are probably still some bugs left). So, maybe its only a question of time till GCBasic supports 32 bits processors, too ... And, on the other side, how many hobbyists do really need 32 bits processors ? I remember the time when I developped (in ASSEMBLER only) programs for the 6502, and compiled Basic on the C64, and this processor did everything I wanted him to do !

The only thing I am (a little bit) missing is a free Pascal, as easy to install and use as GCBasic.

Last Edited: Sun. Nov 22, 2020 - 07:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lemiceterrieux wrote:
how many hobbyists do really need 32 bits processors ?
How many hobbyists really need 8 bit micros? should they be using 1 bit micros or abacus'?

I'm surrounded by a zillion different types of 32bit (and 64bit) micros. I'm unlikely to use an 8bit micro. Plus I can run decent sized LISP programs with the extra ram available with many of the 32bit micros. Tiny basic also runs with a good turn of speed at 600MHz.

 

 

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

We are talking of software development for single board (or even single chip) systems and not supercalculators ... I spoke of the C64 because I used it (with I/O extensions) in the 80's to control a model railroad ... Todays an AVR8515 performs the same work, and it's much less expensive !

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

I am talking about single chip micros. The state of the art has moved considerably since the 6502.

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

Bascom allows only one operation per line

 

That is true for math operations.

 

Bascom only allows one operation per line of code.

So one can write as complex an equation as one desires, but it has to be written in single steps, one per line.

 

N = 5 * (X+Y) has to be coded as

N = X + Y

N = N * 5

 

Not a big deal, just not the norm.

 

ZBasic is another uC basic, which will parse normal mathematical equations written on one line.

It also includes a built-in multi-tasker.

 

Both Bascom and ZBasic have excellent support, with ongoing upgrades and bug fixes.

The last update for Bascom was an add-on package for the new XTiny chips.

The AVR DA, DB, … series is not yet supported.

When I had some early pre-release XMega chips Mark sent me a new / pre-release version of the " .dat" file for them to test the new chips, (great support!). 

 

I've never used MicroBasic, when I investigated it vs Bascom and ZBasic it seem to have a fair number of unresolved "features".

 

Fortran is great for running complex math operations on large data sets on a PC, (or larger processor).

It isn't well structured for real-time processing on an 8-bit micro, that isn't its nitch.

 

I've look at GCBasic a time or two, but I tend to use Bascom on the AVRs, and MS Studio / Basic on the PC.

If GCBasic supported the new AVR DB chips I would certainly use it for those chips.

 

What I find nice about Bascom is that it has sooo many HLL instructions that I can focus on the global concepts of what I am trying to accomplish without getting bogged down in the nitty-gritty details of the coding.

At times, when checking on the syntax for some instruction, I've seen a new instruction that performs some function for which I'd previously written a subroutine.

 

Its been quite a while since we had a good "my language is better, (faster, compiles to less memory, …), than your language" Thread!

 

At the end of the day it simply makes sense to use what works best for you!

That could be C, C++, Basic, etc.

 

JC  

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

DocJC wrote:

Bascom only allows one operation per line of code.

So one can write as complex an equation as one desires, but it has to be written in single steps, one per line.

 

N = 5 * (X+Y) has to be coded as

N = X + Y

N = N * 5

 

Ah-ha.  That is unusual.   I would expect any language to handle expressions (whether compiled or interpreted).    PETBASIC did. 

It is interesting to hear your practical experience.   You obviously have learned to live with this.    And HLL instructions for peripherals and hardware would be important.

 

I have sympathy for lemiceterrieux .   That would be a deal breaker for importing legacy code.

Of course you could bung it through a SED script as a one-time expression splitter.   I would still be irritated.

 

lemiceterrieux wrote:
I must admit that open source utilities like GCBasic evolve very faster than the others ... For example, the newest version of GCBasic came Oct 2020, and for comparison some other (commercial) compiler show a version from 2017 (and Murphy says that there are probably still some bugs left).

Infrequent releases generally mean that the product is stable.

Of course it can just mean the authors have lost interest.

 

A handy tip.   Visit the GitHub project.   Observe how well authors respond to Issues and Pull Requests.    Observe code tweaks on the Beta.   Observe the Release version dates.

 

David.

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

PS : finally I tested MikroPascal again, and I am again hesitating between GCBasic and Pascal. Till today, my projects remained under the "fatidic" size limit for which I must register, so I can keep on testing Pascal. I must admit that finally this language is my preferred ...

Last Edited: Mon. Nov 23, 2020 - 11:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I maybe missed this but what does the choice of language actually matter? Why not C or C++ like 95% of the other folks who program AVRs in which case you can share code and knowledge. All procedural languages (C, Basic, Pascal, Ada, Java, Python,....) are all much the same at the end of the day and it's simply a question of "how do you construct a while loop or a for loop or whatever in this particular one?"

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

I'm in the same boat as OP, PASCAL. Had it at high school CP/M compass pascal (also called turbo pascal), and later university, then PC turbo pascal -> delphi

And a pascal for the 8051. If not pascal then ASM :) .

 

ok now I program mostly in C because the customers want's it that way. (and python for the PC side for test).    

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


First "structured language" I learned was Pascal (uni 1981) rather than C etc - which is a good thing because of strong typing etc makes you more aware of mixing types and so on. It (original Pascal) also doesn't have pointers which is where the vast majority of problems in C start (but also what makes it so "powerful"). I still have my copy of "Grogono" somewhere:

 

But for AVR I would go with learning Arduino (so C++) or C (if not Asm) so I could piggy-back onto all the existing library code for many many devices - so I wouldn't have to end up reinventing the wheel for the vast majority of devices I might want to drive. Imagine re-writing FAT for SD/MMC from scratch rather than simply using EL Chan's FatFs for example. Or maybe HD44780 rather than Fleury LCD etc. All that stuff is in C so it seems the most productive pace to start.

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

I can already write programs with :

- Fortran

- Assembler (for 6502, but they all look the same)

- Basic (and VBA)

- Pascal (and Delphi)

- Forth

WHY SHOULD I LEARN THE SYNTAX OF ANOTHER LANGUAGE ? AND WHAT SHOULD I SHARE ? Utilities for a model railroad with conventional (not even DCC) control ?

I attached the code of the sequencer for my railroad layout (converted from GCBasic, but not yet tested), sorry everything is in French. Which routines could be re-used by other programmer ?

 

sad

 

Attachment(s): 

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

They're all rather "niche".

 

What you could gain with 'C' or C++ is the far wider pool of resources.

 

But if what you already have meets your needs - that's fine.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
What you could gain with 'C' or C++ is the far wider pool of resources.
This.

 

Given a free choice I'd program AVRs in Python probably but the reason for using C/C++ is because "everyone else does". So if you want help or you want to borrow some tried/tested code to get something going quickly (particularly true in the land of Arduino) you would choose C (which is "easy" by the way! ;-) so you can benefit from all the existing work and knowledge.

 

Let's just take one scenario - suppose you wanted to be able to decode (for display) small PNG and JPEG images on your AVR - how are you going to achieve that? Do you dig out the book to find out what a Discrete Cosine Transform is then meticulously code that into Pascal/Basic/whatever or do you get on to github.com, download one of 50 existing image decoders in C/C++ and just get on with life.

 

Of course it might be the case that you are simply interested in learning the mathematics and technique of JPEG decode (or whatever it happens to be) and by encoding something from scratch in a language it's unlikely anyone else has ever used for the same job that you will achieve something in itself. But if your real goal was simply "to get a picture on a screen - you could probably have been there in half an hour using someone's existing C.

 

BTW I will bet that most work done model railway DCC is in the form of C code too ;-)

Last Edited: Mon. Nov 23, 2020 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


clawson wrote:
BTW I will bet that most work done model railway DCC is in the form of C code too ;-)

I don't know what language they wrote it in, but this was at the last Basingstoke mode railway show:

https://www.youtube.com/watch?v=...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


clawson wrote:

BTW I will bet that most work done model railway DCC is in the form of C code too ;-)

 

Yep.

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."