|
Malcolm XML posted:yeah I take it Intel bought Altera? When did that happen? It sucks trying to run a demo program and being told that an "IP Core" has expired because I'm over the 30 day free trial of some aspects of the software (but not other aspects!), for this device which cost me real Earth dollars. What a lovely move to sell a demo board and then nickel-and-dime people all over the place to buy pieces of software to actually use it. The main barrier I have right now is that I cannot get any of their provided demo code (in c) to compile on the device, so I can't get any software interface going to do things like read the ADC values. It's a feature that this board has an integrated hard processor, unlike the Mojo board, but it's not a useful feature if I am going to have to laboriously build up a huge compile chain since the thing doesn't have internet access and I have to load files onto the SD card on my desktop to transfer anything. reading fucked around with this message at 00:20 on Dec 30, 2015 |
#
?
Dec 30, 2015 00:11
|
|
|
|
| # ? May 12, 2024 22:19 |
|
|
ante posted:There's a Verilog thread that is very dead. I'm kind of surprised noone's ever tried to reverse engineer the commercial ones and come up with something better, to be honest.
|
|
#
?
Dec 30, 2015 16:36
|
|
|
People have done exactly that with some of Lattice's stuff. I haven't checked it out because who the hell uses Lattice FPGAs, FPGAs have also only really been accessible for non-professionals for 3 or 4 years, too, so I'm sure some cool stuff will happen over the next 5 years in the open source community.
|
|
#
?
Dec 30, 2015 20:28
|
|
|
http://www.clifford.at/icestorm/ for the Lattice Ice40's exists. http://opencores.org/projects also has a bunch of code (great for learning!). This is the only FPGA I've ever gotten to work, Lattice's software works alright if you read what there is of the manuals. It at least outlines what your workflow should be, step by step. The only other one I've ever dealt with was a Xilinx Spartan from about 9 years ago. They happened to have one where I was at, and we couldn't get it to do a drat thing considering none of us had FPGA experience. An open source FPGA would be a dream ... I've been working on getting it to run a grid of LED's, something it seems to excel at, it's just that TI makes a specialized device for the same price. I imagine they (the Ice40's) are really for cases where you need some more I/O with a little glue in between, where cutting out those glue parts would save a lot of time, money, and space. It's still fun to tinker with/break little processors though 
|
|
#
?
Dec 30, 2015 21:18
|
|
|
Another issue with this DE0-Nano-SoC board is that the .bat files they provide for use in Windows are supposed to load .sof and .jic files on to the FPGA, but the .bat files never work! I'm doing everything in Win7, the board is hooked up and set to the right mode, but when I run the .bat files it just tells me that it can't find the files it needs even though they are in the same folder. Everything is just like it was out-of-the-box and still almost nothing works. Really annoying. I mean how can it be that lovely? :-( The Quartus software has this nice block diagram method of programming and I was able to get one demo working that they provided a step-by-step instruction for, but I can't find a block item for the ADC or PWM so if I want that stuff I have to code it directly in .v which is slower than wiring up a block diagram. Really wish the hard processor/FPGA interaction worked. I would love for this thing to be my new beaglebone black.
|
|
#
?
Jan 1, 2016 01:59
|
|
|
You can probably find generic code for those parts online. Import the code to your project, then just convert them to block diagram parts and wire away. There is also part wizard for some more complex parts so you may have to fire that up to get what you're looking for since the standard part list is limited to pretty basic stuff. Also, if you just want to use the Nios 2/ARM, use Altera Monitor (you may have to download this separately but it's free). There should be a section in the board documentation for what IO addresses your board uses when the cpu core is loaded so you can start blinking leds using RISC assembly or C. You set the board you're using, the programmer type, then give it a source file for the asm/c code then hit program. Pretty easy compared to Quartus. They also have documentation on the Nios 2 ISA, and a separate one for ARM that you should definitely have handy. As for the board demos, the Terasic tool I got with my board is all GUI based and loads the demos fine. Maybe try downloading the latest version for your board off the website if you haven't, or try contacting Terasic to see what they recommend. I wouldn't be surprised if it was a windows compatibility issue, or having to run them as admin. elite_garbage_man fucked around with this message at 08:56 on Jan 1, 2016 |
|
#
?
Jan 1, 2016 07:04
|
|
|
I'd like to attach a bunch of accelerometers to a device that supports I2C. It looks like the three that I bought all have the same address. Is it possible to reassign addresses, or am I stuck having to do some line fuckery? I was hoping I'd be able to just attach a whole bunch of devices on the bus, enumerate them somehow, and read off data from each. The headers and source file of this device seem to hint that it's expecting a fixed address. Is this commonplace for accelerometers? Or I2C devices in general?
|
|
#
?
Jan 7, 2016 08:25
|
|
|
Jo posted:I'd like to attach a bunch of accelerometers to a device that supports I2C. It looks like the three that I bought all have the same address. Is it possible to reassign addresses, or am I stuck having to do some line fuckery? I was hoping I'd be able to just attach a whole bunch of devices on the bus, enumerate them somehow, and read off data from each. The headers and source file of this device seem to hint that it's expecting a fixed address. Is this commonplace for accelerometers? Or I2C devices in general? I2C devices usually have an address you can configure to a few different options (like 2 or 4 or 8 different addresses are common). Usually done with external pins you need to set to set the address. They also can have one fixed address which is not uncommon either. If you want to attach multiple devices to a microcontroller with the same I2C address you need something like a I2C bus multiplexer such as PCA8574: http://www.nxp.com/documents/data_sheet/PCA8574_PCA8574A.pdf Through which you can address multiple separate I2C buses.
|
|
#
?
Jan 7, 2016 14:00
|
|
|
If the address isn't fixed, there should be some address pins that allow you to set the bottom few bits of the address. If you don't have that then you're looking at using chip select/enable pins.
|
|
#
?
Jan 7, 2016 14:02
|
|
|
Thanks, goons. I don't see any external pins for address select, so I'll look into chip select.
|
|
#
?
Jan 7, 2016 22:59
|
|
|
Jo posted:Thanks, goons. I don't see any external pins for address select, so I'll look into chip select. What chip are you using?
|
|
#
?
Jan 7, 2016 23:24
|
|
|
That's unfortunate; many I2C devices I've seen have at least two pins for configuring the same number of bits (usually the LSBs) of the address. Edit: It's not an optimal solution, I'm sure, but consider using the hardware bus master for one of the ICs and bit-banging the others with GPIO pins and a software library.
|
|
#
?
Jan 8, 2016 18:09
|
|
|
Probably going a bit into the newbie side here, but I plan on setting up my Beaglebone Black as a Plex media server (direct stream, transcoding disabled) to take over functionality from my desktop machine. Has anyone here done something similar with a BBB? Is there a preferred OS? An OS that supports Limelight game streaming would be heavily preferred, but less important.
|
|
#
?
Jan 8, 2016 22:04
|
|
|
Aurium posted:What chip are you using? Xadow COM01400P.
|
|
#
?
Jan 9, 2016 02:05
|
|
|
Huh, that's a neat little package. The chip at the heart of it is: http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf That has 1 address bit "ALT_ADDRESS", with page 18 describing the functionality: quote:I2C
|
|
#
?
Jan 9, 2016 02:31
|
|
|
Jo posted:Xadow COM01400P. Ok, that board uses the ADXL345. Since it's it's using the address 0x53, that means they've grounded the alt address pin (pin 12 in this case), if you raise it high, you can get the address 0X1D. Info found on page 18 of the datasheet. Unfortunately, the board you're on has that pin directly connected to the ground fill of the board by a couple of relatively small traces. You could potentially cut them and then solder a wire to the pad and raise it high that way. Unfortunately, one of the traces you need to cut is directly underneath the accelerometer itself. So you'd need to desolder the chip, cut the traces, resolder the chip, and then add a wire to a pretty small pad. Difficult. I wouldn't do it unless I had no choice. It'd be easier to build my own board. Instead, you're probably going to have to bitbang i2c, hope whatever uC you're using has multiple i2c channels, or use a i2c bus multiplexer. I'd recommend the last http://hackaday.com/2015/08/12/i2c-bus-splitting-with-a-more-professional-touch/
|
|
#
?
Jan 9, 2016 03:12
|
|
|
Aurium posted:Unfortunately, the board you're on has that pin directly connected to the ground fill of the board by a couple of relatively small traces. I very nearly added "and wait till Aurium strolls through after peeking at the layout to explain why it's impossible"
|
|
#
?
Jan 9, 2016 03:25
|
|
|
Couldn't you just control the /CS line to enable the device to be in I2C mode and that is enough? You could then hook up as many devices as you want and set the correct GPIO to drive the /CS when you want to read/write I2C.
|
|
#
?
Jan 9, 2016 18:21
|
|
|
Popete posted:Couldn't you just control the /CS line to enable the device to be in I2C mode and that is enough? You could then hook up as many devices as you want and set the correct GPIO to drive the /CS when you want to read/write I2C. The idea of an I2C device with a chip select boggles my mind; guys, just use SPI if you're going to do that 
|
|
#
?
Jan 9, 2016 18:44
|
|
|
feedmegin posted:I'm kind of surprised noone's ever tried to reverse engineer the commercial ones and come up with something better, to be honest.
|
|
#
?
Jan 9, 2016 21:04
|
|
|
Aurium posted:Ok, that board uses the ADXL345. Since it's it's using the address 0x53, that means they've grounded the alt address pin (pin 12 in this case), if you raise it high, you can get the address 0X1D. Info found on page 18 of the datasheet. Thanks so much! The last link looks like a perfect solution. Will report back if anything interesting happens.
|
|
#
?
Jan 9, 2016 22:22
|
|
|
I'm new at embedded stuff above bare-metal, so be gentle. I'm working with a MIPS24KEc-based SoC (MT7688) that has 3 16550A-compatible UARTs. It's running OpenWRT based on the 3.18 kernel. Two of the UARTs are used for communicating with peripherals using a binary protocol at 34800 baud. They're located at /dev/ttyS1 and /dev/ttyS2 (ttyS0 is for console access) and I didn't really have anything to do with setting this up, but I can modify the device tree if needed. Under difficult to replicate conditions, but presumably when the system is loaded, the two UARTs connected to peripherals occasionally overflow their receive FIFOs and drop bytes. This occurs dozens of times an hour. I've detected this by putting a brief printk in 8250_core.c where the OD bit is detected and seeing it in the console log. I know that printing from an interrupt is usually a bad idea and I assume that my printk is making things worse than they actually are by slowing down the isr handler, but I don't know how else to get debug information out of the interrupt... I've also verified that the link is good and the sender is working ok by tapping the line with a faster computer and sniffing the data coming across. TL;DR I think that the issue is caused by the kernel not emptying the receive FIFO quickly enough, but I don't know how to speed that up. One thought is that the interrupt priorities are too low, they're set as 29 and 30 according to /proc/interrupts. Is this adjustable? The interrupt is set to trigger when there are 8 bytes in the FIFO, this is a hard-coded configuration in 8250_core.c... I could change it if I need to, but it feels wrong.
|
|
#
?
Jan 9, 2016 23:04
|
|
|
evensevenone posted:My understanding is that the problem is that even though they present themselves as just a bunch of identical logic elements, for performance reasons vendors have started adding special purpose hardware inside the fabric for commonly used stuff but all of that is hidden under the hood and they don't tell you any details, just that it will behave the same. Around the mid 90's one company did reverse engineer the Xilinx configuration bitstream for use in their third-party EDA suite. Xilinx bought them out. Focusing on the Xilinx ecosystem, creating a complete open-source replacement to Vivado/ISE today would constitute an unimaginable amount of effort. Certainly there are bits which you can and do replace (the IDE, netlist generator, simulator, etc.) but I can't see anyone replacing the core technology mapping and place-and-route because modern FPGAs are so drat huge and complex. They're not just glue-logic sea-of-gates with interconnect anymore, rather heterogeneous devices which include block RAM, DSP blocks, PLLs, SERDES, and whatever else can be shoehorned onto the die. None of this is particularly obfuscated (you need to know a lot about the device in order to efficiently target it and do manual floor-planning), the problem is how a third-party would do a place-and-route such that the timing and power analysis is correct.
|
|
#
?
Jan 10, 2016 03:03
|
|
|
BattleMaster posted:The idea of an I2C device with a chip select boggles my mind; guys, just use SPI if you're going to do that It's actually quite a clever device. When /CS is high it's an i2c device, when it's low it's a SPI device. You're also not going to be able to do any /CS fuckery on this board either to have only one of them respond to I2C commands at a time either. Once again it's tied to high with a trace that goes underneath the chip. Jo posted:Thanks so much! The last link looks like a perfect solution. Will report back if anything interesting happens. Good choice, after I posted my last message I came to the conclusion that the other 2 options would be nearly impossible on that hardware without things like hacked up flatflex cables, or your own custom boards (with flatflex cable hookups), or really fine hardware mods. With the bus multiplexer you'd just need one board that already breaks out the SDA/SCL lines, which it looks like all the boards do, as well as a carrier board for the multiplexer itself (ok, you could deadbug it...). Note that whatever the board is that you're using to breakout the SDA/SCL lines has to be something other than the accelerometer board. The multiplexer needs to be in front of all of the devices with the same address. After the multiplexer though, you'd just solder to the SDA/SCL breakouts on the accelerometer boards.
|
|
#
?
Jan 10, 2016 07:19
|
|
|
Knyteguy posted:Probably going a bit into the newbie side here, but I plan on setting up my Beaglebone Black as a Plex media server (direct stream, transcoding disabled) to take over functionality from my desktop machine. Just for future reference in case someone wants to tackle this - With a Beaglebone Black Rev A6 board (so a very old one), I setup Ubuntu 14 on it flashed from an SD card. I feel like this was the most difficult part. I tried Debian/Angstrom first, but I couldn't find a lot of useful troubleshooting guides. After the OS installed I followed this guide (I think, it may have been the Banana Pi one) to get Plex Media Server installed: http://www.htpcguides.com/install-plex-media-server-on-raspberry-pi-2/ Starting from: pre:wget -O - https://dev2day.de/pms/dev2day-pms.gpg.key | sudo apt-key add - Finally I setup this script code:I'm powering the board and external HDD with a powered USB hub, and voila it's a nice little NAS/DLNA server. I'll probably get NFS on there soon also. The media server/non DLNA Plex will work where there's no transcoding required. A more powerful board could transcode. If you wanted to get a micro HDMI/adapter you could likely get Moonlight game streaming working (along with this Steam Emulation manager I wrote!), but I decided it wasn't worth the effort at the moment. Knyteguy fucked around with this message at 18:41 on Jan 11, 2016 |
|
#
?
Jan 11, 2016 18:27
|
|
|
meatpotato posted:I know that printing from an interrupt is usually a bad idea and I assume that my printk is making things worse than they actually are by slowing down the isr handler, but I don't know how else to get debug information out of the interrupt... I've also verified that the link is good and the sender is working ok by tapping the line with a faster computer and sniffing the data coming across. The typical way to break things up is to have something in the ISR do a very lightweight memory operation (i.e. copy FIFO length & OD bit out) then have application code come along later and process it. So in your ISR, have it write whatever information you need (hopefully measured in bytes) into some shared structure and another process poll there to take the results and print them out for you. If it's possible to have several ISR's fire before application code could empty the results out, either set the results area up as a ring buffer or just mark that you're deleting old data. Specific to your problem, on the system level switching to a speed faster than 38400 or using hardware flow control on the UART could help. Making the buffer deeper might make the condition more rare, but probably won't solve it entirely and if the length is hard-coded your concern that something else might not work properly may be correct.
|
|
#
?
Jan 11, 2016 20:46
|
|
|
I've been learning Verilog over the past few months and a somewhat trivial question has been bugging me. Is there a reason to do declarations like this in Verilog:code:code:
|
|
#
?
Jan 12, 2016 01:42
|
|
|
Here's a reason:code:What I would prefer is to define input/output in the module declaration, and then size (if variable) below, but that causes ModelSim to barf (seems to want all or nothing in the declaration). I'm sure an experienced Verilog user would shudder at the way I do it, but it works for me. Edit: wrote that on a phone and butchered it.
|
|
#
?
Jan 12, 2016 01:58
|
|
|
Mr. Powers posted:Here's a reason: You can't use a defparam in a parameter block, so if you want to calculate widths from maximums without putting $clog2's in all your definitions, you need to use the first style you have where you can declare your params and defparams before your interface types/sizes. Makes sense, and explains why the manufacturer's ram example does it like that. I haven't messed with params much, just trying to make stuff work in eight bits and then I figured I'd shove 'em in once I got some good modules. Guess I'm gonna have to fix the old ones ... I've been using Icarus Verilog and it'll eat anything apparently ... I feel like it is inevitable that everything I write in Verilog would make at least one other Verilog user puke if they were to see it. dougdrums fucked around with this message at 02:38 on Jan 12, 2016 |
|
#
?
Jan 12, 2016 02:34
|
|
|
code:
|
|
#
?
Jan 12, 2016 03:07
|
|
|
JawnV6 posted:Yeah printf in a ISR is generally a bad idea. ISR's should be short and direct, very little flow control and certainly nothing like unbounded polling. I still haven't figured out why the system isn't servicing the ISR quickly enough, but I've discovered debugfs and think it may be a less-idiotic way of getting the stats I need into userspace than printks in an isr. Can you tell I'm a Linux noob? It also turned out that lowering the 16550 FIFO interrupt trigger level from 8 to 4 bytes didn't significantly fix the issue after running a longer test. The improvement was only ~10%, so something more serious is going on but I'm not sure what it is. I'll keep poking around and post if I fix it, thanks for taking the time to think about it. EDIT: Whoops, looks like debugfs isn't what I want at all! I thought it was kind of like /proc files. Hunter2 Thompson fucked around with this message at 00:58 on Jan 13, 2016 |
|
#
?
Jan 12, 2016 21:29
|
|
|
Ponderous Saxon posted:Around the mid 90's one company did reverse engineer the Xilinx configuration bitstream for use in their third-party EDA suite. Xilinx bought them out. There's been some recent work to get an opensource setup for the Lattice iCE40. Not being a FPGA guy, I don't really know how finished it is, but it claims to be "feature complete (with the exception of timing analysis, which is work in progress)." Which you already noted as one of the major potential stumbling blocks. https://media.ccc.de/v/32c3-7139-a_free_and_open_source_verilog-to-bitstream_flow_for_ice40_fpgas#video
|
|
#
?
Jan 15, 2016 19:53
|
|
|
Aurium posted:There's been some recent work to get an opensource setup for the Lattice iCE40. Not being a FPGA guy, I don't really know how finished it is, but it claims to be "feature complete (with the exception of timing analysis, which is work in progress)." Which you already noted as one of the major potential stumbling blocks. This is what I've been using, everything has worked as expected. I think the PLL isn't supported, but I haven't tried to use it yet. Lattice's tools work fine too (and come with the dev board), but make is easier to use and I don't want to use a VM. The iCE40 line is all pretty tiny too, I'm thinking that may help.
|
|
#
?
Jan 15, 2016 20:31
|
|
|
elite_garbage_man posted:You can probably find generic code for those parts online. Import the code to your project, then just convert them to block diagram parts and wire away. There is also part wizard for some more complex parts so you may have to fire that up to get what you're looking for since the standard part list is limited to pretty basic stuff. Thank you for the info. I'm still working with this thing. Currently I can't run that DE0_Nano_ControlPanel.exe because it can't find the jtag .dll (same problem as this guy http://www.alteraforum.com/forum/showthread.php?t=45942 . I'm also in Win 8.1, 64 bit). I have recompiled several of the demonstrations using this chip (since they naturally come compiled with a different chip as their target! What the heck!) and loaded them on the board without any complaints from Quartus or the Programmer. However all they do is keep all the LEDs very dimly lit, so, there must be some error in the logic or pin assignments that I need to find and fix. This is the Gsensor demo and the PWM LED demo.
|
|
#
?
Jan 16, 2016 23:42
|
|
|
There's a third party packaging Windows 8.X/10 drivers for the programmer. I'll find the link... http://altera-guide.blogspot.com/2012/11/many-collage-students-find-ourselves.html?m=1 I did this method on 10 64 and it worked. I was skeptical of the Dropbox link, so I grabbed the files from FTDI directly.
|
|
#
?
Jan 17, 2016 09:01
|
|
|
Does anyone work with TI's MSP430 line and their open source GCC toolchain? I'm picking up a project that I haven't touched in three years which was originally built with MSPGCC. I decided to download the new TI toolchain and give it a spin but it's giving me some linker problems which seem to be related to generated code size. Using the MSPGCC toolchain and -g -Os I get the following from size: code:code:
|
|
#
?
Jan 19, 2016 23:52
|
|
|
Did the linker script change at all? Or is it pulling some generic description instead of something specific to the G2231?
|
|
#
?
Jan 19, 2016 23:56
|
|
|
JawnV6 posted:Did the linker script change at all? Or is it pulling some generic description instead of something specific to the G2231? I'm not sure about MSPGCC. As far as I can tell the only hint that it has that it's looking at a G2231 is the -mmcu=msp430g2231 option. If it's using something specific that seems to be opaque to my Makefile at least. The TI toolchain was being specifically passed ( via -T) some msp430g2231.ld script that was distributed with the toolchain. Sorry, I forgot to mention that in my first post  The link result is the same whether I pass or don't pass the linker script argument.edit: my grammar is bad today csammis fucked around with this message at 00:19 on Jan 20, 2016 |
|
#
?
Jan 20, 2016 00:17
|
|
|
There should be a header file like msp430g2231.h, make sure it's not grabbing something generic like msp430g2xx1.h. But that's just for SFR's and other chip-specific things, missing that would not cause your current problem and if you're failing linking you're beyond anything in that header. The .ld script is where errors like that come from. All my work was with CCS, so I'm sorta guessing at the mspgcc setup, but is the failing build producing a .map file anywhere? I can't suss out which numbers are wrong, you have 128b/0x80 of actual RAM, in no base is '54' too large to be contained in that by 80. The map file should tell you what's getting put where.
|
|
#
?
Jan 20, 2016 00:26
|
|
|
|
| # ? May 12, 2024 22:19 |
|
|
JawnV6 posted:There should be a header file like msp430g2231.h, make sure it's not grabbing something generic like msp430g2xx1.h. But that's just for SFR's and other chip-specific things, missing that would not cause your current problem and if you're failing linking you're beyond anything in that header. I was using <msp430.h> but I tried changing it to <msp430g2231.h> just to make sure it wasn't including anything squirrelly. It didn't result in any change to the linker output. quote:.ld script is where errors like that come from. All my work was with CCS, so I'm sorta guessing at the mspgcc setup, but is the failing build producing a .map file anywhere? I can't suss out which numbers are wrong, you have 128b/0x80 of actual RAM, in no base is '54' too large to be contained in that by 80. The map file should tell you what's getting put where. Yeah, I've got maps from both. gist for MSPGCC, gist for TI's msp430-gcc. I've never looked at linker output in this detail but taking a stab at this... TI's linker is bringing in many more symbols. There's a metric ton of crap in the TI generated .text segment that isn't brought in by mspgcc...looks like TI is bringing in all of libc even though it's not explicitly referenced in code. Okay swell. Adding -nostdlib yields a different linker error: code:code:
|
|
#
?
Jan 20, 2016 17:10
|
|