TM4C1294 ethernet, worth using or not really? - feedback

Might a bit more focused "subject/title" assist your quest?   As you state - you (know) about the "not really" results here - you seek (really) the, "Success!"

So - might, ("Have you succeeded w/xxx Ethernet?   Might we make it even better?) eliminates "woe is me" reports AND hints at (some) benefit to anyone who "lands in your web."   Recall that while we (like) to think we're programmers/engineers/scientists - to best succeed - we should often (try) to SELL!   (otherwise - w/out such quid pro quo - we're begging (almost) are we not?   (doubtful that will yield top cabin response...)

You report "having to use" - is that really/truly the case?   Who made such determination - are they qualified - might a far simpler, slower method (perhaps via multiple, parallel channels) work nearly as well?   And be delivered (so that you're paid) far faster - and w/less "pain/suffering" upon you.

The most unfortunate Exosite reports - should they overlap your usage - may cause concern.

Are low-cost, readily available, commercial elements of your need available?   Might you be able to employ those - in simple combination w/your own MCU - and solve the problem more quickly (and far more surely) in that manner?   Locking into "single source, forever" usually proves most limiting - yours may be "just one more" example....

Hi cb1,

Well, that certainly looks better :p
I wonder If i can change the title.

The project needs to use ArtNet protocol. Ethernet to DMX512.

So my instant first option - get a ArtNet device that outputs in DMX512. So I only need to make the controller receiving the DMX512 and control the LEDs.
Problems - ArtNet to DMX512 are actually pretty expensive and the interface not that fast. But the price is the real problem, I have to search more for alternatives.

Second alternative - Make a ArtNet device for example with a Raspberry PI in Linux, if needed even ask a colleague for that. Then like before add the controller but arrange UART communication between the ArtNet Receiver and the controller (could even have multiple data lines).

Third alternative - all in one.
Controller wise I would like to use another one but lack of skills on DMA and past experience and using it for this specific purpose makes me turn to Tiva (even though the 8 pin per GPIO limitation). And well there is Energia to help me with the Ethernet and lots of compatible Arduino libraries.
Other option would be a raspberry pi.

Luis Afonso said:

I wonder If i can change the title.  

Mais certainement mon ami.   Quickly, easily.  (click "edit" (your 1st post) then your title block is exposed for your access)

 Again - you only want the "wins" - who cares for the "not reallys?"   And then - you may try to SELL your post - not hope/pray/beg... (something for the responder)

If we assume that this project is "for profit" - and a critical element is "new" - that's high risk - is it not?   If you'd like my small firm's "model" - we'd only/ever (sometimes) do such if we had good evidence that the effort would not be, "One time" - and that the profit far outweighed our business risk.   As you expand your capabilities & "opportunity awareness" you should find less "need" to engage "uncertainty" - target instead, far easier, "low hanging fruit."

Might you "find" some ArtNet device (not w/DMX512) and then manage the DMX512 side yourself.   Years ago we (almost) went DMX - if memory serves your MCU skills and this vendor's devices should be "up to task."

Again - "one off" tasks do NOT a business make - and you must plan/allow for delayed shipment & even failure - make sure those events are survivable...

 

There is also Beaglebone and various commercial SBCs.


8 pin per GPIO limitation? I don't understand how there is more than one unless you include power pins. You must be using GPIO differently. In any case, DMX is slow enough that SPI expansion is a real possibility local to the micro.

Robert

Not long ago I had occasion to look at building a DMX receiver to replace the ones in light bars my employer had purchased. There are some bad implementations out there

Robert Adsett72 said:

Not long ago...I had occasion to look at (dare we say "bypass" ) light bars my employer had purchased.

As OSHA does not extend its mighty grip to your frozen tundra - upon my visit - I got (bit too close) to one of your, "light secured" (yet bypassed) machines.   (I've (almost) adapted to life w/8 fingers - can (almost) read (what remains) of my iWatch ("reconstruct mentally" the missing "A & B" of the 7 segments) and the "robot chasing me" nightmares have declined to only once/week...)

Some bad implementations, indeed...   (one-off journeys, into unfamiliar terrain, may not always yield pleasant results ... thus the earlier "caution" for young poster's (and others') consideration...)

Different kind of light bar. Around a meter in length or more, RGB LEDs, intensity of each colour controlled by DMX.

We do have similar to OSHA here and an offence such as described can and does result in fines to the company, the worker doing the bypass, the supervisor and on up to the top echelons. Fines increasing as you go up the chain. A first offense with no injury might result in mandatory training and increased inspections.

I did run into a situation south of the lakes while touring a customer's metal forming plant where they had no safety barriers. Stated reason was that it was safer because people would be more careful. Not sure why OSHA hadn't cracked down on them.

Robert

Robert Adsett72 said:

Not sure why OSHA hadn't cracked down on them. 

Perhaps because the firm was (struggling) to comply w/"You can keep your doctor/policy" - and finding such "very much not" to be the case.

Learning now of your fine detail - that appears very much over-lapped w/the application of Luis.   Strange that he's not, (yet) "all over you" for details...

This would have been about 20 years ago so well before such considerations. Though I would expect OSHA to be indifferent to such considerations

Robert

Not that much overlap really. No use of artnet and we ended up patching in a properly built driver for the one off. They didn't want to do the further selling that would have justified a proper development.

Can't blame them. This one cost a pretty penny both in initial work around and later rework.

Robert

Thus the "caution" to our young friend may prove justified... (beware - that which you seek...)

"8 pin per GPIO limitation?"
the specific application in driving smart LED strips could actually benefit from using bit-banged SPI with 8, 16, 24 or 32 lines. If the GPIO used 16 pins instead of just 8 per GPIO peripheral it would be much better.

If this was just DMX side it would be so much easier and more "main-stream".
The requester of this project asks for a too short development time for what he asks and with what I already have to do. Mid September deadline. Well, I can't just drop everything else and go do that specifically.

This supposedly has being developed for some time, they just lack the controller, hence, they want me to just provide a solution and make the software.

Not sure if I'll go through and accept this. Most likely only if I can get one of my colleagues, more experienced with Ethernet, to do the "ArtNet" part and me just make the DMX side (much easier for me and faster to develop).
Most likely I will not. Study is first. And usually this type of requests I only accept to make software more familiar and easier to develop

Luis Afonso said:

they want me to just provide a solution and make the software. 

So - have they not "discounted" your (pending) efforts - with the (never defined) "just?"    If "just" was so simple/quick - why have they not easily/quickly done (just) that?   (Ans: because this is 90%+ a negotiating ploy - seeks to drive down your time estimate to complete - and the price you may charge...)

Many here are so glad to read your writing, "Study is first!"   Bravo, Luis - you'll have the rest of your life to descend to the ranks of Robert, Amit, this reporter.

What I may suggest - mid Sept. is (just) weeks away - point that out - get them to agree (instead) to early Jan. - and raise your price!   (assumes your partner can successfully, "ArtNet" and that you can devote minimal time to this on weekends & then big/finishing effort during holiday break.)   You may then, "quote me" relaying that this represents "just" a little delay!

Note that it's not always bad to reject a "bad offer or contract."  (and unfortunate that schools avoid such issues like the plague)  (as to 8 bits/gpio - you well (know) of other ARM MCUs - not suffering that limitation...)

Agreed. And if you do provide an estimate with a reasonable to you schedule do it in writing. They will not remember the schedule or cost you provide. Also make sure you make your estimate contingent on the situation being as they describe.

Robert

Cb1, now I need many likes.

Robert

Unless you are driving slow peripherals I'm far from convinced bit banging in parallel will be faster. There's a lot of overhead in parallel bit banging.

If speed is that big an issue go to memory mapped output instead. Use a variant that supports an external bus. 74xx244s are as inexpensive as serial drivers and not harder to hookup. They just need more pins but you are already planning to give that up.

Robert

Robert Adsett72 said:

now I need many likes.   

Sigh - who doesn't?   Like barrage "on the wire!"

Your caution, "Get it in writing" absolutely spot on.   Luis - be not afraid - your request for "fairness/legality" is no weakness - instead states (clearly) that you've, "Been around the block!"  

Believe both Robert & I believe that, "You are in the driver's seat!"   Postponing delivery till post holiday - AND raising your price (based upon your recent "findings" seems very much in your best interest...  (and fully appropriate)

Sorry, that should be a '374. Obviously it's been awhile since I had to build a parallel bus.

Robert

Uh huh - since when is (yesterday) deemed, "a while?"

cb1 , "Believe both Robert & I believe that, "You are in the driver's seat!" Postponing delivery till post holiday - AND raising your price (based upon your recent "findings" seems very much in your best interest... (and fully appropriate)"

I will have to see this better. Starting tomorrow I will only have mobile net on the phone for almost a week so I might take a while to respond :/
Plus short sentences will be the rule. I really can't use a touch anything as fast or as reliably as a keyboard+mouse.



Robert Adsett72 , what overhead? :p DMA can help a bit with that.
Memory to GPIO DMA transfers are easy for me. Getting the data in the correct order ready for the DMA use, the triggers and interrupt handlers for ping-pong transfers.
That's exactly what I used for a harder Smart LED to control (it wasn't SPI, it was a weird 1 signal with timings).
If the GPIO had 16 pins then only 1 memory transfer would be needed. In the Tiva you need 2 transfers since you need 2 diferent GPIOs.
The problem (only from execution time point of view, the algorithm is simple) is that the bytes received by ArtNet would need to be converted to be in other format. Some math would need to be done to check if there is a performance boost.

What I was expecting to gain more with this 16 pin SPI was to have 16 sets of independent LED strips instead of 1 big one (in this case you need to update all the LEDs to change just even 1 LED brightness).

But about the getting all in writing. You mean in paper or digital format would be fine? Everything until now is actually recorded in chat...

Overhead of reformatting and managing the I/O.

As far as selecting sections of I/O it's doable with SPI and very simple with the parallel bus.

And refreshing/updating the output on a parallel bus becomes a simple memcpy or memory to memory DMA. I suspect memcpy is faster.

Robert

BTW, 20Mhz SPI provides about 2MBps transfer or 2kBp/ms. Transferring the entire DMX payload would take about 1/4 ms. TV refresh rate here is about 2 orders of magnitude slower if my mental arithmetic is correct. You'd need to do a fair amount of built updating of a larger set of LEDs for the update rate to matter.

Robert

By getting it in writing I mean you write at least a semi formal quote that says what you are going to do, by when, for how much. Then get them to agree that's what they are paying for.

Make sure you note that changes requested or as a result of the situation you find not being as described will require additional quotation.

The better you can describe what you expect the current condition is and what you will deliver the better chance you have of meeting expectations.

They have to agree this is what they are paying for.

I suggest PDF or paper.

Robert

Brute force can be elegant.

Robert

This forum editor doesn't manage functional

Well, I ended up refusing it. Mid September just was too close. Plus I didn't get anyone to help me with the Ethernet side.

That said it was a good thing. I've been a bit sick (which made be really be out of energy to do "sprints"). Plus I was not going to risk a bad start of the semester.

Thanks everyone for you answers :)

Let the record show that "everyone" was 2 guys. (one operating from a back room - behind a back room. The other from Canada - sometimes denoted as "back room")

Even though you "refused" the job - it will (still) prove most useful for you to follow-up/inquire as to, "How (or if) this task was completed."   Should the task have been implemented it would be useful for you to learn "by whom, for how much - and in what time-frame?"   (such is not easy - but "worth it's weight in gold" to your future design/marketing efforts...)   Getting to know "skilled others" amplifies your skills - and wins more opportunities for you - as well...