|
The first intern prototype was derailed for a week when their cheap arduino knockoff turned out to nonfunctional. Was one of those onion peeling weeks when they finally traced it back to the cheap board not having the right parts on it. So I'm a little wary of going that route  I want to do a rewrite in C actually. The EE's time is more constrained than mine. I've been working in the comfort of managed languages and IDE's too long, need a return to the basics.
|
#
¿
Oct 16, 2013 21:36
|
|
|
|
| # ¿ May 13, 2024 03:03 |
|
|
Thanks for the advice. AVR Dragon and some bare atmega328p's on order. Confused that digikey couldn't get them here today, but tomorrow's good enough.
|
|
#
¿
Oct 17, 2013 16:53
|
|
|
Slanderer posted:Be real careful with those AVR Dragons---they are really easy to kill. Presumably it's just ESD or something, but a lot of people have had those randomly die. A lot don't, but still consider getting/making a case for it. Slanderer posted:Personally, I've always been just fine with the AVR ISP mkii.
|
|
#
¿
Oct 17, 2013 17:57
|
|
|
Got the Dragon wired up and verified it's programming the chip with a meter. Biggest obstacle was the stupid DIP package. Will be doing a proto breadboard tomorrow to check if it's better to use the ADC input or a clock line and the I/O might be complicated by how the LED's are driven. But so far so good on step 1 of the process Thanks armorer, I referred to your earlier post once I had it wired and ready to test.
|
|
#
¿
Oct 18, 2013 00:47
|
|
|
SPI was my guess.
|
|
#
¿
Oct 31, 2013 19:50
|
|
|
Anyone have a good resource for learning BLE? I have a TI dev kit. I was thinking it would be easy enough to start by capturing the boards discovery/connection sequences. This was confounded by a few things. The first being when I turned on the sniffer, it was immediately flooded by the hundreds of BLE devices my coworkers have lying around advertising themselves. This wouldn't be so bad but the packet sniffer software doesn't allow for crazy filtering tricks like "!=" or "OR" so I can't easily filter out the two devices I want. So I'm reluctantly left with having to learn something from reading about it instead of mashing around a working system. I've looked over the iOS and Android resources for the host side, but I'll be doing a lot more work on the device side. The TI docs are a good start and I'm sure they'll do the job, I'm just curious if anyone had a good reference.
|
|
#
¿
Nov 6, 2013 21:17
|
|
|
You can totally slim down the dev process to gcc and a serial programmer. I'd be very curious how you plan to debug anything nontrivial with that setup though. Debugging in an IDE with breakpoints and awareness of your code will take a fraction of the time compared to debugging with LED's providing bits of information about what's going on inside.
|
|
#
¿
Nov 14, 2013 19:49
|
|
|
I had a +5V rail drooping that was causing the ADC reading referenced against another plane to come back a little goofy. Of course, it didn't manifest in any sensible way the device just kicked into the next stage of operation. The ADC reading wasn't the only possible transition, it wasn't 100% fail, etc., so it took some onion-peeling to root-cause it. You can totally figure that out with a multimeter, an array of LED's to show the 12 bit ADC reading (once you somehow figure out that's what's going on) along with the state machine position and a dozen other triggers. But sweet jesus why would you subject yourself to that instead of using a tool designed for explicitly this scenario? Corla Plankun posted:Maybe I have never encountered a nontrivial bug?
|
|
#
¿
Nov 15, 2013 01:10
|
|
|
Sorry, I don't mean to sound so snippy. It's just that debug is very, very important. Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging can easily get to the 90% mark on a project without any red flags then have horrendous integration debug because they can't easily peek at what the software's doing. At that point it's a difficult decision between engineering a one-off solution with an oscilloscope and hardware or changing the entire toolchain. Neither impossible, but I wouldn't want to implement either right up against a deadline. Notice that everyone who said IDE's weren't necessary backed it up with very good practices. Unit tests, strict development, etc. It takes some expertise to figure out when a debugger isn't necessary.
|
|
#
¿
Nov 15, 2013 20:30
|
|
|
armorer posted:I take a bit of offense to the statement "Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging..." because it really isn't like that in my industry. Some of the developers I know who have the best practices work in vi or emacs on linux. When they need to debug something, they dust off Eclipse (typically) and use it just for the debugger. They have just internalized the keyboard shortcuts and general mindset of their preferred editor to the point where their productivity is severely impaired using anything else. I don't really follow. "Programmers from cmdline linux land who think they can get by with shoddy practices and printf debugging" is distinct from "programmers from cmdline linux land who use good practices and reach for debuggers when appropriate".
|
|
#
¿
Nov 15, 2013 21:06
|
|
|
evensevenone posted:I kinda think that if your workflow requires that you spend a lot of time pressing F7 and watching numbers change in a watch window to figure out what your code does, you must have some pretty shoddy development practices. armorer posted:I don't think anyone will object.
|
|
#
¿
Nov 16, 2013 00:22
|
|
|
Mr. Powers posted:Yeah, that's the trouble I've run into, although I have an EE background so it's not totally foreign, professionally I am a software engineer and the concepts are completely different. It helps having a team of FPGA guys at work to answer my questions. I know I'm veering into "uphill both ways" territory but I learned on a GUI and dagnabit that's good enough for everyone. You're describing how a circuit should be built, not creating a list of instructions.
|
|
#
¿
Dec 5, 2013 19:53
|
|
|
Right, I use a HDL for everything now. The biggest project I did purely by GUI was an embedded Tetris game, took a sega genesis controller and spit VGA out, stored the board in SRAM. But for learning purposes, telling everyone C is close will hamper more than help.
|
|
#
¿
Dec 5, 2013 20:05
|
|
|
Seconding the request for examples. Could also move discussion to the Verilog megathread.Mr. Powers posted:Also, that is a ridiculous project to do graphically. Then I got to watch as everyone who learned HDL's first go through a few rounds of "wait wait, I want to do it C-like!" until the differences finally sunk in. Starting from the C perspective seems like you'd just delay that learning and have a lot more stumbling along the way.
|
|
#
¿
Dec 5, 2013 20:39
|
|
|
evensevenone posted:You can totally skip the arduino editor and libraries and just write bare metal code. You basically have a working board with a USB port, a bootloader, and tons of peripherals, it's not that bad a deal.  I really doubt his choice of IDE is affecting the electrical connectivity all that much?Most shields I've dealt with are just pins that slide in. The easiest check would be to get a meter and ensure each pin is making contact. Beyond that, check the voltage your wall wart is delivering, check the +5 and +3.3 on the Uno without the shield, then check voltages on the shield itself.
|
|
#
¿
Jan 5, 2014 00:28
|
|
|
I'm working with the MSP430 and can't use the TouchPro GUI for Stupid Reasons. I loaded the firmware on the chip, tried to stream it through FTDI, but the tool's hardcoded to look for "MSP430..." COM ports that the launchpad provides. I'm not using the launchpad except to program the chip, I was unable to get the UART out through it, suspect it's the level shifting. This seems like an asinine problem to be having. edit again: yeah, the COM port isn't showing anything. I've installed CCS which should've handled the vcp driver, but nothing's coming out of it with any terminals i have around JawnV6 fucked around with this message at 00:11 on Jan 17, 2014 |
|
#
¿
Jan 16, 2014 21:38
|
|
|
Tiger.Bomb posted:It should be easy enough to RE the client to look for the name you want. I have a release at the end of next week so between doing legit work I know will ship out and faffing about with RE a .jar it's a pretty easy choice. Worst case we have a FAE visiting early next week who can hopefully do without the tool. I went through all the basic configurations (SM/A clk, 64/512/8192/32768) and none of them showed a great response. I sorta suspect the hardware, but it works decently enough from a stable voltage and clocked off the VLO. Not sure why TI's vcp wouldn't work. I reinstalled drivers, tried multiple launchpads, nothing. Eh, plenty of other concerns to mess with.
|
|
#
¿
Jan 17, 2014 17:15
|
|
|
I need a little utility to dump the flash off a connected MSP430 without disturbing it. This will be run by someone else out in the field, so the less complexity the better. It's totally fine for it to be cygwin->msp430-gcc, but if there's some way for CCS to do this out of the box that would be better. Nothing's jumping out at me besides hopping into debug mode (trashing whatever image is on the flash) and poking through the disassembly. Agents are waiting outside the warehouse and I need to send this interrupt.
|
|
#
¿
Jan 22, 2014 20:51
|
|
|
Found the magic google words to bring this up: http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer Works for me. Now I need to debug why it keeps crashing after a flash write, but I'm sure it's more of my stupidity.
|
|
#
¿
Jan 23, 2014 18:24
|
|
|
reading posted:When using CCS and working on TI uCs (specifically MSP430 and Piccolo) I notice that using a breakpoint (not sure if its hardware-breakpoint or not, just "breakpoint") and setting it to "Refresh All Windows" to update watched variables, I notice a lot of flickering on the actual device and debug LEDs when it runs. I'm working with Launchpads recently. The connection between the MSP and the 'emulation' side of the board is some 2wire interface with the test and ~rst pins. I'm programming an embedded device with ground, test and ~rst alone. I can't speak to your specific issue, but if you need to get a bunch of variables out of RAM and off the chip, your code can't keep crushing through. Getting a snapshot at that moment of execution requires each value to be sent over that interface. If you're watching the whole memory, my SWAG comes out to .05 seconds as a lower bound.
|
|
#
¿
Feb 5, 2014 01:04
|
|
|
Otto Skorzeny posted:the hardware guy on the project didn't want to use more pins My hardware guy didn't even give me LED's on the last board. 
|
|
#
¿
Feb 5, 2014 02:06
|
|
|
Is there a way to get TI's CCS to show me the assembly output without a target present? This is a stupid question but searches either end up on the Disassembly pane, which appears to require a target present to populate, or in Assembler-only project directions, which don't apply since I'm working in C. I have some questions about how things are getting laid out in memory that would be trivial to check if I had the assembly listing easily available.
|
|
#
¿
Feb 10, 2014 23:23
|
|
|
I'm not sure this is applicable, but when I've used the Dragon to program targets I've either powered it just from the Dragon or not connected the VCC at all. From here: http://www.atmel.no/webdoc/avrdragon/avrdragon.isp_description.html quote:When using off-board targets there should be no connection between the VCC header and pin 2 of the SPI header. It's confusing that you're powering it from both sides? Not sure if I just misread your description.
|
|
#
¿
Feb 21, 2014 21:30
|
|
|
I need a particular function to be easy to update. This is on a MSP430. I'll have a very, very narrow communication channel to a micro out in the field. It's low bandwidth and might get cut off with only half a message sent. There's one function that contains most of the sensing algorithm. I've already separated out the constants and stuffed them into their own segment. But for the function itself I'm not sure the best approach. By default, the compiler packs it in with the rest of the code. Right now it's taking up 0xe2 bytes, it's reasonable to assume it will stay under the size for a flash segment 0x200. The two main approaches I see are 1) Pin the entire thing out in memory, away from everything else, and rewrite it in place when required. 2) Set up a jump gate and point it to the shipped function, updates are done by writing the new function into memory, then updating the jump gate's segment e: welp, #2 was 3 lines of code leveraging function pointers, didn't even have to muck about linker maps e2: and victory declared all too early, quote:MSP430: File Loader: Data verification failed at address 0x00001000 Please verify target memory and memory map. e3: above was a debug setting in CCS, "erase main memory AND information segments" had to be set. now i'm mucking around in linking, because naively grabbing &sense_algo is showing up as 0xFFFF at the end of compilation. JawnV6 fucked around with this message at 19:54 on Feb 25, 2014 |
|
#
¿
Feb 25, 2014 19:02
|
|
|
Does PSoC Designer have any hotkeys, specifically "jump to definition"? I'm looking through someone else's code and keep banging F3/F12 to no avail. At this point I'd take a goofy alt-shift-meta combo to jump to where something's defined, but it's not even in the right click context menu.
|
|
#
¿
Mar 18, 2014 00:58
|
|
|
Otto Skorzeny posted:I don't know much about PSoC Designer (that's the IDE for PSoC 1 devices, right?), but PSoC Creator (for the higher end PSoC 3 and 5 devices) lacks it and it infuriates me. The go-to app engineer at Cypress for these sort of questions is Matt Landrum - he emailed me a week ago about a major update to PSoC Creator that's coming that's supposed to address some of its many deficiencies, maybe Designer is getting a facelift too? I dunno, I got roped into looking at some source to help our EE's out. PSoC Designer 5.4 is what the window's calling itself, I thought it was a PSoC 3 I was looking at. Thought it was just buried away, thanks for the dismal confirmation.
|
|
#
¿
Mar 19, 2014 21:56
|
|
|
Otto Skorzeny posted:What do folks here do for unit testing? I'd like to do more of it than I currently am I'm looking into TI's Debug Server Scripting at the moment. Not answering your question, just curious about other's experience solving this problem with this tool. I'm not crazy about testing embedded code with JavaScript of all things, but I've hit the point where I need to start testing some of the weird conditions this device will see and it appears to have all of the hooks I'll need to do it in the JS examples. They claim python compatibility, but without examples I'm thinking it'll be faster to modify the JS. Setting up a memory image and stubbing out the sensor data to read the values we pulled off the units live are the biggest opens at the moment. edit: jesus, this isn't unit testing, it's automating the debugger interactions with a live target JawnV6 fucked around with this message at 18:25 on Mar 28, 2014 |
|
#
¿
Mar 28, 2014 17:09
|
|
|
Joda posted:The problem arises because every particle has a life span, which is different between particle types, but constant for a single subclass of Particle, but the code for handling this lifespan is the same for all subclasses. Joda posted:I'm not sure if the way I've done it doesn't actually automatically store the life span in the program memory, but I have no reliable way of testing it, and since it's an actual field in the class, I would assume it does go in the SRAM?
|
|
#
¿
May 30, 2014 22:33
|
|
|
A MSP430 with a real time clock (RTC) would take less than 4 mAH over a year assuming some stupidly ideal conditions. That's about 1% of the worst AA you could find. A CR2032 coin cell would last 20 years. If you're using a whole board like a RPi or Uno, you're going to waste a lot of power on things you don't need. I'm seeing current numbers for the Uno around 31mA, meaning 1 year will cost you 271,000 mAH. Significantly more than a AA. Bottom line, you need to shoot for a shorter duration, supply external power, or change your electronics. What's the current failure mode of the safe if the battery runs out? Is it... fail safe?
|
|
#
¿
Jun 10, 2014 08:12
|
|
|
4 AA's won't last a year's worth of WiFi. And if you're inside a metal box the signal strength takes a pretty big hit (read: more power). You're back to a hard-wired connection or some goofy setup with a small window of time every day.
|
|
#
¿
Jun 10, 2014 10:58
|
|
|
That's a bit of a lovely spot. Dynamically jacking into something and trying to do a live trace seems much, much harder than any of: A) Do it in a VM, put hooks in the Host OS to do the tracing you need B) Do it in asm, using DR0-3 & DR7 to hook what you need C) Run it on Valgrind, get all the visibility you need
|
|
#
¿
Jul 15, 2014 19:21
|
|
|
No Gravitas posted:I'm getting my traces, I just need to store them. Where's the 20 bytes of storage/ 150bytes of data coming from? Do you have control over either of those? Can you shoot something out over a bus that you can sniff with something else? e.g. don't store anything, just shoot and isoch packet out over USB to something sniffing for it. Look into something like RLE. Don't store every event, store changes and timestamps. For debugging state machines it's very common, if you're ridiculously tight on space don't even store the state name, just number the arcs and be careful to capture everything from the beginning.
|
|
#
¿
Jul 15, 2014 19:51
|
|
|
I like the idea of a high reliability chip that lets me redefine which register has the PC in software.
|
|
#
¿
Aug 26, 2014 03:13
|
|
|
PDP-1 posted:Atmel Studio 6.2 (set up for an ATtiny24) is taking this ISR handler code This warning happened because TIM1_COMPA_vect wasn't defined. It thought you were declaring a new function, the warning was just a head's up that it thought TIM1_COMPA_vect was a variable declaration in the function header that it was inferring to be of type int. As EpicCodeMonkey mentioned, ISR's always have the signature of void func(void).
|
|
#
¿
Sep 24, 2014 19:39
|
|
|
Vibration motors won't give you positioning or tracking, but they might turn a static gravity-dominated thing into a quivering mass of eyeballs? Or look into making magnetic googly eyes. You've got enough lead time to looks at really cheap motors. Last time I was in Shenzhen I picked up 10 motors for less than a dollar.
|
|
#
¿
Sep 25, 2014 21:18
|
|
|
I have a BT radio paired to a phone. I have a WiFi radio. The phone is on the local WiFi. How ddo I get the wifi credentials from the phone to the device?
|
|
#
¿
Sep 30, 2014 18:31
|
|
|
I've seen example TI code that hits up undefined registers. The datasheet just didn't mention them, they weren't called out explicitly like that. Haven't gotten as far as the replacement code on a different micro running, but I'm curious to see if they're actually required or not. Maybe it blows up counterfeits.
|
|
#
¿
Oct 23, 2014 20:26
|
|
|
I'm trying to get to a working environment that involves as few vendor tools as possible. I want to have .c/.h files, run them through clang, then loaded onto a cortex M4 with as little headache as possible. How feasible is that? Are any particular vendors out of ST, Atmel, or Freescale that are better?
|
|
#
¿
Dec 2, 2014 03:36
|
|
|
My Rhythmic Crotch posted:Are you really cross compiling with clang? I was imagining vendor-specific header files, flashers, and dongles still being in the picture. Just something a little slimmer than a GUI that hides everything in that gap. I'm really comfortable on the MSP side. I'm using CCS for the debugger but have a complete flow without that. I've got something cross compiling with headers, not yet linking. Delta-Wye posted:My experience is that the things that makes C++ valuable over C (polymorphism, for example) come with undesirable run-time overhead.
|
|
#
¿
Dec 2, 2014 07:17
|
|
|
|
| # ¿ May 13, 2024 03:03 |
|
|
That's where I got last night, if nothing else clang is still relying on gcc's linker. Got the install off launchpad, have it working in cygwin up til some missing symbols. I should probably be looking at the plentiful examples of working gcc chains instead of banging on the Cube's generated output. I'm wary of GCC because I've seen it take missing semicolons and use Boost to turn that into pages and pages of template errors. e: got it working with gcc, thanks for the tips! JawnV6 fucked around with this message at 19:19 on Dec 2, 2014 |
|
#
¿
Dec 2, 2014 17:11
|
|