|
I just got a job doing embedded code with a dspic and I am really interested in doing things the right way instead of just doing them. My work involves signal processing, serial communication, and a host of digital outputs--I know how to do all of these things one-at-a-time but I am worried about getting them all to take turns nicely. Does anyone know of a good resource (free or paid) that could help me think about this in a constructive way? I think I need to develop an interrupt-driven scheme to keep everything working when individual modules take too much time, but its tricky to tell which parts should be interrupts and which should be in the main loop. For what it's worth, I'm using MPLAB X and programming in C. Most of the resources I have found are either too basic or they use assembly and it takes too much mental effort to translate that to C.
|
#
¿
Sep 5, 2013 19:19
|
|
|
|
| # ¿ Jun 2, 2024 23:07 |
|
|
Delta-Wye posted:Any reason you couldn't just knock out an easy dev board of your own? If you're willing to program the bare processors, you don't need a whole lot of parts and then you can make the footprint whatever you want. Should be trivial to beat the $30 mark too. This is probably the best answer. Get a breakout/protoboard to make it easier to deal with tiny pins and then go to town adding only the stuff you need.
|
|
#
¿
Oct 17, 2013 02:47
|
|
|
Do you all think it is possible to reprogram a microcontroller over a serial bus with one master and multiple slaves? The application is basically an accessible master node and a bunch of physically inaccessible slave nodes. When it comes time for a firmware update, it would be awesome if I could reprogram the slave nodes from the master node's bus connection (or even just using the master node). But this is a really weird thing to do and I can't find any information about it on the internet. In this situation, all nodes would be reprogrammed with the exact same firmware, so it would be totally okay if the reprogramming worked globally.
|
|
#
¿
Oct 31, 2013 18:35
|
|
|
Its a design choice that I haven't really made yet, but I was thinking about RS485 because it seems appropriate for the application. Communication will only be initiated by the master and it will address slaves individually, although I am toying with the idea of a broadcast address that directs all slave nodes at once (and obviously doesn't expect a response to maintain a collision free bus). The latter method would be an easy way to reprogram everybody at once. I think I am at an impasse because I don't really know how the actual hardware portion of microcontroller programming works, and I'm not sure how hard it would be to create a device that programs microcontrollers (or itself). I suppose I will read up on it. Sorry about being vague, but the network and controllers are t.b.d based on this inquiry, and I also had to sign an NDA :/
|
|
#
¿
Oct 31, 2013 20:33
|
|
|
Do any of y'all program microcontrollers with a linux toolchain? There are so many huge, proprietary IDEs out there that it seems like it might be hard to do, but I would love it if I could slim down the development process to just gedit and a makefile. I just tried this out with a Maple this morning, but it hasn't been altogether successful.
|
|
#
¿
Nov 14, 2013 19:37
|
|
|
JawnV6 posted:I'd be very curious how you plan to debug anything nontrivial with that setup though. Debugging in an IDE with breakpoints and awareness of your code will take a fraction of the time compared to debugging with LED's providing bits of information about what's going on inside. I've never used any of that stuff so it is all just bloat to me. Maybe I have never encountered a nontrivial bug?
|
|
#
¿
Nov 15, 2013 00:52
|
|
|
JawnV6 posted:I had a +5V rail drooping that was causing the ADC reading referenced against another plane to come back a little goofy. Of course, it didn't manifest in any sensible way the device just kicked into the next stage of operation. The ADC reading wasn't the only possible transition, it wasn't 100% fail, etc., so it took some onion-peeling to root-cause it. I tried to do some register-/memory-peeking stuff with MPLab X and it was really cumbersome and counter-intuitive so I ended up writing my own thing that dumped what I cared about to the serial bus CSV-style every time it was modified so that I could put it in matlab and do weird stuff to it on my own. Judging by the discussions on microchip's forums, I think MPLab X is just a really bad IDE so maybe the other ones aren't so bloated-yet-unhelpful. I'm sorry for constantly posting dumb stuff in this thread about my noob idiot part-time embedded coding internship, but the main reason I post whenever any dumb thing comes to mind is because it seems like this thread is often dangerously close to falling off into the archives and I like it a lot and want it to stay alive.
|
|
#
¿
Nov 15, 2013 20:03
|
|
|
Why don't you just use the right pin?
|
|
#
¿
Feb 20, 2014 14:33
|
|
|
I impulse bought a couple Photons a while back and they just came in. I didn't do enough background research and it turns out these things are a huge pain in the rear end to develop on. The particle team has "disrupted" the poo poo out of embedded dev by making every interaction with the photon have like 4 different middle men ~in the cloud~ Flashing the LED blink script to my Photon doesn't make it flash its LED, it just puts it in safe mode for some reason. Have any of y'all had better luck with these things?
|
|
#
¿
Aug 30, 2015 14:20
|
|
|
Patterson and Hennesey is the standard for computer architecture 101, so the negative reviews are probably just sad undergrads. I would definitely recommend it. It has tons of really good information and it is one of maybe 4 textbooks I used in undergrad that I was actually really excited to read.
|
|
#
¿
Apr 10, 2016 06:37
|
|
|
Ha! Yeah, I was talking about "Computer Organization and Design". I don't know anything about that other book.
|
|
#
¿
Apr 10, 2016 19:04
|
|
|
|
| # ¿ Jun 2, 2024 23:07 |
|
|
Use the verbose flag when you SSH. I had this problem at work and it turned out that SSH was trying like 200 ways to authenticate and THEN trying the one that works. You can set arguments to disable some of the types you aren't using. Edit: Sorry I left out a step. Use the verbose flag and then google the line that it slows down on. That'll show you what you need to disable.
|
|
#
¿
Oct 9, 2016 21:42
|
|