Area 51 » Technology

Yes, I included it to highlight where the overlaps might be. There will obviously be some, and complete high wall saying "this belongs on EE" may or may not be appropriate. Discussion is called for. – Scott Seidman Jun 8 '14 at 17:42

In fact, part of my motivation is to show the bare metal folks that they can find a good home here – Scott Seidman Jun 8 '14 at 19:54

up vote 11 down vote

added by Scott Seidman Jun 6 '14 at 20:21

Great example question. – BigHomie Jun 9 '14 at 2:43

Thanks @BigHomie -- brings in PCB fabrication, grounding schemes, multilayer boards, decoupling, etc. All very hardware-ish, but important for anyone laying out an embedded board. – Scott Seidman Jun 9 '14 at 13:28

... and EE.SE happily covers all of these analog issues. Reading from your comment, you are proposing to cover PCB fabrication topics on the Embedded stack. What's next? Are you planning to cover foundry processes too? Besides, why are you calling this "hardware-ish" ? Isn't this called "hardware, period" ? – Nick Alexeev Jun 10 '14 at 3:39

@nickalexeev Yup, I'm trying to figure out where the boundary is with my 5 questions. Sort by oldestand look at them. This is the one I'd clearly flag for migration. The first I2C queston would need to stay, as it would be silliness to suggest that simple hardware issues around a commom low level bus would need to be migrated from an embedded group, and the second I2C question coud go either way. I'm commenting to highlight the hardware nature -- and injection molding processes are next on my list, not foundry ;-) – Scott Seidman Jun 10 '14 at 10:36

Perhaps my own close vote makes this clearer? I suppose what I'm trying to point out ( or perhaps figure out, and I'm getting there!) is that it not the hardware-only aspect that we should look at (defending the first I2C question as on topic), but the level of hardware expertise it would take to answer the question. Open drain with pullups is vanilla stuff, grounding schemes for 59 MHz oscillators, less so. That said, I think "How do I make a PCB for my embedded design? " would be appropriate for this proposal. – Scott Seidman Jun 10 '14 at 10:51

show 3 more improvement suggestions

up vote 11 down vote

added by BigHomie Jun 6 '14 at 20:46

Seems like the question should site which compiler/platform they are using. – Nick Aug 15 '14 at 21:09

up vote 11 down vote

added by SF., edited by WikiSpeedia hang-around Aug 2 '14 at 11:08

up vote 11 down vote

added by David Freitag Jun 18 '14 at 20:30

up vote 10 down vote

added by Scott Seidman, edited by WikiSpeedia hang-around Aug 2 '14 at 11:04

Awesome question. You would get a lot of thoughtful answers about ways to control bus capacitance and buffers with trades offs W.R.T. data rate. – Nick Aug 15 '14 at 21:42

up vote 10 down vote

added by BigHomie, edited by WikiSpeedia hang-around Aug 2 '14 at 11:04

up vote 10 down vote

added by BigHomie Jun 6 '14 at 20:46

up vote 10 down vote

added by thejohnny Jun 7 '14 at 18:50

up vote 10 down vote

added by thejohnny Jun 7 '14 at 18:56

I suggest editing or removing this, as UART is not limited in speed. RS232 is, but uart can go into megabaud using the correct protocols – Scott Seidman Jul 12 '14 at 15:03

"modern technology"? Synchronous serial interfaces aren't exactly modern - SPI was introduced in the 70s. I agree with Scott - the better question would be why can't I pump 10mBaud through my RS232 interface. The answer it would generate: The horrid 300Ohm output resistor on every RS232 Driver per the standard which kills your slew rate by limiting the current you can drive onto the line. The other question would be why do Synchronous serial interfaces achieve higher baud rates than asynchronous interfaces (TTL UART)? – Nick Aug 15 '14 at 21:33

up vote 10 down vote

added by thejohnny Jun 7 '14 at 19:01

up vote 10 down vote

added by Patrick, edited by WikiSpeedia hang-around Aug 2 '14 at 11:06

How is this an embedded question? This seems more like a UNIX & Linux question or a software testing question. This can bleed over into embedded systems, but would this stack be the best place for this kind of content? – Nick Aug 15 '14 at 21:07

That's a fair comment. I wanted to do something like this when I was making an embedded Linux distro and testing it in QEMU. There will be overlap with several SE sites with embedded, but I think the best advantage of an embedded SE site is the wide range of expertise embedded developers tend to have, and thus the higher likelihood of getting a good answer to your question. – Patrick Aug 18 '14 at 13:31

up vote 10 down vote

added by Rocketmagnet Jun 7 '14 at 23:36

That's going to depend a lot on what you want to do with it. A reasonable question would be something like “Minimum amount of RAM for a system that relays temperature measurements over wifi”. – Gilles Jun 9 '14 at 22:19

This embedded systems question is getting closed, while the circuit design questions about I2C level shifting and range extension are getting upvoted. I find it odd. – Nick Alexeev Jun 9 '14 at 22:38

This is crazy. This very question was asked on the original site, and generated some excellent answers. – Rocketmagnet Aug 7 '14 at 14:14

I think the question should be reworded to "Minimum hardware requirements for embedded Linux" – Mahendra Gunawardena Aug 12 '14 at 0:17

Agreed - hardware specific questions can almost bleed into the electrical engineering stack, whereas this is classically embedded. Not just 'embedded linux' either - what if I want to run gentoo on an SBC that will take analog inputs as a piece of packaged test equipment? I would still consider that an embedded system. – Nick Aug 15 '14 at 20:47