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 »

qsvui: Aug 23, 2003; some crazy thing

ante posted:

ST is the rising star, gently caress Atmel

i agree with this man

# ? Sep 29, 2017 02:13

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 06:01

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Luigi Thirty posted:

They still make CodeWarrior?

CodeWarrior from 10.x on is just a rebranded Eclipse now.

# ? Sep 29, 2017 02:43

iospace: Jan 19, 2038

Blotto Skorzany posted:

CodeWarrior from 10.x on is just a rebranded Eclipse now.

From poo poo to even worse poo poo.

# ? Sep 29, 2017 02:48

FlapYoJacks: Feb 12, 2009

Luigi Thirty posted:

They still make CodeWarrior? Christ, I used that to program 68K Macs.

It's just eclipse. But at this point, if you aren't using pure eclipse-cdt you are doing it wrong.

What's wrong with eclipse-cdt? I converted to CLion a few months ago, but it doesn't support GNUMake projects, so when I do kernel/uboot dev, I go back to eclipse. It works fine and I haven't had any major issues with it since... mars I think. Oxygen is pgood. :shrug:

# ? Sep 29, 2017 11:41

Volguus: Mar 3, 2009

ratbert90 posted:

It's just eclipse. But at this point, if you aren't using pure eclipse-cdt you are doing it wrong.

What's wrong with eclipse-cdt? I converted to CLion a few months ago, but it doesn't support GNUMake projects, so when I do kernel/uboot dev, I go back to eclipse. It works fine and I haven't had any major issues with it since... mars I think. Oxygen is pgood.

My only problem with the vendor IDE (eclipse+some plugin) was only that it was old as hell and I would have trouble running it on my latest Fedora. On CentOS though, it was working fine. And, depending on what you do, their plugins can be quite helpful, if not outright necessary. CLion ... that thing has trouble parsing C++ code last time I checked it. Throw a template or two and it goes belly up (to be fair, it's been a while since I checked it).

# ? Sep 29, 2017 12:30

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

CodeWarrior still exists but is no longer officially supported at least for most new micros. They wanted you to use Kinetis Development Studio, which is also a rebranded eclipse, with a (slightly different) flavor of processor expert for those. After they got acquired they switched again to something called MCUXpresso, which as far as I can tell is just a third rebranded eclipse, and now have a static API rather than a graphical configurator. Or maybe also some separate configurator tool. This is probably better because ProcessorExpert is 100% incompatible with modern software development but I'll probably never know because all our poo poo was done in PEx already.

Atmel isn't really any better aside from having Atmel Studio which is I guess nice because it's a rebranded Visual Studio rather than rebranded Eclipse... but also who knows the degree to which Atmel is gonna continue to exist.

Honestly I think mBed compatible Cortex-M4s should probably be the goto. They're cheap, they're ubiquitous, they're surprisingly capable of both doing a lot of poo poo and optimized low power modes...

# ? Sep 29, 2017 12:47

carticket: Jun 28, 2005; white and gold.

Phobeste posted:

I'm using a kinetis at work. It's fine. Processorexpert is so drastically not fine that with the primary bringup done we've killed it and started just editing its hal manually. Plus side: it's dead. Minus side: doing any far reaching changes like adding more clock configs would require editing its heinous auto generated code. Guess I didn't need those 5 mA anyway

Just download/build against the Kinetis SDK and never look at processor expert again.

# ? Sep 29, 2017 13:23

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

ante posted:

ST is the rising star, gently caress Atmel

Actually Espressif is the rising star

# ? Sep 29, 2017 23:25

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

If you dump on Atmel I take that as a personal attack. Fight me.

# ? Sep 30, 2017 04:54

iospace: Jan 19, 2038

Popete posted:

If you dump on Atmel I take that as a personal attack. Fight me.

# ? Sep 30, 2017 05:00

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

# ? Sep 30, 2017 05:33

iospace: Jan 19, 2038

Luigi Thirty posted:

I hope whoever failed to check that in QA got sacked.

# ? Sep 30, 2017 05:48

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

iospace posted:

I hope whoever failed to check that in QA got sacked.

What do you mean? There is a work around.

# ? Sep 30, 2017 06:27

FlapYoJacks: Feb 12, 2009

Volguus posted:

My only problem with the vendor IDE (eclipse+some plugin) was only that it was old as hell and I would have trouble running it on my latest Fedora. On CentOS though, it was working fine. And, depending on what you do, their plugins can be quite helpful, if not outright necessary. CLion ... that thing has trouble parsing C++ code last time I checked it. Throw a template or two and it goes belly up (to be fair, it's been a while since I checked it).

Nah, CLion has become way better recently. I use it with templates all the time. They recently integrated clang-tidy into it as well which has been super useful.

# ? Sep 30, 2017 17:44

yippee cahier: Mar 28, 2005

ratbert90 posted:

Nah, CLion has become way better recently. I use it with templates all the time. They recently integrated clang-tidy into it as well which has been super useful.

How is CLion these days? I remember being really excited when it was announced, but I think they've made progress on debugging features for embedded.

# ? Sep 30, 2017 17:47

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

ST's documentation is terrible and their libraries are unforgivable.

# ? Sep 30, 2017 22:52

FlapYoJacks: Feb 12, 2009

yippee cahier posted:

How is CLion these days? I remember being really excited when it was announced, but I think they've made progress on debugging features for embedded.

I'm a embedded Linux guy, so I usually am not using jtags. Can't tell you about that.

Clion is pgood though from my perspective. I really do like intellij though. :unsmith:

# ? Oct 1, 2017 01:58

Splode: Jun 18, 2013; put some clothes on you little freak

Sinestro posted:

ST's documentation is terrible and their libraries are unforgivable.

Yeah ST libraries are horrendous

# ? Oct 1, 2017 14:35

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

Mr. Powers posted:

Just download/build against the Kinetis SDK and never look at processor expert again.

Hopefully will do this soon. It's just kind of a hard pitch because it's essentially redoing bringup with all the bullshit that implies.

# ? Oct 1, 2017 16:42

taqueso: Mar 8, 2004

I thought some people might be interested in the 4th Octojam, taking place this month. It's a game jam targeting the Chip8 virtual machine from 1978. The platform is a fairly limited 8-bit machine with 12-bits of code space and 16-bits of data space if you use the extensions. It's a fun way to get down and dirty with some low-level code.

You can join the awfuljam discord to talk about it, someone there can probably answer your questions.

Internet Janitor posted:

I've been thinking about this. Might be worth adding a :suffix for such a purpose.

In other news, the Octojam IV page is together:

http://www.awfuljams.com/octojam-iv

# ? Oct 1, 2017 21:55

carticket: Jun 28, 2005; white and gold.

Phobeste posted:

Hopefully will do this soon. It's just kind of a hard pitch because it's essentially redoing bringup with all the bullshit that implies.

I use the clock_config.c from their examples and everything else I've just built against the KSDK, so all I need to do is write my isr.c with the vector table and I can port to a different part in the lineup. I've used it for KL17/27/43 builds and K20 and K24. Their lineup cohesion is so much better than ST.

You do it once and bring up on new hardware takes so little time.

# ? Oct 2, 2017 00:31

iospace: Jan 19, 2038

So, on the Dragon 12 Lights, there's a keypad on them. Cool. They're tied to GPIO Port A.

Port A doesn't have hardware interrupts on it.

:wtc:

Oh, and to make things better, one of the ports that DOES support interrupts... is tied to dip switches.

# ? Oct 4, 2017 02:16

unpacked robinhood: Feb 18, 2013; by Fluffdaddy

Following a post I previously made in the Arduino thread, and some help from forums user babyeatingpsychopath:

My circuit outputs a simple train of pulses, on the model of unmodulated IR signals (0 is high for w ms then low for x ms, 1 is high for y ms and low for z ms) using PWM, sandwiched between a preamble and a stop pulse.

Here's an example of a valid 16 bit signal (preamble, address in orange, command in stop, stop pulse

Here's my current code, with a constant command for clarity:

code:

const uint8_t JVC_MUTE = 0x71;
const uint8_t JVC_ADDRESS = 0xF1;

void preamble(){
	PORTB |=_BV(PB1);
	_delay_us(8600);
	PORTB &=~_BV(PB1);
	_delay_us(3100);
}

void sendCode (uint16_t code) {
	TCNT0=0;

        //busywork 1
	OCR0A=0;
	OCR0B=0;
	do ; while ((TIFR & 1<<OCF0B) == 0);
	TIFR = 1<<OCF0B;
        //busywork 2
	OCR0A=0;
	OCR0B=0;
	do ; while ((TIFR & 1<<OCF0B) == 0);
	TIFR = 1<<OCF0B;

		for (uint16_t Bit=0x8000;Bit;Bit=Bit>>1){
			if (code & Bit) {
			OCR0A=255;
			OCR0B=80;
		}
		else {
			OCR0A=130;
			OCR0B=80;
		};
		//wait for TIFR:OCF0B==1
		do ; while ((TIFR & 1<<OCF0B) == 0);
		//clear OCF0B by writing a 1
		TIFR = 1<<OCF0B;
	}
	//stop bit (short pulse)
	OCR0A=130;
	OCR0B=80;
	do ; while ((TIFR & 1<<OCF0B) == 0);
	TIFR = 1<<OCF0B;

}

void transmit(uint8_t address,uint8_t code){
	//preamble();
	setupPCM();//PWM settings in TCCR0A and TCCR0B
	sendCode((JVC_ADDRESS<<8)+JVC_MUTE);
	stopPCM();//disables PWM (TCCR0A=0)
}

This one produces a valid 16 bit data signal and stop pulse, without the preamble.
Here are my 2 main issues:

-uncommenting the preamble() call adds the preamble pulse as expected, but sometimes gives the last bit before the stop pulse an incorrect value.

-removing the two paragraphs I labelled //busywork somehow cuts the first two bits of the transmission (the orange address part)

This is all on an ATtiny85.

Any ideas ?

unpacked robinhood fucked around with this message at 16:07 on Oct 5, 2017

# ? Oct 5, 2017 14:29

Colonel Taint: Mar 14, 2004

Are there any interrupts going on that could be trashing something?

# ? Oct 7, 2017 00:42

unpacked robinhood: Feb 18, 2013; by Fluffdaddy

I also tried using pwm with a different prescaler value in the preamble() method but couldn't get it to work.

Colonel Taint posted:

Are there any interrupts going on that could be trashing something?

Only the watchdog that regularly polls the buttons.

e: the full code is here

unpacked robinhood fucked around with this message at 10:37 on Oct 7, 2017

# ? Oct 7, 2017 10:09

Colonel Taint: Mar 14, 2004

I'm certainly no AVR expert, but it looks like this may be applicable:

http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_16bitio.html

You're also doing a lot of stuff in that ISR. Maybe rework it to something like this:

https://github.com/rainey/renault_remote

This was a pretty quick attempt at getting the work out of the ISR. You should probably think it through. Maybe just disable the ISR when in the transmit function (see this commit), as it will probably mess with your timing in any case.

E: Also, while investigating this a bit, I found out that

uint8_t j;
...
j++

gets compiled to

code:

 2da:   80 91 6c 00     lds     r24, 0x006C     ; 0x80006c <__data_end>
 2de:   8f 5f           subi    r24, 0xFF       ; 255
 2e0:   80 93 6c 00     sts     0x006C, r24     ; 0x80006c <__data_end>

Why does it do that when there is an INC instruction?

E2: To answer my own quesion, maybe because subi sets carry and half-carry flags?

Colonel Taint fucked around with this message at 02:54 on Oct 8, 2017

# ? Oct 7, 2017 13:50

Tan Dumplord: Mar 9, 2005; by FactsAreUseless

Spent half a day building an avr32 toolchain because apparently Microchip can't keep a loving website online.

It took half a day to figure out a TARGET that caused ld to work on gcc'd binaries.

# ? Oct 7, 2017 16:42

EpicCodeMonkey: Feb 19, 2011

sliderule posted:

Spent half a day building an avr32 toolchain because apparently Microchip can't keep a loving website online.

It took half a day to figure out a TARGET that caused ld to work on gcc'd binaries.

My condolences, the company that I work at has to do the same thing. Spoiler alert, the last patch released for the AVR32 GCC target is for an ancient version of GCC and produces broken and unstable output on some settings. We had to run a script to fuzz what options produced a working and stable output binary.

It's a dead architecture, avoid it if you still can.

# ? Oct 8, 2017 02:05

Tan Dumplord: Mar 9, 2005; by FactsAreUseless

EpicCodeMonkey posted:

It's a dead architecture, avoid it if you still can.

Writing firmware for fixed hardware. No choice. Legacy projects, oy.

# ? Oct 8, 2017 02:24

unpacked robinhood: Feb 18, 2013; by Fluffdaddy

Colonel Taint posted:

I'm certainly no AVR expert, but it looks like this may be applicable:

http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_16bitio.html

You're also doing a lot of stuff in that ISR. Maybe rework it to something like this:

https://github.com/rainey/renault_remote

This was a pretty quick attempt at getting the work out of the ISR. You should probably think it through. Maybe just disable the ISR when in the transmit function (see this commit), as it will probably mess with your timing in any case.

Late and can't say much except holy poo poo thank you. Disabling interrupts inside the transmit function did the trick.
I have some room for something more elegant but this will do for now.

e: I'm going to spend some effort understanding your first solution because I probably need to learn writing more efficient code anyways.

unpacked robinhood fucked around with this message at 21:14 on Oct 9, 2017

# ? Oct 9, 2017 14:43

Colonel Taint: Mar 14, 2004

unpacked robinhood posted:

Late and can't say much except holy poo poo thank you. Disabling interrupts inside the transmit function did the trick.
I have some room for something more elegant but this will do for now.

e: I'm going to spend some effort understanding your first solution because I probably need to learn writing more efficient code anyways.

Ah nice. If this is literally the only thing the chip has to do, my first solution is probably a bit excessive. It's also probably not 100% correct since I have no way of testing beyond simple compilation.

The basic idea though is:
-Spend as little time in the ISR as possible. Do this by moving all of the input checking code to the main loop and simply setting a flag in the ISR. The main loop essentially spins while this flag is 0, and does the input check after the ISR has set the flag.
-Lock around accesses to the check_inputs flag. The ISR and the main loop are essentialy two threads of execution and disabling the ISR is basically acting as a mutex.

If this is the only thing the chip will ever do, you can consider a few other options as far as structure:
-Do everything in the ISR.
-Disable the Global interrupt flags in entirely, and poll for the watchdog interrupt flag. The program would take a similar structure to my first solution except you would be polling and manually unsetting the Watchdog Interrupt flag.
-It looks like the attiny can also interrupt on gpio changes. This might be better than using the watchdog timer. The watchdog is more meant to detect timeouts/non-halting loops or whatever. It doesn't matter too much since it's a wired device, but if this was a battery powered device, you could have the chip enter sleep mode and only wake up when one of the pins change.

Anyway none of that really matters as long at it works :shrug:

Colonel Taint fucked around with this message at 23:23 on Oct 12, 2017

# ? Oct 12, 2017 22:07

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

I haven't done embedded multiprocessing. I'm programming an old game console with a 68000, a custom load-store RISC processor, and a blitter unit shared between them. All three chips appear on the same address map and have access to program memory. I need to arbitrate blitter access somehow so the CPU and GPU don't try to set up its registers at the same time. The 68K has the TAS instruction but the RISC chip has no memory read-modify-write instructions. How can I set up some kind of lock in C99 when I don't have an atomic read-modify-write instruction on one of the processors?

# ? Oct 13, 2017 14:53

Colonel Taint: Mar 14, 2004

You should be able to use Peterson's Algorithm to lock around blit accesses.

Colonel Taint fucked around with this message at 18:28 on Oct 13, 2017

# ? Oct 13, 2017 18:21

My Rhythmic Crotch: Jan 13, 2011

I was just curious if anyone has experiences with Platformio they would want to share? Anything from weekend hacks up to big production stuff that teams work on. I have yet to try the integrated debugging, or to really go hog wild in terms of changing linker scripts, and the guts of the toolchain. So I basically I have not really hit any showstopper issues for the one-man hobby stuff I do, curious to see what others' experience has been.

# ? Oct 15, 2017 22:57

Splode: Jun 18, 2013; put some clothes on you little freak

I used it to do a big* arduino project for work, it was good, but took a long time to set up everything. It doesn't feel particularly robust, I remember having to reinstall the plug in at some point as it had somehow reverted to atom.

For arduino projects at home and my new job I'm still using the arduino ide because I'm lazy. If I do anything requiring multiple pages or non arduino compatible ICs I'd use it.

*by arduino standards

# ? Oct 16, 2017 21:47

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

Harik posted:

That's a slightly older version of the official vendor tree, so yeah, it's pretty crap. Note that there's no "rockchip,audio-routing" in there anywhere like most of the other SoCs have, so all of that is hardcoded in rk_rk312x.c, rk_i2s.c and rk312x_codec.c. Some of which makes sense! All the codec-internal stuff should be hardcoded, it's not like the codec module can route differently. But the inter-module connections are all in rk_rk312x.c and it doesn't quite manage to get it right.

I'm currently studying the beaglebone kernel since their audio seems to A) work and B) use the modern setup. Looks like rockchip doesn't have a .cpu_dai_name/.codec_dai_name mapping in their soc_dai_link structure.

I dropped this for months, then punted it back to the chinese side of the development when they hired someone who knew what this "linux" stuff was. They found a kernel for the "FirePrime" rk3126/3128 boards and used it's audio drivers and now things work somewhat. Had to change the gain and filter on the amplifier, but we figured that would happen once we had signal to test it with.

Yay for random chinese pirate Kodi boxes, I guess? I don't think the vendor-provided code had ever worked for anyone. Apparently a lot of this chinese hardware has chinese forums and I'm behind a hell of a language barrier trying to get information about it. At least I've got some guys over there who can look into things like this.

That leads me to my current issue: low-level audio driving is a PITA. I don't think this one is hardware related, so anyone who's done audio on linux (embedded or otherwise) may be able to help:

I've got an issue with stuttering/popping and it's not making a whole lot of sense to me. After some interval of running, the sounds goes from crisp and clean to stuttery. Once it kicks in, it's on every frame, not intermittent.

I don't think it's a consistent underrun because that is detected when it happens during startup if my timing gets a little bit off. I've never seen it log an underrun outside the first few seconds, and I'm not attempting to play any audio until I've finished initializing.

Driving 16bit PCM via the poll/epoll interface of libasound. I can dig into the exact setup in detail if someone has a specific question, but the pseudocode is

code:

init() {
    snd_pcm_open(&handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
    init_hwparams(handle);
    init_swparams(handle);

    snd_pcm_poll_descriptors_count(handle)
    allocate pollfds
    snd_pcm_poll_descriptors(handle, &pollfds)
}

mainloop() {
   poll(pollfds);
   revents = snd_pcm_poll_descriptors_revents(handle, pollfds);
   if (revents & POLLOUT) {
       snd_writei(handle, buffer)
       fix underruns
       update buffer when empty
   }
}

I'm never not sending audio, if there's nothing to mix in it's just sending zeros. The amplifier is pretty garbage and pops when enabled, so I don't disconnect/reconnect the audio stream during silence.

It doesn't require a reboot to fix, simply restarting the program gets me functioning audio again.

I don't see any timing difference between working and non-working, it's consuming a frame every 40ms either way. I'm thinking it might be the kernel/codec internal buffer having slowly drained and for some reason it's never requesting I fill it back up? I'm not sure how the alsa thresholds are supposed to be set properly.

# ? Oct 21, 2017 02:29

Colonel Taint: Mar 14, 2004

In my (thankfully) limited experience with ALSA playback I've had similar issues with pops and clicks and such in polled mode. I never found the root cause really, but I'm pretty sure changing the playback method to alsa's async mode basically resolved the issue on the boards I was working with. Maybe try that if it's an option? It's only slightly more work to set up.

Colonel Taint fucked around with this message at 00:46 on Oct 23, 2017

# ? Oct 23, 2017 00:28

Harik: Sep 9, 2001; From the hard streets of Moscow
First dog to touch the stars; Plaster Town Cop

Colonel Taint posted:

In my (thankfully) limited experience with ALSA playback I've had similar issues with pops and clicks and such in polled mode. I never found the root cause really, but I'm pretty sure changing the playback method to alsa's async mode basically resolved the issue on the boards I was working with. Maybe try that if it's an option? It's only slightly more work to set up.

At that point I might as well just dump it on a separate thread and run in blocking mode, the async mode really conflicts with the epoll base of the main loop. No wonder everyone just uses pulse for audio in modern linux - libasound might as well not be documented. "the function sets this setting" with no explanation of what the setting is or how you should know what to set it to.

It is a quadcore arm, so maybe dumping it on it's own thread is for the best anyway. I'm only really using one core, and that just for doing screen updates.

# ? Oct 23, 2017 19:47

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

These Xilinxs tools are driving me insane, nothing but auto-generated broken software and libraries.

Spent a week trying to figure out why the Microblaze ethernet (with lwip library) was no longer working when nothing in my software had changed. I got a new FPGA image that had added another DMA block instance (1 for the ethernet and 1 for transferring audio data). Well what happens is the lwip library in xilinx SDK is hard coded to always use XPAR_AXIDMA_0_DEVICE_ID (this is the device ID assigned to a DMA instance) which works fine with only 1 DMA instance for the ethernet interface as device 0 is always the ethernet DMA instance. But when you add the second DMA instance the default name it chooses always means the ethernet DMA instance will come second (alphanumerically) and thus the XPAR_AXIDMA_0_DEVICE_ID will be set to the wrong DMA instance.

The lwip library won't report any errors as it has a valid DMA instance to use it just happens to be the wrong DMA instance and the network interface will come up and look like it's fine but won't actually work.

Once I changed the hard coded value in the lwip library from XPAR_AXIDMA_0_DEVICE_ID to XPAR_AXIDMA_1_DEVICE_ID it worked. Hooray!

# ? Oct 23, 2017 20:48

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 06:01

movax: Aug 30, 2008

Popete posted:

These Xilinxs tools are driving me insane, nothing but auto-generated broken software and libraries.

Spent a week trying to figure out why the Microblaze ethernet (with lwip library) was no longer working when nothing in my software had changed. I got a new FPGA image that had added another DMA block instance (1 for the ethernet and 1 for transferring audio data). Well what happens is the lwip library in xilinx SDK is hard coded to always use XPAR_AXIDMA_0_DEVICE_ID (this is the device ID assigned to a DMA instance) which works fine with only 1 DMA instance for the ethernet interface as device 0 is always the ethernet DMA instance. But when you add the second DMA instance the default name it chooses always means the ethernet DMA instance will come second (alphanumerically) and thus the XPAR_AXIDMA_0_DEVICE_ID will be set to the wrong DMA instance.

The lwip library won't report any errors as it has a valid DMA instance to use it just happens to be the wrong DMA instance and the network interface will come up and look like it's fine but won't actually work.

Once I changed the hard coded value in the lwip library from XPAR_AXIDMA_0_DEVICE_ID to XPAR_AXIDMA_1_DEVICE_ID it worked. Hooray!

Now, to go for broke, get your entire setup into Git and building as part of scons or some other build system without shooting yourself.

Amazingly, the workflow / tools for Zynq-based projects used to be worse. I was at Xilinx HQ a few months ago, and at least some of their senior guys admitted "yeah, we kind of hosed up" when it came to making Vivado and tools play nice with VCS.

# ? Oct 24, 2017 02:06

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

«‹›53 »