On Mon, Jan 7, 2013 at 10:19 AM, Joerg Wunsch <j...@uriah.heep.sax.de> wrote:
> As Andreas Løhre wrote:
>
> > I tried the latest trunk with an ATmega2560 this weekend without success,
> > using the latest firmware from S6 patch 2.
>
> First, thanks for testing!
>
> > What devices and jtag firmware version are you doing your development on
> ?
>
> The JTAGICE3 firmware is 2.12 (decimal; Atmel Studio would call that
> "2.d"). My current target board uses an ATmega128RFA1 (since I just
> had that board around). My previous primary test board used an
> ATmega1284P but that one started to fail reprogramming some day, so
> it's now in kind of a read-only state.
>
I have a board with the 1284P, so I will try that today and see if I have
more success.
>
> I've also done some tests on a board using an ATxmega16D4, but have
> not re-tested that one lately.
>
> Operating systems tested include FreeBSD 8.x, Linux 2.6.38 (Ubuntu
> 11), Linux 2.6.18 (CetOS 5), plus some quick "does it work at all?"
> test on OS X and FreeBSD 6.x. The latter machine cannot operate the
> JTAGICE3 though as it's only got USB 1.1 hardware; my main reason for
> testing it was to see there are no regressions for older systems
> introduced by the USB thread handling. (FreeBSD < 8.x doesn't use the
> libusb20 code path but the libusb-0.1 code as all other systems do.)
>
I am doing the tests on a ubuntu 12.10 64-bit install.
> > I will post the complete debug output later tonight when I get home; It
> > seemed to alternate between failing with an buffer overflow error and usb
> > connection errors.
>
> The normal debugging output basically assumes the USB communication works.
> If it doesn't, it might be necessary to stuff some fprintf(stderr, ...)
> statements around into the various USB threads.
>
> I know the current implementation still has a race condition which I'm
> going to fix, but it should not trigger very quickly: each message
> from the USB reader threads (for the JTAGICE3, there are two of them)
> is preceded by a message length word so the consumer knows how many
> bytes to expect. However, if events arrive at a high rate (e.g. the
> device repeatedly going into/out of sleep), the information from both,
> the event and the normal reader thread could get mixed up. I'm going
> to fix that by using atomic write operations which write both, the
> message length and actual message data within a single write() call.
>
> --
> cheers, J"org .-.-. --... ...-- -.. . DL8DTL
>
> http://www.sax.de/~joerg/ NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> avarice-user mailing list
> avarice-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/avarice-user
>
--
Mvh. Andreas Løhre
Tlf: 936 50 366
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
avarice-user mailing list
avarice-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avarice-user
