Sun Mar 7 15:24:53 CET 2010
Let's forget about the dsPIC assembler until after using the
binutils/gcc toolchain to get something to work.
I'd like to re-focus on actually using Staapl to build things instead
of perpetually redesigning the core. The problem I got stuck on last
time was building a network of PIC devices.
Let's make this priority one.
Last time the problem was that I don't have an I2C network yet. This
is the ultimate goal. In order to get there, I need to build a hub
app. The hub app takes serial PC communication to anyting else.
The hub needs to run at 40 MHz to be able to get a decent data rate.
It's been a while. In the summer I got side-tracked by the dataflow
language ideas. This is where I got last time:
entry://20090711-151122 better to use a single code image (homogenous network)
entry://20090627-144638 serial daisy-chaining works
entry://20090625-131214 standard ``zwizwa connector''
The circuit that's on my desk is a 452@40 connected to a 2620@54
(using a 13.5 MHz XTAL).
Daisy chaining worked by connecting the TX of the 452 to the RX of the
2620. In Staapl this worked like this:
tom@zni:~/staapl/app$ make ttlmono-2620-54.dict
tom@zni:~/staapl/app$ mzscheme ttlmono-2620-54.dict
That didn't work
tom@zni:~/staapl/app$ make 452-40.live
That gave a programming error. After disconnecting the 2620 it did
program succesfully. Looping the RX/TX chain on the slave connector
Found 1 target(s).
If I recall this has something to do with the reset of the 2nd PIC.
Or the baud rate?
Hmm.. and then out of the blue it works.
Found 2 target(s).
Using `target!' it's possible to switch target.
This does get messed up easily. I have no idea how to reset it
properly. This seems to help:
pk2cmd -W1 -R -PPIC18F452
Good. Cleaned up the target addressing so it is a bit more robust:
- target-count now sends a nop token to 255 without checking
- target-receive+id/b checks to see if a message made a round-trip
without being answered
- target! performs target-count to make sure the id is valid before