Thanks for all the comments, I think they have put me on the right track.. Have ordered a couple each of PIC24FJ64GA002, and low voltage PIC12LF1840 in DIP format for experimenting :)
Coming from an AVR hobbyist background, I thought I'd have a tinker with some PIC projects. I've been playing around with MPLABX under Linux, which is all good from the software side, but I'm a little bewildered by the choice of chips ;)
From an AVR perspective, I've mostly used the 28 pin ATMEGA48/88/168 series, and some 8 pin ATTINY 25/45/85 for simple things. Am really just looking for ideas on similar PIC ranges, and trying not to pick something that's dated for new designs.
A couple of hours with google has me leaning towards something in the PIC24F and 12F families? But that's the extent of my knowledge so very open to suggestions..
Hi Jawi, have done some testing with RC1 on 32bit Fedora 14
Platform tests;
Not a new issue (or a problem with the client), but the test charter did remind me that Fedora 14 broke non-root RXTX lock file usage some time ago - see http://https://bugzilla.redhat.com/show_bug.cgi?id=581884 for background. The Fedora RXTX package has been patched to create lock files in another directory, but for bundled RXTX I need to change permissions on the /var/lock subdirectory.
Acquisition tests;
Can confirm issue 50 is solved. I do see that if a long capture is stopped before completion, then the data is not decoded. Will raise a new issue for this on GitHub. [edit: I see issue 56 has already been raised for this]
Tooling tests;
UART analyser settings (channel selection) are not retained when the dialog is closed. If this is unexpected I'll raise an issue for it?
Thanks Jack, can confirm the latest code built for me with no issues. Was my first venture into MinGW compilation for Windows and it all just worked. I've attached the binaries in the "OLS files and utilities - Windows, Linux, Mac" thread..
While further client / core incompatiblity would be pain, I think it's fair to say that it's already a bit of an issue for RLE support now.
If there were a new scheme that (a) increased sample depth, and (b) improved future compatibility - it would certainly get my vote, even if there was a one-time breakage from changing schemes now..
@Ian, is there any reason why Robots updater hasn't made it into the "OLS files and utilities - Windows, Linux, Mac" thread? I vaguely recall someone saying it needed more work, but it works perfectly here for both PIC and FPGA updates..
Attaching a small patch for the other issue I'd been seeing recently. During my RLE testing all inputs were tied to ground, which was falsely triggering your check for RLE counts without preceding sample values.