insensitiveclod
commented
11 years ago You can reach me, directly, via contact@sociallife.org if you'd like. That's perhaps easier than communicating via github issues. But I will reply to the 'mail' here for now ;)
The reason i would like to do it without bluetooth but with some technique (like sound) is that it keeps it all a lot cheaper and easier to connect (no bluetooth-synching blabla). But bluetooth is certainly usable. It will cost a bit more battery.
I would like to have PCB's to work on testing your/my code and any additions, myself. I can etch single-sided stuff myself, but double-sided SMD is just too much work to etch. If you have PCB's spare that i can get/buy/trade, that would be great!
I have the tools and the materials (SMD resistors, atmega32au's, etc) to put parts on the PCB's; this shouldnt be too much of a problem.
I personally havent tried Eclipse ; i use vim/gedit/etc.. but i will try it out!
I will check the global_variables issue myself a bit closer, first. No worries :)
About IFDEFs; i'll try some stuff out and see if it will work and show you to see if you like it ;)
I see the 644 also uses TQFP44 package; is it drop-in replacement or do you need new PCB ? Why not Atmega2560 and have enough I/O ports for... well... anything ;) (ok... TQFP100 is not nice to solder... I know the reason ;)
Also: I contacted the guy who wrote the code in i2c_eeprom on his nagits.wordpress.com forum and asked him about the copyright. He replied that it is public domain; so I will add his name to the comments there and also the license (public domain). I will do that in a couple of days time; the weather here is GREAT and my garden needs some work, first ;)
Hope your summer is also starting nice ;)
Arnd
PingvinOpenTag
I saw that, yes! Very interesting indeed! Personally, I'm thinking of adding a way to communicate to a smart-phone (via Bluetooth or perhaps via audio (http://www.slideshare.net/Sudar/transfering-data-using-audio-signal-in-android) to send 'scoring' info to the phone which can then send the info about 'where is player' 'how much did he shoot' 'who hit him', etc. to a central server. This central server would allow later game-replay and, of course, total scores, etc. Some of the code for that was already written/designed by the London Hackerspace. Perhaps I can re-use some of that.
Yes! I want this! Let's do it! Transmit data over Bluetooth - no problem! Just have to play with a wire headband. You can also make all the settings from smatphone.
That would be wonderful! Let me know prices, etc... and i'll buy enough for 3 - 4 sets
No price! What the bourgeois manners? :-))
You just printed circuit boards? You will be able to solder the device?
I would of course appreciate that; but I think I will ask you to 'pull' files from my fork into your repository first so you can test the changes and see i didnt break anything. Also, I only worked on the 3.1 version; none of the other directories have been touched by me. I am thinking about what is best: make a 'main' code-segment and a 'branch' for each 'hardware release' or so... Or support different hardware-releases via IFDEF's in code. Of course 'my' release 3.1 can be used for further development of '3.2+' or '4.0... etc' but it has to be properly tested first. If you have time, could you compile it in your WINAVR and see if everything works well on your hardware ? It compiles well here in my AVR-GCC on Linux; but I cannot test if the project works correctly. NOTE: i have also translated the 'texts' in 'commands.h' to english. I am not sure, but I think this will work because your USART-protocol uses the labels , which I did not change, right ? Would be interesting to see how well/bad that works on your side ;) The next things I will start doing is to work on some things i found in the code that I marked with 'FIXME'. Then I will do code-cleanup. - Add descriptions of all the functions/etc and get rid of double declarations. I believe 'global_variables.c' is corrently not used? Do you want to move all global variable definitions TO that file ? or have you just gotten rid of the file ? ;) Let me know , perhaps I can help with that. - I will try and make all the code 'look nice'; I intend to do 4-space TAB-width and get all the functions properly indented. Then I will start on translation of LCDTEXT messages; probably by creating a 'lcd_texts.h' file that contains DEFINES for all the texts for on the display, with IFDEF LANG=RU, IFDEF LANG=EN... etc.. to choose between languages at compile-time. Does this sound like a good way to do it ? If you have any preferred direction you want to go first, let me know; perhaps I can help with that. Any ideas about what i can do are welcome. Let me know if or when you could try out my fork and see if it works well; that will help me be confident that I did my work well. Will let you know of my progress! Till soon
I will compile your version and give the video report! Under Linux I have tried Eсlipse and AVR-plugin - it works, the firmware is compiled. Not quite sure about global variables (due to problems with the language, apparently). They are used. Just put them in a separate file for convenience. I also thought about using IFDEF, but little know precompiler. If you can help him to understand - will be grateful.
Still plan to switch to Atmega644 - it has an additional timer. This will generate hardware IR F0, and change the duty cycle - as Miles systems.