|
Fanged Lawn Wormy posted:
Becoming an embedded developer is a wondrous time in a young man's life. You may wake up one day to find hair where there was no hair before (neck)
|
#
?
Apr 8, 2015 00:53
|
|
|
|
| # ? May 16, 2024 00:05 |
|
|
Bloody posted:we're definitely hiring your type, where do you live and/or are you interested in relocating to boston area Fanged Lawn Wormy posted:i'm getting interested in taking the arduino training wheels off and using big boy developer tools for embedded systems that said, light blue bean is easier than arduino (literally program from your iPhone), then arduino, then these folks are a step up i'm inclined to second guess the supposition that your work isn't limited by arduino. it might be the case, or you might be solving problems inefficiently because of your limited tool set? a lot of embedded work is power saving, if you're always plugged into the wall it might be interesting to try to break that dependency, learn how to write to the flash segments and use a USB power brick to walk around with it
|
|
#
?
Apr 8, 2015 01:02
|
|
|
Mido posted:it depends where you are at, I learned a lot by just taking the programming manual for a SoC and making my own linker script and C bring up code with determination and self hatred and esoteric examples the avr gcc tool chain is relatively sane at least
|
|
#
?
Apr 8, 2015 01:03
|
|
|
hobbesmaster posted:start with the big AVRs that go in the arduinos... but you don't know any C? that may be a problem My only formal programming training was some VBASIC back in high school, of which I remember nothing. When I came to the company I'm at, they were using Basic Stamps for a lot of stuff, and so I learned a little PBASIC, but then as I worked with them I found them really slow and frustrating. I began to tinker with arduinos at home, Then we had a project come in that a stamp couldn't do, I proposed an arduino-based solution, and coded the whole thing. Mido posted:it depends where you are at, I learned a lot by just taking the programming manual for a SoC and making my own linker script and C bring up code with determination and self hatred and esoteric examples yah we have an EE at work who has done some stuff, but he doesn't program much. He's usually my unfortunate rear end in a top hat for transistors/circuit questions. JawnV6 posted:
yah I've seen tuts that basically allow you to pull the arduino training wheels into the avr toolchain, and I've considered giving that a try. As for limitations, I'm betting there are times I do things inefficiently... for context, I work at a company that does museum exhibits. I'm in the interactives department, so I do a lot of different things - installation of sound, video, lighting, dmx programming, and then the stuff i'm really getting interested in: electromechanicals like remote control boats or simple machines. so usually our programs are relatively simple: push button > do thing, keep an eye on the other parts of the system and be sure tanks aren't overflowing with water or whatever. so yeah there's a lot of times when it's like I could reduce the number of cycles for something to execute or something, but the visible benefits aren't super high. I've started writing some function libraries for my own use for future projects, and I think i'm going to start exploring the arduino internal libraries for basic functions to help myself get out of using them and writing my own i'm also trying to get the will to start bumbling around with python and a raspi, while also learning a few other things
|
|
#
?
Apr 8, 2015 02:13
|
|
|
Fanged Lawn Wormy posted:My only formal programming training was some VBASIC back in high school, of which I remember nothing. When I came to the company I'm at, they were using Basic Stamps for a lot of stuff, and so I learned a little PBASIC, but then as I worked with them I found them really slow and frustrating. I began to tinker with arduinos at home, Then we had a project come in that a stamp couldn't do, I proposed an arduino-based solution, and coded the whole thing. you have a cool job
|
|
#
?
Apr 8, 2015 02:19
|
|
|
IT IS LITERALLY THE BEST.
|
|
#
?
Apr 8, 2015 02:26
|
|
|
movax posted:so in a vivado zynq design, you can do a block design to easily stitch together axi peripherals and stuff so it turns out you can in theory work around this by doing everything in non project mode (ie you write your own tcl script to run synthesis/place/route which you invoke via "vivado -batch" so you never have to have the xilinx project structure). to make your block design work in that context you create it in a temporary project (which you need not ever check in) and then "export" it, which creates a bit of tcl that you can version control and invoke from your non-project synthesis script. the block design tcl script is basically a recording of the sequence of tcl commands the vivado gui used to create your block design as you were entering it, although it is at least smart enough to not preserve history (e.g. if you delete something it doesn't create it and then delete it). so you're version controlling a meta text file that generates the *.bd text file which in turn controls auto generation of hdl when you do it this way, all the *_design_auto_pc_N bullshit is created under a hidden (.xil or something like that) dir that's created inside your synthesis working directory, so you need not ever check it in. being xilinx, this option is poorly documented and doesn't work perfectly but is slowly, painfully rounding into shape over many more releases than you'd think would be necessary. quote:i'm this close to just cribbing off what adi did for their hdl libraries what did adi do for their hdl libs
|
|
#
?
Apr 8, 2015 08:59
|
|
|
Fanged Lawn Wormy posted:My only formal programming training was some VBASIC back in high school, of which I remember nothing. When I came to the company I'm at, they were using Basic Stamps for a lot of stuff, and so I learned a little PBASIC, but then as I worked with them I found them really slow and frustrating. I began to tinker with arduinos at home, Then we had a project come in that a stamp couldn't do, I proposed an arduino-based solution, and coded the whole thing. If you don't actually have to make a mass-produced product then throw Raspberry Pis at everything and save yourself the ballache of writing linker scripts and crts and clock tree initialization routines
|
|
#
?
Apr 8, 2015 18:19
|
|
|
if you want to learn this poo poo on your own time (please do not inflict your learning process on your employer, for them you should do some simple poo poo that might not be super optimally cost effective but that will at least actually work i.e. use a Raspberry Pi for everything) then i guess try the following: First, actually learn C in a cozy environment like a desktop IDE. Do not learn C++. Go to olimex.com and buy a board with an STM32 on it that you like the look of. Do some research, find a JTAG pod that will work with OpenOCD that you can hook up to your STM32 board. Do some research, learn how to build a cross GCC and Binutils toolchain targetting ARM (see if you can manage to do this without pulling in the Newlib libc) Read the datasheet for the STM32, learn how its address space is laid out, write a linker script (from scratch, most examples have a ton of ancient copy&paste cruft that hasn't been relevant since the 90s). Write a CRT (C Runtime). A CRT is a small chunk of code that sets up the CPU to the point where it can run ordinary C code. Microsoft are loving obnoxious and call their C standard library the "CRT", that's not wha a CRT is. Anyway. The STM32 has a Cortex-M3 CPU core inside it. One of the nice things about this CPU is that you can even write a CRT in C: all you really have to do is clear memory and then copy the initial values of your variables into RAM from ROM. Most of this stuff is googling but then that's what you're going to be doing a lot of anyway.
|
|
#
?
Apr 8, 2015 18:28
|
|
|
Mr Dog posted:if you want to learn this poo poo on your own time (please do not inflict your learning process on your employer, for them you should do some simple poo poo that might not be super optimally cost effective but that will at least actually work i.e. use a Raspberry Pi for everything) then i guess try the following: final step: utilize, understand and worship CMSIS, i never got here 
|
|
#
?
Apr 8, 2015 19:21
|
|
|
also: having an oscilloscope makes verifying your poo poo a lot easier, it's easy to sanity check your clocking by toggling a GPIO in a while loop and also debug a bus or two. i used the gently caress out of my scope to verify poo poo once i could run arbitrary c
|
|
#
?
Apr 8, 2015 19:22
|
|
|
never understood the fixation some people have on linker scripts and make files. you've got C and asm, and a bunch of knobs to fix the translation between them. becoming an expert knob maker doesn't help the final product as much as a half dozen easier things
|
|
#
?
Apr 8, 2015 19:37
|
|
|
or if you happen to use windows as your dev platform get avr dragon(or some ice( dragon has support for xmega and arm)) and atmel studio since you already have arduinos. this way you save some money starting to learn programming µCs(dragon is about 50$). you can use dragon also with gdb and eclipse iirc... but yes going with straight to gdb and makefiles teaches you more but atmel studio (  IMO) is shortest step to programming and debugging atmels (right tools for the right job and dont make it too complicated for yourself)OpenOCD/urJTAG can give you more flexibility choosing your target chips. and then there is the bus pirate/blaster(and like) route to programming different targets Choose your poison and drown to it while you reach for the second.
|
|
#
?
Apr 8, 2015 20:49
|
|
|
JawnV6 posted:never understood the fixation some people have on linker scripts and make files. you've got C and asm, and a bunch of knobs to fix the translation between them. becoming an expert knob maker doesn't help the final product as much as a half dozen easier things i dont think anyone should ever bother to make a linker file more than once, but it's a really good exercise to force you to understand how when you write C you aren't writing code in a vacuum there's a lot of poo poo across the full stack of your toolchain that eeks its way into the C you write even if you don't realize it, defining linker variables that point to blocks of memory and then referring to them in C basically make them one and the same
|
|
#
?
Apr 8, 2015 21:21
|
|
|
yeah im pretty good once it's in assembly or talking about memory, i guess that's my blind spot here still kills me to see college programs teaching makefiles before hello world, but w/e
|
|
#
?
Apr 8, 2015 21:25
|
|
|
C is a nightmare of a lang to do any project of scale in because of how loosely defined it actually is, and this fact can burn you really bad if you don't respect that fact every time you write code you are writing in a dialect the lang actively encourages you to write macros and elaborate generics that turn into your own bespoke dialect
|
|
#
?
Apr 8, 2015 21:27
|
|
|
doing the crt/linker script thing is whimsical but it really pulls back the curtain in a decisive way. Define a symbol for the interrupt vector table and a fixed address for it, set up sections for rom and ram then use them to define __bss_start and __bss_end or whatever. write a C file that defines this vector table and fills it with various function pointers (again, a reason why Cortex-M's NVIC owns), write a __start() in C that loops between __bss_start and __bss_end and zeros the memory out then calls main(). Write a non-recursive makefile to drive the compilation and linking process (and then copy and tweak this Makefile for every subsequent project you'll ever write until the day you die) and emit an ELF, then finally do an objcopy to convert the non-metadata parts of this file into a binary ROM image. Open the binary ROM image in a hex editor and gaze upon your work. Every byte of it is yours. There are no more training wheels, no more arcane magic that was once beyond your ken. There is only your creation sitting upon the machine's cold steel throne. Then learn the joys of gdb remote debugging and double and triple-checking your clock setup and GPIO port configuration code when you run the poo poo and the GPIO doesn't start blinking like it was supposed to 
|
|
#
?
Apr 8, 2015 21:29
|
|
|
Mr Dog posted:Open the binary ROM image in a hex editor and gaze upon your work. Every byte of it is yours. why aren't we pushing people to make their own flex/bison files for their C dialect? why not their own parser generator? what makes chucking more files at GCC some magical point that's Totally Real where an IDE isn't Mr Dog posted:Then learn the joys of gdb remote debugging and double and triple-checking your clock setup and GPIO port configuration code when you run the poo poo and the GPIO didn't start blinking like it was supposed to
|
|
#
?
Apr 8, 2015 21:37
|
|
|
JawnV6 posted:just use the friggin GUI with big red breakpoint buttons and arbitrary register/value tools. it drives me crazy to see people chase this fantasy that's Yet Another Abstraction then whine about all the problems they invited to their lap after pretending IDE's aren't "real" absolutely use IDEs and any tools that will make you not have to worry about that poo poo but understand wtf the IDE is and is not doing for you so you can make informed decisions when it comes time to troubleshoot issues in your toolchain or make future tooling decisions for various processors and stuff the ARM tools for eclipse have makefile generators that you can specify architectures for and overall it Just Works, even better if your mfg of choice has their own eclipsey plugins that will do their own linker script generation and generate boilerplate driver stuff for your SoC like interacting with the DMA engine or generating startup code for things like clocking changes you can wrap in a state machine
|
|
#
?
Apr 8, 2015 21:41
|
|
|
JawnV6 posted:except for the ones GCC emitted for you. "no, no, MY arbitrary point on this continuum is SO MUCH BETTER and LESS MAGICAL and ROBUST and ARCHITECTED" but but but back in my day we could only debug over JTAG using an oscilloscope on TDO and bare leads and a battery for TDI and TCK!
|
|
#
?
Apr 8, 2015 21:41
|
|
|
sadly i'm now curious to see whether that would actually work
|
|
#
?
Apr 8, 2015 21:41
|
|
|
yes hence why i said it's whimsical you could write an app in ARM assembly by hand too but that's probably taking it a bit far.
|
|
#
?
Apr 8, 2015 21:47
|
|
|
hobbesmaster posted:sadly i'm now curious to see whether that would actually work Mido posted:the ARM tools for eclipse have makefile generators that you can specify architectures for and overall it Just Works, even better if your mfg of choice has their own eclipsey plugins that will do their own linker script generation and generate boilerplate driver stuff for your SoC like interacting with the DMA engine or generating startup code for things like clocking changes you can wrap in a state machine really thought i spent 8 years in the silicon mines and ive got a pretty good grasp on what HW's doing
|
|
#
?
Apr 8, 2015 21:50
|
|
|
I didn't make any custom linker scripts or any of that kinda poo poo until I needed to. I mean the hardest thing coming from desktop world to embedded was interrupts and memory mapped I/O. Use an IDE it's fine and cool.
|
|
#
?
Apr 8, 2015 22:05
|
|
|
i dunno why you would do any of the bullshit described above when you can go download atmel studio 6.2 or whatever version they're on now, plug in a $50 debugger pod connected to a $30 eval board (or even just plug in one of the $30 arm eval boards that has a builtin debugger) make a new project and immediately be doing things there is no reason at all to go into linker scripts and openocd or whatever the gently caress for this. you're coming from arduino. there is no reason to do it the painful way.
|
|
#
?
Apr 8, 2015 22:13
|
|
|
i guess what im trying to say is if you're the p-langer type then by all means set up your bespoke linker scripts and makefiles and manually program bits into your microcontroller by manually toggling io lines (lol hope youve got schmitt triggers) but if you're just like "arduino is cool but i wish i had a bit more power/flexibility" then gently caress that noise, the tools are good, use them
|
|
#
?
Apr 8, 2015 22:16
|
|
|
thanks for all the thought, the hardware/software recommendations and such are really helpful. I think my next step will be atmel studio, but I may look into the makefiles and such. iunno if I want to do my own, but I like to see what's going on behind the curtains, even if I don't always understand it and yeah I wouldn't drag this poo poo into work unless we needed it for some special reason. when you are producing maybe 6-10 of a particular machine at most, it's usually best to just have some off-the shelf blocks that snap together. Thus the use of arduino: it's fast, easy, and has tons of libraries and stuff already around. We use a special breakout shield I designed to tie in to our other equipment - relays, input isolators, etc. We use prototyping pcb services a lot because it allows us to get a batch for a particular job, and then improve on it for the next without ending up with a lot of overstock of 'that board that seemed really good in theory but wasn't in service'
|
|
#
?
Apr 8, 2015 22:49
|
|
|
Mr Dog posted:Do some research, learn how to build a cross GCC and Binutils toolchain targetting ARM (see if you can manage to do this without pulling in the Newlib libc) if you're dealing with something like an ARM then it's worthwhile to also look at clang for cross-compiling, it's pretty well-supported on ARM (as you might expect), it's straightforward to build, and it has its own compiler runtime that doesn't suck (including licensing) for all of the compiler-support stuff. you'll still have to provide your own C runtime, but that's part of the fun, isn't it?
|
|
#
?
Apr 9, 2015 02:42
|
|
|
eschaton posted:if you're dealing with something like an ARM then it's worthwhile to also look at clang for cross-compiling, it's pretty well-supported on ARM (as you might expect), it's straightforward to build, and it has its own compiler runtime that doesn't suck (including licensing) for all of the compiler-support stuff. mbed is cool for arm if you're just loving around
|
|
#
?
Apr 9, 2015 04:48
|
|
|
movax posted:don't even get me started on trying to version control the shitshow that's version controlling the export process over to their sdk tool as well (an eclipse-based system) I literally just got that flow working for me today - do you have any questions / are you stuck?
|
|
#
?
Apr 9, 2015 07:26
|
|
|
JawnV6 posted:lmao oic design and test everything in systemverilog, god's own language.
|
|
#
?
Apr 9, 2015 07:55
|
|
|
i wanna put iHDL and protocyte on my resume to see if anyone can come up with a whiteboard problem across two dead languages
|
|
#
?
Apr 9, 2015 15:53
|
|
|
JawnV6 posted:i wanna put iHDL and protocyte on my resume to see if anyone can come up with a whiteboard problem across two dead languages interview question: "if you were to interview a candidate with two dead languages on their resume what would you ask them?"
|
|
#
?
Apr 9, 2015 15:58
|
|
|
JawnV6 posted:no, no, no, suffering Must Be Better. any Tool is an Abomination and must be abhorred. for any given protocol if you don't write a bit-banging version first you can't possibly understand how to use a HW module that does it for you i implemented 1wire with just TI's documentation and my scope to verify timing, that was a hell of a bit bang edit: to clarify 1wire is some baby poo poo i just had never done anything like that, since you have to flop the GPIO from input to output and read things in sensitive timing ranges and dumb basic poo poo i'd never done a cyberpunk goose fucked around with this message at 18:23 on Apr 9, 2015 |
|
#
?
Apr 9, 2015 18:17
|
|
|
Mido posted:that was a hell of a bit bang .text me
|
|
#
?
Apr 9, 2015 18:20
|
|
|
hobbesmaster posted:interview question: "if you were to interview a candidate with two dead languages on their resume what would you ask them?" those two? "why was domino logic natively supported?" and "why was the threading model for checkers utterly broken?"
|
|
#
?
Apr 9, 2015 18:42
|
|
|
|
|
#
?
Apr 14, 2015 23:01
|
|
|
keeping this thread aliveStar War Sex Parrot posted:current school status: TTCR1B = (1 << CS12 | 1 << CS10 | 1 << WGM12);
|
|
#
?
Apr 16, 2015 06:13
|
|
|
JawnV6 posted:i live in sf and/or "no" how do you feel about seattle? BobHoward posted:what did adi do for their hdl libs basically exactly what you described and what i haven't had the time to do; maybe i'll just have to sit down one weekend and burn that on transferring my project over to a purely tcl-driven flow. it only took me a day or two to do that for the microsemi stuff, which wasn't too bad.
|
|
#
?
Apr 16, 2015 06:17
|
|
|
|
| # ? May 16, 2024 00:05 |
|
|
JawnV6 posted:i live in sf and/or "no" how do you feel about mountain view and/or satan clara
|
|
#
?
Apr 17, 2015 09:25
|
|