search

free-pdk / free-pdk.github.io

Source of the Free PDK documentation website.
https://free-pdk.github.io
MIT License
22 stars 9 forks source link

Convert uC-specific Information and Pinouts to a table #12

Closed serisman closed 4 years ago

serisman commented 4 years ago

I think it would look better, and we could fit more information, if the following section was converted to a table:

image

Maybe, something like this: Padauk MCU IO (max) Ins. Set ROM RAM Timers PWM COMP ADC Special Datasheet
PFS154 14 14-bit 2KW Flash 128 bytes T16, T2, T3 2x 8-bit, 3x 11-bit Yes - 4x LCD Datasheet
PFS172 14 14-bit 2KW Flash 128 bytes T16, T2, T3 2x 8-bit Yes 12x 8-bit - Datasheet
PFS173 18 15-bit 3KW Flash 256 bytes T16, T2, T3 2x 8-bit, 3x 11-bit Yes 13x 8-bit 5x LCD Datasheet
PMS15A 6 13-bit 0.5KW OTP 64 bytes T16, T2 1x 8-bit Yes - - Datasheet
PMS150C 6 13-bit 1KW OTP 64 bytes T16, T2 1x 8-bit Yes - - Datasheet
PMS152 14 14-bit 1.25KW OTP 80 bytes T16, T2 1x 8-bit, 3x 11-bit Yes - - Datasheet
PMS154C 14 14-bit 2KW OTP 128 bytes T16, T2, T3 1x 8-bit, 3x 11-bit Yes - 4x LCD Datasheet
PMS171B 14 14-bit 1.5KW OTP 96 bytes T16, T2, T3 1x 8-bit Yes 11x 8-bit - Datasheet
serisman commented 4 years ago

We could also have a column that shows EasyPdkProg support with a minimum version #, or 'in development', or 'read-only', or blank depending on what the support level is.

cpldcpu commented 4 years ago

Not as easy, as the markdown tables are quite inflexible and immediately break the layout. It may be necessary to reduce the number of columns further.

grafik

cmfcmf commented 4 years ago

Not as easy, as the markdown tables are quite inflexible and immediately break the layout. It may be necessary to reduce the number of columns further.

You could also use an HTML table in the markdown file, if that is easier. Regarding the number of columns / width of the table: We should be able to use some CSS trickery to make the table horizontally scrollable (similar to the table-responsive class used by Bootstrap: https://getbootstrap.com/docs/4.5/content/tables/#always-responsive).

cpldcpu commented 4 years ago

Ah, that's a nice table class. How do we get it into this project?

Edit: Maybe the main layout should also be a bit wider in its default desktop configuration.

serisman commented 4 years ago

Edit: Maybe the main layout should also be a bit wider in its default desktop configuration.

I was thinking the same thing. 👍

cpldcpu commented 4 years ago

Oh my, it took me more than one hour to figure out how to override the width settings. But now I should be able to address this...

cmfcmf commented 4 years ago

Oh no, didn't you see #14?

cpldcpu commented 4 years ago

Oh no, didn't you see #14?

oops - i should not multitask so much. Going to merge everything.

I now added added a table. Some device information still needs to be added. Let me see whether your change helps making it dynamic.

grafik

serisman commented 4 years ago

I can help lookup / confirm device information. What still needs to be added?

cpldcpu commented 4 years ago

I'll just use your table above to populate the remainder.

I am not sure about the OSS status for every device, though. Are all of the currently listed devices supported?

Other than that, there are still chips missing from here: https://github.com/free-pdk/free-pdk.github.io/tree/development/chips

serisman commented 4 years ago

I'll just use your table above to populate the remainder.

Ok, that should work.

One note... instead of saying ADC: 1x 8-bit, I think we can just say ADC: 8-bit, or ADC: 12ch 8-bit. It is probably assumed that there is only one actual ADC.

Also, we can link the Arch column to the appropriate instruction set html files.

Did we decide whether or not to have a column to the official Padauk website for each device from this table?

I am not sure about the OSS status for every device, though. Are all of the currently listed devices supported?

I believe they are all supported now, but some of them require the 'development' branch of the programmer. That's why I was thinking that maybe we would specific a minimum version number for each IC. The current release 1.2 officially supports PFS154, PFS173, and PMS150C (not sure about PMS15A). The rest of them require the not yet released 'development' branch I believe. I'm not sure if there is a previous (before 1.2) version that supported some of these or not? Maybe the programmer needs a CHANGELOG...

Other than that, there are still chips missing from here: https://github.com/free-pdk/free-pdk.github.io/tree/development/chips

Which chips are missing?

Just noticed the <br>s in the chip files. That feels wrong to me. Are those actually needed for proper layout?

cpldcpu commented 4 years ago

One note... instead of saying ADC: 1x 8-bit, I think we can just say ADC: 8-bit, or ADC: 12ch 8-bit. It is probably assumed that there is only one actual ADC.

Good proposal. Done.

I am not sure about the OSS status for every device, though. Are all of the currently listed devices supported?

I believe they are all supported now, but some of them require the 'development' branch of the programmer. That's why I was thinking that maybe we would specific a minimum version number for each IC. The current release 1.2 officially supports PFS154, PFS173, and PMS150C (not sure about PMS15A). The rest of them require the not yet released 'development' branch I believe. I'm not sure if there is a previous (before 1.2) version that supported some of these or not? Maybe the programmer needs a CHANGELOG...

Hm, indeed. Instead of "Yes", we should probably add the minimum version of SDCC and the programmer. But that will be quite tedious...

Other than that, there are still chips missing from here: https://github.com/free-pdk/free-pdk.github.io/tree/development/chips

Which chips are missing?

PFC154, PFC232 come to mind, but maybe there are also others.

serisman commented 4 years ago

I am not sure about the OSS status for every device, though. Are all of the currently listed devices supported?

I believe they are all supported now, but some of them require the 'development' branch of the programmer. That's why I was thinking that maybe we would specific a minimum version number for each IC. The current release 1.2 officially supports PFS154, PFS173, and PMS150C (not sure about PMS15A). The rest of them require the not yet released 'development' branch I believe. I'm not sure if there is a previous (before 1.2) version that supported some of these or not? Maybe the programmer needs a CHANGELOG...

Hm, indeed. Instead of "Yes", we should probably add the minimum version of SDCC and the programmer. But that will be quite tedious...

Yeah, not sure what to say about SDCC. Technically support started in 3.9.0 I believe, but wasn't really worth using until 4.0.0. And a lot of bugs/improvements have been made since then.

The programmer should be easier to figure out though. Unless we are trying to separate out RO support vs. full support. I vote just focus on full support, cause that is probably what most people will care about.

Other than that, there are still chips missing from here: https://github.com/free-pdk/free-pdk.github.io/tree/development/chips

Which chips are missing?

PFC154, PFC232 come to mind, but maybe there are also others.

I didn't think those were supported yet. I think PFC154 is in progress with the programmer (and working fine with SDCC), but isn't PFC232 a 16-bit IC which isn't yet part of SDCC? Are we wanting to add all devices, or only ones where support is at least in progress?

cpldcpu commented 4 years ago

Hm ok, let's skip the PFC232. It's not yet available, anyways.

serisman commented 4 years ago

Moving these out of the edit that I snuck in that you probably didn't see...

We can link the Arch column to the appropriate instruction set html files.

Did we decide whether or not to have a column to the official Padauk website for each device from this table?

Just noticed the <br>s in the chip files. That feels wrong to me. Are those actually needed for proper layout?

cpldcpu commented 4 years ago

Just noticed the <br>s in the chip files. That feels wrong to me. Are those actually needed for proper layout?

I agree, it's not nice. It's needed create proper breaks for the timer entry. Otherwise it's too long for the table.

cpldcpu commented 4 years ago

Did we decide whether or not to have a column to the official Padauk website for each device from this table?

It's actually already implemented. Clicking on the device name links to the padauk homepage. It's not 100% obvious, but there is only so much space in the table.

serisman commented 4 years ago

Just noticed the <br>s in the chip files. That feels wrong to me. Are those actually needed for proper layout?

I agree, it's not nice. It's needed create proper breaks for the timer entry. Otherwise it's too long for the table.

What does that do to the 'detail' page? Can the breaks be handled by word wrap in css instead? Or, can the table code insert the <br>'s?

serisman commented 4 years ago

Did we decide whether or not to have a column to the official Padauk website for each device from this table?

It's actually already implemented. Clicking on the device name links to the padauk homepage. It's not 100% obvious, but there is only so much space in the table.

Ahh ok. Would it make more sense to flip the links? So, keep the user on this website when they click on the main link (i.e. clicking on the device takes them the detail/pinout page) and have the sub-link take them to Paduak's website.

cpldcpu commented 4 years ago

True

grafik

cpldcpu commented 4 years ago

What does that do to the 'detail' page? Can the breaks be handled by word wrap in css instead? Or, can the table code insert the <br>'s?

It would mean introducing a different separator or break it up into two entries. Neither of those options in particularily nice.

serisman commented 4 years ago

What does that do to the 'detail' page? Can the breaks be handled by word wrap in css instead? Or, can the table code insert the <br>'s?

It would mean introducing a different separator or break it up into two entries. Neither of those options in particularily nice.

For the PWM, using a comma and splitting on that in the table code could work. But that wouldn't work quite as nice for the Timers... unless maybe the data was structured like T16, T2/T3. Or reverse that... use '/' as the separator and leave the comma between T2 and T3 alone.

Also, it looks like The PMS154C should have 2x for 8-Bit PWM.

Maybe make the main link slightly larger, and the Padauk link slightly smaller?

The COMP column could be renamed to CMP possibly. That's what Padauk calls it.

Looking pretty good by the way! 👍

serisman commented 4 years ago

PMS154C currently goes to the wrong product page. The correct one is: http://www.padauk.com.tw/en/product/show.aspx?num=14&kind=41

cpldcpu commented 4 years ago

Ok, all fixed. I hope I did not do something un-jekyllik with the font size.

I'll leave the <br> issue for another day. No good idea how to tackle this now without creating another mess.

grafik

serisman commented 4 years ago

oh, it looks like we are missing the PMS171B, which is also supported in the development branch. I'll working on a separate PR to add pinouts and chip support.

I'll make a separate issue for that too.

cpldcpu commented 4 years ago

Ok, It's live now. Closing this issue.

cpldcpu commented 4 years ago

<br> issue is now also addressed in development branch.

serisman commented 4 years ago

<br> issue is now also addressed in development branch.

Looks like a reasonable enough approach. 👍