Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 06:47 11 Jul 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : A compiler with a somewhat civilized syntax

     Page 1 of 2    
Author Message
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 11:22am 07 Jan 2025
Copy link to clipboard 
Print this post

Almost 500 bucks for what I'd need, though
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 5056
Posted: 02:19pm 07 Jan 2025
Copy link to clipboard 
Print this post

Hi Phenix,

Oberon .. ?
A long forgotten language ? Which resembles Pascal (also from Nikolas Wirth).
hih... the typical ":=" is back again.

Volhout
PicomiteVGA PETSCII ROBOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10232
Posted: 02:29pm 07 Jan 2025
Copy link to clipboard 
Print this post

Looks very like a skin on C. Really C shouldn't be frightening. I'd never used it until I started playing with MMbasic and at its simplest level it really does map 1:1 onto most MMBasic syntax - just uses 'funny' characters rather than things like 'END FUNCTION'
 
Marcel27

Regular Member

Joined: 13/08/2024
Location: Netherlands
Posts: 93
Posted: 02:56pm 07 Jan 2025
Copy link to clipboard 
Print this post

Pascal, Oberon, Modula 2, all very stable and good languages. I love these languages. I programmed a while ago in Blackbox Component Builder. That is a complete IDE under Windows.

Be aware that Blackbox Component Builder is maintained by Russian programmers. I already used it before Putin invaded Ukraïne.
 
PeteCotton

Guru

Joined: 13/08/2020
Location: Canada
Posts: 543
Posted: 05:40pm 07 Jan 2025
Copy link to clipboard 
Print this post

  matherp said  I'd never used it until I started playing with MMbasic


WHAT!!!! That makes your achievements even more impressive - I assumed you'd been doing it for decades.  

  matherp said   and at its simplest level it really does map 1:1 onto most MMBasic syntax - just uses 'funny' characters rather than things like 'END FUNCTION'


I did write a simple convertor for a project years ago that converted a simple English like pseudo code to C and then compiled down to an ESP32.

It has crossed my mind that we could do a similar thing with MMBW on a Windows PC. i.e. Convert the Basic to C in a text file, and include "libraries" which would be the functions from your compiled MMBasic (such as rotate, string handling etc.), compile it on the PC using the standard ARM compiler and blow a fully compiled program into the CMM2 hardware.

So there would be no BASIC interpreter - just the compiled program plus the libraries. But having played with the CMM2 Basic, I think people would be surprised how little difference it would make (I suspect) compared to the BASIC program. Sure, if you're doing mathematically intensive things - it would matter, but the existing graphics algorithms and array manipulation functions are so efficient (and already compiled from C) that you can do absolutely astounding things with it, without resorting to compiled C.

The only advantage I can see is if you wanted to "protect" your source code from prying eyes. But that could be done with far less effort by introducing some sort of password/simple encryption*

*Note: I'm not asking for this - I like that all programs on the CMM2 are open - just pointing out that it's the only really reason I can see to compile the program.
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 08:11am 08 Jan 2025
Copy link to clipboard 
Print this post

  matherp said  Looks very like a skin on C. Really C shouldn't be frightening. I'd never used it until I started playing with MMbasic and at its simplest level it really does map 1:1 onto most MMBasic syntax - just uses 'funny' characters rather than things like 'END FUNCTION'


OK, I'm inspired  

Not afraid of the C language but - and I could be out-of-date here - I seem to have it in my head that not writing but implementing CSUBS is not easy(???)

My DOS QuickBasic ended-up as glue for a ton of MASM routines. I'd love to be able to take chunks of BASIC code and convert it to CSUBS.

I spent a couple of hours yesterday, shaving-off 9µSec  

Thanks Cap'n (it was you, wasn't it?). I replaced decimal constants with octal  
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 08:46am 08 Jan 2025
Copy link to clipboard 
Print this post

  PhenixRising said  Not afraid of the C language but - and I could be out-of-date here - I seem to have it in my head that not writing but implementing CSUBS is not easy(???)

Don't be put off.

Yes, CSUBs are a bit awkward. Most of one is just ordinary C but there's some "messing around" to get values in and out of MMBasic and to join the CSUB to MMBasic (i.e. fit into the address space of MMBasic).

Needs some unusual ways of declaring things and some casts to get them treated as the things they really are, which makes it look like C is hard when it's only hard in the odd corners (like these, a bit).

I hope someone can post URLs to the teach-ins about CSUBs...

One other snag (beyond the above) is that C gives you the power to do just about anything including using a bad pointer that'll make the CPU crash.  Try not to!

Also, you'll be in a situation with no OS to catch the bad pointer attempt (on Linux/Windows/Mac/etc you'd be returned to a command prompt or window).

OTOH - do you _need_ any CSUBs?  MMBasic on a Pico/CMM2/etc is fast.

John
Edited 2025-01-08 18:48 by JohnS
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 09:49am 08 Jan 2025
Copy link to clipboard 
Print this post

  JohnS said  
OTOH - do you _need_ any CSUBs?  MMBasic on a Pico/CMM2/etc is fast.

John


No. Just my OCD  

The unsigned 32bit count from the PIO quadrature decoder/counter, I have extended to signed 64bit and it just feels like it should be a low-level function. It's costing ~100µS but not really a problem.

It's just comforting to know that I can rotate a high-speed machine spindle for 100,000 years or so and not have worry about rollover  
Edited 2025-01-08 19:49 by PhenixRising
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 12:59pm 08 Jan 2025
Copy link to clipboard 
Print this post

  PhenixRising said  The unsigned 32bit count from the PIO quadrature decoder/counter, I have extended to signed 64bit and it just feels like it should be a low-level function.

That ought to be a really short CSUB.

If you post the code you now have that does it, someone may have ideas or a go at it...

Or talk you through it.

John
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 01:11pm 08 Jan 2025
Copy link to clipboard 
Print this post

Not yet tested with the encoder because I don't have it here, but:

DIM counter32 AS integer ' 64-bit variable
DIM prevCounter32 AS integer
DIM rolloverCount AS integer
DIM extendedCounter64 AS integer

prevCounter32 = 0
rolloverCount = 0
extendedCounter64 = 0

Do
   ' Read the current 32-bit counter value
   counter32 = 'From the PIO

   ' Adjust counter32 to account for 32-bit rollover
   IF counter32 > 2147483647 THEN
       counter32 = counter32 - 4294967296 ' 2^32
   END IF

   ' Check for rollover
   IF counter32 < prevCounter32 - 2147483648 THEN
       rolloverCount = rolloverCount + 1
   ELSEIF counter32 > prevCounter32 + 2147483648 THEN
       rolloverCount = rolloverCount - 1
   END IF

   ' Update the extended 64-bit counter
   extendedCounter64 = (rolloverCount * 4294967296) + counter32

   ' Store the current counter value as the previous counter value
   prevCounter32 = counter32

   ' Output the extended counter value
   PRINT "Extended Counter: "; extendedCounter64
Loop

Edited 2025-01-08 23:23 by PhenixRising
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 01:18pm 08 Jan 2025
Copy link to clipboard 
Print this post

The PIO has a 32-bit counter which counts... up only?
(And then wraps.)

John
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 01:26pm 08 Jan 2025
Copy link to clipboard 
Print this post

  JohnS said  The PIO has a 32-bit counter which counts... up only?
(And then wraps.)

John


Yeah, from 0, I get either 1 or 4 billion, depending on direction of rotation.
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 01:34pm 08 Jan 2025
Copy link to clipboard 
Print this post

As Pete explained, the PIO FIFO is unsigned 32bit.
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 02:14pm 08 Jan 2025
Copy link to clipboard 
Print this post

It's reading a rotating shaft?

So, some variant of RPM? But, say, per second multiplied by, er, 4?

Initialised to zero but can go (apparently) -ve because of the direction of rotation?

I'm wondering why you want even 32 bits let alone 64?

John
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 02:20pm 08 Jan 2025
Copy link to clipboard 
Print this post

A CSUB link

John
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 02:25pm 08 Jan 2025
Copy link to clipboard 
Print this post

Your code keeps 3 things: prevCounter32, rolloverCount and extendedCounter64 so a CSUB could be something like

#include "ARMCFunctions.h"

void count64(long long int *prevCounter32, long long int *rolloverCount, long long int *extendedCounter64) { /* CSUBs use pointers */

and then a C version of your code but keep using * to deref the pointers

}


John
Edited 2025-01-09 00:25 by JohnS
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 03:41pm 08 Jan 2025
Copy link to clipboard 
Print this post

  JohnS said  It's reading a rotating shaft?

So, some variant of RPM? But, say, per second multiplied by, er, 4?

Initialised to zero but can go (apparently) -ve because of the direction of rotation?

I'm wondering why you want even 32 bits let alone 64?

John


Yeah, like a robot joint (axis) or a CNC machine motor. We keep a track of the shaft (rotor) angle.

Many of my encoders are 4,096 "line" but in order to also detect direction, there are two (5v) pulse streams that are 90° out of phase. Due to the fact that we then have two rising edges and two falling edges, we have 4 separate transitions. This is where "quadrature" comes from. a 4,096 line encoder now provides 16,384 counts/rev.

Some of my motors run at 6,000 RPM (100 revs/sec) so the PicoMite will need to handle 1.6M+ counts/sec. Granted, it would take a while to hit +/- 31bits but I don't want such a limit if I have an option.  




The X4 Up Pulse Count is us
Edited 2025-01-09 01:44 by PhenixRising
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 03:55pm 08 Jan 2025
Copy link to clipboard 
Print this post

  JohnS said  A CSUB link

John


Many thanks. So damn tickled with what we have but this would be the icing on the cake and the cherry on top  
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4038
Posted: 04:07pm 08 Jan 2025
Copy link to clipboard 
Print this post

I reckon it'll be easier to debug the code in Basic and only then change to C.

If your Basic code (above) is OK, the straightforward C from it should be easy (*), but post if not LOL

(*) ahem, if you know C

I kinda feel like the 64-bit number will just be converted back to a quite small delta for the overall control algorithm.  (Doesn't matter - arguably - when there's so much compute power so cheap.)

John
Edited 2025-01-09 02:09 by JohnS
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 1360
Posted: 04:48pm 08 Jan 2025
Copy link to clipboard 
Print this post

  JohnS said  I reckon it'll be easier to debug the code in Basic and only then change to C.

If your Basic code (above) is OK, the straightforward C from it should be easy (*), but post if not LOL

(*) ahem, if you know C

I kinda feel like the 64-bit number will just be converted back to a quite small delta for the overall control algorithm.  (Doesn't matter - arguably - when there's so much compute power so cheap.)

John


Yes, the way this works; The software runs a theoretical velocity profile that is incremented, typically every 2ms. I happen to be incrementing every 1ms atm.

So, ignoring accel and decel ramps for the sake of simplicity, if I want to move 1000mm in 1 second, I increment my command by 1mm every 1mS. After the first iteration, my command is 1mm but my motor actual position is zero.

Therefore Error = command - actual = 1mm

This Error is multiplied by a gain coefficient Kp (p means proportional) and the DAC outputs Kp * Error

If Kp is too small, the motor won't get to position
If Kp is too large, the motor will overshoot and will then move back and will overshoot again and so on and now we have oscillation



do
 Error = command - actual
 DAC = Kp * Error
 Pause 1    (it actually runs in SETTICK 1)
loop


The closer that the motor actual position gets to the command, the smaller the error and the error is obviously zero when the motor reaches command.

A reasonable limit is established for Error, at which point, something's wrong and we shut down.

This method not only controls position but also velocity (v=dp/dt)

Robots and CNC machines are commanded in increments but at a frequency where we have continuous motion. Bit like a stepper but smoother, quieter, faster and aware of actual position.
 
     Page 1 of 2    
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025