64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »

Hunter2 Thompson: Feb 3, 2005; Ramrod XTreme

Echoing Pan Et Circenses with my proxied experiences.

My wife once managed to get OpenOCD to work on an ST-Link V2 for a project at work (trying to flash a bunch on non-ST chips without dropping loads on cash on J-Links) but it was really slow compared to using vendor libraries with an ST-Link or a J-Link debugger. One day it might be a useful replacement for proprietary tools but these days it's not practical for real work.

I believe OpenOCD is a cool project and I hope that the future brings ridiculously cheap open hardware debuggers that can compete with the big guys.

# ? Aug 9, 2016 06:16

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:21

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

Pan Et Circenses posted:

What are you doing that you need actual JTAG for?

Normally for ARM I'd suggest getting a J-Link instead of whatever proprietary debug probe the company produces. It's supported by every embedded IDE out there or you can use the bundled GDB server, and works with anything that's a proper ARM core. To be frank I wouldn't even consider using OpenOCD unless you seriously can't afford the $60 for the edu version (non-commercial use).

I'm a moron who decided that it would be fun to try and make my own operating system, so the ability to debug bare-metal programs is pretty desirable. Yes, I am aware of the many layers of bad decision involved in this, but I already spent far too much time and money on this stuff so I'm not going to quit right now.

I already spent $80 for the XDS100v2 from TI, but that's because just the adaptor from the standard normal interface that everything else uses to the special proprietary TI connector is almost twice as much. I can afford it soon, I just already got the BBB, the XDS100v2, and a new soldering station because my old Hakko knockoff stopped working when I tried to change the tip to put the JTAG connector on the board so I was hoping that I wouldn't have thrown that money away completely.

Not super happy with the idea of the J-Link EDU, just because I do pretend to myself that somehow I'll manage to succeed where all but a very tiny few have failed and could somehow someday make money off of this, and I'd rather not familiarize myself with something that I can't use for other projects I'll definitely be selling, since there's no way that I'm shelling out the $400 for the full one soon, but I don't want to end up in a position where I get in trouble because I someday decide to start selling something that I play around with using the wrong adaptor right now.

meatpotato posted:

Echoing Pan Et Circenses with my proxied experiences.

My wife once managed to get OpenOCD to work on an ST-Link V2 for a project at work (trying to flash a bunch on non-ST chips without dropping loads on cash on J-Links) but it was really slow compared to using vendor libraries with an ST-Link or a J-Link debugger. One day it might be a useful replacement for proprietary tools but these days it's not practical for real work.

I believe OpenOCD is a cool project and I hope that the future brings ridiculously cheap open hardware debuggers that can compete with the big guys.

This is for the least real work ever, but it's not even just 'not practical', it's not even vaguely functional at the moment at anything that I've tried to do except for using an ST-Link to program and debug an STM32 much, much slower than the official tools could, but with the advantage of being marginally less painful to use... eventually.

I guess I'll save up and then give another too-large chunk of money for something that might actually work.

I've spent at least twenty or thirty hours trying to get this poo poo to work, I don't want to think about how little that means my time is worth versus $120 for a J-Link EDU and the SEGGER branded version of the adapter, or $90 for the EDU and an off-brand adaptor which should be okay because it is just a tiny circuit board with a connector on either side of it.

# ? Aug 9, 2016 07:15

Pan Et Circenses: Nov 2, 2009

If a non-commercial project turns into a commercial one, there's really no chance you'd get in trouble for buying the J-Link commercial version at the time you actually start commercializing it. Also, the only reason you'd really need a specialized adapter like that is if you're connecting/disconnecting the debug probe a bunch because it's a pain to reconnect pins one by one over and over.

ARM JTAG connections are totally standardized across every single ARM core in existence, so all you need to do is get some female/female jumper wires and play connect the dots (assuming that board brings the signals out to a header; otherwise it's soldering time). Connect the following pins of your generic JTAG probe to the same pins on the board and it will Just Work: TDI, TDO, TMS, TCK, V+ (reference), GND. You may also need to connect RESET (that's CPU reset, not tap reset) so the probe can hold the board in reset while connecting, allowing you to debug the boot process.

# ? Aug 11, 2016 04:06

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

Pan Et Circenses posted:

If a non-commercial project turns into a commercial one, there's really no chance you'd get in trouble for buying the J-Link commercial version at the time you actually start commercializing it. Also, the only reason you'd really need a specialized adapter like that is if you're connecting/disconnecting the debug probe a bunch because it's a pain to reconnect pins one by one over and over.

ARM JTAG connections are totally standardized across every single ARM core in existence, so all you need to do is get some female/female jumper wires and play connect the dots (assuming that board brings the signals out to a header; otherwise it's soldering time). Connect the following pins of your generic JTAG probe to the same pins on the board and it will Just Work: TDI, TDO, TMS, TCK, V+ (reference), GND. You may also need to connect RESET (that's CPU reset, not tap reset) so the probe can hold the board in reset while connecting, allowing you to debug the boot process.

I know that's the logical thing, but my attitude towards any company involved in electronics and especially embedded processor technology is about five hundred percent cynicism, so I'm never sure.

I'm aware that it's standardized, don't worry. Unfortunately, it's also tiny (in comparison to the standard 2.54mm stuff) and smaller than any jumpers or anything that I could find online. Tiny connectors are a pretty good reason to get an adaptor board, in my book.

And before someone points it out, yes I know that 1.27 mm isn't tiny overall, but compared to what I really want to muck around with jumper wires for, it is. Also, I feel like there are the mountain of ground pins in that connector for a good (signal integrity) reason, and at this point I'd rather skip a pizza and a bit more and buy the cheaper 'clone' (inasmuch as you can clone the idea of 'two signal-compatible connectors on opposite sides of a PCB') adaptor so I don't have another thing to worry about.

# ? Aug 11, 2016 09:56

yippee cahier: Mar 28, 2005

what's a good SBC to learn the linux side of things? not looking to bring up a new board or anything, i'd just like to begin writing a driver for an external SPI attached ADC chip or something like that.

i'd prefer a standard as possible kernel, up to date and without too many quirks that would distract me from learning useful generic stuff.

# ? Aug 15, 2016 16:15

ante: Apr 9, 2005; SUNSHINE AND RAINBOWS

Raspberry Pi is really the only option there. It's not even close to the best hardware or anything, but the huge amount of community support is the best for Getting Stuff Done without dicking around too much

# ? Aug 16, 2016 01:13

qsvui: Aug 23, 2003; some crazy thing

There seems to be an embedded Linux thread here: https://forums.somethingawful.com/showthread.php?threadid=3783629.

# ? Aug 17, 2016 02:46

yippee cahier: Mar 28, 2005

Thanks, I assumed as much.

EDIT: ^^^ Thanks for the link to the other thread as well.

# ? Aug 17, 2016 03:10

Popete: Oct 6, 2009; This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs; Grimey Drawer

There is something very rewarding about shrinking a program down by a factor of 10 to fit into a 128KB of RAM. It took 2 days of looking up compiler/linker optimizations,shrinking buffers/heap/stack but it's there.

It was the last 50KB that really gave me trouble. Then I turned on gcc garbage collection which split text/data sections and that reduced the Xilinx libraries I was using by a nice chunk. The final piece was disabling LwIPs internal malloc routines to favour using the standard libc implementation.

Popete fucked around with this message at 23:21 on Sep 2, 2016

# ? Sep 2, 2016 23:18

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I'm working on a pet 68K project and I need to output a single-precision IEEE 785 floating point number as a string. My operating system includes a string output function.

My assembler package is from 1991 and I'm not sure how to work its linker. I have a C compiler for this system and a function that just wraps sprintf("%f", buf) but I haven't been able to call it from ASM yet...

I suppose I could just rip open the object file with a hex editor and figure out what printf is doing. It seems that the actual floating point -> string algorithm is, uh, complex.

# ? Sep 3, 2016 00:03

Keebler: Aug 21, 2000

Does anyone have a minute to sanity check some AVR code? I'm using the 16-bit timer of an attiny2313 and having trouble with some basic set up. I'd like it configured as follows:

Fast PWM (mode 14), with inverted output on the OC1A pin (timing specified by TOP and OCR1A).
An interrupt triggered when OCR1B matches the current count in the timer.

The PWM piece works fine. I am able to hook a scope to OC1A and I get the expected waveform with the correct timings so I know the timer is counting. I cannot for the life of me get the interrupt to fire though. The code is pared down so that the only thing the interrupt handler should be doing is turning on a LED attached to PB1 so that I know it ran. I tested the LED by moving the portb command into the main function so I know it works. Am I missing something with the set up? I verified in the disassembly that vector 12 (0x0C) exists in the interrupt table so I know it's compiled in. I just can't seem to get the thing to trigger.

code:

int main( void )
{
    // Set up the sleep mode
    set_sleep_mode( SLEEP_MODE_IDLE );
    sleep_mode();

    // Set OC1A as output for C-sync
    // Set PB1 as output
    DDRB = 0x0A; 

    // Configure the counter for PWM output
    TCCR1A |= (1 << COM1A1);
    TCCR1A |= (1 << COM1A0);
    TCCR1A |= (1 << WGM11);

    TCCR1B |= (1 << WGM13);
    TCCR1B |= (1 << WGM12);

    ICR1  = 909; // TOP value of timer
    OCR1A = 67;  // PWM match value
    OCR1B = 156; // Interrupt match value

    TIFR  |= (1 << OCF1B); // Clear OCR1B interrupt flag just in case
    TIMSK |= (1 << OCIE1B);
    TCCR1B |= (1 << CS10); // Start the timer, no prescale

    sei(); // Enable interrupts

    while ( 1 ) { sleep_cpu(); }

    return 0;
}

ISR( TIMER1_COMPB_vect )
{
    PORTB |= 2;
}

# ? Sep 6, 2016 14:53

carticket: Jun 28, 2005; white and gold.

So, I'm looking to get into reverse engineering/security. There is a company near me specializing in this, and it sounds like a place I'd like to work, doing something really interesting. I've got a lot of low level experience on ARM, but no practical reverse engineering, and security is not a concern for us. We fix buffer overflows because it smashes our stack and crashes the system and not because of a remote execution exploit.

I played the microcorruption CTF and got through all but what I believe is the last one (and I'm pretty sure I'm on the right path for a solution to it by abusing printf formatters in the input). It was really fun.

I have no idea where to start with more practical applications though. Are there any microcorruption-like CTFs that target a more desktop-like environment?

# ? Sep 7, 2016 06:48

BlackTie: Oct 23, 2008

Keebler posted:

Does anyone have a minute to sanity check some AVR code? I'm using the 16-bit timer of an attiny2313 and having trouble with some basic set up. I'd like it configured as follows:

Fast PWM (mode 14), with inverted output on the OC1A pin (timing specified by TOP and OCR1A).
An interrupt triggered when OCR1B matches the current count in the timer.

The PWM piece works fine. I am able to hook a scope to OC1A and I get the expected waveform with the correct timings so I know the timer is counting. I cannot for the life of me get the interrupt to fire though. The code is pared down so that the only thing the interrupt handler should be doing is turning on a LED attached to PB1 so that I know it ran. I tested the LED by moving the portb command into the main function so I know it works. Am I missing something with the set up? I verified in the disassembly that vector 12 (0x0C) exists in the interrupt table so I know it's compiled in. I just can't seem to get the thing to trigger.
code:
    ICR1  = 909; // TOP value of timer
    OCR1A = 67;  // PWM match value
    OCR1B = 156; // Interrupt match value

I think these registers you're setting might be the problem. TIMER1 is a 16 bit timer, and these registers are made out of 2 8 bit registers, xxxH and xxxL. ICR1 is ICR1H and ICR1L, and so on. If the PWM works, it might be sharing the register addresses with other AVRs, so it goes to the same place anyway, but I'd check if changing the registers you now have to the H and L to see if it does something.

# ? Sep 7, 2016 12:34

Keebler: Aug 21, 2000

Thanks for taking a look! I actually managed to figure it out last night and I was looking in the completely wrong area. Turns out that sleep_mode(...) was preventing anything that came after it from executing. Almost like it put the processor to sleep at that instant. I had originally had that positioned about half way through the main function which is why the PWM output was working. The correct call ended up being sleep_enable(...). Once that was in place the interrupt started firing. Took me 4 days to figure that out, sometimes the simple things cause the most headache I guess.

For reference here are the descriptions for the two functions:

quote:

void sleep_enable ( void )
Put the device in sleep mode. How the device is brought out of sleep mode depends on the specific mode selected with the set_sleep_mode() function. See the data sheet for your device for more details.

Set the SE (sleep enable) bit.

void sleep_mode ( void )
Put the device into sleep mode, taking care of setting the SE bit before, and clearing it afterwards.

# ? Sep 7, 2016 16:07

hendersa: Sep 17, 2006

Mr. Powers posted:

So, I'm looking to get into reverse engineering/security. There is a company near me specializing in this, and it sounds like a place I'd like to work, doing something really interesting. I've got a lot of low level experience on ARM, but no practical reverse engineering, and security is not a concern for us. We fix buffer overflows because it smashes our stack and crashes the system and not because of a remote execution exploit.

I played the microcorruption CTF and got through all but what I believe is the last one (and I'm pretty sure I'm on the right path for a solution to it by abusing printf formatters in the input). It was really fun.

I have no idea where to start with more practical applications though. Are there any microcorruption-like CTFs that target a more desktop-like environment?

This is my research area. Are you more interested in dynamic analysis (observation and modification at runtime, "taint" tracking, etc.) or static analysis (symbolic execution/simulation, control flow graph construction/analysis, etc.)? There are tons of different techniques to find security flaws at library/process/kernel/system levels, depending upon your specific wants and needs. I just recently submitted a paper to a security conference on using fuzz testing to slam the MMIO interfaces of virtual devices to find bugs in their internal state machines.

Send me a PM with some questions and I'll see if I can find you some answers.

# ? Sep 7, 2016 18:52

Crankit: Feb 7, 2011; HE WATCHES

I ordered a $2 stm32 board off ebay, and an st-link programmer, apparently the board is called a "blue pill" and my computer recognises the ST Link and the ST link programmer software can communicate with the board. I'm still waiting for a little screen and accelerometer thingy to turn up, but how do I actually make the .bin file i want to put on it?

# ? Sep 10, 2016 10:23

qsvui: Aug 23, 2003; some crazy thing

Do you have a toolchain? If not, I've found that Atollic can get a simple application up and running pretty quickly.

# ? Sep 10, 2016 19:48

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

Crankit posted:

I ordered a $2 stm32 board off ebay, and an st-link programmer, apparently the board is called a "blue pill" and my computer recognises the ST Link and the ST link programmer software can communicate with the board. I'm still waiting for a little screen and accelerometer thingy to turn up, but how do I actually make the .bin file i want to put on it?

I'd suggest against using an IDE like that, at least if you've done any C programming before. It's not hard to make the whatever.bin file yourself, you just use arm-none-eabi-gcc (available from Homebrew as OS X with brew cask install gcc-arm-embedded, in the package manager of pretty much every Linux distribution, and easily installable in the Linux VM you'll really want if you're on Windows :v:

) in much the same way that you would with a normal C project, and then use arm-none-eabi-objcopy -O binary linked_output_from_gcc.elf actual_program.bin to generate the file you'll flash to the STM32 with st-flash.

I'm not on the computer that I use for ARM development stuff, so I can't test it, but a good starter Makefile is probably something like this, although that's mostly written off the top of my head.

# ? Sep 10, 2016 20:28

FlapYoJacks: Feb 12, 2009

Anybody familiar with RGMII, Micrel, and the IMX6?

I have a KSZ8794CNX connected via RGMII to a imx6 Solo, all the clock lines look good, uboot detects the phy, I can read via the MDIO bus registers 0x0 - 0x5, the rising and falling edge match up with RGMII spec, yet I get RX but no TX.

Any help would be appreciated!

# ? Sep 23, 2016 01:57

Popete: Oct 6, 2009; This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs; Grimey Drawer

ratbert90 posted:

Anybody familiar with RGMII, Micrel, and the IMX6?

I have a KSZ8794CNX connected via RGMII to a imx6 Solo, all the clock lines look good, uboot detects the phy, I can read via the MDIO bus registers 0x0 - 0x5, the rising and falling edge match up with RGMII spec, yet I get RX but no TX.

Any help would be appreciated!

Does it auto negotiate the speed? What TX are you expecting to receive and from were? Are you booting to Linux?

# ? Sep 29, 2016 19:05

FlapYoJacks: Feb 12, 2009

Popete posted:

Does it auto negotiate the speed? What TX are you expecting to receive and from were? Are you booting to Linux?

Turns out the TCC drive strength was too low which messed with the skew. Putting a 640ohm resistor on the line did the trick.

# ? Sep 30, 2016 05:34

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

I frequently ssh into an arm system which is on my LAN, and between giving command "ssh user@ip" and seeing the password prompt is about 30s. Once logged in, the connection feels reasonably responsive, its just really annoying to wait that long for a password prompt.

/proc/cpuinfo for reference

quote:

Processor : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 719.25
Features : swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2

Hardware : ti8148evm
Revision : 0000
Serial : 0000000000000000

On the other hand, I have another arm system (beaglebone black) that I also sometimes ssh into, on the same LAN, from the same client, and I see the password prompt in 1s or less.

Here is it's cpuinfo

quote:

processor : 0
model name : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 298.24
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2

Hardware : Generic AM33XX (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000

Why would these two perform vaslty differently for that initial ssh connection? Any ideas if there is some config I can change to make this not take ages to initiate ssh connections?

# ? Oct 9, 2016 20:36

Corla Plankun: May 8, 2007; improve the lives of everyone

Use the verbose flag when you SSH. I had this problem at work and it turned out that SSH was trying like 200 ways to authenticate and THEN trying the one that works. You can set arguments to disable some of the types you aren't using.

Edit: Sorry I left out a step. Use the verbose flag and then google the line that it slows down on. That'll show you what you need to disable.

# ? Oct 9, 2016 21:42

teamdest: Jul 1, 2007

Comedy option: make sure forward and reverse DNS is working properly. This may only apply to FreeIPA managed systems but that was causing massive slowdown in SSH because one DNS server (on a different subnet but routed) couldn't talk to a DNS server on our subnet because DNSSEC was broken. This caused every ssh attempt to hang for 6-30 seconds until the DNS lookup timed out, with no visible error message to the user.

# ? Oct 10, 2016 00:37

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

ok I ran ssh -v on the slow system, and this is what it output:

code:

$ ssh -v root@192.168.1.15
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.15 [192.168.1.15] port 22.
debug1: Connection established.
debug1: identity file /home/peeps/.ssh/id_rsa type 1
debug1: identity file /home/peeps/.ssh/id_rsa-cert type -1
debug1: identity file /home/peeps/.ssh/id_dsa type -1
debug1: identity file /home/peeps/.ssh/id_dsa-cert type -1
debug1: identity file /home/peeps/.ssh/id_ecdsa type -1
debug1: identity file /home/peeps/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/peeps/.ssh/id_ed25519 type -1
debug1: identity file /home/peeps/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: Remote protocol version 2.0, remote software version dropbear_2012.55
debug1: no match: dropbear_2012.55
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received     
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 90:75:3d:ca:f1:42:65:92:71:97:48:d7:6b:ff:d7:8b
debug1: Host '192.168.1.15' is known and matches the RSA host key.
debug1: Found key in /home/peeps/.ssh/known_hosts:23
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/peeps/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/peeps/.ssh/id_dsa
debug1: Trying private key: /home/peeps/.ssh/id_ecdsa
debug1: Trying private key: /home/peeps/.ssh/id_ed25519
debug1: Next authentication method: password
root@192.168.1.15's password:

It waits about 20s after outputting the line that says "Local version string ..."
And another 10s on the line "expecting SSH2_MSG_KEXDH_REPLY"

I mean, these messages are coming from the ssh client, and the problem is presumably with the server, so I'm not sure how useful that is. Seems like its just waiting for dropbear to do things and its taking forever. I don't know if I can get any verbose logging from dropbear. It logs a minimum of messages to syslog but nothing that indicates the reason for the pause.

In comparison, the beaglebone uses openssh server, not dropbear, and I also noticed it does ECDSA while the slow system does the RSA key.

peepsalot fucked around with this message at 01:03 on Oct 10, 2016

# ? Oct 10, 2016 00:49

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

peepsalot posted:

It waits about 20s after outputting the line that says "Local version string ..."

This is almost certainly slow or broken DNS on the server.

peepsalot posted:

And another 10s on the line "expecting SSH2_MSG_KEX_ECDH_REPLY"

Might be a very slow implementation of ECDH on the server and a large key. Could also be DNS again.

Test on the server how long it takes to find the hostname for your client's IP address. You might have something like mdns enabled and causing a long wait while it probes the local network to try to discover a hostname.

# ? Oct 10, 2016 00:57

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

ShoulderDaemon posted:

This is almost certainly slow or broken DNS on the server.

Might be a very slow implementation of ECDH on the server and a large key. Could also be DNS again.

Test on the server how long it takes to find the hostname for your client's IP address. You might have something like mdns enabled and causing a long wait while it probes the local network to try to discover a hostname.

Sorry, I had copied and pasted that "10s" line from the beaglebone log which is not the slow one. So its not "ECDH", I corrected my post above.
Its "expecting SSH2_MSG_KEXDH_REPLY"

Also I don't know how to test the reverse DNS lookup from the ssh server. There are no dig or host commands.

# ? Oct 10, 2016 01:08

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

peepsalot posted:

Sorry, I had copied and pasted that "10s" line from the beaglebone log which is not the slow one. So its not "ECDH", I corrected my post above.
Its "expecting SSH2_MSG_KEXDH_REPLY"

DNS still plausible. Might also still be keysize related. I'd probably attack the DNS angle first before bothering with further investigation.

peepsalot posted:

Also I don't know how to test the reverse DNS lookup from the ssh server. There are no dig or host commands.

See if ping is noticeably slower than ping -n or something? It's hard to answer without knowing what you do have.

Check that resolv.conf has the right nameserver. Check nsswitch.conf for something like mdns. Break out Wireshark and see what traffic is coming from the server during one of these delays.

# ? Oct 10, 2016 01:17

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

ShoulderDaemon posted:

DNS still plausible. Might also still be keysize related. I'd probably attack the DNS angle first before bothering with further investigation.

See if ping is noticeably slower than ping -n or something? It's hard to answer without knowing what you do have.

Check that resolv.conf has the right nameserver. Check nsswitch.conf for something like mdns. Break out Wireshark and see what traffic is coming from the server during one of these delays.

What I have is a lovely 4 yr old busybox multi call binary and no man pages for it

code:

$ ping -n 192.168.1.16
ping: invalid option -- 'n'
BusyBox v1.19.4 (2012-12-16 13:54:20 CST) multi-call binary.

Usage: ping [OPTIONS] HOST
$

Of course enumerating what those options are would take up precious bytes and we can't have that sort of bloat in busybox.

e: I guess dropbear is only configurable at compile time?

peepsalot fucked around with this message at 17:42 on Oct 13, 2016

# ? Oct 10, 2016 02:12

toadoftoadhall: Feb 27, 2015

Hi everybody. I need to finalise a selection for 3 semester implementation project. Initially I planned to do a little toy operating system for 32 bit x86 programming small microkernal following osdevs tutorials and Minix book and other sources, but after a PIC asm course I would like to reorient and complete a project in the embedded domain which is only lightly touched upon in my BSc. Because of this I would like to do something as non-trivial as is feasible for final year CompSci student to close the gap between myself and electrical engineers. Please reply or message me - any help with direction so I can develop clear project proposal is greatly appreciated

# ? Oct 17, 2016 22:52

Popete: Oct 6, 2009; This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs; Grimey Drawer

toadoftoadhall posted:

Hi everybody. I need to finalise a selection for 3 semester implementation project. Initially I planned to do a little toy operating system for 32 bit x86 programming small microkernal following osdevs tutorials and Minix book and other sources, but after a PIC asm course I would like to reorient and complete a project in the embedded domain which is only lightly touched upon in my BSc. Because of this I would like to do something as non-trivial as is feasible for final year CompSci student to close the gap between myself and electrical engineers. Please reply or message me - any help with direction so I can develop clear project proposal is greatly appreciated

I don't think anyone is going to be able to tell you what project you should do because that depends on a lot of factors, hardware constraints/deadlines being the biggest. Take a look at Arduino or Rasberry Pi projects that others have done to get an idea for something you would want to do.

Pick something you are truly interested in doing, it's gonna be a drag and having real motivation to reach the finish line is key. Do not pick an overly ambitious project (e.g. writing an OS from scratch) you will quickly fall behind and get overwhelmed. It's better to have a simple project done well than a complex project half assed.

# ? Oct 18, 2016 02:12

toadoftoadhall: Feb 27, 2015

Popete posted:

I don't think anyone is going to be able to tell you what project you should do because that depends on a lot of factors, hardware constraints/deadlines being the biggest. Take a look at Arduino or Rasberry Pi projects that others have done to get an idea for something you would want to do.

Pick something you are truly interested in doing, it's gonna be a drag and having real motivation to reach the finish line is key. Do not pick an overly ambitious project (e.g. writing an OS from scratch) you will quickly fall behind and get overwhelmed. It's better to have a simple project done well than a complex project half assed.

Hello Popete. I have 7 months for this project. The minature x86 OS has been given as benchmark and I would be expected to propose something similarly challenging. The tightest constraint is my skill with hardware. I wouldn't ask somebody to tell but having somebody who knows the field to discuss the direction I might want to take so as to be working with embedded systems not websites this time next year would be nice. My relevant interests are microcontrollers, communications and operating systems but I am expert in none. Thanks for the reply

# ? Oct 18, 2016 03:35

carticket: Jun 28, 2005; white and gold.

You should write an efficient and comprehensive readers-writer lock implementation for FreeRTOS and then contribute it back so I can use it.

E: and while you're at it, if you can make mutexes and semaphores take fewer than 76 bytes (on a 32-bit system), I'd appreciate it.

I have no idea if these will help you graduate, but they will make life less annoying for me.

# ? Oct 18, 2016 05:34

ante: Apr 9, 2005; SUNSHINE AND RAINBOWS

OpenCV implementation (or similar project) on PIC32.

And put it up on Github

# ? Oct 18, 2016 07:23

dougdrums: Feb 25, 2005; CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)

I would do something other than write a generic OS for PC/x86. Three quarters of your time will be spent writing drivers that have already been written, not to mention your own libc with multitasking... Maybe take one part of the linux kernel like scheduling or the network stack, and get creative with it. That'll cover three semesters pretty easily.

If you're hellbent on making a whole OS, I've fancied making a pure 64 bit armv8 OS, but of course will never get to it.

I think if I was in your position, I'd design a some sort of stage lighting fixture. Iirc you said you wanted to focus on the EE and embedded side of things. It covers a good range of problems from driving LEDs to real-time networking. Optionally you can add some mechanical aspect if you wish. Flashing or blinking lights will impress people easily and keep you motivated.

Mr. Powers posted:

You should write an efficient and comprehensive readers-writer lock implementation for FreeRTOS and then contribute it back so I can use it.

This would be far more useful though... even if it doesn't blink anything.

dougdrums fucked around with this message at 10:29 on Oct 18, 2016

# ? Oct 18, 2016 10:22

yippee cahier: Mar 28, 2005

Is there a good embedded data structures library that I should be using? I don't feel like reinventing the wheel is going to be productive.

# ? Oct 18, 2016 16:25

peepsalot: Apr 24, 2007; ��PEEP THIS...
��BITCH!

Whats an embedded data structure?

# ? Oct 19, 2016 01:05

carticket: Jun 28, 2005; white and gold.

peepsalot posted:

Whats an embedded data structure?

A struct inside of a struct.

# ? Oct 19, 2016 02:11

FlapYoJacks: Feb 12, 2009

peepsalot posted:

Whats an embedded data structure?

A miserable pile of structs! But enough talk, have at you!

# ? Oct 19, 2016 02:37

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:21

JawnV6: Jul 4, 2004; So hot ...

A ring buffer where an empty entry to make the accounting simpler is a good space tradeoff.

# ? Oct 19, 2016 04:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

«‹›53 »