Go Down

Topic: ATmega1284P: End to End using 1.0 IDE (Read 83165 times) previous topic - next topic

bperrybap




Support in the CORE is almost there.  Issue 728 was applied, which did most everything.  Issue 736 will finish it off.

There is no talk of adding VARIANTS to the official release.  But we don't need variants in the release, the hardware extensions mechanism is fine for that.


What does that mean?
How can you support the original Sanguino and the Bobduino without variants?
Are you saying that this 1284p core will be hard coded to say the "standard" variant
and that the other 2 pin mappings have to ship their own core?


I think you're confused about what is a core and what is a variant.  Review the boards.txt file.  The advantage of having 1284P in the core is that we won't need to ship separate core files.  So boards.txt can simply point to the Arduino core.

Code: [Select]

uno.build.core=arduino:arduino



Not hardly. I'm fully aware of how each mechanism works.
I understand the value in adding 1284p support to the mainline official "arduino" core as it
means users no longer have to locate and install their own separate core to get 1284p support.

What you haven't addressed is how to support multiple variants of the 1284 processor (which might use different pinouts)
once 1284p support is in the arduino core
because there is still the issue is that if a given core supports multiple variants of a single processor
type then there can be issues if the pin mappings are different and the pin mapping
information is needed at compile time.

For example in the analogRead() function there are some assumptions being made as to how to
map digital pins to analog pins/channels based on processor type.
These assumptions may not be correct depending on the given variant for that processor type
and how it defines its digital pin mappings.

While you can add support for 1284 to the common Arduino core, unless there are
defines to indicate more than just the processor type,  mapping code like what is in
analogRead() can potentially fail.

Another alternative (which I think is better) and what is already used in the mighty-1284p core
is to create the needed mapping macros in the variant files.
So rather than having to use ifdefs with magic Arduino Pin#s in functions like
what is in  analogRead() today that is used
to convert from a digital pin # to an analog pin #/channel, a single
macro function would be called which would work regardless of the processor or variant.
This is much better than trying to depend on processor type which does not work
in all cases - which is what we are seeing with the 1284p and its potential variants.

analogRead() can use the digitalPintoAnalogPin() macro
but I would not implement it using ifdefs in the analogRead() function as it is done
today in the mighty-1284p core.

I think it would be much better to create the digitalPintoAnalogPin() macro for *all* variants
in the core and eliminate ifdefs related to dititalPinToAnalogPin().

That way any code (not just analogRead() ) that needs this same functionality
can also have the information and use it and not have to mess with having to create ifdefs with magic number
calculations for when it is not there.

I don't see the value of sometimes having the macro and sometimes not having it.




Unless I'm missing something,
At the present time if I look at wiring_analog.c and analogRead() on git hub and
the proposed patch in issue #736, I don't see how that can support multiple variants
of the same processor that use different digital pins on the analog pins.

It looks like if a boduino variant and its pinouts were used then ananlogRead() would
fail to properly map the digital pins to analog pins.

Can't we just force all the arduino cores to have a digitalPinToAnalogPin() macro
and be done with it? That way each variant defines the needed pin information and nobody
has to ever monkey if ifdefs and magic pin numbers to do pin conversions like what is being
done in analogRead().
All the pin number "magic" is in the variant files.
The core code remains simple, clean, and easy to read.

--- bill







For example in the analogRead() function there are some assumptions being made as to how to
map digital pins to analog pins/channels based on processor type.
These assumptions may not be correct depending on the given variant for that processor type
and how it defines its digital pin mappings.


Ah, yes.  The problem is that the CORE makes assumptions on the VARIANTS.  "For example" is an overstatement, though.  I think analogRead() is the only place this problem exists.

Quote

Another alternative (which I think is better) and what is already used in the mighty-1284p core
is to create the needed mapping macros in the variant files.
So rather than having to use ifdefs with magic Arduino Pin#s in functions like
what is in  analogRead() today that is used
to convert from a digital pin # to an analog pin #/channel, a single
macro function would be called which would work regardless of the processor or variant.
This is much better than trying to depend on processor type which does not work
in all cases - which is what we are seeing with the 1284p and its potential variants.


Yeah, I think I will go and propose this to the developers list.  It is broken to have the core hard-code information that's in the variant.

Quote

analogRead() can use the digitalPintoAnalogPin() macro
but I would not implement it using ifdefs in the analogRead() function as it is done
today in the mighty-1284p core.

I think it would be much better to create the digitalPintoAnalogPin() macro for *all* variants
in the core and eliminate ifdefs related to dititalPinToAnalogPin().

I don't see the value of sometimes having the macro and sometimes not having it.


So this is true.  It would be better.  The #ifdef was expediency.  The value is that I'm not sure it's the right approach--I just built it like 2 days ago.  So until I'm happy with it, I didn't want to port it to all the other variants just to have to change it everywhere later.

Quote

It looks like if a boduino variant and its pinouts were used then ananlogRead() would
fail to properly map the digital pins to analog pins.


Yeah, that's true.  It's a matter of time-ordering.  The patch was created before the Bobuino pinout, and so yes the patch does not account for Bobuinio pinouts.

CrossRoads

I spent some time today wiring up a simple Atmega1284.
I still can't get a sketch downloaded via the serial ports. I can only conclude I have got my system totally hosed as far as bootloaders, boards.txt,  etc.

I think I'm down to stripping everything off my PC and starting from scratch.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

westfw

FWIW, I put a 1284 in my old Sanguino board, and have had no problems getting a bootloader onto it, or downloading sketches (using maniacbug-1284p in ~/Documents/Arduino/hardware/)

CrossRoads

I used to have them working quite well in -0022 with my Bobuino as well - can't even make that work anymore. Got something hosed up.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

retrolefty


I used to have them working quite well in -0022 with my Bobuino as well - can't even make that work anymore. Got something hosed up.


Sunspot counts have been good recently, 10 meter DX is to be had. Maybe a connection?

Lefty


CrossRoads

Must be it! Need to take the antenna off my PC ;)
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

#187
Feb 20, 2012, 10:34 pm Last Edit: Feb 20, 2012, 10:40 pm by adilinden Reason: 1
I finally completed my *uino-1284p board. I successfully loaded the firmware into the ATmega8u2 doing the USB to serial task using avrdude command line on a Mac. I was dreading this task a little, but it turned out there is really good information in the Arduino firmware folder. Using the mighty-1284p files I was able to load the bootloader into the ATmega1284p. I only tried the "Original Mighty 1284p", not the optiboot one. Will try optiboot as well. I was also able to load a sketch to do some blink lights.

Next I need to accomplish two things:


  • Modify the pins_arduino.h to reflect the pinout of the board I created.

  • Create a shield to exercise, verify the various functions of the pins. The way I see it, I need to verify the digital outputs and the PWM functions as well as the analog inputs at the very least.



I assembled the version 0.3 board. So far I encountered two issues. The first issue is the polarity of the reverse polarity protection diode on the external power input is marked wrong. If connected as indicated the board won't power up with proper polarity connected. The second issue is the reset tact switch. I do not know what footprint I picked, I thought it was a standard tact switch, but it is smaller, small enough that a "regular" tact switch won't fit. I will have to find the proper part to fit that space.

If anyone is interested in a bare PCB I will gladly mail one out to you.


  • *uino-1284p version 0.3

  • *uino-1284p version 0.2




  • Modify the pins_arduino.h to reflect the pinout of the board I created.

  • Create a shield to exercise, verify the various functions of the pins. The way I see it, I need to verify the digital outputs and the PWM functions as well as the analog inputs at the very least.




I would really appreciate any information or instructions on how to go about defining pins in pins_arduino.h. I not only have to do this for the *uino-1284p but also for the *uino-32u4.

magagna

I can't help you with the 1284p, but the pins_arduino.h is already done for the 32u4 in hardware / arduino / variants / leonardo of the Arduino install folder.

http://en.wiktionary.org/wiki/magagna <-- My last name.  Pretty apt.


I can't help you with the 1284p, but the pins_arduino.h is already done for the 32u4 in hardware / arduino / variants / leonardo of the Arduino install folder.


Correct, but my 32U4 pinout is different then the Leonardo pinout. So I will still need to modify pins_arduino.h for both boards, and understand how that is done.


CrossRoads

Nice work!
My 1284 DIP boards shipped from iteadstudio today, could have boards in a week or so.

@maniacbug -
Went to see skyjumper today to see why I can't download sketches via serial port. Figured my software was hosed.
We did sort some oddity out, I was seeing lots of 1284 board types when I opened the IDE up, we cleaned up boards.txt to straighten that out, and also straightened out the baud rate changes I had been trying.

In IDE 1.0 discovered that after downloading a bootloader, if I select Bobuino as a board type, that the sketch download would not complete, results in the not in synch errors I had reported earlier.
We used skyjumper's AVR Studio 5 setup to read the fuses - and discovered that the 3rd bootloader fuse listed was listed as Locked, and had to be cleared to Not Locked before a sketch would download.

Selecting one of these as the board type

Mighty 1284p 16 MHz using Optiboot, or
avr-developors.com pinouts16 MHz using Optiboot

didn't seem to have the same problem.
Any ideas?
We were looking at averdude.conf, but we decided that the file was the same for all 3 board types.
Also looked at boards.txt, made sure the fuses entries for the 3 board types were the same, didn't see any change in performance.
At that point we stopped, figured I had a solution I could get by with temporarily - download AVR5, borrow an AVR MkII programmer from skyjumper for some boards I have coming in.

Occurred to me as I started typing this up - we had opened pins_arduino.h, didn't really know what to do with it - this file seems to be the thing that is different between the 3 board types. Is there something in the way that the Rx, Tx lines are defined that would prevent the serial port from working?
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

CrossRoads

Have AVR5 installed now, its Lock  Bit BLB1 that seems to be getting set.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

markab

Just wanted to jump in and say Hi,

I just completed assembly of my new 1284P-AU based board last night and burned the 1284p optiboot loader, so far so good I will give it a full test out over the next few days, I just need to understand the pinout variations that you are discussing here and if it will effect my board design and how I use the bootloader and IDE.

For my first full end to end design including smd reflow with a skillet/frying pan I am pretty happy with how it turned out only issue was the regulator was supplied as the wrong part by farnell so I can't use the unregulated input supply until I replace the IC.  I will be making the design source files available somewhere soon and also have a Rev B in the making with some improvements.

Here is the board assembled...


Go Up