I used a milling machine to cut a cavity to fit the board, cleaned it up with wood chisels and a sander, stained and sealed, then mounted the board with nylon machine screws and standoffs in tapped holes.
Hmmm. Sounds like challenge. Is this mostly just writing data to the UART or is there some back and forth going on? What's the baud rate? I'm guessing the buffers fill up and it overflows and does not recover properly. I'll have to play around with it a bit and see if I can make it happen. The Normal button not working and and echoing characters is probably a pretty good hint as to where it is in the code, so I'll have to spend a little time with it this weekend. Have you tried holding the normal button down for a while? Sometimes it takes a long press for it to catch it at the right place in the polling.
I version i committed was 1892 (for some reason I'm now thinking of Christopher Columbus).
I had no trouble with the build, but as mentioned above I did have some problems making it work on the actual hardware. These were related to the USB product ID change. Just tweak the inf file to substitute FA97 for FB00 and use it when Windows asks for drivers and all will be well. I think Linux will just work (although you may have to tweak your udev rules if you use them), but I have not tried this build on Linux yet.
I ran the build using MPLAB v8.84 (Windows) using workspace file firmware/bp4.mcs from the repository. I had to respond to a few prompts about changed file locations, but other than that no issues. When exporting the hex file for the bootloader, I used 0 to 0x2abf6 for the program memory range.
If you send a snippet of the build errors your getting, I might be able to point you in the right direction.
Just committed the code to fix the UART transparent mode and add Normal button to cancel transparent into the v4 source. I tested my changes with the latest SVN code, including the new USB stack and noticed a few minor issues. With the new code, the BP reported as a "Logic Shrimp" (needs to be fixed in the descriptor) and the standard inf file did not work for configuration. I tracked this to the USB_PID which seems to have changed to FA97 from FB00. If worked around this with a patched inf file and it tested okay (at least for the UART parts that I tested)
Assuming the USB_PID change is intentional, and the "Logic Shrimp" descriptor is not, shall I also commit changes to the BpV4 inf file and the USB descriptor? I'm not terribly knowledgeable about the inf file format - is it better to modify the existing entry, or add another line for FA97 with a different description (like v6.2)? I'm also a bit confused as to why the inf file appears several different places in the code repository.
I'll leave my BP loaded with the current SVN version and report (and perhaps fix) anything else that pops up.
Mercurial is another option for distributed source control, and its rumoured to have better Windows support. I can't speak to that first hand, I've only used Mercurial in Linux.
[quote author="tucsonclimber"] Bottom line, I'd like to get svn commit access because I'm pretty sure this won't be the last time I tweak this sweet piece of hardware. Let me know if you'd like to see a diff first. I've used C plenty and I've coded on PIC's plenty, but this was my first time with C on a PIC (I usually hand code in assembly)[/quote]
Bump. So - how do I get commit access to contribute my fixes?
This line check if any received in txbuf AND if tx buffer ready THEN copy U1TXREG = U2RXREG; If tx buffer not free wait in external loop. But not working.(only for me???)
This line check if anything in rxbuf THEN check OR wait on INSIDE LOOP for tx ready then copy the char to U1TXREG.
Again the question, where is the problem in first implementation? Because my implementation add wait on rx when usbtx full, if anything coming from usb will not handled as well. So it's not preferable but working for me.[/quote]
There is little wrong with what you have done. It is correct for the BPv4 but not for the BPv3. The only thing that needs to be added is conditional compile directives for the different BP versions. The usb stack will pretty much always be ready to receive a byte so you do not need to test for it as the usb stack does not return to user code until there is at least one buffer available. It provides handshake by blocking if (like, never) both buffers are full.[/quote]
I recently bought a BP v4 figuring it is the future and I've got the skills to contribute. Sure enough I ran right into this problem the first time I used it. I have integrated TES's change above into the current SVN code with the appropriate compile directives and also modified the Transparent UART mode to end with a press of the Normal button on the v4 hardware, which makes it much more usable. I had an interesting time figuring out how to do the translations properly (so v4 hardware says use Normal to exit), and plan on doing at least a readme.txt file in the translations directory to explain what needs to be done (mostly use the javascript translator not the exe, and some tweaking related to embedded semicolons)
Bottom line, I'd like to get svn commit access because I'm pretty sure this won't be the last time I tweak this sweet piece of hardware. Let me know if you'd like to see a diff first. I've used C plenty and I've coded on PIC's plenty, but this was my first time with C on a PIC (I usually hand code in assembly)
