Sat Jul 19 14:07:20 CEST 2008
The idea is that code goes 'somewhere'. It is associated to a
resource. All code compiled inside a compiler namespace is registered
to a central code registry. Every time code gets TRANSFERRED somewhere
else, the corresponding code is marked as old. Transfer means to
either write out a hex file or similar, or to upload it directly to a
The simplest interface seems to be indeed the mapper: this can ensures
the operation completed before state is changed.
Onward: using map/mark-target-code, create a function that uploads the
binary code using code defined in tethered.ss
Ok, I remember: last what i did here was to use the comprehensions to
build a formatter for upload-bin. That code now needs to be tied to
getting the last binary code. Simple match? No: i got annoyed by the
absence of a Scheme interface to the interaction code in tethered, one
that automatically connects to the console. Let's write that first.
Maybe the simpler solution is to add a default somewhere?
I moved some of the tools/io.ss code to live/console.ss since it's
quite specific. Can probably merge together.
Added the 'with-console function to run arbitrary code in connection
with the console. This is still not good enough. Need a real
connection. But let's postpone this decision until after the highlevel
part of the code is done.
Verified that the programming worked using a read 'fbytes>list
The 'ihex function in pic18.ss uses 'auto-bin to produce binary
code. Maybe upload should work similarly?
( This level is really a bit of a mess.. Internally code is organized
well, but on the outer levels it's a patchwork.. probably because it's
a state machine written around code state, and there are several
format conversions going on.. )
The interactive state consists of:
* code compiled upto now, possibly marked as old
* core + project macros (the concatenative language)
* the current upload point for interactive dev
The last one is still missing: assembly doesn't save the memory
pointers. Let's place them in target/code.ss