lurk101 / pshell Goto Github PK

Over in HPCguy/Squint, everything in pull request #82 above line 960 and the entirety of the follow-on pull request #83 provides a fix for really bad pointer bugs. Squint still doesn't have forward declarations, hence the cut and paste sections in pull request #83, that could esily be consolidated in a small function.

Hello:
I use CC to compile this code to prompt "program data exceptions data segment"

char tmp[4096];
int main(){
return 0;
}

I found that the data side size defined in the code is 16k，but I only used 4k.
#define DATA_ BYTES (16 * K) // data segment size
What is the problem?

Hello,

The idea of having the file system on the internal flash is great as it makes the project self-contained, but I use my Pico for other things (essentially VGA stuff with the VGA demo board) and the files get wiped every time.

Does anyone has implemented SD card support, especially with the VGA demo board (which has a special way to hook it up as there aren't much GPIO pins left with RGB555 using 15 pins) ?

It has already been done for the PT52 project, cf. https://gitlab.com/DarkElvenAngel/pt52.

Running Pico Shell v1.2.22, LittleFS v2.5, Vi 0.9.1, SDK v1.5.0

I receive this error when running rndtest.c

`/code/: cc rndtest.c

Error : Unknown external function get_rand_32
14: ++histogram[(get_rand_32() >> 28) & 0xf];

`

You might want to create new "Immediate" IR nodes that take an immediate argument. Example:

in run():
case AddIMM:
a.i += *pc++;

in gen():
int *b; // add a tmp var at top of function:

case Add:
    gen((int*)n[1]);  *++e = PSH; b = e; gen(n + 2);
    if ((e - b) == 2 && b[1] == IMM) {
       *b = AddIMM; b[1] = b[2]; e = ++b;
    }
    else *++e = ADD;
    break;

By doing this, three IR instructions become one, so less iterations of run():

PUSH
IMM 1 --> AddIMM 1
ADD

And also, push/pop overhead is reduced.

I would have made the pull request myself, but I can't compile your code in my programming environment.

I suggest you test it with Advent of Code day8. Just an AddIMM and SubIMM should speed it significantly.

Please post timing results in your pshell thread at raspberrypi.com. Thanks.

in V1.2.9, executable search order is current directory followed by /bin directory

Yes, but it only works if current directory is /
If you are currently in a subdirectory and the program is in /bin you 've got an "unknown command" message
If you are currently in a subdirectory and the program is in this subdirectory you 've got an "unknown command" message
From a subdirectory, it works if the full path is specified ../bin/progname

Probably not really a problem but should be explain at least

Using latest version 1.2.22

File system was created by previous version, it had only 2 small files on it. One was a small C program and the other was a text file.

Attempting to cat either of those files results in PANIC and dropping out of terminal mode.

Using MacBook Pro (latest OS) screen command.

vi works fine as does the C compiler, haven't tested any other things.

Great program by the way.

I have been able to "put xx.bin" file and Xmodem "CtrlAS xx.bin" and the file transfers to pico littlefs.
On the Raspberry Pi the xx.bin is 4160 bytes. On littlefs the size shows 4224.
I still have not been able to transfer between pico "get xx.bin" to Raspberry Pi Xmodem "CtrlAR xx.bin".
Any help is appreciated. Thanks in advance.

hello,

it's a nice project!

you should document on the readme how to connect to the pico once it has been flashed.

for example using screen or minicom on Linux:

copy the pshell_usb.uf2 into your raspberry pico
screen /dev/ttyACM0 115200
# or
minicom -b 115200 -D /dev/ttyACM0

even "screen /dev/ttyACM0" should be enough btw
(I found some help from this website https://michlstechblog.info/blog/raspberry-pi-serial-console/)

Here is the content of the file system on my pico and the values returned by status.
The block size is 4096 so 22 blocks should be used if I am not mistaken

/: ls /bin

     428 blink
     664 sieve

/: ls /code

     580 blink.c
     364 clocks.c
     128 clrscr.c
     121 crash.c
      68 essai.txt
     387 essaigetchar.c
     976 fade.c
      51 hello.c
    2440 life.c
    5357 lorenz.c
    2104 penta.c
     222 pi.c
     370 pi2.c
     558 sieve.c
     362 sine.c
     673 string.c
     256 tictoc.c
   10188 wumpus.c

/: status

total blocks 448, block size 4096, used 20 (1792K), 4.5% used.

/: 

I first thought that /bin was not taken into account but If I compile wumpus.c to /bin/wumpus, new blocks are used

/code/: ls /bin

     428 blink
     664 sieve
    8860 wumpus

considering the size of wumpus i suppose two new blocks are used. But status returns

/code/: status


total blocks 448, block size 4096, used 23 (1792K), 5.1% used.

If I delete /bin/wumpus the original status is returned
If I now make a copy of a small file say essai.txt

/code/: cp essai.txt essai2.txt

file /code/essai.txt copied to /code/essai2.txt

/code/: ls

     580 blink.c
     364 clocks.c
     128 clrscr.c
     121 crash.c
      68 essai.txt
      68 essai2.txt
     387 essaigetchar.c
     976 fade.c
      51 hello.c
    2440 life.c
    5357 lorenz.c
    2104 penta.c
     222 pi.c
     370 pi2.c
     558 sieve.c
     362 sine.c
     673 string.c
     256 tictoc.c
   10188 wumpus.c

/code/: status

total blocks 448, block size 4096, used 20 (1792K), 4.5% used.

So it seems that small files are not taken into account or that they are all stored in one block (??)

• pshell v1.2.2
• USB interface
• minicom as terminal

Using vi in pshell, when moving cursor with left or right arrow. Sometimes the end of the line disappears

Edit: the problem comes from minicom not pshell. There is no problem when using h, j, k,l but only when using the arrows.

(1) The compiler runs faster when using arrays vs pointers. Since all your arrays are so small, you might want to consider putting them all in the .data or .bss segment instead of using malloc.
Example:

static struct member_s {
struct member_s* next;
struct ident_s* id;
int offset;
int type;
int etype;
int pad;
} *members[1024];

(2) Stay away from manipulating floats where possible.
Example:

case IMMF:
a.i = *pc++; // vs old a.f = *((float*)pc++);
break;

Hello:
I wanted to generate your software and I have this error during the cmake under windows 11:

E:\Pico\pshell\build>cmake ..
-- Building for: Visual Studio 16 2019
Using PICO_SDK_PATH from environment ('E:\Pico\Pico\pico-sdk')
PICO_SDK_PATH is E:/Pico/Pico/pico-sdk
Defaulting PICO_PLATFORM to rp2040 since not specified.
Defaulting PICO platform compiler to pico_arm_gcc since not specified.
-- Defaulting build type to 'Release' since not specified.
PICO compiler is pico_arm_gcc
-- The C compiler identification is MSVC 19.28.29336.0
-- The CXX compiler identification is MSVC 19.28.29336.0
-- The ASM compiler identification is GNU
-- Found assembler: E:/Pico/Tools/10 2020-q4-major/bin/arm-none-eabi-gcc.exe
Build type is Release
Defaulting PICO target board to pico since not specified.
Using board configuration from E:/Pico/Pico/pico-sdk/src/boards/include/boards/pico.h
-- Found Python3: C:/Users/Vincent/AppData/Local/Programs/Python/Python39/python.exe (found version "3.9.1") found components: Interpreter
TinyUSB available at E:/Pico/Pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
CMake Error at E:/Pico/Pico/pico-sdk/src/rp2_common/tinyusb/CMakeLists.txt:24 (include):
include could not find load file:

E:/Pico/Pico/pico-sdk/lib/tinyusb/hw/bsp/family_support.cmake

-- Found Git: E:/Pico/Tools/Git/cmd/git.exe (found version "2.30.0.windows.2")

-- CMake 3.19.4
-- Build Release / PICO
-- USB_CONSOLE ON, using USB

-- Configuring incomplete, errors occurred!

I don't know where the problem comes from and I couldn't find anything on the internet to guide me.
Do you have an idea .
Thanks

What would be the effect of using halfwords, or even bytes, for the VM IR on the Pico? I'm not familiar enough with the architecture to know how it would impact performance. One clear benefit is that you could fit larger programs in the tight memory space on the Pico. Maybe this could be another Makefile configured option?

Host is Raspberry Pi CM4 running PiOS 64 bit.

Scanning dependencies of target pshell_usb
[ 12%] Building C object CMakeFiles/pshell_usb.dir/main.c.obj
[ 13%] Building C object CMakeFiles/pshell_usb.dir/xreceive.c.obj
[ 14%] Building C object CMakeFiles/pshell_usb.dir/xtransmit.c.obj
[ 15%] Building C object CMakeFiles/pshell_usb.dir/crc16.c.obj
[ 16%] Building C object CMakeFiles/pshell_usb.dir/fs.c.obj
[ 17%] Building C object CMakeFiles/pshell_usb.dir/vi.c.obj
[ 18%] Building C object CMakeFiles/pshell_usb.dir/cc.c.obj
/home/znmeb/Projects/pshell/cc.c: In function 'cc':
/home/znmeb/Projects/pshell/cc.c:4148:13: error: a label can only be part of a statement and a declaration is not a statement
             int sysc = *pc++;
             ^~~
/home/znmeb/Projects/pshell/cc.c:4177:17: error: a label can only be part of a statement and a declaration is not a statement
                 int strl = strlen((void*)sp[0]);
                 ^~~
/home/znmeb/Projects/pshell/cc.c:4178:17: error: expected expression before 'void'
                 void* strp;
                 ^~~~
/home/znmeb/Projects/pshell/cc.c:4179:23: error: 'strp' undeclared (first use in this function); did you mean 'strl'?
                 if (!(strp = sys_malloc(strl + 1)))
                       ^~~~
                       strl
/home/znmeb/Projects/pshell/cc.c:4179:23: note: each undeclared identifier is reported only once for each function it appears in
/home/znmeb/Projects/pshell/cc.c:4226:17: error: a label can only be part of a statement and a declaration is not a statement
                 struct file_handle* h = sys_malloc(sizeof(struct file_handle));
                 ^~~~~~
/home/znmeb/Projects/pshell/cc.c:4239:17: error: a label can only be part of a statement and a declaration is not a statement
                 struct file_handle* last_h = (void*)&file_list;
                 ^~~~~~
/home/znmeb/Projects/pshell/cc.c:4284:17: error: a label can only be part of a statement and a declaration is not a statement
                 unsigned us = sp[0];
                 ^~~~~~~~
/home/znmeb/Projects/pshell/cc.c:4293:17: error: a label can only be part of a statement and a declaration is not a statement
                 unsigned ms = sp[0];
                 ^~~~~~~~
make[2]: *** [CMakeFiles/pshell_usb.dir/build.make:141: CMakeFiles/pshell_usb.dir/cc.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1666: CMakeFiles/pshell_usb.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

I captured logfiles of the whole build process; they're in the attached zipfile.
pshell.zip