{"shas":[["e6e44637b0cbae4ed70bdf86a50b73b13ef9658f","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Huge rework of \"universal chat\" primitives\n\nStructuring the code - both on the host and target - for flashing S08\nparts has been a challenge. I've tried it several ways, and none felt right.\n\nWhen thinking about how to do it in the context of USB, a light bulb went on.\nThe issue before had always been, \"where do I store the bytes that I want to\nflash?\" Well, USB solves that: they are sitting in the OUT buffer, waiting to\nbe copied somewhere. My insight was that instead of just copying each byte, I\ncould burn it to flash. I've already got a loop running; instead of simply\n\n  0 ,x sta\n\ncall a routine that does\n\n  0 ,x sta\n\nfollowed by the magic incantation to write the flash. Since the only code that\nneeds to be in RAM is the above routine, I can easily switch between copying\nand flashing, and the code overhead is nil. It's also blazing fast.\n\nSo I took that insight (flash while doing something else) and tried to apply\nit to the chat and BDM code, and in the process I realised that my\nabstractions were wrong. My exported abstraction was about streaming bytes in\nor out of the target, but that doesn't fit well with USB.\n\nMy new abstractions are about moving chunks back and forth (read, write,\nflash), which in the case of the serial chat code can be easily expressed with\nthe streaming protocol that the target gives me. And by making one tiny\nchange, writing to flash with the serial chat is as easy as saying\n\"c.FlashNext\". And it runs at wire speed! (It takes 45us to flash a byte, and\n83.3us to send a character at 115200 bps.)\n\nUnfortunately, flashing via BDM got slower (again ;-) because we no longer\nloop in the executed code, so there is a lot of overhead wrangling the memory\nand registers over BDM. In fact, it's no slower to run the entire show over\nBDM - executing no code on the target.\n\nThe speed of flashing via BDM, while frustrating, is only a tiny concern,\nthough: the issue is with serial port latency, not something inherent to BDM.\nOver USB it will be much faster. And in any case, I'm just using BDM to\nbreathe first life into the parts: I burn a boot/chatloader (serial or USB)\nand leave BDM behind unless I brick the part and need to recover it. So I can\ntolerate a couple of seconds to write a bootloader every once in a while...","David Frech"],["e8f929548715c53d45e6f2bf93693c934cb7af4f","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","USB targets are now \"first class\" chat targets!\n\nWhat this means:\n * register display works\n * memory dump works\n * calling out to code (from interactive prompt) works\n\nThe main piece that was missing (before this commit, that is) was proper\ndisplay of registers, and a good way to set them, then run some code,\nthen re-capture their values, and then display them. This has been\nstandard issue on serial and bdm chat targets... but I didn't see a good\nway to do it over USB.\n\nThe solution was to add a vendor request to read the SP register, and\nalso to \"wrap\" the loop that calls process-usb with a loop that calls\nemulated-swi (which, like its namesake, pushes the PC and all the\nregisters onto the stack). In this way the interactive session can show\nand change the captured registers, and when it comes time to execute\ncode, by putting a new value into the PC slot (and any other useful\nvalues, like a data stack pointer into HX, if calling into Forth);\nthese changes are made using the read-memory and write-memory vender\nrequests. To execute, the \"run\" request simply executes an rti\ninstruction, which pops all the registers, and starts execution.\n\nBy cleverly leaving a return address on the stack, _above_ the SWI/RTI\nregister frame, we make it easy for the executed code to \"return home\":\nit simply executes rts, and it re-enters the emulated-swi loop, which\nthen calls process-usb in a loop, and we're back in (interactive)\nbusiness.\n\nI was lucky that it all fit. All this added about 20 bytes of code,\nbringing me dangerously close to the limit... I think I have about six\nbytes to spare, not counting the eight or so that I could reclaim by\nreplacing a few uses of compare immed then beq with a single instruction\n(but I haven't figured out how to add it to assembler yet...)\n\nSo, there you have it! USB has officially arrived!","David Frech"],["1acd1f0a279c3daa5317a93422a710ec1c28414e","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Apparently __meta really needs to search .labels.\n\nMakes we wonder if .labels. isn't a dumb idea after all...\n\nI was doing my with this version of __meta.. but didn't check it in. Without\nit, you can't load the USB code into ram.","David Frech"],["464286e157ffbe5bcba76a56d0a680014f3f333f","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Prettification - mostly whitespace changes\n\nA few comments moved around.","David Frech"],["a62c6d355019c347df1a9287a15ad7e30f285c69","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Saved a few more bytes in the USB code\n\nBy compressing the code even further - moving code to set IN's to NAK into a\nroutine and calling it instead - I squeezed out a few more bytes.\n\nDon't Repeat Yourself!\n\nCoding in the Forth style is generally really good at extracting all the\nredundancy from a program. In this case I was a bit lazy, and didn't see the\npossibilities for sharing.","David Frech"],["9c70fc1f771ded3f992c1753eb2cb14d0be19a09","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Rewrote chat byteloader in \"forth style\" - like USB byteloader\n\nThis is an experiment. The code works, but it's not the \"default\" and I\nhaven't flashed any parts with it.\n\nThe main difference between this code (chat v3) and the existing code\n(v2) - there was a v1 but only the host-side code still exists - is that\nit is written as a subroutine that gets called repeatedly, rather than\nas a loop that once entered is only exited via rti.\n\nBoth approaches have their merits. The big loop means that nothing\nprevents us from moving the stack pointer and pushing arbitrary stuff on\nit: what's sitting on the stack is an SWI/RTI frame _not_ a return\naddress. So the host can change the SP, fill up the new frame with\nregister values, and cause an RTI, and it work fine. In fact, this is\nprecisely how I used to flash the code. I had to move the SP (by command\nfrom the host) because I was pushing the bytes that I wanted to program\nonto the stack.\n\nThis approach, using a subroutine, is both more and less flexible. Less,\nbecause changing the SP is hard - you have to copy the return address\nsomewhere, fiddle with SP, then push it back. And since the chat code\nassumes that HX is precious, it starts to get pretty involved.\n\nOTOH, a nice tail-recursive styles becomes possible, and to return to\nthe dispatch point, any code just needs to execute rts, or jmp to code\nthat returns.\n\nIt also becomes possible to do something I have been thinking about for\na while - having the byteloader code dispatch _more_ than just the\ncommands it knows about (BDM over serial, eg). Right now the way I\n\"multiplex\" BDM and chat commands is pretty ugly. Having the flexibility\nto call several routines to figure out what to do with a received\ncommand byte is useful.\n\nThat said, none of this \"mainline\" code right now. I've set it aside for\na rainy day project... ;-)","David Frech"],["d4c3c08757fbd8e806dbbefd314487885f25f7de","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","No longer two versions of b.GetRegs and b.SetRegs\n\nOops. Somehow both ended up in the file.","David Frech"],["f67eb9349d671da7ffeb8c20335be4f118067aae","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Added support for S08JS USB ROM bootloader\n\nIt's now possible to flash bare devices (as long as they are JS8 or\nJS16) via USB, without recourse to serial chat or BDM or any other\nnonsense that only I have access to. ;-)\n\nAll you have to do, to (for example) load my USB chat firmware into a\nbare device (assuming it's wired up with a crystal and USB connector and\nthe minimal hardware required!) is the following:\n\n * jumper device for bootloader (pull pin 7 (BLMS) low)\n * run the following command to start muforth:\n\n  ./muforth -f target/HC08/load-S08usb-chat.mu4\n\nIt will autoprobe for the JS device and load the bootloader if found.\nYou probably want to be in hex to see the status messages more usefully,\nso do\n\n  hex\n\nand then type\n\n  flash-image\n\nand it should write the image and reset the device. Rejumper it (and\nprobably disconnect/connect, without this YMMV) and reload the same\nmuforth file, and it should now say something about USB chat loaded, so\ntype\n\n  chat\n\nand you should see a dump of the registers.\n\n  0 du\n\nwill get you into the memory dumper; further <Return> or <BS> to go up\nor down. q to quit.\n\nYou're talking to the device!","David Frech"],["54e0b051ea3f8d9623049e3ca445535ab520a86d","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","File loading can now durably set radix and mode\n\nAnd the HC08 build tools default to hex and __meta.\n\nI realised that my saving and restoring of several settings - radix and\ninterpret mode among - was super _useful_, but not universally applicable. Now\nit's possible to choose between raw-load-file (which saves very little) and\nload-file (which continues to save just about everything).\n\nBy defaulting -f (the command-line flag to load a file) to call _raw_ load,\nand by having all the HC08 project load files call build.mu4 with the\n_non-raw_ load, it's possible to have build.mu4 set up things in a durable way\nso that we always end up in hex and __meta, which is mostly what you want.\n\nYou can also do this on the command line, after the -f <file> but it's tedious\nand I always forget to do it. This is much more fool/drool-proof.","David Frech"],["b71b0f838bd8e024db4fdeed98730209cd155ced","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Another rework of HC08 project load files\n\nThings are even simpler - again.\n\nI kept the names of the 908-specific load files, but changed all the S08 ones\nto \"bare\" names with no mention of \"S08\".\n\nThe build.mu4 file is much smarter about loading support for flash and usb now\ntoo. To create a new project you now just create a file with\n\n  ld! target/HC08/build.mu4  ( ld! let's build set a nice radix and mode)\n  ld target/HC08/myproject.mu4\n\nand load it!","David Frech"],["86b9a757cad10c4b6850b5e388219df143787393","aa743a0aaec8f7d7a1f01442503957f4d7a2d634@nimblemachines.com","Nicer USB device recognition\n\nNow if a USB device is found that is known to be an \"interactive target\"\n(ie, running my chat firmware) it is queried for its S08 device id\n(which is built-in and can be read from the register at 1806/7 hex) and\nthe proper device support gets loaded.\n\nI'm currently using one USB product id for all interactive targets:\n15a2:c0de (I've temporarily \"borrowed\" Freescale's vendor id for testing\n;-). I could assign a different product id to each chip.\n\nThat could help ameliorate a minor annoyance: the Freescale S08 device\nids are _shared_ among related members of a sub-family (like JS8 and\nJS16, or JM8 and JM16), so it's impossible to know how much memory the\ntarget has.\n\nThe important thing is that the right device \"equates\" - for the\nlocations of registers etc - are loaded, and they are.","David Frech"]],"repo":"nimblemachines/muforth","actor":"nimblemachines","ref":"refs/heads/target-hc08","size":11,"head":"86b9a757cad10c4b6850b5e388219df143787393","actor_gravatar":"a89670ce6ee60c597ac3a8218f3cac02","push_id":31345903}