ATmega644(Sanguino) compatibility on Arduino 0012

Hi,

So the question is if the ATmega644 is fully compatible with Arduino 0012 using the Sanguino botloader and Core code?

Quoting Mem

A specific question is: given that this arduino library uses thirteen of the twenty arduino defined digital pins, eight accessed through direct port io, five through arduino digital pin mappings, should this code work unchanged on the sanguino, if not, where can guidelines be found for running arduino code to the sanguino

This question expressed more generally is:
What are the issues with arduino software (such as different mappings to ports and/or resources) using digital pins 0-19 on the ATmega644, either with digitalWrite or using direct port access?

From post http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1210427907/40#40

Another quote from Mem

Had a quick look at the sanguino website and didn't see information on how to access the extra digital ports in an arduino compatible way. The doc I did see had mappings for digitalWrite that seemed quite different (read incompatible) with the arduino for all digital pins above 13.

I am a little confused by the claim that the sanguino is arduino compatible and would appreciate if someone could point me to advice on porting arduino code that uses digital ports 0 through 19 (including direct port io) so that it can run on the sanguino

And reply from Digger

It looks the same to me mem, just more pins Although, I haven't had time to mess with mine yet.

Quote:
pinMode(), digitalRead(), digitalWrite()

The digital pin functions are identical to the Arduino, with one difference: there are more of them!

The Sanguino has 24 normal digital pins, numbered 0-23. As with the Arduino, you can also use Analog pins as Digital pins. Digital pins 24-31 correspond to Analog pins 7-0. Its sort of backwards, but that means Analog 0 is Digital 31, and Analog 7 is Digital 24.

Some of the digital pins have extra features you may want to keep in mind when choosing pins:

  • Digital 2 - Interrupt 2
  • Digital 3 - PWM
  • Digital 4 - PWM
  • Digital 5 - MOSI (used for SPI)
  • Digital 6 - MISO (used for SPI)
  • DIgital 7 - SCK (used for SPI)
  • Digital 8 - Rx0 (this is used by the USB<->Serial port)
  • Digital 9 - Tx0 (this is used by the USB<->Serial port)
  • Digital 10 - Rx1 (this shared with the extra serial connection) / Interrupt 0
  • Digital 11 - Tx1 (this shared with the extra serial connection) / Interrupt 1
  • Digital 12 - PWM
  • Digital 13 - PWM
  • Digital 14 - PWM
  • Digital 15 - PWM
  • Digital 16 - SCL (used for I2C)
  • Digital 17 - SDA (used for I2C)

These extra features are optional, and the pins function as digital I/O pins by default.

This is another issue but when compaling:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1222013546/17#17

Go to sanguino.cc and get the latest info and files.

I don't have the chip and haven't spent much time looking at this, but if digital pins 14 – 19 do not map to analog pins 0-5 than that doesn't seem identical to me. Also, is the USB serial port really on digital pins 8 and 9 instead of 0 and 1?

And is there somewhere (other than going through the datasheet) for information on getting Arduino code that access the registers particularly the timers and direct port io running on the sanguino? I don't have an ATmega644 so haven't' needed to bother with the datasheet but I would be happy to help people get code running on the chip if someone had some notes on mapping the equivalent ATmega168 data ports and timer registers.

Go to sanguino.cc and get the latest info and files.

Hi franklin, you posted while I was replying. do you know of a link that has the information mentioned in the previous post?

The main page is sanguino.cc and the hardware page is Contact Support Hope this will help.

I had already looked at the the Sanguino website.

There is a page on the site on “the differences between the Sanguino and Arduino” that I hoped would help. But it avoids mentioning the issues that prompted this thread, i.e. Arduino playground code that accesses resources like direct port IO not working on the Sanguino.

The board looks to be welcome addition to the Arduino/Freeduino ecosystem, but as this seems to be commercial venture and is promoted as “compatible with the Arduino software”, I think the Sanguino distributors should clarify areas that may not be compatible with widely used (and not necessarily official) code in the Arduino playground. And ideally provide advice on porting code that accesses resources like direct port io/ timer registers, PWM pins etc so that people producing code for the playground can help users get up and running on the Sanguino.

I understand where you are comming from but

“compatible with the Arduino software”

is true, what it does not do is allow user hacked code to run without modification but then it didn't run with the Arduino software until someone wrote code to allow it to. I'm sure the people that decide to use the Sanguino will port any code they see as useful in time. I would like it to run all code out of the box but since it is a different animal I can see why it doesn't.

My point is not that the compatibility statement isn't true, its that the statement is potentially misleading for people that get the board and find it doesn't run some popular library from the Arduino playground.

The issue is easily resolved by clarifying the “compatible with the Arduino software” message. Perhaps the site could say that the board works with all of the current Arduino distribution examples ( I presume it does, this would seem a minimum definition of compatible). And I think there should be a note clarifying that sketches and library code that make direct access to resources like timers and ports may need to be modified to function correctly.

It's great to see the Sanguino filling a need in the quest for more powerful hardware to run software developed by the Arduino community. I am sure it will do well. But a little more clarity would help avoid potential disappointments if a needed library won't run on the board.

Hey Guys,

I'm the creator of the Sanguino, and I'd like to clarify a few things:

by 'compatible with arduino', we mean that the Sanguino is:

it's my goal to keep the Sanguino as compatible as possible with non-official Arduino libraries, but as you may imagine it is quite a bit of work to ensure that they all stay synchronized. i'll try to make a note of this on the sanguino website to avoid confusion.

the reason for creating the sanguino, as well as my day to day work is hacking on RepRap, which keeps me really busy. i'll try and dig into the library code that is having a problem here and try to figure stuff out, but it may take me a little bit to get up to speed with the library and figure out whats wrong.

in the meantime, i'm sending mem a Sanguino kit in hopes that the creator of the library will be able to easily spot and fix the problem.

unfortunately, with low level hardware access happening, you tend to lose compatibility between different microcontrollers. all of the pin to port mappings are published: you can either check out the schematic or look at the code in the sanguino 'core' folder. Both are freely available.

good luck with the LCD, and I hope we get this fixed asap.

I could be off base here, but it seems to me that a lot of the libraries didn't even survive the transition from Rel 011 to Rel 012.

So the problem of maintaining compatibility with Playground examples and libs goes beyond the Sanguino.

(Don't hit me if this is "out of line" :slight_smile: )

BroHogan, The 011 to 012 problems are a very different issue then the one raised here. Most of the problems with the transition to 0012 I have seen reported were caused by a handful of macros that were moved around in 012 that conflicted with some of the low level C include files. I have read that these macros will removed in future but simple workarounds have already been posted.

The issue here is that the sanguino chip has many more hardware resources then the standard Arduino chip and the registers used to access the hardware is different. The arduino abstractions as documented in the reference insulate users from this problem, but if a sketch or library code use the registers directly, as it may have to do to access things like the timers then code may not work on the chip used by the sanguino.
This means modifying code to access the registers and perhaps also changing the pin assignments if the chip maps resources to different pins.

This should not be a difficult task once documentation is available that summarizes the register changes from the ATmega168 to the 644 for commonly used resources.

Thanks, mem. I appreciate the clarification. :slight_smile:
Sorry for the distraction.

Hoeken,

Thanks for popping in with a comment in this thread, Rome wasn´t build in one day so...
Hopefully mem will arrenge the needed fix for his LCD Library and also get a better understandig of the pin configuration fot the ATMega 644 that he can share with us all.

Will you by the way be able to check what is wrong when you compile the code attached bellow. It works perfect with the Arduino 0011 or 0012 and a Arduina Diecemila board selected but not with the Sanguino board selected.

Cut & paste and you will see the issue from this link:
http://opengauge.googlecode.com/svn/trunk/obduino/obduino.pde

code that accesses resources like direct port IO not working on the Sanguino.

An arduino-like board that uses a significantly different CPU chip would (most likely) not be compatible below the "aduino runtime library" level. It's an interesting point for would-be library writers - do you use ONLY the arduino library calls (maintaining compatibility with alternate hardware, but getting pretty ugly when you really do want to do byte-wide access to pins), or do you drop below that level to get more elegant and better performing code? (and of course, the purpose of SOME libraries is to access on-chip resources like the timers or uart in more advanced ways than are possible via the arduino libraries, and those libraries are going to be chip specific regardless. A library author cannot be expected to keep track of every third-party piece of hardware that comes along (unless they're getting paid!) (although, free hardware sounds pretty motivating, too, for easy jobs.) (to some extent, this is where the open source community comes in. After several iterations of new hardware, you code may be a bloated and unintelligible mass of conditionals and mixed styles, but it'll run all over!)

I would have thought this all was relatively obvious, but then it's at the level of code that I'm frequently involved with, and I keep forgetting the experience level of the target audience for arduino. Sanguino probably should have some explicit warning about library compatibility, and maybe a wiki page showing which libraries have been tried (and whether they work or not.)

Well its nice to say it's "almost" Arduino compatible, but to anyone buying one, the concept that library authors don't get paid to update their library's isn't going to occur to them until they discover something doesn't work.

And even then it's not really their problem, if they believe its Arduino compatible thats something of a global declaration with no visible conditions attached.

I was about to place an order for 10 to play with, but now it looks like it might be best to wait for a Wiki page to make an appearance.

Its good to see westfw and John_Ryan reinforcing the importance of clarity in statements about compatibility.

This thread started because a user of my graphics LCD library found it wouldn't work on the ATmega644 chip. The library uses direct port IO because it would be about 100 times slower if it used digitalWrite in drawing pixels. Because the 644 chip maps arduino pins to different registers than the 168, the code doesn't work as is on that chip.

Its not difficult to change the code if one knows the mapping, and I think any site promoting 'compatible' hardware should provide guidance on relevant differences and what is (and is not) likely to work without modification.

I have looked at the changes needed for the GLCD code and will update the library when it is tested with the ATmega644. I am compiling a table showing the differences in pin and register mapping between the 168 and 644 and will post that here and make it available to the sanguino people. I expect they will also make this information available on their site.

Sorry mem I hope it didn't sound like a stab, I would have thought the Sanguino people might have approached library authors for support before it was released.

Sanguino is an awesome evolutionary step forward for Arduino so it'll be great once all the lose ends are sewn up =)

No problems John. I posted my comment to thank you guys for your support. I hope it didn't come across as otherwise.

I completely agree that the sanguino will be great for applications that need lots of IO.

Just want to give you all some feedback.
mem has provided me with a updated KS0108 Library that after some tweeking works with the Sanguino bootloader and a ATMega644.

I am sure that mem will give us more information on his progress when he feels finished with his work on the KS0108 library and the understandig of the ATmega644 technical hardware functionallity combined with Sanguino bootloader.

The library source code is too big to post here in full, and I am still working on some changes that will simplify interfacing to panels that require different delays and also make the pins easier to select in the header file.

But for those of you in a rush, here is a modified top half of the ks0108.h that works with the sanguino. Replace the top half of the code in the ks0108.h file with the code below. All code from the following line is unchanged from the version downloaded from the playground: // macros for pasting port defines

The default settings here have the LCD data pins connected to Sanguino pins 0-7. Control pins are 20 to 23 (see the header file for specifics), but you can change these if necessary
The file can also be used with the Arduino by commenting out #define ATMEGA644

Not that the sanguino allows all data pins on the same port which makes the updates a little quicker, but note that you may need to add some additional delay in the cpp file if your panel can't cope with the extra speed.

I recommend waiting a few weeks for a finished and tested version that will be easier to use. But if you are in a rush to test some alpha code, have fun!

//  ks0108.h - Arduino library support for ks0108 and compatable graphic LCDs
// alpha version for sanguino testing

#include <inttypes.h>
//#include <wiring.h> // for boolean
typedef uint8_t boolean;
typedef uint8_t byte;
#include <avr/pgmspace.h>

#ifndef      KS0108_H
#define KS0108_H

/*********************************************************/
/*  Configuration for assigning LCD bits to Arduino Pins */
/*********************************************************/

// first we have the Sanguino defines
/*******************************************************************************************/
/* Sanguino/ ATmega644 defines                                                             */
/*******************************************************************************************/
#define ATMEGA644
#ifdef ATMEGA644

// Command pins assignments:
#define CSEL1                        20             // CS1 Bit   // swap pin assignments with CSEL2 if left/right image is reversed
#define CSEL2                        19             // CS2 Bit
#define R_W                              21             // R/W Bit
#define D_I                              22             // D/I Bit 
#define EN                              23             // EN Bit

// data pin assignments- on ATmega644 all data pins are assigned to the same port
#define dataPins0to7    // bits 0-7 assigned to sanguino pins 0-7
//#define dataPins8to15   // bits 0-7 assigned to sanguino pins 8-15 // note this conflicts with serial UART
//#define dataPins16to23  // bits 0-7 assigned to sanguino pins 16-23 
//#define dataPins24to31  // bits 0-7 assigned to sanguino pins 24-31

// these macros  map pins to ports using the defines above
// the following should not be changed unless you really know what your doing 
#ifdef dataPins0to7
#define LCD_DATA_LOW_NBL    B   // port B=pins 0-7 on ATmega466  
#define LCD_DATA_HIGH_NBL   B   // on ATmega644, high and low nibbles are on the same port
#endif
#ifdef dataPins8to15 
#define LCD_DATA_LOW_NBL    D   // port D=pins 8-15 (note serial UART uses 8 and 9) 
#define LCD_DATA_HIGH_NBL   D   
#endif
#ifdef dataPins16to23          
#define LCD_DATA_LOW_NBL    C   // port C=pins 16-23
#define LCD_DATA_HIGH_NBL   C 
#endif
#ifdef dataPins24to31          
#define LCD_DATA_LOW_NBL    A   // port A=pins 24-31 (note these are the analog ports)
#define LCD_DATA_HIGH_NBL   A
#endif


// ATmega644 macros to fast write data to pins, this version only works for pins 0-23
#define fastWriteHigh(_pin_) ( _pin_ < 8 ?  PORTB |= 1 << (_pin_ & 0x07) : ( _pin_ < 16 ?  PORTD |= 1 << ((_pin_ -8) & 0x07) : PORTC |= 1 << ((_pin_ -16) & 0x07)  ) ) 
#define fastWriteLow(_pin_) ( _pin_ < 8 ?   PORTB &= ~(1 << (_pin_  & 0x07)) : ( _pin_ < 16 ?  PORTD &= ~(1 << ((_pin_ -8) & 0x07) )  :  PORTC &= ~(1 << ((_pin_ -16) & 0x07) )  ) )

/*******************************************************************************************/
/* Arduino ATmega168 specific defines                                                             */
/*******************************************************************************************/
#else  
#define CSEL1                        15            // CS1 Bit   // swap pin assignments with CSEL2 if left/right image is reversed
#define CSEL2                        14            // CS2 Bit
#define R_W                              16            // R/W Bit
#define D_I                              17            // D/I Bit 
#define EN                              18            // EN Bit

/* Arduino pins used for LCD Data 
 * un-comment ONE of the following pin options that corresponds to the wiring of data bits 0-3 
 */
#define dataPins8to11   // bits 0-3 assigned to arduino pins 8-11, bits 4-7 assigned to arduino pins 4-7
//#define dataPins14to17 //bits 0-3 assigned to arduino pins 14-17, bits 4-7 assigned to arduino pins 4-7. (note command pins must be changed)
//#define dataPins0to3  // bits 0-3 assigned to arduino pins 0-3 , bits 4-7 assigned to arduino pins 4-7, this is marginally  the fastest option but  its only available on runtime board without hardware rs232.

// ATmega168 macros to fast write data to pins known at compile time, this is over 30 times faster than digitalWrite
#define fastWriteHigh(_pin_) ( _pin_ < 8 ?  PORTD |= 1 << (_pin_ & 0x07) : ( _pin_ < 14 ?  PORTB |= 1 << ((_pin_ -8) & 0x07) : PORTC |= 1 << ((_pin_ -14) & 0x07)  ) ) 
#define fastWriteLow(_pin_) ( _pin_ < 8 ?   PORTD &= ~(1 << (_pin_  & 0x07)) : ( _pin_ < 14 ?  PORTB &= ~(1 << ((_pin_ -8) & 0x07) )  :  PORTC &= ~(1 << ((_pin_ -14) & 0x07) )  ) )

// these macros  map pins to ports using the defines above
// the following should not be changed unless you really know what your doing 
#ifdef dataPins0to3
#define LCD_DATA_LOW_NBL   D   // port for low nibble: D=pins 0-3  
#endif
#ifdef dataPins14to17 
#define LCD_DATA_LOW_NBL   C   // port for low nibble: C=pins 14-17 (using this requires reasignment of command pins) 
#endif
#ifdef dataPins8to11            // the following is the defualt setting
#define LCD_DATA_LOW_NBL   B   // port for low nibble, B=pins 8-11
#endif

#define LCD_DATA_HIGH_NBL  D   // port for high nibble: D=pins 4-7, B & C not available on std arduino  
/* NOTE: all above options assume LCD data bits 4-7 are connected to arduino pins 4-7 */

#endif // end of Arduino/ATmega168 specific defines


/*******************************************************/
/*     end of pin configuration                        */
/*******************************************************/

/* option: uncomment the next line if all command pins are on the same port for slight speed & code size improvement */
//#define LCD_CMD_PORT            PORTC            // Command Output Register 

//#define HD44102   // uncomment this to build a 44102 version

/* 
#ifdef dataPins8to11 || dataPins14to17  // these arduino options split data across two ports 
#define LCD_DATA_NIBBLES                // if this is defined then data i/o is split into two operations
#endif 
the above is now done using the test below
*/
#if LCD_DATA_HIGH_NBL !=  LCD_DATA_LOW_NBL
#define LCD_DATA_NIBBLES               // if this is defined then data i/o is split into two operations
#endif 


// macros for pasting port defines

note that exisiting code from the header file needs to be appended starting with the macros for pasting port defines