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

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

About to purchase an Altera DE0 nano board. Am I getting myself into trouble?
I know nothing about FPGA and hardware design and I don't really understand HDLs.

Also what's a good book on hardware design + vhdl/verilog? Preferably something that doesn't shy away from the math.

# ¿ Mar 16, 2013 00:43

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 15:46

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Dolex posted:

Get a spartan S3 (http://www.xilinx.com/products/boards/s3_sk_promo.htm) and this book http://www.amazon.com/FPGA-Prototyping-VHDL-Examples-Spartan-3/dp/0470185317/

The DE0 Nano is good if you kind of already know what you are doing.

Those boards are also $200. The de0 is like $90.

Thanks for the book suggestion--even though it says xilinx it seems that most of it will transfer to altera with no real issues.

# ¿ Mar 17, 2013 16:42

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

movax posted:

The absolutely cheapest way to get started in my opinion is the TI MSP430 LaunchPad. For the price of a Starbucks thingy, you get the programmer/debugger, the chip, loving everything.

C is not that hard! You can definitely make things blink with just a few lines, and it'll get you in the nice habit of reading datasheets to find the information you need. Once you know that, every subsequent processor is easy. It's reflexive: "hey, I need to wiggle some pins...I should look for a chapter called 'Ports' or 'Digital I/O', and find their equivalent of data direction reg, port data reg, and latch reg". Likewise for any hardware peripherals.

Did I mention that's its less than $5 and a few hours of your time? Well, OK, so add a few bucks for shipping. Still cheap as balls.

Ti ships them for free but it takes a while. Really nice hardware and a closer to metal feel than arduino

# ¿ May 22, 2013 17:44

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

Eh, I wouldn't get it just for that. It's all "open" in some sense, but re-flashing the FPGA didn't seem like a high priority to make accessible.

Ugh, you would want to use BlueSpec...

What's wrong with bluespec?

# ¿ Jun 3, 2013 21:39

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Rescue Toaster posted:

I would at least take a look at FRAM. There's a few different manufacturers, and it's more mature. I have no idea what the MRAM cost is, but FRAM can get fairly cheap in reels of 1500 for such a specialized chip.

If you just need a few for a project, FRAM is available in regular packages (soic8) vs just QFN, though it is about $12 bucks per chip for say 1Mb.

TI makes an MSP430 with some FRAM embedded on it but it's ~64KB tops

# ¿ Jun 16, 2013 15:36

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

RTOS literally exist to provide real-time guarantees. It's half of the name. They offer easy hooks for writing ISR's and enforcing guarantees between them. I really don't know which ones you've worked with, but if you think they somehow enforce dynamic memory or a stack frame I'm not sure what to say. Most of them compile down to a static system you can inspect without much trouble if you've got that much skepticism about it.

Stupid question: if you need hard realtime guarantees why go with an rtos on a uc over an fpga where you implement your algorithm in logic? Cost, complexity, validation? I think there are some fpga with hard procs embedded too for convenience.

# ¿ Sep 7, 2013 08:59

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

I found hdl to be superficially like writing frp code but I only made LEDs blink so I don't know how generalizable that is

Fwiw conal Elliot, the arrowized frp guy now does work for an fpga company and arrows are very good at describing frp so maybe there's something useful there

# ¿ Dec 5, 2013 23:44

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Spatial posted:

Continuing this discussion.

The total memory budget is 1KB, of which 256 bytes are reserved for user code. To give you an idea how constrained this thing is, the native firmware has a mere 96 bytes of stack memory.

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.

Even if you do t use forth look at how forth was built to get compact code

# ¿ Jul 10, 2014 00:22

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

No Gravitas posted:

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!

sqlite

# ¿ Jul 15, 2014 15:50

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

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

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

I'm selecting a protocol for an embedded sensing device to package up readings and deliver them to the cloud. The embedded side is a m4 in C, nothin' fancy like a file system. The cloud is python, java, or scala. The options I'm considering, along with my windbag opinions:

1) MessagePack - C support is good. Restricted to JSON isn't. I have 2-byte unique identifiers for most of the data types, going to single or double-character field names for the protocol to compress seems like a loss.

2) Protocol Buffers - Leading right now. Requires specifying format ahead of time, which isn't too bad. Someone kindly linked the spec for the wire format and I'm confident I can suffer the headache of linking that once or generate it to a specific target.

3) Cap'n Proto - The engineer who wrote protobufs wrote this afterwards. Meant as an in-memory storage as well as network transmission. I'm not really sold on it. No C support, less other-lang support than protobufs proper. As much as I like the idea of network transmission being as simple as a single pointer, mucking up every in-memory structure doesn't seem worth it.

I'm going to spin up one or more of these and see how it does with my real data. But I'd welcome other opinions about solving this problem.

protobuf is pretty rock solid.

for other fun binary encoding times, consider avro, thrift or bond!

# ¿ Sep 28, 2015 19:57

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

travelling wave posted:

Does anyone know why people define bit flags like this:
code:
#define FLAG1 1
#define FLAG2 2

reg = (1 << FLAG1) | (1 << FLAG2);
rather than like this:
code:
#define FLAG1 (1 << 1)
#define FLAG2 (1 << 2)

reg = FLAG1 | FLAG2;
I see both a lot, but I can't think of a single reason to prefer the first.

you could then use an enum with autoincrement

code:

enum Flags {
ENABLE_FART = 1,
ENABLE_BUTT
}

# ¿ Nov 29, 2015 14:08

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

reading posted:

Has anyone here worked with the Altera Cyclone V development board, the DE0-nano-SoC?

I cannot get most of their demo programs to run on the default linux install! Pretty ridiculous how poorly supported this stuff is. And hardly anything on the web, although I expect that for something esoteric like an FGPA dev board.

Is there an FPGA thread anywhere in the forums? I checked SH/SC.

yeah

i gave up when quartus shat the bed 4 times in an hour

if the only thing intel does w/ altera is make good fpga tools it'll be amazing

# ¿ Dec 29, 2015 23:19

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Use Netfpga

# ¿ Apr 7, 2016 09:49

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Stick your iot poo poo in electrical gangboxes. Easy to service and any electrician can add or remove them.

# ¿ Jan 26, 2017 21:22

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

csammis posted:

Yeah, I wasn't thinking about the voltage drop over house-length runs

Further advantages of gangboxes: you can mains to them and put in a cute little power supply.

Don't tell your home insurer!!!!

# ¿ Jan 26, 2017 21:23

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Alternatively run Ethernet and a 48vdc PoE switch

# ¿ Jan 27, 2017 12:33

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

This is the one argument that I sorta believe, and that wavers day to day. The folks I know who are super into RISC-V are all carrying axes to grind, and they do that bitcoin thing where criticism from nearby-field experts are brushed off as "so make ur own orthogonal extensions "

There was one serious name getting floated around but everything attached just looks like an empty pitch?

Nvidia is using it on GPUs as a watchdog micro

Tbh it will likely compete more with xtensa and arc than arm unless apple decodes to stop paying for an arm license. Maybe it'll kill off some softcores on FPGA. The hifive1 mcu is neat but niche. Isa just doesn't matter that much when the code is high level.

Also, Arm ip libraries are just more complete and developed.

Malcolm XML fucked around with this message at 19:24 on Nov 9, 2017

# ¿ Nov 9, 2017 19:22

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

I dug around, the info's out there. Back when ex-coworkers were trying to recruit me for the thing it was hush-hush, but I was thinking of Dave Ditzel.

If anything's going to cause a paradigm-breaking shift in computing architecture, it'll have some tie to Transmeta. Those folks got so, so much right.

Could just as well be an inscrutable state machine, worst case it balloons into a ME equivalent.

It's basically a ME equivalent. it runs a bunch of "security" code and handles some DRM stuff too. The designer gave a talk about it https://www.youtube.com/watch?v=gg1lISJfJI0

# ¿ Nov 9, 2017 23:57

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 15:46

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

JawnV6 posted:

Just set up the first scatter target as the end chain descriptor and have the DMA engine reprogram itself

That's devious as heck

# ¿ Nov 23, 2017 02:36

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