If there's a (room) function can we have a (board) function?

#1

Shirley we can have a (board) function. Room & board go together like rum and Coke™. :)
I was thinking (amazing!) that maybe return a list of the board, variant, memory, and maybe
clock frequency although I’d be happy with a compiled in board name. Just a thought…

While we’re at it, how 'bout a (save-image) for the Pico? There’s gobs of flash there and more
than enough for a copy or two of all the RAM on the board, no?

What about (save-image) for the Pico?
#2

Common Lisp, which I believe uLisp strives for compatibility with, has some interesting corners. In reference to this suggestion, allow me to point to three of them:

I think one problem here is that adding additional symbols (functions) to the ‘base set’ for uLisp has costs - in particular, because adding symbols takes ever-more space in flash, and on the Arduino Uno we’re already just about flush against the limit. That problem aside, I would enthusiastically support adding these kinds of “which board am I running on” functions.

#3

I understand. A MACHINE-TYPE would be fine.
I still like the function name of BOARD though. :)

#4

It’s odd that the Arduino core doesn’t have such a function (as far as I know). The best you can do is try each of the #defines, such as:

#if defined(__AVR_ATmega328P__)
#5

A post was split to a new topic: What about (save-image) for the Pico?

#7

Arduino has a very decidedly C-based view on the world, where this sort of thing is not something you ask about at runtime. As a matter of fact, Arduino takes this considerably further than standard C(++) does, such as by inventing its own I/O API that has separate functions per-stream.

I want to note that the hardware itself does not share this view - not only do even the older MCUs have ways to inquire for their model, the more recent ones tend to have serial numbers accessible to software.

#8

Can anyone suggest an application that won’t be possible without a (board) function or equivalent?

That would help decide if it’s necessary, and if so, what information it should provide.

#9

Using the same source code on the different MCU’s which have different number of GPIO pins, number of SPI, I2C, etc let alone, my favorite, which pin has the blinken LED on it. Being able to adjust for whether Flash is on the SPI bus or part of the address space.

Back in my early PC days we used such a global variable (PC Scheme) to allow functions to adjust for different video modes and graphics capabilities.

   -Rusty-
#10

I’m not sure it really allows for things that aren’t possible otherwise, but it can make some things easier. Let’s take an example from the AVR assembler and move part of the textual description into the code:

(defvar vport
  (cond ((string= (board) "AVR128DA48") 8)
        ((string= (board) "AVR128DB48") 4))

(defvar led
  (cond ((string= (board) "AVR128DA48") 6)
        ((string= (board) "AVR128DB48") 3))

(defcode on ()
  ($sbi vport led) ; Set LED bit in DIR
  ($cbi (+ vport 1) led) ; Clear LED bit in OUT
  ($ret))

(defcode off ()
  ($sbi (+ vport 1) led) ; Set LED bit in OUT
  ($ret))
#11

In Version 4.0 of uLisp I’ve added a keyword :led-builtin to provide this; for example, you can now do:

(defun blink (&optional x)
  (pinmode :led-builtin :output)
  (digitalwrite :led-builtin x)
  (delay 1000)
  (blink (not x)))