You are evidently working on Windows. On my Mageia Linux system,
libhidapi is included and comes as part of the standard software. But
the current version of Mageia still comes with avrdude 6.3, so I did not
try 6.4
Juergen
On 07/30/2014 10:02 PM, Andreas Graebe wrote:
The order of the separate displayed fusebytes is right, but in the
resume, H: and E: are changed.
Here is what I get - which looks OK
harms@ltjuergen ~ avrdude -v -p AT90CAN128 -c jtag3 -P usb
... snip
Programmer Type : JTAGICE3
Filed bug #42517 with the patch file as an attachment
Juergen
___
AVR-chat mailing list
AVR-chat@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-chat
The attachment is a patch file that adapts the configure script file
of the avrdude-6.1 tarball to correctly detect the availablity of all
required header files (according to what I described in my last email -
06/04/2014 10:03 AM - sorry for the zig-zag in arriving there).
I have used this
Thanks for pointing me to ac_cfg.h!
ac_cfg.h contains
#define HAVE_USB_H 1
I tried - in the un-tared directory - to see where HAVE_STDINT_H is
defined and used: it is only used, nowhere defined.
grep -r HAVE_STDINT_H *
ac_cfg.h.in:#undef HAVE_STDINT_H
configure:#ifdef HAVE_STDINT_H
On 06/02/2014 11:50 PM, Joerg Wunsch wrote:
Make sure you've got the header files for all your libraries
available
That is one advantage of needing to create rpm packages: the spec file
contains a list of requirements, which allows for automatic checking (of
what it is told to check) and
On 06/03/2014 11:17 AM, Martin Stejskal wrote:
... Then type gcc -Wall test.c
Done, no problem (and, as I said, I have already had a close look at
config.log - I do not have sufficient knowledge for going beyond guesses
on the conclusions to draw). Summing up:
We all agree: there is a
After a firmware upgrade of my JTAGICE3 (1.25 - 3.23) my JTAGIC3 had
become totally unusable: avrdude 6.0.1 failed top open the USB port (...
did not find any device usb). Some googling showed that this is a
known problem, and which has been fixed on avrdude-6.1.
But, building 6.1 on my
Thank you, this reply is helpful - I can stop looking for the magic
configuration option that I might have missed, and there is hope that
one day a fix will turn up.
I am afraid that I dont have the knowledge to efficiently help checking
what Atmel Studio does - but if I can be of help doing
I intend to incorporate a patch into the avrdude rpm on Mageia that
fixes the use of avrdude with usb for non-root users. I have found
plenty of discussions on this issue, the fix is essentially based on
http://www.mikrocontroller.net/articles/AVRDUDE
I append a copy of set of udev rules
Sorry, my mail went away before I had double-checked: the product ID
2103 vs. 2104 question is clarified: JTAG vs. ISP
___
AVR-chat mailing list
AVR-chat@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-chat
On 08/06/2013 09:27 AM, Joerg Wunsch wrote:
you could create your own
lightweight tool to talk to AVaRICE instead of the rather universal
(and heavy) GDB, just tailored to monitor/change a few SRAM bytes.
I had already considered going this way - with low priority. Since what
I have to do is
On 08/05/2013 10:49 AM, Joerg Wunsch wrote:
Is your SRAM accessed through the standard XRAM interface (i.e.
mapped into the regular address space)? If so, would AVaRICE +
GDB be a solution for you?
Yes, it is, I do access to external SRAM in the same address space as
internal SRAM (the
I have recently augmented an application by adding external NV RAM
(AT90CAN128, DS1244), using the NV RAM for data I - so far - kept in EEPROM.
For debugging/maintenance purposes it would be nice to have an easy way
to - very occasionally - manually inspect/modify some few bytes of NV
RAM
Same problem in the Mageia distribution - the cross-compiler broke after
an upgrade of gcc - avr-binutils had to be upgraded correspondingly
before re-building the cross-compiler.
With the combination of binutils 2.23 and gcc 4.72 the cross-compiler
now builds OK, using the standard make
I am using (Linux platform - Mandriva/Mageia) minicom as a terminal
emulator on my serial port to display data received from my Atmel
microprocessors.
I have had some problems making minicom on work a new Linux release - it
works now. But, solving the problem made me have a closer look at
Thank you for the rapid replies - using screen appears to be the
approach to pursue. And it gives me ideas - I have already a GUI
frontend that wraps up avrdude - maybe I should just add a this kind of
tool as an additional feature.
___
AVR-chat
For image development and storage on the host I would stick to Gimp -
the list of formats that Gimp can produce / import reads like a
who's-who of available formats. Gimp claims that it also can produce
C-code (I never had a look at that and do not know what that precisely
means, but I would
Thank you, nice to have code just to copy from.
That brings up a second question: are there any guidelines how paranoiac
to be with checksumming of data in eeprom?
Reread-verify after download is an evident necessity - one extreme; I
certainly will not checksum what I write to RAM, the other
Thanks, that is a good solution.
I have solved my problem by simply disabling the chip erase for eeprom
(program the EESAVE fuse byte and suppress any download to eeprom),
compiling object-code for eeprom into a template in flash and than
initialising EEPROM - when and where needed - by
I wonder whether there is some approach to provide specific CPUs with
some program-readable identifier that allows to individually recognise
each CPU in a way that survives programming operations that start by
erasing the chip.
To be more clear, here is why I need this: I am having a bus with
Thanks for the reply - that is a solution, but requires me to modify my
PCB, something I would like to avoid, at least for the moment.
Juergen
___
AVR-chat mailing list
AVR-chat@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-chat
Thanks for all that help. I am using an AT90CAN128 (ram-size imposed,
currently with less than 32Kbytes flash used) - dragon would be problematic.
There exists an ftdi_sio driver on my Mandriva kernel (I guess it comes
with the vanilla kernel). But, unless somebody has positive experience
... a GUI template generator that is only available on Win32 platforms
Yes, I had realised that I had better try doing any experiments with an
installation under windows. If I dont run into too much trouble (I only
have an XP machine easily accessible), I will try - always good to look
what
My primary motive for starting my question has been precisely the
occasional user scenario. I deal with it by inserting comment lines at
conspicuous places in my code that contain avrdude command line calls
for copy/pasting to a console (according to my mood: one, several - any
combinations
Thank you for the feedback. I had problems to reduce the flood of
results from googling to something reasonable, and your pointers are
very helpful.
As to the criteria you mention (avoid duplicating what avrdude already
does, think about maintenance, take care of integration into the avrdude
I am passing some quiet vacation afternoons, dreaming. Has a GUI wrapper
for avrdude already been considered? - i.e. replacing painful command
line input for some frequently made avrdude calls by a frontend that
allows selecting what you want to do in a nice graphical user interface?
Am I the
I enquired recently at DigiKey about shipment of small quantities (to
Switzerland), the reply has been:
If you want to use our www.digikey.com website, you can place your
parts as an order and see what the availability of parts and cost
would be without really sending off your order.
All
The replies on PWM in the avr-gcc list make me warm up an old
discussion: how can a selection of information from the avr-gcc and
avr-chat mailing lists be distilled into something with a less ephemeral
visibility and easier to access (search, sort) than an entry in an email
archive?
The
You are right - and I am too tired. On thunderbird you reply to ALL and
then manually delete the original expeditor before sending (my memory
played me a trick, the discussion I remember goes back to exmh times).
My aplogies for the mess - I will resend the PM messages to the list
tomorrow
You might consider gaining some insight by doing practical programming
exercises - for instance a very small client - server application using
sockets, just obtaining a hello message from the server. If you look
left and right while doing that and read the man-pages, it would provide
you with
The JTAG ICE (MK2) comes with a relatively short cable (about 20cm).
Does somebody have experience using a short (how long?) extension cable?
A longer cable would facilitate debugging / re-programming targets that
are located inside some box. I realise, signal rates are high and with
long
In addition to the lfuse settings described by Joerg, I suggest you have
a look at the CKOPT bit of hfuse: I read in the processor manual that
this bit should be programmed to 0 for clock speeds above 8 MHz.
Maybe some remarks from the frog-perspective can be of help - I am
just going through
What else could be happening for the comunication to fail?
There are 3 items in the chain that can be at fault: avrdude, your
programming interface (ICE or whatever you use), and your CPU; can you
try and assess for the initial 2 whether they work correctly?. Avrdude:
are you using the right
I read the question in a slightly different way: is it possible to
multiplex (a) the the Programmer´s serial I/O and (b) the User uart I/O
to a single PC com port?
As far as I know it is not possible in a standard way to simultaneously
link both channels to a single com port.
If you have a
as for ethernet connectivity take a look at:
http://tuxgraphics.org/electronics/200606/article06061.shtml
Some additional practical information relative to this article at:
http://shop.tuxgraphics.org/electronic/eth.html?id=1c550c
For commercial piggy back boards see:
36 matches
Mail list logo
