Show Posts
Pages: [1]
1  Forum 2005-2010 (read only) / Development / Re: WinAVR dead in the water... (sort of) on: July 10, 2010, 12:35:08 am
I think you're missing the point entirely - you don't "cobble together" the WinAVR toolchain - the actual build is a small part of the process - regression testing across the multiple supported platforms is far more demanding.

The "current generation" of chips is a constantly moving target. Whilst the Arduino has tended to stay in one small sub-group, in a while, that'll go and be replaced by something else. It won't effect the majority of users, but it will effect the effort needed to make the project go forward.

GCC is a non-trivial toolchain to build (I've done builds & ports to other chips myself), and the Arduino dev environment depends on a huge amount of work done on avr-libc & the avr-gcc port - this is ongoing, but in the absence of a third-party delivered build, the Arduino team may well have to do it themselves - in theory, this is not too complex, in practice it can be distinctly non-trivial.

Luckily, it seems that Atmel may allow an equivalent of the WinAVR tree to be split off from the AVRstudio 5 build, but as it is very much early days on that and they are making no clear statement, no-one can be sure.

Nick
2  Forum 2005-2010 (read only) / Development / WinAVR dead in the water... (sort of) on: July 01, 2010, 10:31:42 am
The WinAVR project is now marked as "inactive" as is seems Atmel are going to do this internally (as the maintainer is an Atmel employee anyway) and it looks like this will be rolled into AVRstudio 5 due very soon.

How will this change effect the Arduino development environment?

Cheers

Nick
3  Forum 2005-2010 (read only) / Development / Any documentation available on IDE pre-processor? on: July 15, 2010, 04:13:23 am
Hi,

Is there any documentation available of how the Arduino IDE pre-parses the C++ code to generate function prototypes etc. before the actual avr-gcc compilation phase - by documentation I don't mean generalities - I'm looking for specifics and detail... preferably the actual algorithm.

The reason I ask is that I have singleton classes with embedded static member functions - these happily compile in AVRstudio with avr-gcc (same version), but fail with obtuse messages in the Arduino environment.

Alternatively, is there a way of keeping the intermediate file produced after the pre-processor has had its way so that I can see more clearly what its up to?

Thanks
4  Forum 2005-2010 (read only) / Bugs & Suggestions / Re: Hardware robustness... (ADC & RESET)... on: June 29, 2010, 11:53:33 pm
Quote
I believe that is so it can be set-up for high voltage programming where (I think) +12vdc is wired to the reset pin. Perhaps the datasheet section covering HV programming might explain the reset pin functions better. Obviously the normal clamping diodes from Vcc to pin wouldn't work for this pin.
As I stated in point 2 of my OP, HV programming precludes the use of the full ESD protection, but Arduinos don't use that so can take advantage of the optional additional protection. Even if empty  pads were left for optinal extra components, that'd be good and at no extra cost to the dev board.

Cheers

Nick
5  Forum 2005-2010 (read only) / Bugs & Suggestions / Hardware robustness... (ADC & RESET)... on: June 29, 2010, 11:56:18 am
Hi,

I work in a high-EMI environment. A couple of small changes to the standard Arduinos would ease matters for those like myself:

1. Add in a low pass filter for the AVCC pin - a simple LC filter (15uH, 10nF) as recommended by Atmel - this will also enable more accurate ADC readings...

2. read AVR040 & AVR042 - it's not commonly known that the /RESET pins on most AVRs is not ESD-protected in the same way as all other I/O pins - its almost impossible to find this out in the data sheets - its very obtuse indeed. A small diode (1N4148) with a 4k7 resistor to VCC, and a 4n7 cap to ground would help greatly (assuming you're not using HV programming). In addition, leaving space for a small zener between GND & /RESET would allow it to be easily added in very high noise environments.

Probably only a few cents to add, but these are simple changes that are recommended by Atmel that would, IMHO, greatly improve the robustness of these boards.

Cheers

Nick
6  Forum 2005-2010 (read only) / Bar Sport / Re: BOM Database for Arduino and other boards on: July 15, 2010, 04:20:24 am
Well, a BOM is a Bill Of Materials, almost always for a single project.

What you appear to be looking for is a common repository of parts which you can use across a number of projects.

Devices in Eagle libraries can have attributes associated with each technology type. It may be (and I haven't tried this yet) that when you use a part you can access its attributes from within a BOM ULP, i.e. you can put all your parts in a library with the supplier p/ns, and when you use that part the project BOM will reflect that information.

Best place to punt this one is in the Eagle newsgroups I mentioned above - probably eagle.support.eng or eagle.userchat.eng (assuming you're an Anglo- not a Germanophone, as there are German-specific groups too... replace ".eng" with ".ger")

I should also point out that Eagle has been bought by Premier Farnell (who also own Newark) and that they have stated that they will be providing an on-line lookup & BOM generator in future releases - the first cut at this is called "designlink.ulp" and is in Eagle 5.10 as standard.

Cheers
7  Forum 2005-2010 (read only) / Bar Sport / Re: BOM Database for Arduino and other boards on: July 10, 2010, 04:27:52 pm
Eagle comes with bom.ulp and there are several other BOM ulps on the Cadsoft download site.

The Eagle newsgroups at news://news.cadsoft.de are the main source of help on this sort of question.

Its worth noting that the latest versions of Eagle have the concept of user defined attributes for parts. What most users do is define an attribute for each supplier you want to use, e.g. DPN xxxx (for DigiKey part number), FPN xxxx (the Farnell equivalent) etc.

When you use the BOM ulps, the attributes are automatically split into seperate columns, thus generating BOMs for however many suppliers you want.

Doing it this way means that the BOM is integral to the Eagle design files (typically the SCH file) and uses ulps that all Eagle users have access to, i.e. no-one needs any special software or databases etc.

Cheers

Nick
Pages: [1]