spth / openrabbit Goto Github PK

Faster loading of programs would allow faster development cycles for users.

• The current waiting-based method to ensure dta has been written could be replaced by tcdrain / sp_drain use.
• A higher speed could be used to upload the user program (we now use pilot.bin from DC9, which allows faster speeds than the one from DC8).
• A minimmal (no debugging, just loading replacement for pilot.bin) could be used in rfu mode.

Currently, OpenRabbit does

1. Use cold-boot mode (slow - 2400 bps, load to RAM, lower 64 KB only) to load coldboot.bin (a binary blob from dynamic C that implements a medium-speed (57.6 bps or 19.2 bps) loader)
2. Use the medium-speed loader to load pilot.bin (a binary blob that implements a fast loader)

The main disadvantage of this process is the requirement for the two binary blobs (free MPL v2 source code is available, but they need the non-free Dynamic C compiler to compile) .

Exposing a cold-boot only functionality could allow to write a program onto the Rabbit without needing any binary blob.

Trying to build out-of-tree fails:

philipp@notebook6:/tmp/OpenRabbit/build$ LANG=C make
make  all-recursive
make[1]: Entering directory '/tmp/OpenRabbit/build'
Making all in src
make[2]: Entering directory '/tmp/OpenRabbit/build/src'
make[2]: *** No rule to make target 'openrabbitfu', needed by 'all-am'.  Stop.
make[2]: Leaving directory '/tmp/OpenRabbit/build/src'
make[1]: *** [Makefile:456: all-recursive] Error 1
make[1]: Leaving directory '/tmp/OpenRabbit/build'
make: *** [Makefile:367: all] Error 2
philipp@notebook6:/tmp/OpenRabbit/build$

Openrabbit now has its initial loader, coldload.bin.
However, the build process it not integrated with the rest of the build (requires manual invokation of make in coldboot directory).

This should be integrated:

• top-level make should trigger a make in coldboot
• configure should check for presence of needed sdasrab and sdcc
• make distcheck should include relevant files in distribution tarball

OpenRabbit should display the type of processor detected in human-reaaable format ("Rabbit 2000C", etc) instead of just a hexadecimal number.

OpenRabbit 0.2.0 requires pilot.bin from DC9 (included), but there still is a macro to allow the use of pilot.bin from DC8 instead.
Maybe this should be exposed as a configure option? Or maybe even a runtime option?

OpenRabbit currently depends on the coldboot.bin and pilot.bin binary blobs from Dynamic C.

While the source code for both is free (MPLv2), the non-free Dynamic C is required to compile them.

It would be good to have replacements that compile with free SDCC.

When using a serial programming cable attached via an PL2303 USB-to-serial adapter, OpenRabbit fails:

Error: Status line should be high after sending initial loader.

By reverting the tcdrain() approach in rabbit_triplet() back to the old usleep() one, we get a bit further, but then fail at the pilot checksum:

loaded 5517 bytes from ../coldboot/pilot.bin
sending 5517 pilot
csumR 0xfd69 != csumU 0xd469

When using the pilot.bin from DC9.62A (which is shipped with OpenRabbit), openrabbitrfu does not give any error messages, but apparently, the user program is not written or not written correctly. I found this by using simple pin-setting examples (pe7 to 1, pe1 to 0 or the other way round):
When using OpenRabbit with DC9.62A pilot.bin, the pins still have the same state as before.

However, the very same programs work fine when either written using the RFU from DC 9.62A on Windows 10 or OpenRabbit with the pilot.bin from DC 8.61 (requires setting dc8pilot to true in rabbit.c).

OpenRabbit should support the use of Intel hex (.ihx, .hex) files. It should try to detect if a supplied file is Intel hex vs. binary (maybe just checking the filename like other software does would be enough).

Intel hex is a common format. It is also the default output format of the Small Device C Compiler (SDCC), the main alternative to Dynamic C for Rabbit development.

When trying to use OpenRabbit a second time I usually see the following problem:

pilot.csum 0x4a != csum 0x00

pilot.csum of course depends on pilot.bin (the above is for the one from Dynamic C 8.61), but the error is always the same.

My setup is an RCM2200 supplied with 5 V from a lab power supply and connected to a USB programming cable from Diig. This hardware setup works on Windows 10 with the RFU from Dynamic C 9.62A, on the first and further tries. And using the coldload.bin and pilot.bin from Dynamic C 8.61 it works on the first try on Debian GNU/Linux. But not on subsequent ones.

So far the only workaround is to disconnect the RCM2200 from the power supply and programming cable and wait a few minutes. Waiting just one or two minute isn't enough.

With a build on my Mac, ran into this:

[tom@tbc-mbp src]$ ./openrabbitfu
Segmentation fault: 11

Without looking at the code, I'm guessing it's checking argv[] without looking at argc.

Help works:

[tom@tbc-mbp src]$ ./openrabbitfu -?
Usage: openrabbitfu [dc8pilot] <coldload.bin> <pilot.bin> <project.bin> <cable device>
Usage: openrabbit [dc8pilot] <coldload.bin> <pilot.bin> <project.bin> <project.brk> <drive> <mount> <cable device>

But I'm having some serial port troubles so I'm going to switch over to Windows and try building/testing there (using MSYS2).

The openrabbitfu script, which allows to use openrabbit as plain RFU (Rabbit Field utility) is missing from tarballs created by "make distcheck".

I've ported stdcbench to the RCM2200.
But I get an error from the stdcbench self-test. Unfortunately, I wasn't able to create a small reproducer yet. The error happens no matter is I #undef C90BASE (reducing the code size), or change compilation options to remove -opt-code-speed or --max-allocs-per-node.
But when I just put use c90lib-lnlc.c by itself with a thin main()-wrapper, I can no longer reproduce the issue.

See https://sourceforge.net/p/stdcbench/code/HEAD/tree/trunk/stdcbench/, compile using make -f examples/Makefile.SDCC-R2K

I'd suggest large root and stack segments, since SDCC by default just uses a linear 64Kb address space.

For normal code and constants (CODE, INITALIZER areas) we will want to use the root segment in flash.
For later banked code we would use the xpc segment (since it works with the lcall, lret, ljp instructions) in flash.
That leaves the data and stack segments. We'd use one for normal data (i.e. stack, DATA and INITALIZED areas), the other for named address spaces.

I think we want at least 32KB for the root segment (the stdcbench benchmark needs 25 KB in there).
We'd want at least 8 KB for the segment that holds DATA area and the stack (both the Dhrystone and Coremark benchmarks need about 5 to 6 KB in there).

For the other segment in ram, and the for the xpc segment, we'll want at least 4 KB each, so that reasonably-large objects fit.

That leaves 16 KB of the address space that we could assign whereever we think it will be most useful. And we need to decide if the stack and the DATA and INITALIZEDarea will go into the stack segment vs. the data segment.

I'm having to sort through lots of files in my git client, and it's hard to tell what needs to be added to the repository and what is just a configure/build artifact. It would be great to have configuration and building take place in separate directories. This would be for both building openrabbitfu and coldload.bin.

OpenRabbit currently has the --dc8pilot option for the use of a DC8-style secondary loader.

It could make sense to instead auto-detect the secondary loader style, so the user doesn't have to specify this explicitly.

Currently, for a program using serial port A, I have to:

• Unplug diagnostics port of cable, plug programming port
• Load program via RFU
• Switch off power
• Unplug programming port of cable, plug diagnostics port
• Start a terminal program
• switch on power

Could this be simplified? Could the RFU start the program at the end (maybe depending on commandline option), soI don't need to power-cycle? Could the RFU leave the cable in a state that allows serial I/O by a terminal program on the programming port, without requiring the use of the diagnostics port?

I got a Digi 2 mm USB programing cable (says "This programming cable requires Dynamic C v 9.62 or later" on it).
Since I don't have the prototyping board, I just connect the RCM2200 to a lab power supply to supply and the programming cable.

I use the coldboot.bin and pilot.bin from Dynamic C 9.62.
I invoke Openrabbit via:

./rfu /home/philipp/OpenRabbit/coldboot/coldload.bin
/home/philipp/OpenRabbit/coldboot/pilot.bin test test test test /dev/ttyUSB2

But both in my (here) and the unchanged code from the latest release (01.1.), it hangs when trying to read the pilot checksum. I verified this by enabling #ifdef DEBUG_COMM in myio.c:

sending 46477 pilot
writing 46477 bytes
reading 2 bytes

OpenRabbit never proceeds beyond that last line.

At this point, there are multiple potential underlying issues: A bug in OpenRabbit, and incompatibility with the cable, an incompability with the pilot.bin.

On the RCM2200, which has a Rabbit 2000@22 MHz, I see 2755 Dhrystones/s using the example code with current SDCC.

For comparison, current SDCC gets about 6000 Dhrystones/s on a C8051@96 MHz, and over 10000 Dhrystones/s on a STM8AF@24 MHz.

make distcheck can be used to generate useable tarballs, but:

1. It only works if normal make has been invoked first, otherwise it fails complaining that there is no rule to generate openrabbitfu.
2. It deosn't find coldboot.s.
3. It creates a directory openrabbit-0.1.2 (or whatever the release is) that cannot be removed even by rm -rf by the user. I always use su to get rid of it.

The current trunk compiles well on current GNU/Linux systems, which is an advantage over the 0.1.1 release.
It would make sense to make a 0.1.2 release from trunk after some testing.

Instead of having a single executable with different behavior depending on the name, either:

• Use a command-line option to choose the action.
• Have two separate executables that link in shared code.

We need a README in the examples directory with instructions on how to add a new target to targetconfigurations, and how to build binaries for a given target.

OpenRabbit currently uses Linux-isms. Since it requires direct access to DTR, etc it can't just use the portable POSIX functionality instead. Also, it would be nice to have Windows support.
Thus a serial port abstraction layer is needed. Options include:

• Roll our own, like https://github.com/free-pdk/easy-pdk-programmer-software does
• Use an existing library like the one from the sigrok project https://sigrok.org/wiki/Libserialport

I've tried with a CH340G USB-to-serial adapter and the serial programming cable.

However, this fails:

Reset Rabbit.
loaded 831 bytes from ../coldboot/coldload.bin
Sending initial loader.
Warning: Processor verification sequence failed!
sending 276 initial loader triplets
Error: Status line should be high after sending initial loader.

The error is the same no matter if the new tcdrain() or old usleep() approach is used in rabbit.c