Bootloader? You mean it wasn't already in the core memory when power was reapplied?
No, the Space Sciences department across the street had a prototype doppler weather radar that regularly corrupted the core memory.
What is important to say is the user only writesCode: [Select]RCC_CR.
RCC_PLLCFGR.
RCC_CFGR.
as the command in the terminal..
In order to write a celestial navigation app all you would need is a mechanical teletype worst case.. Would be better if you got a PC which can do copy/paste and work with .txt files, however
What do you have against paper tape? ..
In order to write a celestial navigation app all you would need is a mechanical teletype worst case.. Would be better if you got a PC which can do copy/paste and work with .txt files, however
What do you have against paper tape?
In case it is interesting to some of you, I've made my own small interpreted language that I use from time to time to have a flexible in system debugging and exploration.
It is a work in progress thing, for my personal use. But PRs are welcome if you find this interesting
https://github.com/AlexanderBrevig/yalex
https://github.com/AlexanderBrevig/yalexide <- the editor/playground for prototyping scripts for larger projects.
There's an example that works on the Arduino Uno (as a proof of concept for small 8bitters) but I tend to use it on larger projects on larger μCUs (ARM and PIC32 in my case).
Bootloader? You mean it wasn't already in the core memory when power was reapplied?
Bootloader? You mean it wasn't already in the core memory when power was reapplied?In the late 1970’s I purchased a heavily used and abused Data General NOVA system where the core memory had burned up (literally). The previous owner replaced it with (then new-fangled) dynamic RAM. No data retained during power off. I manually entered the NOVA bootloader thousands of times from the dreaded row of 16 toggle switches. Fortunately the entire bootloader was something like 28 words in length. And yes, its program input format was paper tape (8 level).
In case it is interesting to some of you, I've made my own small interpreted language that I use from time to time to have a flexible in system debugging and exploration.
It is a work in progress thing, for my personal use. But PRs are welcome if you find this interesting
https://github.com/AlexanderBrevig/yalex
https://github.com/AlexanderBrevig/yalexide <- the editor/playground for prototyping scripts for larger projects.
There's an example that works on the Arduino Uno (as a proof of concept for small 8bitters) but I tend to use it on larger projects on larger μCUs (ARM and PIC32 in my case).
At first sight, it kind of looks like a cross between Lisp and Forth.
There's nothing wrong with stack models--I was an early HP calculator user (HP35) and like RPN. In fact, I've only ever used HP calculators. An HP calculator only has a four level stack, which makes it rather easy to remember what's on the stack. With Forth programs more complex than trivial one liners you have more to keep track of, and this is compounded by operators that manipulate the stack in ways you can't do on an HP calculator (like 2over and 2rot).
There's nothing wrong with stack models--I was an early HP calculator user (HP35) and like RPN. In fact, I've only ever used HP calculators. An HP calculator only has a four level stack, which makes it rather easy to remember what's on the stack. With Forth programs more complex than trivial one liners you have more to keep track of, and this is compounded by operators that manipulate the stack in ways you can't do on an HP calculator (like 2over and 2rot).
The RPN models have a 4 level stack. The RPL models (HP 48/49/50, maybe others) have an infinite stack and all the stack manipulation words anybody could ever want.
I often need to do some quick prototyping and testing of sensors on some of my MCU platforms and I find myself writing the code in C and compiling it, downloading it, etc. I'd like something like a small scripting language I can interact with over a serial link to a board to send commands to a sensor, look at the output, etc.
...
Anyone know of a scripting language small enough to run on an ARM Cortex-M4 and not require too many resources?
There's nothing wrong with stack models--I was an early HP calculator user (HP35) and like RPN. In fact, I've only ever used HP calculators. An HP calculator only has a four level stack, which makes it rather easy to remember what's on the stack. With Forth programs more complex than trivial one liners you have more to keep track of, and this is compounded by operators that manipulate the stack in ways you can't do on an HP calculator (like 2over and 2rot).
The RPN models have a 4 level stack. The RPL models (HP 48/49/50, maybe others) have an infinite stack and all the stack manipulation words anybody could ever want.
@
@ R->A2 (second version)
@ Converts roman numerals to real value
@ Roman numeral input can be single or double-quoted
@ ( roman numeral string --> real value )
@
%%HP: T(3)A(R)F(.);
\<< "" + RCLF SWAP { }
SWAP 1 CF
WHILE DUP SIZE 0. > REPEAT
DUP HEAD
CASE
DUP "M" == THEN 1000. END
DUP "D" == THEN 500. END
DUP "C" == THEN 100. END
DUP "L" == THEN 50. END
DUP "X" == THEN 10. END
DUP "V" == THEN 5. END
DUP "I" == THEN 1. END
# 202h DOERR
END
SWAP DROP ROT SWAP +
IF 1 FS? THEN
DUP SIZE 1 - GETI ROT ROT GETI SWAP DROP ROT DUP2
IF > THEN
NEG SWAP DROP SWAP DUP SIZE 1 - ROT PUT
1 CF
ELSE
DROP2
END
ELSE
1 SF
END
SWAP TAIL
END
DROP DUP SIZE 1
IF == THEN
1 GET
ELSE
\GSLIST
END
SWAP STOF
\>>
I had a large hardware project (that you now all know about, but has yet to be officially released). Back in the prototype days, it existed on a bunch of largest-on-the-planet FPGAs all wired up with optic interconnect, and we had a Zynq as the boot-controller.
I wrote the firmware for all this, and chose Lua as the scripting language - basically wrote an OS around Lua rather than unix's /bin/sh. I implemented a virtual filesystem interface (flash for permanent storage, Ramdisk mounted as /tmp), so we could store data between runs, and it even ran a boot sequence (looked in /etc/rc.d for scripts prefixed by a number and ran them in numerical order). That handled bringup because all the things we needed to control were bound to objects in the Lua domain, so could be scripted. Lua provided the control structures that let you write useful scripts ("read the value of this register on that i2c device on the specified bus, is it X, then do Y else do Z").
Using the system interactively, there was a Lua shell interface that talked over thunderbolt (via a custom PCIe kernel extension) to a connected Mac, and since all the hardware was bound to objects in the Lua shell people using it didn't have to get me to redo some firmware when they wanted to fiddle with something, they just used the shell to either change things interactively, or rewrite the file in /etc/rc.d and reboot the device if it was a "boot up" stage thing they wanted to change.
I had some fun with this project, even implemented stdio redirection, so you could run a command on the device, and have the output appear on the Mac - or vice versa - which turned out to be really useful for long runs of data collection and interactive monitoring (drawing a graph on a monitor on the wall) over time.
Lua was pretty much perfect for this. Expressive enough to make it a useful language to have around, and completely trivial to bind hardware to objects so the hardware could be easily interacted with. 10/10 would (and did) use again.
yalex
this post should belong to the thread where I asked "with what?" can I replace Bash scripting
this post should belong to the thread where I asked "with what?" can I replace Bash scripting
I use SNOBOL4 for that, but I realize that may raise some eyebrows
this post should belong to the thread where I asked "with what?" can I replace Bash scripting