|
peepsalot posted:Why do you think you want to program directly in assembly? I was thinking the same thing, just play really any Zachtronic game if you have nothing in particular you want to accomplish.
|
#
¿
Jun 2, 2017 20:05
|
|
|
|
| # ¿ May 13, 2024 11:59 |
|
|
JawnV6 posted:How's that now? Cause everyone is actually using Thumb mode.
|
|
#
¿
Jun 2, 2017 23:14
|
|
|
Phobeste posted:My current place uses kinetis studio and processor expert. This is the eclipse rebrand and codegen setup for NXP. It succeeded CodeWarrior which was also iirc a rebranded eclipse with processor expert. We're still using it even though after NXP was bought by Freescale they moved on to yet another setup which I assume is another rebranded eclipse. Meanwhile, processor expert doesn't allow you to do some things like enable the 48mhz oscillator to run USB independently from the main clock, has seven options for everything with half of them marked DEPRECATED, and is incredibly slow. Kinetis Processor Expert/CodeWarrior/Whatever the gently caress they call it now. It all sucks rear end, automated code generators are often more trouble then they are worth and they never properly deprecate or support old code. You'll upgrade your IDE one day and your project will be horribly broken because it forces you to use their new auto-generated libraries and you'll spend a week digging through the generated code/headers to find what is hosed now and you'll then forever have to remember to go in and make that fix every time you click the "generate code" button. This isn't just a Freescale problem, tons of IDE's with code generators or built in libraries are terribly broken and never properly supported. But I ran into a bunch of annoying bugs with Kinetis Studio the one time I had to use it and it made me hate the processor expert with a fiery passion.
|
|
#
¿
Jun 13, 2017 22:18
|
|
|
iospace posted:Has anyone here have the joy of working with board that used this crap? Last place I worked at developed COTS embedded form factor units that had these and other insane connectors and where often plugged into a backplane like that. It was hell trying to pull a board out and often you'd cut up your hands when it finally came out. Also pray to God you don't bend or break a pin.
|
|
#
¿
Jun 14, 2017 23:24
|
|
|
iospace posted:Why do you think I hate cPCI so much. VME was, ok, it was pins but it felt like they were durable. cPCI you could look at them funny and they'd bend. Had to remember which one VPX was and it made my hands hurt thinking about pulling those things off their backplanes. Either your backplane had the 2 side posts to help guide the board into place without breaking the "fins" in which case the board was a bitch to pull back out, or you didn't have the side posts and the board was easy to pull out but you ran the risk of it bending and breaking pin fins or seating it at a bad angle.
|
|
#
¿
Jun 15, 2017 05:54
|
|
|
I started writing a stupid little OS for Atmel microchips. It's very early on but I got task switching to work so it runs two tasks that just print out a number. It's a fun exercise though, I plan to flesh it out eventually and add in a scheduler and maybe some kind of basic command line shell. It was pretty fun to put in the plumbing for libc stuff, like how stdin/stdout are directed to use your serial driver.
|
|
#
¿
Jun 21, 2017 18:23
|
|
|
iospace posted:Bumping this to say I'm in an intro to microcontrollers class. A class that I should be able to test out of if I could but I can't. And we're using Freescale chips. gently caress Code Warrior and Processor Expert. Are they still using that? Why every intro to microcontrollers/embedded class doesn't use Atmel is beyond me. They are cheap, have great documentation and everyone in the hobby world uses them so you can find a ton of support online. Here is my hot take of the day. gently caress every other micro, always use an Atmel.
|
|
#
¿
Sep 28, 2017 23:58
|
|
|
If you dump on Atmel I take that as a personal attack. Fight me.
|
|
#
¿
Sep 30, 2017 04:54
|
|
|
iospace posted:
What do you mean? There is a work around.
|
|
#
¿
Sep 30, 2017 06:27
|
|
|
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
|
|
|
I once blue up a wall wart charger. I was using a DMM to test voltages at certain points to figure out where I could solder in a connection and accidentally shorted a lead. The thing blew up in my face with a huge bang that about gave me a heart attack as I shorted 120 V. The power went out at my work and everyone had a good laugh at my expense. Another good one. Place I worked at we were an Intel certified partner (or something like that) so we would get new chips in months before commercial release. Intel still technically owned these chips and could request to have them back at any time and we were usually limited in how many we had. Well I got a board with one of these chips but no heat sink. One of the hardware engineers gave me a heat sink and I figured it's simple enough to screw down. The setup was a little wonky and I ended up over compressing the CPU with the heat sink and destroying it. That was fairly embarrassing.
|
|
#
¿
Nov 13, 2017 21:50
|
|
|
Speaking of Xilinx DMA, I'm about to lose my mind dealing with this scatter gather DMA engine. The FPGA guy was explaining it in more detail and he linked me to a bunch of older DMA version documents that had more detail in the operation. But it appears for multi-channel SG DMA Xilinx just tacked on a bunch of modules to their existing DMA logic and it's kind of a Frankensteins monster to parse.
|
|
#
¿
Nov 20, 2017 04:59
|
|
|
Ahhh yes of course, if you want the DMA engine to continue running after reaching the end of the buffer descriptor chain you just have to set the end chain descriptor register value to a non buffer descriptor address (so that the compare of current to end descriptor location never matches). Never mind that the DMA driver automatically figures out the last buffer descriptors address and sets this register for you. So you either have to modify the drive or know to manually change this value to be something bogus.
|
|
#
¿
Nov 21, 2017 05:45
|
|
|
Here is a link to the schematic to your board, looks like you can get SPI. https://nurdspace.nl/ESP8266#Schema Looks like the PUY-P25Q is a flash part connected via SPI. There is an open chip select GPIO0 pin 15.
|
|
#
¿
Dec 8, 2017 21:38
|
|
|
ante posted:For babby's first watch, more realistic goals would be losing maybe half a second per minute, ~2 hour runtime, and unless you're spinning your own PCB, pretty chunky. A desk clock is do-able, and will give you an idea of what you can expect for your next project They make RTC chips for this purpose, so unless you're explicitly trying to only using a microchips internal clock just for difficulties sake then you would want to grab an RTC chip such as a MCP79410 or another I2C/SPI part (Maxim?). You'll also want a coin chip holster that will power your microchip/RTC and some sorta buck regulator. If you go the RTC route which will be far more accurate than an internal micro clock you'll still end up losing probably seconds per-day so don't expect this too be a very accurate watch without regular updating. Popete fucked around with this message at 07:30 on Mar 22, 2018 |
|
#
¿
Mar 22, 2018 07:28
|
|
|
If all you wanna do is make a digital clock you get an 8 bit atmega chip and one of these. https://www.adafruit.com/product/3013?gclid=Cj0KCQjwqM3VBRCwARIsAKcekb1-lnlWlrUrXaqlfGB4C27lSpc9eMdCiivaNkmKBE0drSc9-WJcKAIaAvWbEALw_wcB It's a temperature compensating RTC that will get you pretty close. It'll still drift over time but less so. Then get a 4 x 7 segment LED panel too display the digits.
|
|
#
¿
Mar 23, 2018 05:00
|
|
|
Whats the device tree entry for your LCD panel look like? Might check if there is a reset line in the device tree entry for the LCD panel. Then take a look at the driver associated with that device tree entry and see if it's toggling the reset line. The kernel driver is likely not expecting the LCD panel to be up at boot (sounds like U-Boot is setting it up?) so it's gonna reset the LCD controller chip. There might be an option to tell it the panel is already configured, but more than likely you'll have to edit the drive to not reset/reconfigure the panel chip. Otherwise you could take the LCD initilization out of U-Boot and just wait for Linux to come up and bring up the panel first.
|
|
#
¿
Mar 30, 2018 01:46
|
|
|
My time in RTP hell is finally coming to a close. I've been working on it on and off for over a year now. It's a Microblaze softcore processor inside a Xilinx FPGA, softcore processors are new for me and they have their own little pitfalls. Lots of problems with drivers/IP components (especially the ethernet IP) not resetting correctly and maintaining stale data causing weird behavior during development. My design is running FreeRTOS with LwIP networking library support. There are 5 encode RTP (outbound) streams of stereo/5.1/7.1 audio all simultaneously being streamed out of the Microblaze/FPGA and then it supports 3 simultaneous decoded (inbound) stereo RTP streams. In reality the 3 decoded streams are actually only 1 at any given time but the Microblaze can switch which RTP stream to listen to via an interrupt coming from the main Linux processor elsewhere on the board. The difficult task was extrapolating a real audio frequency from the inbound stream. I knew ideally that the streams could either be 44.1 kHz or 48 kHz but due to network/UDP variability and audio sources being slightly different than the ideal rate the actual audio rate could vary. I feed the decode RTP stream data into a DMA engine which contains a FIFO of unkown size and I had no visibility into how full the internal DMA FIFO was at any given time, this means I never knew if it was full or empty which would cause audio artifacting. My initial solution was to use a timer in the FPGA to determine the time between any two RTP packets received and based on this time difference extrapolate a clock frequency to set the internal rate adjust clock that pulled data out of the DMA FIFO. In this way the DMA FIFO would never overflow or undeflow as I was constantly adjusting the clock rate based on the timing of packets coming in. This worked eventually after a lot of fiddling until I went back and re-enabled the encoding task in FreeRTOS (I had it turned off during development to make things simpler). This threw off my timer calculations as task switching and OS scheduling meant I couldn't easily determine the time between two tasks. Time to start all over again... One of the FPGA guys came to my rescue and had the brilliant idea to add another FIFO on the output of the DMA FIFO, this FIFO would have a level value that I could read via GPIOs. My final implementation involved pre-filling the secondary FIFO to a known level (say 1 or 2 packets deep) and then turning on the clock so data started flowing out. This way anytime I received a new RTP packet I could check the FIFO fill level and adjust the clock faster/slower to get it back to the target fill level. With some adjusting based on difference between current fill level and target fill level I came up with a "2nd order" clock adjustment algorithm that is working great! Really happy to finally have this sorted out as I was dreading how I was gonna manage to pull this off without knowing the actual level of the DMA FIFO. DMA well very powerful can be a real pain in the rear end to debug, once you turn it on there is no stopping it to take a look and poke around. Things tend to fall apart real fast and you're left looking at the broken mess to figure out what went wrong.
|
|
#
¿
May 15, 2018 05:33
|
|
|
|
| # ¿ May 13, 2024 11:59 |
|
|
Of course you would have to reference State and Score as members of the struct but you have the general idea right. Always pass a pointer to a struct.
|
|
#
¿
May 28, 2018 16:45
|
|