|
Victor posted:That impression is from your attitude that people must expend as much effort as you had to, in order to get going on something more powerful than an Arduino. I encounter plenty of your type: people who refuse to believe that helping people learn things in less time than it took you to learn them is a good thing. If you had to walk uphill both ways for school, your children ought to as well! It's... character-building! You specifically asked for my learning ramp and I provided it. If I'd known you'd throw this much poo poo at me as a result or so grossly mischaracterized a response to a direct question you asked, I doubt I would've been so forthcoming. You're shilling for your company, and that's great, have at it, but could you back the gently caress up off me?
|
# ? May 9, 2013 21:36 |
|
|
# ? May 11, 2024 16:40 |
|
Slanderer posted:Actually, my complaint was about people taking Arduino way too far, and not saying, "Ok, let's start naming our files *.c and *.cpp, let's use our own build process, and let's actually commit to doing a good job". As it stands, that project has been so overextended that it's an incomprehensible mess a lot of the time, and it's not rare to encounter a completely untraceable bug that causes poo poo to fall out of the sky. Due to the way they integrated a lot of libs from arduino, tracing poo poo is hard as balls. Do you know of any OSS multicopter projects with sane code? quote:I admittedly still use the Arduino at times to prototype something extremely quickly (because it's quicker than digging out an Atmega, a programmer, a breadboard, and all the components I need). I through something together in a day last year using a graphical LCD shield and an isolator that counted hi speed pulses and kept a histogram of pulse duration (I was debugging an issue with some power switchover HW here at work). It's just annoying to see people accumulating a tower of crap on top of Arduino.
|
# ? May 9, 2013 21:38 |
|
JawnV6 posted:You specifically asked for my learning ramp and I provided it. If I'd known you'd throw this much poo poo at me as a result or so grossly mischaracterized a response to a direct question you asked, I doubt I would've been so forthcoming. quote:You're shilling for your company, and that's great, have at it, but could you back the gently caress up off me?
|
# ? May 9, 2013 21:51 |
|
In the grand scheme of the "embedded systems world" I really do think Arduino is kind of like Duplo block. Sure you can do all sorts of stuff with it, but it clearly isn't the right tool for everything. I think my previous comments made it clear that I still think it has merit and is a useful product that fills a slot people clearly wanted. The fact that it is something of a Duplo block means that this stuff is available to a wide audience that otherwise would not be free to tinker. Regarding the "gap" between Arduino and more professional options - I am not really qualified to say much because I don't know the profession. I know that Arduino didn't provide the flexibility or power that I wanted, and so I ended up reading Atmel datasheets, learning some AVR C (I already knew C, but learning what all the registers are and how to use them is a bit confusing), teaching myself to use Eagle, and a whole host of other skills. With all of that, I can just barely make something functional going that route. I feel like after a while, once I know the tools and the landscape better, I will prefer that approach because it gives me more control and robustness for less cost. I am a professional software developer though, with engineering and mathematics degrees. In order to "step up" from Arduino (which I feel is a sort of construction kit/toy) to these other solutions, you really do need a lot of engineering knowledge. armorer fucked around with this message at 21:59 on May 9, 2013 |
# ? May 9, 2013 21:53 |
|
Maybe I'm not being clear enough. Consider if we made the following changes to Arduino:
armorer posted:In order to "step up" from Arduino (which I feel is a sort of construction kit/toy) to these other solutions, you really do need a lot of engineering knowledge. Part of this may be due to a huge personality difference between folks like Jawn6V and myself. I like to dig into something head-first, learning the various bits and pieces only when I need to. Oftentimes, bad software and hardware design requires you to know far more details than is theoretically required, for a given task. I wouldn't be surprised if Jawn6V doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised.
|
# ? May 9, 2013 22:07 |
|
Victor posted:Hell, the use of digitalWrite(pin, level) could have been implemented via digitalWrite<pin>(level), avoiding the insane number of cycles it takes to write to a single pin. There is a tradeoff here, and it isn't necessarily one that everyone will want to make. The writer of that blog didn't really profile anything (hard to blame him since it isn't super easy to profile code running on an Arduino), but there are several distinct things that lead to that function being as slow as it is. The runtime checking is excessive, the excessive runtime checking and several other runtime configurations are done inefficiently, some of the safety could be better provided by the type system (eg. checking they passed a valid pin), etc, but claiming that templates are The Answer is a bit naive. The Atmel chip in the larger Arduinos has what, 64ish GPIO pins? You probably don't want to duplicate even a small function 64 times if code space is tight.
|
# ? May 9, 2013 22:16 |
|
Where does the tradeoff occur, though? I doubt people will be digitalWrite-ing all 64 pins. People who are doing that should definitely be accessing the port registers directly. I definitely didn't mean to indicate that templates are the answer, in all situations. I wonder if one could turn the templated call into a trampoline to something closer to the original digitalWrite and have it inline, and then offer that as an #ifdef option between size and speed...
|
# ? May 9, 2013 22:27 |
|
Victor posted:Maybe I'm not being clear enough. Consider if we made the following changes to Arduino: There are a few points here. The first half of this seems to be about building a dev board that is essentially a better Arduino in terms of quality, which is a great goal, albeit one that is already partly and imperfectly filled by things like TI's Stellaris launchpads. The second half seems to be about building a dev board with greater capabilities than the Arduino, which is where the questionable utility resides. For instance, suppose someone wants to do serious signal processing or process control. The Atmel chip that (most) Arduinos use doesn't have the horsepower for this, and not only due to its lack of an FPU and non-astronomic clock. It might at first seem that a more powerful dev board would be useful, but hold your horses. The type of person who has these problems knows what a Fourier transform is, otherwise they wouldn't know how to implement or use one, or probably even that they should use one (for a lot of process control problems you would actually want a laplace transform, but whatever). You don't learn these things without picking up a bunch of other EE knowledge along the way, or at least relatively few people do. If you know about PID control, you probably know there are ICs that handle the PID stuff on their own that cost very little and are easy to use. If you know about signal processing, you probably know about a zillion types of micro, and about DSP chips, and you probably want control over how poo poo is laid out. This is the no-mans land that Jawn was talking about - there is demonstrably a lot of demand on the very low end, and a multibillion dollar industry on the high end, but there are good reasons to believe there isn't much demand in the middle. It's possible that this is a niche that's waiting to be filled, but the odds look to be against it. Furthermore, apologies if I sound like an rear end in a top hat or an "elitist" in saying this but it stands to reason that if this niche were to be filled competently, it would be by someone who doesn't think PCB layout is wizardry. You have a reasonably good background in programming, Victor, and you seem to have picked up on a fair amount of the math needed for control systems in your quadcopter ventures, but if you think this opportunity is real and are sure you want to do this I think you're going to have to bone up on the fundamentals of electronics engineering. I recommend The Art of Electronics if you elect to go this way. e: another point here is that PCB layout is kind of annoying, but in many contexts just isn't that hard - this is another thing that eats away at the middle end of the market as it were. Blotto Skorzany fucked around with this message at 22:34 on May 9, 2013 |
# ? May 9, 2013 22:31 |
|
Thanks for taking the time to post that, Otto. And yep, I wrote Jawn6V instead of JawnV6—sorry JawnV6.Otto Skorzeny posted:It might at first seem that a more powerful dev board would be useful, but hold your horses. quote:Furthermore, apologies if I sound like an rear end in a top hat or an "elitist" in saying this but it stands to reason that if this niche were to be filled competently, it would be by someone who doesn't think PCB layout is wizardry.
|
# ? May 9, 2013 22:52 |
|
After saying that I couldn't think of motivating uses of a 168MHZ 32-bit ARM with FPU beyond quadcopter avionics boards and IMUs, apparently contradicting my there-exists-a-niche claim, I think a stronger case can be made for offering something Arduino-like with quality libraries and a real build process, full stop. Using something more capable than an AVR makes sense because an STM32F407VG costs less than an ATmega2560. Smaller, cheaper ARM chips could be used if we want to have an alternative to the ATmega328P. I'm not sure there would be enough people to make up such a community, though. :-( Most are happy with pretty crap-quality code. The quadcopter community might actually be more appreciative of robust code than most others, given that there are significant, fun-abridging, $$ costs to buggy code. I still can't get over the state of TWI library code in Atmel's libraries. Heh, if you look at their API documentation, you can see which error codes are never returned.
|
# ? May 10, 2013 00:40 |
|
Having quality libraries (ISRs and all) for common peripherals like I2C, SPI, UART, PWM, etc would be amazing, as well as still being able to utilize those with your own C code (vs being forced to use Processing, etc). That said, it's tough to monetize that (factoring in enforcing licenses and stuff); I think you've got a decent chance of engaging the quadcopter/drone community, especially if you could come up with some convincing/easy to understand PR to explain why your board may be more suitable than an Ardupilot.
|
# ? May 10, 2013 06:19 |
|
Yeah, the more I think about this, the more quadcopters seem to be our way in. I'd love to move out from there into fostering a community of people who want higher quality hobbyist (and sometimes not hobbyist) electronic projects, but that's not where to start. If it can be made known that our hardware/software is excellent for quadcopters, maybe people would branch out, more boards can be made (or just used, there are a few STM32F4xx boards out there). In terms of monetizing, we ourselves want a solid foundation and when the code isn't secret sauce, we want to release it and expose it to critical eyes. That's one of my favorite things about my startup. We roll our eyes when someone says everything must be open-sourced, but hey, the world's gotta have some ideologues.
|
# ? May 10, 2013 07:05 |
|
Delta-Wye posted:Of course, when they go to do 30-45 analog reads in a row (the multiplexor guide said it would work!!!!!) and find out that it's hellishly slow they lack both the ability to recognize the problem (ADC reads take a long time) or the solution (kick them off and use an ISR to grab the data instead of spinlocking and waiting). Something I'm confused about with the ISRs on the MSP430 line of chips is if the chip only has one processor, the ISR has to be swapped in and the main program be swapped out for a while for the ISR to run, so it's not truly happening in the background like on a multi-threaded system, correct? So for this example of kicking the analog reads off to an ISR, that requires a multi-core or multi-threaded system to have any effect, right? Are those terms multi-core and multi-threaded appropriate for talking about microcontrollers?
|
# ? May 11, 2013 16:29 |
|
Uh you never have multiple cores and rarely have multiple threads (unless you are using some kind of crazy RTOS). An ISR needs to be a super-fast little thing that just does something like copy the value into a buffer and return. Then your regular code can read the buffer on its own time. As long as you keep your ISRs fast, it's like they're happening in the background but they really aren't.
|
# ? May 11, 2013 16:41 |
|
evensevenone posted:Uh you never have multiple cores and rarely have multiple threads (unless you are using some kind of crazy RTOS). That's what I thought. So Delta-Wye is saying that the ISRs should read the ADC output when it's ready at the ADC and then return it, rather than having the main thread poll it? I believe this assumes that the hardware supports activating an interrupt flag when the ADC output is ready?
|
# ? May 11, 2013 17:04 |
|
Yeah, exactly. What happens is that it takes 20 usec or whatever to read the ADC, and you get an interrupt when a new value is in. So you can do the read and wait in your main code, or you can do the first read on init, and have an ISR that takes the results and puts them somewhere and starts the next read or switches channels or whatever. Then the the main code just reads the results from memory. The ISR is just two or three instructions and it doesn't fire until the data is ready so it doesn't add much overhead. If you want even lower overhead or a certain precise sampling rate you can put the read requests on a timer (although usually timers are much more of a limited resource than cycles).
|
# ? May 11, 2013 17:18 |
Kire posted:That's what I thought. So Delta-Wye is saying that the ISRs should read the ADC output when it's ready at the ADC and then return it, rather than having the main thread poll it? I believe this assumes that the hardware supports activating an interrupt flag when the ADC output is ready? So lets say arduino's backend wrote the AnalogRead() function this way (in psuedocode, I'm not familiar with how the avr compilers want some of this stuff specified) code:
code:
code:
|
|
# ? May 11, 2013 18:26 |
|
Kire posted:Something I'm confused about with the ISRs on the MSP430 line of chips is if the chip only has one processor, the ISR has to be swapped in and the main program be swapped out for a while for the ISR to run, so it's not truly happening in the background like on a multi-threaded system, correct? So for this example of kicking the analog reads off to an ISR, that requires a multi-core or multi-threaded system to have any effect, right? Some architectures maintain a shadow set of registers so that you don't have to waste time pushing/popping them on the stack, you literally have a different set to play with when you're in ISR land. Other things to never do in ISR land include making function calls (yeah...), large loops, etc. On chips with a DMA engine you don't even have to worry about the data transfer part, all your ISR will do is clear some interrupt flags at the expense of a cycle or two.
|
# ? May 11, 2013 21:36 |
|
Victor posted:Pretty sure I haven't grossly mischaracterized you. Need I quote the elitist post you later edited away? Victor posted:My criticism wasn't that you are a really good engineer, it's that you don't think there's a niche between Arduino and requiring ten years of engineering experience, as you stated. Although, I actually do question what those ten years of engineering experience have gotten you, if you think the TWI libraries provided with Atmel Studio 6 are production-ready. Maybe you just haven't done much with TWI, but this also makes me wonder about the other libs provided by Atmel. I'm not interested in giving a history lesson with such an antagonistic student, but let me know if you ever learn why Atmel doesn't say I2C and we could share a laugh about this. If you literally need to see those letters, check out Dimax's USB solution. Victor posted:Part of this may be due to a huge personality difference between folks like Jawn6V and myself. I like to dig into something head-first, learning the various bits and pieces only when I need to. Oftentimes, bad software and hardware design requires you to know far more details than is theoretically required, for a given task. I wouldn't be surprised if Jawn6V doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised. I'd like to characterize your two approaches "dig in, learn as necessary" and "bookworm datasheet analysis". One of these is The Right Way, a slow plodding approach that guarantees safety at the cost of huge up-front investment. The other is demonstrably Worse, with no guarantee of deterministic success and potential for huge delays that could have been avoided. Victor, you're arguing for Worse Is Better. And if either of us has a known history of requiring a 50-page PDF to be read before commencing a task, I believe it's you. I've always been an advocate for Worse Is Better and I can't imagine your bookworm description squaring with that history instead of whatever mythical elitist you've concocted in my place. Victor posted:I definitely have the urge to splurge and use an FPGA to do stuff, but that's quite a bit more expensive, especially if you can't use a free dev environment (in other words, if you want anything more than a very simple design, unless things have changed since I last looked into this).
|
# ? May 12, 2013 16:20 |
|
What I don't get about this whole argument is that there already is a LGPL library (libopencm3) for STM32 with support for I2C, SPI, USART etc, and a complete gcc toolchain maintained by ARM. I think you can even hardware debug with gdb on the $15 dev boards.
|
# ? May 12, 2013 16:40 |
JawnV6 posted:One of these is The Right Way Books are for dorks
|
|
# ? May 12, 2013 17:49 |
|
JawnV6 posted:Who the hell does this? Seriously? You kept the post that I thought better of and are now, I'm not even sure, are you threatening posting it again? Classy dude. quote:One last shot at explaining this. I mentioned "Ten Years" was my learning ramp. quote:I'm not interested in giving a history lesson with such an antagonistic student, but let me know if you ever learn why Atmel doesn't say I2C and we could share a laugh about this. quote:Lies. Lies and slander. Not content asking direct questions and going nuts over misreading the answer, now you're just going to make things up whole cloth? Classy dude. quote:Yet again, decade-old knowledge of the toolchain is inaccurate. WebPack is free, I've done a few complex designs with it. On the Linux side there's ways to do Verilog simulation, compilation, and download to the device entirely from the command line. I've talked about these a few times over in the Verilog thread. Victor fucked around with this message at 02:45 on May 13, 2013 |
# ? May 13, 2013 02:42 |
|
Victor posted:I'm merely suggesting that you forget what it was like to want to go beyond Arduino, but not really want to get into a more powerful microcontroller from the ground-up. It's pretty typical for people to forget their understanding level and mentality when they were first learning something. My statements are actually based on watching a bunch of mechanical engineers with no coding or EE skills get Arduino up to snuff prototyping things without my help. And seeing them perfectly content with that tool set. No, really, they've done amazing things and haven't needed floats or FFT's that you're totally sure the Arduino really really needs. If you're quite done maligning my good name without cause, we might be able to discuss the gap you see in real terms instead of whipping up yet another false accusation. quote:How did you interpret the following statement as slander? "I wouldn't be surprised if JawnV6 doesn't mind reading through a datasheet in a bookworm fashion, which would mitigate some of the issues I've raised." Color me surprised. I'm not what you're talking about with respect to the 50-page PDF thing. Good grief.
|
# ? May 13, 2013 14:14 |
|
Victor posted:My criticism remains: the TWI libraries you casually referenced in AS6 are not robust. Well, the one for AVRs was third-party and passed its arguments via global variables, so I hesitate to call it a 'library'. Uh, wanna cite your source here? At work now and the tool that I'm actually using, the one that would be in front of a generic user, doesn't look anything like "third party passing global variables." Check it out. I'd hate to think you're using decade-old knowledge to unfairly trash something for the third time in as many posts. But the only other explanation that comes to mind is that you're using cursory google searches to call swaths of competing products "not robust" without ever thinking the problem might be on your end or that the IDE would helpfully link you to the proper docs. For someone claiming to be eager to do the heavy lifting for others, you don't seem all that invested in figuring out what's already out there. Did you even get around to checking out libopencm3 that evensevenone mentioned? Or were you more interested in trashing me than discussing relevant tech?
|
# ? May 13, 2013 16:08 |
|
Was there a vitriol spill recently?JawnV6 posted:Yet again, randomly picking lovely positions, ascribing them to me, then being a condescending jerk about the whole thing. You must be a hit at parties. quote:My statements are actually based on watching a bunch of mechanical engineers with no coding or EE skills get Arduino up to snuff prototyping things without my help. And seeing them perfectly content with that tool set. No, really, they've done amazing things and haven't needed floats or FFT's that you're totally sure the Arduino really really needs. If you're quite done maligning my good name without cause, we might be able to discuss the gap you see in real terms instead of whipping up yet another false accusation. quote:You made up the shittiest possible learning method that nobody in their right mind would use, JawnV6 posted:Uh, wanna cite your source here? quote:At work now and the tool that I'm actually using, the one that would be in front of a generic user, doesn't look anything like "third party passing global variables." quote:Did you even get around to checking out libopencm3 that evensevenone mentioned?
|
# ? May 13, 2013 18:06 |
|
This thread is the worst. Knock it off.
|
# ? May 13, 2013 19:28 |
|
As I've mentioned before, I am trying to teach myself some embedded programming skills. Thus far, that has meant a lot of reading online, fumbling with AVR programming with a Dragon and AVR Studio, and reading of various datasheets. I have a few pretty obvious deficiencies in my skillset that I need to remedy, and so I was hoping you could provide me with some suggestions. The main deficiency is that I don't really know C++. I did a lot of C in college, and have extensive experience in Java from my professional career, but I have never had to do anything meaningful in C++ so all my embedded code just ends up being C. (I know some other languages as well, but I mention C and Java to demonstrate somewhat relevant experience with concepts I expect I would find in C++.) I've looked into getting a good book to help remedy this, but a lot of C++ books seem to make heavy use of the standard library and I imagine embedded C++ tends to be a lot more lean. When I look for recent books on embedded programming, I tend to come up short. Does anyone have any recommendations? The second problem I am running into is that I learn the most by doing. My learning style revolves around picking something that I don't know how to do, and then doing it. To that end, I find myself recreating various interesting things I find online (hackaday, make, etc) and picking up whatever skills I need along the way. This has worked pretty well for me so far, but I've also looked around for a decent project book. Most of the ones I find are either extremely old and dated, or entirely focused on making things with an Arduino (which is what I trying to move past). Are there any particularly good resources people can direct me to in this area? The last problem is that there is a huge wealth of knowledge out there in the embedded world that I would classify under "best practices", "design patterns", and "institutional knowledge". This is an area that I am mostly ignorant of. Stuff like commonalities between different microcontroller architectures (so I might know what skills are transferable from AVR to PIC to others), tradeoffs between SPI and I2C, best practices for embedded debugging techniques (whether JTAG, digital logic analyzer, or other), common ics that I should always have on hand, and a whole lot more. I seriously doubt that there is a good book (or a few good books) that I can read to pick up some of this general knowledge. I don't work in an environment where I can pick this stuff up from professionals either. If there are decent resources that I can go through, please point me to them. I looked through the OP but there really isn't a whole lot there on these topics. Edit: If it's relevant for any potential recommendations, my preferred development environment is Linux, although I am perfectly willing to code on Windows or OSX if there is a compelling reason for it. I am mostly using AVR Studio on Windows at this point because I haven't gotten around to familiarizing myself with the command line toolchain, and my gaming computer (Windows) is right next to my electronics work bench. Edit2: I realize there are a lot of questions in this post, and that it will take me years to develop full operational knowledge of all of this stuff. I am mostly looking for some good reference material to accompany my explorations. armorer fucked around with this message at 02:01 on May 15, 2013 |
# ? May 14, 2013 19:33 |
Is there any particular reason you're doing c++? The runtime overhead for most of the novel c++ features (polymorphism et al) make it an unusual choice for resource constrained systems like 8bit avr/pic/etc chips. You can get the benefits of classes in C with structs and making your own *this pointers as an argument to each 'member' function (it's all c++ is doing anyways). Hell, you can even do inheritance if you really really want to via structs.
|
|
# ? May 15, 2013 00:02 |
|
No reason, and thus far I haven't been using C++ since I don't really know it. It just seemed like C++ was more common from some of the stuff I've read. If it's a better idea to stick with C and just use structs, that's great - less to learn!
|
# ? May 15, 2013 01:57 |
|
armorer posted:No reason, and thus far I haven't been using C++ since I don't really know it. It just seemed like C++ was more common from some of the stuff I've read. If it's a better idea to stick with C and just use structs, that's great - less to learn! Yes, you definitely want to start out with C!
|
# ? May 15, 2013 02:07 |
|
Delta-Wye posted:Is there any particular reason you're doing c++? The runtime overhead for most of the novel c++ features (polymorphism et al) make it an unusual choice for resource constrained systems like 8bit avr/pic/etc chips. Just scoping functions to a class is an ok reason to use C++, that's pretty much what I did for mbed programming. It's handy for modularizing IO that you can instantiate multiple times on different pins, for example, and more convenient than how you'd do it in C with no more overhead. The one advantage C++ has over other OOP languages is constructing static and stack objects so you don't have to use the heap at all, which is great all by itself for embedded. Plus, there's so many random BS features in C++ that you should never feel bad ignoring most of the language if a tiny subset solves your problem.
|
# ? May 15, 2013 02:17 |
|
For some reason I had the impression that C++ was more common in embedded design than C, and that if I wanted to be more "serious" I should learn it. If that is a bogus impression I picked up from somewhere, I am more than happy to cross it off my long list and focus on some other things instead. I am thinking about going through one of these two books next: Making Embedded Systems Designing Embedded Hardware
|
# ? May 15, 2013 02:38 |
|
armorer posted:I am thinking about going through one of these two books next:
|
# ? May 15, 2013 02:43 |
|
How do I learn to layout real PCBs.
|
# ? May 15, 2013 10:27 |
|
Sinestro posted:How do I learn to layout real PCBs. I learned my way around Eagle using the youtube videos that this guy put up rpcelectronics. They don't really teach you any design skills, but they do show you how to use the program for basic stuff pretty clearly. If you want to make them yourself via etching, there are a lot of tutorials online. If you want to upload your design to someplace like OSH Park, then I would look online for a design rule check (drc) file for eagle to run before you send them out. armorer fucked around with this message at 13:21 on May 15, 2013 |
# ? May 15, 2013 13:12 |
Sinestro posted:How do I learn to layout real PCBs. "Real" PCBs? If you just mean a normal PCB, I would get a copy of Eagle and follow some tutorials to get started. Once you figure out the software start making lots of circuit boards as they are going to suck at first; like a lot of things, it takes practice. Base Emitter posted:Just scoping functions to a class is an ok reason to use C++, that's pretty much what I did for mbed programming. It's handy for modularizing IO that you can instantiate multiple times on different pins, for example, and more convenient than how you'd do it in C with no more overhead. Tell me again about how developing for ARM is fundamentally different than an 8bit micro Eh, mostly just giving you a hard time. Curious what exactly you mean by "scoping functions". Are you referring to public/private or seperation? I'm pretty sure you can recreate that by encapsulating a function inside of a library that is a separate .c/.h file by simply not exporting the private functions in the header file. Delta-Wye fucked around with this message at 13:46 on May 15, 2013 |
|
# ? May 15, 2013 13:13 |
|
Sinestro posted:How do I learn to layout real PCBs. Find slides and read a lot of app notes. Then, you'll have to parse all those documents yourself because they willconflict with each other when it comes to recommendations. Luckily the basics are not too difficult, and for most hobbyist class projects, even terrible PCB layout (usually) ends up working.
|
# ? May 15, 2013 15:02 |
|
Sorry, I am not at my most coherent at 2:27 AM. I want to learn to do advanced layout, such as a board using a CC430 family chip --I've never payed out a board with wireless on it.
|
# ? May 15, 2013 15:13 |
|
Delta-Wye posted:Curious what exactly you mean by "scoping functions". Are you referring to public/private or seperation? I'm pretty sure you can recreate that by encapsulating a function inside of a library that is a separate .c/.h file by simply not exporting the private functions in the header file. Probably he means using classes as ersatz namespaces.
|
# ? May 15, 2013 15:26 |
|
|
# ? May 11, 2024 16:40 |
|
I think the trick with using C++ embedded is to start with a good understanding of C, and only incorporate those features from C++ that aren't too complex and that let you avoid dynamic allocation. If you just read a C++ book and start trying to use std:vector, you're headed for trouble. You certainly aren't going to get full OOP paradigm.
|
# ? May 15, 2013 16:23 |