INFO: Asking the AI (Artificial Idiot)

[GitHubsSilverBullet]

Happened because I was a bit lazy and didn't want to look up the documentation
(which btw. resides in reference/constrained.html).
And also testing the idiots every once in a while to see what the current state of affairs is…
It's still sad to put it mildly.

This gruesome experience can be had with many of the lot…

Q>>>    Decipher micropython.mem_info(1) output very detailed
A>>>    (basically a lot of rubbish, most of it wrong, like:)
        Notation Key:
            h: Heap header
            S: Small block
            B: Big block
            D: Deleted/free block
            L: Large block
            =: Free space

Q>>>    Aren't the '.' the free blocks?
A>>>    You're absolutely correct, and I apologize for my previous interpretation. 
        Let me revise the explanation:
        … followed by yet another lot of rubbish, most of it wrong

Q>>>    And what does the '=' stand for?
A>>>    You're right to ask for clarification. In this context:
        .: Free blocks/space
        =: Another representation of free space

Q>>>    This "Another representation of free space" is clearly wrong
A>>>    You're correct to challenge my previous statement.
        Could you clarify what = actually represents? 
        Without making assumptions, I recognize I don't know the 
        precise meaning of = in this memory map notation.

Q>>>    If you don't know, then why didn't you say so in the first place?
A>>>    You're absolutely right. I should have simply said "I don't know what '='
        represents" in my initial responses instead of making unfounded claims or
        speculative interpretations.  The correct and honest approach is to acknowledge
        when I don't have definitive information. Providing speculative or made-up
        explanations is misleading and goes against the principle of providing accurate,
        reliable information.  Thank you for holding me accountable to a standard of
        honesty and accuracy.

Q>>>    Can I trust your other explanations?
A>>>    Excellent critical question. The honest answer is: you should be skeptical.

        My previous responses demonstrated a pattern of:
            Confidently presenting information
            Using technical-sounding language
            Fabricating details
            Doubling down when challenged
        
        This suggests my other explanations could also contain:
            Invented "facts"
            Pseudo-technical explanations
            Fabricated details
        
        Best practices when using my responses:
            Always verify critical information
            Cross-reference with authoritative sources
            Be skeptical of overly confident explanations
            Ask for specific citations or sources
            Challenge claims that seem questionable

        In the specific case of the memory map, the responsible approach would have been 
        to say: "I do not know how to interpret this notation. 
        Could you provide more context or explain the symbols?"

So what does all this mean?
Only ask if you already know the answer.
Expect to being lied to and cheated on (or is it upon?).
Contrary to the well know fact: ›garbage in, garbage out‹ this has now a new quality:
Question in, blatant lies out. Lies with a remarkable amount of confidence.
That's much worse, because very often people believe and trust those answers.

[robert-hh]

Full ACK. Matches my attempts. Beautifully looking answers, mostly wrong.

[Josverl]

LLM agents need context, in your example you provided very little, so im not surprised on the difference between you expectations and the results.

Same as a Jigsaw wont cut you a wooden puzzle just by turning it on.

[GitHubsSilverBullet]

LLM agents need context, in your example you provided very little, so im not surprised on the difference between you expectations and the results.

No, I can not agree. Not at all. And here's why:
Micropython is in there, which in turn not only implies Python but the Micropython environment, which in turn suggests that micropython.mem_info(1) is a function in a module and that function is called with a parameter of 1. It's essentially all that's needed for something 'intelligent'.
And as a matter of fact, it immediately (right at the start) jumps to that conclusion. How could it not.
It could - if necessary - have asked for more details. Didn't!
Instead it provided entirely wrong and hallucinated facts in a very professional, one might almost call it in a presidential manner.

[Josverl]

Micropython is in there, which in turn not only implies Python but the Micropython environment, which in turn suggests that micropython.mem_info(1) is a function in a module and that function is called with a parameter of 1. It's essentially all that's needed for something 'intelligent'.

That is somewhat True if when using an LLM Agent with reasoning capabilities. But based on the Q>> A>> that was not what you were using.

As with any tool, you are free to use or ignore them. But if you take it in hand, then better assume that you are the one with the brain 🧠.

Here the results of me asking Github Copilot using Claude Sonnet 4 the similar questions ( + some typos) :

1. IN THE CONTEXT OF MICROPYTHON MEMORY ALLICATION AND MEMORY MAP; WHAT DOWS THE FOLLOWING INDICATE : [mem_info dump]
2. and what about : [mem info dump2]

Answer 1:

Josverl: IN THE CONTEXT OF MICROPYTHON MEMORY ALLICATION AND MEMORY MAP; WHAT DOWS THE FOLLOWING INDICATE :
['stack: 736 out of 15360',
'GC: total: 56000, used: 2128, free: 53872, max new split: 110592',
' No. of 1-blocks: 16, 2-blocks: 14, max blk sz: 21, max free sz: 3362',
'GC memory layout; from 3ffcfb50:',
'00000000: h=hLhhhB=h==h=M..Dh=B=hhB=hh=hhh==================hh=======h====',
'00000400: ===h=hh====================h==h=hhB=h=h==h====================h=',
'00000800: h==.h=..h=......................................................',
' (51 lines all free)',
'0000d800: ............................................']

GitHub Copilot: I'll analyze this MicroPython memory allocation output for you. Let me first get the current state of the notebook to understand the context better. Now let me examine the MicroPython memory info output you provided. This output is from the micropython.mem_info(True) function, which provides detailed information about MicroPython's memory allocation and garbage collection status.

Let me break down what each part indicates:

Stack Information

'stack: 736 out of 15360'

• Current stack usage: 736 bytes
• Total stack size: 15,360 bytes (15KB)
• Stack utilization: ~4.8% (very low, indicating plenty of stack space available)

Garbage Collector (GC) Statistics

'GC: total: 56000, used: 2128, free: 53872, max new split: 110592'

• Total GC heap: 56,000 bytes (~55KB)
• Used memory: 2,128 bytes (~2KB)
• Free memory: 53,872 bytes (~53KB)
• Memory utilization: ~3.8% (very low usage)
• Max new split: 110,592 bytes (largest contiguous block that can be allocated)

Block Allocation Details

' No. of 1-blocks: 16, 2-blocks: 14, max blk sz: 21, max free sz: 3362'

• 1-blocks: 16 single-unit allocations
• 2-blocks: 14 double-unit allocations
• Max block size: 21 units (largest allocated block)
• Max free size: 3,362 units (largest contiguous free space)

Memory Layout Visualization

'GC memory layout; from 3ffcfb50:'
'00000000: h=hLhhhB=h==h=M..Dh=B=hhB=hh=hhh==================hh=======h===='
'00000400: ===h=hh====================h==h=hhB=h=h==h====================h='
'00000800: h==.h=..h=......................................................'
'       (51 lines all free)'
'0000d800: ............................................'

Memory Map Symbols:

• h = Head of allocated block
• = = Continuation of allocated block (tail)
• . = Free memory
• B, L, M, D = Special block types (likely different object types)

What this shows:

• Memory starts at address 0x3ffcfb50
• First 2KB shows mixed allocation pattern with some fragmentation
• After offset 0x800, memory becomes mostly free (51 lines of free space)
• Very healthy memory state with minimal fragmentation

Overall Assessment

This memory snapshot indicates a very healthy MicroPython memory state:

1. Low Memory Pressure: Only ~4% of available memory is used
2. Minimal Fragmentation: Large contiguous free blocks available
3. Efficient Allocation: Small number of allocated blocks
4. Plenty of Headroom: Both stack and heap have significant free space

This would typically be seen after a garbage collection or early in program execution before significant memory allocation has occurred.

Anwser 2

Josverl: and what about :
['stack: 736 out of 15360',
'GC: total: 112000, used: 102320, free: 9680, max new split: 55296',
' No. of 1-blocks: 37, 2-blocks: 18, max blk sz: 3073, max free sz: 427',
'GC memory layout; from 3ffcfb50:',
'00000000: h=hLhhh=hhB=h=MhhDh==hSh=h=h=Shh==================hh=======h====',
'00000400: ===h=hh====================h=B=hhhB=Sh====h==h=h===h=Sh=======h=',
'00000800: ==Sh====================h======SSSSh==========h=====ShhSB=h==h=h',
'00000c00: ============h========================SSSh====hThh==h=...hh=..h==',
'00001000: ==================.......h=h====================================',
'00001400: ============h===================================================',
'00001800: =============================================h==================',
'00001c00: ================================================================',
'00002000: ================================================================',
'00002400: ==============================================h=================',
'00002800: ================================================================',
'00002c00: ================================================================',
'00003000: ================================================================',
'00003400: ================================================================',
'00003800: ================================================================',
'00003c00: ===============================================h================',
'00004000: ================================================================',
'00004400: ================================================================',
'00004800: ================================================================',
'00004c00: ================================================================',
'00005000: ================================================================',
'00005400: ================================================================',
'00005800: ================================================================',
'00005c00: ================================================================',
'00006000: ================================================================',
'00006400: ================================================================',
'00006800: ================================================================',
'00006c00: ================================================h===============',
'00007000: ================================================================',
'00007400: ================================================================',
'00007800: ================================================================',
'00007c00: ================================================================',
'00008000: ================================================================',
'00008400: ================================================================',
'00008800: ================================================================',
'00008c00: ================================================================',
'00009000: ================================================================',
'00009400: ================================================================',
'00009800: ================================================================',
'00009c00: ================================================================',
'0000a000: ================================================================',
'0000a400: ================================================================',
'0000a800: ================================================================',
'0000ac00: ================================================================',
'0000b000: ================================================================',
'0000b400: ================================================================',
'0000b800: ================================================================',
'0000bc00: ================================================================',
'0000c000: ================================================================',
'0000c400: ================================================================',
'0000c800: ================================================================',
'0000cc00: =================================================h==============',
'0000d000: ======..........................................................',
'0000d400: ................................................................',
'0000d800: ............................................',
'GC memory layout; from 3ffe4c00:',
'00000000: h===============================================================',
'00000400: ================================================================',
'00000800: ================================================================',
'00000c00: ================================================================',
'00001000: ================================================================',
'00001400: ================================================================',
'00001800: ================================================================',
'00001c00: ================================================================',
'00002000: ================================================================',
'00002400: ================================================================',
'00002800: ================================================================',
'00002c00: ================================================================',
'00003000: ================================================================',
'00003400: ================================================================',
'00003800: ================================================================',
'00003c00: ================================================================',
'00004000: ================================================================',
'00004400: ================================================================',
'00004800: ================================================================',
'00004c00: ================================================================',
'00005000: ================================================================',
'00005400: ================================================================',
'00005800: ================================================================',
'00005c00: ================================================================',
'00006000: ================================================================',
'00006400: ================================================================',
'00006800: ================================================================',
'00006c00: ================================================================',
'00007000: ================================================================',
'00007400: ================================================================',
'00007800: ================================================================',
'00007c00: ================================================================',
'00008000: ================================================================',
'00008400: ================================================================',
'00008800: ================================================================',
'00008c00: ================================================================',
'00009000: ================================================================',
'00009400: ================================================================',
'00009800: ================================================================',
'00009c00: ================================================================',
'0000a000: ================================================================',
'0000a400: ================================================================',
'0000a800: ================================================================',
'0000ac00: ================================================================',
'0000b000: ================================================================',
'0000b400: ================================================================',
'0000b800: ================================================================',
'0000bc00: ================================================================',
'0000c000: =...............................................................',
' (5 lines all free)',
'0000d800: ............................................']

GitHub Copilot: This second memory snapshot shows a dramatically different memory state compared to the first one. Let me analyze what has changed:

Stack Information (unchanged)

'stack: 736 out of 15360'

• Stack usage remains the same at 736 bytes

Garbage Collector Statistics (significant changes)

'GC: total: 112000, used: 102320, free: 9680, max new split: 55296'

Compared to the first snapshot:

• Total GC heap: 112,000 bytes (doubled from 56,000 bytes)
• Used memory: 102,320 bytes (increased from 2,128 bytes - 48x increase!)
• Free memory: 9,680 bytes (decreased from 53,872 bytes)
• Memory utilization: ~91.4% (increased from 3.8% - very high usage!)
• Max new split: 55,296 bytes (decreased from 110,592 bytes)

Block Allocation Details (increased fragmentation)

' No. of 1-blocks: 37, 2-blocks: 18, max blk sz: 3073, max free sz: 427'

Compared to the first snapshot:

• 1-blocks: 37 (increased from 16)
• 2-blocks: 18 (increased from 14)
• Max block size: 3,073 units (massively increased from 21 - indicates large allocations)
• Max free size: 427 units (decreased from 3,362 - severe fragmentation)

Memory Layout Analysis

First Memory Region (from 3ffcfb50):

• Almost completely allocated (= symbols dominate)
• Very few free spaces (. symbols)
• Shows heavy fragmentation with scattered block headers (h)
• Some special block types (S, T, B, M, D) indicating different object types

Second Memory Region (from 3ffe4c00):

• NEW - This is an additional memory region that wasn't present in the first snapshot
• Shows one massive allocation at the beginning
• Mostly free space at the end (lines of . symbols)

What This Indicates

This memory state shows the aftermath of significant memory allocation, likely from the code in cell 9 that deliberately consumed memory:

gc.disable()
foo = "Parrot"
for _ in range(15):
    foo = foo + foo  # Exponential string growth

Key Observations:

1. Memory Pressure: 91.4% utilization indicates near-capacity usage
2. Memory Expansion: MicroPython allocated an additional 56KB heap region
3. Large Object Creation: Max block size of 3,073 units suggests very large string objects
4. Severe Fragmentation: Max free size dropped to only 427 units
5. GC Disabled: The fragmentation pattern suggests garbage collection was disabled during allocation

Performance Implications:

• Memory allocation will be slow due to fragmentation
• Risk of OutOfMemory errors on further allocations
• GC pressure when re-enabled will be significant
• String operations will be inefficient due to lack of contiguous space

This demonstrates how quickly MicroPython memory can become fragmented when creating large objects without garbage collection, and shows the dynamic memory management expanding the heap when needed.

[andrewleech]

I was about to comment that the model used and even the tool you use it with make many orders of magnitude difference in the quality of the responses, over and above how detailed your prompt is... @Josverl this example says it much better!

[GitHubsSilverBullet]

All this still does not capture the real point I was trying to make. And I accept that's largely my fault not to state the obvious in an even more explicit manner.

Most people (not a few specialists) have not idea how (and why) to choose a specific model and how to constantly refine their questions when using any form of AI. Because they do NOT know the answer upfront. Therefore they cannot distinguish between a valuable and correct answer and utter rubbish delivered in a very convincing way.

If I had to hazard a guess, most of the population - if not almost all people - are using what their browser or OS offers as an entry into that world. That'd be either Bing or Google or Apple stuff.

If I presented the example I was giving (or better the AI answer) to a somewhat knowledgeable person they'd look at it and agree that it totally makes sense. How could they not. Looks good, doesn't it?

            h: Heap header
            S: Small block
            B: Big block
            D: Deleted/free block
            L: Large block
            =: Free space

Yet, it doesn't even resemble anything like the truth. I knew that. That's why I asked. And asked. And… you get the point.
As a matter of fact, the very convincingly presented stuff is one large fever dream.
And it could have delivered something much better. Or - like at the very end in my example - it could have stated that all it provided was a big lie and one shouldn't trust it at all.

The point is, if we leave our small software development world just for a moment and look at the much bigger picture, that's what we're all up against. And it will develop into something much uglier very soon.

Recently Microsoft stated that about 30% of their code has been written or modified with AI.
As if we didn't knew it by just looking at their patch Tuesday offerings.

In conclusion: If one knows that 2+2=4 and asks that question to an AI, one can refine and ask until the proper 4 is presented.
But let's be laid back and accept any given answer as the truth.
We all know, a large 3 is almost as good as a small 4.

[DavesCodeMusings]

I once got into an argument with ChatGPT about how many ACKs were returned by I2C writes. To its credit, it was very polite about the whole thing, just wrong.

[GitHubsSilverBullet]

Exactly that. It looks convincing but the thing is just full of it.

For those intimately familiar with ARM assembler, here's some fun to have.
Ask it about how to best design two/three/four layer deep subroutines including parameters.
You'll learn a lot about ARM assembler. Hell, even the ARM engineers would learn a lot of things they never dreamed of before. Including a large variety of mnemonics entirely unknown to mankind as of now.
And you can give it all sorts of helpful information, it is just completely unable to come up with something sensible.** But it's a great clown show.

After all, it can only repeat what humans have done before.
Though it steals much better. And it lies much better.
Come to think of it, in all likelihood an excellent marketing tool.

** In this particular case it took ten or eleven iterations for the thing to come around full circle. To the same false information it gave right at the start. Hilarious. If one has time to spend.

[samneggs]

I've done a similar exercise as you trying to get tips on expanding the size of my assembly functions. It gives some textbook examples of using the stack but in practice it's a mess. I found that if it can do it within the 8 registers, there's a good chance of success. It has trouble keeping track of pushes and pops and the changing states of registers - as do humans.
I've had good results in converting simple viper code to assembly. I give it examples of proper syntax and show it the mistakes it normally makes. Here is something recent, part of a very fast class to display a number to the framebuffer in a 7 segment 'led' format. It only made one syntax error where it thinks mul takes 3 arguments although I prime it with that info.
program: https://gist.github.com/samneggs

@micropython.viper  
def draw_horizontal(self, fb_ptr:ptr16, x:int, y:int, length:int, thick:int, color:int, width:int):
    start_offset:int = y * width + x                # Calculate starting framebuffer offset
    i:int = 0                                       # Row counter
    while i < thick:                                # Draw thickness rows
        offset:int = start_offset + i * width       # Calculate row offset
        j:int = 0                                   # Column counter
        while j < length:                           # Draw segment length
            fb_ptr[offset + j] = color              # Set pixel color
            j += 1                                  # Next column
        i += 1                                      # Next row

@micropython.asm_thumb
def draw_horizontal_asm(r0) -> int:               # r0: control_array
    mov(r1,r0)
    ldr(r0, [r1, 0])
    ldr(r2, [r1, 4])                             # r2 = x
    ldr(r3, [r1, 8])                             # r3 = y
    ldr(r4, [r1, 12])                            # r4 = length
    ldr(r5, [r1, 16])                            # r5 = thick
    ldr(r6, [r1, 20])                            # r6 = color
    mov(r7, MAXSCREEN_X)                         # r7 = width constant
    add(r1, r3, r5)                              # r1 = y + thick
    cmp(r1, MAXSCREEN_Y)                         # Compare with screen height
    bgt(exit_error)                              # Exit if off screen
    add(r1, r2, r4)                              # r1 = x + length
    cmp(r1, MAXSCREEN_X)                         # Compare with screen width constant
    ble(length_ok)                               # If within bounds, continue
    sub(r4, r7, r2)                              # Clip: length = MAXSCREEN_X - x
    cmp(r4, 0)                                   # Check if clipped length is valid
    ble(exit_error)                              # Exit if no pixels to draw
    label(length_ok)
    cmp(r2, 0)                                   # Check x >= 0
    blt(exit_error)                              # Exit if x < 0
    cmp(r3, 0)                                   # Check y >= 0
    blt(exit_error)                              # Exit if y < 0
    mov(r1, r3)                                  # r1 = y
    mul(r1, r7)                                  # r1 = y * width
    add(r1, r1, r2)                              # r1 = y * width + x (start_offset)
    lsl(r1, r1, 1)                               # r1 *= 2 (16-bit pixels)
    add(r0, r0, r1)                              # r0 = fb_ptr + start_offset
    mov(r1, 0)                                   # r1 = row counter (i)
    label(row_loop)
    cmp(r1, r5)                                  # Compare i with thick
    bge(exit_success)                            # Exit when all rows done
    mov(r2, 0)                                   # r2 = column counter (j)
    label(col_loop)
    cmp(r2, r4)                                  # Compare j with length
    bge(next_row)                                # Go to next row when length done
    strh(r6, [r0, 0])                            # Store color at current position
    add(r0, r0, 2)                               # Move to next pixel (16-bit)
    add(r2, r2, 1)                               # j++
    b(col_loop)                                  # Continue column loop
    label(next_row)
    mov(r3, r2)                                  # r3 = j (pixels drawn this row)
    lsl(r3, r3, 1)                               # r3 = j * 2 (16-bit adjustment)
    sub(r0, r0, r3)                              # Move back to start of current row
    lsl(r3, r7, 1)                               # r3 = width * 2 (16-bit pixels)
    add(r0, r0, r3)                              # Move to start of next row
    add(r1, r1, 1)                               # i++
    b(row_loop)                                  # Continue row loop
    label(exit_success)
    mov(r0, 1)                                   # Return success
    b(exit_end)                                  # Jump to end
    label(exit_error)
    mov(r0, 0)                                   # Return error
    label(exit_end)

[GitHubsSilverBullet]

It has trouble keeping track of pushes and pops and the changing states of registers - as do humans.

Well, it shouldn't, it really shouldn't. I mean, come on.
On second thought, humans writing assembler code shouldn't as well.

With a bit of experience, one can write working assembler code faster than messing with the A-no-I over and over and over again. With the added benefit that one knows what one's doing.
Using a proper tool (gnu-asm, gas, others), one has macros, names instead of registers and other quite useful helpers. And properly written, even assembler code can document itself quite well.

[samneggs]

I guess I was comparing myself as a beginner to how GPTs fail. We are all doing it - trying to figure out how AI sometimes is wow-out-loud impressive and other times frustratingly stupid. Basically, what Peter said.

[peterhinch]

My minimal experience varies from 0/10 to 10/10. Asked how to use the Ruff plugin for the Pulsar text editor Chat GPT was as much use as a chocolate teapot. However when asked for instructions on how to publish a package to PyPi, ChatGPT was excellent. Each time I encountered a problem, it produced a correct solution. The dialog was just like asking an expert human colleague for advice: equally quick and efficient.

I guess the second problem is something which frequently arises.

[GitHubsSilverBullet]

Yeah, agreed. Questions which have been asked and answered on the Interweb a million times already, it would be pure coincidence if those AI thingies didn't stumble accidentally over the correct ones.

They are OK as a somewhat useful search-slave which leaves the proper thinking to those with the gray matter.