BBC Micro:bit versus Arduino and its use for a Rotary Table Indexer

[IanTParticipant @iant]

Ah! yes! That’s a very useful link John, I’d only seen summaries of the actual G-Codes before. Thank you.

I’ve been thinking about an ‘off-line’ controller for my CNC Router (as it didn’t come with one) and this will help me explore the matter further. But it seems I also need to load another ‘app’ on my phone – that ‘GC’ one. I use HC-06s too and you can just use them with default settings or configure them with a USB/Serial adaptor. I’ve changed the name and password on mine but otherwise they just work, assuming you only need a BT slave.

I’ve also been thinking about my simple ‘stepper’ application. I do have an unused UNO, so could use GRBL + Stepper Shield – or I can use one of my PicoMites. The Kitronics can drive a bi-polar but needs to bit-bang the H-Bridges. However, I could use a ‘clever’ driver chip (such as a DRV8825) and then it’s much simpler to programme.

Regards,

 

IanT

[John HaineParticipant @johnhaine32865]

You do need to configure the HC06 for a higher baud rate I think.  GRBL needs 115200 but the default ’06 rate is something like 19200.  There are quite a few alternatives to GC if you use either a PC or a Pi for the sender.  Listed somewhere on the wiki I think.

[IanTParticipant @iant]

That’s useful to know John.

The HC-06 default is 9600 baud (N81) but it can be set to 115299 baud with the command “AT+BAUD8”

I have both Candle and UGS on my laptop (as my G-code senders) but they do tie up the laptop. I’m used to just plugging an SD card into my 3D Printer and letting it get on with printing. There is an off-line controller available for £30 but the (UK!) postage is then another £20 (which being tight by nature rather put me off). It’s probably still a good price compared to my time trying to make a (working) alternative and I have a long list of other things to do.

There is a RPi version for UGS but it seems to need a RPi4 – and the RPi3 (that I also have spare) is reported to be “sluggish” running it. A new RPi4 is going to be near £50 inc postage and needs an external monitor, so doesn’t save anything moneywise.

Sorry, I’m ruminateing and I’m now well off topic.

Getting back to stepper motors and driving them from something like a BBC Micro-bit (or PicoMite/Arduino) having looked at the DRV8825 datasheet, this would seem to be well worth considering. It contains dual H-Bridges and a “micro-stepping indexer” so does the bit twiddling for you. It can also handle upto 2.5A per coil with the heatsink attached. So good for most bi-polar NEMA 17 steppers. Mounted chips are about £5 on eBay (if you look around) so they seem reasonably priced too.

DRV8825 details here:  https://www.ti.com/lit/ds/symlink/drv8825.pdf

Regards,

 

IanT

 

 

[Michael GilliganParticipant @michaelgilligan61133]

That DRV8825 looks very useful, Ian

Thanks for the link.

MichaelG.

.

Edit: __ come to think of it; I may already have some on my little laser engraver

… the purple modules available on ebay look very familiar !

[Neil WyattModerator @neilwyatt]

Not entirely relevant to the discussion, although they show what can be achieved using microcontrollers and solves some related problems like using steppers and calculating angles/trig.

I once made a small computer based around AVRs (the microcontroller in Arduinos).

One operates a display and responds to BBC VDU commands (I made versions for several types of display, and used them in a few other projects).

The other interprets (nearly all of) BBC Basic. I set it up to use the tiny keyboard from an Amstrad Emailer. Doing it again, I would use an ordinary PC keyboard for ease of use.

Early version

Trial run…

Later version

Font test

Telescope guider with display using an early version of the VDU driver:

[IanTParticipant @iant]

Yes Michael, I think they are a slightly more powerful chip than the A4988 found on the common Arduino ‘UNO’ type stepper motor shields. One Chinese manaufacturer of these shields states that their DRV8825 module is pin compatible with the more usual A4988 modules – but this may vary of course.

If one needs to drive a larger stepper current (NEMA 23 etc) then it seems you have to go up to the TB6600 (black box) type of contoller. For my needs the DRV will probably be fine and will just need a capacitor across the power input (which as far as I can tell) is all the the Arduino Shields have, apart from providing an Ardunio compatible pin-out. But as I only need one stepper driven, simple is good.

 

Regards,

 

IanT

[SillyOldDufferModerator @sillyoldduffer]

Nealeb’s question about using two, or more, microcontrollers to manage a load where one would be too slow is a good one.

There are several ways of connecting them, from manipulating cross-connected pins, to an ethernet network, plus USB, I2C and many other possibilities.    In CNC world, grbl running on an Arduino, is sent G-code by a host with serial over USB.  Then grbl translates the G-code into pulses applied to pins that enable an axis, set the motor direction,  and sends ‘n’ pulses needed to move the cutter over a distance.  There are enough pins available on an Arduino Uno to drive 3 axes simultaneously, and the Uno is fast enough control all three axes at up to 30,000 steps per second.

Getting this amount of work out of an Arduino Uno is a serious challenge, and I’m impressed by grbl!   Acheved by careful design and  pulling almost every trick in the book to save cycles.  The advantage of squeezing everything on to one CPU is it simplifies the electronics and software maintenance.  The advantage of using two CPUs, is it provides more power at the cost of some extra complexity.  Depending on the circumstances both ways have considerable merit.

The simplest general purpose way of connecting two microcontrollers is with the Serial Interface.   This provides two way communication, and can exchange strings, or blocks of binary, at various standard speeds.   Almost all microcontrollers have at least one serial interface.

Serial transfers raise the bogey of flow-control – what should be done if the sender transmits data faster than the receiver can clear it?   This was a major problem back when printers and terminals were mechanical slow-coaches with no memory, and most circuits were ‘half-duplex’.  Therefore the RS232 interface specification provides pin connections for 3 separate hardware flow-control methods (Request to Send/Clear to Send, Data Carrier Detect/ Ring Indicator, Ready to Receive/Ready to Send.  In the good old days, when men were men, all of them might have to be connected.

Thankfully much of the need for hardware flow-control gradually disappeared because most devices operated in full-duplex, and had plenty of memory, and telecomms equipment needing Data Carrier or Ring detection became obsolete.   Though still available for legacy equipment, the first simplification was to use only Ready To Send and Clear To Send.   Then, they were often abandoned in favour of putting X-On/X-Off control characters into the data stream.   (When the receiver couldn’t cope, it sent an X-off character to the sender, who would pause until the receiver sent an X-on character.)

Today, most microcontroller serial interfaces don’t bother with flow-control.   Only three pins are used, Transmit, Receive, and Ground.   Nor do the standard libraries implement X-on/X-off.   Instead, the programmer has to keep an eye on sending and receiving issues and design them out.   As a Personal Computer is orders of magnitude faster than a microcontroller, it’s unlikely to be overwhelmed by the smaller machine.    Trouble is more likely the other round, because a fast PC can give a slow microcontroller a right rogering.  Can get complicated but typically flow can be managed simply by setting the baud rate to suit the slower device.   Throttling the data-link manages the amount of work the receiver has to complete in a given time.

From a programming perspective, the most important requirement is to avoid blocking.   This is any circumstance in which the program stops and waits for an input or output to complete.   Thus in BASIC, it’s unacceptable to write code like:

INPUT “Angle”,  turnAngle

because the INPUT command stops the program until the user types in a value and presses return.   Instead, the program has to do something like “scan the keyboard, returning a character if one is pressed, otherwise NULL, and don’t stop!”

On the Arduino platform, access to the serial interface is provided by the Serial object.   It connects to the USB port and to Pin 0 (RX — Receive) and Pin 1 (TX – Transmit).   Cross connecting two Arduino so that TX goes to the others RX and vice versa allows them the exchange messages.    This example from the Arduino IDE shows non-blocking Serial read:

The Baud rate is set to 9600.  Then the receiving program loops continually until a flag is set showing that a full line of data has been received.  The program doesn’t wait, which allows loop() to process other functions in the meantime.  However, Arduino provide a special built-in function called serialEvent() that’s automatically called by loop() on every cycle.  Normally serialEvent() is empty and does nothing, but in this example it checks the Serial buffer to see if any characters have arrived, and appends any newcomers to a string, before carrying on.   When a newline character is received, the flag ‘stringComplete’ is set true.    Code in loop() checks the flag, and processes the input.  The input can be anything, perhaps a line of data to be displayed on a screen and logged to a memory card, or a g-code command like “G00 X0Y0Z100” that has to be parsed into whatever motor-control pulses are needed to move the cutter as quickly as possible to table coordinates X=0, Y=0, Z=100

I recommend starting with simple examples, such as having one Arduino sending an incrementing count to another that displays it.   Or if you prefer two PICs,  two Nucleos, two Micro:bits, or any other pairing.    Conceptually an Arduino can be programmed in C to talk to a Micro:bit running MicroPython or to a PIC running BASIC.   The main problem with mix and match is the learning curve because the implementation details are all a bit different, and the programmer has to get all them all in alignment.   In practice, that feels like herding cats, so many programmers stick with whatever platform they know best, just to reduce the amount of swotting needed.

Dave

 

 

 

 

[John HaineParticipant @johnhaine32865]

I’ve used the drv8825 and 8834 quite a lot.  The 8834 can run off 5v or less, up to 10.8 max.  More flexible than the 4988 but I have seen a report that the latter gives more accurate micro stepping.  My 2 axis controller uses 2 8825s with a 24v supply.  Nowadays I think people shouldn’t even consider bit banging old fashioned drivers like the L298.  The TB6600 should also be avoided as there are clones which have a reputation for fragility.  The are much better modern digital drives around at reasonable prices from the likes of StepperOnline .

[DellParticipant @dell]

Being old and not very computer savvy I have just purchased

world of wards rotary controller and fitted a nema 17 stepper motor to both my rotary tables.

it will do division, degrees, continuous, steps and more, he does sell the kit but I decided to buy it ready made.

Dell

RotaryController

[NealebParticipant @nealeb]

I think that I am taking the opposite approach – why do things the easy way when there is a more difficult path to take! Having been inspired by Dave’s outline above which suggests that inter-processor comms might be easier than I thought, I shall be looking at the same kind of setup that my existing CNC machines use, with one part responsible for the user interface and non-time critical functions and the other just doing the direct hardware control. I shall use a couple of Arduinos, though, rather than PC and motion controller.

Actually, having read Dave’s note, I went off to search for further info but found it very difficult to get an overall picture from the mass of “how to do it” posts available, so I tried something new – I asked ChatGPT how to connect two Arduinos. I was pleasantly surprised by the result, getting a neat summary list of the options available with enough info to better research each mechanism. And now I know that, given the libraries available off-the-shelf, it will be easy! What could possibly go wrong?

[Robert Atkinson 2Participant @robertatkinson2]

I think I’m going to go with the World of Ward design. Ido my own build on protoboard.  I’ve got better things to do with my time than write code.

One thing on this type of thread bugs my inner pedant – “…a NEMA 23 stepper….”  The NEMA number is just the nominal frame size in tenths of an inch. A NEMA XX motor could be any type AC, stepper BLDC, AC servo, DC servo etc. Even if qualified with “stepper” it is still pretty meaningless unless the length, type, step angle and current are specified.

Robert.

[IanTParticipant @iant]

Good feedback John – I haven’t heard of some of those devices but will take a look. I date back to the days of buying discrete components and thought 74 series logic was simply wonderful. When I originally ‘trained’, it was in valve theory (so I’m getting ‘on a bit’ too Dell). I also remember subscribing to Wireless World and trying to figure out some of the circuit diagrams therein.  🙁

By comparison, yesterday I spent £4.25 on eBay (free postage, UK shipping address) and purchased a DRV8825 module to play with. The mind boggles to think about the kind of PCB complexity & cost etc that would have been required to build this back in the days of Wireless World.

—————–

Dave, an interesting comment on serial comms and ‘blocking’. I can see that it could be a problem but it’s not something I’ve encountered in practice (probably because I don’t transmit very large amounts of data – just a few characters or use very high baud rates, mostly (the default 9600baud 8N1) in my apps. By co-incidence the Backshed Forum had a post about serial comms this morning and I remembered this code snippet from the thread.

 

MM Basic (as used in the PicoMite) has a (default) RX buffer of 256 bytes but this can be increased as an (optional) “OPEN” parameter if required. My programmes are generally pretty small and memory size (or lack of it) isn’t a problem. The PicoMite has a maximum programme size of 160Kb and this doesn’t include the ‘Flash’ storage slots also available for programme storage.

I must admit, being a ‘numptie’ I haven’t bothered to use ‘LOC()’ – I generally just open and read/write to the “file” as MMB handles this very well. Having read your post above, I will now try to mend my lazy ways and (as Lizby suggests) check the buffer too.

For anyone interested in what is happening here – I’ll attach a bit of the manual below to explain further

Regards,

 

IanT

Once a serial port has been opened you can use any command or function that uses a file number to read from
and write to the port. Data received by the serial port will be automatically buffered in memory by MMBasic
until it is read by the program and the INPUT$() function is the most convenient way of doing that.

When using the INPUT$() function the number of characters specified will be the maximum number of characters
returned but it could be less if there are less characters in the receive buffer. In fact the INPUT$() function will
immediately return an empty string if there are no characters available in the receive buffer.

The LOC() function is also handy; it will return the number of characters waiting in the receive buffer (i.e. the
maximum number characters that can be retrieved by the INPUT$() function). Note that if the receive buffer
overflows with incoming data the serial port will automatically discard the oldest data to make room for the
new data. [Hence my comment above about being able to increase the RX buffer size if required]

[IanT]

On IanT Said:

…
—————–

Dave, an interesting comment on serial comms and ‘blocking’. I can see that it could be a problem but it’s not something I’ve encountered in practice (probably because I don’t transmit very large amounts of data – just a few characters or use very high baud rates, mostly (the default 9600baud 8N1) in my apps. By co-incidence the Backshed Forum had a post about serial comms this morning and I remembered this code snippet from the thread.

 

…

Yeah, not many application programs don’t need to respond instantly to external events, provide a non-stop service, finish within a tight time slots, or transfer data flat-out.  Much needed in real-time, embedded and operating systems though.

The MMBASIC example is the sort of approach that’s needed, but although Lizby is on the right track, I suspect it’s not quite right.  The code loops correctly allowing other work to be done until file #5, actually a serial port buffer, contains at least one character, detected with loc().   Then control drops out of the loop and blocks at “pause 100”, presumably in expectation that more characters on on the way.  That pause wastes a lot of time, doesn’t guarantee all the input will be read, so it has to go!

I liked loc() until reading in the manual that ‘input’ returns immediately from a serial port read, which I think makes loc() unnecessary for this.  MM BASIC is unusual in that input attached to a serial port doesn’t block, which is handy. It also allows an interrupt function to be attached to a serial open,  another good way of responding to a ‘react immediately’ event.   A potential objection to loc() is that it’s a file seek operation, which is very slow on many systems, depending on how it’s implemented.   Be interesting to measure how long MM BASIC takes.

Time critical event handling is great fun to program, because there are so many ways of getting it subtly wrong!

Dave

 

 

 

 

[GreensandsParticipant @greensands]

Many thanks for all those informative and in some cases quite learned discussions on the use of micro controllers but with the greatest respect I think the discussions have wandered a little of track from my original posting. My question and main interest is centred on whether it might be possible for a Gary Leming/SOD Rotary Table indexer unit could be built and programmed using the BBC:bit micro controller with the software written in BBC Basic programming language.

My main issue with the current Arduino indexer referred to above is that it is written in C ++ (or C), a language that I am afraid it is a little too late for me to get to grips with having been brought up using Fortran (what ever happen to that?) and later for all my workshop applications TurboBasic a language that was more than adequate for all that I wanted to do.

I am well aware of all the valid arguments against using the Basic language and Fortran etc. i.e. the lack of any structural integrity in the program and the difficulty posed for other people when taking on another’s programmers work.  But surely if written in a thoughtful manner simple program applications such as an indexer can be made perfectly readable by all potential users which would make things a lot more interesting and dare I say it, easier for some of us to handle.

I believe the main reason for promoting Pascal was that is a structural language but again, what happen to that?   However, all good stuff and food for thought.

[IanTParticipant @iant]

My apologies GS.

I’ve never used the BBC Micro-bit, so cannot give you an answer based on actual experience.

I have used the PicoMite (i.e. MM Basic which is a much updated version of Microsoft GW Basic) and I beleive I could programme a rotary table indexer using one – although I would ‘off-load’ the stepper motor drive to a device that would do the ‘stepping’ for me (like the DRV8825 as we’ve discussed above). There is therefore no need to ‘bit-bang’ the stepper and the actual calculations involved in ‘indexing’ the table would be well within the capabilites of the Picomite and (I assume) the Micro-bit.

However, I think the question to be asked, is if someone else has already done this work (and unlike myself, Dave is a professional programmer) then why re-invent the wheel when you can piggy-back off the work of others?

Regards,

IanT

BTW – Modern Basics shouldn’t be confused with those encountered on 1980s ‘8-bit’ consoles. MMBasic programmes don’t have line numbers, GOTOs or PEEK/POKE commands etc (although they are there if you really want them). You can write very readable MMBasic programmes with just a little care and lot’s of comments!   🙂

[Greensands]

On Greensands Said:

… My question and main interest is centred on whether it might be possible for a Gary Leming/SOD Rotary Table indexer unit could be built and programmed using the BBC:bit micro controller with the software written in BBC Basic programming language.

…

As far as I know, BBC Basic as supplied with the good old BBC Micro, isn’t available for the micro:bit, so not directly possible.

The micro:bit is mostly programmed in MicroPython or MakeCode.  C is available for advanced users.  Javascript, Rust and Ada too, but I couldn’t find a BASIC of any description for the micro:bit.   In theory, MMBASIC, which is written in C, could be ported to a micro:bit, but I don’t think it’s been done.  Porting isn’t for beginners, so I wouldn’t recommend DIY.  Maybe Neil could be tempted though, see his post above!

If BASIC is your thing, then MMBasic on a Maximite or Raspberry Pi Pico is a good option.  They’re both fairly friendly! Or any of the various PIC chips that support BASIC.  Though I don’t have any recent experience of PIC + BASIC myself, others do.

You might try MicroPython, which is easier to learn than C, and may be similar enough to get you going.  You can be sure that whatever BASIC does, Python does better!  It’s mainly the syntax that differs, admittedly a serious PITA if comfy with BASIC already because it’s so easy for code to get lost in translation!

And although MMBASIC is similar to BBC BASIC, they aren’t the same, so still a learning curve!

The micro:bit hardware can certainly host a rotary table driver, but it can’t run code written in BBC Basic.

Dave

 

[Mark RandParticipant @markrand96270]

Just a couple of thoughts from a moderately old fart (got my first state pension payment a fortnight ago 😀 )

If you are trying to combine ‘real time’ control’ with human interface then the entire program shoud be interrupt driven.

Any of the processors mentioned should be capable of the requirements, with the note that the two core Pico can and should be used in multi-threading mode because the capability is there and for the slower chips, hand (or automated) optimising of the time dependent code into assembler or C (Pascal worked for me until I learned C) may be worthwhile.

The key is to write the data control/output/input routines to be as tight as possible and have interrupts set for  catching when an action is needed, so set the output high and set an interrupt for when it needs setting low again etc. similarly, set an interrupt for key presses rather than scanning for them. The Pico, in particular is extremely well equipped with timers, interrupts and PIO state machines for this sort of use.

These comments are based on getting 100, 5 digit readings per second from data loggers, converting them into engineering units and displaying them in 1985 with a 20MHz 68020 based HP computer running BASIC and Pascal and frequency reading from 5Hz to 200kHz, doing software floating point arithmetic and processing RS232 terminal input with a 4MHz PIC processor in the early ’90s. Both while accepting keyboard inputs and displaying results.

 

PS:_ Sorry if I was teaching grandmother to suck eggs there, but the tools we have available now really are orders of magnitude better and simpler to use than we had in the ‘glorious days’ when computers were the next best thing to sliced bread.

PPS:- still struggling to learn enough Python to write the database program to help me find all my mislaid tools and help SWMBO describe and sell them after I’ve popped my clogs

[BazyleParticipant @bazyle]

Bear in mind there is 40 FORTY years between the original BBC computer and the BBC:microbit. The original computer was already developed and on the point of launch when the BBC decided to produce a program about programming for their schools programme. I was at the initial launch event as part of the ALCC and ACC committees.
Since then many different computers have been used in schools and also small controllers as part of tech education. The BBC:microbit is just the version of the moment for 2020’s. It has no logical connection to the one of 40 years ago.

However Model Engineers could use this opportunity if they have connections to schools (ie kids as pupils or staff) to suggest that, when the children are asked to select a project to do  with their newly learned computing skills, they find out about the concept of a dividing head and write the required program. A very small stepper could be used with a 3D printed dividing head for demonstration purposes.
This should be possible for a GCSE level child and easy for an A-level one. I think if I were interviewing prospective engineering students or apprentices I would be more impressed by such a project than some silly game.

 

[IanTParticipant @iant]

“…for all my workshop applications TurboBasic, a language that was more than adequate for all that I wanted to do”

[PowerBASIC, formerly Turbo Basic, is the brand of several commercial compilers by PowerBASIC Inc. that compile a dialect of the BASIC programming language. There are both MS-DOS and Windows versions, and two kinds of the latter: Console and Windows. The MS-DOS version has a syntax similar to that of QBasic and QuickBASIC – Wikipedia]

Borland – well, that’s certainly a name from the past GS.

However, it sounds as though MMBasic might well suit you. It’s an interpreter but running on an ARM CPU, it’s very quick. I suggest you download the PicoMite Manual from the botton of this page and see if anything looks familiar.

https://geoffg.net/picomite.html

Regards,

IanT

[Robert Atkinson 2Participant @robertatkinson2]

While MM Basic is a great product, I still encourage those looking at PICs who don’t get on with C to look at PicBasicPro 3.

http://www.PBP3.com

It is a COMPILED basic not an interpreter. Even the free student edition is fully featured. The only limitation being a restricted range of processors. The choice of 12F683, 16F688, 16F88, 16F690, 16F886, 16F1937, 18F2550, 18F25J20, 18F25K22 covers most needs though.

I’ve been using it and it’s earlier versions as a hobbyist and for commercial products for over 20 years.

Robert.

[IanTParticipant @iant]

As with many things (CAD also comes to mind) – choice often comes down to personal preference Robert

However, I think for most uses, the question of ‘compiled’ vs ‘interpreted’ isn’t as valid as it once was. Back in the days of 8-bit computers, there was often the need to use machine code to ‘tune’ the slowest parts of an interpreted programmes. When I first started usng MMB it was on 40Mhz PIC32 chips. They run at an order of magnitude faster than an Apple IIe by comparison.

I’m now routinely using Pico’s (with dual ARM CPUs) and the default clock speed is 133Mhz but you can over-clock them to 378Mhz (by use of an OPTION command) if you want. There is also a facility to include ‘C-Subs’ (compiled C routines) as well as directly programme the PIO state machines.

However, my experience has been that my apps spend most of their time waiting for things to happen. Execution speed really isn’t a problem for the Rotary Table Indexer for instance, especially with a clever stepper driver chip.

The reason I moved from Arduino to MMB was because it was much easier and quicker for a dummy like myself to debug. No complie, test, re-compile, test cycle. ‘Speed’ for me is speed in getting things working and MMB is very quick in this respect.

Of course for the kind of use I might want to use the 16F/18F PIC family for, I might indeed have a look at PBP3 but for what I generally need, the use of the Pico and it’s accessories is far more convenient.

Regards,

 

IanT

[IanT]

On IanT Said:

As with many things (CAD also comes to mind) – choice often comes down to personal preference…

…

The reason I moved from Arduino to MMB was because it was much easier and quicker for a dummy like myself to debug. No complie, test, re-compile, test cycle. ‘Speed’ for me is speed in getting things working …

Regards,

 

IanT

A good summary from Ian, that captures one of the key issues in software engineering:  the trade-off between execution speed and how long it takes to write, test and debug the program.

When I started programming, even big mainframe computers were slow and had small memories.   It was essential for the programmer to manage the size and performance of his executables because it wasn’t difficult to write programs too big to fit on the machine, or that took longer to run than the time available.    For example, I worked on a program that analysed an entire months transactions, millions of them, that decided the big money saving operating parameters of the following months activity.   Had to complete in the 28 hours between close of business on Saturday and midnight Sunday, which an ICL1906 mainframe, initially failed to do!  However, with careful tuning, and pre-processing, the run time was eventually brought down to about 22 hours, ±5 hours.   The program was written in a complicated mix of COBOL, Fortran, and Assembler:  COBOL for anything not speed critical because it was easier to write and maintain,  FORTRAN for the time-consuming number crunching,  and Assembler to reduce bottlenecks.    There were several tricky trade-offs, for example compressing the input off-line caused the analyser to run faster when memory was short, but slower whenever the processor was heavily loaded, depending unpredictably on the transaction mix.

Being short of memory and CPU speed is still typical of microcontrollers:  no problem programming them until either resource gets tight, at which point it may become apparent that choosing the development language based on personal preference was a bad idea!

C is outstanding whenever small, efficient, fast executables are needed, the language can do almost anything, and is suitable for both very big and very small programs.   It’s close to the machine, and a good compiler optimises so effectively it’s rarely necessary to write assembler, though that is fully supported.   But C’s power and capability comes with a multitude of options, and having to learn them is liable to get in the way of simple requirements.   There’s no Nanny in ‘C’ either:  the programmer is in control, and allowed to do things that could either be very clever or a stupid mistake causing bizarre hard to diagnose bugs!     The Arduino environment is popular because it successfully hides most of C’s under the bonnet complexity, and does a lot of helpful hand-holding.    However, if necessary, a C programmer can override the Arduino environment and go entirely native.    Another massive advantage is C is being available for almost every computer ever invented, so once learned any platform can be tackled.

Being a low-level system language makes C is unnecessarily hard work for most applications.    As soon as computers got faster and had more memory, it paid to develop languages that were easier for humans to write, allowing better hardware to hide the fact that high-level language executables were bigger and slower than the equivalent written in C.  For most purposes, it’s best not to waste human time writing fast space efficient executables, because most computers are powerful enough to run most applications ‘fast enough’.

BASIC was an early example of a user friendly programming language, originally intended as a teaching aid and demonstrator, rather than a development tool.  But being small and simple meant it fitted on early home-computers, where it’s shortcomings didn’t matter, and it became very popular.   Over time, many of BASIC’s  shortcomings were addressed, but haphazardly,  so a multitude of similar dialects appeared, none of them entirely compatible with the others.

Other languages appeared later, and benefitted from ‘lessons learned’.    They gradually forced out COBOL, BASIC and a host of other also-ran early languages, making most of them a poor choice today.    At the moment, Python is a much better alternative to BASIC, unless of course you already know BASIC and have never used Python, or anything else more modern!   Not having to learn a new language is a personal advantage, but a poor reason for recommending it to newcomers.   Old dogs should remember young dogs are good at learning new tricks.

Python and MMBASIC share similar pros and cons on a Microcontroller.   Both are far too big to fit on a small Arduino board!  They will fit on a Pico, micro:bit,  or any other fast modern microcontroller,  the performance of which is often good enough to hide how inefficient the programs are, typically between 2x and 20x slower than well-written C.   Thus developers can write and debug code quickly, without needing a degree in Computer Science,  and all is good provided the result does the job, as it usually will.

Not sure about MMBasic, but Python can call modules written in other languages, such as C, when performance or a special device has to be supported.   Again, mix and match should be an engineering decision rather than personal choice, because the developer has to understand how to glue two complicated languages together.   If this is likely to happen, stick to mainstream languages, rather than going BASIC because one once wrote BBC-BASIC!   Definitely don’t learn BASIC in hope of becoming a professional programmer!

No computer language is best for everything.   My favourites are C/C++ and Python because they cover 99.99% of most requirements.   For what it’s worth I’ve been paid to write code in COBOL, Z80, C, C++,  FORTRAN,  Filetab/FTL6, several BASIC dialects, perl, BASH, SQL, and half a dozen 4GLs.   Of these COBOL is my most hated language, but the BASICs are close behind – some much worse than others!!!

Dave

[Robert Atkinson 2Participant @robertatkinson2]

Hi Ian,

A not unreasonable approach but a bit of a sledgehammer to crack a nut. I’ve looked at Raspberry Picos professionally and it’s hard to beat the price but I have had concerns over compliance. While they say they are CE compliant you have to sign an NDA including a unreasonable amount of personal information to see the test report which tells you the conditions. This might be running minimal code with nothing but a supply connected. In addition to this despite having a retail shop their terms and conditions state all transactions are business to business. This means it is not subject to consumer rights.
I know where I stand on EMC with a 8MHz PIC but a 133MHz Pico is a bit more of a risk. I can also review the assembler and object code the complier makes if need be. It’s much harder know exactly what a interpreter is doing.
Horses for courses.

Robert.

[John HaineParticipant @johnhaine32865]

A major issue with the Pico and the component processor for commercial products is the lack of any security features. This is recognised in the documentation.

[John Haine]

On John Haine Said:

A major issue with the Pico and the component processor for commercial products is the lack of any security features. This is recognised in the documentation.

Whether this is an issue or not depends on the application.   A hobby rotary table divider is unlikely to have any security requirements whatsoever!

Something like a cashpoint machine requires strong security features, but how these are implemented are holistic to the system in its widest sense, not just the the chip.

The RP2040 has the basic security provided by an ARM Cortex M0, which is nothing special.   ARM chips are a little unusual in that the processor part only is licensed to the chip maker, who then adds whatever peripherals to the mask he needs to produce his ‘system on a chip’.   Tough security requirements like encryption are usually met by the peripherals, not by the core, unless the system is multi-user/multi-tasking. The RP2040 wouldn’t be my choice for anything privacy sensitive like a smart-phone, because the peripherals provided by Raspberry are hobby friendly, but that makes it excellent for many projects.

Another common mistake is to buy a chip stuffed with security features assuming they will make life easy, only to discover they’re not switched on by default and are frigging hard to use.  It’s all too easy to render security features impotent by programming them badly and/or by not understanding the risks properly.    Computer security is hard work!   Fortunately, hobbyists, and even most professional application developers,  rarely have to write secure systems!

Dave

 

 

[Author]

Posts