|
hobbesmaster posted:at that point can't you get m4s that'll be more powerful? For $5 with 32MB DDR included and drives LCDs natively? I'm all ears. I think it's $3-$4 for us, I'm just going by avnet pricing on it. I see a lot of M4s for that price, but none that include the RAM. It's insane how cheap these parts are. Good news though, there's slightly more recent part running 3.10.x so I don't have to gently caress around with pre-device-tree initialization. For smaller projects, the $1-$2 M4s are great.
|
#
?
Jan 4, 2017 08:09
|
|
|
|
| # ? May 16, 2024 21:27 |
|
|
I guess even a cheap external sdram with an m4 would blow the bom?
|
|
#
?
Jan 4, 2017 10:11
|
|
|
gonadic io posted:is there a reason to buy an arduino zero over a MKRZero? The micro touts that is has the same pins, and it's about half the price. Is it just a more modern (smaller) upgrade? Also it runs arm so it's fairly easy to get rust to compile on! I bought a CO2 tank, a regulator, some solenoid valves, and a gyroscope chip. Here's hoping that I actually do something with it
|
|
#
?
Jan 4, 2017 14:58
|
|
|
gonadic io posted:Also it runs arm so it's fairly easy to get rust to compile on! i tested compiling and running rust on the m0-based microbit based on https://github.com/SimonSapin/rust-on-bbc-microbit, but then i realized i didn't have time to reimplement everything i needed from scratch so i just used python
|
|
#
?
Jan 4, 2017 15:14
|
|
|
Harik posted:For $5 with 32MB DDR included and drives LCDs natively? I'm all ears. i didn't realize it was a mcm with the ram onboard. that's kinda nifty, if it wasn't 2017. now I almost feel bad for bitching about a at91sam9x earlier. I assume you're not expecting to run JavaScript at least
|
|
#
?
Jan 4, 2017 16:25
|
|
|
I have a little gyroscope chip that I'd like to connect to a small pcb so I can mount it in the desired orientation. It doesn't have pins though, it looks like this: It's roughly 1cm a side. What's the usual way to connect one of these? I saw one person mount it upside down on the board, and solder wires to each of the pads. This is pretty fiddly though, is this the usual way to do it? The device is 5V and draws 51mA. Is a 0.01microF bypass okay? I plan to put it on the board itself as I'll never not want it. Sorry for the stupid questions but I am very new to the wonderful world of hardware.
|
|
#
?
Jan 6, 2017 19:04
|
|
|
the "true" way to do it is have a pcb with the proper land pattern, get some solder paste onto the pcb's lands, place the part (and also paste/place for all the other surface mount parts), heat the whole thing in an oven or use a hot air gun to reflow the solder if you do reflow right (the right amount of solder paste, the right geometry of the land pads, etc) the surface tension of the molten solder auto-aligns the parts so placement doesn't even have to be super accurate you may be able to find prototyping pcbs that break out the pins from a package like that to something easier to deal with. you'd still have to hand solder the part to that board, but you'd avoid needing to make a custom pcb just for a one-off. look up the name of the package in the gyro's data sheet and google that plus "prototyping board" or "breakout board" or whatever. might also be able to do a more targeted search on digikey's website (digikey is the poo poo for buying small quantities of stuff for proto)
|
|
#
?
Jan 6, 2017 19:15
|
|
|
BobHoward posted:look up the name of the package in the gyro's data sheet and google that plus "prototyping board" or "breakout board" or whatever. might also be able to do a more targeted search on digikey's website (digikey is the poo poo for buying small quantities of stuff for proto) yeah, the great thing about arduino and other intro-grade hardware kits is that they handle 99% of the digital abstraction for you. all the power delivery/bypass caps in place, all of the crystals properly shielded, etc. you write Wiring code, it toggles pins. fwiw, this was absolutely not the case in 2007 the downsides are cost and size. the breakout boards will be larger than you need and cost more than bare chips in bulk. also, arguably, the lengths that Wiring goes to maintain the abstraction go to far (e.g. calling PWM "analog") but that's not at issue for gonadic i've never personally soldered a component that small 
|
|
#
?
Jan 6, 2017 19:29
|
|
|
you can of course use arduino shields with other MCUs that don't have a dev environment with that amount of abstraction. just match the pin out and you're good to go with a giant ecosystem of breakout boards for prototyping. one example is STM's nucleo line for their ARM parts http://www.st.com/en/evaluation-tools/stm32-mcu-nucleo.html ps: be careful with digikey and dev boards. they sell my company's dev kits for close to 50% above MSRP, so double check the pricing on the kits. (the "production" hardware is the correct price of course) hobbesmaster fucked around with this message at 19:41 on Jan 6, 2017 |
|
#
?
Jan 6, 2017 19:38
|
|
|
gonadic io posted:I have a little gyroscope chip that I'd like to connect to a small pcb so I can mount it in the desired orientation. It doesn't have pins though, it looks like this: when i am doing hand assembly of QFN (quad flat no-leads) packages, i aim to: * when i design the board, expand the pads on the board for the part a bit so they extend comfortably past the part. this gives you a spot to heat up when the part is placed * dump a bunch of flux on the landing site * tin the pads on the board as evenly as possible * plop the part down, plausibly with more flux * heat up the pad fingers on the board until they flow with the part * inspect under a microscope a bunch * retouch and remove solder where needed * do a lovely job cleaning it its better/easier to do it with solder paste, and you can even hand-dispense it without a stencil. proper stenciled solder paste and reflow is the best way to go but kinda overkill for a one-off thing for yourself. if you can get some paste on every pad and plop down the part, going around it with an iron will probably be sufficient to get a good flow
|
|
#
?
Jan 6, 2017 20:35
|
|
|
in terms of decoupling caps, the first thing i would do is check the datasheet for a typical application circuit or reference schematic of some form, which should include guidelines for decoupling the part. at 51 mA, .01 uF sounds insufficient to my intuition
|
|
#
?
Jan 6, 2017 20:36
|
|
|
i usually just pop in a 1-10µF 0603 ceramic unless the data sheet is very specific about what is needed
|
|
#
?
Jan 6, 2017 20:48
|
|
|
decoupling is actually a super-complicated topic - more uFs (uF uF uF) aren't always better remember: it's not the size of the capacitor, it's how you gently caress I'd plop down a 0.1uF in the smallest package you're comfortable with, right next to each power pin. if you need ~precise~ measurements, maybe add a 1uF and an 0.01uF in parallel
|
|
#
?
Jan 7, 2017 01:21
|
|
|
Poopernickel posted:decoupling is actually a super-complicated topic - more uFs (uF uF uF) aren't always better i do need as ~precise~ as possible, since in theory this is one day supposed to be a rocket guidance system: https://github.com/djmcgill/to-the-moon i will check the data sheet though. the chip arrived today!! but my anti-static wriststrap hasn't though so i can't open the bag. i really am starting from nothing here.
|
|
#
?
Jan 7, 2017 01:34
|
|
|
lol an anti static strap, look at this noob
|
|
#
?
Jan 7, 2017 02:44
|
|
|
gonadic io posted:I have a little gyroscope chip that I'd like to connect to a small pcb so I can mount it in the desired orientation. It doesn't have pins though, it looks like this: The dead bug style (upside down with flying leads soldered to the chip) is okay for prototyping. QFP can still be hand soldered in the proper orientation though, unlike BGA or w/e.
|
|
#
?
Jan 7, 2017 03:38
|
|
|
ESD is a myth
|
|
#
?
Jan 7, 2017 07:55
|
|
|
hobbesmaster posted:lol an anti static strap, look at this noob Bloody posted:ESD is a myth brb putting on my woollen jumper, playing with my cats and some balloons, moonwalking across my carpet and then working with this £50 chip
|
|
#
?
Jan 7, 2017 08:41
|
|
|
gonadic io posted:brb putting on my woollen jumper, playing with my cats and some balloons, moonwalking across my carpet and then working with this £50 chip video pls
|
|
#
?
Jan 7, 2017 08:45
|
|
|
gonadic io posted:brb putting on my woollen jumper, playing with my cats and some balloons, moonwalking across my carpet and then working with this £50 chip just touch a piece of metal after you sit down
|
|
#
?
Jan 7, 2017 09:18
|
|
|
Poopernickel posted:decoupling is actually a super-complicated topic - more uFs (uF uF uF) aren't always better it is complicated when you're driving high speed FPGAs that don't have internal decoupling or you have a ton of high speed unbalanced digital I/O to consider of course for those caps to have any effect you'd need a power+ground plane on the board to match, and if you're dead bugging an IC on a prototyping board the wires between the board and IC will add so much inductance that the sick gains from using a beautifully calculated broad band 0402 or 0201 packaged decoupling network with power plane capacitance will be completely irrelevant and there's two sides of the same issue here; one aspect is making sure there's a PDN with a low enough impedance at all frequencies the devices under load needs to operate and drive I/O without di/dt related voltage drops, the other is making sure the incoming power supply doesn't have a bunch of switching noise from other devices on the same rail for a gyroscope the output is probably analog or some slow interface like I2C/SPI and it might make more sense to put a dedicated linear regulator + some series resistance/inductance near it, along with whatever decoupling the device + regulator needs
|
|
#
?
Jan 7, 2017 12:58
|
|
|
i got a risc-v microcontroller board in an arduino form factor today maybe i'll even find some time to do something cool w/ it
|
|
#
?
Jan 9, 2017 15:01
|
|
|
my zero should be arriving today! i already wrote some (rust) code for it, based off the great hannobraun.de/embedded/ that's for a duo though, so none of the memory addresses are the same (which I looked up from the data sheet). hopefully it'll work.
|
|
#
?
Jan 9, 2017 15:03
|
|
|
good luck! just curious, how nicely does rust play with gdb/lldb?
|
|
#
?
Jan 9, 2017 20:49
|
|
|
JawnV6 posted:good luck! seems fine, i've not tried it: https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html
|
|
#
?
Jan 9, 2017 21:04
|
|
|
gonadic io posted:seems fine, i've not tried it: https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html wheres he talk about gdb? openocd+gdb is finicky with supported languages, I couldn't imagine it with unsupported ones. edit: actually rust is supported by gdb now so it may not be as bad as I thought hobbesmaster fucked around with this message at 23:33 on Jan 9, 2017 |
|
#
?
Jan 9, 2017 23:31
|
|
|
JawnV6 posted:good luck! rust uses LLVM for the backend, right? so LLDB should be along for the ride in a pretty straightforward fashion especially since all of the changes to enable Swift support are really more about changes to enable support for languages that aren't subsets of Objective-C++
|
|
#
?
Jan 10, 2017 04:07
|
|
|
i thought lldb couldn't handle embedded targets?
|
|
#
?
Jan 10, 2017 04:15
|
|
|
hobbesmaster posted:i thought lldb couldn't handle embedded targets? depends on the embedded target it can speak the gdb remote serial protocol and if it has support for your architecture/ABI/object/debug format (e.g. ARM, ARM ABI, ELF, DWARF) you can do an awful lot with it and you can add any missing bits in a pretty straightforward fashion, the system is pretty modular, it's just if you need to add an entirely new architecture that things get hairy because you basically have to add that to LLVM (so no 68K LLDB support yet, alas)
|
|
#
?
Jan 10, 2017 10:51
|
|
|
eschaton posted:depends on the embedded target yo out of curiosity how required would something like https://github.com/blacksphere/blackmagic/wiki is this just adding an interface that you can already get elsewhere a different hardware option, or is it literally something that you couldn't do without it if you were trying to do remote debugging?
|
|
#
?
Jan 11, 2017 08:32
|
|
|
im going insane here trying to get rust onto my arduino zero. this c program, when uploaded via the arduino IDE, turns the led on: code:code:code:i can't really read assembly, but from what I gather movw r0, #17416 ; 0x4408 movt r0, #16640 ; 0x4100 mov.w r1, #131072 ; 0x20000 str r1, [r0, #0] really should be doing what I want for the first instruction?? so what's going wrong?? e: also i'm uploading them the same way using the bossac bundled with the arduino IDE gonadic io fucked around with this message at 23:22 on Jan 14, 2017 |
|
#
?
Jan 14, 2017 23:20
|
|
|
well does the c bin look any different? does the base address match on the c bin and the rust one? edit: bins don't have addresses, is there a hex or something? hobbesmaster fucked around with this message at 23:31 on Jan 14, 2017 |
|
#
?
Jan 14, 2017 23:29
|
|
|
now that i think about it, it's only the c version the IDE uploads that works not my self-compiled c version. i checked the logs though, and the arduino one does "arm-none-eabi-objcopy" -O binary "[...]/Blink2.ino.elf" "[...]Blink2.ino.bin"" too. i'm trying to inspect the .ino.bin file that gets uploaded though (the IDE one that works), and readelf and objcopy both choke completely with "readelf: Error: Not an ELF file - it has the wrong magic bytes at the start" and "File format not recognized" which is weird. but i looked and the ide compiles with arm-none-eabi-g++ -mcpu=cortex-m0plus -mthumb which im doing so i have no loving clue what's going on
|
|
#
?
Jan 14, 2017 23:58
|
|
|
A few things to check - Is the vector table getting emitted at 0x00000000? The NVIC will read the first word of that table to determine where to jump. I'm guessing this chip is a Cortex-M, which means it only supports Thumb instructions, which in turn means that the jump address needs to have its lsbit set to 1 to indicate Thumb mode. If your vector table is just zeros then it'll get stuck in an infinite exception loop because it'll try to jump to 0 in non-Thumb mode to start execution. Which would almost work, seeing 0 is a NOP on ARM (i think) which would unintentionally NOP-sled you all the way to Reset_Handler, except for the fact that your instructions are Thumb instructions and also Cortex-M chips are only capable of decoding Thumb instructions anyway, so any attempt to execute non-Thumb instructions is an error. Try $ objcopy yourprogram.elf -O binary yourprogram.bin $ hexdump -C yourprogram.bin and see if there's a vector table at the beginning. - Some micros (well, EFM32 does, idk about any others) need you to open a clock gate to the GPIO unit before it will respond to register accesses. Check your micro's reference manual to see if this is the case.
|
|
#
?
Jan 15, 2017 00:04
|
|
|
i think that i'm just missing system init maybe? that still doesn't explain why the "official" bin file won't open in objdump or readelf
|
|
#
?
Jan 15, 2017 00:05
|
|
|
that asm is correct but not enough by itself to execute a program. is there a vector table section? you need it to reach the program entrypoint. if you don't the mcu will just enter a lockup state and halt. the vector table is address 0. first word is the initial stack pointer, second is the reset entrypoint. edit: actually that code is ARMv7-M but the M0+ only supports ARMv6-M. that asm will hardfault Spatial fucked around with this message at 00:10 on Jan 15, 2017 |
|
#
?
Jan 15, 2017 00:07
|
|
|
gonadic io posted:i think that i'm just missing system init maybe? that still doesn't explain why the "official" bin file won't open in objdump or readelf a BIN file is a raw image of the contents of a chip, stripped of all its metadata. an ELF file is a metadata-rich structured data file which can be converted into a BIN file but not vice versa. edit: It's the same sort of thing as a Windows EXE.
|
|
#
?
Jan 15, 2017 00:08
|
|
|
gonna be honest with you here this is really basic stuff that you need to understand before you start programming microcontrollers playing around with Rust will just complicate matters, stick to C until you get a better handle on what's going on. Happy to answer any further questions though.
|
|
#
?
Jan 15, 2017 00:09
|
|
|
compiling for the right platform is also a good start 
|
|
#
?
Jan 15, 2017 00:12
|
|
|
|
| # ? May 16, 2024 21:27 |
|
|
well no afaict the platform is right but there is no vector table. How to emit that depends on the toolchain being used and what its linker script looks like.
|
|
#
?
Jan 15, 2017 00:16
|
|