I'm an extreme noob, how do I reload the human firmware to make my badge work again (somehow nuked the firmware playing around)? Then how do I load the goon firmware?
Using simpleIDE is what nuked my original firmware, and I loaded something simple to restore LED functions, simpleIDE did not except the human code. Using PropellerIDE I do not get any faults loading, but the LEDs do not work. For the goon firmware, I tried to use Daemon to convert the bin- I'm trying to learn googling around, but I'm getting no where.
I'm an extreme noob, how do I reload the human firmware to make my badge work again (somehow nuked the firmware playing around)? Then how do I load the goon firmware?
Using simpleIDE is what nuked my original firmware, and I loaded something simple to restore LED functions, simpleIDE did not except the human code. Using PropellerIDE I do not get any faults loading, but the LEDs do not work. For the goon firmware, I tried to use Daemon to convert the bin- I'm trying to learn googling around, but I'm getting no where.
Go back to post #27 of this thread and follow the directions to load the goon firmware image to eeprom. (someone at the hardware hacking table is likely to have a human image as well) That will get you a functioning badge. You probably just accidentally did a load to eeprom while experimenting instead of a load to ram. You might consider installing a switch to control the write-protect pin of the eeprom to avoid mistakes in the future?
You probably just accidentally did a load to eeprom while experimenting instead of a load to ram.
Right, the first thing I did was load SimpleIDE and accidentally used the burn to EEPROM vs. the burn to RAM button- even after reading the readme file on the defcon disk mentioning f10 and the ram option to protect the firmware. I spent three hours messing around with the provided code from the defcon CD and ultimately gave up, loaded an example code from the SimpleIDE library, change the code to the pin numbers listed in the defcon provided code and got my LEDs to do a custom routine, but lost all of the other badge features of course.
Go back to post #27 of this thread and follow the directions to load the goon firmware image to eeprom.
With post 27, thats the thing, I can't even follow those instructions, I do not know how to execute that burn. I've been pouring over this thread and google as I wasn't sure how asking here would be received. I open PropellerIDE, go to open, the goon file does not show in the folder because its looking for a spin file, go to all files, it won't load a bin. Tried to use Daemon to convert the bin/extract it into something useful. I went to the hardware hacking village and it looked like most people were trying to crack the IR challenge, I didn't want to bug them with such a novice situation.
You might consider installing a switch to control the write-protect pin of the eeprom to avoid mistakes in the future?
Its burned into my EEPROM not to make that mistake again lol.
I hope to be able to post the FULL code for download later today. I just need approval from LoSt or DarkTangent, and then it'll be on the first post of this thread.
With SimpleIDE and it's library, this is what I put into the badge to at least have LED functions and not be "that guy" with a dead badge-
/* Blink Light.c
Blink light circuit connected to P26.
[URL]http://learn.parallax.com/propeller-c-simple-circuits/blink-light[/URL]
*/
#include "simpletools.h" // Include simpletools
int main() // main function
{
while(1) // Endless loop
{
high(16); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(16); // Set P26 I/O pin low
pause(600); // Wait another 1/10 second
high(23); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(23); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(17); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(17); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(22); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(22); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(18); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(19); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(19); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(20); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(20); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21);
high(18); // Set P26 I/O pin low
pause(200); // Wait another 1/10 second
high (16);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
high (23);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (18);
high (19);
high (20);
high (21);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (19);
high (20);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high(16); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(16); // Set P26 I/O pin low
pause(600); // Wait another 1/10 second
high(23); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(23); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(17); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(17); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(22); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(22); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(18); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(19); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(19); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(20); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(20); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21);
high(18); // Set P26 I/O pin low
pause(200); // Wait another 1/10 second
high (16);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
high (23);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (18);
high (19);
high (20);
high (21);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (19);
high (20);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200); high(16); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(16); // Set P26 I/O pin low
pause(600); // Wait another 1/10 second
high(23); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(23); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(17); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(17); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(22); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(22); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(18); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(19); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(19); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(20); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(20); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21);
high(18); // Set P26 I/O pin low
pause(200); // Wait another 1/10 second
high (16);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
high (23);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (18);
high (19);
high (20);
high (21);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (19);
high (20);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high(16); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(16); // Set P26 I/O pin low
pause(600); // Wait another 1/10 second
high(23); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(23); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(17); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(17); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(22); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(22); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(18); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(19); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(19); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(20); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(20); // Set P26 I/O pin low
pause(100); // Wait another 1/10 second
high(21);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21);
high(18); // Set P26 I/O pin low
pause(200); // Wait another 1/10 second
high (16);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
high (23);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (17);
high (18);
high (19);
high (20);
high (21);
high (22);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (18);
high (19);
high (20);
high (21);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (1200);
high (19);
high (20);
pause (150);
low (16);
low (17);
low (18);
low (19);
low (20);
low (21);
low (22);
low (23);
pause (100);
high(16);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(16);
low(18);
high (17);
high (19); // Set P26 I/O pin low
pause(100);
low (17);
low (19);
pause (100);
high (18);
high (20);
pause (100);
// Wait another 1/10 second
high(21);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21);
low(18);
high (19);
high (20); // Set P26 I/O pin low
pause(200);
high (21);
high (22); // Wait another 1/10 second
high(21);
high(18); // Set P26 I/O pin high
pause(100); // Wait 1/10 second
low(21);
low(18);
high (19);
high (20); // Set P26 I/O pin low
pause(200);
high (21);
high (22); // Wait another 1/10 second
}
}
Token, type (code) in the line above your code and (/code) in the line below your code. This will format your code so it's easy for people to read.
Use [] instead of ()., like this:
some code
some more code
even more code
blah blah blah
That BIN file is Propeller code that's ready to run.
With post 27, thats the thing, I can't even follow those instructions, I do not know how to execute that burn. I've been pouring over this thread and google as I wasn't sure how asking here would be received. I open PropellerIDE, go to open, the goon file does not show in the folder because its looking for a spin file, go to all files, it won't load a bin. Tried to use Daemon to convert the bin/extract it into something useful. I went to the hardware hacking village and it looked like most people were trying to crack the IR challenge, I didn't want to bug them with such a novice situation.
Propeller code is generally open source, so it never really occurred to me to add a binary programming button. I wouldn't "just burn" someone's random badge binary on my badge at DEFCON ;-) Gee, there were reports of dongles on the ATM machine a few years ago when I went.
The PropellerIDE has a p1load program that can be used from a Terminal command line. The p1load program is added to various PropellerIDE packages in these folders:
For help enter "p1load -?" or some unrecognized parameter like -h.
sh-3.1$ ./p1load -?
p2load - a loader for the propeller 2 - version 0.008, 2013-04-23
usage: p2load
[ -b baud ] baud rate (default is 115200)
[ -p port ] serial port (default is to auto-detect the port)
[ -e ] write a bootable image to EEPROM
[ -P ] list available serial ports
[ -r ] run the program after loading
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] verbose output
[ -? ] display a usage message and exit
file[,addr]... files to load
sh-3.1$
Propeller code is generally open source, so it never really occurred to me to add a binary programming button. I wouldn't "just burn" someone's random badge binary on my badge at DEFCON ;-) Gee, there were reports of dongles on the ATM machine a few years ago when I went.
The PropellerIDE has a p1load program that can be used from a Terminal command line. The p1load program is added to various PropellerIDE packages in these folders:
For help enter "p1load -?" or some unrecognized parameter like -h.
sh-3.1$ ./p1load -?
p2load - a loader for the propeller 2 - version 0.008, 2013-04-23
usage: p2load
[ -b baud ] baud rate (default is 115200)
[ -p port ] serial port (default is to auto-detect the port)
[ -e ] write a bootable image to EEPROM
[ -P ] list available serial ports
[ -r ] run the program after loading
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
[ -v ] verbose output
[ -? ] display a usage message and exit
file[,addr]... files to load
sh-3.1$
Hmmm... Looks like I should fix the help text for p1load since it claims to be called p2load and to work only with the P2. Where is the source for this checked in?
Hmmm... Looks like I should fix the help text for p1load since it claims to be called p2load and to work only with the P2. Where is the source for this checked in?
For all of you who are still waiting on the official source release, here's my recovery of the source, which produces, byte-for-byte, the full Human EEPROM when compiled in Propeller Tool.
Aside from the variable and function names, this should be identical to what Ken will be releasing shortly.
For all of you who are still waiting on the official source release, here's my recovery of the source, which produces, byte-for-byte, the full Human EEPROM when compiled in Propeller Tool.
Aside from the variable and function names, this should be identical to what Ken will be releasing shortly.
OK, it's time for the official release then! Looks like P120ph37 (don't these DEFCON attendees have the most encrypted forum names you've ever seen?) may have already read it, byte for byte.
I'll modify the first post in this thread to include the entire DEFCON 22 badge source code, so take a look!
Thanks, Ken! Excited to check out how the "official" badge did IR TX/RX; @joshcano and I hacked together a laser tag game last night and had to guess at some of the timing.
Huge shout-out to Parallax and J0nnyMac for sponsoring the badge and helping introduce us all to Propeller!
Thanks, Ken! Excited to check out how the "official" badge did IR TX/RX; @joshcano and I hacked together a laser tag game last night and had to guess at some of the timing.
Huge shout-out to Parallax and J0nnyMac for sponsoring the badge and helping introduce us all to Propeller!
/m
Thank you, mrisher. I imagine the IR tx/rx objects and their use were constructed as efficiently as possible. JonnyMac has used the same code base for an application equally demanding as what you describe for laser tag.
The video is it in "Party Mode"[tm]. Few seconds of animation, few seconds of automatic game-play.
"Party-mode" was designed to get people engaged in conversation. Once they said "Hi" I handed them the remote control and let them play. At times I was in a crowd 30-40 people deep.
Many, MANY people thought the frame hid another computer so wanted to see "behind the curtain". Then I told them the prop could natively drive VGA and composite monitors.
I used the bytecode disassembler from AiChip as a starting point (along with some manual disassembly based on the bytecode definition document). It had code alignment issues, but it helped a lot.
Then I did some educated-guessing to compose spin code that might produce the expected bytecodes, followed by a lot of recompiling and diffing.
Does anyone here know anything about the Impostor badge? I saw it once - it was basically the same as the others, but violet LEDs and all of the silk screening was riffing on the official version. E.g. Instead of "The Dark Tangent" it said "The Light Arc", and instead of "Do Not", it said "Always". The violet LEDs were running in PWM mode.
Does anyone here know anything about the Impostor badge? I saw it once - it was basically the same as the others, but violet LEDs and all of the silk screening was riffing on the official version. E.g. Instead of "The Dark Tangent" it said "The Light Arc", and instead of "Do Not", it said "Always". The violet LEDs were running in PWM mode.
Ah, yes, I have to admit that I know something about this badge. While we were in design for the badges Daniel decided to spin his own "Always Obey" badge using the purple PCB process from OSH Park. - Ken
I have updated the first post in this thread to include a proper schematic and badge layout PDF. Until now, it seems we were posting files from an older revision.
I'm responsible for the badge hack that turned it into a quadcopter.
visit http://meat.damnit.us/dc22 for the sourcecode (defcon_quad.tar.gz) and some build pics. There are some videos at and
Here's most of the README file from the source code archive:
Compile and load 'meat.spin' to your badge to turn it into a quad.
It has been colloquially referred to as the "Shitty Hawk" - first in DEF*CON
flight - brought to you by "the wrong brothers" - myself (loather), cannibal,
and beermonkey.
Parts needed:
a DEF*CON 22 badge
an InvenSense MPU-6050 3-axis gyro/3-axis accelerometer
other parts to put together a quadcopter
It works in X-mode only. All values are currently hard-coded. It was written
in a day.
There are no provisions to correct for gyroscopic precession. Only the gyro
is used.
The flight controls are ... cumbersome and difficult. It barely flies.
Danger: it is *always* armed.
kudos go out to cannibal and beermonkey for helping
out with the set-up, testing, coding, and looking over my shoulder to make
sure i didn't do anything completely stupid.
thanks to linky for the use of his o-scope.
and most of all, thanks to my girlfriend, imaginaryfiend, for giving me
the idea in the first place and putting up with absolutely everything in our
hotel room getting prop rash on it.
oh yeah, all the objects outside meat.spin included in the sourcecode archive are downloaded from the intarwebz - most of them from object exchange here.
apparently my post from last night didn't show up.
Anyways, I'm the one responsible for the flying badge, a.k.a. the "Sh1tty Hawk" - first in DEF*CON flight. Brought to you by the Wrong Brothers; loather, cannibal, and beermonkey.
I've dropped a bunch of stuff onto http://meat.damnit.us/dc22 - this includes some build photos, the source code, etc. - it's a work in progress and I'll be likely updating it more and more. No schematics just yet.
Here's the README inside defcon_quad.tar.gz:
This is the source code for the DEF*CON 22 Badge Quadcopter that we hacked
together.
Compile and load 'meat.spin' to your badge to turn it into a quad.
Parts needed:
a DEF*CON 22 badge
an InvenSense MPU-6050 3-axis gyro/3-axis accelerometer
other parts to put together a quadcopter
It works in X-mode only. All values are currently hard-coded. It was written
in a day.
There are no provisions to correct for gyroscopic precession. Only the gyro
is used.
The flight controls are ... cumbersome and difficult. It barely flies.
Danger: it is *always* armed.
kudos go out to cannibal and beermonkey for helping
out with the set-up, testing, coding, and looking over my shoulder to make
sure i didn't do anything completely stupid.
thanks to linky for the use of his o-scope.
and most of all, thanks to my girlfriend, imaginaryfiend, for giving me
the idea in the first place and putting up with absolutely everything in our
hotel room getting prop rash on it.
This is very very awesome, as I said before - epic. Congratulations.
I'm not surprised you found SPIN strange to start with coming from the ARM world.
It is a different mindset but once you get your head around the propeller architecture and the different way of doing things it's actually a lot easier. If you get a chance to look at propeller ASM I would recommend it - it's one of the cleanest and consistent languages I've used.
I hope you stay around - welcome to our community! - I wish I'd gotten a chance to see your creation in person!
This is an AMMAZING example of the ease of use and flexibilty of the platform produced. Here we have a smart guy with zero exposure to the IC or the platform and he's built this in 24 hours.
Yeah. Coming from ARM and AVR where interrupts rule supreme and ADCs and I2C peripherals are built-in (among other things), having to think differently about how to do things was neat. I figured without a programmable interrupt controller I'd have to do a lot of polling and dedicate a cog to it - fortunately there's a lot of good library functions out there to do a good deal of what I wanted to do. It made it a lot easier.
Spin is kind of like ... an object-oriented amalgamation of assembly and a procedural language that takes hints from fortran and cobol (what with the declarative sections and whatnot). The operators and literals take some getting used to, but just like any language, the more use you give it, the more useful it becomes
Once I get a better grasp on the architecture (ie. spending more than 30 minutes looking at the datasheet to figure out how it worked ), especially the interactions between cog and hub, I'll look further into the assembly language. At first glance a lot of it looks fairly similar to other assembly, but to be honest the time I've spent looking at it was to read through some of the modules I downloaded to figure out if they'd do what I needed them to do.
In any case, I'm not taking this one apart. These bits & pieces are going to remain on the quadcopter and probably come next year too. Or if you're in San Diego for toorcon in a couple months I'll bring it and we can meet up or something. I'm glad you enjoyed it
Many, MANY people thought the frame hid another computer so wanted to see "behind the curtain". Then I told them the prop could natively drive VGA and composite monitors.
Minds were blown.
So I'm not alone! Video capability was what first blew my mind about the Propeller.
BTW, with the abundance of inexpensive composite screens (Chinese "Car RearView LCD Monitor" that Dr. Acula popularized here) the Prop's video capability is as relevant as ever.
Comments
Using simpleIDE is what nuked my original firmware, and I loaded something simple to restore LED functions, simpleIDE did not except the human code. Using PropellerIDE I do not get any faults loading, but the LEDs do not work. For the goon firmware, I tried to use Daemon to convert the bin- I'm trying to learn googling around, but I'm getting no where.
Go back to post #27 of this thread and follow the directions to load the goon firmware image to eeprom. (someone at the hardware hacking table is likely to have a human image as well) That will get you a functioning badge. You probably just accidentally did a load to eeprom while experimenting instead of a load to ram. You might consider installing a switch to control the write-protect pin of the eeprom to avoid mistakes in the future?
Marty
Right, the first thing I did was load SimpleIDE and accidentally used the burn to EEPROM vs. the burn to RAM button- even after reading the readme file on the defcon disk mentioning f10 and the ram option to protect the firmware. I spent three hours messing around with the provided code from the defcon CD and ultimately gave up, loaded an example code from the SimpleIDE library, change the code to the pin numbers listed in the defcon provided code and got my LEDs to do a custom routine, but lost all of the other badge features of course.
With post 27, thats the thing, I can't even follow those instructions, I do not know how to execute that burn. I've been pouring over this thread and google as I wasn't sure how asking here would be received. I open PropellerIDE, go to open, the goon file does not show in the folder because its looking for a spin file, go to all files, it won't load a bin. Tried to use Daemon to convert the bin/extract it into something useful. I went to the hardware hacking village and it looked like most people were trying to crack the IR challenge, I didn't want to bug them with such a novice situation.
Its burned into my EEPROM not to make that mistake again lol.
Use [] instead of ()., like this:
That BIN file is Propeller code that's ready to run.
Propeller code is generally open source, so it never really occurred to me to add a binary programming button. I wouldn't "just burn" someone's random badge binary on my badge at DEFCON ;-) Gee, there were reports of dongles on the ATM machine a few years ago when I went.
The PropellerIDE has a p1load program that can be used from a Terminal command line. The p1load program is added to various PropellerIDE packages in these folders:
Linux: /opt/propelleride/bin/p1load
Mac: /Applications/PropellerIDE.app/Contents/MacOS/p1load
Windows: C:\Program FIles (x86)\PropellerIDE\p1load.exe
For help enter "p1load -?" or some unrecognized parameter like -h.
However, Jon, 1o57 and Parallax will be posting full sources within a day or so so I'd encourage you to use that instead as it's official.
That, and I don't have a badge to test on anymore so you'd be flashing something I wouldn't be able to test over and above the checksum.
The code is in the repository at easyside.googlecode.com under loader. It's just a copy of your repository.
https://code.google.com/p/easyside/source/browse/?name=loader#hg%2Floader
p1load.zip
Aside from the variable and function names, this should be identical to what Ken will be releasing shortly.
http://git.io/JxQtSg
OK, it's time for the official release then! Looks like P120ph37 (don't these DEFCON attendees have the most encrypted forum names you've ever seen?) may have already read it, byte for byte.
I'll modify the first post in this thread to include the entire DEFCON 22 badge source code, so take a look!
Ken Gracey
Huge shout-out to Parallax and J0nnyMac for sponsoring the badge and helping introduce us all to Propeller!
/m
Thank you, mrisher. I imagine the IR tx/rx objects and their use were constructed as efficiently as possible. JonnyMac has used the same code base for an application equally demanding as what you describe for laser tag.
Ken Gracey
The video is it in "Party Mode"[tm]. Few seconds of animation, few seconds of automatic game-play.
"Party-mode" was designed to get people engaged in conversation. Once they said "Hi" I handed them the remote control and let them play. At times I was in a crowd 30-40 people deep.
Many, MANY people thought the frame hid another computer so wanted to see "behind the curtain". Then I told them the prop could natively drive VGA and composite monitors.
Minds were blown.
I used the bytecode disassembler from AiChip as a starting point (along with some manual disassembly based on the bytecode definition document). It had code alignment issues, but it helped a lot.
Then I did some educated-guessing to compose spin code that might produce the expected bytecodes, followed by a lot of recompiling and diffing.
Ah, yes, I have to admit that I know something about this badge. While we were in design for the badges Daniel decided to spin his own "Always Obey" badge using the purple PCB process from OSH Park. - Ken
Thanks, Ken Gracey
visit http://meat.damnit.us/dc22 for the sourcecode (defcon_quad.tar.gz) and some build pics. There are some videos at and
Here's most of the README file from the source code archive:
Compile and load 'meat.spin' to your badge to turn it into a quad.
It has been colloquially referred to as the "Shitty Hawk" - first in DEF*CON
flight - brought to you by "the wrong brothers" - myself (loather), cannibal,
and beermonkey.
Parts needed:
a DEF*CON 22 badge
an InvenSense MPU-6050 3-axis gyro/3-axis accelerometer
other parts to put together a quadcopter
It works in X-mode only. All values are currently hard-coded. It was written
in a day.
There are no provisions to correct for gyroscopic precession. Only the gyro
is used.
The flight controls are ... cumbersome and difficult. It barely flies.
Danger: it is *always* armed.
kudos go out to cannibal and beermonkey for helping
out with the set-up, testing, coding, and looking over my shoulder to make
sure i didn't do anything completely stupid.
thanks to linky for the use of his o-scope.
and most of all, thanks to my girlfriend, imaginaryfiend, for giving me
the idea in the first place and putting up with absolutely everything in our
hotel room getting prop rash on it.
@ultimateloather on twitter.
Anyways, I'm the one responsible for the flying badge, a.k.a. the "Sh1tty Hawk" - first in DEF*CON flight. Brought to you by the Wrong Brothers; loather, cannibal, and beermonkey.
I've dropped a bunch of stuff onto http://meat.damnit.us/dc22 - this includes some build photos, the source code, etc. - it's a work in progress and I'll be likely updating it more and more. No schematics just yet.
Here's the README inside defcon_quad.tar.gz:
This is the source code for the DEF*CON 22 Badge Quadcopter that we hacked
together.
Compile and load 'meat.spin' to your badge to turn it into a quad.
Parts needed:
a DEF*CON 22 badge
an InvenSense MPU-6050 3-axis gyro/3-axis accelerometer
other parts to put together a quadcopter
It works in X-mode only. All values are currently hard-coded. It was written
in a day.
There are no provisions to correct for gyroscopic precession. Only the gyro
is used.
The flight controls are ... cumbersome and difficult. It barely flies.
Danger: it is *always* armed.
kudos go out to cannibal and beermonkey for helping
out with the set-up, testing, coding, and looking over my shoulder to make
sure i didn't do anything completely stupid.
thanks to linky for the use of his o-scope.
and most of all, thanks to my girlfriend, imaginaryfiend, for giving me
the idea in the first place and putting up with absolutely everything in our
hotel room getting prop rash on it.
@ultimateloather on twitter.
I'm not surprised you found SPIN strange to start with coming from the ARM world.
It is a different mindset but once you get your head around the propeller architecture and the different way of doing things it's actually a lot easier. If you get a chance to look at propeller ASM I would recommend it - it's one of the cleanest and consistent languages I've used.
I hope you stay around - welcome to our community! - I wish I'd gotten a chance to see your creation in person!
This is an AMMAZING example of the ease of use and flexibilty of the platform produced. Here we have a smart guy with zero exposure to the IC or the platform and he's built this in 24 hours.
__red__
Spin is kind of like ... an object-oriented amalgamation of assembly and a procedural language that takes hints from fortran and cobol (what with the declarative sections and whatnot). The operators and literals take some getting used to, but just like any language, the more use you give it, the more useful it becomes
Once I get a better grasp on the architecture (ie. spending more than 30 minutes looking at the datasheet to figure out how it worked ), especially the interactions between cog and hub, I'll look further into the assembly language. At first glance a lot of it looks fairly similar to other assembly, but to be honest the time I've spent looking at it was to read through some of the modules I downloaded to figure out if they'd do what I needed them to do.
In any case, I'm not taking this one apart. These bits & pieces are going to remain on the quadcopter and probably come next year too. Or if you're in San Diego for toorcon in a couple months I'll bring it and we can meet up or something. I'm glad you enjoyed it
So I'm not alone! Video capability was what first blew my mind about the Propeller.
BTW, with the abundance of inexpensive composite screens (Chinese "Car RearView LCD Monitor" that Dr. Acula popularized here) the Prop's video capability is as relevant as ever.