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.
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.