|
From a practical/security standpoint, you're worsening the security of the safe significantly by adding an extra way to get the safe open. I'm willing to bet that your insurance would refuse to cover its contents if they found out about it.
|
# ? Jun 10, 2014 21:06 |
|
|
# ? May 9, 2024 21:43 |
|
ante posted:Big drill bits can definitely fit kibbles in the flutes. Gesundheit!
|
# ? Jun 10, 2014 21:33 |
|
ante posted:Big drill bits can definitely fit kibbles in the flutes. https://www.youtube.com/watch?v=s-mOy8VUEBk
|
# ? Jun 10, 2014 21:38 |
|
Tiger.Bomb posted:From a practical/security standpoint, you're worsening the security of the safe significantly by adding an extra way to get the safe open. I'm willing to bet that your insurance would refuse to cover its contents if they found out about it. Its an electronic safe with a keypad, I am planning on removing the functionality to that and replacing with an internet enabled system that allows you to remote unlock and set timelock thus increasing the security as the timelock function would mean it would only open at certain times and not be easily changeable. Of course if i really wanted to make it more fun i could add GPS and 3G connection allowing it to be tracked if stolen. and it will be used as a keysafe holding other keys - for instance that the cleaner can get the house keys out only at the agreed times.
|
# ? Jun 12, 2014 09:33 |
|
If you could feed in a few wires for I/O and power you could have the microcontroller, battery backed RTC and the lock actuator live inside the safe, but reliant on the outside world. Power and RF wouldn't be an issue. You'd have to plug it in, feed it an unlock code, a GPS NMEA string within its geofence, etc., to do anything.
|
# ? Jun 12, 2014 16:43 |
|
Thought I would post this little duder: It's a little dev board I designed for the dirt-cheap Kinetis KL26z series. I forgot the pullup on the reset pin, that's what the tacked on resistor is for. I'm using the FRDM-KL26z as a programmer/debugger as these instructions show. This repository does have a barely functional USB CDC (virtual comm port) but it is for the 25z, not the 26z. It shouldn't take much work to get that ported to the 26z. Though the cheapest 26z chips (which cost under $2 in singles) only have 4KB of RAM, so I'm not sure how well that will work.
|
# ? Jun 21, 2014 02:20 |
|
Time for a very specific question: I'm working on a project with 2 microcontrollers (STM32F400 and STM32F300 series) and like 4 independent power sources. However, I currently don't have the ability to load code via the bootloaders, so it's JTAG all the way for now. However, since most of the time I'm not using a debugger for debugging (I'm making optimized builds that don't debug well anyway), I need to remove all 4 power sources from the device (which takes a minute or two) every time I load new code onto one of the microcontrollers. I'm using IAR embedded workbench with a J-Link debugger (pretty standard). Anyone know if I can set it up to start the CPU automatically after downloading? If I were doing this from the command line utility it would be trivial...
|
# ? Jul 9, 2014 16:53 |
Slanderer posted:Time for a very specific question: I've never seen an option for that. If you disable run to main, it will just stop at your reset vector. You may be able use a C-SPY macro file to do this, but I'm not familiar with the macros beyond displaying some info on log breakpoints. There's probably a resume directive and you can just put it in your debugger .mac file.
|
|
# ? Jul 9, 2014 17:05 |
|
Continuing this discussion.Internet Janitor posted:Do the VM and user code have to fit inside 768 bytes, or do you have more flash space for code and that budget is strictly your working RAM? In the final version the constraints won't be so tight because the VM/firmware code will be in ROM, which there's a reasonably generous amount of. But during development it has to fit in SRAM if we want to run our code on the real device and have customers play with it. We don't have flash in this part. My current design is about 450 bytes including working memory, so not too bad. My main design goal right now is to make the language more friendly. At the moment users deal directly with four GP registers and two load/store memory address registers. There are no expressions or subroutines and no stack. This makes for a fairly simple compiler and a miniscule bytecode format, but it's not great to work with. Thanks for the heads up. I think I might be using token threading already - the VM works by masking off bits of opcodes and indexing into a jump table. I'll look into using a stack machine as well.
|
# ? Jul 9, 2014 17:11 |
|
Mr. Powers posted:I've never seen an option for that. If you disable run to main, it will just stop at your reset vector. You may be able use a C-SPY macro file to do this, but I'm not familiar with the macros beyond displaying some info on log breakpoints. There's probably a resume directive and you can just put it in your debugger .mac file. I looked at the macros and tried issues a reset at different times (after the flashloader, at least in theory) but it wasn't working out... Then I figured out that I can semi-reliably reset the CPU by one of the following: disconnecting from the jtag port connecting to the jtag port disconnecting my debugger from USB connecting my debugger from USB It's not consistent (reset lines are weird idk), but it's good enough for me.
|
# ? Jul 9, 2014 20:37 |
Slanderer posted:I looked at the macros and tried issues a reset at different times (after the flashloader, at least in theory) but it wasn't working out... Looking at a macro file I have, execUserSetup should execute after download, you could either send a GDB command with __gdbserver_exec_command or you could try __hwReset with a halt time of a big number.
|
|
# ? Jul 9, 2014 21:07 |
|
Spatial posted:Continuing this discussion. Even if you do t use forth look at how forth was built to get compact code
|
# ? Jul 10, 2014 00:22 |
|
Spatial: The really key invention in Forth is the use of a dual-stack architecture. One stack stores return addresses for subroutine calls and the other is used as an argument-passing mechanism for subroutines. By disentangling these you can eliminate the need for "stack frames" and a good deal of the bookkeeping involved in subroutine calls with a C-style calling convention. This ends up both simplifying the compiler enormously and reducing the complexity of your bytecode. The stacks don't have to be particularly large, either- 10 to 20 words of memory each is sufficient for fairly complex embedded applications.
|
# ? Jul 10, 2014 19:19 |
|
I went off and compiled some code by hand for a dual stack VM and the results are very promising. Small, simple and powerful is exactly what I need. Thanks dudes.
|
# ? Jul 10, 2014 23:23 |
|
This is probably really loving stupid, but what the hell! While this has precisely zip to do with embedded anything, the constraints I have to work with is something that you guys may be able to help with. This isn't your regular programming and MCU techniques will be a must. I'm aiming for labour saving. I can do this stuff by hand, but I'd like to save time and save myself making lots and lots of errors. I have an application which gathers data. It will produce too much data for my memory, so disk storage is a must. The data gathering will run on Windows 32-bit and the processing will run on Linux 64-bit. Per every data item I have 20 bytes of disk to store the whole thing. The data content is not set in stone yet, but will be about 100-150 bytes per item. Compression is a must, but thankfully the data is very repetitious. C is the only language I can use. Finally, and probably the worst thing of it all: I cannot use any standard libraries during the gathering stage. I can probably use newlib to get around that to a degree and make my own stdlib within the retarded setup I have to cope with. The system is not networked. Are there any MCU databases/key-value stores/etc...? With compression? Which can run on Windows and Linux? Which will handle the data portably across different sizeof(void*) systems? Yeah, I know it is a loving long shot, but what the hell... why not! Good for a laugh if nothing else!
|
# ? Jul 15, 2014 06:30 |
|
Maybe one of these libraries would work for you?
|
# ? Jul 15, 2014 10:54 |
|
No Gravitas posted:This is probably really loving stupid, but what the hell! What led to your weird constraints about language and library usage? Is your boss the PHB from Dilbert?
|
# ? Jul 15, 2014 14:33 |
|
e: doppelposten
|
# ? Jul 15, 2014 14:47 |
|
No Gravitas posted:This is probably really loving stupid, but what the hell! sqlite
|
# ? Jul 15, 2014 15:50 |
|
Otto Skorzeny posted:What led to your weird constraints about language and library usage? Is your boss the PHB from Dilbert? No, I'm my own PHB. I'm doing some seriously great science. The tools are the restriction. DynamoRIO is great fun, but you need to play along. See, this isn't a standalone program. This is about dynamic binary instrumentation. There is an application running and I'm gathering data on it. I do this by attaching to it in a goofy way (recompilation!) and I cannot use the stdlib as a result. There are two applications trying to exist in one process and for each instruction of my "victim" I execute a ton of my own code. If the "victim" is doing malloc and I also do malloc then bad things will happen. I have to use allocation and IO primitives provided by Dynamo, those are safe and work portably on Windows and Linux. Dynamo uses C as the language of choice. I could probably make it work with C++, but it may be messy. Just as well, I don't know how I'd avoid "new" and "delete" otherwise. And I don't know C++ well at all. Finally, the compression is because the disk on the machine I'm using is small for the amount of data I'm gathering. Thanks for the link to LZO, that is a good one. Looks like Sqlite may be it. Portable! C! Slow on the inserts but I have the time. Only... How do I portably compress the databases without spending 2k$ on addons... Ah well... Start with small datasets I guess! Thanks! Nanopb looks interesting too. If Sqlite is too slow I may use that.
|
# ? Jul 15, 2014 18:59 |
|
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:No, I'm my own PHB. I'm doing some seriously great science. The tools are the restriction. DynamoRIO is great fun, but you need to play along. See, this isn't a standalone program. What's up, dynamic analysis buddy? I do my dynamic analysis work at the system level (modified QEMU), but there is that awful semantic gap problem to work around. Usually, I see people working with DynamoRIO and Pin for process-level stuff. It is an interesting area, to be sure. Lots of good binary analysis research going on using those tools, too.
|
# ? Jul 15, 2014 19:39 |
|
JawnV6 posted: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) Using a VM is right out, sadly, for the final deliverable. Maybe I will look at it again. Also, kinda too baked-in for that though. I'm getting my traces, I just need to store them. B) I want to finish this by the end of term, to meet publication deadlines. This is a month. Writing and debugging asm is a no-go. C) Does not run on Windows, game over. Thank for the suggestions though. hendersa posted:What's up, dynamic analysis buddy? I started on Pin, went over to DynamoRIO because it is so much faster for my needs. Instrumentation latency matters! And then I just kept using it. It seems so much more technologically advanced and quite well designed. The docs suck though! No Gravitas fucked around with this message at 19:47 on Jul 15, 2014 |
# ? Jul 15, 2014 19:40 |
|
No Gravitas posted:C) Does not run on Windows, game over.
|
# ? Jul 15, 2014 19:47 |
|
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 |
|
How structured are the 150 byte packets?
|
# ? Jul 16, 2014 01:53 |
|
fritz posted:How structured are the 150 byte packets? Here is what I have after a major redesign: 1. A running count. Often close to the previous entry, but no guarantees. 2. A pointer. Low bytes unpredictable, high bytes almost always same. 3. Zero or more bytes, up to five. Usually two. 4. Zero or more bytes, up to five. Usually one. 5. Zero or more pointers, up to an arbitrary amount. Anything above one is extremely unlikely. Usually one or zero. 6. Zero or more pointers, up to an arbitrary amount. Anything above one is extremely unlikely. Usually one or zero. 7. Required extra data - a few bytes utterly unpredictable. I have no idea how to handle those variable-sized bits nicely. It would be nice to merge some element counters. Another obvious place to save space: A lot of duplication between 3/4 and 5/6. The entries could be disambiguated by a bit each, but variable size bitmaps are scary? Another thing is the count. I need it, but feel like I should not. Current estimate: 28 bytes per record on average and I'm recomputing a lot of stuff in post. I just hope I did not trim too much. Still a bit shy of my goal, but small experiments should fit now.
|
# ? Jul 16, 2014 05:57 |
|
You might have good success with repeatedly applying a byte-oriented LZ compressor. Someone shrunk a 3.5GB log file down to 750KB by repeatedly compressing it.
|
# ? Jul 16, 2014 06:15 |
|
Attach a usb hard/flash drive to the windows 32bit system. Honestly, I understand you've got all these weird requirements. And I've been in that situation where I'm just looking for a specific answer and everyone wants to answer different questions. But... you've given no reason why, in the day of 4TB hard drives, you cannot just fix the storage problem. Unless by 'Windows 32bit' you mean Windows 95, and even then you should have the possibility of adding an IDE drive. I just can't wrap my head around how "I have a month to finish my research... time to develop an all new compressed storage format!" happens instead of "... time for a bigger hard drive."
|
# ? Jul 19, 2014 14:32 |
|
Rescue Toaster posted:Attach a usb hard/flash drive to the windows 32bit system. Easy answer: Politics. As annoying as you'd imagine. I'm working on it, but it ain't going anywhere. It ain't just about one system, reduce costs, blah blah blah. EDIT: To clarify: I'm my own PHB, but the exact hardware is what I'm given to work with. And the supervisor does not think the same way as I do. I wish I could toss some money into this and be done. He wants something more impressive for the paper. Academia is a bitch. Run, if you can. No Gravitas fucked around with this message at 18:11 on Jul 19, 2014 |
# ? Jul 19, 2014 16:33 |
|
Mostly finished a side project I'm working on, just waiting on some final connector specs: dmx512 controlled interface for a laser + 3 motors. should be a fun sw project writing the dmx512/rdm slave interface code. Purple to simulate the prototypes from OSH Park; expecting finals to be matte black.
|
# ? Jul 20, 2014 03:24 |
|
No Gravitas posted:Looks like Sqlite may be it. Portable! C! Slow on the inserts but I have the time. Only... How do I portably compress the databases without spending 2k$ on addons... Ah well... Start with small datasets I guess! Thanks!
|
# ? Jul 21, 2014 21:47 |
|
One Eye Open posted:You could look into this compression library for sqlite. It uses zlib and comes with source. Thanks, but I just managed to make it all fit. More recalculating in post, but it works out now!
|
# ? Jul 22, 2014 03:07 |
|
No Gravitas posted:Thanks, but I just managed to make it all fit. More recalculating in post, but it works out now! OK so the standard trick (what SQL server/vertica do, at a high level) to doing this is to store it column oriented and then if you can run differences for as long as possible to reduce magnitude, then compress that with something like eg lzma/lz4
|
# ? Jul 22, 2014 12:13 |
|
Can anyone comment on the diffences/step change between programming and development on Arduino and on an Mbed style device? I've seen a prototyping board that could suit a need I have for rapid detailed calculations but my only experience up to now is making stuff work with Arduino.
|
# ? Jul 27, 2014 13:33 |
|
For a half way approximation, you could ignore the Arduino GUI and build code for the atmega chip with avr-gcc. There'll be a bunch more setup code when you switch to ARM, but mbed looks like it abstracts that away pretty well. Just grab a cheap board and check it out!
|
# ? Jul 27, 2014 16:49 |
|
I'm looking at putting something together which controls focus on a camera from an arduino. This involves rotating a ring on the lens, which can be quite delicate. I'm from a heavy software background so I'm trying to figure out what the best peripheral is to do this. At first I looked at brushless motors controlled via an ESC, but they look to be very much speed-oriented which makes sense given their use in RC planes etc. They also don't provide any position or other feedback. Given the delicacy of camera lenses I'd like to be able to detect resistance that indicates hitting either end of the ring's rotation. Would a servomotor be the right tool for this job? I'd quite like to transfer the power via a belt for ease of installation and reduced risk of damage if the motor overruns the focus ring's stop points, but I could manage toothed gears if it makes it easier to map the rotation of a lens to the rotation of the motor. I'm also looking for quite a small form factor for the motor, maybe 5cm cubed or thereabouts.
|
# ? Aug 10, 2014 12:01 |
Arachnamus posted:I'm looking at putting something together which controls focus on a camera from an arduino. This involves rotating a ring on the lens, which can be quite delicate. They make some pretty tiny stepper motors. I think one of the companies is micromo. You'd need a stepper driver, too.
|
|
# ? Aug 10, 2014 14:02 |
|
The only concern I'd have with stepper motors would be the resolution, given it'll be gearing up onto the lens.
|
# ? Aug 10, 2014 18:06 |
|
|
# ? May 9, 2024 21:43 |
|
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 |