Re: pilMCU on STM32F4-discovery

[Kuba Tyszko]

On Nov 26, 2014, at 4:10 PM, Alexander Burger  wrote:

> Hi Kuba,
> 
>> ..and I just got to the same exact point, compiled minipicolisp for 
>> stm32f4-discovery,
>> (same modifications, reduced allocation size, removed argc/argv etc).
> 
> Great :)
> 
> 
>> gdb session:
>> ...
>> GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
>> ...
>> First impression - it's very slow, resembles a 1200bps terminal ;) but that 
>> was fun.
> 
> Yes, I noticed that too. I also tried direct Telnet instead of GDB, but
> it is the same. I think it has to do with how stdio is handled over the
> USB link. The speed of PicoLisp itself is all right.
> 

It is a debugging link afterall, meant rather for register access not a 
"regular" console interface.

It's not very difficult to initialize proper STM32F4's UART and modify pil 
functions to direct its IO there - that should yield pretty decent console.

I might do that someday when I find time.


> ♪♫ Alex
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pilMCU on STM32F4-discovery

[Alexander Burger]

Hi Kuba,

> ..and I just got to the same exact point, compiled minipicolisp for 
> stm32f4-discovery,
> (same modifications, reduced allocation size, removed argc/argv etc).

Great :)


> gdb session:
> ...
> GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
> ...
> First impression - it's very slow, resembles a 1200bps terminal ;) but that 
> was fun.

Yes, I noticed that too. I also tried direct Telnet instead of GDB, but
it is the same. I think it has to do with how stdio is handled over the
USB link. The speed of PicoLisp itself is all right.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

pilMCU on STM32F4-discovery

[Kuba Tyszko]

..and I just got to the same exact point, compiled minipicolisp for 
stm32f4-discovery,
(same modifications, reduced allocation size, removed argc/argv etc).

semihosting output redirection:


Open On-Chip Debugger 0.8.0 (2014-11-25-23:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.907884
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 
Info : device id = 0x10016413
Info : flash size = 1024kbytes
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010788 msp: 0x2002, semihosting
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010788 msp: 0x2002, semihosting
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x6100 pc: 0x2042 msp: 0x2002, semihosting
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet 
not sent! (2433). Workaround: increase "set remotetimeout" in GDB
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010754 msp: 0x2002, semihosting
Minipicolisp says Hello!
: "hello"
-> "hello"
: (+ 4 5 6 7)
-> 22
:  




gdb session:


GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 
--target=arm-none-eabi".
For bug reporting instructions, please see:
...
0x080100be in ?? ()
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x0100 pc: 0x08010788 msp: 0x2002, semihosting
Reading symbols from /Volumes/MAIN/DEVEL/miniPicoLisp_/bin/picolisp...done.
(gdb) load
Loading section .isr_vector, size 0x188 lma 0x800
Loading section .text, size 0x1b5e0 lma 0x8000188
Loading section .ARM, size 0x8 lma 0x801b768
Loading section .init_array, size 0x8 lma 0x801b770
Loading section .fini_array, size 0x4 lma 0x801b778
Loading section .data, size 0x1540 lma 0x801b77c
Loading section .jcr, size 0x4 lma 0x801ccbc
Start address 0x8010754, load size 117952
Transfer rate: 23 KB/sec, 7863 bytes/write.
(gdb) c
Continuing.


First impression - it's very slow, resembles a 1200bps terminal ;) but that was 
fun.



Cheers

On Nov 25, 2014, at 11:07 PM, Alexander Burger  wrote:

> Hi Kuba,
> 
> in addition to what Jakob said:
> 
>> Think for example of micropython or armpit-scheme - those are able to
>> run on many microtrollers, I personally run them on a STM32F4 that's
>> quite powerful (1MB flash, 200KB RAM) - pretty good for a
>> mictrocontroller
> 
> I compiled miniPicoLisp here on an STM32F4-Discovery. Works almost
> without changes, basically I removed only the command line parsing
> stuff, and decreased the allocation size from 1 MB to 32 kB.
> 
> As miniPicoLisp now can compile Lisp expressions to C code (see also
> http://picolisp.com/wiki/?miniCodeROM), you can incrementally test Lisp
> functions in the 196 kB of RAM and then move them to ROM.
> 
> ♪♫ Alex
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe