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. 
If you are comfortable with BASIC then you can get BASCOM-AVR https://www.mcselec.com/index.ph...
The best programming language is Common Sense.
GCBasic is better than Bascom (allows multiple operations on the same line) ... and is free so it does not cost anything !
Pity it doesn't run on a AVR - it is a cross-compiler.
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 !
It is unfortunate that neither Bascom nor GCBasic yet support the new AVR DB series...
JC
re PIC
micropython/ports/pic16bit at master · micropython/micropython · GitHub
Some PIC24 have EPMP (a lot of SRAM data space)
If one is looking for a challenge :
Python for the 8bit AVR mocrocontroller · Issue #3699 · micropython/micropython · GitHub
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.
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 solved ; 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 ...
Bascom allows only one operation per line
This seems unlikely. Which is why it would be interesting to hear from genuine Bascom users.
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.
"Penguin contaminated", instructions only for Linux distributions, nothing for Windows.
Most developers / hobbyists would prefer Linux.
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.
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.
Most (sic?) developers / hobbyists would prefer Linux.
I don't know about that ...
IME, at the level of AVR, Windows seems more common?
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 !
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...
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
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.
how many hobbyists do really need 32 bits processors ?
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.
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 !
I am talking about single chip micros. The state of the art has moved considerably since the 6502.
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
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.
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.
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 would be my preferred one ...
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?"
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).
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.
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 ?
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.
What you could gain with 'C' or C++ is the far wider pool of resources.
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 ;-)
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=...
BTW I will bet that most work done model railway DCC is in the form of C code too ;-)
Yep.
Hello again (alberich = lemiceterrieux)
About Lazarus : I installed the last version available on SourceForge (for Win x64) and, in "Project > Options > Target" (translated from French), I selected "avr" and de-selected "Graphic application" (look at attachments, Screen copy 1). But with "OK" I got ... Screen copy 2 ! Are there some more configurations to be done, or some files to be added (and where should I copy them ? ). Thanks for any answer ...
@ alberich = lemiceterrieux
I strongly advise choosing the language that is favoured by the "Model Railway Community".
Ask on their Model Railway Forums
It might require a bit of self-education but at least you will be able to use their proven designs to get you started.
Help from AvrFreaks:
I am not familiar with GCBasic, BasCom, MikroBasic, ... but I would be inclined to select the most common dialect used by AvrFreaks members.
Basic of any form does not have many users here.
I would give similar advice about any subject. i.e. follow the popular route. e.g. Arduino, avr-gcc
Not because one language is better. But because more members have the experience. Proven code and working projects can be replicated.
David.
About Lazarus
As already noted, this is not really the place for Lazarus support.
Try: https://forum.lazarus.freepascal.org/index.php
And: https://wiki.freepascal.org/
and maybe other resources at https://www.lazarus-ide.org/
I strongly advise choosing the language that is favoured by the "Model Railway Community".
Pick one...
* PIC processors programmed in assembler
* PIC processors programmed in JAL
* Arduino
Thanks for Your answers ...
To awneil : I posted almost the same on Lazarus forum.
To Brian Fairchild : I am afraid that my whole system has nothing in common with usual layouts, it looks more like the control program for a washing machine than for other (DCC'ed) layouts. For example, my avatar on a railroad forum is "No DCC Please" ... . In the 80's, I built a layout controlled in (compiled) Basic by a ... Commodore 64 !
Hello again (alberich = lemiceterrieux)
Why the hell did you create TWO accounts!? 
Pick ONE and STICK WITH IT!
Jim
As I wrote, I had simply forgotten that I had already created a profile more than 18 months ago ...
I had BASIC in High school, then Fortran and Pascal in college, also some C classes at a community college that did not benefit the degree. At work, I used some C, but mostly VB, before tripping over Python. I tinkered with Perl and TCL before finding Python also. Recalling now that I did a fair amount with TCL, I guess it was the expect tool that made TCL powerful for what I did. Then I started tinkering with Python; it was a perfect fit; I did not even have to read the instructions; I just typed some pseudo-code and tested it with the interactive prompt, holy cow that was mind-blowing at the time.
The rail-roads in the Factorio game have me wanting to build a model railroad system with a pathing/signaling system that works somewhat like the game.
It is perfectly understandable to use what you know, but if you don't use what the community does, that is sort of a problem (though I am guilty also).
BASIC in High school,
BASIC was created in & for a high school.
Modern versions probably share little more than the acronym ...
Modern versions probably share little more than the acronym ...
like the amount of Java in JS? VB felt like BASIC, well... yep now that I think about it...
Meanwhile I tested Bascom ; I could live with the limitation of one mathematical operation per line (for comparison, GCBasic does not "like" several string concatenations in one statement). What is more annoying is that it seems not to accept parentheses around test expressions, so it would not be possible to define priorities between "and" and "or" operators in complex expressions ...
Then split complex expressions which then makes the code (in any language) more easy to read and follow anyway!
.
Code should not be written as a challenge to the reader "they'll never work out what's going on here"
and the processor has to do it all one step at a time anyhow - so that shouldn't have much (if any) impact on the generated code ...
Hi,
it also depends on the need you have. Since a model railroad should have plenty of space you are not really limited to a physical small micro controller. But maybe you have some time critical wishes like RS232 / RS485 communication or reacting to external interrupts you might get a problem with some high level programming languages. Since a Raspberry Pi might not have such limitations they might exist on small micro controllers.
I started to write a speed controller for an ATTiny85 in assembler a few years ago (but because of shortage of time I did not finished all my planned functions) for using in a model R/C car. I have to detect an incoming signal which has an signal length between 1ms and 2ms and usually a gap between two signals of about 20ms. I tried to use a timer to measure the signal length, but since the ATTiny85 (I chose this one because of it's small size, the model truck is in 1:87 model rail road size) has only 8 bit timers I had to build a 16 bit counter. Usually everything works, but sometimes there is a timing problem if the external signal ends and causes an interrupt, but the 8 bit counter runs into an overflow. So I tried to detect this in the interrupt routine, but it is difficult to test.
If I had used a high level language like Basic or even Pascal I might not have thought about this an maybe I interpreted the signal length wrong. Since there might be stick positions on the sender which will cause permanent this error I might receive constantly a wrong value.
Since this thread is not about my problem and I do not like to discuss this in this thread it is just an information from real life which I can share. Maybe lemiceterrieux can give some more information about his plans (what do you like to do and which hardware do you like to use). So the pros can help a little bit better.
But my opinion is: programming micro controller should use a low level language like C or assembler.
Regards,
Nils
a model railroad should have plenty of space
surely, that depends on the gauge/scale ?
There's not that much spare room inside a OO/HO model locomotive ...
EDIT
Then again, "physically small" micros are not necessarily resource-starved these days - you can get large amounts of RAM and ROM and an ARM core in tiny packages nowadays...
I do a lot with model railways. We (merg.org.uk, c 3500 members) use CAN bus as a layout control bus because it's simple, cheap, robust, peer-to-peer, fast enough, and amenable to longish bus lengths <=100m. We're starting to hit the limit of nodes per bus (c 100) on the larger layouts though.
Loco control is either digital (DCC, multiple independent locos on the track) or traditional analog DC using section switching. DCC is a 8kHz bipolar signal that carries the control instructions as well as being rectified to produce the DC motor traction power.
The favoured PC-based automation software is JMRI (Java model railroad interface), mainly because it runs on anything, incl Pi. It's scriptable in Python.
The one area where hobby projects have so far failed to match commercial products is on-board loco decoders. Simple motor control is fairly straightforward but it's difficult to 'compete' with many man-years of motor control algorithm development. That and physical size. The smallest I've managed so far is a 10x20mm double-sided board, but that's huge by commercial standards. That includes the micro, power rectification, H-bridge motor driver, BEMF sensing, lighting control, etc. I'm waiting for AVR-DD so I can go from a 5x5mm QFN part down to 4x4mm ;)
Sound decoders are a whole other problem. Decoding, mixing and playing multiple audio streams in real-time is hard. And the collection, production and encoding of the audio samples is a life's work. But that's why commercial products can cost hundreds of pounds.
I'm not particularly interested in trains (!!) but the hobby electronics opportunities are endless. Apparently it's the most popular indoor hobby in the UK ...
Yes, you're right. But model rail road could also mean controlling accessories on the landscape, lightning in houses, streets, steering some "decorations".
But also controlling a locomotive might have some specialties. I don't know if the acceleration is linear or not, but you can program a good simulation of the acceleration, also you can modify the clutch (is this the right word? the part, where the trailer is connected to the locomotive) with a spring and a potentiometer, measuring the load and slow down the acceleration (or measure the current of the motor).
But as you said, size matters and big processor is not useful for some projects. As far as I remember in some H0 locomotives it should be possible to integrate a Raspberry Pi Zero - but it is not useful... but for detecting and extracting 8kHz signals you should have the right mc. And depending on the requirements and the possibilities you can have a look for the right language.
