So, I’ve never dabbled in C until now while using it with AVR microcontrollers – and while trying to complie a simple for loop:
for (uint8_t bit = 0x80; bit; bit >>= 1) {
...
}
I got this error:
error: 'for' loop initial declaration used outside C99 mode
and to fix it I would move my decloration of the varabile outside of the loop. This seemed stupid to me so a quick Google search turned up this
Back in the old days, when dinosaurs roamed the earth and programmers used punch cards, you were not allowed to declare variables anywhere except at the very beginning of a block.
Solution was to add -std=c99 to the Makefile. My new AVR Makefile now looks like this..
Posted: June 15th, 2011 | Author: jay | Filed under: Code, Electronics | Tags: attiny, avr, avr-gcc, c, c99, gcc, makefile | No Comments »
This was what I needed for a rainbow RGB LED cycle…
Posted: May 10th, 2011 | Author: jay | Filed under: Code | Tags: attiny, attiny85, avr, led, rainbow, rgb, sin, sine, sine wave | No Comments »
Based on Atmel’s AVR136: Low-Jitter Multi-Channel Software PWM Application note, here’s a 3 channel software-based pulse width modulator to drive a RGB LED. This is a proof of concept and currently there is some in-efficient color cycling code in there, but the goal is to drive these cheap chips using an I2C (two wire serial) bus. Disco dance floor anyone?…
Posted: May 4th, 2011 | Author: jay | Filed under: Code, Electronics | Tags: atmel, attiny, attiny85, c, i2c, led, pulse width, pwm, rgb | No Comments »
avrdude -c dragon_hvsp -p attiny85 -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -P usb
Posted: May 3rd, 2011 | Author: jay | Filed under: Electronics | Tags: atmel, attiny, avr dragon, avrdude, dragon_hvsp, fuse, high voltage, reset | No Comments »
This is what I’m using as a Makefile – based on what was included in a downloaded XCode template project – Can’t remember where I downloaded the starting point, but thanks…
Posted: April 26th, 2011 | Author: jay | Filed under: Code, Electronics | Tags: attiny, avr, make, makefile, usbtiny | No Comments »
Starting to play around with Arduino and straight-up AVR ATTiny microprocessors… Here are some resources I’ve found helpful so far:
- Getting started with the ATTiny MP
- Building and using an AVR target board
Posted: April 8th, 2011 | Author: jay | Filed under: Uncategorized | Tags: arduino, attiny, avr | No Comments »
Yeah, it’s simple but useful. Since I’m using sqlite at the moment, it’s just a copy but you could run any command in a similar way. I’m also tagging the backup name with a date. Here’s a snip from my Capistrano deploy file….
# ...snip...
namespace :deploy do
task :restart do
t=Time.now
run "cp /path/to/db.sqlite3 /path/to/backup/#{t.year}-#{t.month}-#{t.day}_#{t.hour}:#{t.min}:#{t.sec}_db.sqlite3"
run "touch #{current_path}/tmp/restart.txt"
end
end
Posted: May 20th, 2010 | Author: jay | Filed under: Code | Tags: backup, capistrano, database, db, deploy, sqlite | No Comments »
This MOSTLY is working, so, here’s what I found when trying to connect to Facebook with OAuth. It needs some serious refactoring because a lot of this was done in an “investigative” trial and error way. It also looks like Facebook have improved their docs on this since I was first looking at them…
First, you need to initiate a connection:
get '/:blog_name/facebook/oauth/create' do
redirect "https://graph.facebook.com/oauth/authorize?client_id=##FACEBOOK API KEY##&redirect_uri=##CALLBACK URL##&scope=publish_stream,user_status,user_photos,user_about_me"
end
where ##FACEBOOK API KEY## = your applications API key (mine is a 32 digit hex value) and ##CALLBACK URL## = the URL that will be processing the next step. Also, the scope value let’s you get more access to the user’s account. Check their extended permissions doc for more info.
Next, you need to process what comes back from Facebook. I am stashing what comes back in the DB (the FacebookOauthToken model). Also using the Mechanize gem which is pretty silly. Some of the code below is specific to my app, so ignore those bits…
get '/:blog_name/facebook/oauth/callback' do
if !params['code'].blank?
url="https://graph.facebook.com/oauth/access_token"
client_id="client_id=##CLIENT ID##"
client_secret="client_secret=## CLIENT SECRET ##"
code="code=#{URI.escape(params['code'])}"
redirect_uri="redirect_uri=http://example.org/#{@blog.url_name}/facebook/oauth/callback"
url="#{url}?#{client_id}&#{client_secret}&#{code}&#{redirect_uri}"
begin
res=open(url)
rescue
flash[:error]="There was a problem connecting to Facebook"
redirect "/#{@blog.url_name}/"
end
read=res.read
access_token=CGI.parse(read)['access_token']
if !access_token.blank?
@blog.facebook_oauth_token = FacebookOauthToken.new(:access_token=>access_token,:blog_name=>params[:blog_name])
if @blog.save
begin
a=Mechanize.new
res=a.get("https://graph.facebook.com/me/?access_token=#{access_token}")
@blog.facebook_oauth_token.facebook_id=JSON(res.body)['id']
@blog.save!
rescue
flash[:error]="There was a problem getting information from Facebook"
redirect "/#{@blog.url_name}/"
end
flash[:notice]="Facebook connection created!"
redirect "/#{@blog.url_name}/"
else
flash[:error]="There was a problem saving Facebook connection"
redirect "/#{@blog.url_name}/"
end
else
flash[:error]="There was a problem making Facebook connection"
redirect "/#{@blog.url_name}/"
end
else
flash[:error]="There was a problem connecting to Facebook"
redirect "/#{@blog.url_name}/"
end
end
Where ##CLIENT ID## = your Application ID (mine is a 12 digit numeric value) and ## CLIENT SECRET ## = your Application Secret (mine is a 32 digit hex value).
Once you have an access_token you should be able to make calls to URLs like this:
"https://graph.facebook.com/me/?access_token=#{access_token}". The /me path is the connected user’s data and I’m grabbing their Facebook ID from the returned JSON for use elsewhere.
Posted: May 20th, 2010 | Author: jay | Filed under: Code | Tags: access token, api, client id, facebook, graph, graph.facebook.com, json, oauth | 1 Comment »
Going to start reviewing what went down with my little app though.
Posted: May 20th, 2010 | Author: jay | Filed under: Uncategorized | No Comments »
Pretty simple, but wanted to log here so I can look this up in the future…
I wanted to deploy to both a stage and a live site. Here’s how that went down:
First I installed the capistrano-ext gem. Second, I edited my Capfile to look like this:
1
2
3
| require 'capistrano/ext/multistage'
set :default_stage, "beta"
set :stages, %w(beta live) |
Third, I created a deploy folder and added my two recipes there. beta.rb looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| load 'deploy' if respond_to?(:namespace) # cap2 differentiator
default_run_options[:pty] = true
# be sure to change these
set :user, 'username'
set :domain, 'beta.example.org'
set :application, 'fundastache'
# the rest should be good
set :repository, "#{user}@#{domain}:git/#{application}.git"
#set :repository, "/home/#{user}/git/#{application}.git"
set :deploy_to, "/home/#{user}/#{domain}"
set :deploy_via, :remote_cache
set :scm, 'git'
set :branch, 'master'
set :git_shallow_clone, 1
set :scm_verbose, true
set :use_sudo, false
server domain, :app, :web
namespace :deploy do
task :restart do
run "touch #{current_path}/tmp/restart.txt"
end
end |
The live recipe looks almost identical.
Now when I
the site is deployed to the live environment and when I
or simply
the site is deployed to the beta site.
Posted: April 23rd, 2010 | Author: jay | Filed under: Code | Tags: beta, capistrano, deploy, production, recipe, stage | No Comments »