|
Go get yourself a $30 PicKit 3 and MPLAB. My preference is for the original MPLAB, rather than MPLAB X, but they're both kinda buggy pieces of poo poo. That's pretty much par for the course. PICs will take you the full gamut from "pretty easy" to "industry standard" solution. There will almost definitely points right at the beginning where you'll feel overwhelmed, but just take a break when that happens and come back to it. Or ask here. I like answering easy questions because then I'm like 90% sure I have the right answer and won't look dumb
|
#
¿
Sep 4, 2013 03:34
|
|
|
|
| # ¿ Apr 28, 2024 23:36 |
|
|
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
|
|
|
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
|
|
|
A lot of that is probably greybeards working in the same company for 30 years.
|
|
#
¿
Sep 5, 2013 17:09
|
|
|
TwystNeko posted:I am noticing that I'm having to declare a whole lot more variables in the global scope. Is that something I should worry about? Or just roll with it? Pretty common and fine in microcontrollers. Not so cool in desktop programming.
|
|
#
¿
Oct 15, 2013 01:32
|
|
|
In school I wrote an in-chip debugging routine that used a MAX232 to talk to a computer. It was kinda ridiculous
|
|
#
¿
Nov 15, 2013 07:04
|
|
|
Both versions of MPLAB are huge turds.
|
|
#
¿
Nov 15, 2013 20:18
|
|
|
You don't need to be searching for Raspberry Pi specific boards. Anything designed for hobbiests (mostly Arduino stuff) will work pretty well with I2C libraries using the GPIO. Something like: http://www.adafruit.com/products/1083 http://www.adafruit.com/products/935 That's with like two minutes of searching, I'm sure you can find combination boards (for waaay cheaper than that gertboard) from your preferred suppliers.
|
|
#
¿
Dec 7, 2013 23:19
|
|
|
That was demystifying and good. I liked that writeup.
|
|
#
¿
Dec 8, 2013 23:03
|
|
|
Sir_Substance posted:I know this thing is not quite up your guys alleys, but it's in the same vein. I thought I might post here before spawning a whole thread for it. This is a great project and somewhat up my alley and not nearly as doom and gloom as that other dude said. Provided you use SD cards instead of flash drives, however. SD cards are purely driven by SPI, which makes them trivial to communicate with using an Arduino or PIC. I've never looked into the internal structure of flash drives, but the USB addition makes them way less accessible. Look on Alibaba or Aliexpress and see if you can get a handful of 2gb microSD cards for cheap. If you get stuck on any part of this, I'd totally be interested in a thread about it, I might have some ideas on how to proceed.
|
|
#
¿
Feb 4, 2014 23:43
|
|
|
Otto Skorzeny posted:This isn't quite true - the SD spec defines the (slow as balls) SPI interface to an SD card as well as the much faster parallel SD interface. I wrote an SPI interface using PIC about fourish years ago, at that time (as far as I could figure), the only way to get the parallel spec was to pay licensing fees. Regardless, the SPI commands that Bunnie's talking about is straightforward, as I said.
|
|
#
¿
Feb 5, 2014 01:46
|
|
|
Sir_Substance posted:Ok, so for context here, I'm a total software guy. I've played with an arduino once, and that's about it. Yes, a reader will wipe out the advantage. You need something that reads and writes directly to the pins in binary. An arduino or maybe a bus pirate would be easier for a software guy
|
|
#
¿
Feb 5, 2014 03:35
|
|
|
Yup, that would work. Just don't use the SD card libraries at all. Or maybe use them but hack them to send the altered commands that you want to send. If you could find the same brand of card from the link above, it would make your life easier, but if not you might be able to brute-force it.
ante fucked around with this message at 05:44 on Feb 5, 2014 |
|
#
¿
Feb 5, 2014 05:39
|
|
|
Cool, keep us updated. I wish I still had my code for my final year PIC project that included an SD card for extra space. It was pretty clever (read: hackish and loving stupid)
|
|
#
¿
Feb 5, 2014 06:49
|
|
|
Tiger.Bomb posted:The first ten levels are _very_ basic. You're pretty much always doing some kind of overflow. Figuring out what you need to overflow it with is the trick. Thanks for ruining the sense of accomplishment I got from doing the first eight levels 
|
|
#
¿
Feb 12, 2014 17:37
|
|
|
You could start with the codebase of some existing SD card library. edit: Looking over my old notes now, this was the most useful thing ever for me in 2010ish before reliable SPI SD card libraries were a thing. http://www.esawdust.com/blog/serial/files/SPI_SD_MMC_ATMega128_AVR.html ante fucked around with this message at 08:04 on Feb 20, 2014 |
|
#
¿
Feb 20, 2014 07:53
|
|
|
The slow speed is just because some cards may lose data if they're run faster. You're not transferring large amounts of data so who cares, really. Timing doesn't really matter, if your device has an SPI peripheral, it should pretty much handle that automatically. Give it a byte and it'll clock 8 times at your chosen speed. I hope you're not bitbanging SPI in software, that's a pretty unneeded extra step in complexity. The slave/chip select (CS/SS) pins are inactive(high) when you're not sending data, so there's no special idle timing or anything. From the PM where I sent you some of my relevant code: quote:I notice that you're sending a CMD0 restart before you perform the 74 cycle clock speed loop. I haven't seen that in any of the standards I've read, they've all said DI and CS to high, cycles, CS to low and then send CMD0. Again, it's been a bunch of years since I touched this stuff so I'm not a 100% reliable source, but I think I was reprogramming my PIC a whole punch with power on, so I generally pumped a bunch of extra RESET(CMD0) commands. I think either I wanted to be absolutely sure, or my card was out of spec, or it only worked properly when I did that or something, but there's no downsides to a bunch of extra resets right at the beginning. The great part of a step-by-step procedure with feedback from the card is that as soon as you get started, you know at exactly what step it's failing at.
|
|
#
¿
Feb 20, 2014 09:59
|
|
|
The CRC is done for the first few commands until the card successfully gets dropped into SPI mode. After that, the checksum is still a thing, it's just ignored completely by the card. Conveniently, though, those first commands are always the same, so the CRC can be hardcoded.
|
|
#
¿
Feb 20, 2014 20:17
|
|
|
No, not checking the CRC in SPI mode is part of the spec, as far as I remember. Keep in mind SPI mode isn't actually supposed to be used in any professional capacity.
|
|
#
¿
Feb 20, 2014 21:13
|
|
|
Are you going to release code?
|
|
#
¿
Feb 27, 2014 18:39
|
|
|
I'd look into FPGAs. They're good at exactly what you need, i.e. taking data into, performing a set series of operations, and dumping it out very fast. VHDL, the language you'd likely be using is a fully parallel language, which will be a huge paradigm change for you. But it's kinda fun.
|
|
#
¿
Mar 10, 2014 17:43
|
|
|
Crossposting from electronics thread because I just realised this is even more relevant hereante posted:HEY GUYS!
|
|
#
¿
Mar 18, 2014 01:22
|
|
|
I'm sure TI has volumes of app notes about it for their Launchpad, it's kinda their thing. Come to think of it, you'll probably find some good ones from Microchip or Atmel, too. Like this: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en556618
|
|
#
¿
May 14, 2014 07:53
|
|
|
Big drill bits can definitely fit kibbles in the flutes. e: that is a very fun sentence
|
|
#
¿
Jun 10, 2014 03:34
|
|
|
The 28byj-48 is dirt cheap and internally geared down to 64 steps per revolution I think. e: 64*8 = 512 steps On Aliexpress there are also a lot of micro-stepper motors designed for the internals of lenses. That seems pretty likely, too. ante fucked around with this message at 18:44 on Aug 10, 2014 |
|
#
¿
Aug 10, 2014 18:25
|
|
|
Controls group for cyclotrons.
|
|
#
¿
Dec 9, 2014 01:41
|
|
|
poeticoddity posted:That bidirectional buffer looks fantastic and the price isn't nearly as bad as I'd thought. I may be building equipment this spring semester with LEDs that are over a $100 a piece, so dropping <$4 on a buffer that lets me move something across the room is of no problem. I've seen people with spaghetti wire going everywhere on their projects, and I always always suggest ethernet. It's ubiquitous, cheap, easy to terminate, the connectors lock into the sockets, and if you need to send fast signals long distance, that is literally what cat 6 is designed to do.
|
|
#
¿
Dec 13, 2014 02:02
|
|
|
Hey, so give me two good reasons to use anything other than internal oscillators. I would assume better stability / accuracy, but other than that... ?
|
|
#
¿
Jan 31, 2015 08:04
|
|
|
bobua posted:I was wondering if that was a huge undertaking. Yeah
|
|
#
¿
May 2, 2015 01:21
|
|
|
The VHDL thread is dead, I guess, so this is the next best thing. I have an Altium license through work. Would it be worthwhile to try FPGA development using that instead of ISE? Xilinx's tools are stupidly clunky and aren't really well integrated, so it would be nice if Altium sidestepped all those issues.
|
|
#
¿
Jul 12, 2015 01:51
|
|
|
Ponderous Saxon posted:What kind of integration are you after? taqueso posted:I played around with it (a couple years ago) and it seemed to work well, if in a bit of a complicated way. I went back to the comfortable vendor toolchain for expediency and never bothered to try again. I think Altium can do what you want (sidestepping xilinx's toolchain) and you will be writing mostly the same HDL so you can bail pretty easily if it doesn't work out. I didn't care for the visual plug-together stuff, but that might have improved. Honestly, I've been working on something stupidly complicated off and on for the past year, so I'm not even past the design/simulation stage. I'll eventually be putting it on some higher end Spartan 6s, and my impression is that Vivado is the latest and greatest, but drops all support for non-enterprise chips like Spartans? I dunno, marketing doublespeak seems really prevalent in the FPGA world, so I had a hard time understanding exactly what the deal is. Never thought of downloading Vivado just to use the tools and then back to ISE for layout and programming, but I guess it could be worth a shot.
|
|
#
¿
Jul 13, 2015 08:08
|
|
|
Crankit posted:What's the difference between a FPGA and a CPLD? To answer your second question, you write out your VHDL/Verilog in a vendor toolchain, and it will synthesize the design and spit out a number of logic gates / whatever metric that particular vendor uses. The languages are mostly device-agnostic, so it's easy enough to shop around if you're unsure which to go with.
|
|
#
¿
Aug 25, 2015 00:03
|
|
|
Read out the clock value every loop, and if you read HIGH, wait until the loop that reads time + 20ms, and if you read LOW, bam, debounced button read. You don't need a blocking wait() or anything, just set a flag to come back to it later. Also fyi, a good rule of thumb is typical decent buttons need ~20ms of debounce time, 100ms for really sloppy presses. edit: actually read the code and tailored advice edit2: If you're new to embedded development, read up on state machines, this would be a good application for one ante fucked around with this message at 04:32 on Sep 8, 2015 |
|
#
¿
Sep 8, 2015 04:28
|
|
|
There's a Verilog thread that is very dead. Yeah, FPGA toolchains suck. Like, a lot.
|
|
#
¿
Dec 29, 2015 23:14
|
|
|
People have done exactly that with some of Lattice's stuff. I haven't checked it out because who the hell uses Lattice FPGAs, FPGAs have also only really been accessible for non-professionals for 3 or 4 years, too, so I'm sure some cool stuff will happen over the next 5 years in the open source community.
|
|
#
¿
Dec 30, 2015 20:28
|
|
|
The tools have gotten miles better in the last couple years. They're actually pretty good now. Debugging still sucks, unless you have a $150 ICD
|
|
#
¿
Jan 22, 2016 05:03
|
|
|
Mr. Powers posted:I haven't used MPLAB X, though. Do iiiiiit.
|
|
#
¿
Jan 22, 2016 07:20
|
|
|
Why don't you make the ESP8266 write to a database hosted somewhere else? https://influxdata.com/blog/how-to-send-sensor-data-to-influxdb-from-an-arduino-uno/ The ESP8266 is pushing, not the other way around.
|
|
#
¿
Mar 4, 2016 05:30
|
|
|
Hacking the XBox is actually a surprisingly good reference, and still relevant, and free.
|
|
#
¿
Apr 10, 2016 04:39
|
|
|
|
| # ¿ Apr 28, 2024 23:36 |
|
|
Raspberry Pi is really the only option there. It's not even close to the best hardware or anything, but the huge amount of community support is the best for Getting Stuff Done without dicking around too much
|
|
#
¿
Aug 16, 2016 01:13
|
|