• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About avockley

  • Rank
    MIDIbox Newbie
  1. Communication between multiple PIC cores

    A single LPC17 core was my initial thought, but I wasn't sure how to control so many devices with it. The problem is that each synth board will end up with something like 15 IIC-controlled digipots/switches/dacs and there just aren't that many IIC ports on the core. I suppose the best option would be to bit bang IIC on other pins on the core.   And I just discovered IIC bus hubs (TI PCA9518). I think I may have my solution. 
  2. First, a bit of background on the project. It's an analog synth that will have a control surface similar to the one on the Moog Little Phatty. It will be a few encoders with a bunch of buttons to select the function each will perform. These are on the master core, with that core communicating with a slave core on each monophonic synth board. Each of these slave cores with forward the commands on to a series of digital pots and switch to control the synth.   The issue I'm having right now is how the master core will send data to the slave cores. I'm trying to decide whether to use MIDI or IIC (or maybe mbNet?). The issue with MIDI is that the digipots are 8 or 10 bits each, so the 7 bit per packet restriction could cause some problems. I think IIC would be a good option, but I'm not really sure how receiving on the slaves would work.. Sending the data from the master core should be easy enough, with the built-in MIOS_IIC_ByteSend function, but I don't believe the built-in functions will work for receiving on the slaves. MBNet seems like it was designed for exactly this purpose, but as far as I can tell, it doesn't exist for MIOS8, and I'd rather not use a bunch of LPC1769 cores since they're overkill and quite a bit more expensive.   Any thoughts, or should I just stick to trying to make MIDI work?
  3. I actually already found that option. I have it enabled, but It doesn't seem to fix any of my issues. Edit: And I've just figured it out. I missed the "all ones" address in uip.c. The broadcast address this protocol uses is I think that is the issue.
  4. The issue with using uip_udp_bind is that it requires that I know the ip address of the remote peer before running the app. My app gets the remote ip address from data in a broadcast packet, and also (if I follow all specs) should be able to receive from multiple ip addresses on the same local port. The second part isn't really important, but I would have to bind to a port to get the ip address to set up the port binding..... which obviously won't work. Is my best option to try rewriting parts of uip.c? Edit: And as I just realized, the point of using broadcast in this particular protocol is so that my device doesn't need to know anything about the network it is on. It just gets all the data and sorts out what it needs. I don't want to have to give it the ip of the remote device. The remote ip may not even be available always, as this protocol is designed to work on a closed LAN without any computers, only embedded devices.
  5. I assume you mean that I should use uip_listen(port). I tried that and it had no effect. I'm not sure, but I think that might only be for TCP, and not UDP. Is there a different function for UDP that I missed?
  6. I have an application on my computer that is both broadcasting and unicasting udp. Anything that it sends to a unicast IP is picked up correctly by the app running on my LPC core. The issue is that anything that is sent to the broadcast address on the network is not being received. I have a debug messasge at the first level of the UIP_TASK_UIP_AppCall function that should show all incoming data, and only the unicast packets make it that far. The strange thing is that all incoming packets, unicast and broadcast, cause the activity light on the lpcxpresso to blink. Is there something I have to do to enable uIP to receive broadcast UDP, or is there some other issue on my network or computer?
  7. The uip_task_standard files needed some modifications so that they would work for my purposes, mainly a branch in the udp appcall, so that I could handle the data coming to my app. I thought including them in the sources was enough to make the compiler recognize them. BTW I did intend to change the copyright back to the original once I realized that only very minor modifications needed to be made. I just hadn't gotten around to it when I posted.
  8. Here's the entire source directory and all the build files. And here's the compiler log ArtNet Node.zip
  9. I just figured out the problem, and as I suspected, it was a simple fix. I hadn't added the new source files to the THUMB_SOURCE variable in the makefile.
  10. I'm getting the same undefined reference error with a new piece of code. This is a new file, with 2 functions, its .h file is included in the app.c, and the error is now happening on those functions. I'm not seeing the files that are causing errors being compiled anywhere, and the .o files are missing from the build directory. Is there an include missing somewhere? What's going on here? Edit: As a matter of fact, only 4 of the 9 sets of .c/.h files are showing up as .o/.d files in the build directory.
  11. That app compiles correctly.
  12. I have already included my own uip_task.h file in the code that's giving me problems. I am going to modify some of the functions, so I need a local copy in my source folder. Even with both #include "uip_task.h" and #include <uip_task.h>, the compile still fails.
  13. Something else that I realized. The compile error I'm getting is not the one as if the functions are undeclared. I'm not getting the "implicit declaration of function" error, but the "undefined reference" error. I don't know what this means... Just thought I'd mention it.
  14. I am having an issue with accessing functions in 1 source file from multiple other source files. I have included my entire source directory, as I'm not really sure where the error is. The function I want to call are in uip_task.c, and they are called from both terminal.c and presets.c. The functions are called properly from terminal.c, but not from presets.c. I have included the compile log below. The first warning happens even with the tutorials, but doesn't seem to be causing any problems. The errors at the end are the problem that I'm having. I'm guessing it's an issue with an include somewhere, but as far as I can tell, it's all seems correct.
  15. Using uIP to receive UDP packets

    That was actually the one I was looking at earlier, but I don't know how to get a raw UDP packet. I believe that the OSC code calls the APP_MIDI_Notify_Package function after receiving data, but my app will not be receiving OSC data. I want to get the raw data inside the UDP packet so that I can parse it myself.