|
isr posted:I am with this poster. Also, check out the microstick II, it comes with a few 16bit PIC24 MCU's, and a 32bit PIC32, all in DIP packages. The Microstick II is basically a PicKit 3, so if you want to program a non-dip part thats also possible. MPLAB X sucks in windows, but it flies in linux. Some other things to check out are TI's MSP430, Atmel is popular (they can't ship parts, but if you're a hobbiest this doesn't matter), and there are a load of ARM things around. I mainly work with microchip PIC24 parts. I have a real-ice, a pickit 2, a pickit 3, an ICD3, and a microstick II. I mainly use the microstick II. Didn't think about other tools needed so this is helpful indeed. As to budget, no way could I be laying out $150+ on tools alone at least initially.
|
#
?
Sep 4, 2013 04:34
|
|
|
|
| # ? May 9, 2024 22:12 |
|
|
mfny posted:Didn't think about other tools needed so this is helpful indeed. As to budget, no way could I be laying out $150+ on tools alone at least initially. Completely reasonable. What kind of projects would you like to make? There's plenty you can do without spending a lot, my back ground just happens to be with very low-level things which generally are made easier with tools etc. I haven't used one, but the beagleboard company http://beagleboard.org makes higher-level dev boards. It looks like you can do a lot of software development with just the inexpensive board.
|
|
#
?
Sep 4, 2013 04:44
|
|
|
No Gravitas posted:To change the topic a bit: Has anyone of you guys ever used a tiny compression algorithm for the data in a program? I have seen some cute decompressors that fit in under 150 bytes of ROM, but I just cannot decide which is a good candidate... Any hints? LZ4 is one of the simplest (and fastest) compressors possible. There's a 166-byte 6502 version, I'm not sure how big it would end up on your system.
|
|
#
?
Sep 4, 2013 05:03
|
|
|
isr posted:Completely reasonable. What kind of projects would you like to make? There's plenty you can do without spending a lot, my back ground just happens to be with very low-level things which generally are made easier with tools etc. I dont actually have projects in mind as such, more of an overall idea to learn and tinker with embedded overall, I do have a bias to software if any as my soldiering skills are pretty poor. Also I dont mind doing low level closer to the metal stuff as my tinkering with 68000 ASM would I guess show. Though Id say on instinct something like the Discovery or Launchpad would be what I should be looking at. Ive been basicly lost amongst the STM Discoverys, TI Launchpads and the like.. so many low cost eval/"starter" boards out there its hard to work out what would be a good entry board/device. Have also looked into FPGA's for an outlet for this need/want but the hobbyist ecosystem there is noware near as developed as for MCUs and CPUs in embedded systems. Though I did actually find something I feel I could follow as a "appetizer" so to speak here - http://www.xess.com/appnotes/FpgasNowWhatBook.pdf.. it even starts of with the blinky light, and the hardware that xess sells seems reasonable, and inexpensive.
|
|
#
?
Sep 4, 2013 05:30
|
|
|
If you want to aimlessly nerd out there is so much you can do with $0. That book about FPGA's you linked looks like a great resource for starting with the ISE Webpack. You can do soup to nuts hardware design and simulation in web pack without needing any hardware. I bought the Nexys 2 FPGA board from diligent, and only loaded a design to the board once. There is so much you can do in webpack. For microcontrollers the same is also true. Both the 68k and PIC24 are very similar to the PDP-11 instruction set, so programming in assembly is very enjoyable. Download MPLAB X with the XC16 compiler, and read this http://ww1.microchip.com/downloads/en/DeviceDoc/70157F.pdf . Skip to the instruction set description. You can do a lot of algorithm development just with knowing the instruction set. The simulator is decent enough that you can also work with some peripherals, and you can write stimulation files to simulate things like input capture/ output compare / adc's / etc. The same is also probably true for other MCU vendors, but I can't speak to them as well. If you do decide to try out MPLAB X, I highly recommend loading it on a linux machine. MPLAB X on windows is like work. isr fucked around with this message at 06:00 on Sep 4, 2013 |
|
#
?
Sep 4, 2013 05:57
|
|
|
I wouldn't start with an FPGA. They're very specific to certain applications, and a very large paradigm shift from standard programming. In general, I'd stick to PIC/AVR/Launchpad, the first two are pretty well-established leaders, and TI is catching up. I've never used a demo board outside of school, so I can't recommend one, though.
|
|
#
?
Sep 4, 2013 05:59
|
|
|
So i just found mbed.. In terms of an easy start, both software and hardware wise it would not get much more plug in and go then mbed and a mbed supported platform (http://mbed.org/platforms/) from the looks of things, anyone here have experience of it though ?
|
|
#
?
Sep 4, 2013 16:01
|
|
|
For cost you really can't beat spending like $5-$10 (with shipping) on a MSP430 LaunchPad, if you're OK with more effort on your part in reading docs, getting environments set up, etc.
|
|
#
?
Sep 4, 2013 17:14
|
|
|
movax posted:For cost you really can't beat spending like $5-$10 (with shipping) on a MSP430 LaunchPad, if you're OK with more effort on your part in reading docs, getting environments set up, etc. The Freescale Freedom FRDM-KL25z looks interesting on the mbed front and is $10 to. So it would be ether that or a TI Launchpad of some flavour I guess, ether the MSP430 or the ARM based ones. Which brings me to a important question. How much more effort/complication would I be giving myself in terms of learning choosing an low end ARM based board/mcu vs the MSP430 though or since the ARM on the likes of the Freedom board is low end im guessing it would not make much of a difference ?
|
|
#
?
Sep 4, 2013 18:15
|
|
|
Everyone and their mom are making GBS threads out ARM "devboards" left and right with software support ranging from non-existent to laughable to only half-lovely. It's a neat architecture and certainly very popular in the market, but there is a level of complexity to keep in mind. If you are just starting out, I really think the best choice is a "simple" MCU like PIC/AVR/MSP430/etc. The devtools are cheap, and you will learn a lot of basics that can be carried on upwards to bigger and more powerful chips. I am partial to PICs because I think Microchip has the best organized documentation out of anyone. With AVRs, of course Arduino uses the Atmega328, but I would urge you to learn on bare-metal / C. AVRs IMO are less-forgiving if you gently caress-up your fuses because then you have to rig up your programmer with copious amounts of extra wires to blow the fuses with high-voltage programming whereas PICs and MSP430s can recover from their standard debug ports (for the most part). The most common example here is if you accidentally set the wrong clock source for your chip (i.e. use external crystal when you don't have one). If you're willing to put in work and deal with poorly organized documentation, the MSP430 LaunchPad is a great choice. If you want better documentation and want to spend a little more, a devboard based around a PIC18 or PIC24 that supports the PICKit3 is what I would recommend.
|
|
#
?
Sep 4, 2013 18:24
|
|
|
TI has done a fairly decent job supporting and documenting its Stellaris Launchpad product and if you're comfortable learning to use their StellarisWare API then I think it's probably as good a platform to start on as any when it comes to ARM. Plus you can always ditch the libraries and go to registers and bare metal, but I think TI is banking on you finding StellarisWare so easy to use that you just keep on using it. There's a non-negligible community of MSP developers and I think they're starting to adopt the Launchpad now too. It's literally a drop in the bucket compared to the PIC/AVR online community, but if you're going to start I honestly think that's the way to go. I say this as someone who tried to make a foray into embedded programming starting with the ARM Cortex line. I started with the Launchpad and then went to NXP's lpcxpresso platform before just ditching both and moving to AVR for simplicity's sake. I had a big problem with learning to use a platform with a vendor library because I wanted to keep myself pretty much vendor independent so I tried to bitbang everything, but being someone who relies primarily on online support I found that the ARM communities out there are pretty much still in their infancy, whereas people have been using AVRs and PICs for forever so finding an off-the-shelf solution to a problem is easier when you go with one of the 8 bit micros. That isn't to say that what you learn doesn't apply to the ARMs -- it pretty much directly carries over and if I had a project that could make use of an ARM micro I would probably be fairly comfortable using one, but so far none of my pet projects have come close to even maxing out an 8 bit AVR let alone needed an ARM so I'm sticking with what is comfortable. I don't want to say something like "once you learn how to code for X, coding for Y micro will be pretty much just a matter of looking up registers and switching your compiler" because that's an oversimplification, but if you start out with an AVR or PIC tutorial I think you'll find that moving up is pretty easy. If you're like me and just want to start with ARM then that's definitely doable, but you're kind of putting yourself at a disadvantage because the hobbyist community is much smaller and you'll be doing most of the grunt work yourself. And obviously I don't want to sound like someone who's an expert in the field. I started in this thread and I'm still struggling, but I've managed to make lights turn on and RFID stuff read and motors step and all that without an arduino, so I can safely say that if I can do it, you certainly can. some kinda jackal fucked around with this message at 19:06 on Sep 4, 2013 |
|
#
?
Sep 4, 2013 18:57
|
|
|
Martytoof posted:TI has done a fairly decent job supporting its Stellaris Launchpad product and if you're comfortable learning to use their StellarisWare API then I think it's probably as good a platform to start on as any when it comes to ARM. Plus you can always ditch the libraries and go to registers and bare metal, but I think TI is banking on you finding StellarisWare so easy to use that you just keep on using it. StellarisWare is fairly easy to use, yeah. Now, they assumed that people would just start from their example projects, so if you want to make a new project you have to manually tell the IDE to include the StellarisWare libraries if you use their provided environment. Also for what it's worth, it's called the Tiva C Series microcontroller, and TivaWare now.
|
|
#
?
Sep 4, 2013 19:00
|
|
|
movax posted:Everyone and their mom are making GBS threads out ARM "devboards" left and right with software support ranging from non-existent to laughable to only half-lovely. It's a neat architecture and certainly very popular in the market, but there is a level of complexity to keep in mind. If you are just starting out, I really think the best choice is a "simple" MCU like PIC/AVR/MSP430/etc. The devtools are cheap, and you will learn a lot of basics that can be carried on upwards to bigger and more powerful chips. I am partial to PICs because I think Microchip has the best organized documentation out of anyone. I am a little puzzled as to why your recommendation would be so strong in favour of Microchip/PIC. You have said that the software for PICs is a buggy piece of poo poo, software being described in such a way does not inspire confidence at all from a ease of use/learning perspective. I am thinking having dev tools that work well and not be a buggy piece of poo poo would be important or maybe im being naive in my newbieness ?
|
|
#
?
Sep 4, 2013 19:01
|
|
|
Arcsech posted:Also for what it's worth, it's called the Tiva C Series microcontroller, and TivaWare now. Shows you how long it's been since I last used my Stellaris  mfny posted:I am thinking having dev tools that work well and not be a buggy piece of poo poo would be important or maybe im being naive in my newbieness ? I use Atmel Studio which I would consider kind of buggy and annoyingly slow, but it hasn't really hampered my ability to make a light blink. I suspect that it's probably buggy once you start to dig into the guts, but for someone who's starting out it should be perfectly fine. I downloaded and played around with MPLAB X for OSX and I thought it was pretty serviceable. It did everything I really asked of it. It's not the prettiest looking software on the block but it doesn't really need to be. Really, all you need for an IDE is the ability to compile and upload your code (and probably not even that if you use third party tools). If you don't like the IDE then they're just tools that you can switch out for other editors. I use Sublime Text for AVR development at work since my Mac is too bogged down to run a VM with Atmel Studio sometimes. And I'll second that Microchip has some amazing documentation. They have application notes for scenarios that I have bookmarked even though I don't use a PIC. They blow Atmel out of the water there IMHO. some kinda jackal fucked around with this message at 19:14 on Sep 4, 2013 |
|
#
?
Sep 4, 2013 19:08
|
|
|
mfny posted:I am a little puzzled as to why your recommendation would be so strong in favour of Microchip/PIC. You have said that the software for PICs is a buggy piece of poo poo, software being described in such a way does not inspire confidence at all from a ease of use/learning perspective. Did I? I know I hated on the Atmel tools here. The Microchip tools can be buggy yes, but for starting out I think they'll do fine. The secret is that almost all of the design suites (and EDA tools in general) tend to suck and have poo poo wrong with them. The userbase is tiny (but generally well-educated), there are no alternatives, they can charge obscene amounts of money, etc.
|
|
#
?
Sep 4, 2013 20:50
|
|
|
movax posted:Did I? I know I hated on the Atmel tools here. The Microchip tools can be buggy yes, but for starting out I think they'll do fine. The secret is that almost all of the design suites (and EDA tools in general) tend to suck and have poo poo wrong with them. The userbase is tiny (but generally well-educated), there are no alternatives, they can charge obscene amounts of money, etc. Oh crap, my bad..it was ante who said that. I somehow got you and them confused as you both had mentioned Microchip a lot. Sorry.
|
|
#
?
Sep 4, 2013 20:58
|
|
|
Yeah, that was me. Sorry, I should explain. All of the toolchains right now are pretty buggy. I've used Freescale/PIC/AVR microcontrollers pretty extensively, and while they all of their problems, PIC is the one I've found best in terms of usability, features, and ubiquity. I really do think getting a PicKit3 is your best option, and not worrying too much about dev boards. They're fine for school when you're forced to sit down and make that LED flash, but if you actually want to build something, a standalone microcontroller with an internal oscillator is just as good.
|
|
#
?
Sep 4, 2013 22:02
|
|
|
Apparently Zilog still exists, I did do a course at collage on a Z80 trainer in Assembly and raw Hex, the latter being a pretty uhh unique experience to say the least.
mfny fucked around with this message at 06:46 on Sep 5, 2013 |
|
#
?
Sep 5, 2013 06:35
|
|
|
Edit: Quote is not Edit.
|
|
#
?
Sep 5, 2013 06:35
|
|
|
I like AVR because at least you're using gcc. At work we use STM32 which I think has a decent open-source toolchain with arm-none-eabi, libopencm3 and stlink, but holy gently caress there is way too much going on for it to be enjoyable as a hobby project. If I didn't have way smarter people around to ask questions, and a big codebase to look through I would never be able to figure out how to configure the timers, much less the things that are actually tricky like USB.
|
|
#
?
Sep 5, 2013 07:53
|
|
|
mfny posted:Apparently Zilog still exists, I did do a course at collage on a Z80 trainer in Assembly and raw Hex, the latter being a pretty uhh unique experience to say the least. I did this "hex programming" thingy a few times, because the assembler for those CPUs did not exist yet. It is a unique experience and I would wish it on no one. And that was without any relative jumps even. I cannot imagine doing this with relative jumps and keeping your sanity for very long.
|
|
#
?
Sep 5, 2013 08:31
|
|
|
Not sure if its strictly embedded related but given my history with them I am curious as to what the "modern" equivalent to the Motorola 68000/PowerPC would be ?
|
|
#
?
Sep 5, 2013 08:40
|
|
|
First, those are two completely different architectures separated by about 15 years. Second, both are still around. 68000 for various low power embedded type things--the "Dragonball" chips used in Palm devices were 68k based, and now god knows what still used.them but you can certainly buy them. I would guess that there's a few in your car or household appliances. As for PowerPC, http://www-03.ibm.com/systems/power/hardware/. You can get a system with several 16-core 5ghz POWER7s. Or several hundred.
|
|
#
?
Sep 5, 2013 10:37
|
|
|
evensevenone posted:First, those are two completely different architectures separated by about 15 years. I know they are totally different, bought them up because of my mentioned experimentation with ASM on the Macintosh, 680x0 mostly but PPC was just showing up then in new systems as well, was just curious and figured id ask even if it was kinda random.
|
|
#
?
Sep 5, 2013 11:23
|
|
|
What parts have taken up the 68k/PPC market? Like MOVAX said, everyone and their mother has released ARM (or MIPS) parts, those are probably about as powerful as the 68k / PPC but with integrated peripherals. Companies just buy the IP, slap on their peripherals. In some market research I saw, embedded developers are still reporting planning new designs using old rear end architectures like 68k/PPC/186/286/386/486/Z80/8085, you name it. Why? Hell if I know. I suspect its to leverage existing code bases. For example, isr fucked around with this message at 19:17 on Sep 5, 2013 |
|
#
?
Sep 5, 2013 16:24
|
|
|
A lot of that is probably greybeards working in the same company for 30 years.
|
|
#
?
Sep 5, 2013 17:09
|
|
|
isr posted:For example, military contractors have to write everything in assembly, Huh? For a while there was a mandate to use Ada although that eventually blew over, the JSF has published C++ coding standards (perhaps contributing to its lol-factor), we aren't a defense contractor by any stretch but we have products that get sold to .mil customers that had their firmware done in C, ...
|
|
#
?
Sep 5, 2013 17:09
|
|
|
isr posted:In some market research I saw, embedded developers are still reporting planning new designs using old rear end architectures like 68k/PPC/186/286/386/486/Z80/8085, you name it. Why? Hell if I know. I suspect its to leverage existing code bases. For example, military contractors have to write everything in assembly, so migrating just wouldn't make sense. Converting Z80 ASM to MIPS would be very enjoyable, I wish someone would pay me to do it... The old archs have a lot of heritage (flight and otherwise), combined you've probably got centuries of real-world usage time. Well known errata, performance, etc. And yeah, probably the same greybeards working at a company for like thirty years. I don't know if it's a benefit or not, but those old ones also aren't very mixed-signal, if at all (unless modern variants are slapping the IP core on there and gluing logic/peripherals to it). Want an ADC or something else? 8-bit parallel address/data interface time 
|
|
#
?
Sep 5, 2013 17:35
|
|
|
Otto Skorzeny posted:Huh? For a while there was a mandate to use Ada although that eventually blew over, the JSF has published C++ coding standards (perhaps contributing to its lol-factor), we aren't a defense contractor by any stretch but we have products that get sold to .mil customers that had their firmware done in C, ... I met a guy at microchip's master's conference who works for some defense contractor. He claimed that the military required that firmware be written in assembly for some laser guided something his company developed. Maybe I misunderstood, or maybe that's just how he chose to meet the requirements, or maybe it wasn't true... Anyways, he used "all our code is in asm!" as a reason to stick with PIC24 rather than moving to PIC32.
|
|
#
?
Sep 5, 2013 18:44
|
|
|
I bet the requirement was more along the lines of having to know EXACTLY where the code that was actually being executed was coming from and what it was. For example, with C, someone could alter the compiler to sneakily inject some nasty code to do nefarious things that the developer wasn't aware of. 
|
|
#
?
Sep 5, 2013 18:46
|
|
|
Bad Munki posted:I bet the requirement was more along the lines of having to know EXACTLY where the code that was actually being executed was coming from and what it was. For example, with C, someone could alter the compiler to sneakily inject some nasty code to do nefarious things that the developer wasn't aware of. Right, for different saftey-related applications there are different certification requirements. There are a lot of hoops to jump through just for certifying appliances, for a cruise missile I bet the requirements are much more stringent. Just a change in compiler version could result in the code being assembled differently. Certified Compilers are a thing, they guarantee certain behavior to serve that market. I don't believe anyone makes a certified compiler for microchip parts, so maybe it was just that ASM was the most sensible thing for them.
|
|
#
?
Sep 5, 2013 19:04
|
|
|
isr posted:I met a guy at microchip's master's conference who works for some defense contractor. He claimed that the military required that firmware be written in assembly for some laser guided something his company developed. It's a pretty far stretch from there to "every military contract ever uses only asm"
|
|
#
?
Sep 5, 2013 19:05
|
|
|
isr posted:There are a lot of hoops to jump through just for certifying appliances [for safety], for a cruise missile I bet the requirements are much more stringent. On a related note, does anyone know of good reads for doing designs for SIFs that have to get SIL certified? It seems like CE is cake and UL general safety certification isn't hard, FM intrinsic safety is a huge but reasonably well understood bitch, (and the equivalent ATEX and CSA certs), and nobody will say what to do for SIL without being paid five grand to come give a talk which then leaves you barely wiser than before.
|
|
#
?
Sep 5, 2013 19:08
|
|
|
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
|
|
|
Corla Plankun posted: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. Sounds like you need a RTOS? Basic scheduling, priority queues, interrupt tiers...all things a RTOS can provide (though admittedly you can do the interrupt priorities yourself with the IPCx registers). The dsPIC doesn't give you a free shadow set of registers for IPC7 like the PIC32 does, right? I think that is a MIPS thing.
|
|
#
?
Sep 5, 2013 19:23
|
|
|
Corla Plankun posted: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. What it sounds like you want here is a preemptive scheduler (probably with priorities), which is the most fundamental thing an RTOS will give you. In general I have found it easier to write well-factored firmware with an RTOS than without (except for really small things). There is at least one decent free one with permissive licensing as well.
|
|
#
?
Sep 5, 2013 20:10
|
|
|
movax posted:Everyone and their mom are making GBS threads out ARM "devboards" left and right with software support ranging from non-existent to laughable to only half-lovely. Forgot to ask in reply to this a obvious question it seems. Who would have the least lovely,easiest to set up tools/boards for an newbie ARM Cortex M0+ setup ?
|
|
#
?
Sep 6, 2013 01:52
|
|
|
Corla Plankun posted: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. Measure how much time all your individual routines take, and plot them out to make sure they'll all fit in the time you're allotted. (Ab)use the DMA channels if you've got them. What goes in the main loop vs what goes in an interrupt is really up to the individual application, or developer's preference. The right way is the way the works  An RTOS is great for certain things, but it opens up a new world of problems that are more complex than super-loop vs. interrupt. If you're doing motor control or some other static application, I would suggest you lean away from an RTOS. If you're developing something with lot of user interaction an RTOS begins to make more sense. Really, the best way to learn is to do.
|
|
#
?
Sep 6, 2013 01:56
|
|
|
Except don't make your own RTOS one piece at a time, because inevitably the result will be less full-featured and way buggier than even FreeRTOS
|
|
#
?
Sep 6, 2013 06:25
|
|
|
|
| # ? May 9, 2024 22:12 |
|
|
Question: I'm kind of fuzzy on the PIC infrastructure. How much do the optimization limitations of their free compiler actually affect you guys? I am imagining scenarios where you really only start to see it if you have some crazy large firmware you've designed and for like 99% of users out there their free implementation is probably fine? All this talk about microchip got me thinking about PICs and I think I'm going to pick up a cheap pickit 3 and just give their thing a whirl. Why not, right?
|
|
#
?
Sep 6, 2013 18:42
|
|