Lately I've seen many 1D pong projects passing by, so I decided to make my own version.
Not just being a copycat, I really had to add a bit of extra mustard. In this case an entire TCP/IP stack! This results in a network connected 1D Pong game, in which you can have as many nodes (players) as you would like.
It was another fun experience... writing a driver for the WS2812, getting our stack integrated on these wifi boards (you can't just make your own wifi driver because Microchip doesn't even provide a decent data sheet for the wifi chips), designing a UDP protocol, learning that decentralized behaviour is really not that easy...
I managed to get the firmware to compile with the USB funzies from Microchip. But it's not working just yet. I believe that the usb_descriptors.c file needs some changes here and there... But I cannot find anything about it in the repositories.
I'd like to get the BACKLIGHT_BRIGHTNESS implemented.
Since text is quite boring, here are some pictures!
I've been using this LCD for a week now at work, and it makes receiving emails nicer :-) Now I should still get it to work with LCDproc. That should provide for a lot more flexibility!
Seed was offering their 10$ coupon, so I couldn't let that one go! I got the design from this website, and sent it to them! The articly is quite boring, but it was a quick writeup. I'll add some pictures of the functional board later! But for now, you'll have to do it with text :-)
PS: the firmware could use some work... would be nice if it would have a serial buffer, and not just overflow!
Well, I'm actually working on that first option :-) Still waiting for the new pic to arrive + I have ordered a breakout board, since bigger flash pics in the 24F series are only available in SMT.
I can only use optimisation level 1. All the others aren't available in the free edition. I could try the trial edition, but I don't see entirely how that could help me out :)
I am porting the stack from a fully blown 32bit linux system. People are developing on that platform now, because it's the one that is available. That leaves me with all the fun stuff when porting to a 16bit system with very limited resources.
Maybe some more info: I have a saleae 16 channel logic analyzer, how could I use that one without simply changing one pin per time, and go to the next point I want to check?
I'm getting desparate! I'm trying to port a TCP/IP stack (under development by others) to a PIC24FJ64GA002. For some reason, the thing is resetting all the time! Because the stack is too big to flash without optimization, I had to turn optimization on. And that makes debugging the thing even harder.
Could anyone please advise me on how to proceed? Breakpoints on stack under/overflow aren't possible with this model, and that would be my best guess. Or otherwise a null pointer is used somewhere. Can I somehow catch these errors? And can I report where they came from?
So far, I have tried setting breakpoints, but once I start debugging, it seems that the code is behaving entirely different. It doesn't even arrive at a breakpoint it should. So I reverted to sending stuff over UART to the PC (1 byte codes). But the compiler is moving those instructions around, and it seems that the behaviour isn't the same all the time.
sigh, this is a nasty bug. I'd appreciate any suggestions!
For our master's thesis at Group T Engineering College (Leuven - Belgium), we made a system that combines a laser, a 3D camera and a computer. For more information, I'm going to send you off to my website :-)
Same here, I canceled compilation because I needed the processing power :-) I don't quite understand why it's taking so long. Putting all the stuff in the right memory locations shouldn't be too hard...
../WORLDcodes.h:3975: error: could not find space (138 bytes) for variable _EUpowerCodes ../WORLDcodes.h:3975: warning: object "_EUpowerCodes" lies outside available data space
Memory is full :-) I'll see how many extra we could add...
I'm letting it run for the 1822 now. You never know that compiler does some crazy stuff :-)
After lunch I'll get it compiling with more codes. We could try to use the trial version of the XC8 compiler. It should enable optimization and reduce things somewhat more. But nevertheless, the codes should still be stored. and you can't optimize that away!
Oh, I checked again! It seems it compiled just fine now :-) I just imported the project into MPlab X. It did take quite some time. According to the stats, it consumes 82% of the flash and 9% of the RAM. Let me see what it does when I select the 12F1822 :)
[quote author="ian"] That's some skills there, I'd never be able to do that, even with hot air tools. I always melt the casing :) [/quote]
If I remeber correctly, I heated the back side of the pcb until the solder on the other side started to melt. A couple of taps later, it just fell off. The biggest problem I have, is that I simply can't get the damn solder to get off of the pins.
Quote
Sounds like there is a short on one of the pins used for the LCD and it tanks the power. When the firmware runs it sets pins certain ways (especially the transistor for example) that are not used in the bootloader. I would look for a short and remove T1 temporarily.
I was guessing something like that. Let the debugging fun begin!
Quote
Only on the PC side. Sometimes through 1M resistor and a capacitor, but usually just not connected on device side.
After I wrote this, I was thinking about classes I had; One of them mentioned that you should only connect shielding on one side. Nevertheless, I have used the casing to connect to the Ground line. I hate those mini-usb connectors in SMD. They're worse to solder than an FT232RL (which is in fact not that hard). The solder always sneaks up the pins, and solder wick also has a hard time getting the stuff out of there.
Quote
Shorts are never really great, and don't help with debugging :)
Yeah, I can see why :-) Now I still have to figure out a way how to get that short gone. I've tried a shitload of flux together with solder wick, bus it doesn't seem to come off. another trick is to add more solder, but I'm just afraid it will make things worse.
