First an introduction. I started programing on Windows as a retirement hobby. First Python, then C using Code::Blocks and finally Ben Eater’s 6502 project. I’m not happy with the W11 rules, so now I’m trying to move to Linux. This is all to say I’m a beginner and especially with Linux. Also, because I learned by using Code::Blocks, make & cmake are (for now) a mystery to me.
However I was getting an error message : “warning: implicit declaration of function ‘gpio_get_out_level_all64’; did you mean ‘gpio_get_out_level’
I could see this function is defined in gpio.h but then couldn’t figure out where this file was pulled into the build. It occurred to me that the instructions placed a modified gpio.c (via the mv and ln commands) in the ~/pico path, so perhaps the same was needed for gpio.h?
I’m no longer getting an error building, but I’m wondering if what I did was proper. If not, what should I have done?
Let me say thanks in advance to everyone who has helped bring so many neat tools to the PicoCalc. Really looking forward to getting mine delivered.
It’s more garbage from upstream, where the author would rather do the wrong thing and make a mess of other people’s libraries than do it the right way (even though the right way was trivial.) It is absolutely not proper, but it’s not your fault.
I would very strongly advise you to do literally anything other that learn from MMBASIC.
It’s appalling code seemingly written by trial and error, incomprehensible even to experienced developers, the author follows no best practices and accepts no outside contributions.
Furthermore I would have though the actual useful effect you could have on it would be limited.
If you want to learn about development using the Pico native development tools, a much better choice would to take the the PicoCalc Text Starter (C/C++) , and extend one of the examples or create your own Pico-Calc compatible program from scratch.
@pelrun While waiting for delivery I’ve been reading lots of postings. I’ve already understood the MMBasic source is a mess. But I choose to look at it anyway.
I started from the main Clockwork GitHub page which eventually linked me to the adcockm GitHub page as the MMBasic source. I see your page is a fork of his, and I will grab it today to see what’s different. Too bad there are multiple GitHub pages for the MMBasic source.
@jonathanp See my reply to pelrun. Seems we need an alternate, good source for Basic on the Pico. I’m normally obsessive about trying to make my code faster, but that’s not my reason for looking at MMBasic. I accept that it’s too much of a mess for anyone to fix.
Thanks for the link to the BlairLeduc starter. Not sure where I’m going with my PicoCalc, but this will be a good learning resource. I like the idea of creating and executing BASIC fully on the PicoCalc as it reminds me of the ancient TRS-80 pocket computer. I guess I could change my mindset and try microPython as well. If I want speed then developing on my PC and transferring the compiled uf2 will have to be the path.
Looks like I’ll have to get the uf2loader so I can jump around these ideas!
Basic compiler MachiKania type P for PicoCalc looks promising as an alternate BASIC. It doesn’t support everything MMBASIC does, and clearly people are going to be attached to the “default” that comes with their device, but it does seem to integrate SSL support for web requests which proved to be MMBASIC’s nemesis.
I have been thinking the same for awhile. There is Machikania Basic, its main problem is it is not an interactive interpreter, it is a compiler. So while it is lightning fast, if the interactive part is important to you like it is for me, then that is a problem. There are some other minor issues like it is an integer Basic so it does not handle values between 0 and 1, not a show stopper, but an annoying limitation.
There is also a variant of uBasic specifically for the Raspberry Pi Pico, picoloBASIC. This would need to be ported to the PicoCalc, but the code base looks simple enough that a competent programmer could probably do it in fairly short order. The hard part would be adding the features necessary to make it really usable. I do think there is some potential there for a community of hobbyist programmers to build it into a PicoMite Basic rival.
Madcock’s repo is about as “official” as we can manage. My fork is purely the minimum fixes for uf2loader and pico2 (and that gpio library mess), and will get rolled into madcock’s at some point.
If the upstream author wasn’t stubbornly refusing patches, we’d be able to do larger scale refactoring. But he’s not, so we have to be as compatible as possible in order to reduce the maintenance burden.
I wasn’t complaining about a lack of support, I was talking about an annoying limitation (maybe incompatibility would have been a better word) , again not a show stopper, just mildly annoying.
again, i’m still not sure what the limitation is. you are affirming that machikania cannot represent values between 0 and 1. the machikania developer has shown you that machikania can represent values between 0 and 1. one of us is not understanding something very fundamental.
My problem was really with the rnd() function, rather than anything else. I wanted to generate a random number between 1 and 6. In most versions of Basic it is very simple, something like x = int(rnd * 6) + 1 will do the trick. In MachiKania Basic, this does not work because rnd() generates a number between 1 and 32768 instead of a number between 0 and 1. So to get what I want, I need to do something like x = (rnd() / 5461) + 1, which breaks from traditional Basic. If you read the whole conversation, I already knew all of that, what I really needed help with was seeding the random number generator from the system timer because randomize timer did not work.
I think the problem here is I was just not clear in what exactly was annoying me and for that I apologize.
It now appears to me that the Pico doesn’t have floating point hardware, and thus all FP will be software emulation! In fact it doesn’t even seem to have an integer divide! Hopefully someone will tell me I’m wrong on both counts.
You’re not mistaken. The RP2040 is only a Cortex-M0+, it’s not meant to be a cpu powerhouse. (edit: but it does have an integer divider! It’s a memory-mapped peripheral, not intrinsic to the cpu.)
But that’s ignoring the fact that it’s still ridiculously powerful compared to the 8-bit microcontrollers that still see a lot of usage (and those don’t have FPUs or integer divide either!), and that the peripherals allow doing stuff that faster mcu’s balk at.
But if you’re programming in basic, then you’re not really making efficient use of the cpu anyway, and discussions around performance are a little bit academic.
Thanks for the divide info. I need to re-read the chip manual to find it.
Desktop CPU’s have had hardware FP since the 80387 came out (1987), so I guess I just assumed it would be standard in any modern CPU. Always dangerous to assume!
I built Ben Eater’s 6502 breadboard computer kit. That CPU has only 8-bit add and subtract. In his course we programmed 32-bit integer +, -, * and /. Afterwards I invented my own 32-bit FP format (IEEE-754 is hard) and then programmed FP +, -, * and /, so I know it can be done.
MMBasic looks like something fun to play with when out in a coffee shop. Now that @jonathanp has pointed me to @BlairLeduc’s starter GitHub I think that will become the basis for my real programming. I cloned it yesterday and now need to dive in to understand what it’s doing. My main reason for diving into the MMBasic source was to understand how to write to the LCD, but Blair’s code will be much easier to follow.
Is it worthwhile, to just full on fork mmbasic, and fix it from a source code point of view and forget about pushing the changes back up to the orginal?
I would be happy with other flavors of basic, but most dont have one feature or another. MMbasic with all its faults is fairly complete.