I released v0.7 today:
- Adds a new font that provide 64 columns and 32 rows on the screen
- A new command in the REPL allows you to select the width
1 Like
Thanks to your library, I was able to create an Arduino IDE Keyboard library. The keyboard and southbridge APIs helped a TON. Thanks for your contribution!! GitHub - jblanked/pico-calc-text: Arduino IDE Pico Calc Keyboard Library
3 Likes
This is exactly why I created this starter. So creators like you could get on with creating and not have to deal with the low-level grind.
My approach was to provide working code that you could take, base your code on it, or get your code working with a working example to compare.
5 Likes
I released bug fixes today. Thank you for every who uses this starter and provides feedback!
A maintenance release for today: I fixed a problem with scrolling text of the LCD display, serial can be configured to use the stdio functions and upgrade to SDK v2.2.0.
A updated release that supports BIOS 1.4: Adds the ability to power down or reset the PicoCalc from the Pico.
This also fixes a bug where you could not set the backlight or keyboard brightness.
Hi. Iām starting to experiment with your framework. I added some Wi-Fi functionality to your example (main.c) and noticed that the function led_init() triggers an error: ā*** PANIC *** Hard assertā. After doing some debugging, I found that using the definition PICO_DEFAULT_LED_PIN resolves the issue.
Specifically, the relevant part is:
static inline bool status_led_set_state(bool led_on) {
if (status_led_via_colored_status_led()) {
return colored_status_led_set_state(led_on);
} else if (status_led_supported()) {
#if defined(PICO_DEFAULT_LED_PIN)
#if PICO_DEFAULT_LED_PIN_INVERTED
gpio_put(PICO_DEFAULT_LED_PIN, !led_on);
#else
gpio_put(PICO_DEFAULT_LED_PIN, led_on);
#endif
return true;
#elif defined(CYW43_WL_GPIO_LED_PIN)
cyw43_gpio_set(&cyw43_state, CYW43_WL_GPIO_LED_PIN, led_on);
return true;
#endif
}
return false;
}
This is found in the status_led.h file included in the Pico SDK.
Just sharing this as general info.
Cheers!
1 Like
If I set the board type or pico2_w, it works. Which board is causing problems?
I set the board type to pico2_w
set(PICO_BOARD pico2_w CACHE STRING "Board type").
The Board is a normal Pico 2WH.
Iāll try another time to see if I missed something else.
1 Like
I did another test.
Confirm that using this option in CMakeList.txt
target_compile_definitions(picocalc-text-starter PRIVATE PICO_DEFAULT_LED_PIN)
the program works fine without a runtime error is generated.
Thanks for creating this Starter Kit. I was wondering how I was going to figure out how to talk to all these peripherals, and youāve just given me a huge head start to doing that.
1 Like
This is why I created it. Please donāt assume itās perfect, itās not.
Hopefully it will get you on your feet with the PicoCalc quickly!
I understand this. It might not be perfect, but itās much better than the blank page I had.
1 Like
Blair,
This is great! Thanks so much for developing it!
Once I saw the uf2 loader, I started thinking if add a text-oriented BIOS/stdlib APIset, and process mgmt infrastructure, weād have a platform for a GP picoOS/DOS. Seems like youāve now provided the BIOS/stdlib part of that, so thanks!
Is there any provision for different size fonts in the text system? My eyes are too old to deal with 8x8 chars without a permanent magnifying glass mounted on the PicoCalc, so Iād definitely prefer if I could use in text-mode but with larger font size (as available for PicoMite & zeptoforth).
(question pulled ā answered in the repo, that ANSI emulation is supported)
That does make me ask, though, how much ANSI emulation is present? Iām just trying to get a sense of where it falls between VT52 and Kitty (which actually extends the ANSI protocol significantly).
Again, thanks so much for doing this!
1 Like
Thank you for your kind words!
What size of font are you thinking about? Currently, there is 40 columns (8x10) and 64 columns (5x10), both 32 rows.
The ANSI emulation is close to xterm at the moment with support for 24-bit colour. VT100 is very good. There are some bugs that I am chasing down.
For example, top and htop run clean but btop requires 80 columns. Pico/nano and vi still have a problem somewhere.
On fonts, my feeling is, if there can be options, then support all such options, and let devs choose at āstarter build timeā and/or at runtime ā f.e. let them choose at build what among the available fonts are included for runtime use, then have a pref or something at start which to use that can be changed somehow if the user needs larger fonts.
How is the āmodularityā of whatās there, in terms of the environment it expects at boot (is it fully UF2 Loader compatible?), and whether the core APIs could easily be split off into one or more flash-loaded modules, separating the drivers and library code from the infrastructure that use them?
Hereās why Iām asking: Iām thinking if the drivers and library can be a āpre-resident BIOSā early-loaded somehow and always around in mem, then UF2 Loader itself could also make use of them (as, theoretically, could the images it loads).
At that point, add some process mgmt, shell and linker-loader (static loading initially with only āpre-residentā shared, then fully dynamic loading down the road), and weāre almost reached 1980s-era DOS. ;D
As RPi Pico toolchain object & binary files are already ELF objects āat heartā, getting together an āarm64-/ELF-compatibleā linker-loader (and eventually, full dynamic-linker-loader) shouldnāt be too difficult, and probably wouldnāt even disrupt use of current toolchain ā building would just omit the elf2uf2 step, and instead build ELF executables (when targeting that future environment).
@jwiede OK, this is going beyond what this starter kit is (I can see where you are going). Feel free to run with this idea and use what you can from the starter kit!
I use the starter kit to write my software, and I upgrade it when I need to functionality. I also have a PR from the community.
Where you want to go is different, conceptually bigger, that is, then where I am. For your idea, the starter kitās drivers will need to be hardened and made more suitable for that use case.
Thatās not advisable - the bootloader is already extremely efficient and robust, and any incremental size improvement wonāt be enough to free up a single extra flash page, so itās effectively pointless. And adding shared dependencies only causes compatibility issues when the apps and bootloader disagree on what version of the base library they want. Itās bad enough that we have a couple of keyboard firmware versions that conflict with apps already.
I already considered writing an elf loader, but it would have been larger and less reliable than the uf2 code, along with losing some critical platform functionality in the process. UF2 is the right tool for that job.
If you want to explore the techniques, then absolutely, go ham with your application and itās sub-apps. Jblanked is already doing something roughly similar with his picoware.
@BlairLeduc, Thank you for building the PicoCalc Text Starter Kit, it was amazingly easy to use. I was able to do a quick and dirty port of uBasic in just a couple of hours.
3 Likes