Electronics > FPGA
I am looking for help completing an FPGA project or two.
mr_darker:
I can pay (not right this moment, but the work can certainly wait too).
I recently decided I need to stop spending time on electronics and technical stuff, and spend more time having fun. But, I do have a few projects I'd like to have completed so there is not that eternal "what if" question on whether or not it was a good idea or not. So I'd like to see if I can just hire out little portions of my projects at a time to people way more experienced than myself, as I should have a whole team working on things, not just little old me spending 100 hours on google per issue.
To start, I was trying to make a sort of adapter for vending machines, one for each communication protocol. At a minimum it needs to take care of the low level stuff like bus timing and parity bits and such, and turn parallel (or paralell/serial combinational protocols) into one abstract little UART interface. I was gonna use a Lattice ICE40UltraLite for this, due to its low cost.
But, to start, there are two protocols I'd like to PROGRAM (in VHDL) for (then try and make ONE universal adapter later, which I can do). The first one is MicroMech, and the second one is MDB. I can describe both and help with questions about the protocols, I just.... don't have VHDL experience. I made a blinking light program, and could never figure out how to get it working, couldn't figure out how to link to the internal oscillator. So I figure I ought to hire someone else if I struggle to blink a light. The protocols are primarily UART based, MicroMech has some parallel pins though (the entire protocol fits on one page/paper), and MDB has 9 bits of data which there seems to be only 2 bridge chips for, in existence, and in short it's just better to make your own on an fpga. MDB is a lot more complicated, however, I plan to do most of the data-processing on a processor, and just use the FPGA as a physical & digital adapter.
Idk, the project as a whole is a giant system of hardware/software intended to sorta re-write how technology works in the industry. Don't gotta believe in that, u get paid either way ^-^ I don't even care if it works I just want it done :-; "it's been 84 years."
Anyways, I got more projects too, and more parts of the same projects. So if looking to do stuff. Just please don't be rushed, like I just recently got a nice job, and am trying to pay off a couple bills before I start allocating money to unnecessary stuff. I'd have to say you get paid per job completed instead of per hour :O Idk lemme know if anyone interests.
rstofer:
That MDB protocol is HUGE! I hope you are making a slave, not a master.
I would do all of the protocol stuff in a very high end uC. I might use an FPGA for the bottom layer interface but none of the protocol logic. It's just too complicated and machine specific.
You can manipulate the parity bit of the standard serial protocol by dynamically changing between odd parity and even parity. I seem to recall that some UARTs can directly set the parity but my memory is hazy. Nevertheless, this is the kind of thing an FPGA would excel at. Much easier to do with an FPGA than with a uC UART.
Use a uC for the heavy lifting and the FPGA do handle the transmission/reception.
I didn't look at the other protocol.
SiliconWizard:
Yep, MDB is a pretty big protocol.
OTOH, the low-level part seems pretty basic? I haven't looked thoroughly, but it seems to be some kind of asynchronous serial communication over a bus a bit like RS-485? Couldn't even the low-level part be implemented in a MCU?
rstofer:
--- Quote from: SiliconWizard on December 22, 2019, 04:23:10 pm ---Yep, MDB is a pretty big protocol.
OTOH, the low-level part seems pretty basic? I haven't looked thoroughly, but it seems to be some kind of asynchronous serial communication over a bus a bit like RS-485? Couldn't even the low-level part be implemented in a MCU?
--- End quote ---
Yes but the ugly part is using the parity bit for the 9th 'mode' bit when the only options are None, Odd or Even. You would need to know the parity of the 8 bits and then set parity odd or parity even in the configuration to force the 9th bit. Some UARTS allow you to set parity to '1' or '0' directly (as opposed to just odd or even) and these would be better but you kind of get what you got when you move to a uC.
I would probably implement the UART in a CPLD or the physically smallest FPGA I could find. I would take and put 9 bits broadside into the uC (assuming enough pins) and let the CPLD/FPGA handle the serial communications. UART chips tend to be large, probably larger than a small CPLD, but I might look around for one that would interface with my uC and have direct access to the parity bit.
uCs don't always have a lot of pins so maybe the machine interface is handled with the FPGA and the FPGA presents things like switch contacts over an SPI or I2C interface to the uC exactly like a port expander. Or, use a uC with a LOT of pins and they are out there.
What I would avoid doing is implementing the MDB protocol itself on an FPGA. Unless... If I dropped a CPU core in the FPGA for which I had a C compiler and there was enough memory to do something like that, then, sure, the uC is redundant.
Zynq? One of the new Cypress PSOCs with dual ARM cores? I checked the PSOC documentation and their UART doesn't allow for setting the parity to 1 or 0 directly. It does support 9 bit addressing and I didn't follow that idea far enough.
blacksheeplogic:
--- Quote from: rstofer on December 22, 2019, 05:43:24 pm ---Zynq? One of the new Cypress PSOCs with dual ARM cores? I checked the PSOC documentation and their UART doesn't allow for setting the parity to 1 or 0 directly. It does support 9 bit addressing and I didn't follow that idea far enough.
--- End quote ---
I implemented a full UART on a Cyclone 4 but that was more of a case I could not think of something better to do with the Cyclone 4 in my spare time.
Altera Cyclone V with dual ARM cores is also another option. I've started using Terasic Cyclone V TSOM's for weekend projects. I like the module approach.
Navigation
[0] Message Index
[#] Next page
Go to full version