I've secured the xcodeuino.com domain (I considered xcodeui.no for .Norway but relented;) and web
hosting with mySQL databases for a year. I planned to implement it as a Joomla!-site but talking
with a collegue I've decided to use Drupal instead. This means I no longer know
what modules are good or not, so if you have any preferences, let me know.
I'm thinking something like this:
Forums: Drupal Advanced Forum module(s) (screenshots: http://drupal.org/node/867944)
Wiki: demo of the wiki-installation module http://acme.yourbizwiki.com/ (login with test/test!!)
File upload functionality
Unregistered/Registered/Admin/SuperAdmin granularity for permissions
Lets start with just one discussion board, put it on the front page, and go from there
as we build the wiki, coordinate our efforts and get to master how git works with
branching and pulling and requesting
If everything goes according to plan, it should be live monday and open for registrations.
Again guys, thank you so much for all the work you've put in to creating makefiles and what not
to get xcode+arduino running together. I'm way behind atm but will get up to speed asap.
If it isn't too much hassle, I know that myself and many with me would appreciate a lot if
you could do a write-up of what you have learned so far about how this Xcode+Arduino.app setup
works. I'm thinking about a sequential description of how you understand everything runs from
the point to click Build&Upload, what happens with the makefile, documentation about the makefile
and other important knowledge like customizing code completion, syntax coloring et al.
I'm thinking this can be the starting point for a page in the upcoming wiki. We can divide it
into the different phases of compiling and uploading.
We can also start a wiki page documenting how to use git for this project in particular; how to
clone, branch, pull requests and merge. I'm still not sure how merge works with conflicting
parts of the same files (say, the .xcodeproject file) and not overwriting other important changes.
I know diving into many smaller files are key, as always, but with Xcode projects some files are
unavvoidably monolothic.
Also, how does the serial monitor work with our setup? I see you use 'screen ...' - is this the
usual screen command I use when I start shell scripts and irssi on remote servers so I
can reconnect to them later?
Maybe it's an idea to hack a quick Cocoa app or script that handles/starts the serial monitor automatically
for the user?
I've also ordered the WiFly wifi shield from Sparkfun.com so my arduino can speak tcp/ip
with the world. Do you guys have any experience with this, or have any other wifi shield
to reccommend?
Regarding versions: as Olivier use a different and more powerful Arduino board that
isn't fully compatible/running to Arduino 1.0 libraries yet, we'll have two parallell
projects running (or more). For myself I'm primarily interested in Arduino 1.0 + Xcode 4.2
as I'm just recently come aboard and might as well start with the most recent iteration of both.
Tim: How does A*.app 1.0 seem to have changed from 022?
avenue33:
Could you please detail how you reach the result? I've already noticed the HEADER_SEARCH_PATHS parameter, but are there other?
Hey Olivier, my guess is that this should work fine on mpide too, as long as you have Arduino.app installed. Unless Mpide has a lot of functions that are not in Arduino? Anyway it is only for syntax coloring and code completion, it will not affect your build.
IF mpide is not following the arduino conventions, it should be another project anyway, we can't make one XCode project for every flavour of Arduino-style AVR programming, right? Better make a specific project that bases its concepts on the Arduino project.
How does it work? "Serial" is defined in HardwareSerial.h, but only when certain macros have been defined. Those are defined in io.h.
Those macros get defined depending on a macro that defines the arduino board you're using.
So when you pick your board inside the Arduino.app before compiling, it adds a macro that defines your board. For example: AVR_ATmega168 . When this is defined, io.h can then load the correct io header for that specific board and the serial communication can get put together correctly.
I have just set AVR_ATmega8 in the build settings for the fake target, because for our purposes it doesn't really matter what board the fake target thinks it is building for. (not really sure about this)
While looking through all this, I noticed that a lot of stuff in the Arduino .cpp and .h files depends on inttypes.h, stdlib.h, stdio.h etc..
Just to be sure, I included the ones that avr-g++ uses in the header search paths.
I thought about moving the Arduino group to the header search paths too, but I think you sometimes want to check them for reference...
The WProgram.h file, which provides declarations for the Arduino API,
has been renamed to Arduino.h. To create a library that will work in
both Arduino 0022 and Arduino 1.0, you can use an #ifdef that checks
for the ARDUINO constant, which was 22 and is now 100. For example:
The avrdude included with the Mac and Windows versions of the Arduino
software has been upgraded to avrdude 5.11 (from an Arduino-specific
version of avrdude 5.4). The software now uses the "arduino" programmer
type in place of "stk500v1" for uploading to most Arduino boards.
The Arduino part works fine and features a dedicated folder for OBJ files. I'm currently testing the chipKIT part and face two issues I've already reported.
Another section to add to the website is the list of features required, with a points-based system of vote, pretty much like the http://getsatisfaction.com implementation. Each registered user has —let' say— 6 points and can allow up to 3 points per feature. Once the feature is delivered, the user recover his/hers points.
It would be nice to link the number of points one user can handle with his/hers active participation on the project.
HaakonStorm:
If it isn't too much hassle, I know that myself and many with me would appreciate a lot if
you could do a write-up of what you have learned so far about how this Xcode+Arduino.app setup
works. I'm thinking about a sequential description of how you understand everything runs from
the point to click Build&Upload, what happens with the makefile, documentation about the makefile
and other important knowledge like customizing code completion, syntax coloring et al.
Absolutely agree with that, when I get some time, I will try to do a nice write-up.
Maybe after we finnish integrating Arduino.app 1.0 ?
Maybe it's an idea to hack a quick Cocoa app or script that handles/starts the serial monitor automatically
for the user?
I have that app lying around here on my computer.. but I'm not sure I am convinced this should be part of the XCode project...
This is just my personal opinion, but I think this should be as general as possible and the least bloated possible. More stuffss == more places where things can break. People can always fork from the project to add extra special personal preferences to it..
I'm not sure I am right on this one... is serial communication essential in this project? Should it be from XCode? I feel not. What do you guys think?
I've also ordered the WiFly wifi shield from Sparkfun.com so my arduino can speak tcp/ip
with the world. Do you guys have any experience with this, or have any other wifi shield
to reccommend?
There must be some people on this forum that have worked with those things, but that might be another thread...
Maybe it's an idea to hack a quick Cocoa app or script that handles/starts the serial monitor automatically
for the user?
I have that app lying around here on my computer.. but I'm not sure I am convinced this should be part of the XCode project...
This is just my personal opinion, but I think this should be as general as possible and the least bloated possible. More stuffss == more places where things can break. People can always fork from the project to add extra special personal preferences to it..
I'm not sure I am right on this one... is serial communication essential in this project? Should it be from XCode? I feel not. What do you guys think?
I use the serial connection very often as a mean to debug my applications.
So I would greatly appreciate an easy way to have a serial console with a smart management of the USB port to avoid any conflict between the serial console and the upload of the code.
For normal and interactive use, I prefer CooTerm (free).
The error message I receive so far is
screen /dev/tty.usbmodem641 -b19200
Must be connected to a terminal.
It seems to be a rather basic error but I don't know OS X intricacies feel enough to fix it!
HaakonStorm:
I've also ordered the WiFly wifi shield from Sparkfun.com so my arduino can speak tcp/ip
with the world. Do you guys have any experience with this, or have any other wifi shield to reccommend?
I bought the XBee Explorer Regulated board from Sparkfun (WRL-09132) but it has a major flaw: the diode D1 prevents data going to DIN. I put a 10 k? resistor instead.
First app was to read time from a NTP server a set the internal clock of my chipKIT UNO32 board.
try this in your makefile for opening a serial terminal from XCode:
serial:
@echo " ---- open serial ---- "
osascript -e 'tell application "Terminal" to do script "screen /dev/tty.usbmodem* 9600"'
killserial:
@echo " ---- close serial ---- "
osascript -e 'tell application "Terminal" to do script "screen -X quit"'
You can then add these rules after and before your upload if you want.
HaakonStorm:
I've also ordered the WiFly wifi shield from Sparkfun.com so my arduino can speak tcp/ip
with the world. Do you guys have any experience with this, or have any other wifi shield
to reccommend?
I've been using the RN-171 from Roving Networks and just set it up to post to a PHP server every minute without interaction from the host controller. This way, you can power down everything except the WiFi module, it will read sensor data and post to a web server as the frequency you wish. I posted on the Roving FAQ at http://rovingnetworks.com/FAQs/Standalone_WiFi_modules_sending_data_to_web
Okay, the skeleton of http://xcodeuino.com is live.
All interested parties are called to register!
I'm not a web developer by trade, and this is my first Drupal site. Bear with me