Re: pilMCU progress (slowed)
Hi Geo, First of all, great progress with the pilMCU so far, I hope the EEPROM continues to work and you can move on to the next step. A small suggestion - please put big image files on some site (imgur etc) and attach - it would be easier, downloading large email file takes time (I don't use webmails like gmail). Further, I have a couple questions on the implementation, you said you had an emulator running picolisp already - is this actually the whole picolisp converted somehow to a dedicated CPU running on FPGA, or is that an actual CPU emulated (say some kind of ARM), and picolisp compiled for that CPU ? I'm just trying to have a sense of what the pilMCU will become - will it be running on some kind of microcontroller, or will it actually run on a FPGA with a dedicated CPU, or maybe will it be some kind of ARM or MIPS core running on FPGA running the picolisp ? If the picolisp were to run on a real FPGA, there has to be a CPU somewhere..., I just wonder whether you're trying (or already have) to develop a CPU that runs picolisp itself, or will that be some kind of generic CPU. This could determine how popular picolisp could become - if it's able to run on generic (not only FPGA) hardware. 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 Cheers On Oct 17, 2014, at 8:33 PM, gpor...@yahoo.com wrote: Hi List, Just want to inform that progress will be a bit slow coz I’m going home tomorrow and be able to get back on this after 10 days, but im bringing my laptop with me and see how it goes there I’m still stuck with EEPROM coz it’s using I2C bus in which is serial, on my simulated version we use a parallel one so it was easy to handle. But no worries I already almost near to make it work, I just need to take a close look on how my I2C master perform esp the signals. Will keep you posted, bis bald! BR, Geo Sent from Windows Mail
Re: pilMCU progress (slowed)
On November 25, 2014 at 11:19 AM Kuba Tyszko k...@lbl.pl wrote: is this actually the whole picolisp converted somehow to a dedicated CPU running on FPGA, or is that an actual CPU emulated (say some kind of ARM), and picolisp compiled for that CPU ? It is a new CPU. I'm just trying to have a sense of what the pilMCU will become - will it be running on some kind of microcontroller, or will it actually run on a FPGA with a dedicated CPU, or maybe will it be some kind of ARM or MIPS core running on FPGA running the picolisp ? pilMCU is a new CPU. However, regular PicoLisp, can, and has been, ported to various microcontrollers. Any 32 or 64 bit microcontroller can have PicoLisp ported to it. best regards, Jakob -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilMCU progress (slowed)
Hi Kuba! I see that Jakob and Alex already covered most of your inquiry, but i'll just answer you too ;) First of all, great progress with the pilMCU so far, I hope the EEPROM continues to work and you can move on to the next step. Thanks!! and yes, i utilized one push button so that every time i press it it will increment the PC counter then it will fetch from EEPROM the stored bytecode :) now i'm a bit busy with work coz of the coming CES :( but don't worry, the I2C hurdle was done so EEPROM write should be already done, just need to properly align the state machine inside ;) A small suggestion - please put big image files on some site (imgur etc) and attach - it would be easier, downloading large email file takes time (I don't use webmails like gmail). Oh! sorry about that and actually Jakob already called out on this, sorry everyone i this will not happen again, either i change to smaller resolution or use an external link as Kuba suggested Further, I have a couple questions on the implementation, you said you had an emulator running picolisp already - yes, we still got it ;) is this actually the whole picolisp converted somehow to a dedicated CPU running on FPGA, or is that an actual CPU emulated (say some kind of ARM), and picolisp compiled for that CPU ? as Jkob said, its a new 64bit CPU :) I'm just trying to have a sense of what the pilMCU will become - will it be running on some kind of microcontroller, or will it actually run on a FPGA with a dedicated CPU, or maybe will it be some kind of ARM or MIPS core running on FPGA running the picolisp ? As of the moment, its the will it actually run on a FPGA with a dedicated CPU. This is just considered as prototype stage? And once we got this running and able to get the funding we need? we will proceed of doing it to ASIC? or even better but expensive, fabricate it to an actual standalone microchip? this would be the ultimate goal, but does ASIC version has the same purpose correct? but yes, the goal is to have a pilMCU chip on its own development board in which would look like RPi, or TI BB or other microcontroller kits these days that are capable of running Linux? once we got this running Alex already started implementing an OS which is now stored on an SD card :) 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 ah yes i think i read it somewhere? but hmm the difference is this still is not considered as bare metal running of python or scheme, they still rely on a small vm inside the microcontroller correct? or do you mean python and scheme is used as programming syntax but then it is compiled to a STMicro binary? As mentioned by Alex, there is the miniPicolisp, im not sure on which MCU it was run, something like Arduino maybe? Give it a try if you have time ;) BR,geo On Tuesday, November 25, 2014 10:14 PM, Alexander Burger a...@software-lab.de 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
subscribe
Hello Pierpaolo Bernardi olopie...@gmail.com :-) You are now subscribed picolisp@software-lab.de -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
String syntax, or Transient Symbol syntax
Hello. I am having some trouble working with Strings or Transient Symbols. (I'll call them strings for now.) Consider this string: ^(a+)\) In picoLisp, I must enter that as: \^(a+)\\) See, the escaping syntax is a pretty heavy burden for the types of strings I work with... So, I considered using a reader macro. I imagined something like: (re-handler /^(a+)(.*)'.*(\)+)/ nd here's some input! :) -- (re-handler \^(a+)(.*)'.*(\\)+) nd here's some input! :) See, the / is being used as a delimiter, instead of . Javascript does this. /foo/ is a kind of literal like foo is a literal. ..Then I discovered that we don't have a defmacro. (I've read previous discussion about macros and I accept Alex's stance.) Any advice for implementing some sort of special case for /strings/, which would be just like strings but with different escape mechanics? I see src64/io.l contains (code 'readA_E) which handles reading strings. But I don't understand this assembly code. I hope my question is clear. Thanks, cheers, --Dave -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
pilMCU on STM32F4-discovery
..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 http://gnu.org/licenses/gpl.html 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: http://www.gnu.org/software/gdb/bugs/... 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 a...@software-lab.de 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
Re: String syntax, or Transient Symbol syntax
Hi Dave, I am having some trouble working with Strings or Transient Symbols. (I'll call them strings for now.) ... ^(a+)\) In picoLisp, I must enter that as: \^(a+)\\) That's right. This is the syntax of the PicoLisp reader. See, the escaping syntax is a pretty heavy burden for the types of strings I work with... So, I considered using a reader macro. I imagined something like: (re-handler /^(a+)(.*)'.*(\)+)/ nd here's some input! :) -- (re-handler \^(a+)(.*)'.*(\\)+) nd here's some input! :) A read macro won't help, because it is still based on 'read', the PicoLisp reader synax. A read macro reads an expression, evaluates it, and returns the result to the reader. ..Then I discovered that we don't have a defmacro. (I've read previous discussion about macros and I accept Alex's stance.) A macro won't help either, because it also processes the data *after* they are read by the Lisp reader. And though you can do everything a macro would do in PicoLisp with a normal function, it also operates on s-expressions and not on the input stream. Any advice for implementing some sort of special case for /strings/, which would be just like strings but with different escape mechanics? On the *application* level, you can do everything you like, using low-level I/O functions like 'char' and 'line'. I think the problem is that you want to change the *language* level, and the reader is the core of the language (read/eval/print). I see src64/io.l contains (code 'readA_E) which handles reading strings. But I don't understand this assembly code. Yes, that's the right place to change the language :) The normal REPL (i.e. the 'load' function) doesn't operate on raw input data. What you could do is write you own top-level REPL, using e.g. 'line' and 'eval' directly. Another possibility is using 'pipe' and perhaps external tools to process the input stream. In any case you need to get hold of the data and process them *before* they are seen by the reader. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
