![]() |
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 KingdomPosts: 1360 |
Almost 500 bucks for what I'd need, though |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5056 |
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 KingdomPosts: 10232 |
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: NetherlandsPosts: 93 |
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: CanadaPosts: 543 |
WHAT!!!! That makes your achievements even more impressive - I assumed you'd been doing it for decades. ![]() 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 KingdomPosts: 1360 |
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 KingdomPosts: 4038 |
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 KingdomPosts: 1360 |
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 KingdomPosts: 4038 |
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 KingdomPosts: 1360 |
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 KingdomPosts: 4038 |
The PIO has a 32-bit counter which counts... up only? (And then wraps.) John |
||||
PhenixRising Guru ![]() Joined: 07/11/2023 Location: United KingdomPosts: 1360 |
Yeah, from 0, I get either 1 or 4 billion, depending on direction of rotation. |
||||
PhenixRising Guru ![]() Joined: 07/11/2023 Location: United KingdomPosts: 1360 |
As Pete explained, the PIO FIFO is unsigned 32bit. |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
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 KingdomPosts: 4038 |
A CSUB link John |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
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 KingdomPosts: 1360 |
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 KingdomPosts: 1360 |
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 KingdomPosts: 4038 |
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 KingdomPosts: 1360 |
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 ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |