Re: [avrdude-dev] avrdude on Solaris 10 x86?

[Joerg Wunsch]

As ad5gb wrote:

> I just moved from FreeBSD 5x to Solaris 10 and I'm wondering if
> anyone has successfully built and used avrdude on Solaris 10?

I just committed a bunch of changes that make avrdude compile and run
successfully on my Solaris 10/SPARC setup.

Changes:

. Parallel port access is now optional; for systems where no method to
  access the parport is known, it will be disabled.

. In order to achieve the above, I generalized the hooks for the
  bitbang interface.  Everything is now passed on through the
  PROGRAMMER * object handle.  In theory, it should be much simpler
  now to add yet another bitbang programmer type (like an FTDI-base
  USB-controlled bitbang hardware).

. While being here, I also moved the getexitspecs function to the
  (parport) programmer.  That way, more than PPI programmers could now
  parse the exit specs if they can make any sense out of it.

. avrdude.conf is now built a bit differently than before.  All
  parallel-port programmer definitions have been moved into a single
  block, and that block is bracketed by @HAVE_PARPORT_BEGIN@ and
  @HAVE_PARPORT_END@; a sed script will be run to produce the final
  avrdude.conf out of this (depending on whether parport access is
  available).

. Flex on that Solaris 10 failed to compile the lexer.l.  An internal
  function has been using a formal parameter named "str", yet <str>
  was also a start condition, which flex converted into a "#define str
  1" statement.  That garbled the formal parameter, so I changed the
  start condition to strng.

. The non-standard BSDism rindex() has been replace by the C-standard
  strrchr().

Known issues:

. Either bison or byacc are required to compile the code successfully.
  Solaris' yacc causes strange compilation errors.  I didn't find a
  goog autoconf test for that (in particular given that byacc might be
  just named "yacc" on a target machine).

. Serial bit-bang access under Solaris is abysmally slow, at least on
  that Siemens SCC (se(7D)) controllers I've got for /dev/term/b here.
  Every once in a while, an ioctl(TIOCMGET) waits for several seconds
  until it eventually returns.  The result itself will be OK,
  communication with the bit-bang programmer really works, but it's
  simply unusable that way.  The hardware itself is OK, as the very
  same setup works pretty well under FreeBSD/sparc64 on the same
  machine.

. ecpp(7D) parport access for Solaris needs to be written.  No idea
  what kind of driver would be present under Solaris/x86.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)